Requirements traceability matrix: a template, an example, and the part everyone skips
What an RTM is for, a copy-ready template, a filled example, and how to stop it going stale the week after the review.
Where this comes from
The template and example are ours. Their columns follow the links Entalpa stores between stakeholders, stories, requirements and tests; the forward, backward and bidirectional terms are the standard ones from requirements-engineering practice. We have not surveyed how long traceability matrices stay accurate in real projects; the staleness argument is from how the document is maintained, not from a measurement.
What a requirements traceability matrix is
A requirements traceability matrix (RTM) is a table with one row per requirement and a column for each thing that requirement connects to: the need it came from, the design or code that implements it, and the test that proves it. Read across a row and you know why a requirement exists and whether it is done. Read down a column and you find the gaps: a requirement with no test, a test with no requirement, a business need nothing implements.
It answers three questions that come up in every project with more than a handful of requirements: is everything we promised built and tested, what does this change touch, and why is this requirement here at all.
Forward, backward and bidirectional traceability
| Direction | Question it answers | Typical use |
|---|---|---|
| Forward | Is every requirement implemented and tested? | Release sign-off, coverage checks |
| Backward | Does every piece of work trace to a requirement? | Finding scope creep and gold-plating |
| Bidirectional | Both, in one table | Change impact: what breaks if this requirement changes |
Most teams need bidirectional traceability and write forward. Forward is the easy half: you start from the requirements list and fill in tests. Backward is the half that catches the work nobody asked for, which is also the half that matters most when an AI coding agent writes the code, because agents widen scope when nothing says where the edge is.
The template
Copy it into a spreadsheet or a markdown file. One row per requirement; a requirement that needs two tests gets both IDs in the test column, not two rows.
| Req ID | Requirement | Source (stakeholder / story) | Priority | Design / code | Test ID | Test status | Req status |
|--------|-------------|------------------------------|----------|---------------|---------|-------------|------------|
| REQ-001 | <one verifiable statement> | <who asked, or US-00x> | must | <module, PR or file> | TC-001 | pass / fail / not run | draft / reviewed / implemented / verified |- Req ID is the anchor. Without stable IDs the matrix cannot be kept in sync with anything.
- Source is the backward link. A requirement whose source column is empty is the first candidate for deletion.
- Test status and Req status are separate on purpose: a requirement can be implemented and still unverified.
A filled example: password reset
| Req ID | Requirement | Source | Priority | Test ID | Test status | Req status |
|---|---|---|---|---|---|---|
| REQ-001 | A reset link is valid for 60 minutes from sending | US-004 Forgotten password | must | TC-011 | pass | verified |
| REQ-002 | A reset link can be used once | US-004 Forgotten password | must | TC-012 | pass | verified |
| REQ-003 | Setting a new password signs out every other session | Security review | must | TC-013 | fail | implemented |
| REQ-004 | The reset form responds identically for known and unknown emails | Security review | must | — | not run | reviewed |
Two findings in four rows: REQ-003 is built but failing its test, and REQ-004 has no test at all. That is what the matrix is for.
The same feature is written up as a full PRD, with acceptance criteria for each requirement, in the PRD template.
Why most traceability matrices are stale
An RTM kept in a spreadsheet is a copy of facts that live somewhere else: the requirements in a document, the stories in a tracker, the tests in a test suite. Every edit to any of them has to be copied into the matrix by hand. Nobody does that on a Tuesday afternoon, so the matrix is accurate on the day of the review and drifts from then on.
the rule
A traceability matrix stays true only if it is generated from the links, not maintained beside them.
The second, quieter failure is a link that still exists but no longer means anything: the story was rewritten, and the requirement written from it now says something the story no longer asks for. A spreadsheet cannot notice that; the row still looks complete.
Keeping it current in Entalpa
Entalpa stores the links instead of a table of them: stakeholders link to stories, stories to requirements, and requirements to each other. Each requirement carries its ID, MoSCoW priority, acceptance criteria and a status from draft through reviewed, implemented and verified. When a story is edited after a requirement was written from it, the link is marked suspect, which is the stale-row problem caught at the moment it happens rather than at the next audit.
Requirements export as CSV, Markdown, JSON or ReqIF, so the matrix you hand to a reviewer is a fresh export rather than a spreadsheet someone remembered to update. Your coding agent reads the same requirements over MCP and can cite their IDs in commits and tests, which is what fills the code and test columns. Setup per client is on connect your agent.
Questions this raises
What is a requirements traceability matrix?
A table that links each requirement to its source (the stakeholder need or user story it came from) and to the design, code and tests that implement and verify it. It shows whether everything requested is built and tested, and what a change will affect.
What should a traceability matrix include?
At minimum: a stable requirement ID, the requirement statement, its source, its priority, the test that verifies it, the test result and the requirement's status. Add design or code references when change impact matters.
What is the difference between forward and backward traceability?
Forward traceability goes from requirements to tests and answers whether everything is implemented and verified. Backward traceability goes from work back to requirements and answers whether anything was built that nobody asked for. Bidirectional covers both.
Can I make a traceability matrix in Excel?
Yes, and for a small project it is fine. The cost is that every change to a requirement, story or test has to be copied into the sheet by hand, so it is usually out of date within weeks. Generating it from linked requirements avoids that.
Entalpa gives your agent one locked source of truth
Structured, traceable requirements your agent reads over MCP — so it works from a curated spec instead of reconstructing your project every session. Free to start, no card, and reading or writing your project over MCP never spends credits.
Other guides