A requirement is a formal specification that identifies a condition to be met by a designed artifact.
We design things to achieve preferred situations. All designed interventions that achieve the preferred situations are valid design solutions. Requirements are conditions that will occur in the preferred situation and thus define conditions that must be true of any suitable designed intervention.
In natural languages, requirements take the form of imperative sentences the subject of which is the design intervention. For example:
These are all reasonably stated requirements.
However, natural language is a very poor tool for specifying crisp and precise engineering requirements. We therefore break requirements into types, each of which may be written as a clause or, even better, as a logical or mathematical condition.
There are three kinds of requirements:
FRs explain how the PCs are implemented functionally, and PCs explain why specific FRs are necessary. This relationship is depicted graphically in the example shown in figure 1.
There is a simple analogy between types of requirements and parts of speech in natural languages like English:
If we think of requirements as natural language statements, then we can write out some characteristics of good requirements.
Exercise for the reader: Consider the requirement “Minimize the weight of the engine.”
Is this a proper requirement according to the above-noted rules? What is the subject of the requirement?
Requirements capture the overall expectations of a design intervention in engineering terms. In other words, requirements re-state in engineering language the expectations of users and co-users for their preferred situation.
This does not mean that we only worry about engineering issues; all aspects of an intervention - including ethical, technical, aesthetics, legal, economic, social, and environmental - will influence the intervention's design.
This does mean that engineers must accommodate all the aspects of an intervention to engineer a good solution. Requirements are the “formal” way in which that is done, in a way that engineers can understand and work with the specific problem.
Requirements need to be documented and agreed to by all stakeholders for three principal reasons.
Requirements form the “official” engineering specification of a design problem - that is, of the expectations of stakeholders to address an imbalance in some situation. They constitute a reference document to which everyone involved in subsequent design and engineering tasks will refer; they constitute a question that a satisfactory design must answer.
Because of this, top-level requirements (i.e., those requirements applying to the intervention as a whole) must be defined before any specific design ideas or concepts are developed.
However, beware of creating artificial requirements not rooted in information available at that point in the design process.
The principle of coevolution tells us that only some requirements will be specifiable at the beginning of a design project - those that involve the design intervention as a whole. The design project will proceed by successively developing some requirements, then executing some design tasks, and then recurse between problem analysis and design, until a complete design is rendered.
Exercise for the reader:
For each of the following products or processes, try to determine their overall requirements. Remember, the best requirements make no reference to the structure, behaviour, or operation of the product, but rather only to the functions they serve in a larger context.
Requirements specify conditions that will apply to any design intervention able to achieve the expected situation. This therefore includes the entire PSS, the Personas, revised usage scenario, and interaction errors (especially the SIIs).
When you start a new design project, you literally have no idea what it will be. Your designed intervention is literally a “black box”, completely opaque to you; you know absolutely nothing about it.
However, you do know what role it must fulfil in a broader supersystem, in the situation into which your intervention will eventually exist. The specification of that role your intervention will fulfil is embodied in the external requirements. They're “external” because they are derived from things outside the scope of your control: climate, available power sources, external loads, abilities of users, the influence of co-users, etc.
From a systems point of view, external requirements are the top-level requirements of your intervention as a whole.
Since you do not control the external requirements, the best you can do is specify and manage them in (hopefully) clever ways. If you don't specify them well with good requirements, your intervention will not fit the situation and will therefore fail miserably.
As your design proceeds, however, you will find it necessary to develop more requirements. These are internal requirements. They are “internal” because they will become necessary once you “open the black box” of your design and start developing subsystems, assemblies, and parts. Internal requirements are very different from external ones because you have complete control over the internal requirements - so long as they do not violate any of the external requirements.
Another way to think about this is: external requirements establish the scope of control you have over the situation, and internal requirements determine how you will know that your design satisfies the external requirements.
Some people prefer to think of the external requirements as situational requirements because they arise directly from the situation itself.
Example: designing a bicycle Say you're designing a bicycle. The weight of the bicycle will be determined by the strength and endurance of the targeted users, and the nature of the terrain and climate in which the bicycle will be used. The weight of the bicycle is an external requirement because you have no control over the users, co-users, and the environment in which the product will be used. You have to make your bicycle fit these requirements.
However, the distribution of that weight among the various assemblies and parts of the bicycle is much more open to your manipulations. If the drivetrain is made heavier, then some other subsystem must be made lighter. The details of that trade-off are under the control of the designers (and subject to the laws of nature). So long as the top-level requirement of overall weight is satisfied, the design remains valid regardless of how the weight is distributed.
There are, generally speaking, two formats for specifying requirements: diagrams and lists. Lists area easier to prepare, but are harder to maintain and are more susceptible to error. This is because lists are by definition linear in nature, whereas requirements are actually more like a network of information items that are richly interconnected.
NOTE: Ultimately, it is the content of the requirements that matter, not their presentation. So use whatever representational form you want - so long as your whole team agrees to it.
MEC325 Use requirement lists.
The easiest/fastest way to build the top-level requirements of your intervention is to divide up the work among your team, and then blend the results together. So here's a simple process you can follow:
Further information for some of these steps is given below.
Remember: you are not looking for solutions yet. You're looking for the conditions that will be met by any appropriate solution. See examples below for more about this.
Each time you find a potential requirement to add, check it in two ways:
Once you've gone through everything that is your responsibility, review your draft requirements one more time - looking for further duplicates and inconsistencies.
Also, review all your requirements with respect to your team's PSS to make sure that the requirements you've generated are consistent with your team's overall strategy.
A US for a projector has a step that reads: “Projector projects image.”
The design brief explicitly states “The engine cannot weigh more than 100 kg.”
At this point, each team member will have their own list of requirements.
Now, each team collaboratively blends the lists together into a single, cohesive, diagram or list of all requirements. It may look messy at first.
There may well be several conflicting requirements, each specified by a different team member; this is the point where such conflicts must be resolved.
To resolve conflicting requirements, you will have to discuss why the conflict exists.
Many conflicts will track back to different user needs.
The key is this: you want to make sure that all your Personas can use your product, so you resolve constraint conflicts to ensure that that happens.
Finally, you clean up the diagram or list.
In a diagram, group the nodes such that they flow from PCs to FRs to constraints. Make sure that every FR is connected to at least one PC, and that every constraint is connected to at least one FR or PC. Try to minimize the number of links/arrows that cross one another. Make sure your numbering scheme is consistent and that every requirement has an ID.
In a list, check to make sure you've indented and numbered everything correctly. Also check that each of the three types of requirements are at the right level of indent and grouped in a way to which the whole team agrees.
Coupled requirements are very important. Requirements are coupled if, for instance, one FR is connected to more than one PC.
If you're using a diagram, go through the diagram and look for requirements that, in the team's opinion, will significantly interact. Make sure that the coupling is evident from the way you draw the arrows. (See requirement diagram for details.) Make sure you have documented the rationale for that coupling (because you might forget).
In the list format, coupling cannot be directly represented. However, you can insert references to other requirements (e.g., “See also R2.6.4”). We advise against just duplicating (i.e., copy/pasting) requirements to show coupling. This introduces redundancies that will increase the odds of downstream design errors.
The most typical error is that there are PCs and FRs that have no associated constraint(s). This is an error because without at least one constraint, the attribute or function is manifested infinitely by the design intervention. For instance, to say that the ladder must carry loads without constraint means that the ladder could support the weight of anything (an anvil, a house, a jetliner, a black hole) on it. Clearly, this isn't possible.
Other errors include:
Perhaps the most important part of a set of requirements are its justifications. Every requirement amounts to a decision to exclude any design that does not meet the requirement. A decision that is unjustified is not reliable. So every requirement must be justified.
In many cases, requirements are quite obvious, especially for PCs and FRs. A bicycle must move forward; car must carry people and cargo; a paper clip must hold papers together. Still, some PCs and FRs may not be obvious. These are the ones that require justification.
Constraints always require justification because they set quantitative limits on how PCs and FRs are expressed by a suitable design intervention. Constraints are also responsible for setting the criteria by which ideas and concepts for design interventions are identified and evaluated. Details on what constitutes a good justification for a constraint is given on this page.
See this page for one way to add justifications to your requirement diagrams.
In list format requirements, you can add justifications directly at an extra level of indent.
A detailed specification of the external requirements for your project.
The result of this stage is fairly straightforward: a list or diagram containing all the requirements for the current level of the system hierarchy, including quantified justifications.
There may be requirements that require longer, specialized justifications. You can add extra documentation immediately after the list or diagram to provide that documentation.
It's very important to remain focussed on only one level of the system hierarchy at a time. Building requirements that span multiple levels of the hierarchy will result in too many requirements that may conflict with one another. Read about coevolution to find out more about why this is the case.
Also remember that you may discover errors in your requirements much later. In real life, these kinds of errors can cause serious harm to both users (and co-users) and the engineers responsible for their implementation. So remember that, while you would prefer that the requirements be fixed by the end of the problem analysis stage, you may have to update them at some point later in the process. This is why it's very important to document your activities, especially in your design journal.