HKSM

A structured approach to discover stakeholder needs and translate them into clear, prioritized, and testable requirements that guide solution delivery and validation.

Purpose & When to Use

Elicit and Analyze Requirements ensures the team understands what stakeholders need and why, then converts that understanding into clear, testable requirements. It reduces rework, aligns scope with value, and sets up reliable acceptance criteria.

• Use at project start to define scope and value outcomes.
• Use iteratively during discovery, each iteration, and whenever changes arise.
• Use before major design or procurement decisions to avoid costly misalignment.
• Use to validate compliance, security, and non-functional expectations.

Mini Flow (How It’s Done)

• Plan the approach: identify stakeholders, objectives, decision rules, cadence, techniques, and tools.
• Prepare context: confirm problem statement, current state, constraints, assumptions, and a shared glossary.
• Elicit collaboratively: use interviews, workshops, observation, document analysis, surveys, and prototypes to surface explicit and tacit needs.
• Model and structure: categorize into business, stakeholder, functional, non-functional, and transition requirements; use process flows, user stories, use cases, data models, and wireframes.
• Define acceptance: write measurable acceptance criteria and examples to enable testing and shared understanding.
• Analyze and refine: remove ambiguity, split large items, resolve conflicts, assess feasibility, and estimate at the right level.
• Prioritize with value in mind: apply methods such as MoSCoW, Kano, or WSJF, and document decision rationale.
• Validate with stakeholders: review walk-throughs, prototypes, and examples to confirm correctness and testability.
• Trace and organize: link requirements to objectives, scope, risks, and test cases using a backlog or traceability matrix.
• Manage changes: use integrated change control for baselined sets or backlog refinement for adaptive lifecycles.
• Prepare outputs: updated backlog or requirement set, acceptance criteria, models, and agreed Definition of Ready/Done.

Quality & Acceptance Checklist

• Clear, specific, and free of ambiguous terms; each requirement is atomic.
• Testable with defined acceptance criteria or concrete examples.
• Aligned to business goals and measurable outcomes.
• Prioritized and right-sized for planning and delivery.
• Feasible within constraints and compliant with policies, standards, and regulations.
• Includes non-functional needs such as performance, security, privacy, usability, reliability, and accessibility.
• Traceable from source to design, build, and test artifacts.
• Consistent with other requirements; conflicts identified and resolved.
• Assumptions, constraints, and dependencies captured and visible.
• Reviewed and agreed by the right decision-makers and end users.
• Meets Definition of Ready for commitment and Definition of Done for acceptance.

Common Mistakes & Exam Traps

• Jumping to solution design before understanding the problem and outcomes.
• Relying on a single stakeholder group and missing end users, operations, security, or compliance voices.
• Using vague language like “fast” or “user-friendly” without measurable criteria.
• Ignoring non-functional requirements and operational quality attributes.
• Skipping acceptance criteria, leading to unclear testing and rework.
• Not maintaining traceability, making impact analysis of changes difficult.
• Treating initial sign-off as immutable rather than applying proper change control or backlog refinement.
• Prioritizing by loudest voice instead of value, risk, and constraints.
• Documenting duplicate or conflicting requirements without reconciliation.
• Believing prototypes or wireframes are only for agile; they are useful in any delivery approach.
• Assuming the sponsor approves every requirement; respect defined roles like product owner and SMEs.
• Failing to validate with actual users through reviews, examples, or tests.
• Collecting requirements once and not revisiting them as the context changes.
• Leading questions and facilitator bias that steer stakeholders toward a preset solution.

PMP Example Question

During a requirements workshop, two stakeholder groups propose conflicting needs for the same feature. The product owner asks you to pick one so the team can move on. What should you do next?

1. Choose the requirement that is faster to implement to avoid delays.
2. Document both requirements as-is and baseline them for a later decision.
3. Facilitate a follow-up session to clarify underlying needs, evaluate value and constraints, and agree on acceptance criteria and priority.
4. Escalate the conflict to the sponsor and pause elicitation until a decision is made.

Correct Answer: C — Facilitate a follow-up session to clarify needs, evaluate value, and agree on acceptance criteria and priority.

Explanation: The best next step is to analyze and resolve conflicts collaboratively using decision rules and prioritization. Escalate only if governance requires it; do not baseline conflicting items or decide based on effort alone.