One way of representing requirements is with a requirements diagram.
The kind of diagram we use to represent requirements is designed to be easy to read and clearly represent the relationships between requirements.
See the bottom of the system diagram page for a list of software that can be used to create diagrams.
Here are the basic conventions for drawing a requirements diagram:
You will probably find that some requirements relate to more than one other requirement; in this case, use cross-links. In this case, you will put the requirement in question under the most “sensible” other requirement, as decided by your team, then link it to any other requirements using a red link rather than the usual black one. Do not rearrange the requirements diagram to make red links short.
A numbering convention for requirements is essential. You will be referring back to requirements often, so it makes sense to have some kind of coding scheme to simplify naming requirements. Whatever numbering convention you choose, state it clearly (for your TAs and instructors) and follow it scrupulously.
Two possible numbering schemes include:
4.2.5which would signify the 5th constraint of the 2nd FR of the 4th PC.
Make sure each node in your requirements diagram includes the ID number.
NOTE: The ID numbers are missing from the diagram examples on this page. That is no excuse for forgetting them in your own work.
This example is based on the ladder design brainstorm. If we carefully dissect the statements from the brainstorm, we can get something like the diagram shown in figure 1. This is only an initial diagram because one benefit of a requirements diagram is that it helps us recognize shortcomings in the brainstorm.
Some notes about figure 1 are in order.
Exercise for the reader Given the ladder design brainstorm, go over this requirements diagram and make sure you understand where each link and node in the diagram came from in the brainstorm.
Part of the process of developing requirements is to reflect and revise the requirements. The kinds of changes one might expect as a result could lead to a revised requirements diagram as shown in figure 2.
Further notes on figure 2 are in order.