Requirements traceability

A bug discovered during acceptance testing. Looking back at the project history, the finding is straightforward: the requirement was documented, but no test had ever been associated with it. Earlier test coverage would have been enough to avoid rework, delays and non-compliance.

In regulated industries (aerospace, medical, defense, automotive), this kind of situation raises a fundamental question:

How can you ensure that every requirement is covered by a test, and that this coverage is verifiable throughout the project?

DO-178C, IEC 62304, ISO 26262 and ASPICE leave no room for approximation on this point. They require formal, documented proof of requirements coverage.

Requirements traceability, or req-to-test, links each requirement to the test that verifies its implementation.

What is requirements-to-test traceability?

Requirements traceability links each requirement to design and verification activities, from the specification document to test results. These links are formalized in a traceability matrix, which centralizes the relationships between each requirement and its associated tests.

It is an essential tool for managing test coverage and demonstrating compliance in a regulated context.
Requirements traceability operates according to three complementary approaches:

• Forward traceability: starts from the requirement and links to the associated test cases.
• Forward traceability: starts from the requirement and links to the associated test cases. It ensures that no requirement is left without test coverage.
• Backward traceability: traces back from the test to the original requirement. It guarantees that every test exists for a documented and verifiable reason.       

Why is req-to-test traceability essential in software projects?

Ensure test coverage

In a project without formalized traceability, it is difficult to guarantee that no requirement is left without test coverage. These blind spots represent:

• direct non-compliance risks
• undetected malfunctions
• late correction costs

Often, these consequences prove more costly than implementing traceability from the outset.

Test coverage cannot rely solely on team goodwill or occasional manual checks. Without an explicit link between each requirement and its tests, entire areas of the system can go undetected until acceptance testing, or even after delivery.

Meeting regulatory requirements

In regulated industries, req-to-test traceability is not optional: it is an audit criterion for all critical industrial projects.

The main industry standards are explicit on this point:

• ISO 26262 (automotive): requires demonstrating that each safety requirement is covered by verification tests, whose results are documented and traceable.
• IEC 62304 (medical software): requires establishing links between software requirements, implementation tasks and verification activities, throughout the lifecycle.
• DO-178C (aerospace): requires complete traceability between high-level requirements, low-level requirements, source code and associated test cases.
• ASPICE requirements (automotive SPICE): assesses the ability of teams to maintain consistency between requirements, tests and execution results, as an indicator of process maturity.

In an audit context, the absence of traceability constitutes a major non-conformity that can block certification.

Facilitating maintenance and evolution

In any software project, requirements evolve. A regulatory change, a client specification update or a functional correction can impact several parts of the system simultaneously.

Without an up-to-date traceability matrix, identifying all the tests affected by a change becomes a lengthy and risky exercise.

Req-to-test traceability makes it possible to immediately identify:

• when a requirement changes

• which test cases need to be updated or re-executed.

It limits unintentional regressions and helps contain the cost of changes throughout the project.

How to create a requirements-to-test traceability matrix?

Setting up a requirements-to-test traceability matrix follows a four-step approach.

1. List all requirements with a unique identifier:
   The first step is to identify all project requirements and assign each one a unique identifier (REQ-001, REQ-002, REQ-003…).
   This identifier must remain stable throughout the project, even if the requirement content evolves.
2. Create the associated test cases:
   For each requirement, one or more test cases are defined and identified in the same way (TC-001, TC-002…).
   Each test case must be explicitly linked to its requirement, specifying execution conditions, input data and expected results.
3. Build the traceability matrix:
   The most common traceability matrix takes the form of a cross-reference table:
   rows represent requirements,
   columns represent test cases, each cell indicates whether the link exists (covered) or not (not covered).
   This table makes it possible to identify at a glance orphan requirements — those for which no test has yet been defined.
4. Track execution statuses:
   Once tests have been executed, the matrix is enriched with results: passed, failed, not executed.
   The actual coverage rate can then be calculated: the proportion of requirements verified by at least one successful test.

The limits of an Excel matrix

For small-scale projects, an Excel-based matrix may be sufficient initially.
However, this approach quickly reaches its limits as the project grows in complexity:

• Manual maintenance: every change to a requirement or test case must be manually updated, with a high risk of errors or omissions.
• No live link: the Excel matrix is a static document, disconnected from tickets, test executions and development tools. It reflects a snapshot in time, not the real-time reality of the project.
• No history: it is impossible to know who changed what, and when — a critical gap in a regulatory audit context.

These limitations push regulated teams towards dedicated tools, capable of managing traceability in a dynamic and auditable way.

Which tool for managing req-to-test traceability?

The choice of a requirements management and traceability tool depends on:

• the size of the project,
• the level of process maturity,
• the regulatory requirements the team is subject to.

In regulated environments, one criterion stands out: maintaining consistent and verifiable traceability throughout the project.

Tuleap meets this need. Within a single environment, manage requirements, test cases, execution campaigns and development tracking.

Best practices for maintaining effective traceability over time

Setting up a traceability matrix is not enough: it must be actively maintained throughout the project. Here are five practices that make the difference between formal traceability and truly operational traceability.

1. Assign a traceability owner within the team. Traceability does not maintain itself. Designating a point of contact ensures that links between requirements and tests are created, updated and verified at every stage of the project.
2. Update the matrix with every requirement change, not at the end of the project. Traceability updated at the end of a project is reconstructed traceability — and therefore unreliable. Every requirement change must immediately trigger the update of associated links and the identification of impacted test cases.
3. Automate the test / requirement link in the tool rather than maintaining it manually. Manual entry is a source of errors and omissions. A tool that automates these links reduces the administrative burden and ensures reliable traceability over time.
4. Generate the coverage report at every sprint or milestone. The coverage rate is only useful if it is monitored regularly. Integrating this report into the project rhythm makes it possible to detect uncovered areas before they become risks.
5. Integrate the traceability review into the definition of done criteria. A requirement is only truly “complete” when it is covered by at least one validated test case. Incorporating this criterion into the definition of done anchors traceability in daily practices, rather than treating it as an end-of-cycle obligation.

Req-to-test traceability only has value if it is maintained continuously, and not reconstructed on the eve of an audit.

Tuleap enables this traceability to be implemented natively, linking requirements, test cases and execution results in a unified ALM environment.

FAQ

What is requirements traceability?
Requirements traceability links each requirement to design and verification activities, throughout the development cycle. It ensures that no requirement is left without test coverage, and that every test is justified by a documented requirement.

How to create a traceability matrix?
Creating a traceability matrix follows four steps:

• identify each requirement with a unique identifier (REQ-001…),
• create the associated test cases (TC-001…),
• build the requirements / tests cross-reference table,
• track execution statuses to calculate the actual coverage rate.

Which tools for req-to-test traceability?
Several options exist, from spreadsheets to specialized ALM tools such as Polarion, DOORS Next or Codebeamer. Tuleap offers native traceability between the requirements tracker, test cases and execution campaigns, with integrated coverage reporting.

Which standards require requirements-to-test traceability?
Regulated industry standards require formal demonstration of requirements management:

• DO-178C in aerospace,
• IEC 62304 for medical software,
• ISO 26262 in automotive,
• ASPICE for automotive process maturity assessment.

In each of these frameworks, traceability constitutes an audit criterion.