Requirements Traceability Matrix

Download RTM template (CSV)

A requirements traceability matrix (RTM) is a table that maps each requirement to the test cases that prove it. If a requirement has no cases, the matrix shows a gap. If a case has no requirement, the matrix shows work that may be leftover or unscoped.

That is the whole job. An RTM is not a project plan, not a test strategy, and not proof that the product is “certified.” It is a coverage map you can argue with.

Download the CSV above, or copy the blank table below into Sheets, Excel, Jira, Azure DevOps, or TestRail.

What a requirements traceability matrix is

Each row is one requirement. Each row answers four questions:

1. What did we agree to build?
2. Where is that agreement written?
3. Which tests cover it?
4. Is that coverage complete, partial, or missing?

If you cannot answer those four for a release, you are testing from memory. Memory does not survive a staff change, a slipped date, or a prompt rewrite on an AI feature.

The matrix is useful in both directions:

• Forward: from requirement to tests. “We said users can reset a password. Which cases prove it?”
• Backward: from test (or defect) to requirement. “This failed. What requirement is actually broken?”

Bidirectional traceability is those two views on the same data. You do not need two files.

Why teams keep one

Without an RTM, coverage debates become opinions. Engineering thinks login is “covered.” QA ran two happy-path clicks. Product assumed locked-account behaviour was in scope. The matrix makes the disagreement visible before the release, not after a customer email.

It also stops two expensive habits:

• Writing dozens of cases that do not map to anything anyone asked for
• Shipping a requirement that nobody designed a test for

On manual and functional testing work we treat the matrix as the spine: cases hang off it, and the test plan points at it. A QA audit often starts by asking whether this table exists and whether anyone trusts it.

What to put in each column

Keep the column set small. Extra columns that nobody updates become decoration.

Column	What it holds	What “done” looks like
Requirement ID	Stable ID (REQ-014, US-221)	It does not change when the wording is edited
Requirement statement	One testable sentence	A stranger can tell pass from fail
Source	PRD section, ticket, regulation clause, email decision	You can find the original ask
Priority	Business or risk rank	Used to decide what to cover first when time is short
Test case IDs	IDs from your test case template	Every listed case exists and is current
Coverage status	Covered / Partial / Uncovered / Out of scope	Partial always has a note
Owner	Who must close the gap	A person, not “QA” as an abstraction
Notes	Why coverage is partial, or why a row is out of scope	Dated if the decision will be challenged later

Do not store full test steps in the RTM. Steps live in the case. The matrix only stores IDs.

Blank requirements traceability matrix template

Requirement ID	Requirement statement	Source	Priority	Test case IDs	Coverage status	Owner	Notes
REQ-					Uncovered

Copy that header row and add one row per requirement, not per test. If one requirement needs eight cases, those eight IDs sit in one cell.

How to build an RTM

1. Collect the requirements that this release actually promised. User stories, a PRD, a changelog, and “we told the customer it would work” emails all count. If it is not written down, write it down as a row before you invent cases.
2. Rewrite each row as a testable statement. “Improve onboarding” is not a requirement. “A new user can create an account with email and a password that meets the published rules” is.
3. Give every row a stable ID. If your tracker already has IDs, use those. Do not invent a second numbering system unless the tracker IDs are unusable.
4. List existing cases against each row. Pull from the current case list, not from memory of “we always test that.”
5. Mark coverage honestly. Happy path only is Partial. No cases is Uncovered. “We will test it exploratorily” is still Uncovered until you write what you will look for.
6. Prioritize the Uncovered High rows. That list is the real test-design backlog.
7. Re-check the matrix when scope changes. A story split, a prompt change, or a “quick” API tweak is a new or edited row.

If you have no cases yet, the matrix is still worth building. An Uncovered column is a plan.

Worked example (not a client project)

A generic sign-in change. Four requirements, mixed coverage.

Requirement ID	Requirement statement	Source	Priority	Test case IDs	Coverage status	Notes
REQ-001	User can sign in with email and password	PRD 2.1	High	TC-101; TC-102; TC-103	Covered	Valid, invalid, empty password
REQ-002	User can reset password via email link	PRD 2.2	High	TC-110	Partial	Expired-link and reused-link cases missing
REQ-003	Account locks after five failed sign-in attempts	SEC-14	High		Uncovered	No cases mapped
REQ-004	Session expires after 30 minutes of inactivity	PRD 2.4	Medium	TC-140	Covered
REQ-005	Sign-in errors do not reveal whether the email exists	SEC-09	High	TC-102	Covered	Shared with invalid-password case

