Requirements Gathering: 10 Questions Every Business Analyst Should Ask
"We need a better checkout." Is that a requirement? Not yet. In this video I take one vague request from a made-up online shop and turn it into real, testable requirements: the 10 questions to ask, how to ask them, 6 elicitation techniques (interviews, document analysis, surveys, workshops, observation, prototypes), a worked example with acceptance criteria, and the 5 mistakes to avoid.
Step by step
Requirements are drawn out, not gathered
- People rarely hand you a list of requirements. They bring a problem, a wish or a complaint. That is why the IIBA's BABOK Guide calls this elicitation: you draw out what people really need with good questions, then check you heard it right.
Explain like I'm 5: the good doctor
- Think of a good doctor. When you say you feel bad, they don't hand you a pill straight away. They ask where it hurts and since when. A business analyst does the same with "we need a better checkout" before anyone builds a fix.
The three elicitation tasks (BABOK)
- The BABOK Guide has tasks for 3 stages of elicitation. Prepare: set the goal and pick the technique and the people. Conduct: run the interview, workshop or observation. Confirm: play back what you heard and check it against other sources. Beginners often skip the first and last.
A one-page elicitation plan
- Preparing can be a one-page elicitation plan. Goal: understand why shoppers leave at checkout. People: the sales manager, 2 customer service agents, the warehouse and some shoppers. Techniques: interviews, then a survey, then a workshop. Materials: the checkout screens and last month's support tickets. Timing: 1 week.
The vague request
- The sales manager of the online shop says: "We need a better checkout." That is not a requirement yet. Better for whom, and better how? Nobody could build or test it. The 10 questions below come in 3 groups: the why, the flow and the edges.
How to ask: open, closed, silence
- Use open questions (what, how, tell me about) to get people talking. Save closed yes/no questions for the end, to confirm details. After you ask, stay silent and count to 5. People fill the gap, and the real answer often comes out there.
Questions 1-3: the why
- 1: What problem are we solving? Not "what do you want", which gets you a solution. Answer: too many people leave at checkout. 2: Who has this problem, such as phone shoppers or first-time buyers? 3: How will we know it worked? Here: fewer carts abandoned at checkout.
Questions 4-6: the flow
- 4: What happens today, step by step? Walk through cart, address, shipping, payment and confirmation, and ask them to show you. 5: What should happen instead? Keep asking why. 6: What are the rules and data, such as how shipping is priced and which payment types are accepted?
Questions 7-10: the edges
- 7: What can go wrong? A declined card, an item that sells out, a wrong address. 8: How well must it work: how fast, for how many and how safe? These are non-functional requirements. 9: What is out of scope? 10: Who else should I talk to? That is how you find the warehouse team.
Three types of elicitation
- Questions are what you ask. Techniques are how you ask them. The BABOK Guide sorts elicitation into 3 types: collaborative (interviews, workshops), research (documents, data) and experiments (observation, prototypes). Good analysts mix all 3.
Technique 1: interviews and the 5 whys
- An interview is one person, one conversation, your questions. Dig deeper with the 5 whys. Why a better checkout? People leave. Why? The data shows most leave at the shipping step. Why there? It's the first time they see the cost. Send questions ahead and write notes the same day.
Techniques 2-3: document analysis and surveys
- Document analysis: read the old checkout spec, the shipping rate table and the support tickets first. Many tickets ask "how much is delivery?" A survey gets many voices fast: send 5 short, neutral questions to shoppers who left a cart. Ask "What made you stop?", not a leading question.
Technique 4: workshops
- A workshop puts the right people in one room with one goal and a time box. Sales wants free shipping, finance wants to protect the margin, and the warehouse knows parcel costs. In 90 minutes they agree: show shipping in the cart, with free shipping above a set order value.
Technique 5: observation
- Observation means watching people work, because they can't always explain it. Sitting with customer service for an hour shows them looking up delivery costs in a spreadsheet nobody mentioned in the interviews. Observation finds workarounds like this.
Technique 6: prototypes
- A prototype, even a paper sketch of the new cart page, gets real reactions. The mock-up shows shipping worked out from the postcode, but a phone shopper doesn't want to type a postcode yet. New requirement: estimate shipping from the state first, and ask for the postcode later.
Worked example: from wish to requirements
- The result. Problem: shoppers leave because they see shipping too late. Requirements: the cart shows estimated shipping, uses the state and then the postcode, and shows free shipping above the threshold. Given a shopper in Victoria, when they open the cart, then they see the estimate.
Confirm: play it back
- Then confirm. Play the requirements back to the sales manager, the warehouse and finance: "Here's what I heard. Did I get it right?" Check that the tickets and the survey tell the same story as the interviews. A mismatch found now is the cheapest fix you'll get.
Make every requirement traceable
- Record each requirement with an ID, a priority and an owner, so it traces back to the problem and to who asked for it. That can be a table in Airtable, a page in Confluence or user stories in Jira. Also add a quality requirement (the estimate appears within 1 second) and the scope: international shipping comes later.
5 common mistakes
- 5 common mistakes: asking "what do you want?", jumping to a solution in the first meeting, only talking to the boss, asking leading questions, and not writing requirements down and playing them back.
Recap
- Recap: requirements are drawn out, not gathered. Prepare, conduct, confirm. Ask the 10 questions, mix interviews, documents, surveys, workshops, observation and prototypes, and play back what you heard before anything is built.
Common mistakes
- Asking stakeholders what they want. You get a solution, like a new button, instead of the need behind it. Ask what problem they are trying to solve, then ask why until you reach the real cause.
- Only talking to the manager who asked. The people who do the work, like customer service or the warehouse, know where it really hurts. Ask "Who else should I talk to?" and observe them at work.
- Leading questions in interviews and surveys. "Wasn't the shipping cost annoying?" only gets the answer you hoped for. Ask neutral, open questions such as "What made you stop?"
- Skipping the confirm step. If requirements are not written down and played back, misunderstandings reach the developers. Send a summary, ask "Did I get this right?" and check it against tickets or survey results.
When a business analyst uses this
When a sponsor asks for "a better onboarding process", a business analyst runs short interviews with the 10 questions, observes the team doing the current process, then holds a 90-minute workshop. Each agreed requirement goes into the requirements log with an ID, an owner and acceptance criteria, ready for sign-off.
Questions people ask
What is the difference between requirements gathering and elicitation?
They describe the same work, but the BABOK Guide uses "elicitation" because requirements are rarely ready to pick up. You have to draw them out of people with questions and techniques, then confirm what you heard.
What questions should you ask in requirements gathering?
Ask what problem you are solving, who has it, how success will be measured, what happens today and what should happen instead, and what the rules and data are. Then ask what can go wrong, how well it must work, what is out of scope and who else to talk to.
How do you run a requirements gathering workshop?
Invite the people who need to agree, set 1 clear goal and a time box, and have a facilitator, an agenda and someone taking notes. End by playing back what was agreed so everyone confirms it.
