Requirements ElicitationLesson 1
Eliciting vs Gathering: Why the Word Matters
8 minutes
Junior BAs are often told to "go gather the requirements". It sounds reasonable. It is also a flawed mental model that leads to bad requirements work.
This lesson is about the difference between gathering and eliciting, and why BABOK uses the word "elicitation" deliberately.
The gathering metaphor
The word "gather" implies a few specific things.
1
Requirements already exist
Somewhere out there. In stakeholder heads, in old documents, in process maps. The BA just needs to find them and write them down.
2
Requirements are complete
Stakeholders know what they want. They can articulate it clearly. The BA collects, ranks and documents what they say.
3
The BA is a stenographer
A transcriber of what stakeholders say. Neutral. No judgement on the requirements themselves. Just write them down.
All three are wrong on most projects.
Why "gathering" fails in practice
Stakeholders cannot fully articulate what they needMost people doing operational work cannot describe it accurately. They know how to do the job but not how to explain it. Asking for their requirements produces an idealised version of the actual process.
Different stakeholders contradict each otherEach stakeholder has a partial view. Their requirements rarely add up to a coherent whole. A gathering mindset writes all of them down. An elicitation mindset surfaces the contradictions and resolves them.
What people say differs from what they doDocumented processes describe the ideal. Real practice has exceptions, workarounds and undocumented steps. Gathering captures the ideal. Eliciting captures the real.
Tacit knowledge stays hiddenA huge fraction of operational knowledge is tacit: people know it but cannot say it. Gathering misses this. Eliciting uses observation, prototyping and probing to surface it.
The elicitation mindset
BABOK uses "elicitation" because the word carries the right implications.
Elicitation in one sentence
Elicitation is the process of drawing out information that stakeholders may not consciously know they have, surfacing contradictions between sources and creating a coherent view of what the system needs to do.
Three implications follow.
1
The BA is a co-creator, not a transcriber
Requirements get shaped by the conversation, not just captured by it. Asking the right question often produces a requirement that the stakeholder did not have before the question.
2
Multiple techniques are needed
No single elicitation technique catches everything. Interviews miss tacit knowledge. Observation misses strategic intent. Document analysis misses how work actually happens. A good BA uses several techniques in combination.
3
Iteration is necessary
The first pass surfaces 60% of the picture. The second pass, after stakeholders have seen a draft, surfaces another 25%. The third pass closes gaps. Plan for multiple cycles.
The single biggest failure mode
When a project ships and the business says "this is not what we asked for", the most common root cause is not BA incompetence. It is that the BA gathered requirements instead of eliciting them. The stakeholders said one thing, the BA wrote it down, and what got built matched the words but not the underlying need.
The escape clause that catches gathering
When a project review identifies that the delivered system 'meets the documented requirements but does not solve the business problem', that is the signature of a gathering project. The fix is upstream: stronger elicitation. Not stronger documentation.
What this module covers
The remaining lessons in this module each cover one elicitation technique. Use them in combination.
1
Interviews
1-on-1 or small group. The default for getting stakeholder perspective and surfacing intent.
2
Observation and shadowing
Watch the work being done. The only technique that catches tacit knowledge reliably.
3
Document analysis
What the organisation already wrote down. Often a faster start than asking people to repeat what is already on paper.
4
Brainstorming and affinity diagrams
For early-stage problem definition and future-state design. Group technique.
5
Prototyping for elicitation
Show the stakeholder something and watch what they react to. Catches requirements that are easier to recognise than to specify.
6
Surveys
When you need broad input from many stakeholders. Useful at scale, limited depth per response.
Key Takeaways
- "Gathering" is a flawed metaphor. It implies requirements already exist, are complete and just need transcription. None of those are usually true.
- "Eliciting" is the right word. Requirements emerge through dialogue, observation, modelling and iteration.
- Tacit knowledge is real. Most operational knowledge cannot be articulated cleanly when asked. Elicitation techniques surface it.
- Multiple techniques in combination. No single technique catches everything. The next 6 lessons cover the core techniques.