Traceability means you can follow any requirement back to the business need that caused it, and forward to the design decision and test case that implements it. Without this, changes become guesswork.
A traceability matrix is the most common tool: rows are requirements, columns are test cases, design artifacts, or business goals. When a requirement changes, you immediately see what else is affected.
Three practical reasons traceability matters:
Impact analysis. When a stakeholder requests a change, you should be able to say "here's what changes, here's what stays the same, here's the cost." Without traceability, you're estimating in the dark.
Coverage. Before release, you want to confirm that every requirement has been designed for and tested. A traceability matrix makes this checkable rather than assumed.
Compliance. In regulated environments — healthcare, finance, government — auditors need to see that requirements were implemented and verified. Traceability is the audit trail.
On the LPT project, I built traceability from business processes (BPMN) → functional requirements (Confluence) → specific Jira tickets. The traceability made a real difference during the first significant change request: instead of debating scope in the abstract, we could show the chain.
In agile delivery, you don't need a formal matrix. Story-level acceptance criteria, epic-to-story links, and automated test coverage serve the same function. The intent is identical.
Exam tip: Traceability is bidirectional — forward (requirement → test case) and backward (test case → requirement). Both directions matter. The exam may test whether you know why.