HKSM

A component of the project management plan that explains how requirements will be elicited, documented, prioritized, traced, verified, approved, and controlled through the project life cycle. It aligns stakeholders on consistent processes to prevent scope gaps and uncontrolled changes.

Key Points

• Defines the end-to-end approach for eliciting, documenting, prioritizing, tracing, verifying, and approving requirements.
• Establishes how requirement changes are proposed, evaluated, approved, and communicated.
• Tailors practices for predictive, agile, or hybrid life cycles, including how a backlog is managed if used.
• Specifies attributes and standards for requirement quality, including acceptance criteria and definitions of done.
• Describes the traceability model to link requirements to scope, design, tests, deliverables, and benefits.
• Identifies roles, tools, repositories, metrics, and reporting, and is version-controlled and approved.

Purpose

The plan provides a shared, repeatable way to handle requirements so the team builds the right product and controls scope changes. It reduces ambiguity, speeds decisions on priorities and changes, and supports validation and acceptance.

Typical Sections

• Objectives and scope of requirements management.
• Roles and responsibilities for product ownership, business analysis, and approvals.
• Stakeholder groups and sources of requirements.
• Elicitation and analysis methods and collaboration practices.
• Documentation standards and attributes (ID, description, rationale, priority, owner, status, acceptance criteria).
• Tools and repositories (e.g., backlog tool, RM database, document library).
• Traceability approach and matrix structure.
• Prioritization rules and decision methods (e.g., MoSCoW, value, risk, WSJF).
• Baselining criteria and change control workflow integrated with overall change control.
• Verification, validation, and acceptance process, including definitions of done and ready.
• Communication and reporting (reviews, dashboards, status cadence).
• Metrics and quality criteria (volatility, coverage, defects traced to requirements).
• Compliance, security, and regulatory considerations as applicable.
• Review, maintenance cadence, and version control.

How to Create

• Engage key stakeholders to agree on outcomes, decision rights, and approval authorities for requirements.
• Select elicitation and analysis techniques suitable for the domain and life cycle (workshops, interviews, prototypes, user stories).
• Define required attributes and quality criteria for a complete, testable requirement.
• Design the traceability model and the structure of the traceability matrix or tooling links.
• Choose prioritization methods and tie them to release or iteration planning rules.
• Specify baselining points and the change control process, integrated with project-wide change procedures.
• Plan verification, validation, and acceptance steps and who signs off at each stage.
• Select tools and repositories, access controls, and naming/versioning conventions.
• Document reporting cadence, metrics, and review meetings; tailor for predictive, agile, or hybrid approaches.
• Circulate the draft, incorporate feedback, and obtain formal approval and version control.

How to Use

• Apply the documented standards when capturing and refining requirements or user stories.
• Maintain traceability from requirements to scope, design, tests, and deliverables to ensure coverage.
• Use the prioritization and release planning rules to sequence work and manage stakeholder expectations.
• Enforce the defined change workflow for additions, removals, or edits to requirements.
• Report requirement status, volatility, and coverage using the agreed metrics and dashboards.
• Guide verification, validation, and acceptance so completed work meets agreed criteria.

Maintenance Cadence

• Review at major milestones or phase gates to confirm fit-for-purpose and update as needed.
• In agile or hybrid, confirm alignment during inception and revisit at least once per release or quarterly.
• Update promptly after significant scope or governance changes that affect requirements handling.
• Audit traceability and compliance periodically; record revisions with version and approval history.

Example

Excerpt from a requirements management plan for a hybrid project:

• Roles: Product owner prioritizes; business analyst maintains backlog and traceability; change control board approves baselined changes.
• Elicitation: Workshops and prototypes; user stories captured in the backlog with acceptance criteria.
• Attributes: ID, description, business value, priority, risk, status, owner, acceptance criteria, links to tests.
• Traceability: Each requirement links to design items, build tasks, and test cases; coverage reported weekly.
• Prioritization: MoSCoW with value and risk; releases set by capacity and dependency rules.
• Change control: Baselined epics require CCB approval; non-baselined items follow product owner workflow.
• Verification and validation: Definition of ready and done; demos each iteration; formal acceptance at release.
• Cadence: Backlog refinement weekly; plan reviewed at each release and at phase gates.

PMP Example Question

A stakeholder requests adding a new high-priority requirement after the scope baseline is approved. What should the project manager do first?

1. Add the requirement to the backlog to keep the stakeholder satisfied.
2. Reject the request because the scope baseline is already approved.
3. Consult the requirements management plan to follow the defined change control process.
4. Ask the team to estimate effort, then decide whether to proceed.

Correct Answer: C — Consult the requirements management plan to follow the defined change control process.

Explanation: The plan defines how requirement changes are evaluated and approved. Follow the documented workflow before estimating or implementing changes.