DesignWIKI

Fil Salustri's Design Site

Site Tools


design:requirement

Requirement

A requirement is a formal specification that identifies a condition to be met by a designed artifact.

What is a requirement?

Fig. 1: The relationship between PCs, FRs, and constraints.

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:

  • The car must weigh less than 1000 kg.
  • The furnace must operate at 800C +/- 10C.
  • The machine may generate noise of at most 20 dB.
  • The stapler must be safe to use.

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:

  1. product characteristics (PCs) that specify what a product must be;
  2. functional requirements (FRs) that specify what a product must do; and
  3. constraints that specify the limits on the extent of PCs and FRs.

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:

  • PCs are analogous to adjectives and adjectival clauses;
  • FRs are analogous to verbs or verbal clauses; and
  • Constraints are analogous to adverbs or adverbal clauses.

If we think of requirements as natural language statements, then we can write out some characteristics of good requirements.

  • A single requirement takes the form of a sentence that begins “The intervention must be…” (for PCs) or “The intervention must do…” (for FRs). That is, the subject of a requirement is the intervention being designed.
  • Requirements apply to the system level at which you are currently working. If you are designing a car, for example, do not add requirements that pertain to the engine, the driver's seat, etc.; those will come later.
  • A single requirement statement includes either a PC or an FR, and at least one constraint.
  • The verb must is used to indicate a requirement that absolutely must be satisfied by any viable design intervention.
  • The verb should is used to indicate a requirement that must be satisfied by any viable product, unless satisfying it will violate a “must” requirement.
  • Requirements must be phrased as positive statements. For example, “The engine must not weigh more than 1000 kg” is considered a weaker requirement than “The engine must weigh 1000 kg or less.”
  • Every PC and FR must have at least one associated constraint.

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.

  1. Documented requirements present a “fixed target” for the design team. If requirements are not written down, they will tend to change over time. This is bad, because you may end up designing a solution that no longer suits the actual imbalance that needs to be addressed.
  2. Documented requirements form a means of communicating important design information. Designers are not the only people involved in getting a product to market. Other stakeholders besides the designers need to know and understand the requirements. Documented requirements become a reference of information used by all participants in the product development process.
  3. Documented requirements often become part of contracts with clients and sub-contractors. Requirements define what a design intervention will be and do. They describe what you promise your client, and thus are a good basis for contracts between designers and clients. Similarly, if you outsource parts of the design to other companies, you would expect them to provide solutions based on requirements that you set; again, this forms the foundation of contracts you would enter in to with those other companies.

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.

  • A jet-liner.
  • Checking out at a grocery store.
  • An umbrella.
  • An automobile.
  • Taking a blood sample.
  • An aglet.
  • Preparing some KD.

Specifying requirements

Requirements specify conditions that will apply to any design intervention able to achieve the expected situation. This therefore includes all the information you've developed so far for your project.

The expected situation is a situation in which all your Personas, using your design intervention in the corresponding SUCs, will be maximally satisfied, while other people and the environment at least will not be harmed or disadvantaged in any way.

It is important to note that, because of coevolution, you will not necessarily be able to determine all the necessary requirements at the outset of your project. You will likely find other necessary requirements at later stages of the process. This is normal and to be expected.

When you run into such a situation, you must carefully add the new requirements, verify that the entire set of requirements remains consistent and valid, and then double check all your work to ensure that the new requirements aren't invalidating some other design decisions.

External vs internal requirements

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.

  • How can you set a constraint on the maximum weight of the bicycle without knowing the shape, size, or materials that you'll use to build it?

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.

Learn about requirements lists & diagrams

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.

Steps to develop the requirements

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:

  1. Each team member develops their own requirement list, taking into account only their own Persona and SUC as well as any relevant information from the situation scan.
  2. As a team, blend all the requirement lists into a single list or diagram.
  3. Clean up the layout and organization of the requirements.
  4. Check for coupled requirements, inconsistencies, and other problems.
  5. Document justifications for (a) all constraints and (b) any non-trivial product characteristics and functional requirements.
  6. Package up a deliverable.

