Requirements Traceability

by Inflectra on

Requirements Traceability

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 tool 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.

Forward 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:

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 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.
  • 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:

Footnotes

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

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

Get Started with Spira for Free

And if you have any questions, please email or call us at +1 (202) 558-6885

Free Trial