A requirements traceability matrix that clients can read
A traceability matrix answers one question: is every requirement tested, and did the tests pass? Here is a simple template, a worked example, and how to keep it from going stale.
What a traceability matrix is for
A requirements traceability matrix (RTM) maps each requirement to the test cases that cover it and their latest results. Services firms are asked for one in three situations:
- Before UAT, to show the client that every story has been tested.
- In audits, especially for banking, insurance and healthcare clients.
- When scope is disputed, to show what was agreed and what was delivered.
The template
One row per requirement is easiest to read. Keep it to these columns:
| Column | What goes in it |
|---|---|
| Requirement | The story key and title, such as "PAY-112 Pay a bill with a debit card" |
| Priority | From the backlog |
| Test cases | The keys of every case that covers it |
| Latest result | Passed, failed, blocked or not run, from the most recent run |
| Open bugs | Keys of bugs still open against it |
| Status | Covered and passing, covered with failures, or not covered |
A worked example
| Requirement | Priority | Test cases | Latest result | Open bugs | Status |
|---|---|---|---|---|---|
| PAY-112 Pay a bill with a debit card | Critical | PAY-T12, PAY-T13, PAY-T14 | 3 passed | None | Covered and passing |
| PAY-115 Save a card for later | High | PAY-T20, PAY-T21 | 1 passed, 1 failed | PAY-140 | Covered with failures |
| PAY-118 Download a payment receipt | Medium | PAY-T25 | Not run | None | Covered, not run |
| PAY-121 Pay with UPI | High | None | None | None | Not covered |
The last row is the reason to build the matrix. A requirement with no test cases is a risk you want to find before the client does.
How to build one from a spreadsheet
- List the requirements. Export the stories in the release from your tracker, with keys and priorities.
- Add the case keys. For each story, list the test cases that cover it. If your cases already have a story column, a lookup does this for you.
- Add the latest results from the most recent test run.
- Add open bugs linked to each story.
- Sort by status so "not covered" and "failed" rows are at the top.
Keeping it from going stale
A matrix built by hand is out of date the moment someone runs a test. A few habits help:
- Link test cases to stories when you write them, not when the matrix is due.
- Build the matrix from the latest run, not from memory.
- Rebuild it for every release, not once per project.
- Share it with the release message, so the client sees coverage and results together.
Generating it automatically
If stories, test cases and runs live in one tool, the matrix can be generated instead of assembled. In NaatOps, the Traceability view under Tests lists each story with its linked test cases and API checks, whether they pass and the bugs the tests found, and counts the stories with no tests. It can be downloaded as an Excel file or printed to PDF for the client.
See the client release report, read the UAT sign-off checklist, or start free.
Stories, tests and API checks in one place
Free for up to 10 users. Team and Delivery start with a free trial, no card needed.