Requirement Traceability Matrix (RTM) in Testing: A Worked Example

Last updated 2026-11-01 · 11 min read · By SoftwareTestPilot

Most explanations of the requirement traceability matrix start with a definition and a blank template. That is how many testers end up with an RTM that looks complete and tells them nothing. This guide does it the other way round: we take one small feature, password reset, and build its RTM together. By the end you will know the meaning, the types and the columns, and, more usefully, what the finished table is supposed to warn you about.

RTM = Requirement Traceability Matrix. It is a table that connects each requirement to the test cases that verify it, and usually onward to execution status and defects.

"Traceability" here means you can follow a thread in either direction: from a requirement to its tests, or from a failing test back to the requirement it protects. The ISTQB glossary describes traceability as the ability to establish relationships between work products, such as requirements and tests. The matrix is simply where those links are written down.

Imagine the product owner hands you this story: "As a user who forgot my password, I want to reset it by email so I can get back into my account."

You cannot trace a sentence like that. It is not testable as one unit. So the first real step of any RTM, before any spreadsheet, is to break the story into requirements you can check with a pass or fail. After a short conversation with the product owner and a developer, we agree on six:

1. PR-01 A registered email receives a reset link.
2. PR-02 An unregistered email gets the same neutral message, so attackers can't discover which emails have accounts.
3. PR-03 The link expires after 30 minutes.
4. PR-04 The link works only once.
5. PR-05 The new password must follow the password policy.
6. PR-06 After a reset, every active session is signed out.

Notice that PR-02 and PR-06 never appeared in the original story. Writing the RTM forced the question "what exactly must be true?", and two security rules came out. That alone is often worth more than the finished table.

Here is the RTM after the first test cycle. Read it before the explanation below, and see whether you spot the two problems.

Req ID gives each requirement a short, permanent key. Never renumber; if a requirement is dropped, mark it removed so old defect reports still make sense.

Requirement is one testable statement. If you need the word "and", it is probably two rows.

Test case IDs are the cases that genuinely prove the requirement. PR-05 has three because the policy has several rules (length, character mix, not reusing the old password). If you write your cases in a tool, the ID should match exactly. Our test case template guide shows a format that keeps IDs consistent.

Status is the latest execution result for that requirement as a whole: pass only if all linked cases pass.

Defects links open bugs, so anyone can see which requirement a bug blocks.

The two problems:

• PR-06 has no test cases at all. Nobody wrote one, because session sign-out is invisible on the reset screen. Without the matrix this gap would have shipped. This is the single most important thing an RTM does: it makes a missing test visible as an empty cell.
• PR-04 is "Not run". The case exists, but it was skipped. If release day arrives with that cell unchanged, the team is shipping an unverified rule, and now they know it.

And one thing to report: PR-02 fails with BUG-58. Because the defect is attached to a requirement, the conversation with the product owner becomes concrete: "the account-leak protection is broken", not "TC-103 failed".

The three types sound academic until you map them to the example:

Backward traceability is the one teams forget. Tests with no requirement are not harmless: they slow the suite and fail for reasons nobody can explain.

Usually the QA engineer owns the RTM, with the business analyst or product owner confirming the requirement list. Update it at three moments: when requirements are agreed, when a test case is written, and when a test run or defect changes a status. Fit it into the software testing life cycle and it costs minutes, not days.

It earns its keep most in regulated work (banking, healthcare, medical devices), on fixed-scope client contracts where you must prove what was tested, and on any feature with security rules. On a small agile team, a lighter form works: link tests to story acceptance criteria inside your tracker. Jira and most test-management tools can produce this view; the Atlassian issue documentation explains the issue links many teams use for it.

A spreadsheet is fine for most projects. Practical tips:

• Freeze the first two columns so the requirement stays visible while you scroll.
• Use a dropdown for Status (Pass, Fail, Blocked, Not run, No coverage) so filters work.
• Add conditional formatting: red when Test case IDs is empty. Empty cells should be impossible to miss.
• Keep a COUNTIF summary at the top, for example how many requirements are "No coverage". That number goes in your test plan exit criteria.

"What is RTM?" is one of the most common manual testing interview questions. A definition gets you half marks. A short story gets full marks: "It's the table linking requirements to test cases and defects. On my last project it showed a session-logout rule with no test at all, so we added one before release." If you don't have a real story yet, build the password-reset matrix above yourself; then you can describe exactly what you did. You can also talk it through with other testers in the QA Community.