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.

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.

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.

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.

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.

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.

• Requirement diagram