Elicitation is discovery, not transcription
Stakeholders rarely arrive with perfectly structured requirements. They describe symptoms, preferences, workarounds, frustrations and desired features. The BA's job is to turn those conversations into shared understanding.
Prepare before the meeting
Know what you already understand, what remains uncertain, who needs to be involved, and what decision the session should enable.
Question patterns that work
| Question | Practical answer |
|---|---|
| Open | “Walk me through what happens today.” |
| Why | “What makes that step necessary?” |
| Exception | “What happens when this does not go as expected?” |
| Evidence | “How do you know this is a problem?” |
| Outcome | “What would be different if this worked well?” |
| Constraint | “What cannot change?” |
Choose the technique to fit the problem
Use interviews when you need depth, workshops when you need alignment, observation when people struggle to describe real behavior, surveys when you need breadth, and prototypes when a visual conversation is faster than abstract discussion.
Listen for hidden requirements
“We need this report every morning” might hide a scheduling requirement. “Only managers should see this” might hide an authorization requirement. “It must never fail” might hide an availability or recovery expectation.
After the meeting
Document the result quickly while context is fresh. Then confirm the interpretation with the people who supplied the information. Confirmation is part of elicitation, not administrative cleanup.