Requirements Traceability: A Field Checklist You Can Use This Week

Requirements traceability is the ability to trace each requirement from its origin (business need, stakeholder request, regulatory obligation) through design decisions, implementation choices, and testing activities, to confirm that it has been correctly addressed in the delivered system or product. In capital and technology projects, poor requirements traceability is a major contributor to scope creep, testing gaps, and acceptance disputes. A requirements traceability matrix (RTM) is the primary tool for managing traceability.

Checklist Part 1: Setting Up Traceability

1. Number every requirement uniquely. Requirements that are not uniquely numbered cannot be traced. Assign a unique identifier to every requirement before the RTM is built. A simple numbering scheme (REQ-001, REQ-002) is better than a meaningful but complex scheme that creates administration overhead.

2. Categorise requirements by type. Distinguish between functional requirements (what the system or product must do), non-functional requirements (how well it must do it -- performance, reliability, security), and regulatory or compliance requirements. Different requirement types may have different traceability obligations.

3. Record the source of each requirement. For every requirement, record where it came from -- which stakeholder requested it, which regulatory document mandates it, or which business process it enables. Requirements without a documented source are often gold-plating (added by the team without a genuine business need) that can be safely descoped if pressure requires.

Checklist Part 2: Maintaining Traceability Through Design and Build

1. Link each requirement to the design element that addresses it. For each requirement, record which design element (architectural component, module, interface, database table) is responsible for addressing it. If a requirement is not linked to any design element, it has not been designed for -- which means it has not been built.

2. Link each design element to its test cases. For each design element, record which test cases will verify that it has been implemented correctly. If a design element has no test cases, there is no way to know whether it works.

3. Update the RTM when requirements change. Requirements changes must be traced through the RTM: which design elements are affected? Which test cases need to be updated or added? Untraced requirements changes are a common cause of testing gaps and regression errors.

Checklist Part 3: Using the RTM in Reviews and Acceptance

• At each design review, use the RTM to confirm that every requirement has at least one design element assigned. Requirements with no design coverage are risks that should be escalated.

• At the start of testing, use the RTM to confirm that every requirement has at least one test case. If coverage gaps exist, write the missing test cases before testing begins -- not after.

• At acceptance, use the RTM to produce a traceability coverage report: what percentage of requirements have been tested, and what percentage of tests passed. Acceptance should not be granted until all mandatory requirements have passing test results.

XNM provides project management and requirements management advisory to public-sector and capital-project clients. Reach out to XNM's program & project delivery advisory team to discuss requirements traceability and scope management for your project.