The 5 Requirements Elicitation Techniques Every BA Must Master

A BA on a warehouse management project held three meetings with department heads, compiled a 40-page requirements document, and handed it to the development team. Seven months later, during user acceptance testing, the warehouse staff discovered the system could not handle their lot-tracking requirements for FDA-regulated devices. The requirement had been sitting inside the heads of 35 dock workers who were never consulted. The rework cost $740,000.

This is what happens when elicitation goes wrong. Not because the BA was lazy, but because they used one technique (executive interviews) when they needed three or four.

Elicitation is not "gathering requirements." That phrase implies requirements are sitting in a document somewhere, waiting to be collected. They are not. They are scattered across stakeholder minds, buried in undocumented workarounds, hidden in spreadsheets only one person understands, and tangled in assumptions nobody has examined. Elicitation is the active, skilled work of drawing them out.

These five techniques cover 90% of what you will use on any project.

1. Stakeholder Interviews

The interview is your foundation. A structured conversation with one person, designed to understand their perspective, pain points, and needs in enough detail to write requirements they would recognize as accurate.

The difference between a good interview and a bad one comes down to question sequencing. Open questions first: "Walk me through what happens when a return arrives at the dock." This gives the stakeholder room to describe their reality, including the parts they would not think to mention if you asked a narrow question. Then narrow with closed questions: "How many returns do you process per day on average?" "Who approves refunds over $500?"

The biggest mistake is leading questions. "Don't you think the search is too slow?" tells the stakeholder what answer you want. Ask instead: "How would you describe the search experience?" The difference sounds subtle but changes everything about what you learn.

The second biggest mistake is jumping to solutions. When someone says "we need a better report," the instinct is to discuss report features. Resist. Ask: "What decisions are you trying to make with that report?" The decision matters more than the format. Often the stakeholder does not need a report at all. They need three numbers on a dashboard.

Use interviews early in a project, when you need individual depth, when stakeholders have conflicting views you need to understand separately, and when topics are sensitive enough that people will not discuss them openly in groups.

2. Facilitated Workshops

A workshop brings six to eight stakeholders into a room to collaboratively discuss and decide requirements. What takes two weeks of individual interviews can sometimes be accomplished in a two-hour workshop, because stakeholders hear each other's perspectives in real time and conflicts surface immediately instead of three meetings later.

The key is structure. An unstructured workshop sounds like this: someone asks "so what do we need?", two vocal people dominate for 45 minutes, and everyone leaves with a different understanding of what was agreed. A structured workshop uses specific techniques to prevent that.

Round-robin brainstorming works well for generating ideas: each person shares one requirement in turn, no discussion until all ideas are captured, which prevents dominant voices from anchoring the conversation. Dot voting works for prioritization: give each participant five votes to allocate to their top priorities, and the results are visible instantly. MoSCoW categorization forces trade-off conversations: is this requirement a Must have, Should have, Could have, or Won't have for this release?

The practical ceiling is eight participants. More than ten and you spend more energy managing the room than eliciting requirements. If you need input from twenty stakeholders, run three workshops with different groups, then synthesize.

One thing workshop guides never mention: the parking lot is your most important tool. When someone raises a valid concern that is off-topic for this session, write it on a visible "parking lot" list and commit to addressing it later. This acknowledges the concern without derailing the session. Skip the parking lot and you will either lose the point or lose the agenda.

3. Observation

Observation means watching people do their actual work, in their actual environment, without interfering. It sounds simple. It is one of the most powerful techniques a BA has, and also the most frequently skipped.

Here is why it matters. During an interview, a returns processing clerk will tell you she follows the standard workflow described in the training manual. During observation, you will watch her check a spreadsheet that is not in any training manual, toggle between two systems because the primary one does not display lot numbers, and use a color-coded sticky note system she invented three years ago to track which returns need quality review.

