A business analyst is preparing for a new project. The business sponsor has shared a process document, the operations team has requested a workshop, and the technical team wants a set of requirements before estimating the work.
There is only one problem: nobody has clearly explained how the process actually works today.
The sponsor describes the intended process. The operations team describes the exceptions. The people doing the work have developed their own shortcuts, and the existing documentation has not been updated in two years.
The analyst has several ways to investigate the situation. They could interview stakeholders, organise a workshop, observe the team at work, review existing documents or create a prototype of the proposed solution.
Which method should they choose?
This is where requirements elicitation becomes more than a checklist of business analysis techniques. The challenge is not simply to collect information. It is to decide which method will reveal the information that is currently missing.
Start with the question, not the technique
Interviews, workshops, observation, surveys, document analysis and prototyping are all useful. None is automatically the best choice.
Before selecting a technique, ask yourself three questions:
What do I need to understand?
Who or what is most likely to provide reliable evidence?
What uncertainty will remain if I use this method alone?
Consider a simple example. A sales director says that the sales team needs a new field in the CRM system to improve opportunity qualification.
An interview might explain why the director wants the field. A workshop might reveal that sales managers interpret qualification differently. Observation might show that representatives already record the information elsewhere. Analysing CRM data might establish whether opportunities are being lost because the information is missing at all.
Each technique investigates a different part of the problem.
If the analyst immediately schedules a requirements workshop, they may gather a detailed list of requested fields without discovering whether those fields would solve the underlying issue.
The first decision, therefore, is not which technique is most popular. It is which question needs answering first.
Five techniques, five different strengths
1. Interviews: when you need to understand individual perspectives
Interviews are particularly useful when the subject is complex, sensitive or influenced by individual responsibilities.
Suppose the finance team wants an additional approval before a sales discount can be offered. Sales argues that the approval will slow down negotiations.
A group meeting may quickly become a debate about whose process is better. Individual interviews allow the analyst to understand each stakeholder's concerns before bringing them together.
Finance may be trying to prevent margin erosion. Sales may be trying to respond quickly to customers. Both could be describing legitimate business needs.
A useful interview explores what happens today, why it happens, where problems occur and what a successful outcome would look like.
The important part is the follow-up question. If someone says, "We need another approval," ask what risk the approval is intended to control. If they say, "The process is too slow," ask where the delay occurs and what impact it has.
Choose interviews when: you need depth, individual viewpoints, sensitive information or an understanding of why people behave in a particular way.
Watch out for: treating one person's account as the complete picture. Stakeholders describe processes from their own perspectives, and those perspectives may be incomplete or contradictory.
2. Workshops: when you need people to work through a shared problem
Workshops are valuable when multiple stakeholders need to agree on a process, clarify competing requirements or make decisions together.
Imagine a customer complaint process involving operations, customer service, compliance and technology. Each team understands its own responsibilities, but nobody has a complete view of how a complaint moves from receipt to resolution.
A facilitated workshop can map the end-to-end process, identify hand-off problems, expose conflicting assumptions and establish where decisions are required.
It also gives participants an opportunity to correct misunderstandings in real time.
However, a workshop is not a substitute for investigation. If participants arrive with different versions of the facts, the loudest or most senior person may shape the outcome before the real issue has been examined.
For difficult or politically sensitive subjects, individual interviews before the workshop can make the group discussion far more productive.
Choose workshops when: you need shared understanding, collaborative problem-solving, process mapping, prioritisation or agreement on options.
Watch out for: groupthink, dominant participants and premature consensus. Agreement in the room does not necessarily mean the requirements are complete or correct.
3. Observation: when what people say may differ from what they do
Documentation describes how a process is supposed to work. Interviews describe how people remember or experience it. Observation helps you understand what happens in practice.
Consider a service team that reports every customer complaint through the official system. During an interview, employees confirm that they follow the process.
When the analyst observes the work, a different picture emerges. Straightforward complaints are recorded immediately, but complicated cases are discussed over email or chat before anyone creates a formal record. Some cases are entered only when a manager asks for an update.
The problem is no longer simply whether the system has the right fields. The analyst must investigate why the official process is being bypassed.
Observation is particularly helpful for repetitive tasks, operational workflows, manual workarounds and situations where employees find it difficult to explain every step they take.
It can reveal duplicate entry, unnecessary hand-offs, hidden dependencies and exceptions that never appear in process documentation.
Choose observation when: you need to understand actual behaviour, operational bottlenecks, workarounds or the difference between the documented and real process.
Watch out for: assuming that one observed instance represents normal behaviour. Explain the purpose of the observation, respect privacy and consider whether people are changing their behaviour because they know they are being observed.
4. Document and data analysis: when evidence already exists
Before asking people to explain everything from scratch, examine the information the organisation already has.
Existing process documents, policy manuals, audit findings, support tickets, spreadsheets, CRM records, reports and system logs can provide valuable evidence.
For example, a business asks for a new escalation workflow because complaints appear to remain unresolved for too long.
The existing procedure says that complaints should be assigned within one working day. The service report shows that most complaints are assigned within that period, but many remain in the same status for several days after assignment.
The initial request was for a new workflow. The evidence suggests that the more important question may be what happens after assignment.
This does not mean the data has already provided the answer. It has helped narrow the investigation.
Document analysis can establish formal rules and existing constraints. Data analysis can help test assumptions, identify patterns and quantify the scale of a problem.
Choose document and data analysis when: you need to understand existing rules, validate stakeholder claims, investigate historical performance or identify patterns across many cases.
Watch out for: outdated documentation, incomplete records and misleading metrics. A report can accurately measure the wrong thing, and a system log cannot explain every human decision behind an event.
5. Prototypes and visual models: when people struggle to explain what they need
Sometimes stakeholders cannot describe a requirement clearly until they can see how it might work.
A request such as "make the customer screen easier to use" is too broad to guide development. A prototype can help stakeholders react to a possible layout, navigation flow or sequence of actions.
A simple screen mock-up may reveal that users need important information in one place, that a particular field is unnecessary or that the proposed process introduces extra steps.
Prototypes are especially useful for user interfaces, new workflows and unfamiliar product capabilities. Process maps, decision tables and low-fidelity sketches can serve a similar purpose when the uncertainty concerns business rules rather than screen design.
A prototype should be treated as a tool for learning, not proof that the proposed solution is correct.
Choose prototypes when: requirements are abstract, users find it difficult to articulate their needs, or the team needs feedback on a proposed interaction or workflow.
Watch out for: stakeholders focusing on colours and layout before agreeing on the underlying process, or mistaking a visual demonstration for a finished, technically feasible solution.
How to choose the right technique
The following decision guide is a starting point, not a rigid rulebook.
If your main question is…Start with…Consider combining it with…Why does a stakeholder want a change?InterviewDocument or data analysisWhy do teams disagree?Individual interviewsFacilitated workshopWhat actually happens during the process?ObservationProcess mappingIs the problem as widespread as people claim?Data analysisInterviewsWhat do existing policies require?Document analysisInterviews with process ownersHow should a proposed screen or workflow work?PrototypeUser testing and workshopsHow can teams agree on a future process?WorkshopProcess analysis and prototype
The most effective approach often combines techniques. Use the table to choose where to begin, then determine what evidence is still missing.
A practical decision sequence
When the situation is unclear, use this sequence to decide what to do next.
Step 1: Define the uncertainty.
Write down the question you cannot yet answer. Avoid vague statements such as "we need more requirements." Be specific: "We do not know why complaints remain unresolved after assignment."
Step 2: Identify the best source of evidence.
If the question concerns people's motivations, speak to them. If it concerns actual behaviour, observe the work. If it concerns frequency or performance, examine the data. If it concerns a proposed experience, show users a prototype.
Step 3: Check the limitations of that evidence.
An interview reveals a perspective, not necessarily a verified fact. A report reveals a pattern, not necessarily its cause. A workshop reveals what participants can agree on, not automatically what customers need.
Ask what the selected technique cannot tell you.
Step 4: Select a second technique if needed.
If the data shows a delay but does not explain why, interview the people involved. If interviews reveal different versions of a process, observe the work. If a workshop produces an agreed future process, test the proposed workflow with a prototype or a representative group of users.
Step 5: Validate what you have learned.
Check whether the findings explain the original business problem. Confirm assumptions with the appropriate stakeholders, test important business rules and record unresolved questions.
The objective is not to use as many techniques as possible. It is to gather enough reliable evidence to make a defensible decision.
An example: choosing techniques for a CRM change
Return to the sales director who requested a new qualification field in the CRM system.
Rather than starting with a large workshop, the analyst takes a staged approach.
First, an interview establishes that management is concerned about opportunities progressing through the pipeline without sufficient qualification.
Next, CRM data analysis shows that opportunities are frequently moved to later stages despite missing information. However, the data does not explain why users do this.
A few observations and follow-up interviews reveal that representatives are using different qualification criteria, while the existing CRM process does not make the expected criteria clear at the point of progression.
The analyst then facilitates a workshop with sales representatives, managers and relevant stakeholders. Together, they agree on the information needed at each stage and identify which exceptions should be permitted.
Finally, a simple prototype demonstrates how the qualification criteria and progression rules might appear in the CRM. Users test whether the proposed approach supports their work without introducing unnecessary friction.
The result may still include a new field. But the decision is now supported by evidence about the process, user behaviour and business need—not merely by the initial request.
That distinction is what makes requirements elicitation valuable.
The real skill is knowing what you do not know
A business analyst does not need to use every elicitation technique on every project. Nor should the choice be driven solely by personal preference or the method used on the previous assignment.
The right technique depends on the question, the available evidence, the people involved and the consequences of getting the answer wrong.
Interviews help uncover perspectives. Workshops help people work through shared problems. Observation reveals real behaviour. Documents and data provide existing evidence. Prototypes make proposed solutions easier to evaluate.
Used thoughtfully, these techniques complement one another.
The next time someone asks for a workshop, a requirements document or a new system feature, pause before organising the activity. Identify the uncertainty first. Then choose the method most likely to reduce it.
Better requirements do not come from collecting more information indiscriminately. They come from asking the right questions, using the right evidence and knowing when the answer still needs to be tested.
Part of Try / Test / Decide on PushPullBuild: practical approaches to choosing between competing methods, options and trade-offs in business analysis and technology delivery.