By Spencer Barrett, Systems Engineer
WHAT ARE THE BENEFITS OF PRODUCT REQUIREMENTS?
At SIGMADESIGN, we begin with the end in mind. The product requirements define the guiding principles that take a client’s product from concept to production. Defining the Product Requirements Document (PRD) early in the development process ensures a complete picture of customer expectations are efficiently communicated to the design team. The document captures the purpose, behaviors, functionalities, and features. Product requirements drive the design requirements and the final acceptance test plan that verifies the new product fulfills the customer’s expectations.
We work closely with our clients and other stakeholders researching and eliciting the Product Requirements. Fully documenting the requirements helps communicate the client’s expectations to our design team and illuminates competing or conflicting requirements. The requirements analysis provides the most efficient, productive path to product realization because it answers critical questions early in the design process. The discovery of unknowns in the requirements analysis guides the project plan risk mitigation towards resolution early on in development. These discoveries also reduce the late stage product rework, saving clients time and resources. This detailed effort builds a true partnership with the client as we work to make their concept a reality.
WHO DETERMINES THE PRODUCT REQUIREMENTS?
Product Requirements are ideally determined by clients, who best understand their product and how it fits in the marketplace. If clarified Product Requirements don’t exist, SIGMADESIGN System Engineers collaborate with clients to arrive at a holistic view of the product; this includes defining product functionality, user interaction, and user expectations, among other considerations.
SIGMADESIGN’s team of Systems Engineers analyze the product as a system and tie together the various product pieces or technologies essential to the success of the product. Systems Engineers consider every subsystem involved in the product including electrical, mechanical, software, and firmware components. The system requirements list will include both functional and non-functional requirements that are specific and measurable.
HOW ARE GOOD PRODUCT REQUIREMENTS DEVELOPED?
Arriving at good Product Requirements is a multi-step process. One of the first tasks in designing a new product is defining Marketing System Specifications. These specifications should capture and describe what the end user expects from the product. Some examples of this include: from a Printer you expect a readable document; from an automated machine, you expect a part that meets specifications; from a vision system you expect inferior parts to be identified. These high level and somewhat abstract specifications determine the general intent and trajectory of the product. After these specifications are determined, they are translated into detailed and measurable goals. These goals are the Product Requirements and may include but certainly are not limited to the product’s footprint, weight, speed, safety, illumination, connectivity, lifespan, environmental endurance, weight tolerance, power supply, etc. Answering questions about each of these areas early in the design process is critical to the success of the product.
WHAT DO SYSTEMS ENGINEERS DO WITH PRODUCT REQUIREMENTS?
When the Product Requirements are understood, Systems Engineers work with the entire product design team to create the big, but detailed picture. This results in what is known as the System Architecture. Building the Systems Architecture is a process that considers the many solutions, their trade-offs and effects, and then builds the best solutions path to fulfill the product requirements. In the Systems Architecture, the design is broken down into subsystems and their interconnections. These subsystems are then designed in detail by the various engineering disciplines. Design reviews are performed to validate that the subsystems all adhere to the requirements. Test plans are then used to verify subsystem performance.
As a project evolves, requirements will change. Systems Engineers keep a detailed history of sign-off approval for these changes. At SIGMADESIGN, Systems Engineers use a traceability matrix to provide mapping from requirements to individual tests to verify that all features have been implemented and are able to perform as required.
Different projects have varying levels of complexity and thus various different tools to manage requirements. At SIGMADESIGN, we often use project management software applications such as Atlassian’s Jira, or Redmine. For simpler projects, something such as an Excel spreadsheet is sufficient.
WHEN ARE SYSTEMS ENGINEERS DONE DETERMINING PRODUCT REQUIREMENTS?
Defining Product Requirements is a constant effort in the design process. Requirements change as discoveries are made in the development process. Systems Engineers stay involved throughout the development process to manage the requirements and adherence thereto, all the way from the marketing system specifications to completion of system testing and system buy
Systems Engineers are not done when a product “goes out the door.” Because a product will see many versions in its lifetime, Systems Engineers stay involved as long as that product is being manufactured. A product that has been in the marketplace for many years will still undergo subcomponent updates as they become obsolete with time. Obsolete subsystems require manufacturing engineers to make updates, and Systems Engineers are again involved to ensure that the requirements are met.
HOW ROBUST REQUIREMENTS IMPROVE PRODUCT SUCCESS
Determining product requirements is key to product success. According to the Harvard Business Review, you should “Delay your launch until the product is really ready.” As expert product designers, we absolutely concur. Seizing an opportunity, product designers or inventors may see an opening in the marketplace that their product is ready to fill. The need is there, the customer is there, and their beautiful product meets the need, so it must be time to launch. Most likely, it’s not. At