What this matrix tells a lead in ten seconds: lockout is a High gap; password reset is only half-done; you should not call sign-in “fully tested” until REQ-003 has cases.

The downloadable CSV uses this same example so you can see the format in Excel.

How to read coverage

Covered means there are cases for the happy path and the failures that the requirement implies. A sign-in requirement that never tries a wrong password is not covered.

Partial means you can name the missing slice. If you cannot name it, mark Uncovered. Partial without a note is how matrices rot.

Uncovered is not a moral failure. It is a decision: test it, drop it from the release, or accept the risk in writing.

Out of scope needs a source. “We will do it later” is not a source. A ticket moved to the next sprint is.

When you report a release, do not say “87% of cases passed.” Say “18 of 22 in-scope High requirements are Covered; the four gaps are ….” That sentence is why the RTM exists.

Spreadsheet vs Jira, Azure DevOps, and TestRail

A CSV is enough for a small product. It is also the right export format when a tool already holds the links.

• Spreadsheet: fastest to start; dies when two people edit it without a rule. One owner, or it forks.
• Jira / Azure DevOps: use issue links (story → test, test → bug). Export a matrix when someone outside the tool needs to see coverage.
• TestRail and similar: store the requirement IDs on cases and generate the matrix from the tool. Do not maintain a second handwritten table that disagrees with the tool.

We have used all three shapes on engagements. That is not a partnership or certification claim. Pick the store your team will actually update.

Agile, changing stories, and “we don’t write requirements”

Agile teams still have requirements. They are just shorter and they move. The RTM should move with them.

Practical rules that survive a two-week sprint:

• One row per story or acceptance criterion, not per epic
• When a story is split, split the row
• When a story is dropped, set status to Out of scope and keep the row until the release notes are written
• Do not wait for a “frozen spec.” Freeze the matrix at the start of test execution, then log deltas

If the only requirement is a Figma file, write the testable statements yourself and put Figma / checkout v12 in Source. An RTM that waits for a perfect PRD never starts.

AI and LLM features

Model-backed features still have requirements. They are just easier to fake-pass.

“The assistant answers billing questions” is not testable. Split it:

• Answers only from the allowed billing documents (RAG evaluation)
• Refuses account-takeover requests (guardrail testing)
• Does not invent invoice numbers (hallucination testing)
• Calls the refund tool only with a valid order ID (AI agent testing)

Each of those is a row. The cases may be evaluation sets rather than click-paths. The matrix still holds.

A prompt or model change is a requirement change. If you do not add a row, you will not notice that last month’s cases no longer match what you shipped. That is the failure mode described on AI testing services.

Common mistakes

• One row for the whole product. “The app works” cannot be traced.
• Mapping to test suites instead of cases. “Regression pack” is not an ID you can open.
• Green status for a single happy path. That is Partial.
• IDs that get reused. Never recycle REQ-001 for a new ask.
• Keeping defects in the matrix. Defects belong in the tracker and can link back via the case ID. Use the bug report template for the write-up.
• Updating the matrix after the release only. Then it is a souvenir.

Related templates

• Test case template — the IDs in the matrix
• Test plan template — the release that this matrix covers
• Test strategy document — whether you require an RTM at all
• Bug report template — when a mapped case fails

If you want Nexus Eclipse to build the matrix on a live product and then execute the gaps, that is functional testing or a QA audit of coverage — not a document sale.

FAQs

What is a requirements traceability matrix?

A table that maps each requirement to the test cases that cover it, and shows which requirements still have no tests.

Is an RTM only for regulated industries?

No. Healthcare and finance teams often need one for audits, but any team that cannot say what a release covered will benefit. We do not issue compliance certificates; we help you see coverage.

How is this different from a test plan?

A test plan says what will be tested in a release, by whom, and when. The RTM says which requirements have cases. You usually want both. The plan points at the matrix.

Can I keep the RTM in Jira instead of a spreadsheet?

Yes. Links between stories and cases are the matrix. Export a CSV when someone needs a single view.

How often should we update it?

When scope changes, when cases are added or retired, and when you start execution for a release. A matrix updated only at the end of the year is not in use.

Do you provide a filled matrix for our product?

Not as a free download — that would be invented work. On an engagement we build it from your stories and then test the gaps. Book a QA consultation if that is what you need.