HKSM

A requirements traceability matrix is a living table that links each requirement to its source and to related artifacts such as design elements, test cases, and deliverables. It helps ensure complete coverage, supports impact analysis, and provides transparency throughout the project.

Key Points

• Shows bidirectional links from stakeholder needs to requirements, deliverables, tests, and acceptance results.
• Enables impact analysis for change requests by revealing affected scope, schedule, cost, and quality items.
• Supports verification and validation by mapping each requirement to test cases and acceptance criteria.
• Works for predictive, agile, or hybrid approaches and can be a spreadsheet or a tool-based artifact.
• Should be maintained as a living document with clear ownership and version control.
• Improves compliance and audit readiness by demonstrating coverage and traceable decisions.

Purpose

• Ensure every approved requirement is implemented, tested, and accepted.
• Prevent scope gaps and gold plating by controlling what is linked and approved.
• Provide a quick view of status and readiness for release or handover.
• Facilitate communication among business, technical, QA, and audit stakeholders.
• Support change control by clarifying the ripple effects of proposed changes.

Field Definitions

• ID: Unique identifier for the requirement.
• Requirement Statement: Clear, testable wording of the need.
• Source/Origin: Stakeholder, document, contract clause, or user story reference.
• Priority/Value: Relative importance or MoSCoW ranking.
• Category/Type: Business, functional, non-functional, regulatory, or interface.
• Acceptance Criteria: Conditions that must be met for acceptance.
• Status: Proposed, approved, in progress, verified, accepted, deferred, or rejected.
• Owner: Person accountable for the requirement throughout its life.
• Related Deliverable/WBS: Product, component, or work package implementing it.
• Design/Backlog Reference: Design element, architecture item, or backlog link.
• Test Case IDs: Specific tests that validate the requirement.
• Verification Method: Test, inspection, analysis, or demonstration.
• Dependencies/Interfaces: Other requirements or systems it relies on.
• Version/Change History: Summary of changes and approval dates.
• Comments/Notes: Clarifications, risks, or decisions.

How to Create

• Collect and approve baseline requirements from the charter, business case, elicitation sessions, and backlog items.
• Define the columns you need based on project context, compliance needs, and toolset.
• Assign unique IDs and write clear, measurable requirement statements.
• Map each requirement to its source and intended deliverables or work packages.
• Link verification elements such as acceptance criteria and test cases.
• Set ownership, status values, and version control practices for the matrix.
• Store the matrix in a shared location or tool with appropriate access controls.

How to Use

• Review the matrix during planning to confirm coverage and detect gaps or overlaps.
• Use it in change control to identify all impacted deliverables, tests, and stakeholders.
• Track status from implementation through verification and final acceptance.
• Report progress by summarizing counts of approved, in progress, verified, and accepted requirements.
• Align testing scope and readiness by confirming each requirement has mapped test cases and results.
• Support audits by showing trace from source to implementation and evidence of verification.

Ownership & Update Cadence

• Primary Owner: Business analyst or product owner; project manager oversees usage and integration with plans.
• Contributors: QA/test lead, solution architect, developers, functional leads, and change control board.
• Update Triggers: Requirement approvals, design changes, test creation/results, and change request outcomes.
• Cadence: Update continuously; review at least each iteration or at key phase gates.
• Governance: Maintain version history and align with configuration and change management procedures.

Example Rows

Row 1: ID: REQ-012; Statement: System shall encrypt data at rest; Source: Security policy; Priority: Must; Category: Non-functional; Deliverable: Database config; Test Cases: TC-45, TC-46; Verification: Test; Status: Verified; Owner: Security lead.

Row 2: ID: REQ-027; Statement: Generate monthly usage report; Source: Operations; Priority: Should; Category: Functional; Deliverable: Reporting module; Test Cases: TC-78; Verification: Demonstration; Status: In progress; Owner: Reporting BA.

PMP Example Question

During review of a change request to add a new reporting field, the team needs to quickly identify all affected deliverables and test cases. What should the project manager do first?

1. Ask each functional lead to estimate the impact based on their experience.
2. Review the schedule network diagram to find activities that might be affected.
3. Consult the requirements traceability matrix to locate linked deliverables and tests.
4. Create a new work breakdown structure focused on the change request.

Correct Answer: C — Consult the requirements traceability matrix to locate linked deliverables and tests.

Explanation: The RTM provides bidirectional links needed for rapid impact analysis. It identifies related work products and tests before estimating or replanning.