Requirements Traceability Matrix (RTM): How to Build One That Stays Accurate

A requirements traceability matrix (RTM) is a mapping between every requirement in a release and the test cases that verify it, together with the latest result of those tests and any defects they found. Read in one direction it answers "is this requirement tested, and did it pass?" Read in the other it answers "which requirement does this test exist for?" In practice an RTM is either a spreadsheet with one row per requirement, or a report your test management system generates from links you already created between requirements, test cases, and runs. The second version stays accurate; the first one is correct on the day it is written and drifts from then on.

The matrix itself is simple. Keeping it honest across a real project, with requirements changing mid-sprint, automated tests appearing and disappearing, and results going stale after every run, is the part teams underestimate.

What a requirements traceability matrix contains

There is no single mandated format. Most working matrices carry some version of these columns:

Everything past the first five columns is optional, and every optional column is one more thing to keep current. Add design element references, code modules, or acceptance criteria only if somebody will read them. Regulated projects usually have to; a web team shipping every two weeks usually does not.

What a filled-in matrix looks like

Here is a fragment for a checkout release, the kind of thing that fits on one screen and still tells you something:

Five rows, four findings. FR-101 has a failing case with a linked bug. FR-103 is blocked, which is worse than failing because nobody knows the answer yet. FR-104 shows a green result from a test that has been quarantined for flakiness, so the green is not evidence of anything. NFR-07 has no test at all, which is the normal fate of non-functional requirements in matrices built by hand.

That last pattern is worth naming: performance, accessibility, and security requirements are the ones most often listed in a spec and least often linked to a test case. If your matrix has a row for every functional requirement and nothing for the non-functional ones, it is measuring the part of the release you were already comfortable with.

Forward, backward, and bidirectional traceability

The three terms describe which direction you follow the links, and each direction catches a different class of problem.

Forward traceability is the direction everyone builds, because "did we test everything" is the question managers ask. Backward traceability is the direction teams skip, and skipping it has a specific cost: the suite fills up with cases that verify behaviour nobody requires any more. Those cases still take execution time, still fail sometimes, and still get triaged. Running the matrix backwards once a quarter is one of the cheapest ways to find them, and it pairs well with a pass for duplicate and low-quality test cases.

Safety-critical work usually mandates the bidirectional version. DO-178C, the standard the FAA and EASA use to certify airborne software, requires trace data in both directions across system requirements, software requirements, source code, test cases, and results, with the required depth increasing with the Design Assurance Level. As Parasoft's DO-178C reference material puts it, at the lower assurance levels teams trace from system requirements to high-level requirements and then to test cases and results, while at the higher levels the links must extend down into low-level requirements and source code. The reason for the backward direction is specific: it is how certification catches orphan code, meaning implementation that no requirement asked for.

What teams actually use an RTM for

An RTM that only proves coverage is a compliance artifact. An RTM that gets opened during the week does five jobs.

Finding coverage gaps before execution starts

The useful moment for a matrix is after test design and before the run, when an uncovered high-priority requirement is still cheap to fix. Ten minutes with the forward view will usually surface two or three requirements where everyone assumed somebody else had written the case.

Impact analysis when a requirement changes

A requirement changes mid-sprint. The question is which test cases are now wrong. Without links you re-read the suite; with links you filter to the cases attached to that requirement and review a handful. This is the single highest-value use of traceability on non-regulated projects, and it is the one that disappears first when the matrix goes stale.

Scoping a regression run with a reason

Most regression suites grow by accretion: everything that ever mattered, run every release, because nobody can defend cutting anything. Traceability gives you a defensible cut. Take the requirements touched by this release plus the requirements that depend on them, pull their linked cases, and you have a regression scope you can explain to a product manager.

Making the go / no-go conversation evidential

"QA is 94% done" tells a release manager nothing about risk. "Two high-priority requirements are at risk, one because its only test is blocked on a sandbox account, one because of BUG-882" is a decision people can make. A traceability view converts test counts into requirement-level status, which is the level stakeholders think in.

Producing audit evidence without an archaeology project

