Design and Requirements: The Yin-Yang of Product Development

Although it can be used as a noun (and often is), the word “design” is first a verb. To design is to synthesize, to create. When I think of design, I tend to envision a painter at an easel, transforming an inner vision into a tangible result. In an engineering context (independent of specific discipline), the design is the activity of choosing components to assemble a greater whole. Like the painter choosing his medium and palette, the engineer relies on a familiar set of components and methods for assembling them into something useful.

But the painter must first frame the result before she or he can even contemplate applying a line. The subject, the mood, the message — all these, and more, need to be considered, which will impact the synthesis that follows. Every effort to design something needs a certain level of constraint to guide that synthesis. In the case of the artist, those constraints often come from within, guided by the inspiration and desire to convey a message. Engineering, by necessity,  is much more quantifiable and cross-collaborative — engineers face the task of synthesizing solutions that typically must meet the budgetary needs of a client. Of course before synthesis begins, every client has a vision of the solution they expect. Requirements are a tool for the client to express their precise needs and vision, in a form which constrains the design activity for the purpose of reaching product goals.

As a silly example, suppose you have a group of twenty people gathered. If you hand them colored  pencils and a piece of paper and ask each of them to draw an ice cream cone, you will probably end up with twenty sheets of paper that have some version of an ice cream cone drawn, and none will look like any of the others. Some will have sugar cones while others have waffle cones; some will have vanilla ice cream while other will have chocolate; some might have sprinkles, others might have a candy coating. Given such cursory guidance, the results will reflect the inner vision of each artist. Even for something as simple as a depiction of an ice cream cone, the potential variations are huge. None of these solutions will be “wrong” as long as they met the minimal constraints (paper, pencil, ice cream cone). However, some may better match the vision that was in your head when you made the request.

As an alternative, you can provide the group with a more complete set of instructions. For example, if you specify that the drawing shall depict an ice cream cone with vanilla ice cream, sugar cone, and rainbow sprinkles, the resulting drawings will likely look much more similar. As the number of constraints increases, the variations in solutions gets smaller. Ultimately, when the number of constraints is so great that there is only one solution, there is no longer opportunity for further synthesis or development — the synthesis has been subsumed into the requirements specification process.

This little exercise demonstrates the typically useful tension between synthesis/design and constraint/engineering requirements in product development activity. The client might tend toward specifying as many constraints as possible to ensure that the solution meets their vision, while the design engineer might lean toward fewer constraints, expanding their ability to find a viable solution that fits their vision. In a product development effort, a seasoned engineer may have a better understanding than the client of the regulatory landscape relevant to the device to be marketed, and it serves them well to prompt the client for requirements which may not have been given prior consideration.

Thus, the process of defining and refining product requirements benefits from a collaborative process between the client and the product development team. Ideally, the client will start the process by identifying the most important attributes that the product must incorporate. In practice, the client might not be aware of all the factors that impact the design of the product and a healthy conversation between the client and engineering teams will move the process along. The requirements development process culminates in a document which captures the negotiated requirements, approved in writing by both parties.

Of course, as almost everyone involved in engineering has experienced, things change. New features desirable to the client become apparent. Unexpected regulatory restrictions are imposed. An unanticipated safety risk is found. A desired component may not be available or is too expensive. These factors can, and often do necessitate a change in requirements. And most engineering organizations have suitable processes for revising requirements. A critical factor to keep in mind — requirements changes later in the development process will almost always result in increased development costs. Completing the requirements process as quickly and comprehensively as possible serves to benefit both the client and the engineering team, reducing both the product development schedule and cost.

With increasing product complexity, it becomes apparent that requirements and design exist in a hierarchy. At the top level are the product requirements, which define the must-have characteristics of the product as a complete entity. This is often referenced as a “black box” viewpoint — without insight to the innards. If the product at hand is sufficiently complex, a systems engineer is typically engaged to define the system configuration (a synthesis activity). The system configuration identifies the subsystems and their interfaces. Each of those subsystems will have a set of requirements, explicit or implicit, with appropriate negotiation between the systems engineer (pseudo-client) and subsystems engineers. Requirements beget design, design begets requirements, and so on, for as many hierarchical levels as make sense.

The bottom line is that requirements are a valuable communication tool between two parties, one of which has a need for a product (client) and the other which has the responsibility for providing a product solution (designer and engineer). And giving early, appropriate attention to requirements development will always have a positive effect on the bottom line.