HKSM

A structured record of all project and product requirements, including attributes such as source, priority, and acceptance criteria. It enables analysis, agreement, traceability, and validation across the life cycle.

Definition

A structured record of all project and product requirements, including attributes such as source, priority, and acceptance criteria. It enables analysis, agreement, traceability, and validation across the life cycle.

Key Points

• Captures business, stakeholder, solution, transition, quality, and project requirements in one place.
• Each requirement includes attributes like unique ID, description, rationale, acceptance criteria, priority, owner, and status.
• Clarity is critical: requirements should be unambiguous, testable, feasible, and necessary.
• Acts as the basis for scope definition, design decisions, estimation, and test planning.
• Versioned and baselined; changes are controlled through an agreed change process.
• Format can vary: document, spreadsheet, user stories with acceptance criteria, or a repository.

Purpose of Analysis

• Transform raw stakeholder needs into clear, testable, and prioritized requirements.
• Resolve conflicts, eliminate ambiguity, and align requirements to objectives and value outcomes.
• Identify constraints and nonfunctional criteria that affect design and delivery.
• Prepare requirements for validation, estimation, and traceability.

Method Steps

• Plan structure: define the template, attributes, and storage tool for requirements.
• Consolidate inputs: gather elicitation notes, models, and existing policies or standards.
• Analyze and refine: decompose, clarify wording, add acceptance criteria, and remove duplicates.
• Prioritize and categorize: group by type, map to objectives, and apply priority or MoSCoW levels.
• Review with stakeholders: verify understanding, negotiate trade-offs, and record agreements.
• Baseline and control: assign versions, set approval status, and apply change control.
• Maintain and trace: link requirements to objectives, scope, deliverables, tests, and defects.

Inputs Needed

• Business case and project charter for goals, constraints, and success measures.
• Stakeholder register and roles for sources, owners, and approvers.
• Elicitation outputs such as interview notes, workshop results, and observations.
• Policies, standards, regulatory requirements, and contractual obligations.
• Existing product documentation, process maps, and data models if applicable.

Outputs Produced

• Requirements documentation with complete attributes, acceptance criteria, and status.
• Prioritized requirement set aligned to objectives and constraints.
• Links or references for traceability to scope elements, designs, tests, and releases.
• Updates to backlog items or user stories ready for planning and estimation.
• Assumptions and constraints updates derived from clarified requirements.

Interpretation Tips

• Read each requirement as an atomic, testable statement that delivers value and is feasible.
• Check attributes: clear rationale, source, and priority help with trade-off decisions.
• Confirm acceptance criteria are objective, measurable, and verifiable.
• Ensure traceability forward to deliverables and tests, and backward to objectives.
• Use version and status fields to understand what is proposed, approved, or changed.

Example

A team documents a requirement as:

• ID: R-014; Type: Quality; Priority: High; Source: Operations; Owner: Product Manager.
• Description: The solution shall process submitted requests within 2 seconds under normal load.
• Rationale: Reduce user wait time to improve satisfaction and throughput.
• Acceptance Criteria: 95% of 1,000 test requests complete in 2 seconds or less in staging.
• Trace Links: Objective OBJ-2, Design Spec DS-3, Performance Test PT-7.

Pitfalls

• Ambiguous wording that allows multiple interpretations.
• Missing acceptance criteria, making validation subjective.
• Over-specifying design choices instead of stating needs and constraints.
• Neglecting nonfunctional requirements like security, performance, or usability.
• Inadequate stakeholder review leading to late rework and change churn.
• Poor version control and traceability that obscure impacts of change.

PMP Example Question

During planning, stakeholders disagree about whether a proposed feature meets the agreed need. What should the project manager review first to resolve the disagreement?

1. Stakeholder engagement plan.
2. Requirements documentation.
3. Risk register.
4. Communications management plan.

Correct Answer: B — Requirements documentation

Explanation: It contains the approved, detailed requirements and acceptance criteria used to assess alignment and verify completeness. Reviewing it clarifies intent and provides a basis for decision making.