Enterprise procurement, SOC 2 auditors, and regulated customers increasingly ask to see requirement-to-test evidence even outside aerospace and medical devices. If the links already exist, this is an export. If they do not, it is two weeks of reconstruction, and reconstructed evidence is usually wrong.

The wider case for taking requirements management seriously is well documented. PMI's Pulse of the Profession in-depth report on requirements management found that inaccurate requirements management was the primary cause when projects failed to meet their original goals in 47% of cases, that 5.1% of every dollar spent on projects and programs was wasted because of poor requirements management (around US $51 million per US $1 billion), and that only about one in five organizations reported high requirements management maturity. Traceability does not fix requirements that were wrong to begin with. It does make the gap between what was agreed and what was verified visible while there is still time to act on it.

When traceability is not optional

Several standards require documented, navigable links between requirements and verification evidence, and the RTM is the usual way of satisfying them:

• DO-178C (airborne software) requires bidirectional trace data across requirements, code, and test evidence, with depth scaled to the Design Assurance Level.
• ISO 26262 (automotive functional safety) expects traceable links from safety goals through technical safety requirements to verification results.
• IEC 62304 (medical device software) expects traceability across software requirements, risk management, and change control, so requirements trace to and from system requirements and risk analysis results.
• ISO/IEC/IEEE 29148 formalizes traceability as part of requirements engineering practice generally, outside any specific safety domain.

If you work in one of those domains, the matrix is a certification artifact and its format is usually dictated to you. If you do not, the honest position is that nobody is going to fine you for a missing RTM, and you should build one anyway at whatever granularity you can maintain, because the impact-analysis and release-readiness benefits pay for themselves without any auditor involved.

How to build a requirements traceability matrix

1. Decide what the matrix has to prove

Write down the question you want to answer before you open a spreadsheet, because the answer determines the columns. "Every requirement in release 4.2 has at least one executed test" needs five columns. "Every safety requirement traces to code and to a verification result, in both directions" needs a different structure and probably a requirements management tool rather than a test management one. Building a matrix without deciding this first is how teams end up with 22 columns and no maintainer.

2. Get the requirements into a list with stable IDs

Requirements arrive as spec sections, user stories, acceptance criteria, contract clauses, and Slack messages that somebody promised to write down. Collect them into one list and give each one an identifier that will not change when the wording does. If the requirements already live in Jira or GitHub Issues, use the issue key as the ID rather than inventing a parallel numbering scheme, because a parallel scheme means two systems to keep in sync and one of them will lose.

3. Pick a granularity you can maintain

This is the decision that determines whether the matrix survives, and it gets the least attention. Three common levels:

Per-acceptance-criterion traceability is the right answer for regulated work and the wrong answer for a hand-maintained spreadsheet on a two-week cadence. If you want that resolution, it has to come out of a tool that generates the view from links, not out of a document somebody updates.

4. Set an ID convention and write it down

Consistent prefixes let you read a row without a legend, and they make the links greppable later:

Two rules matter more than the exact scheme. Never renumber, because every link that points at the old number breaks silently. And never use titles as identifiers: a matrix that maps "FR-101" to "Verify guest checkout works" instead of "TC-118" stops resolving the moment somebody renames the case, which happens constantly.

5. Link test cases to requirements, in both directions

Go through the requirements and attach the cases that verify each one, remembering that the relationship is many-to-many: one requirement typically needs several cases (happy path, boundary, error handling, permissions), and one end-to-end case often covers several requirements. Then reverse the pass and look for cases attached to nothing. Some of those are legitimately exploratory or environment checks; the rest are candidates for retirement.

If you are building the case structure at the same time, our guide to creating test suites and test cases covers how suites, groups, and cases fit together before you start linking.

6. Record results and defects, not only links

A matrix with links and no results proves you intended to test something. Add the latest result for each linked case, and record which run it came from. A bare "pass" with no run reference cannot be checked by anyone, including you in three weeks. Then link the defects, so a failing row carries a bug ID rather than a shrug.

7. Name an owner and a refresh trigger

