Requirements traceability matrix (RTM): free template and how to keep it current

A requirements traceability matrix (RTM) is a table that links each requirement to the test cases that verify it and to the latest result of those tests. It answers three questions at a glance: is every requirement tested, which tests are failing, and which requirement does each failure affect?

Below is a free template you can copy, a worked example, and the part most guides skip: how to keep the matrix current when requirements and tests change every sprint.

The RTM template (copy it)

Req ID	Requirement	Priority	Source	Test case IDs	Categories covered	Latest result	Last run	Owner	Notes
REQ-001		High / Med / Low	PRD §, story, ticket		Positive, Negative, Boundary, Integration	Pass / Fail / Not run	YYYY-MM-DD

CSV version:

req_id,requirement,priority,source,test_case_ids,categories_covered,latest_result,last_run,owner,notes
REQ-001,,High,,,,Not run,,,

Tip: in a spreadsheet, add a conditional format that turns the row red when Test case IDs is empty or Latest result is Fail. Those two colours are the whole point of the matrix.

What each column is for

• Req ID: a stable ID. Never reuse IDs. Tests and bug reports refer to it.
• Requirement: one testable statement. "Checkout accepts coupons" is too broad. "A valid coupon applies its discount at checkout" is testable.
• Priority: decides what blocks a release. A failing high-priority requirement is a blocker.
• Source: where the requirement came from (PRD section, user story, ticket). This is backward traceability.
• Test case IDs: every test that verifies this requirement. This is forward traceability.
• Categories covered: which kinds of tests exist. A requirement with only positive tests is not really covered.
• Latest result / Last run: the current state. A pass from three months ago is not evidence for today's build.
• Owner: who answers questions about the requirement.

Worked example: coupon checkout

Req ID	Requirement	Priority	Test case IDs	Categories covered	Latest result
REQ-101	Shopper can sign in with email and password	High	TC010, TC011, TC012	Positive, Negative	Pass
REQ-102	Cart persists across sessions	Medium	TC020	Positive	Pass
REQ-103	Valid coupon applies its discount at checkout	High	TC001, TC004, TC005	Positive, Boundary	Pass
REQ-104	Invalid or expired coupons are rejected with an error	High	TC002, TC003	Negative	Fail (TC002)
REQ-105	Expired cards are declined before payment	High	none	none	Not tested

Reading it takes ten seconds:

• REQ-104 is broken. TC002 (reject an unknown coupon code) failed. That is a release blocker.
• REQ-105 has no tests. It is high priority and unverified. That is a coverage gap you want to find before release, not after.
• REQ-102 is thin. One positive test. Is there a negative case, such as a cart after sign-out?

Forward, backward and bidirectional traceability

• Forward traceability goes from requirement to test: is every requirement tested? It finds coverage gaps.
• Backward traceability goes from test to requirement: why does this test exist? It finds orphan tests that check nothing anyone asked for, which are candidates for deletion.
• Bidirectional traceability is both. It is what auditors in regulated industries usually expect.

How to build an RTM in 6 steps

1. Collect requirements from PRDs, specs, user stories and tickets.
2. Split them into single, testable statements and give each an ID.
3. Map existing tests to requirement IDs. Mark tests that map to nothing.
4. Mark gaps: requirements with no tests, or with only one category.
5. Write the missing tests, starting with high-priority gaps. Our guide on writing test cases from requirements walks through the method.
6. Attach results from the latest run, with the date.

Why most RTMs go stale (and how to stop it)

A spreadsheet RTM is correct on the day someone updates it. Then a story changes, a test is renamed, a run fails, and nobody copies the result across. Within a few sprints the matrix describes a product that no longer exists.

The fix is to stop maintaining the matrix by hand and generate it from the links the work already has:

• Store the requirement ID on every test case when the test is created.
• Let the test runner write results against the test ID.
• Build the matrix view from those two links, so it updates on every run.

Then the RTM stops being a document and becomes a live view. It is the same view you need for a release readiness check.

How testdart keeps traceability automatic

In testdart, traceability is not a separate artefact. Project Brain extracts requirements from your specs, PRDs, user stories or Jira issues. When AI Genie generates a test case, the test is linked to its requirement from the start. Every run writes its results back, so the Requirements view shows, for each requirement, the tests that cover it, what is failing, and what has no tests yet. See how it works on the testdart product page.

FAQ

Who owns the requirements traceability matrix? Usually QA or the product owner. In practice, the RTM is only trustworthy when updates happen automatically as part of test creation and test runs.

Is an RTM only for regulated industries? No. Any team that wants to answer "is this release ready?" with evidence benefits from knowing which requirements are tested and passing.

How detailed should a requirement be? Detailed enough that one person could write a pass/fail test for it without asking a question.