How are requirement levels connected?

Auditor: Quick question. Auditor: Why does test case TC-207 exist? Team: Great question. Team: It's in the spreadsheet. Auditor: Which spreadsheet? Team: The final one. If that conversation feels familiar, this video is for you. In four minutes: what a requirements traceability matrix is, why the spreadsheet version breaks, and how to keep one that survives an audit. A requirements traceability matrix, or RTM, is a map. Each row connects a requirement to whatever proves it was handled: the design, the code, and the test. Requirement in, evidence out. For any requirement you can show where it went. And for any test, you can show where it came from. Forward traceability goes down the chain. Is every requirement implemented and tested? That's how you find gaps before a release. Backward traceability goes up. Why does this code, or this test, exist at all? That's the auditor's favourite question. Bidirectional means you can do both, from the same data. In regulated work, from medical devices to finance, that's usually what's expected. The spreadsheet version works on day one. Then three things happen. One. The requirement changes in the source document. The spreadsheet still says the old thing. Two. Someone adds a row on Friday afternoon. Nobody checks it. Now the matrix claims a link that nobody reviewed. Three. The auditor asks what was true on release day. The file has been edited forty times since. Auditor: So which version did you release with? Team: Define version. Here's the same idea inside Confluence, with Compliance Glossary. Every artifact becomes a trace node: a regulation, a requirement, a document, a piece of code, a test. Then you link them. The regulation derives the requirement. The code implements it. The test verifies the code. Each link carries an evidence reference, like a ticket or a page ID, and a reason. And nothing counts yet. A declared link stays a candidate until another administrator approves it. That's the review step the spreadsheet never had. Now trace. Forward impact shows everything downstream of a regulation. Reverse provenance starts from a test and walks back to the regulation behind it. Auditor: Okay. Auditor: Why does TC-207 exist? Team: It verifies the register export. Team: That implements the requirement to keep the DORA register of information current. Team: Here's the chain. Auditor: Can I keep this file? That's the result: one reviewed chain, one file, one answer. To be clear about the limits: the app doesn't certify compliance, it doesn't replace your test management tool, and it doesn't approve releases. It gives you reviewed, exportable links between the things you already have. If your requirements already live in Confluence, there's a free trial on the Atlassian Marketplace. The link is in the description. And tell me in the comments: where does your RTM break?