An RTM with no owner is a document that was true once. Pick one person (QA lead, business analyst, or whoever runs release readiness) and pick the events that trigger an update: a requirement changes, a test run finishes, scope is added, a release candidate is cut. If the answer to "who updates this" is "the tool, from links people already maintain", you have removed the failure mode entirely, which is the argument for generating the matrix rather than typing it.

Where the spreadsheet version breaks

Almost every team starts in Excel or Google Sheets, and for a small project with stable requirements that is a reasonable choice. The failure modes are predictable, and they are all about drift rather than about the format:

• Results are a snapshot. The matrix says pass. It said pass three runs ago. Nobody knows whether the case has been executed against the current build, because the sheet has one result column and no run history.
• Many-to-many links do not fit in cells. Comma-separated case IDs in one cell are unfilterable, and the reverse view (all requirements covered by TC-204) requires reading every row by eye.
• Automated results never arrive. Automation runs on every merge and reports into CI. Nobody transcribes those results into the sheet, so the matrix silently covers only the manual half of the suite.
• Renaming breaks links quietly. A spreadsheet has no referential integrity. Delete a test case and the ID sits in the matrix forever, pointing at nothing.
• Concurrent editing. Two people update the same release matrix during a crunch and one version wins. This is where the "final_v3_QA_updated" filenames come from.

We covered the broader version of this progression in test management vs spreadsheets, including the signals that a team has outgrown sheets. Traceability is usually the first thing to break, because it is the one artifact that depends on several other things being current at the same time.

How traceability works inside a test management system

The difference between a document and a generated view is where the links live. In a test management system, requirements are objects, test cases are objects, and the link between them is a real relationship rather than text in a cell. The matrix is then a report the system renders on demand, and it is current by construction because it reads live results.

In QAM Hub specifically, that works like this. Requirements can be created directly in the project or pulled in from Jira or GitHub, so the requirement keeps the ID your team already argues about in standups. Each requirement links to any number of test cases, and each case can be linked to several requirements, which matches how end-to-end tests actually behave. The traceability and coverage reports then read the current state: which requirements have linked cases, which have none, and what the latest execution result was for each linked case. Coverage gaps surface as a list rather than as something you notice by scrolling.

Two details matter more than the reporting itself. First, automated results land in the same picture: when an automated test title carries a TC-<number> prefix matching a manual case, QAM Hub attaches the automated result to that case, so a requirement verified by automation shows real execution status instead of a blank. The mechanics of that pipeline are in our guide to managing automated test results in a TMS. Second, milestones scope the view to a release, so the matrix answers "is release 4.2 ready" rather than "has anything ever been tested". Reports export to PDF when somebody external needs a copy.

The honest limit: linking is still a human judgment. Nothing infers that TC-118 verifies FR-101 for you, and a tool that generates a beautiful matrix from bad links produces confident nonsense. What the tool removes is the transcription work and the staleness, which is where hand-built matrices actually fail. QAM Hub is the test management system built by QA Madness, who publish this blog, so treat the specifics above as a description of one implementation rather than as a claim about every tool.

If your requirements live in Jira and you are weighing a Jira-native app against a standalone system, the trade-offs are different enough to be worth their own read: see test management tools for Jira. If you are comparing platforms generally, our comparison of test management tools covers how each one handles requirements and traceability.

Traceability on an agile team

The objection to RTMs in agile work is fair when the matrix is a document: a master spreadsheet covering a two-year backlog is waste, and it will be wrong. The practice survives when you change three things about it.

Scope it to a sprint or release rather than to the product. The question worth answering is "which stories in this sprint have tests, and did they pass", which is a view you can rebuild every two weeks without ceremony.

Use the story as the requirement. The user story already has a stable key, an owner, and acceptance criteria, so the requirement layer exists whether or not you call it that. Linking cases to stories gets you traceability without a parallel requirements document.

Generate it, do not maintain it. An agile team will not update a spreadsheet during a sprint, and pretending otherwise is how the practice got its reputation. If the links live in the tools the team already uses, the matrix is a tab somebody opens at review time.

Coverage discipline in agile is also a good place to add custom fields for risk or component, so the matrix can be filtered to the rows that matter for a given release. Our KB covers using custom fields if you want that structure on your cases.

Common mistakes

