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. When you can link all of these items together in both directions, you have what is known as end to end traceability.
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:
During this phase, the business and system use cases need to be validated against the functional and system requirements, to ensure complete coverage.
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.
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.
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.
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 forward requirements traceability matrix for our fictitious 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|
What Kind of RTM Reports Exist?
There are different levels of requirements traceability report. The simplest form looks like the tables above and provides a summary list of the relationships between the artifacts:
However sometimes you need a detailed requirements document that includes details of all the associated downstream artifacts:
So, when you are asked to create an RTM for a project, it is wise to verify upfront what level of detail is required.
Why Should I Use SpiraTeam for Requirements Management?
SpiraTeam manages your project's requirements, use cases, tests, tasks, source code, and issues in one integrated environment, with full traceability throughout the product development lifecycle.
- It is a complete requirements management solution that provides multiple views of requirements, including a document, hierarchical, grid, mind map and agile Kanban board view.
- Writing requirements is only the start, with SpiraPlan you can plan your products work with its integrated project, product and quality management system.
- SpiraTeam lets you connect your requirements to your other product artifacts for end to end traceability, you can link requirements to your test cases, issues, tasks, defects and builds, and source code.
How do I Get Started?
To learn more about SpiraTeam and how can be used to improve your management of requirements traceability:
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