A constraint is a hard quantitative limit placed on the range of possible values of some design variable.
A functional requirement describes what a product must do. Constraints limit the extent of the product's performance. That is, constraints limit your selection of how functions can be provided.
A key function of a car is to move people and cargo. To power such a vehicle, one might choose an internal combustion engine, a fuel cell, batteries, or some hybrid. But if there is a constraint that says the car must have “zero emissions,” then you are limited in your selection. Also, the amount of people and cargo that the vehicle must carry will put significant limits on the nature of the power system; the amount of people and cargo is a constraint on the minimum power the vehicle must develop.
Furthermore, without constraints, one must assume that the car can carry any number of people and any amount of cargo. Obviously, this is not possible.
Put another way, functional requirements direct a designer's creativity, whereas constraints limit that creativity.
Constraints take the form of minima, maxima, or optima. There are two kinds of constraints that are relevant here.
A functional constraint limits the way the product works or how it behaves or performs. Some examples of functional constraints are:
A structural constraint limits characteristics of the product itself rather than how it works. For example:
Functional constraints are very important because they detail the limits on the kinds of functions and performances expected of the product. They have tremendous impact on the decisions made about a product's design. They are also very hard to extract from design problem specifications and from your client.
On the other hand, structural constraints are almost always undesirable early in a design process, but are very common in typical design problem specifications. They're undesirable because they're usually unfounded: if the product doesn't yet exist, then how can one justify using, say, aluminum, for some of its parts? How does one know that aluminum is the best material without knowing about the function of the product? Although structural constraints are undesirable, they are also sometimes unavoidable. That is, your client will, for whatever reason, insist that certain structural constraints be met by your design.
Some structural constraints, however, do make sense - such as the maximum weight example in the list above. These constraints are typically driven by aspects of the design situation and will often also relate to the human factor capabilities of the product's users.
Rule of thumb: Functional constraints are important and useful, and should be specified formally early in a design process. Structural constraints should be avoided wherever possible.
Note that all these constraints regard the product itself from an operational point of view. Operational constraints are those that regard how the product will perform in use. But these are not the only constraints that might appear in a design problem.
Life-cycle constraints are those placed on a product due to other stages of its life-cycle besides its use. This includes manufacturing, distribution, end-of-life, cost, etc.
Environmental constraints, on the other hand, are constraints imposed upon the product from outside the product or its design. For example, legal and regulatory constraints, physical laws (e.g. laws of thermodynamics), corporate issues, as well as constraints arising from its operating environment – for example, “The product must function within a temperature range of 0 to 50 degrees centigrade (because it will be used in a desert).”
Sometimes, some constraints can be relaxed; that is, the limits can be changed, or the constraints can be eliminated entirely. One would prefer as few constraints as possible, in order to promote innovation and creativity. So once all the constraints have been identified and categorized, one possible task designers should do (but do rarely, unfortunately) is dispute those constraints that are unreasonable.
Consider again the example: design a zero-emissions car. Saying the car must produce no (presumably harmful) emissions constrains the problem. This constraint is external to the problem — it was set by the problem itself based on the underlying need for a new car design.
However, relatively few constraints are known at the beginning of a design project. The constraints that are known are all exerted from outside the design problem itself. Perhaps your client defined them; or they may result from government regulation; natural laws (e.g. the laws of thermodynamics) are also constraints on designs.
As your design proceeds, however, you will find it necessary to place further constraints on the product.
For example, in the zero-emission car design, we might have decided to use Lead-Acid batteries.
Most of the constraints in a product design are those imposed by the design itself — the internal constraints — rather than those imposed by the overall design problem.
But there's a problem: How can you know what those internal constraints are before you've started designing the product?
Answer: You can't.
This means that you will revisit your requirements often to add new constraints as you encounter parameters that must attain certain values in any suitable design solution.
This also means you needn't get all the requirements in the first pass through your project. It's vital to get all the most significant requirements that affect your design as a whole; the other constraints can come later.
An often overlooked aspect of constraints is that they limit the behaviour and function of an intervention to satisfy the needs and abilities of human beings. So it's essential that the justification for a given constraint track back to a Persona.
While human needs do not necessarily account for every constraint, it's your responsibility to ensure that all those constraints that do involve HFs clearly specify the connection when you justify your constraints.
Consider how HFs relate to the following circumstances where constraints would be specified.
A missing constraint means that there are literally no limits on the extent to which a PC or FR may manifest in a design.
This is both good and bad.
It's good because it gives you the space you need to look for innovative new solutions.
It's bad because it will lead to poor decisions in later stages of the design process.
Consider the following constraint: The operating current to the electric kettle is 10 A.
What will the kettle do if the actual current is only 9 A? What about if it's 9.9999 A? What if it's only 2 A?
And what if the current is 15 A? What about 10.0001 A?
No natural phenomenon works exactly to the degree we expect or want it to. Even if we could design a kettle that only worked at exactly 10 A, what would be the point? The available current may or may not vary outside the scope of our needs and we have no way to control it.
There will be a minimal current that is needed for the kettle to function at all, and there will be a maximum current beyond which one should expect a fuse to blow or a circuit breaker to open. Your job as a good designer is to set both those limits.
Thus, good constraints will typically be defined as a range of values. For instance, our kettle might be designed to work with a current between 8 and 11 A, even though we may target 10 A as the optimal current.
Thus, the constraints on the current in the kettle problem would take the form of a range: The operating current to the electric kettle is between 8 and 11 A.
NOTE: We have excluded here the notion of safety factors, which are multipliers used to overdesign products to ensure safety during operation.
Another feature of constraints that many designers forget about is that they can vary over time. Unfortunately, that variation can often lead to premature product failures if they have not been properly accounted for during design.
When you set constraints, you need to be aware of these ranges and the impacts they can have on your design.
[EF94]: “…a rule that is applied to a relation to define its meaning.”
> There are many more types, depending on the characteristics one chooses to distinguish one type from the other. — Fil Salustri 2013.07.29 19:28
[SB93]: “…the rules, requirements, relations, conventions, and principles that define the context of designing.”
This encapsulates the school of thought that “everything is a constraint.” I find this not particularly useful. — Fil Salustri 2013.07.29 19:28