The process map had everything on it except the notebook. Day three, mid-morning, and I only asked about the spiral pad sitting by the terminal because the clerk kept glancing at it while she was answering a completely different question, which in hindsight is the single reason I asked at all. Two-box orders, she said. The system prints one label. She writes the second one out by hand, and she has been writing it by hand since a release in 2019 that nobody ever went back and fixed.
Two weeks later I went through the sign-off package looking for any trace of it. Nothing. Eleven approvers, and not one of them was hiding anything, which took me a while to accept because my first reaction, honestly, was that somebody had held out on me. They had not. Any of them would have described the second label if I had asked about the second label, and none of them volunteered it, because something you have done every Tuesday for six years stops feeling like a decision and starts feeling like furniture. It never made a list. It was never going to. And it was the requirement that would have broken the release.
Which is why the phrase bothers me. We call this gathering, as though requirements were apples under a tree, already grown, already fallen, waiting on somebody with a basket and a free afternoon. Apples. That framing quietly sets the standard for done: you finish once you have picked up everything lying around, which means the list closes on a Friday because the workshops are over rather than because the questions ran out. The best analysts I have worked with across 25 years in enterprise software delivery do not behave like collectors. Not even slightly. They behave like investigators, and it shows in what they come back with. Which is the whole problem with AI requirements gathering: a faster collector is still a collector.
Why is "requirements gathering" the wrong phrase?
Because it assumes three things at once, and most of the requirements that decide a project break at least one of them. Assumption one: the requirement exists in finished form. Assumption two: somebody knows where it is. Assumption three: they will hand it over when asked. The notebook failed all three, and it failed them quietly, which is what makes this a problem about knowledge rather than a problem about diligence: no amount of asking harder in the same direction was going to produce it.
The research vocabulary is more honest than ours. In a controlled experiment published in June 2026, Manoel Salgado Neto, Alan Araujo and Ronnie de Souza Santos describe elicitation as stakeholders communicating needs, negotiating priorities and collaboratively constructing knowledge that then becomes an artifact. Constructing. Not locating. If the knowledge has to be built between people who each hold a fragment of it, then a process whose success metric is "we collected all the inputs" is measuring the wrong thing, and it will report success at exactly the moment it has stopped being useful.
For years I filed this under pedantry. Vocabulary policing. Then I watched what the word does to a calendar and changed my mind, because gathering gets budgeted the way logistics gets budgeted: two workshops, one survey, a sign-off, done. Nobody blocks four hours to sit beside somebody and watch them work. Watching is not collecting. There is no line for it in the plan, so it does not happen, and the one object in the building that knew about the second label never makes it into the room.
What is the difference between gathering and discovery?
Gathering collects what people can state. Discovery goes after what they cannot, which turns out to be a different activity end to end: different posture, different questions, and a completely different test for whether you are finished. The collected ones are real and you need them. Login works, report exports, tax rate configurable. They are also, word for word, the requirements the team at your competitor wrote down last quarter, from the same stakeholders, in the same kind of room. Same list.
Discovery lives in the gap between what people say they do and what they do. It shows up in exceptions. The workaround that has become routine, the field everyone fills with a placeholder, the report somebody rebuilds by hand every month because the real one is subtly wrong, the rule that only fires when a customer moves provinces mid-cycle. Ask an experienced analyst what they actually do and they will describe something closer to an audit than an interview: they chase every anomaly back to its origin and ask when it was last true.
| Gathering | Discovery | |
|---|---|---|
| What it asks | What do you need the system to do? | Why does that exception exist, and when was it last true? |
| Where it looks | Stakeholders who were invited to the workshop | The work itself, the exceptions, the people nobody invited |
| When it is finished | When the list stops growing | When the questions stop producing surprises |
| What it produces | The requirements everyone already knew | The requirements nobody thought to state |
| Who can do it | Anyone, including a language model, quickly | Whoever is willing to sit with the work and stay curious |
There is a second reason the distinction matters, and it is commercial rather than philosophical. Anything that can be gathered can be gathered by anyone. The requirements nobody states are the only ones that carry information your competitors do not have, which makes discovery capacity a durable advantage and gathering capacity a commodity that a language model now performs for the price of a subscription.
What does AI requirements gathering actually speed up, and what does it miss?
AI requirements gathering speeds up everything downstream of the conversation, and it is very good at that. Transcription, structuring, deduplication, turning ninety minutes of circular discussion into a formatted specification with traceable identifiers: a model does that in seconds, without getting tired at 4pm, and I would not go back. The trouble starts when a tool that makes collecting cheap gets treated as evidence that collecting was the hard part.
A team led from Peking University put a number on the gap this May. They built an interview agent that questions along an explicit ontology of requirement concerns, and benchmarked it against free-form language model interviewing on 101 website elicitation scenarios. The baseline, a state-of-the-art model asked to conduct the interview on its own, surfaced 13% of the ground-truth implicit requirements. The same model, questioning with structure, reached 69%.
Sit with the shape of that result rather than the number. Capability was held constant. What moved coverage from 13% to 69% was not a smarter model but a rule about which question comes next, which is precisely the thing a senior analyst carries in their head and a junior one does not. The authors say it plainly: relying on free-form chat alone struggles to systematically uncover implicit requirements. Their word is systematically, and it is doing real work in that sentence, because free-form chat does find implicit requirements occasionally, in the way that wandering a forest occasionally finds mushrooms.
Two caveats, because I would rather you trust the argument than the number. This is a benchmark of website scenarios with a known ground truth, not a study of live projects with real stakeholders, and a real interview has social dynamics no benchmark models. Also, 69% is not 100%, and the honest reading is that even a well-structured agent misses roughly a third of what the benchmark authors considered discoverable. Structure helps enormously. It does not close the gap.
Small sample, and I flag that rather than lean on it. Still, the ordering is worth noticing: the best artifact came from the model that was handed a human conversation, and the model working alone from a tidy problem statement lost to it on completeness. Discussion first. Synthesis after. That is the sequence automated requirements analysis also assumes and rarely gets, since a tool that grades your specification is only as useful as the discovery that produced the specification in the first place.
How does discovery-first change what you build?
Discovery-first changes the product, not just the document. When you gather, you build what the room asked for, which is usually a faster version of what already exists. When you discover, you occasionally find that the thing people are doing bears no resemblance to the thing everyone assumed they were doing, and that finding does not refine a roadmap so much as rewrite it.
Intuit built Quicken for households. Then the survey data got strange: buyers were running personal finance software in an office rather than at home, which was not what anyone had designed for and not what any customer had requested.
Scott Cook went and talked to them. They were using it for bookkeeping, at work, on purpose. The assumption inside the company had been that every business used accounting software. Cook's summary of what he found instead is four words long: "No, they hate accounting."
Nobody had gathered that requirement, because no small business owner was going to walk into a workshop and say "I want accounting software with no accounting in it." That sentence only exists after somebody watches the behaviour and reasons backwards from it. Intuit shipped QuickBooks in 1992 on exactly that positioning, in Cook's words the first accounting software with no accounting in it, and by his account it outsold the competition within two months.
Source: Wisconsin School of Business, "Savor Surprises: A Conversation with Intuit Co-founder Scott Cook", May 23, 2022, for Cook's first-hand account of the discovery, the quote, and the two-month sales claim, which is his own recollection rather than an audited figure. Industry: small business accounting software.
Three habits get you most of the way there, and none of them require a tool. Watch first. Watch the work before asking about it, because people describe the process they believe they follow rather than the one they run. Treat every exception as an unopened box: ask who created it, when, and whether the condition that caused it is still true. Then put reviewers with genuinely different jobs on the same source material, which is the argument behind multi-agent business analysis and the reason a single reviewer, human or model, tends to inherit the blind spot that made the gap.
Then use the model. Aggressively, for everything it is good at: structuring the mess, spotting contradictions between two transcripts, drafting the acceptance criteria, checking the specification against a coverage checklist. That is real leverage and it is available today. The failure mode is not using AI for elicitation. It is letting a fast collector define what counts as finished, and shipping on the strength of a list that closed before the notebook on the desk was ever mentioned.
Requirements are not collected. They are constructed, and the useful ones resist.
Gathering assumes the requirement exists, that somebody knows where it is, and that they will hand it over when asked. The requirements that decide a project fail those assumptions silently: they live as habit rather than knowledge, so nobody withholds them and nobody states them either. Renaming the activity is not cosmetic, because the name sets the standard for done.
The measured version of that gap: on a 101-scenario elicitation benchmark, a state-of-the-art model running the interview on its own surfaced 13% of the ground-truth implicit requirements, while the same model questioning along an explicit structure of concerns reached 69%. Capability was constant. Only the discipline of the questioning changed. Use AI for what follows the conversation, and keep ownership of which conversation happens, because that is the requirements intelligence layer nothing downstream can reconstruct.
What are the most common questions about AI requirements gathering versus discovery?
