Understanding Design Constraints

While previous articles focused on requirements writing, another element of products requirements is design constraints.

A design constraint might not be a requirement in the purest sense, but must be accommodated in product requirements (and, ideally, identified as such).  Design constraints almost always make their way into product requirements.

Let’s use a simple example whereby a specific housing material is specified (a polyester thermoplastic elastomer).

The requirement might simply be: “The housing material shall be made of a polyester thermoplastic elastomer”.  The PRD is then provided to the designer, essentially telling him he must use this material.

Do we simply proceed with design constraints, or do we find out more about their origins?

Identifying requirements as design constraints might invoke the following questions:

• Who established the design constraint, and why? Knowing exactly why the material was selected might be an opportunity to select an even better material (ie more scratch resistant, stronger, lighter, etc…)
• Perhaps the design constraint is provided by a product manager; therefore, somewhere between the ‘voice-of-customer’ and the design process someone other than the designer made a design decision. (Not necessarily a bad decision, but the specific need or requirement may be lost or not known.)
• The design constraint may (or may not) be validated. If the polyester thermoplastic elastomer is a housing material that’s been proven over years by similar fielded products, then the design constraint can be considered validated for the specific properties for which it’s chosen.  (Conversely, it may not be validated whereby a validated choice might be better.)

The design constraint is a universal concept, even with software; a design constraint might require certain functionality.  The same questions apply (who, why, what need does it address, has it been validated?, what is the customer going to do with the functionality or information it provides?).

While it’s acceptable to identify and specify designs upstream of the design process, ensuring linkage to customer needs, understanding higher level requirements and rationale for design decisions can save a great deal of time and effort in the product development process.