RTM Explained: Tracing Requirements Through to Test

A Requirements Traceability Matrix answers a question that is embarrassingly hard to answer at the end of a project: was every requirement actually built, and how do we know?

It is a table linking each requirement to the design that addresses it, the code or component that implements it, and the tests that prove it. Read forwards, it shows coverage. Read backwards, it shows why a piece of work exists at all.

What it is genuinely for#

Proving coverage. Not "we ran 400 tests" but "every requirement has at least one test, and here they are". Those are different claims, and only the second one supports a go-live decision.

Impact analysis. When requirement FR-023 changes, the matrix tells you which design sections, components and tests are affected. Without it, that is an archaeology exercise performed under deadline pressure.

Finding orphans in both directions. Requirements with no test — the coverage gap. Tests with no requirement — either scope somebody added quietly, or a requirement that exists only in the test team's head. Both are worth knowing.

Evidence. In regulated, contracted or audited work, traceability is frequently not optional, and reconstructing it afterwards costs several times what maintaining it would have.

What it looks like#

At its simplest, one row per requirement:

The columns that earn their place are the requirement identifier, the source it came from, the tests that verify it, and the verification status with a date. Everything else is useful on some projects and overhead on others.

🔴 The whole structure rests on stable requirement identifiers that are never reused. If FR-014 means one thing in March and another in June, every historical reference silently becomes wrong. Retire identifiers; do not recycle them.

Building one that stays current#

The failure mode is universal: the matrix is built once, presented at a gate, and abandoned. Three things prevent it.

Generate it, do not maintain it by hand. If requirement identifiers appear in your tests and your tickets, the matrix can be produced from the tools you already use. A spreadsheet updated manually by one person is accurate on the day it is made and misleading a fortnight later.

Make it a by-product of normal work. Tagging a test with the requirement it verifies takes seconds while writing the test and is nearly impossible to reconstruct later.

Update it at the same moment requirements change. A change that does not reach the matrix breaks the chain quietly — and the matrix will still look complete, which is worse than looking incomplete.

When it is worth the effort#

Honestly: not always, and pretending otherwise is why the practice has a bad reputation.

Worth it when the work is regulated or audited; when delivery is contracted and "delivered" must be demonstrable; when the system is safety- or money-critical; when there are many requirements and several teams; or when handover to a different maintainer is coming.

Rarely worth it for a small team on a short piece of work with a shared understanding of scope and a good test suite — there, the tests themselves are the traceability, and a separate matrix is a document that competes with them for accuracy.

The middle position works for most projects: trace the requirements that matter — the regulated ones, the contractual ones, the ones tied to money or safety — and let ordinary tests cover the rest.

The two directions#

Forward tracing — requirement to test — answers "have we built and proved everything asked for?" This is the coverage question, and it is what a sponsor wants before go-live.

Backward tracing — test or component to requirement — answers "why does this exist?" This is what protects you from scope that accumulated without a decision, and it is invaluable when somebody asks whether a feature can be removed.

A matrix that only goes one way answers half the question. Both directions cost the same to maintain if the links are recorded once.

Common mistakes#

Vague requirements. You cannot trace "the system should be user-friendly" to a test, so it gets mapped to something loosely related and the matrix records a coverage that does not exist. The matrix inherits the quality of the requirements; it cannot improve on it.

One test mapped to fifteen requirements. Usually a sign the mapping was done to fill the column rather than to describe reality.

Status that is never revisited. "Passed" against a test that was passed in March, on a build from March, on requirements that changed in May.

Built for the audit, not for the team. A matrix produced two weeks before a gate review is a document, not a control. It tells you nothing you could have acted on.

Kept in a personal spreadsheet. One person, one file, one laptop — and the project's evidence of completeness leaves when they do.

A realistic starting point#

Number your requirements. Tag each test with the requirement identifiers it verifies. Generate the matrix from those tags weekly and look at two things only: requirements with no test, and tests with no requirement.

That is a working traceability practice, it takes minutes a week, and it produces the two lists that actually change what you do next.

FAQ#

Is an RTM only for waterfall projects?#

No, though that is where the formal version originated. Agile teams trace constantly in a lighter form — acceptance criteria linked to stories linked to tests. The principle is identical: know what proves each requirement. The heavy matrix is a formality of contracted and regulated work, not of the concept.

Who owns it?#

Whoever owns quality for the project — commonly the test lead, with the business analyst maintaining the requirement side. It needs a single owner, because a matrix maintained by everybody is maintained by nobody.

How often should it be updated?#

Whenever requirements or tests change, which in practice means continuously. If updating it is a separate task somebody schedules, it will lag; if it is generated from tagged artefacts, it cannot.

What if requirements have no identifiers?#

Add them before anything else. Traceability without stable identifiers is impossible, and retrofitting them is far cheaper than the alternative of tracing by requirement text, which breaks the first time someone edits a sentence.

Does it prove the system works?#

No. It proves each requirement has been verified by something. Whether the requirements were the right ones is a different question, answered by UAT and by the business, not by a matrix.

Can we generate it automatically?#

Largely, if requirement identifiers appear in test names, ticket references and commit messages. Most modern toolchains will produce the report from those links. The manual part that remains is deciding what a link means — and that part is worth a human.

Is it needed for a small internal project?#

Usually not as a document. Keep the discipline of numbered requirements and tests that name them; skip the matrix until somebody has to demonstrate coverage to someone outside the team.

Related Articles#

Requirements come from the BRD, FRD and SRS; verification happens in UAT; scope changes arrive through Change Management.

What else is coming for RTM