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.
Elicitation is where good questions pay for themselves
Many requirements are hidden inside stories. A user says, “We normally refund it, except when the item is damaged.” That one sentence contains a process rule, an exception and an implied decision authority. Slow down and unpack it.
Use the current process as your anchor
When someone describes the desired future state, bring the discussion back to today. Ask what triggers the process, what information enters it, who makes each decision, what system is used, and where work waits. The contrast between As-Is and To-Be gives you the material for a meaningful gap analysis.
Instead of asking, “What fields should the form have?”, ask, “Show me the last time you completed this form. What information did you need at each step, and where did you have to look it up?” The second question exposes actual behavior rather than remembered ideal behavior.
Close the loop in the same meeting
Near the end, replay your understanding: “So the normal path is A → B → C, but when condition X occurs, the order goes to Y. Finance owns the final approval. Is that accurate?” This gives stakeholders a chance to correct your model while the details are still fresh.
Run a mock discovery for an online return process. Start with “walk me through the last return,” then ask follow-up questions until you can describe the happy path, two exceptions, the business rule behind each exception and who owns each decision.