One can use simple nested lists to capture requirements.
A requirement list is a nested list, four levels deep, that is used to capture requirements.
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
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.
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.
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.