I spent a chunk of my career wiring automation into banks, which means I have built more traceability matrices by hand than I would like to admit. The job always looked the same. An audit is six weeks out, someone asks for proof that every requirement was tested, and a person, usually me, starts screenshotting tickets from Jira, exporting test runs from a separate QA tool, and stitching the two together in a spreadsheet that is already wrong by the time it finishes printing.
Here is the opinion it took me too long to say out loud. In regulated software, the traceability matrix is the deliverable, not a report you generate under duress. If you are rebuilding it from screenshots the week before the auditor arrives, you do not have traceability. You have a fire drill that produces a document shaped like traceability.
The matrix is real. The way most teams build it is broken.
A traceability matrix is a simple idea. Every requirement maps to the design that satisfies it, the test that verifies it, and the defect history that shows the test actually means something. Auditors in finance, medical devices, and aerospace ask for it because it answers one blunt question: can you show that what you said you would build is the thing you actually tested and shipped?