Further information for some of these steps is given below.

Dissect and categorize

Each team member must do the following:

  • Imagine watching a movie in which the Persona uses your (still hypothetical) design intervention in your SUC.
  • That user will have to go through three stages: setting up or initializing the intervention, actually using the intervention, and putting the intervention away or finalizing it.
  • Think of every step they'd have to go through to achieve their goals.
  • For each step, think of all the things the intervention must do.
  • Make a rough list of all those things. These are your draft requirements.

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 three ways:

  • Check for non-functional requirements: your requirements should make no commitment to the shape, size, materials, etc. of your intervention. Remove such requirements, or rephrase them to only specify functions and limits on the extent to which those functions must manifest.
  • Check for duplicates: You may already have that requirement; you don't need to write it down more than once.
  • Check for consistency: You may already have some other requirement that conflicts with the new one.
    • Eliminate inconsistencies as you find them; do not leave them for later - you'll forget.
      • For instance, say you decide that you need a constraint that The intervention will not produce more than 60dB of noise. But you find you already have a constraint that sets the maximum allowable noise to 85dB. This is an inconsistency and must be resolved. It's best do it as soon as you discover the problem.

Also, review all your requirements with respect to your team's situation scan (especially the goals and strategy sections) to make sure that the requirements you've generated are consistent with your team's overall strategy.

Example

Assume:

  • your Persona is Nana Viola, who is an 80 years old grandparent, and in good general health, except (a) she has moderate arthritis in her hands, and (b) uses vision glasses with progressive lenses;
  • your SUC is “Viola is preparing smoothies for her 3 grandchildren at home on a hot summer day. She is the only caregiver in the home at this time”;
  • the intervention is stored in an upper cabinet in the home's kitchen;
  • the design brief expects the intervention to be powered by electricity; and
  • the team's https://deseng.ryerson.ca/dokuwiki/design:situation_scan#strategy is to focus on food preparation and usability rather than innovation in the internal machinery of the product, whatever that may be. (This means we can assume conventional elements like electric motors, power cables, etc.)

Since we're only designing the intervention, we don't worry about things like:

  • Does Viola know where the intervention is?
  • Can Viola open the door of the cabinet in which the intervention is stored?
  • Did someone push the intervention so far back on the upper cabinet shelf that Viola cannot see or reach it?

Here are some of the first steps that Viola who likely perform, with some possible FRs and constraints.

  • Viola grasps the product on the upper cabinet shelf.
    • Requirement: The product must facilitate grasping by relatively small, arthritic hands.
      • Presumably, Viola's Persona is sufficiently well-defined that we can estimate her hand size and the range of motion that moderate arthritis affords.
  • Viola lifts the product slightly.
    • Requirement: The product must weigh no more than X kg.
      • This is not an acceptable requirement yet because we have not specified X. However, we want to write it down, for the sake of knowing that we will have to find a value of X.
      • The value of X will be determined by determining the maximum lifting force that can be exerted by an otherwise healthy 80-year old woman with moderate arthritis in her hands, as well as the kind of grip she can employ to hold the product.
  • Viola lowers the product to the counter before her.
    • Requirement: The product must support a grip that lets users lower the product to a countertop without changing grip.
      • Basically, this requirement calls for a single grip to be required throughout the lowering process.
      • To quantify this requirement, the designer must determine, for the case of elderly women with arthritis, what single grips will allow a range of movement from “above the head” to “counter height”.
      • Furthermore, given a grip, the minimum strength expected by the user will feed into the maximum weight constraint on the product.
  • [ … various other steps … ]
  • Viola selects the mode of operation of the product.
    • For a conventional “blender”, we might have written this as “Viola pushes the desired speed button for the blender.”
    • However:
      • we do not yet know if “speed” will be used to control the blender's behavior;
      • we do not want to call it a “blender” to help avoid fixation; and
      • we do not yet know if the product will have “buttons”.
    • Therefore, we write the step above in functional terms that does not refer to structure, material, etc.
    • Requirements:
      • The product must prepare food in various modes.
        • We must determine what the modes of preparation are. Some similar products provide only “speed” settings on a numeric scale; others have more culinary settings, like “blend”, “puree”, “liquify”, etc. These modes will define the constraints on what modes are expected of our product.
      • The product must accommodate users' HFs when users are selecting mode of operation.
        • Can Viola see the controls under the lighting circumstances one might expect in the SUC?
        • Can Viola operate the controls? (What forces can she exert comfortably with her hands?)
        • Can Viola's hands & fingers reach the controls without accidentally pressing other controls?
        • Should Viola use a voice-activated interface because of her arthritis? Would she see this as a benefit or as a marginalization (“Voice-enabled things are for old, useless people!” shouts Viola.)
        • The answers to all these questions will eventually become constraints on the mode selection.
          • For instance, assuming Viola can exert only 5N with her index finger, then one constraint on mode selection could be phrased as The product must require no more than 5N to select operating mode.

