HKSM

Requirements management is the documented approach and set of artifacts used to capture, analyze, prioritize, trace, and control requirements. As an input to Identify Risks, it supplies the requirements set, change history, and governance rules that reveal gaps, conflicts, and volatility. It matters because requirement issues are a common source of project threats and opportunities.

Key Points

• Type: Input document and repository used across planning and delivery.
• Contents typically include the requirements list or backlog, attributes and acceptance criteria, traceability matrix, status, priorities, versions, and change history.
• Also captures the rules for how requirements are elicited, analyzed, approved, baselined, changed, and verified.
• Built collaboratively with stakeholders and maintained continuously by the delivery team.
• Directly supports risk identification by highlighting ambiguity, dependencies, compliance items, and areas of high change.
• May appear as a formal plan plus supporting artifacts in predictive projects, or as a product backlog and working agreements in adaptive projects.

Purpose

Provide a reliable, traceable source of truth about what is needed and how changes are controlled so the team can spot requirement-related risks early.

• Expose unclear, conflicting, incomplete, or unverifiable requirements.
• Reveal dependencies and constraints that can trigger delivery risks.
• Surface regulatory, safety, and quality requirements with high impact if missed.
• Show volatility and churn patterns that increase uncertainty.

How to Create

• Define roles and governance: who elicits, approves, prioritizes, and accepts requirements; escalation paths; and decision rights.
• Set standards: requirement types, attributes, acceptance criteria format, definition of ready/done, and quality checks.
• Establish traceability: link requirements to business objectives, scope items, designs, tests, and releases; decide on a traceability matrix or tool configuration.
• Plan change control: intake channels, impact analysis steps, approval thresholds, versioning rules, and audit trail needs.
• Select tools and repositories: RM software, backlog tool, document templates, and naming/versioning conventions.
• Seed the repository: capture initial requirements, classify and prioritize, assign owners, and baseline or timebox as appropriate.

How to Use

• Scan the requirements set for ambiguity, conflicting statements, missing acceptance criteria, or unverifiable conditions, and log related risks.
• Review the traceability matrix to identify high-risk dependencies, orphan requirements, and areas not covered by tests.
• Analyze change history and volatility trends to flag instability that could impact scope, schedule, or budget.
• Check regulatory and nonfunctional requirements for complexity and compliance risk, and note required controls or audits.
• Use priorities and status to focus risk workshops on high-value or near-term items.
• Convert recurring issues into risk triggers and link them to contingency or response plans.

Ownership & Update Cadence

Primary ownership typically sits with a business analyst or product owner, with governance by the project manager and key stakeholders.

• Update continuously as new requirements emerge, are refined, or change is approved.
• Review at each planning cycle, backlog refinement, or phase gate to reassess risks.
• Synchronize updates with configuration management and change control decisions.
• Audit traceability and acceptance coverage before major milestones or releases.

Example

A healthcare project maintains a requirements backlog with acceptance criteria and a traceability matrix linking each requirement to HIPAA controls and test cases. During Identify Risks, the team notices several requirements with vague encryption standards and a spike in change requests. They record risks for data privacy noncompliance and schedule delays, define triggers such as rejected security tests, and plan mitigations including security architecture reviews and early compliance testing.

PMP Example Question

While identifying risks, the team reviews the requirements repository and sees frequent changes to nonfunctional performance requirements. What should the project manager do next?

1. Stop all changes until the design is finalized.
2. Record a risk related to requirements volatility and analyze its impact and triggers.
3. Increase the budget contingency by a fixed percentage.
4. Remove the unstable requirements from scope.

Correct Answer: B — Record a risk related to requirements volatility and analyze its impact and triggers.

Explanation: Volatility in the requirements management artifacts is a clear risk signal. The appropriate next step is to capture and assess the risk so responses can be planned; freezing scope or removing requirements prematurely is not justified.