Requirements traceability matrix

A requirements traceability matrix that stays current

Stop maintaining coverage by hand. Choose the documents your rows start from, add a column for each hop of the chain, and Traceable derives every row, its coverage and its result from the trace links as they stand. Accurate between audits, not just before one.

Start freeGet the free template
Source documents on the left, one column per hop, then Coverage and Result. Both status columns are derived from the links, so neither can outlive the evidence behind it.

Configure the shape, not the contents

You choose what the rows start from and how far the chain should reach. Everything in the cells comes from the links.

Source documents

Nominate the documents whose Trace IDs become the rows: usually user needs, sometimes top-level requirements. Rename the column to whatever you call that level.

Hop columns

Add a column for each step of the chain, and point it at one or more documents. Reorder them, rename them, and the matrix rebuilds. Traversal runs in both directions, so a link written from either end counts.

Derived Coverage

Pass when the chain reaches the last hop, Gap otherwise. Never typed, so it cannot outlive the link behind it.

Derived Result

Rolled up from the test results in the chain: any fail makes the row Fail, otherwise any pass makes it Pass, otherwise Not run. On a failure, only the failing ids and their lineage are highlighted, not the whole row.

Orphans surfaced

An id nothing reaches is listed at the bottom with an empty Source. A test case no requirement points at is a coverage gap running the other way, and it will not surface on its own in a spreadsheet.

Saved views, and export

Save an arrangement by name for the whole project, filter to gaps only, choose which of a document’s columns show inside its chips, and, on Team and above, export the current view to CSV or PNG.

The same links, drawn as a V-model

The matrix answers “is this row covered”. The Document Map answers “how do these documents connect at all”, which is the question you actually have when a project is new or someone else built it.

Definition down the left arm, verification up the right, trace links across. A gap in the middle is a document nothing verifies.

A hand-built matrix is out of date the moment you save it

In a spreadsheet, the traceability matrix is a snapshot someone updates by hand, and the coverage column is an opinion typed in at the time. Every requirement change is a chance for the two to come apart, and they usually do. Traceable treats links as first-class data, so the matrix is a reading of the current links rather than a second document to keep in sync, and coverage is a conclusion rather than a claim. That is the difference between coverage you can trust and coverage you have to re-check.

It also means the matrix tells you things a spreadsheet cannot be asked. A link whose target has gone is flagged as broken rather than left looking ordinary. An id nothing reaches is listed rather than absent. And a failing result colours the branch of the chain it belongs to rather than the whole row, so you can see where the failure entered.

For regulated teams, this matters most at audit time. See how it applies to medical device development, how it compares with running requirements in Excel, or start from the free requirements traceability matrix template, which uses the same six columns.

Common questions

What is a requirements traceability matrix?

A requirements traceability matrix (RTM) maps each requirement to the items that trace to it: the higher-level need it satisfies, the design that implements it, and the tests that verify it. It shows coverage at a glance and highlights requirements that are missing a link.

What are the columns in Traceable’s matrix?

A Source column whose rows are the Trace IDs in the documents you nominate, then one column per hop you configure, each naming the documents that hop may step into, then two derived columns: Coverage and Result. You choose the source documents, add and rename the hops, and save the arrangement as a named view the whole project can open.

How is coverage decided?

A row is covered when the chain reaches the last hop, and a gap otherwise. Coverage is never typed in: it is read from the links as they stand, so a row cannot go on claiming coverage after the link behind it is gone. Traceable also lists ids that nothing reaches at the bottom of the matrix, with an empty Source, because a test case no requirement points at is a gap running the other way.

Where does the Result column come from?

It rolls up the test 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. On a failing row, only the ids carrying the failure and their lineage are highlighted, not the whole row, so you can see which branch of the chain broke.

How does Traceable keep the matrix up to date?

The matrix is generated from live, database-backed trace links rather than maintained by hand. When you add or change a link, the matrix reflects it, and a link whose target has gone is flagged as broken instead of leaving the row reading as covered.

Can I get a downloadable traceability matrix?

Yes. On Team and above, the matrix exports to CSV and PNG, and on every plan documents export to PDF and Markdown. The CSV carries the same columns you see on screen, so it matches the free spreadsheet template if you started there.

Build your traceability matrix on live links

Import your requirements and see coverage generated in minutes.

Start free