What is a requirements traceability matrix, and why does NASA require six links inside one?

Figures from SWE-052 — Bidirectional Traceability, NASA Software Engineering Handbook (NPR 7150.2). For Class A, B and C software the project manager must record and maintain bidirectional traceability across six relationships: higher-level requirements to software requirements, requirements to system hazards, requirements to design components, design components to code, requirements to software verifications, and requirements to non-conformances.

What an RTM contains

One row per requirement, one column per thing that requirement connects to. Projects differ, but a workable set of columns looks like this:

• Requirement ID — an identifier that survives reordering. We will come back to it.
• Requirement text, or a short form of it.
• Source — the customer requirement, standard clause or regulation it descends from.
• Design element — the component that implements it.
• Test case — the verification that proves it works.
• Status — where that link stands today.

Functional safety projects usually add the hazard the requirement controls, a criticality level such as an ASIL or a DAL, and the baseline in which it was frozen. You will also see it written as requirement traceability matrix, traceability matrix or trace matrix. Three alternative names for the same thing.

Forward, backward, bidirectional

Three terms that get used interchangeably and should not be. The difference decides what your matrix can and cannot tell you. Switch between them and watch which links light up.

A four-row RTM

Here is a four-requirement matrix. Switch off a verification link and watch what the matrix has to tell you about it — this is the whole job of an RTM, compressed into one table small enough to see at once.

The difficulty of an RTM is not in the number of requirements, nor in the number of links: those grow together. It is in impact analysis. When a requirement near the top changes, what needs reviewing propagates down level by level, and that count does climb fast. That is where this stops being a documentation task, usually around the second baseline.

What each standard actually asks for

"The standard requires traceability" is true and almost useless. What differs between them is how deep the evidence has to go and what document it ends up in. Pick the one that applies to you.

One detail worth knowing if more than one of these applies to you. Both ISO 26262 and Automotive SPICE demand bidirectional traceability, and along the central axis — requirements, design, test — the links are reusable. But they do not overlap at the ends: Automotive SPICE has no hazard analysis and no ASIL, and ISO 26262 does not ask you to trace requirements that are not safety-related. One infrastructure, yes; one set of links, no. Treat them as the same thing and you arrive at one of the two audits with half of it missing.

Where the spreadsheet stops working

Almost every project starts its RTM in a spreadsheet, and for a first prototype that is a perfectly reasonable decision. Nobody buys a requirements tool to manage forty requirements. The failure mode is predictable, though, and it arrives in the same order every time.

The identifier drifts

In a spreadsheet a requirement is a row. Insert a row above it and every cross-reference pointing at "row 47" now points at something else. Teams work around this with a manual ID column, which holds until two people edit the file the same afternoon and one of them wins.

Nobody knows what a change invalidated

The customer changes one top-level requirement. Which software requirements are now questionable? Which tests stopped being valid? A spreadsheet cannot answer, because the link is a piece of text, not a relationship. Someone has to work it out by reading — and they will do it the week before delivery, which is when people read fastest and worst.

The matrix is a snapshot, not a state

The RTM in the folder was true on the day it was exported. Whether it is true today is a matter of faith. Auditors have learned to ask when it was generated and from what, The question is polite; the answer is not always.

What changes with a requirements management tool

Organisations do not move to a requirements management tool because it draws a prettier matrix. They move because the matrix stops being a document somebody maintains and becomes a view generated on demand from links that already exist.

In IBM DOORS, each requirement is an object with an absolute number that never changes. Worth knowing early: the hierarchical numbering shown on screen (1.1, 1.2) does renumber when you insert above it, exactly as a spreadsheet would. What stays put is the absolute number, and that is the one to reference. Links between modules are real relationships rather than typed text, so coverage is calculated instead of compiled. And when a source requirement changes, the links below it are flagged automatically as suspect: the tool tells you what needs reviewing rather than waiting for somebody to notice.

The difference shows up at audit time. Producing the matrix goes from a week of somebody's life to a report you execute, and that report can be automated, and the answer to "when was this generated?" becomes "just now, from the baseline you are looking at".

Five ways to get it wrong

• Tracing forwards only. Half the requirement, and the half auditors trust least.
• One matrix for the whole programme. Slice by subsystem or baseline. Nobody reads a four-thousand-row table, including the person who built it.
• Linking to documents instead of requirements. "See section 4.2" is a reference, not traceability. It will not survive the document being reorganised.
• Free-text status. If "Done", "done" and "OK" all live in the same column, the matrix cannot be filtered, and a matrix nobody can filter is a matrix nobody uses.
• Building it at the end. An RTM assembled the month before certification documents what happened. One maintained from the start changes what happens.

Frequently asked