Practical guide and editable worksheet · Sources checked November 9, 2026
Requirements Traceability Matrix: Template and Example
A requirements traceability matrix is a table that links each requirement to its source and to the work and evidence used to verify it. Start with stable IDs, then record the source, requirement, delivery ticket, acceptance test, result, owner, and review date. Use the blank CSV below in Excel or Google Sheets, or inspect the completed software example before adapting it.
Start with the editable resources
CSV files work in Excel and Google Sheets. The example is fictional. Use the blank file for your own records and the Markdown worksheet for the reasoning behind them.
What the matrix must let you answer
A useful matrix answers two questions in either direction. Starting from a customer need, can the team find the requirement, the implementation work, and the verification evidence? Starting from a test or ticket, can someone explain which requirement and original need it serves? NASA's requirements-management guidance describes this bidirectional traceability. The lightweight worksheet here adapts that principle for product teams. It is an editorial example, not a NASA form or a certification record.
The matrix helps surface omissions. A requirement with no test has a verification gap. A ticket with no requirement may represent necessary technical work, a missing requirement, or accidental scope. Investigate the reason rather than deleting the ticket to make the spreadsheet look tidy. A row is a navigation aid. It becomes evidence only when its references resolve to actual reviewed records.
A worked example for an account-export feature
All IDs, organizations, results, and dates below are illustrative. Imagine a team building a CSV export of account activity. Product has three needs: users must obtain their own records, the export must respect workspace access, and larger exports must complete without freezing the browser. The feature is small enough to inspect row by row, but it contains a permission boundary and an unfinished test.
The completed download contains three rows. R-101 maps the export content to ticket ENG-41 and test AT-01. R-102 maps workspace authorization to ENG-42 and AT-02. R-103 maps background processing to ENG-43 and AT-03. The third row remains Not run. Although its implementation ticket may be complete, the matrix cannot claim that the requirement has passed verification.
The example keeps a requirement's wording separate from its test. “An authorized member can export account activity as CSV” is a product behavior. “A member requests an export and receives the expected header and records” is an observable check. Keeping both visible makes it easier to notice that a passing download test does not cover an unauthorized user's request.
| Requirement ID | Source ID | Requirement | Delivery ticket | Verification method | Test ID | Result | Evidence reference | Tested version | Owner | Review date |
|---|---|---|---|---|---|---|---|---|---|---|
| R-101 | NEED-01 | Authorized members can export their account activity as CSV | ENG-41 | Test | AT-01 | Passed | Example evidence EV-01 | Example build 0.8 | PM + QA | Illustrative review |
| R-102 | NEED-02 | Exports contain records only from the requester workspace | ENG-42 | Test | AT-02 | Passed | Example evidence EV-02 | Example build 0.8 | Security reviewer | Illustrative review |
| R-103 | NEED-03 | Large exports run as background jobs with a completion notice | ENG-43 | Test | AT-03 | Not run | — | Example build 0.8 | Engineering lead | Pending |
Build your first matrix
Choose one bounded feature and identify the version of its PRD or specification. Copy requirements into the worksheet with their existing IDs. If they have no IDs, assign stable ones before linking anything. Do not use row numbers as identifiers, because sorting the spreadsheet changes them. Keep the requirement statement testable and retain the source reference that explains why it exists.
Add the relevant delivery work and verification method. A test-case link, a design inspection record, or an analysis report may be appropriate, depending on the requirement. NASA's verification-matrix guidance distinguishes identified requirements and verification methods. Your team should choose the method that can demonstrate the stated behavior, rather than assuming every requirement can be checked with one automated test.
Enter the result separately from the status of the delivery ticket. Use a small, defined vocabulary such as Not run, Passed, Failed, and Blocked. Include a result reference and the build or version examined. A green cell saying Passed without a date, tested version, and retrievable evidence leaves the next reviewer unable to reproduce the conclusion.
Handle one-to-many relationships without hiding coverage
One requirement can depend on several tickets and tests. For a small worksheet, list the related IDs in each cell and explain the convention on a notes tab or in the accompanying Markdown. When the relationships become difficult to inspect, keep requirements in one table and requirement-to-test relationships in another. Preserve the unique requirement record and use its ID as the join key.
Do not duplicate a requirement's wording in several places and then edit only one copy. Also avoid collapsing three distinct requirements into one row merely because the same ticket implements them. The useful unit is an independently reviewable requirement. A higher-level need may be satisfied by several lower-level requirements, so coverage of the parent requires reviewing the set, not counting a single link.
Review gaps before a release
Filter for empty source, test, and evidence fields. Ask the requirement owner whether each gap is expected, blocked, or an actual omission. For example, an exploratory spike may have a source decision and an analysis outcome instead of a customer acceptance test. Record that distinction. An exception should have a rationale, an accountable reviewer, and a date to revisit it.
Then sample links in both directions. Open a requirement, follow its test evidence, and check that the expected behavior matches the requirement's current version. Open a delivered ticket and trace it back to the source. This review catches stale links that a spreadsheet completeness formula cannot detect. Three complete cells are not necessarily three correct relationships.
Update the matrix when a requirement changes
The table shows the proposed background-job behavior in example build 0.8. Suppose an earlier approved build 0.7 performed the same export synchronously. When R-103 is revised for background jobs, mark the earlier verification result as needing review, identify the new notification behavior, and assess whether additional requirements are needed. Keep the original decision and version reference available. Do not silently retain the old Passed result beside a materially different requirement.
Assign an owner for maintaining links during refinement, implementation, and release review. For a small team this can be the PM and engineering lead together. Review after approved scope changes and before release, with a cadence suited to the risk. A matrix copied once at project kickoff becomes misleading when the actual work changes underneath it.
Use the downloads
The blank CSV supplies headers. The example CSV contains the three illustrative export requirements, including a visible verification gap. Open CSV files in Excel using Data → From Text/CSV when automatic delimiter detection is wrong, or import them into Google Sheets. Save a working copy in your team's preferred format and keep the original downloaded example available for reference.
The accompanying Markdown explains the fields and review checklist. CSV stores plain rows and values. It does not preserve spreadsheet formulas, formatting, validation rules, or multiple tabs. If you need regulated traceability or formal approvals, check the controls your organization requires and select an appropriate system. This lightweight example demonstrates the reasoning and relationships without claiming compliance.
Sources and method
Primary guidance checked November 9, 2026. The worked scenario, field choices, examples, and review recommendations are editorial synthesis. The linked sources explain the underlying practices.