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.

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:

• The car must travel at least 20 km on one litre of gasoline
• The robot must lift up to 200 kg
• The maximum elastic deflection of the wing cannot exceed 2 m at the wingtip

A structural constraint limits characteristics of the product itself rather than how it works. For example:

• The engine must have an aluminum block
• The exterior of the electric motor will be painted Royal Blue
• The car cannot weigh more than 1000 kg

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.

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.

• This design decision implies a variety of other constraints that might not have mattered if we had chosen some other power source.
  • For example, Lead-Acid batteries are quite heavy compared to other kinds of batteries.
• This means that the structural strength of the chassis will have to change — indeed, the constraints on the structure of Lead-Acid battery-powered cars are usually extraordinary because of the weight of the batteries.
• There is also a concern for safety — carrying around all that acid can't be all that safe.
  • This will lead to other constraints on the structure, wearing on key components, materials selection, etc., to ensure that the car's occupants are protected from leaking acid.

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.

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.

• If you don't specify the maximum weight of a ladder, that means the ladder can weigh literally any amount that's greater than zero and less than infinity.

It's bad because it will lead to poor decisions in later stages of the design process.

• If you don't specify enough constraints, you will end up with either (a) arbitrary downstream decisions that cannot be justified - and therefore have no reason to be “correct” - or (b) impossible designs that cannot be built, or used, or maintained, or….

Consider the following constraint: The operating current to the electric kettle is 10 A.

• This constraint would likely be justified by referring to the total current that is available in the situation we're designing for, and the other electrically-powered items that might be on the same circuit and on at the same time.

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.

• Impact loads are much more damaging than gently applied loads, because they're applied over very short times.
• Cyclically repeating loads will eventually make a product fail even though the value of each loading is relatively low.
• Currents and voltages will vary significantly over most reasonable periods of time.
• Weather conditions will change (cyclically or randomly) sometimes over significant ranges.

When you set constraints, you need to be aware of these ranges and the impacts they can have on your design.

• If you're designing a battery-powered product that will recharge using solar power, you need to design for the shortest day (and longest night).
  • The longest night will set an upper limit on how much power the battery must store.
  • The shortest day will set an upper limit on how long you have to recharge the product.
  • Fortunately, the shortest day and the longest night tend to happen within a single 24 hour period on Earth.
  • Unfortunately, there are places on Earth when the shortest day is 0 seconds long.
  • Of course, this assumes a cloudless sky….

[EF94]: “…a rule that is applied to a relation to define its meaning.”

• Many kinds of constraints:
  • Structural constraint: defining relationships between objects (e.g. existence, arity, dependency).
  • Invariant constraint: constraints that are (must be) always true.
  • Variable constraint: define relations between variables.
  • Variant constraint: constraints that are not necessarily always true.

> 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