Requirements traceability matrix template
A free RTM template in Excel and CSV, pre-filled with a worked example. Six columns, two of them calculated. Below it: what each one is for, how to fill it in, and what to do when the spreadsheet stops keeping up with your requirements.
Take the template
Both files are free and download directly. No email, no sign-up.
- A matrix sheet with the six columns below, pre-filled with the worked example
- Coverage and Result as formulas, because both are calculated rather than typed
- A sheet per document (User Needs, Requirements, Test Report) for the row detail the matrix does not carry
- Dropdowns on Verification method and Test Result, a frozen header, filters, and blank rows ready to fill
- A "How to use" sheet with the seven steps, and an honest list of what a spreadsheet cannot do
What a filled-in matrix looks like
Seven rows from a cardiac sensor project. A user need on the left, then each hop of the chain, then the two columns you read rather than write. This is what opens when you download the file.
| Source | Requirements (SRS) | Test Protocol (TP) | Test Report (TR) | Coverage | Result | Why |
|---|---|---|---|---|---|---|
| UN-001 | SRS-001 | TP-101 | TR-101 | Pass | Pass | |
| UN-002 | SRS-003 | – | Gap | – | Protocol retired, chain stops | |
| UN-003 | SRS-008 | TP-106 | TR-106 | Pass | Pass | |
| UN-004 | SRS-004 | TP-108 | TR-108 | Pass | Fail | Endurance measured at 6 d 4 h |
| UN-005 | SRS-011 | TP-112 | TR-112 | Pass | Not run | Executed, result never recorded |
| UN-006 | – | – | – | Gap | – | No requirement written yet |
| – | – | TP-120 | – | Gap | – | Reached by nothing: an orphan |
Three rows fall short, in three different ways. UN-002 stops at a protocol that was retired when the alarm design changed. UN-006 has no requirement written against it at all. TP-120 has no source: it is a test case nothing points at, which is a coverage gap running the other way. The last column is commentary for this page, not part of the matrix. Coverage and Result are not either, in the sense that matters: both are worked out from the rest of the row, which is why they are formulas in the download.
Six columns, and you type into four
A traceability matrix earns its keep by answering one question per column. Everything that describes a requirement rather than a trace belongs somewhere else.
| Column | What it is for |
|---|---|
| Source | The rows. Every Trace ID in the documents you nominate as the starting point, usually user needs or top-level requirements. One row per ID, and the column can be renamed to whatever you call that level. |
| A column per hop | Each hop names one or more documents the chain may step into: requirements, then protocols, then reports. The cell holds the Trace IDs actually reached at that hop, which may be none, one, or several. Add, reorder and rename hops to suit the project. |
| Coverage | Pass when the last hop is reached, Gap otherwise. Calculated, never typed. A row that fills the first two hops and stops is a Gap, which is the point. |
| Result | The verdict rolled up from the results in the chain: any fail makes the row Fail, otherwise any pass makes it Pass, otherwise a result that exists but was never recorded reads Not run. Also calculated. |
What goes on the requirement row
Most matrix templates pull these into the matrix, and that is where the drift starts: the same fact in two places, one of which nobody updates. Keep them on the row they describe. The download gives each document its own sheet for exactly this.
| Column | What it is for |
|---|---|
| Trace ID | The unique, stable identifier. Never reuse one and never renumber: the ID is what both ends of a trace point at, so a renumber silently rewires the matrix. |
| Requirement | The requirement text itself, in one testable statement. |
| Verification method | Test, inspection, analysis or demonstration. A property of the requirement, not of the trace, which is why it belongs here. |
| Owner | Who is accountable for closing the row. Useful when the gap list gets long. |
| Notes | Justification for anything unusual: a requirement verified by analysis, a deviation, a rationale for a not-applicable row. |
| Test result | On the test report row rather than the requirement: pass, fail, or blank for not run. This is the column the matrix Result column reads. |
Traceable works the same way. Each of these is a column on the row inside its own document, and the matrix shows the ones you choose inside the linked chip, so you can see a requirement’s owner in the matrix without storing it there twice.
Seven steps, and the one that fails
- Give every row a stable, unique Trace ID, in its own document. User needs in one document, requirements in another, protocols and reports in their own. IDs are the only thing holding the matrix together, and they have to survive rewording, reordering and renumbering of the source document.
- Put the row detail on the row, not in the matrix. Requirement text, verification method, owner and notes belong on the requirement itself. Pull them into the matrix and you are maintaining the same fact twice, which is how the two start disagreeing. The matrix carries IDs, coverage and result.
- Choose the source documents. Whichever level you want one row per: usually user needs, sometimes system requirements. Everything else in the matrix hangs off these rows, so this decides what "covered" is being measured against.
- Set up one hop per step of the chain. Requirements, then protocols, then reports. A hop can cover more than one document, so a hop named Verification can hold both your protocol and your inspection records. Fewer hops is usually better: each one is a question you are asking of every row.
- Fill the hop cells by following the links. Which requirement realises this need, which protocol verifies that requirement, which report records the run. Where a hop reaches more than one ID, list them all. An empty hop mid-chain is not an error on its own, but it is worth a look.
- Read Coverage and Result, do not set them. Coverage is Pass when the last hop is reached and Gap otherwise. Result rolls up the recorded results: any fail makes the row Fail, otherwise any pass makes it Pass, otherwise Not run. Typing over either one is how a matrix ends up claiming coverage it does not have.
- Re-check the whole matrix after every change. This is the step that fails, and it fails silently. Nothing in a spreadsheet knows that a requirement was reworded or a protocol retired, so a stale row keeps reading as covered until a person checks it by hand.
Steps one to six are a morning of work. Step seven is the rest of the project, and it is where spreadsheet matrices die. For the longer walkthrough see how to create a requirements traceability matrix, and for what this looks like under a medical device QMS see traceability matrices for medical devices.
What it looks like when nobody maintains it
The same six columns, the same rows, the same three gaps. The difference is that every cell here is read from the current trace links rather than typed, so coverage and result cannot outlive the evidence behind them.
Six mistakes that make a matrix worthless
- Typing Coverage or Result in by hand. Both are conclusions drawn from the links. Written down as values, they become a second opinion that quietly outlives the evidence.
- Copying requirement text and owners into the matrix. The same fact in two places will disagree, and the matrix is the copy nobody updates.
- Renumbering Trace IDs when the source document is reorganised, which breaks every trace pointing at them at once.
- Tracing downward only. Without a source column of needs you can show that every requirement was tested, but not that every need is met.
- Leaving out the rows nothing reaches. A test case no requirement points at is a coverage gap in the other direction, and it will not appear unless you look for it.
- Keeping the matrix in a second file that has to be updated whenever a requirement changes. It will not be.
When the template stops being enough
A spreadsheet matrix is the right answer for a small, slow-moving project, and it is the right way to learn what the columns are for. It stops being the right answer at the point where requirements change faster than anyone re-checks the file. After that the matrix is not wrong in an obvious way, which is worse: it is confidently out of date, and nobody finds out until a review.
The fix is not a bigger spreadsheet. It is to stop storing the trace in a second document at all. See how Traceable generates the matrix from live trace links, what that changes for medical device teams, and how it compares with running requirements in Excel.
Common questions
What columns should a requirements traceability matrix have?
Fewer than most templates give you. A source column of the needs or top-level requirements you are measuring coverage against, one column per step of the chain (requirements, then protocols, then reports), and two calculated columns: coverage and result. Requirement text, verification method, owner and notes are properties of the requirement, so they belong on the requirement row, not in the matrix.
Why is verification method not a column in the matrix?
Because it describes the requirement, not the trace. Put it in the matrix and it has to be copied there and kept in step with the requirement, which is exactly the duplication that makes matrices go stale. In the template it sits on the Requirements sheet; in Traceable it is a column on the requirement row, shown inside the linked chip when you want it.
Is there a free requirements traceability matrix template for Excel?
Yes. The Excel workbook on this page is free, needs no sign-up, and opens into a pre-filled matrix with coverage and result as formulas, a sheet per document for the row detail, dropdowns, a frozen header, filters, and a How to use sheet. There is a CSV version too for Google Sheets and Numbers.
What does a filled-in requirements traceability matrix look like?
The worked example on this page shows seven rows from a cardiac sensor project: a user need traced through its requirement, its protocol and its report. Three rows fall short in three different ways, because showing the gaps is what the matrix is for.
What is a simple requirements traceability matrix?
One source column, one or two hops, and coverage. That is enough to show that every need reaches a verification. Add the result column when you start recording test outcomes, and add hops only when you actually have a document at that level.
What is the difference between forward, backward and bidirectional traceability?
Forward traceability follows a requirement down to the design and tests that realise it. Backward traceability follows it up to the need or regulation it came from. Bidirectional traceability is both, which is what auditors expect. In this shape the source column and the hops together give you both directions, and the rows with an empty source are the backward gaps.
How do I keep the matrix from going out of date?
You cannot, in a spreadsheet, beyond re-checking it by hand after every change. Nothing in the file knows a protocol was retired or a requirement reworded. In Traceable the matrix is generated from live trace links instead: you choose the source documents and the hops, and every row, its coverage and its result are derived from the links as they stand.
Do I have to give you my email to download it?
No. Both files download directly. If the spreadsheet upkeep is the part you want to be rid of, the same structure runs on live links in Traceable.
Skip the spreadsheet upkeep
Build your traceability matrix on live links and let it stay current on its own.