Before you close
Requirements Traceability Checker
Check that every requirement has a test that passed, every test traces to something that was asked for, and nothing changed after it was signed off as working.
Open the requirements and, if they are kept separately, the tests: IDs, priorities, results and dates, with the links on either side or as a matrix with an X where a requirement meets a test. Read inside your browser; nothing is uploaded.
Requirements
Drop a spreadsheet here
One row per requirement: an ID and the text, with priority, status and the date it last changed if you keep them. A column of test IDs, or a column per test with an X, works as the links.
Tests (optional)
Drop a spreadsheet here
One row per test or per run: a test ID, the requirement IDs it covers, its result and when it last ran. Leave it out if the requirements file already has the links.
The questions a traceability matrix is for
Before go-live, someone asks whether everything that was asked for has been tested and works. The traceability matrix is meant to answer that, but it is a spreadsheet kept by hand while the requirements and tests keep changing. A requirement added late has no test. A test is traced to the wrong ID. The wording of a requirement changes after its test went green, and the green stays green.
What is checked
Requirements with no test, most important first. Tests that trace to nothing, and tests traced to an ID that is not in the requirements list, with the ID it was probably meant to be when one is an obvious slip. Coverage by priority: how many have a test, and how many are verified, meaning every test passed on its latest run. Failing, blocked and unrun tests. Requirements changed after their tests last passed. Withdrawn requirements that still have tests, and tests traced to so many requirements that they prove none of them well.
Any layout
Links written as test IDs on each requirement, as requirement IDs on each test, or as a matrix with a column per test are all read and merged. A test list with a row per run uses each test’s latest run, so an old failure does not outlive the pass that fixed it. MoSCoW priorities and High, Medium and Low are both understood.
What this does not do
It checks the links and results you have, not whether a test really proves its requirement; that takes someone reading both. It does not decide whether the release is ready: the gaps it lists are evidence for the go/no-go, not the decision. And it reads dates to judge what changed after a pass, so without a last-changed date on the requirements that check is skipped.