There are many relationships between requirements and other requirements and between the requirements and the system design. There are also links between requirements and the underlying reasons why these requirements were proposed. When changes are proposed, you have to trace the impact of these changes on other requirements and the system design. Traceability is the property of a requirements specification that reflects the ease of finding related requirements.
There are three types of traceability information that may be maintained:
- Source traceability information links the requirements to the stakeholders who proposed the requirements and to the rationale for these requirements. When a change is proposed, you use this information to discover the stakeholders so that they can be consulted about the change.
- Requirements traceability information links dependent requirements within the requirements document. You use this information to assess how many requirements are likely to be affected by a proposed change and the extent of consequential requirements changes that may be necessary.
- Design traceability information links the requirements to the design modules where these requirements are implemented. You use this information to assess the impact of proposed requirements changes on the system design and implementation.
Requirements traceability information is often represented using traceability matrices, which relate requirements to stakeholders, each other or design modules. In a requirements traceability matrix, each requirement is entered in a row and in a column in the matrix. Where dependencies between different requirements exist, these are recorded in the cell at the row/column intersection.A traceability matrix is an ‘at-a-glance’ way of seeing the dependencies between requirements.
This is illustrated in the following table that shows a simple traceability matrix that records the dependencies between requirements. A ‘D’ in the row/column intersection illustrates that the requirement in the row depends on the requirement named in the column; an ‘R’ means that there is some other weaker relationship between the requirements. For example, they may both define the requirements for parts of the same subsystem.
| Req id | 1.1 | 1.2 | 1.3 | 2.1 | 2.2 | 2.3 | 3.1 | 3.2 | |
|---|---|---|---|---|---|---|---|---|---|
| 1.1 | D | R | |||||||
| 1.2 | D | D | D | ||||||
| 1.3 | R | R | |||||||
| 2.1 | R | D | D | ||||||
| 2.2 | D | ||||||||
| 2.3 | R | D | |||||||
| 3.1 | R | ||||||||
| 3.2 | R |
You can use a spreadsheet such as Excel to create and maintain traceability matrices when a small number of requirements have to be managed. However, this becomes unwieldy and expensive to maintain for large systems with many requirements.
For these systems, you should capture traceability information in a requirements database where each requirement is explicitly linked to related requirements. The impact of changes can then be assessed by using the database browsing facilities. Traceability matrices can then be generated automatically.