None of that would have surfaced in an interview. She does not mention it because it is invisible to her. It is just "how things work." Observation makes the invisible visible.

Arrange sessions in advance and explain that you are studying the process, not evaluating the person. Take notes on everything: the steps performed, the sequence, the tools used, the interruptions, the communication with others, and especially the moments of friction. Every time someone switches from the official system to a spreadsheet, that is a requirement hiding in plain sight.

After observing, validate: "I noticed you check the inventory spreadsheet after every return. Is that because the system does not show current stock levels?" This confirms what you saw and surfaces the reasoning behind the behavior.

Observe at least two different people doing the same process, and ideally on different days. Busy periods reveal different pain points than slow ones. One observation session with one person is a data point. Two or three is a pattern.

4. Document Analysis

Every project has a paper trail. System documentation describes what the software was designed to do. Training manuals describe how people are taught to use it. Support tickets describe where it breaks. Policy documents describe what rules the system must enforce. And somewhere, almost always, there is a spreadsheet that someone built because the system could not do what they needed.

Document analysis is reviewing these materials to extract requirements that already exist in written form but have not been formally captured. It is the technique you use before interviews, because walking into a stakeholder conversation with baseline knowledge makes every question sharper.

The most valuable documents are often the least formal. A support ticket log that shows 40% of issues relate to search functionality tells you more about where to focus than a polished requirements document from 2019. A workaround spreadsheet maintained by one person reveals an entire workflow the official system does not support. Training materials that differ from what users actually do expose the gap between design intent and operational reality.

The trap is taking documents at face value. A process manual from three years ago may describe rules nobody follows anymore. A system specification may document features that were never built. Always validate what you read against what people actually do, through interviews or observation.

5. Prototyping

Some stakeholders cannot tell you what they want, but they can immediately tell you what they do not want when they see it. Prototyping exploits this by creating a visual representation of the proposed solution, a sketch, wireframe, or clickable mockup, and using it to elicit feedback.

The technique is most valuable when requirements are vague ("make it more user-friendly"), when the solution involves a user interface, and when you need to validate that your understanding is correct before the development team invests weeks of effort.

Start low-fidelity. Sketches on paper or basic wireframes in a tool like Balsamiq. If the prototype looks too polished, stakeholders hesitate to suggest major changes because it looks "done." Present it as a conversation starter: "This is one way this could work. What is your reaction? What would you change? What is missing?"

A mistake I see frequently: presenting one option. If you show a single prototype, stakeholders evaluate it as yes or no. If you show two or three variations, they evaluate trade-offs and give you far richer feedback. "I like the layout of version A but the navigation of version B" tells you more than "looks good" ever will.

Another mistake: the prototype becomes the specification. Stakeholders see a visual mockup and assume the work is nearly done. Be explicit: "This is a sketch to help us discuss requirements. No code has been written. Everything here can change."

Combining Techniques

No single technique is sufficient, and the BAs who rely on only one technique consistently miss requirements that the other four would have caught.

A practical sequence for most projects: start with document analysis to build baseline understanding before you talk to anyone. Use interviews to explore individual perspectives in depth. Bring stakeholders together in a workshop to align on priorities and resolve conflicts. Observe the actual work to catch what everyone forgot to mention because it is so routine they no longer see it. Prototype the proposed solution to validate your understanding before the team starts building.

The order matters less than the coverage. If you only interview, you miss what documents reveal. If you only observe, you miss the "why" behind behaviors. If you only workshop, you miss the concerns people will not raise in front of their manager.

The meta-skill behind all five techniques is comfort with admitting ignorance. "I do not understand how that works. Can you explain?" is the most powerful sentence in a BA's vocabulary. Pretending to understand when you do not is how requirements get written that sound professional and miss the point entirely.

BAvolta teaches elicitation through realistic scenarios, not just definitions. In the Case Lab, you read stakeholder messages, identify conflicting requirements, and produce deliverables with structured feedback. Try the free module.