Most missed requirements are not hidden. They are said out loud, in the room, in a sentence the BA nods at and moves past. Or they belong to someone who was never invited. Or they sit in a spreadsheet a stakeholder mentions in passing and nobody asks to see.
Experienced BAs miss requirements too. The difference is that they miss fewer of the obvious ones, because they have been burned by each pattern at least once. This article is an attempt to give you those burns second-hand.
Below is one realistic requirements workshop, written the way a first-time BA actually runs it. It reads fine on the surface. Then we go through it line by line and flag nine requirements that walked out of the room undiscovered, two things the BA said that cost trust, and one requirement that showed up two weeks later. Each one comes with the question that would have caught it. Then the same workshop is rerun properly, and there is a pre-session checklist you can download and use before your next session, real or simulated.
The project
Meridian Home is a mid-size online retailer selling furniture and home goods across the EU. Returns are handled in the order management system, but the returns module is old, slow and, according to the operations director, "the reason we have a backlog every Monday". The project is to replace it.
Alex is the BA. First project after a career switch, three weeks in. Alex has read the project charter, has a rough understanding of the current system, and has booked a 60-minute workshop with three people:
- Dana, returns team lead. Her team approves or rejects return requests.
- Priya, finance controller. Refunds go through her.
- Tomas, warehouse supervisor. Returned items physically arrive at his dock.
Alex prepared an agenda with three items: current pain points, what the new module must do, priorities.
The workshop, as it happened
Alex: Thanks for coming. The goal today is to understand what the new returns module needs to do. Let's start with pain points. Dana, you deal with this most, what is the biggest problem right now?
Dana: The approval queue. Every return request lands in a queue and someone on my team has to open it, look at the order, look at the reason, and click approve or reject. On Mondays we have 300 in the queue. We need a button that auto-approves anything under 50 euro.
Alex: Auto-approve under 50 euro. Got it. That should be easy enough to build. So the current approval screen is the main problem, right?
Dana: Yes, mostly. And the search. If a customer calls and gives their name, we cannot find the return, we need the order number.
Alex: Search by customer name. Noted. Priya, from the finance side?
Priya: For us it is timing. Refunds go out after we have checked the item. But the system marks the return as complete when Dana's team approves it, so my reports show refunds as done when they are not. I spend Friday afternoons reconciling.
Alex: So the status should reflect the refund, not the approval. Makes sense. We will make sure that is in there.
Priya: That would help a lot.
Alex: Tomas, anything from the warehouse?
Tomas: It is fine mostly. The label sometimes does not scan.
Alex: Okay, we can look at the label format. Dana, going back to the queue, what would the ideal flow look like for your team?
Dana: Honestly, request comes in, if it is under the threshold it just goes through, if not it goes to a person. And I check my sheet for anything that looks like a carrier issue, but that is separate.
Alex: Perfect. So, to summarise what I have: auto-approval under 50 euro, search by customer name, refund status separate from approval status, and a label fix. Priorities?
Dana: Auto-approval first.
Priya: Status accuracy first.
Alex: We will figure that out. I will send the notes around this afternoon. Thanks everyone.
Fifty-two minutes. Four requirements captured. Everyone left feeling heard. If you have run a session like this and thought it went well, you are in the majority.
Here is what left the room with them.
Nine ways the requirement got away
1. The solution that arrived without its problem
"We need a button that auto-approves anything under 50 euro."
Dana brought a solution. Alex wrote it down as a requirement. This is the single most common way requirements go wrong: a stakeholder proposes a feature, the BA captures the feature, and the problem the feature was supposed to solve never gets stated.
Why does Dana want auto-approval? Throughput. Her team cannot clear 300 requests on a Monday. But the 50 euro threshold is not Dana's to decide. Finance sets it, because the threshold is a fraud exposure question, and Priya was sitting right there. Nobody asked her. And "under 50 euro" hides a second question: is that the item value, the order value, or the refund amount after shipping? Three different numbers.
The question that catches it: "What happens today when a request under 50 euro is rejected? How often does that happen, and why?" If the answer is "almost never", auto-approval is a good idea and the threshold is a finance decision. If the answer is "about 10% of the time because of suspected abuse", the requirement is not auto-approval, it is a risk rule, and the feature changes shape entirely.
2. The assumption nobody questioned
Every person in that room used the word "return" to mean one thing: a customer sends back an order and gets their money back. Nobody said it, because it is obvious.
It is not. At Meridian, a return can be one item from a six-item order. It can be a request for exchange rather than refund. It can be a damaged-on-arrival claim where the customer keeps the item and gets a partial refund. Each of these has a different flow, a different financial treatment and, it turns out, a different approval rule.
Alex's four requirements all assume the simple case. The auto-approval rule, for instance, has no answer for "one item out of a 400 euro order, and the item is 30 euro".
The question that catches it: "When you say 'a return', what are the different kinds? Walk me through the one that is most annoying to handle." The word you think you understand is the one to define first. There is only one stupid question, and it is the one you did not ask because the answer seemed obvious.
3. The spreadsheet mentioned in passing
"And I check my sheet for anything that looks like a carrier issue, but that is separate."
That sentence contains an entire sub-process. Dana maintains a spreadsheet, outside the system, to track returns where the item was damaged in transit. Those returns trigger a claim against the carrier, which has its own deadline, its own evidence requirements and its own money coming back to Meridian. None of this exists in the returns module. The spreadsheet is the system.
Alex heard "but that is separate" and agreed. Stakeholders will always tell you their workaround is separate, because to them it is. It is the thing they do outside the system, so it does not feel like a system requirement. It is exactly a system requirement. Any time a stakeholder describes something they do in a spreadsheet, a notebook or their head, you have found a gap the current system left open.
The question that catches it: "Can you show me the sheet?" Then: "What would happen if it disappeared?" The second answer tells you how critical the sub-process is.
4. The stakeholder who was not invited
Three people were in the room. Who talks to the customer? Nobody. Customer service handles the return request from the customer's side: they explain the policy, they generate the label, they answer "where is my refund" calls. They also know the questions customers actually ask, which is where half the real requirements live.
Alex invited the people who process returns. Alex did not invite the people who receive them from customers, or the people whose rules govern them. Legal, for instance, owns the return policy text. IT owns the carrier integration that produces the label Tomas complains about.
Missing a stakeholder means missing every requirement that only they would have raised. It is the most expensive category, because you do not find out until testing, or until go-live.
The question that catches it, asked before the session: "Who touches a return between the customer clicking 'request return' and the money landing in their account? List every role." Then compare the list to the invitation.
5. The stakeholder who was invited and said nothing
"It is fine mostly. The label sometimes does not scan."
Tomas said eleven words in fifty-two minutes. Alex took that as "warehouse has no real requirements".
Here is what Tomas knows and did not say. Returned items cannot go back into sellable stock until someone checks them, and that check has a queue of its own. Furniture returns often arrive as partial shipments (two of three boxes), and the system has no state for "partially received". Some items cannot be restocked at all and go to a clearance channel that is tracked, again, in a spreadsheet. And the label problem is not cosmetic: when it does not scan, the item sits on the dock unmatched for days, which is why Priya's refund timing is off in the first place.
Tomas did not say any of this because nobody asked him a specific question, because the conversation was about screens and queues he does not use, and because he is not the kind of person who competes for airtime in a meeting with the finance controller.
The question that catches it: Directed, specific, and about his work: "Tomas, walk me through what happens from the moment a returned box hits the dock to the moment the item is back on a shelf." A quiet stakeholder is not an empty stakeholder. If someone contributes nothing, either ask them something they alone can answer, or find out why they were invited.
6. Scope meant three different things
Ask each person in that room what the project is, and you get three answers. Dana: a better approval workflow. Priya: accurate refund accounting. Tomas: receiving and restocking. Alex's project charter says "replace the returns module", which all three read as confirming their version.
The requirement that fell into the gap: refund timing. Priya wants the status to reflect the refund. But who triggers the refund, and when? Today, finance runs a batch on Thursdays. Should the new module trigger refunds automatically once Tomas's check passes? That requires an integration with the accounting system that nobody in the room owns, and it sits between Priya's scope and Tomas's scope, in territory both assume belongs to the other.
The question that catches it: "If this project succeeds, what will be different for you personally in six months?" Ask each stakeholder. The differences between their answers are your scope boundaries, and the gaps between them are where the missing requirements are.
7. The leading question
"So the current approval screen is the main problem, right?"
Alex had already decided what the problem was and asked Dana to confirm it. Dana said yes. Of course she did. The question told her what answer was expected, and the approval screen is a real problem, so agreeing cost her nothing.
What Alex did not learn: whether the approval screen is the main problem or just the most visible one. The Monday backlog might be caused by weekend request volume, by a slow carrier integration, by Tomas's unscanned labels, or by the approval screen. Dana's answer did not distinguish between them.
The question that catches it: The same question with the answer removed. "What do you think causes the Monday backlog?" If Dana says the approval screen, you have learned something. If she says "honestly, half of it is the labels", you have learned something bigger.
8. The follow-up that was never asked
"Refunds go out after we have checked the item."
Alex nodded and moved to the next person. That sentence deserved five more minutes.
Checked for what? Condition, completeness, matching the original order. Checked by whom? Tomas's team, which Tomas did not mention because the question was not put to him. How long does the check take? Two to nine days depending on the item. What happens when the check fails? A partial refund with a restocking deduction, and the customer has to be told, and the deduction rules live in a policy document Alex has never seen.
Every one of those is a requirement. All of them were one follow-up question away.
The question that catches it: Any of "checked how?", "by whom?", "how long?", "and if it fails?". The rule is simple: when a stakeholder describes a step in one sentence, that sentence is a compressed process. Decompress it before moving on.
9. The constraint with no owner in the room
Meridian sells across the EU. Under EU consumer law, when a customer withdraws from an online purchase, the refund has to be issued within 14 days of the retailer being notified, or of receiving the goods, depending on the setup. Nobody in the workshop mentioned this. Dana assumes finance handles it. Priya assumes the system enforces it. It does not. Meridian is currently compliant by accident, because Priya's Thursday batch happens to fall inside the window most of the time.
Non-functional and regulatory constraints are missed for one structural reason: they do not belong to a user. No one's daily job is "make sure we refund within 14 days", so no one raises it as a pain point. The same is true of data retention, audit logging, performance under Monday load, and accessibility.
The question that catches it: "What rules does this process have to follow that none of you wrote?" Then find out who did write them, and talk to that person.
Two things Alex said that cost trust
Missed requirements are recoverable. Trust is harder.
"That should be easy enough to build." Alex is not the developer, has not seen the codebase, and does not know that the approval rules are hard-coded in a stored procedure written in 2016. When auto-approval turns out to take three sprints, Dana will remember that the BA said it was easy, and she will discount the next estimate she hears. Never size a requirement in an elicitation session. Your job in that room is to understand, not to commit.
"We will make sure that is in there." Priya heard a promise. Alex meant "I have written it down". When the refund status change is deprioritised in favour of auto-approval, Priya will feel misled, and she will be less forthcoming in the next session, because forthcoming did not get her anything last time.
Both are the same mistake: letting the discovery conversation slide into a planning conversation. The fix is a sentence you can say every time: "I am capturing that, and I am not in a position to promise it yet. Prioritisation happens after we have the full picture." It feels less friendly. It is more honest, and stakeholders respect it.
Two weeks later
Alex has written the requirements document. Twenty-two requirements, reviewed, nearly signed off. Then Dana mentions, in a corridor, that about 30% of returns are actually exchange requests, and the customer wants a different size or colour rather than money back.
Exchanges are not in the document anywhere. They touch approval, stock allocation, shipping, and refunds of the price difference. Adding them means reopening a document that was about to be approved.
The temptation at this moment is enormous: "Let's park exchanges for phase two." That sentence is how a 30% use case becomes a go-live incident. Information that arrives late is still information. It is more expensive to act on now than it would have been two weeks ago, and it is far cheaper than acting on it after launch.
What to do: Write it up the same day. Flag it as a scope change with an estimated impact. Let the sponsor decide whether it is in or out, with the numbers in front of them. Your job is to make sure the decision is made consciously, not by omission.
The same workshop, rerun
Not the whole thing, just the moments that changed.
Alex: Before pain points, one question each. If this project succeeds, what is different for you in six months? Dana?
Dana: My team clears the queue by Monday lunchtime instead of Wednesday.
Priya: I do not reconcile on Fridays. The refund status is true.
Tomas: Returned boxes do not sit on the dock unmatched. Right now some sit for a week.
Alex: Tomas, that is the first I have heard of that. Walk me through what happens from the box arriving to the item being back on a shelf.
Tomas talks for eight minutes. Partial receipts, the condition check, the clearance channel, the label scanning failures. Alex asks who owns the condition check rules. Tomas says "there is a document, warehouse quality, Sofia wrote it". Sofia is now on the stakeholder list.
Alex: Dana, you mentioned auto-approval under 50 euro. What happens today when a request under 50 is rejected?
Dana: It is rare. Maybe one in twenty. Usually a repeat customer we suspect is abusing the policy.
Alex: Priya, is the 50 euro threshold something finance has a view on?
Priya: We have never been asked. I would want to see the abuse numbers before agreeing to anything automatic.
Alex: So the requirement is not "auto-approve under 50", it is "approve low-risk requests without manual review", and the definition of low-risk needs the abuse data and finance sign-off. Is that fair?
Dana: That is fair.
Later:
Alex: Priya, you said refunds go out after the item is checked. Checked by whom, and how long does that take?
Priya: Tomas's team. Two days if it is a cushion. Nine if it is a sofa.
Alex: And when the check fails?
Priya: Partial refund. There is a deductions table in the returns policy.
Alex: Who owns that policy?
Priya: Legal. Marc.
Marc is now on the stakeholder list. So is customer service, after Alex asks who tells the customer about the deduction.
Alex: Last one. What rules does this process have to follow that none of you wrote?
Priya: The 14-day refund thing. We are fine, I think. The Thursday batch covers it.
Alex: Does the system enforce it, or does the batch?
Priya: ...the batch.
And when Dana mentions the sheet:
Alex: Can you show me the sheet?
She shares her screen. Alex now has the carrier claims process, the deadlines, and the evidence rules, and a fifth requirement area nobody had thought of as part of the project.
The rerun ran 70 minutes and captured 31 requirement candidates across six areas, plus four new stakeholders. It was harder to facilitate, and the summary at the end was messier. That is what discovery looks like when it works.
The pre-session checklist
Twenty questions to answer before you walk into any elicitation session. Ten are for you to answer in preparation. Ten are for you to ask in the room. Download the one-page PDF and use it for your next session, in a job or in a case simulation.
Before the session
- What is the business problem, in one sentence, and who told me?
- Who touches this process end to end? Is every one of them invited, represented, or consciously excluded?
- What is my understanding of the current process, and what am I least sure about?
- Which words in the project brief could mean different things to different people?
- What documents exist (policies, manuals, ticket logs, old specs) and have I read them?
- What rules apply that none of the stakeholders wrote (regulatory, legal, security, audit)?
- What is the one thing I expect to hear, and what would I do if I did not hear it?
- Does my agenda ask about problems before it asks about features?
- What will I say when someone asks "can you build that?"
- Who, on this list, is likely to say nothing unless directly asked?
In the room
- If this project succeeds, what is different for you in six months?
- When you say [key term], what are the different kinds?
- What happens today when [the proposed feature] would have made the wrong decision?
- Can you show me the sheet / the document / the screen?
- What would happen if that workaround disappeared tomorrow?
- [Quiet stakeholder], walk me through what happens from [start] to [end] in your area.
- Checked how, by whom, how long, and what if it fails?
- Who owns the rule you just described?
- What rules does this process have to follow that none of you wrote?
- What did we not talk about today that you expected we would?
Download the pre-session checklist (PDF)
What this looks like in practice
You cannot learn elicitation from a list. You learn it by running a session, discovering afterwards what you missed, and running the next one differently. The problem for career switchers is that the first real session comes with real consequences.
BAvolta's Case Lab exists to give you the missed requirement without the go-live incident. You read stakeholder messages, run the discovery, produce the requirements, and get structured feedback on what you caught and what walked out of the room. The use case and portfolio project posts show the artifacts that come out the other end. The elicitation techniques post covers which technique to use when. This one is about the questions, whichever technique you are inside.
Frequently Asked Questions
What is the most common reason business analysts miss requirements?
Capturing a stakeholder's proposed solution as a requirement without asking what problem it solves. The problem is what tells you whether the solution is right, and it is usually never stated.
How do you find requirements that stakeholders do not mention?
Ask to see any spreadsheet, document or workaround they mention in passing, ask quiet stakeholders a specific question about their own work, and ask what rules the process must follow that none of them wrote.
Should a BA ever say "that should be easy" in a requirements session?
No. Sizing belongs to the delivery team after analysis. Saying it in elicitation turns a discovery conversation into a commitment the BA cannot keep.
What do you do when a requirement surfaces late in the project?
Write it up the same day with an impact estimate and put the in-or-out decision in front of the sponsor. Deferring it silently to phase two is how it becomes a go-live incident.
How many stakeholders should be in a requirements workshop?
Three to eight, and every person who touches the process end to end should be either present, represented, or consciously excluded with a note saying why.
Can you practise elicitation without a BA job?
Yes. Case simulations that give you stakeholder messages and score what you caught and what you missed cover the same failure patterns, without the consequences.
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, artifacts you can showcase in your portfolio. Try the free module.