Requirements Elicitation Techniques That Work
- Contributor
- Mar 31
- 5 min read
Writing requirements is easy. Getting accurate requirements out of stakeholders is hard. People don't know what they want until they see something. People know what they want but can't articulate it. People want different things and the contradictions don't surface until much later.
This guide is techniques that actually surface what people need.
Why Elicitation Is Hard
A few specific reasons:
Tacit knowledge. Stakeholders know things they don't think to mention. The accounting team's quarterly close has a specific workflow that nobody describes because it's "just how we work."
Stated vs. actual needs. "I want a search feature." When asked why: "Because I can't find things." The actual need is findability; search is one solution.
Edge cases not top-of-mind. Stakeholders describe the happy path. The edge cases emerge later.
Multiple stakeholders disagree. Each has different priorities; consensus is fragile.
The problem evolves during discovery. Talking about needs surfaces new ones; the team chases a moving target.
Each is addressable with the right technique.
Interviews
The most common technique. One-on-one or small-group conversations.
Strengths:
Rich context
Follow-up questions
Body language signals
Trust building
Weaknesses:
Time-intensive
Stakeholders may say what they think you want to hear
Single-person view; one perspective
Good interviewing practices:
Start with open-ended questions ("walk me through how you do X")
Don't lead the answer
Probe with "why" and "how"
Capture verbatim where possible
Synthesize after, not during
Observation
Watch the stakeholder doing their work.
Strengths:
Reveals tacit behavior
Catches things people don't think to mention
Sees actual workflow, not described workflow
Surfaces workarounds and pain points
Weaknesses:
Observer effect (people behave differently when watched)
Time-intensive
Limited to current behavior; doesn't capture future needs
Observation often surfaces the most surprising requirements. People do things in ways they wouldn't describe.
Workshops
Group sessions with multiple stakeholders.
Strengths:
Surfaces disagreement
Builds shared understanding
Faster than many 1:1 interviews
Captures cross-stakeholder dependencies
Weaknesses:
Dominant voices crowd out others
Politics affect what gets said
Group dynamics can produce false consensus
Good workshop facilitation:
Silent independent generation first (sticky notes, etc.)
Then group discussion
Explicit role for skeptic
Capture disagreements; don't paper over them
Surveys and Questionnaires
Quantitative input from many stakeholders.
Strengths:
Scales
Quantifies preferences
Anonymity can surface honest answers
Quick to analyze (with good question design)
Weaknesses:
Limited depth
Question phrasing biases answers
Misses what isn't asked
Best for validating hypotheses rather than initial discovery.
Document Analysis
Reviewing existing documents, contracts, regulations, support tickets, etc.
Strengths:
Captures established constraints
Surfaces edge cases through support history
Reveals what isn't being said
Weaknesses:
Documents may be outdated
Misses informal practices
Time-consuming for large volumes
Combine with other techniques; rarely sufficient alone.
Prototyping and Mockups
Show something concrete; ask reactions.
Strengths:
Surfaces requirements stakeholders couldn't articulate
Validates understanding
Reduces ambiguity by showing
Fast iteration cycles
Weaknesses:
Stakeholders fixate on visuals over functionality
Can lock in design too early
Low-fidelity prototypes risk being interpreted as final
Prototyping is particularly valuable when stakeholders struggle to describe what they want abstractly.
Wizard of Oz Testing
Simulate the system behavior manually behind the scenes. The stakeholder interacts with what looks like a working system, but a human is operating it.
Strengths:
Tests real interactions before building
Surfaces issues at low cost
Validates flow before locking in
Weaknesses:
Limited scale
Won't catch performance or technical issues
Setup overhead
Useful for novel interactions where the team isn't sure what to build.
Five Whys
A drilling technique for understanding root causes.
Stakeholder: "We need a faster report."
You: "Why?" → "Because monthly reports take 3 days to compile."
You: "Why?" → "Because data comes from 4 systems."
You: "Why?" → "Because each team owns one system."
You: "Why?" → "It's how the org evolved."
You: "Why?" → "Compliance separation rules."
The actual constraint isn't slow reports; it's data integration limited by compliance. The right requirement might be different from "faster report."
Apprenticing
Spending substantial time embedded with stakeholders, doing or assisting their work.
Strengths:
Deepest possible understanding
Captures rare scenarios
Builds trust
Weaknesses:
Very time-intensive
Not always practical
May not be welcome
For high-stakes, complex domains, the investment pays off. For simpler products, lighter techniques work.
Combining Techniques
No single technique captures everything.
A working sequence:
Document analysis (background)
Stakeholder interviews (broad picture)
Observation (actual behavior)
Prototype iteration (concrete validation)
Workshops (cross-stakeholder alignment)
Different techniques for different phases. Different again for validation later.
What to Capture
During elicitation, capture:
The stated need. What they said.
The implied need. What you think they actually need (subject to validation).
The current workflow. How they do it today.
The pain points. What's frustrating.
The workarounds. What they've built around the limitations.
The constraints. What can't change.
The success metrics. How they'd know if it worked.
Notes from each session feed into the requirements document. Verbatim quotes are particularly useful because they preserve nuance.
Avoiding Common Traps
Solution-shaped questions. "Do you want a dropdown or a search box?" Both are solutions. Ask about the underlying need.
Anchoring. Mentioning a number or option biases responses. Open-ended questions first.
Confirmation bias. Asking only the stakeholders who'd confirm your existing belief. Talk to dissenting voices.
Premature design. Locking in a solution before fully understanding the need.
Treating stakeholders as a monolith. Different users have different needs; aggregate views miss the variation.
Validating What You've Captured
Elicitation is half the work. Validation is the other half.
Read it back to stakeholders. Did you capture what they meant?
Show concrete examples. Do the scenarios match their reality?
Identify disagreements among stakeholders. Resolve them explicitly.
Test with a prototype or thin slice.
The first draft of requirements is almost always wrong in subtle ways. Validation catches them.
When Stakeholders Don't Know
A common situation: the stakeholder genuinely doesn't know what they want. The product is too new, the domain too novel.
Approaches:
Show concrete examples. Reactions reveal preferences.
Build small things and iterate. Real use teaches what abstract discussion can't.
Look at adjacent or similar products. Borrow what works there.
Run experiments. A/B test, beta with select users.
In these cases, requirements emerge through use, not before.
A Worked Pattern
For a new feature:
Read existing documents (1-2 days): support tickets, prior research, related work
Conduct 5-8 interviews (1 week): users, internal teams, support
Observe 2-3 stakeholders working (1-2 days): in their environment
Synthesize findings (2-3 days): identify patterns, contradictions, gaps
Build a prototype (1-2 weeks): low-fidelity, focused on flow
Run feedback sessions (1 week): 5-8 sessions with prototype
Refine requirements (1 week): based on synthesis and feedback
Total: 4-6 weeks for a substantial feature. Less for simpler ones. Skipping any step is possible; each skip increases the risk of building the wrong thing.
Key Takeaway
Requirements elicitation is harder than writing them down. Techniques include interviews, observation, workshops, surveys, document analysis, prototyping, Wizard of Oz, Five Whys, and apprenticing. No single technique captures everything; combine for layered understanding. Capture stated needs, implied needs, current workflows, pain points, workarounds, constraints, and success metrics. Validate by reading back, showing examples, and testing thin slices. The first draft of requirements is almost always wrong in subtle ways — iterate.
Related reading
Keep learning. This article is part of the Requirements & Business Process Improvement path in the ShiftQuality Learning Center. Elicit, prioritize, and trace requirements that survive reality.