• Building it once, at the end. A matrix produced the week before release is a report, not a control. The value was in the weeks when it could still change a decision.
• Choosing acceptance-criterion granularity for a hand-maintained sheet. Precision you cannot sustain is worse than coarseness you can, because a half-updated matrix is trusted and wrong.
• Only tracing forward. You will prove coverage and never notice the 40 cases verifying a feature that was removed two releases ago.
• Leaving non-functional requirements out. Performance, accessibility, and security requirements are usually the ones with no linked case, and usually the ones that cause incidents.
• Recording results without runs. Pass / fail with no run reference is unverifiable, and it hides how old the evidence is.
• Counting a flaky or quarantined automated test as coverage. A green result from a test with a poor stability record is not evidence. Coverage should be weighted by whether the test is trusted.
• No owner. Shared ownership of a living document means nobody updates it after the second sprint.

RTM, test plan, and coverage report are three different things

They get conflated because all three appear in the same status meeting. The distinction that matters in practice: a coverage report can be high while the traceability view shows uncovered requirements, because coverage measures what you ran and traceability measures what you promised.

Frequently asked questions

What is a requirements traceability matrix in software testing?

It is a mapping from each requirement to the test cases that verify it, along with the latest result and any linked defects. Its job is to make three things visible: requirements with no test, tests with no requirement, and requirements whose tests have not passed.

What should an RTM include as a minimum?

Requirement ID, requirement description, source, priority, linked test case IDs, and status. Add the latest result and defect links as soon as execution starts, since without them the matrix shows intent rather than evidence.

What is the difference between forward and backward traceability?

Forward traceability runs from requirements to tests and finds untested requirements. Backward traceability runs from tests to requirements and finds tests that verify nothing anyone asked for. Bidirectional traceability maintains both, which is what safety standards such as DO-178C require.

Who owns the RTM?

Usually the QA lead, sometimes a business analyst or the release manager. The specific role matters less than having exactly one, plus agreed triggers for updating it. Shared ownership reliably produces a stale matrix.

Is an RTM still relevant on an agile team?

Yes, if it is scoped per release, uses user stories as the requirement layer, and is generated from links rather than maintained as a document. A master spreadsheet covering the whole backlog is the version of the practice that deserves its bad reputation.

Can I build an RTM in Excel or Google Sheets?

For a small project with stable requirements and mostly manual testing, yes, and plenty of teams do. It breaks down when results go stale between runs, when automated results need to appear in the matrix, and when the requirement-to-case relationship becomes many-to-many across a few hundred cases.

How do automated tests appear in a traceability matrix?

Only if something links the automated test to the requirement or to the manual case that carries the requirement link. A common convention is to put the case identifier in the automated test title, for example a TC-118 prefix, so the result attaches to the linked case when the run is ingested. Without a convention like that, automation stays invisible to the matrix.

How is an RTM different from a test plan?

A test plan describes how testing will be done: scope, approach, environments, roles, schedule, exit criteria. An RTM tracks which requirement each test verifies and what the result was. The plan is written once and revised; the matrix is live.

How detailed should each row be?

One row per functional requirement or user story is the level most teams can sustain. One row per acceptance criterion is more precise and worth it for regulated work or when the matrix is generated by a tool, and it is the level at which hand-maintained matrices get abandoned.

Is a requirements traceability matrix required for compliance?

For safety-critical and regulated software it is effectively required: DO-178C, ISO 26262, and IEC 62304 all expect documented, navigable links between requirements and verification evidence, and an RTM is the standard way to provide them. Outside those domains no regulation demands one, though enterprise customers and security audits increasingly ask for requirement-to-test evidence.

The part worth deciding today

The interesting question is not whether your team should have a requirements traceability matrix. It is whether the one you have is generated or typed. A typed matrix is accurate on the day it is written and degrades from there, which means every decision made from it after that day is made on old evidence. A generated one is only as good as the links behind it, and improving those links is ordinary work you can do in an afternoon.

If you are starting from nothing, do the cheap version first: give every requirement a stable ID, link the cases you already have, and run the matrix backwards once to see what falls out. The gaps that surface in that first pass are usually enough to justify the rest.