HKSM

Requirements traceability is a technique that links each requirement to its source and to downstream artifacts such as design elements, deliverables, and test cases, enabling end-to-end visibility. It supports change impact analysis, coverage verification, and confirmation that outputs align with intended needs.

Key Points

• Creates bidirectional links from each requirement back to its origin and forward to design, build, and validation artifacts.
• Commonly implemented using a requirements traceability matrix (RTM) maintained throughout the life cycle.
• Enables impact analysis when requirements change and helps control scope creep.
• Confirms coverage by ensuring every requirement is designed, built, and tested, and that no work is done without an approved requirement.
• Supports compliance, audits, and stakeholder assurance by showing clear lineage from needs to delivered outcomes.
• Works with both functional and nonfunctional requirements and supports one-to-many and many-to-one relationships.

Purpose of Analysis

Requirements traceability ensures that project work remains aligned with stakeholder needs and business objectives. It provides a transparent chain from the source need to the delivered result and its verification.

By mapping these links, teams can evaluate the effect of changes, avoid unnecessary work, and verify that acceptance criteria and tests adequately cover the approved requirements.

Method Steps

• Define identifiers and attributes for requirements (e.g., ID, source, priority, status, acceptance criteria).
• Select link types and granularity (e.g., requirement to objective, WBS, design, user story, test case).
• Load approved requirements and sources, then establish backward links to business needs and stakeholders.
• Create forward links to scope elements, design or user stories, implementation items, and test cases.
• Validate completeness and quality of links through peer review and stakeholder confirmation.
• Maintain the RTM as work progresses, updating for changes via the change control process.
• Report coverage and gaps, and use the RTM during reviews, testing, and acceptance.

Inputs Needed

• Business goals, benefits, and success criteria.
• Approved requirements backlog or register with acceptance criteria.
• Stakeholder register and source documentation (requests, regulations, contracts).
• Scope baseline and WBS or product breakdown structure.
• Design artifacts, user stories or epics, and implementation plan.
• Test plan and test cases, verification and validation approach.
• Change requests and decision records from change control.

Outputs Produced

• Requirements Traceability Matrix with bidirectional links and status.
• Coverage and gap reports highlighting untraced or orphan items.
• Change impact notes indicating affected requirements, work packages, and tests.
• Updates to backlog or scope baseline and related configuration items.
• Metrics such as coverage percentage, volatility, and defect tracebacks.

Interpretation Tips

• Every requirement should trace backward to a valid source and forward to at least one test; missing links indicate gaps.
• One-to-many mappings are normal; focus on completeness and clarity rather than forcing one-to-one links.
• Orphan tests or designs without an approved requirement signal potential scope creep.
• Use the RTM during change impact analysis to identify all affected components and stakeholders.
• Keep the level of detail appropriate to project complexity; too much granularity can reduce usability.

Example

Requirement R-05 originates from a regulatory need and maps to Objective O-2. It links to WBS 2.1, User Stories US-12 and US-13, Design Spec DS-7, and Test Cases TC-21 and TC-22. When a change request proposes updating R-05, the RTM quickly shows which work packages, designs, and tests must be updated and which stakeholders to involve.

Pitfalls

• Over-detailing links at a task level, making the RTM cumbersome to maintain.
• Missing backward trace to business value or source, weakening justification.
• Failing to update links after changes, leading to inaccurate impact analysis.
• Conflating requirements with solutions or tasks, reducing clarity.
• Ignoring nonfunctional or compliance requirements in the RTM.
• Relying solely on a tool without clear governance and review practices.

PMP Example Question

During system testing, the team finds several test cases that are not linked to any approved requirement. What should the project manager do first?

1. Create new requirements to match the test cases and update the scope baseline.
2. Update the requirements traceability matrix and investigate whether the tests reflect approved requirements or unauthorized scope.
3. Proceed with testing because additional tests increase quality.
4. Ask the sponsor to approve the tests retroactively.

Correct Answer: B - Update the RTM and investigate the mismatch.

Explanation: Traceability requires every test to map to an approved requirement. Orphan tests indicate possible scope creep; validate links and use change control before altering scope or adding requirements.