DesignWIKI

Fil Salustri's Design Site

Site Tools


design:requirement_list

Requirement List

One can use simple nested lists to capture requirements.

What is a requirement list?

A requirement list is a nested list, four levels deep, that is used to capture requirements.

  • The top (outermost) level list is for PCs.
  • Under each PC, and indented one level, are the FRs that define how the PC is achieved.
  • Under each FR, and indented one more level, are the constraints for each FR.
  • Under each constraint, and indented one more level, is a justification for having set the constraint's value.

Some PCs may not have corresponding FRs, but will definitely have at least one constraint.

We use numbered lists for requirements, so that we can subsequently identify requirements by their numeric code. This saves a lot of writing later in your project reports. The justifications need not be numbered.

Example of List Format Requirements

  1. Functionality
    1. turn
      1. Max turning radius <= 3m
        • Turning radius based on smallest area in which turning is expected in any SUC, which is the private road in SUC 3.
      2. Max turning speed <= 20 kph
        • See Appendix 4.2.
    2. change speed
      1. Max acceleration cannot exceed 400W human power generation sustained for 10s.
        • See Appendix 4.3.
      2. Max stopping distance shall be less that described here by 10%.
    3. resist bending loads
      1. bending moment <= 10kN.m along its total length
        • Max applied load per design brief applied over max possible length per design brief.
      2. bending moment <= 2kN.m from either end to 1/4 length
        • Max applied load per design brief applied over length to required attachment point per design brief.
    4. resist corrosion
      1. no more than level 2 (source) over 5 years
        • Flaking corrosion could fall into machinery and cause damage, and so must be avoided.
        • Maintenance over the 5 yr life (per design brief) of this part would be costly, so we design this to not corrode over its operating life.
    5. …other requirements….
  2. Usability
    1. protect user
      1. all corners/edges will be chamfered r=2mm or greater (cf R1.g)
      2. maximum applied foot force in normal operation: 400N1).
    2. …other requirements….

Notice the reference to some other requirement (in the example, R1.g). This is how you note coupling between different requirements - simply by referring to another requirement by its numeric ID in a logical/meaningful place.

YOU MAY USE WHATEVER NUMBERING STANDARD YOU LIKE, SO LONG AS YOU CAN UNIQUELY IDENTIFY A GIVEN PC, FR, AND CONSTRAINT.

Why do we use requirement lists?

Requirements lists:

  • are easy to generate and maintain;
  • provide a visual cue to separate PCs, FRs, and constraints;
  • group FRs and constraints sensibly with respect to their purpose in the overall design;
  • maintain causal relationships between PCs, FRs, and constraints for tracing rationale;
  • embed rationale (justifications) directly to facilitate verification and validation; and
  • are easily and quickly communicated by referring to their numeric IDs.

When do we use a requirement list?

Lists are linear organizations of information. Requirements, on the other hand, are generally richly interconnected networks of information. Because of this, it is often better to use a diagrammatic format to capture requirements. However, requirement lists, because they are very simple to create, remain useful for relatively simple design problems.

How do we create a requirement list?

One uses the information generated in project initialization and problem analysis as the basis of a requirement list.

Look first for all PCs and create a list with one bullet per PC. Next, look for FRs, and add each FR as a sub-bullet under a suitable PC. Finally, look for constraints and add each constraint as a sub-sub-bullet to a suitable FR.

Next, one reviews the requirement list for consistency and errors. It is likely that there are missing constraints. Remember, every PC and FR must have at least one constraint to limit the extent to which that PC or FR is exhibited by any suitable design intervention.

One must also document the rationale for each non-trivial requirement. This can be done by using nested numbered lists for the requirements, then, as a separate document, providing a justification for the requirements by simply referencing the requirement's number ID.

However

It is usually the case that requirements are coupled in non-linear ways. The only way to linearize requirements is to duplicate some requirements in the list. This can lead to significant problems for managing changes to the requirements. Every time a requirement changes, one must review the entire list for duplicates that must also be changed.

The requirements document for the SSRMS (the robotic arm on the International Space Station) was over 8,000 pages long. Managing change in a list-oriented requirements document that is so large is very likely to produce significant errors as requirements are changed.

Requirement lists are best for only small, simple design problems.

See Also

1)
R.G. Mortimer. 2007. Foot Brake Pedal Force Capability of Drivers. Ergonomics, 17(4):Pages 509-513. https://doi.org/10.1080/00140137408931381
design/requirement_list.txt · Last modified: 2021.05.20 15:29 by Fil Salustri