Requirements traceability refers to the ability to describe and follow the life of a requirement, in both forwards and backwards direction (i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through all periods of on-going refinement and iteration in any of these phases.)1
Performing a requirements traceability analysis is an important part of the software engineering process as it ensures that all of the requirements have been adequately considered during each phase of the project, and that there aren't any scope 'holes' in the developed system due to missed requirements. The activity also ensures that all of the requirements are internally consistent with each other and support the overarching business drivers, goals and objectives.
Requirements Traceability Matrix
The most common way of ensuring that there is full requirements traceability is by means of a Requirements Traceability Matrix (RTM). The traceability matrix is used to verify that all stated and derived requirements are associated with corresponding design elements, system components, modules and other project deliverables. This is known as the forward trace. The RTM is also used to verify and document the original source of the requirements so that if questions should arise by the customer regarding why certain features were included, there is a comprehensive audit trail. This is known as the backward trace.
The requirements traceability matrix itself can be created using simple tools like a spreadsheet or even on paper. However to avoid the need to maintain lots of separate artifacts, an integrated requirements management system is usually the best choice. Such systems allow you to manage the list of requirements and associate the other project artifacts (test cases, use cases, tasks, defects, source code revisions, presentations, interview notes, etc.) with them in a collaborative environment.
This refers to the need to document the associations between the functional and system requirements and the various artifacts created during the design, development and testing of the system. Some example artifacts that can be found at each phase include:
- Requirements - During this phase, the business and system use cases need to be validated against the functional and system requirements, to ensure complete coverage.
- Design - During this phase, the design elements, object models, data models, module designs, sequence diagrams, user interface designs and other design artifacts need to be related back to the system requirements.
- Development - During development, the unit tests and changes to the source code (e.g. commits made to the Software Configuration Management (SCM) tool) need to be linked to the requirements that they satisfy. Similarly the project development tasks should be associated with the source requirement that they fulfill.
- Testing - Requirements test coverage is a key metric in the testing activities as it ensures that all of the requirements and use cases have supporting test cases that will validate the functionality works as expected.
- Maintenance - During support and maintenance, all defects and system issues that are raised need to be associated with the module and source requirement so that structural weaknesses in the system can be rectified holistically during the next release cycle.
A forwards requirements traceability matrix for our ficticious Library Information System might include:
|ID||System Requirement||Use Cases||Design Elements||Test Cases|
|RQ1||Ability to create a new book in catalog||UC1, UC4, UC5||DE3, DE6||TC1, TC6, TC9|
|RQ2||Ability to edit existing book in catalog||UC1, UC2||DE4||TC3, TC8|
|RQ3||Ability to create a new author in catalog||UC1, UC8, UC9||DE22||TC1, TC9|
Backwards / Reverse Traceability
This refers to the need to document the lineage and source of all the requirements defined in the System Requirements Specification (SRS). As described in the section on techniques and activities for Requirements Gathering, requirements come from many different sources (written list from the customer representative, interviews with stakeholders, discussions with developers, workshop deliverables, focus groups of end-users, etc.).
These different stakeholders will have different views of the requirements, so it is a good idea to create a requirements traceability matrix to trace each developed feature back to the person, group or entity that requested it during the requirements gathering:
|ID||System Requirement||Source Documents||Stakeholders||Elictation Activity|
|RQ1||Ability to create a new book in catalog||Project Goals List 1.22.2000||Chief Librarian||Goals Development Workshop|
|RQ2||Ability to edit existing book in catalog||None - implied||Librarian Joe Smith||Requirements analysis meeting 1.30.2000|
|RQ3||Ability to create a new author in catalog||Project Goals List 1.22.2000||Chief Librarian||Goals Development Workshop|
Another form of reverse traceability is used to illustrate the relationship between the various artifacts developed during the project and the source requirements that they support. In this case it is basically the same data as the "Forwards Traceability" matrix illustrated above, just switched to the perspective of the downstream deliverables. Whereas the forward RTM made sure that all requirements were covered, the reverse RTM would make sure that unnecessary design elements, use cases, test cases, etc. were not being worked on:
|ID||Use Case||System Requirement||Design Elements||Test Cases|
|UC1||Adding new book to library catalog||RQ1, RQ2, RQ3||DE3, DE6||TC1|
|UC2||Updating the details of a book in the system||RQ2||DE4||TC3|
|UC3||Deleting a book in the system||RQ5||DE22, DE4||TC7|
1. Gotel O.C.Z and Finklestein A.C.W., "An analysis of the requirements traceability problem", in Proceedings of ICRE94, 1st International Conference on Requirements Engineering, Colorado Springs, Co, IEEE CS Press, 1994