5.3 Collect Requirements
Systematically eliciting, analyzing, and documenting stakeholder needs and acceptance criteria to define what the product and project must deliver.
Purpose & When to Use
Collect Requirements defines what success looks like by capturing stakeholder needs and translating them into clear, testable requirements and acceptance criteria. It prevents scope gaps, reduces rework, and aligns the team around measurable outcomes.
Use this process early in planning after the project is authorized and stakeholders are identified. Revisit it at phase gates, during backlog refinement, and whenever significant changes or new information appear. The outputs guide scope definition and WBS creation and inform testing and validation.
Mini Flow (How It’s Done)
- Prepare the approach: review the charter, business case, constraints, and policies; select elicitation methods and success measures.
- Identify and engage the right stakeholders, including end users, regulators, support, and operations.
- Elicit requirements using interviews, workshops, brainstorming, surveys, observation, document analysis, prototypes, use cases, or story mapping.
- Capture and structure requirements with unique IDs, source, rationale, priority, and draft acceptance criteria.
- Analyze and refine: remove duplicates, clarify ambiguous statements, model processes and data, and resolve conflicts with facilitation.
- Prioritize by value and risk using MoSCoW, value scoring, Kano analysis, or voting techniques.
- Define measurable acceptance criteria and quality attributes for each requirement.
- Build a traceability matrix linking requirements to business objectives, WBS items or backlog items, design elements, test cases, and owners.
- Validate with stakeholders through reviews or walk-throughs and obtain agreement.
- Baseline the approved set and manage changes through the change control process or backlog refinement cadence.
Quality & Acceptance Checklist
- Each requirement is clear, concise, feasible, and testable; no vague terms like “fast” or “user-friendly” without measures.
- Acceptance criteria are specific, measurable, and tied to each requirement.
- Every requirement shows ID, source, owner, priority, and rationale.
- Non-functional qualities (performance, security, usability, reliability, maintainability) are included.
- Interfaces, data needs, and reporting requirements are captured.
- Regulatory, legal, and policy constraints are addressed.
- Assumptions, dependencies, and constraints are documented.
- Conflicts and trade-offs are resolved and decisions recorded.
- End-to-end traceability is established from objectives to requirements to test cases.
- Impacts to scope, schedule, cost, quality, and risk are assessed and communicated.
- Prototypes or mockups were reviewed and feedback integrated.
- Formal approval or agreed acknowledgment from key stakeholders is recorded.
Common Mistakes & Exam Traps
- Jumping to design or solutions instead of first clarifying needs.
- Relying on one vocal stakeholder and missing end-user input.
- Writing ambiguous, non-testable statements.
- Ignoring non-functional and regulatory requirements.
- Failing to prioritize; treating all requirements as “must-have.”
- Skipping traceability, leading to missed tests and uncontrolled scope growth.
- Handling requirement conflicts by rank or politics instead of facilitated analysis and value-based decisions.
- Letting requirements change without formal change control or backlog discipline.
- Assuming a prototype equals an agreed requirement without documented acceptance criteria.
- Collecting requirements once and never revisiting them as risks and insights emerge.
PMP Example Question
During a requirements workshop, two major stakeholders propose conflicting capabilities with tight deadlines. What should the project manager do next?
- Escalate the conflict to the sponsor for an immediate decision.
- Facilitate the group to clarify needs, evaluate options, and agree on value-based prioritization criteria.
- Accept the requirement from the more senior stakeholder to avoid delay.
- Defer both requirements to execution and decide during testing.
Correct Answer: B — Facilitate the group to clarify needs, evaluate options, and agree on value-based prioritization criteria.
Explanation: In Collect Requirements, the PM uses facilitation and decision-making techniques to reconcile and prioritize stakeholder needs. Escalating or deferring bypasses proper analysis and consensus-building.
HKSM