Requirement Elicitation
A structured method for systematically capturing stakeholder needs, assumptions, and acceptance criteria to define product and solution scope.
Classification
- ComplexityMedium
- Impact areaOrganizational
- Decision typeOrganizational
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Incomplete stakeholder analysis leads to missing requirements.
- Misunderstood requirements cause costly corrections later in the project.
- Over-documentation delays delivery and reduces agility.
- Small, focused workshops instead of large collection sessions.
- Explicitly record assumptions and open questions.
- Routine validation of requirements in iterations.
I/O & resources
- Stakeholder register and contact information
- Existing process and system documentation
- Business goals and product vision
- Aligned and prioritized requirements
- Acceptance criteria and test bases
- Risk and assumptions log
Description
Requirement elicitation is a structured method for uncovering stakeholder needs, constraints and acceptance criteria to shape product scope and design. It combines interviews, workshops, observation and document analysis to build shared understanding. The method emphasizes stakeholder alignment, traceability of decisions and early validation to reduce rework.
✔Benefits
- Reduction of rework through earlier clarification of expectations.
- Better alignment between business and engineering teams.
- Traceable requirements with clear acceptance criteria.
✖Limitations
- Without good facilitation, dominant voices may skew outcomes.
- Time-consuming with a large number of stakeholders.
- Only as good as the represented stakeholders and data sources.
Trade-offs
Metrics
- Number of clarification questions during implementation
Measures how often requirements are unclear during implementation.
- Requirement change rate
Share of requirements changed after planning.
- Stakeholder satisfaction with elicited requirements
Stakeholders' subjective rating of completeness and correctness.
Examples & implementations
Bank: Elicitation of regulatory reporting requirements
Workshops with compliance, IT and business units resulted in a standardized reporting specification and a clear implementation plan.
E-commerce: defining MVP requirements
Interviews and prioritization workshops reduced scope and enabled quick market launch of the core feature.
IoT integration: aligning partner requirements
Technical workshops with partners clarified interfaces and test criteria and avoided later integration failures.
Implementation steps
Identify and invite stakeholders.
Define goals, assumptions and scope together.
Conduct a mix of interviews, workshops and observations.
Consolidate, prioritize and document results.
Validate and sign off requirements with stakeholders.
⚠️ Technical debt & bottlenecks
Technical debt
- Unclear requirements that lead to repeated rework.
- Missing traceability between requirements and tests.
- Outdated specifications without a maintenance process.
Known bottlenecks
Misuse examples
- Interviewing only management and ignoring end users.
- Creating formal documents without stakeholder feedback.
- Not documenting assumptions and being surprised later.
Typical traps
- Requesting too much detail too early (analysis paralysis).
- Treating stakeholders as a homogeneous group.
- Not versioning results and keeping them traceable.
Required skills
Architectural drivers
Constraints
- • Time constraints before releases
- • Confidentiality requirements for sensitive data
- • Limited resources for facilitation and analysis