A requirements traceability matrix example for a payments change
A requirements traceability matrix (RTM) is a table that links each requirement to where it came from and to what proves it was delivered. People often build one because a governance process asks for it, then abandon it after sign-off. Used properly it does a more useful job: it shows you, while the project is still running, which requirements have no test, which tests have no requirement, and which requests nobody ever approved.
Here is a worked example. The firm and the change are fictional.
Last reviewed: October 2026.
The scenario
Northgate Bank lets business customers make payments through its online banking service. Today a customer can pay a new payee immediately. Following an internal fraud review, the product owner wants a warning screen the first time a customer pays someone they have not paid before, with a hold of up to 30 minutes on amounts above £10,000.
You are the business analyst. By the end of discovery you have a handful of requirements, a design document, a set of test cases and a change request. The RTM is where those things meet.
The matrix
| Req ID | Requirement | Source | Owner | Design ref | Test IDs | Status |
|---|---|---|---|---|---|---|
| REQ-01 | Show a warning screen before the first payment to a new payee | SRC-01 Fraud review minutes, action 4 | Product owner | FS-3.1 | TC-01, TC-02 | Approved |
| REQ-02 | Customer can confirm and continue from the warning screen | SRC-01 action 4 | Product owner | FS-3.2 | TC-03 | Approved |
| REQ-03 | Hold payments above £10,000 to a new payee for up to 30 minutes | SRC-02 Email, Head of Fraud, 6 Oct | Head of Fraud | FS-4.1 | TC-04, TC-05, TC-06 | Approved |
| REQ-04 | Notify the customer by text message when a payment is held | SRC-02 | Head of Fraud | FS-4.3 | TC-07 | Open: wording not agreed |
| REQ-05 | Record every warning shown, with the customer's response | SRC-03 Audit workshop, 8 Oct | Compliance | FS-5.1 | None yet | Approved |
| REQ-06 | Let a branch manager release a held payment | SRC-04 Ops call, 9 Oct | Operations lead | Not designed | None yet | Proposed |
Starter, £30 (41 files, discovery to a tested set of requirements) · Complete, £80 (59 files, adds governance and assurance). Prices include UK VAT: Starter £25 + VAT, Complete £66.67 + VAT. Payhip may show the price before VAT. One payment, no subscription.
Sold by Quantum Sphere Consulting Limited; your statutory rights apply.Reading it column by column
Requirement ID and wording. One behaviour per row. REQ-03 says "up to 30 minutes", which is testable. If it said "briefly", you could not write a test for it, and the matrix would not rescue you.
Source. This is the column most teams skip and the one that earns its place later. A source reference means that when someone says "who asked for the hold?", you can point to an email on a date, from a named role. Notice that REQ-03 and REQ-04 come from an email, not from the fraud review minutes. If the minutes are the only document the steering group saw, you now know the hold has less visible backing than the warning screen.
Owner. The person with authority to confirm the requirement, not the person who mentioned it. Operations raised REQ-06, but nobody has said who can approve a release process for held payments. Leave the owner blank rather than guessing.
Design reference. Points to the section of the functional specification that deals with it. REQ-06 shows "Not designed". That is useful information, not a failure.
Test IDs. Forward traceability, from requirement to proof. REQ-05 has no test yet. If you were preparing for a test readiness review, that cell is the first thing you would raise.
Status. Keep this honest. REQ-04 has a source and a design but the wording is still being argued over, so it is open.
Three checks the matrix makes easy
1. Forward gaps. Filter on Test IDs equal to "None". Here that gives REQ-05 and REQ-06. REQ-05 is approved but untested: a real gap. REQ-06 is only proposed, so the missing test is expected.
2. Backward gaps. Take your test case list and look for tests that point at no requirement. Suppose TC-09 checks that the warning screen works on a tablet. Nothing in the matrix mentions tablets. Either a requirement is missing or the test is outside scope. Both are worth a conversation.
3. Scope creep. Sort by status. REQ-06 arrived in a call, was never approved, and has already started attracting design effort. The matrix cannot stop that on its own, but it makes the drift visible to anyone who looks.
Keeping it alive
Three habits make an RTM useful rather than decorative.
First, update it when something changes, not at the end. A matrix built the week before sign-off documents what you remember, not what happened.
Second, link to the live documents. A source column that says "meeting" tells the reader nothing. One that says "SRC-02, email from Head of Fraud, 6 Oct" can be checked.
Third, keep it small enough to read. If your RTM has 400 rows and nobody opens it, split it by workstream or by release. A matrix that is read in a weekly meeting is worth ten that are complete.
When a change arrives
Change is where the matrix pays back. Suppose the Head of Fraud emails to say the hold should be 60 minutes, not 30. In the matrix you update REQ-03, and the row tells you straight away that the change touches FS-4.1 and tests TC-04 to TC-06. You can put those three tests and one design section into the change request as the impact. Without the matrix you would be searching documents for the number 30.
You also record the change as a new source, say SRC-05, so the history of how the requirement moved is there if anyone asks.
What to avoid
Do not use the matrix to prove you did your job. Its purpose is to show the team where the holes are while they can still be filled. A matrix with every cell filled and none of the content challenged is just a longer way of saying "done".
Do not add columns because a template had them. Each one needs somebody who reads it and acts on it.
And do not treat a spoken request as an approved requirement. Record it, put the speaker in the source column, and mark it proposed until the right person confirms it.
Download the filled matrix
This matrix is available as a working Excel file, with the forward-gap, orphan-test and scope checks built in, plus a Decisions sheet and the change log. In the download the hold has already moved from 30 to 60 minutes (change CH-01), so you can see how the matrix records it: download the filled traceability matrix.
Try it
Pick one change you are working on now and build a six-row version like the one above. Include the source column and the "None" check. Most analysts find at least one requirement with no test, or one test with no requirement, within the first ten minutes.
The Starter toolkit includes a Traceability Matrix template, the structure behind this example.