What is Requirements Traceability?
The term requirements traceability originates from the field of software development and systems engineering.
Requirements traceability is the ability to follow the relations of a requirement to other requirements or work products, also known as artifacts. Typical artifacts are specifications, test cases, software units, source code and test results.
Traceability is achieved by establishing links between those artifacts. This applies especially if they have a direct relation - e.g. a from a requirement to the belonging test. By doing so, a hierarchy of interlinked artifacts is created.
A pragmatic approach to apply traceability is to set up a table that displays the relations between different artifacts. This table is the requirements traceability matrix. It is even possible to set up a matrix that illustrates relations between several (i.e. more than two) types of artifacts.
This blog post explains how to do this in Excel.
Relations from “Requirement” to “Validation” can be maintained in any basic spreadsheet tool.
For complex projects comprising hundreds of thousands of artifacts, a matrix may not be suitable. Instead, you may want a tool that helps you to link artifacts, or even better, which derives the links for you. You also may expect several means to analyze these relations, e.g. find all requirements that are related to failing test cases. Such tools manage traceability based on a data model that defines the types of artifacts and relations between them. This data model is a so-called Traceability Information Model (TIM).
Stakeholder requirements can be linked to System requirements, System requirements can be linked to System architecture elements, etc.
The TIM in the above picture illustrates that traceability between stakeholder requirements and any type of test case is (mediately) given because there exists a well-defined chain of links.
Benefits of requirements traceability
Requirements traceability gives you insights into your project structure, namely the existing artifacts and their relations.
In addition, you can compare the existing data to the expected data. The expectations may e.g. be given in the form of a Traceability Information Model.
Typical traceability analyses are:
- Impact analysis: Analyze the relations of a single artifact to determine the impact when this artifact changes or has a suspect state. Common use cases are analysis of the impact of a requirement change or figuring out which software component is buggy if a test-case fails.
- Coverage analysis: This analysis compares the existing traces of an artifact to the expected traces. A coverage analysis may e.g. identify requirements that are not yet “covered” (i.e. there is no such chain of links) by a test case.
Based on traceability data, you can define KPIs for your project. Imagine e.g. a software project which defines the status of customer requirements as follows
- New = not traceable to any other artifact
- Analyzed = traceable to at least one software requirement
- Implemented = traceable to a software unit
If you can manage your data well, you may set up an automated KPI reporting which runs periodically. If your traceability model does also consider project management data such as development tasks with effort estimations, you can even calculate your project progress automatically.
An empirical study revealed that in the field of maintenance, subjects performed their tasks 24% faster and reduced the error rate by 50% with traceability applied.
Traceability also helps you to prove compliance with development processes or standards. Due to its benefits, traceability is in fact mandatory for most of these standards. If your driver for traceability is standard compliance, be aware that traceability is mandatory for a reason. Do not strive to set up traceability with minimal efforts. Instead, consider maximizing the ratio of benefits to efforts.
Challenges in the field of requirements traceability
The biggest challenge in the field of traceability is to find a suitable approach for your project. The main driver is the complexity of your project(s), i.e. the number of artifacts, traceability links, artifact types, and link types.
As a rule of thumb (and completely ignoring other aspects such as reporting, which are considered below), we have the following:
| project complexity [no. of artifacts] | Traceability approach |
|---|---|
| ~ 150 | conventions, brains |
| ~ 1,500 | requirements traceability matrix |
| ~ 150,000 | tool-based approach |
| ~ 1,150,000 | custom solution |
For small projects, traceability can be implemented by naming conventions (e.g. test case TC-72 verifies use case UC-72).
With rising project complexity, you may want to utilize a spreadsheet tool to manage your traceability data - most likely in the form of a requirements traceability matrix (RTM). An RTM is said to be
one of the most valuable things people almost never do.
If your project is too complex for manual approaches you should consider a professional tool to manage your traceability data. Such tools bridge traceability gaps even across engineering tools and support e.g. traces from a requirements management tool via a modeling tool to test benches, software repositories, etc. This covers not only data analysis but also navigation across tools. You may e.g. navigate from a model element (in a modeling tool) to the belonging software unit (in an IDE). Technically, these tools are often based on manual data exchange (i.e. im- and exports) or by generic data crawlers or extractors. In either case, the challenge here is to synchronize data that resides in different sources. An aggravating aspect is the conflictual relation of concurrent changes and data synchronization - imagine a tester who just specified a test for a requirement which in parallel had been changed.
If it happens that even a generic off-the-shelf tool cannot cope with your project’s complexity, you might consider building a custom solution. This is e.g. the case for complex systems engineering projects, e.g. in the field of autonomous driving with tens of millions of artifacts.
If you want to track the history of your artifacts and their relations, you can even get more insights - e.g. from an automated project progress report. In this case, you need to set up a data storage that supports these temporal aspects.
Another key challenge - especially if your projects are big - is to set a meaningful reporting both on a high level and on a detail level. Imagine a project progress metric that does not look well: Not only should the project lead be able to figure out the actual bottlenecks - i.e. the affected parts/components of your project, but also the responsible engineer should get information about the actual reasons - e.g. which test cases are failing.
The level of tool integration is another success factor for traceability. If your tools are integrated well, a developer may e.g. have access to the requirements specification from inside his IDE.
We just named the important challenges in the field of traceability. At itemis, our challenge and our aspiration are to provide the maximum benefits of traceability for you - either in the
form of itemis ANALYZE or a custom solution.