Elicitation is the most misunderstood BA activity. It's not "gathering requirements" — that framing suggests requirements already exist somewhere and the BA just collects them. They don't. They emerge through conversation, observation, and analysis.
BABOK KA 2 covers three tasks:
- Prepare for elicitation — choosing the right technique for the stakeholder and context, scheduling sessions, framing the questions
- Conduct elicitation — the actual activity
- Confirm elicitation results — verifying that what was captured reflects what stakeholders actually meant
The technique matters less than people think. What matters is the quality of listening and the questions asked. The BA's job is to understand the real need, which is usually one or two layers below the stated request.
The technique repertoire:
- Interviews — deep signal from key stakeholders; time-intensive but high quality
- Workshops — efficient for alignment across multiple stakeholders at once; requires strong facilitation
- Observation — watch users actually do the work; reveals what they can't articulate
- Document analysis — existing systems and processes as requirements sources
- Prototyping — when stakeholders can't describe what they want, they can often react to what they see
I ran 10+ JTBD interviews on the business incubator project before writing a single requirement. The interviews completely reframed what we were building — what stakeholders described as a payroll tool turned out to be a trust problem. Users didn't know what the system was doing with their data. The real requirement was transparency, not functionality.
Exam tip: BABOK says elicitation is ongoing — not a phase. New information emerges throughout delivery, and the BA's job is to integrate it, not to protect the original requirements baseline.