Organize the diagram or list

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.

  • For instance, one team member may have a constraint on the minimum cargo capacity of a human-powered vehicle of 50 kg, while another team member may have specified a minimum capacity of 100 kg.
  • In your team, you will have to discuss the rationale for those constraints. Remember that you cannot change the users' needs because you cannot change human beings.
  • Don't forget to consider the influence of co-users on the reactions a user might have. For instance, a rambunctious child may weigh much less than 50 kg, but their movements may create far worse conditions for the user.
  • Let's say the 50 kg constraint arises from considering one Persona's grocery carrying needs, and the 100 kg constraint arises from another Persona's need to bring three 6-year old children to school (including their books, lunches, etc.)
  • If you decide to keep the 50 kg constraint, then the other Persona will not be able to use your team's design - which defeats the whole purpose of the exercise.
  • Thus, in this case, the team should probably decide to use the 100 kg constraint.
  • Note that this says nothing about how the constraint will be satisfied by an eventual intervention.
    • You may decide, during concept design, to have a modular design such that the basic product carries 50kg, but that you will provide some kind of attachment (e.g., a “trailer” of some sort) that can add another 50kg of carrying capacity. But that's not important right now. All that matters now is determining the maximum carrying capacity you will have to design for.

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.

Check for coupled requirements

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.

Check for 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:

  • Concrete requirements. Set aside requirements that name structural elements of a potential design intervention. Requirements are about function, not structure.
  • Too much detail. Remember what level of the system hierarchy you are working on. Set aside requirements that apply to elements that are not at that level of the hierarchy.
    • If you are designing a car, do not add requirements about the power generated by the engine at this point.
    • If you are designing a printer, do not add requirements about the speed of movement of the print head at this point.
  • Redundancies. Some requirements may just be same, but phrased differently. There should never be redundant requirements. If you find redundant requirements, sit with your team and figure out why that is. It may be that they are truly just repetitions - in which case, the redundant requirement may be removed. However, there may be some subtle difference between them. You'll need to make sure that the differences are accounted for somehow in your other requirements.
  • Omissions. Is there are least one constraint associated with each PC or FR? There should be. Make sure that you have reasonable constraints for every PC and FR. Did you miss any obvious FRs? Example: If you are designing a bicycle, did you forget to specify that the bicycle must be able to turn?
  • Imprecision. Make sure that the constraints are quantitative. This may not be possible for every constraint given the limitations on the project, your resources, your knowledge and experience, etc. However, this is no excuse for at least trying to set quantitative constraint values.
  • Negatively phrased requirements. Requirements must not be phrased as negatives (e.g. “The ladder cannot conduct electricity.”) Look for negatively phrased requirements and rewrite them as positives (e.g. “The ladder must be electrically insulated.”) Of course, there may be some requirements that you simply cannot phrase positively. Check with your instructor in these cases; he may be able to lend assistance.

Document justifications

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.

Deliverables

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.

However

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.

You will probably not find all the necessary external requirements at first. You must remember to revisit the requirements often and add new ones as you discover the need for them. Most often, the requirements you will add will be constraints.

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.

See Also

design/requirement.txt · Last modified: 2021.05.20 15:10 by Fil Salustri