Fig. 1: An initial requirements diagram for a ladder.

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:

• Colour-code your nodes: blue for PCs, green for FRs, and red for constraints.
• Lay out your diagram left-to-right, with the product in the top left corner (in a white node, so that it isn't confused with other types of nodes).
• Arrange the nodes in four columns. First come PCs, then the FRs, then the constraints.
  • There may be two “sub-columns” for PCs. The left column is for the general PCs and the right column is for derivative PCs that are specific to your design problem.
• PCs can connect only to other PCs, to FRs, or to constraints.
• FRs can connect only to other FRs, or to constraints.
• Constraints can connect only to other constraints.
• Connect related nodes with links in black. Cross-links are in red. (See below for more.)
• New nodes (requirements) are added such that the link explains the relationship between the one requirement and other requirements that it affects or is affected by. (See examples below for more.)
• Keep links from crossing one another, and as short as possible.
  • The diagram you get with only black links should look like a “tree” graph (technically, a directed acyclic graph) running from left to right.

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:

• Just giving a unique numeric ID to each requirement, regardless of whether it's a PC, FR, or constraint.
• Numbering in levels - e.g., 4.2.5 which 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.

Fig. 2: Revised requirements diagram for the ladder.

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.

1. The diagram is currently a tree, but this is rarely the case for complete requirements diagrams.
2. Many of the statements had to be rephrased to keep a consistent use of nodes. This kind of consistency is important because it helps keep the designers thinking in a structured way.
3. It should be glaringly evident that there is a lot missing from this initial diagram; for example, there is only one FR. This should raise suspicions in the team that not all the important issues have been addressed.

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.

1. There are now loops evident in the diagram (the red cross-links) – it is no longer a tree. The loops show the interactions between various issues very clearly.
2. Most of the interrelations (loops) occur among the PCs and FRs.
3. The diagram is still not complete, but even this is enough to demonstrate clearly the relative complexity of even relatively “simple” products.