Background:
Requirement tracing (traceability) emerged as a tool to prevent discrepancies between business expectations and the actual implementation of the system. Initially, analysts relied on manual checks and lists, which were extremely inefficient.
Problem:
In the absence of tracing, the connection between requirements at various levels is lost: business goals → functional requirements → technical requirements → test scenarios. This leads to errors, "lost" requirements, and poor implementation.
Solution:
Requirement tracing is structured as a chain of correspondences using matrices, specialized tools (Jama, DOORS, Jira/Zephyr), and templates:
A traceability matrix is created, where the simplest structure is —
| Business Goal | Functional Requirement | Test Scenario |
|---|---|---|
| BG-1 | FR-1 | TC-1 |
Artifacts are tagged in the tools.
Each time any level changes, the chain is reviewed — there must be a connection.
It is important to conduct regular audits to identify “dangling” requirements or tests that are not linked to goals.
Key Features:
Can you do without a traceability matrix on a small project?
No, even on small projects, the absence of tracing often leads to lost requirements.
Is it enough to build traceability once at the beginning of the project?
No, the matrix requires regular updates as requirements and tests change.
Does traceability only affect the completion of testing?
No, it is important at all stages — from design to maintenance, helping to assess the impact of changes and plan work.
Negative Case:
In a project, a traceability matrix was not constructed, and testers relied solely on the specification. Several requirements were implemented but not tested, resulting in features in production not working as needed.
Pros:
Cons:
Positive Case:
In another project, a live traceability matrix was maintained. All requirements were linked to tests and business goals, and any changes were tracked. There were no unaccounted features or "unwritten" tests.
Pros:
Cons: