How AI Changes Requirements Discovery and What Analysts Own

What discovery is, and where AI enters

Discovery is the early part of a project in which you find out what the people affected actually need, what limits the solution must respect, and what nobody yet knows. The International Institute of Business Analysis (IIBA) groups the related work under a knowledge area called Elicitation and Collaboration: obtaining information from stakeholders, confirming the results, and communicating what was gathered. A stakeholder is anyone who is affected by the work or can affect it, from the customer to the person who signs the budget.

The word requirement has a precise meaning. ISO/IEC/IEEE 29148, the international standard for requirements engineering, defines a requirement as a statement that translates or expresses a need and its associated constraints and conditions. Notice what that definition assumes. A requirement starts from a need held by someone, not from a sentence that sounds like a good idea.

That is the first thing to understand about AI in discovery. A language model is very good at producing sentences that sound like requirements. It is not a stakeholder, it has no needs of its own in your project, and it was not in your interview. So the question for an analyst is not "can AI do discovery?" but "which parts of discovery are drafting, which parts are judgement, and where is the line?"

What AI genuinely helps with

Used carefully, AI saves real time on the parts of discovery that are about text. Four tasks are worth delegating.

Interview preparation. Give the model your problem statement and the role of the person you are about to meet, and ask for open, non-leading questions. You will discard some, but a list of twenty candidates is a quicker start than a blank page. Ask it to flag any question that suggests an answer ("Wouldn't a mobile app help?") so that you can reword it.

Cleaning and structuring notes. Raw notes and transcripts are messy. A model can number the lines, mark where the speaker changes, and list candidate statements for you to sort. Line numbers matter, because they let someone else check what you cite.

First-draft summaries. Given a set of transcripts, a model can produce a readable synthesis in minutes. Treat it as a draft that has not yet been checked, never as the finding.

Finding gaps and conflicts. Ask the model to compare two documents, or two interviews, and list statements that disagree or topics that one source covers and the other does not. It is a useful second reader. It will also miss things and flag things that are not real conflicts, so you read the sources behind every item it raises.

Model providers publish guidance for these tasks, and the common advice is consistent. Anthropic's documentation on reducing hallucinations recommends giving the model explicit permission to say it does not know, asking it to extract word-for-word quotes before answering, and having it cite a quote for each claim and retract any claim it cannot support. It also states plainly that such techniques significantly reduce hallucinations but do not eliminate them, and that critical information must still be validated. Its prompting guide adds practical points: put long documents at the top of the prompt and label each document with its source. Everything that follows in this guide is, in effect, a way of applying that advice in a requirements setting.

What AI cannot do

Be honest about the limits, because they determine where you put your effort.

• It cannot know what was meant. It reads the words. It does not see the hesitation, the eye-roll or the thing the stakeholder said in the corridor afterwards.
• It cannot ask the next question. A good interviewer notices an unexpected answer and follows it. A summary tool processes what it is given.
• It cannot tell a rule from an opinion. "Late claims are always rejected" reads the same whether it is written in an approved policy or said by one person who believes it. Only a document, or the owner of the rule, can settle that.
• It cannot be accountable. It cannot own a decision, be asked to explain one later, or be blamed for one. People can.
• It has no access to your unwritten context. Politics, history and the reason a workaround exists are rarely in any document you can supply.

The NIST Generative AI Profile (NIST AI 600-1, 2024), part of the United States government's AI risk management work, gives the underlying reason. It defines confabulation as the production of confidently stated but erroneous or false content, and explains that it is a natural result of how generative models work: they produce output that approximates the statistical patterns of their training data, which can be accurate but can also be wrong. It notes that the risk arises when users believe false content because of its confident tone. The same document warns that a model can produce logical steps or citations that appear to justify an answer even when the answer is wrong. For an analyst, that last point matters: an invented requirement can arrive with a convincing reference attached.

What stays with the analyst

Five responsibilities do not move, however good the tool becomes.

• 5responsibilities that stay with the analyst
• 3questions every line must answer

The standard draws a useful distinction here. ISO/IEC/IEEE 29148 defines requirements validation as confirmation that the requirements define the right system as the stakeholders intend, and requirements verification as confirmation that they are well formed. An AI can help with a part of verification, such as spotting vague wording. Validation is a conversation with the people who hold the need, and it is yours.

The three questions in the card above are the working form of those responsibilities. For every line in an AI-produced summary, ask:

1. Who said it? A named role, a transcript, a line number.
2. Where is it written? A document, a version, a section.
3. Who owns the decision? The person who can say yes or no to it.

A line that cannot answer all three is not a requirement yet. It is a question, and it belongs in your open-questions log with an owner.

How AI-assisted discovery goes wrong

1. The plausible requirement nobody stated. Asked to summarise interviews for a new system, a model may add "customers want real-time notifications" because that is what such systems usually have. It reads naturally and nobody objects. The OWASP list of risks for LLM applications describes this as misinformation: output that sounds credible but is unfounded, made worse by people trusting it without checking. NIST names the human side of the same problem automation bias, meaning excessive deference to automated systems.

2. Lost nuance. A stakeholder says, "We usually do this by phone, but only when the customer asks." The summary says, "The process is done by phone." The qualifiers carried the meaning, and the summary dropped them. Summaries compress, and compression chooses what to lose. Whenever a qualifier changes what the business must do, check that it survived.

3. Unattributed or inflated claims. One interviewee's view becomes "stakeholders believe". One customer's experience becomes "customers prefer". A forecast ("this will halve our calls") becomes a fact. The fix is attribution at the level of the line, plus a habit of counting voices before generalising.

4. Personal data in the transcript. An interview recording is personal data as soon as it contains an identifiable person. India's Digital Personal Data Protection Act, 2023, defines personal data as any data about an individual who is identifiable by or in relation to that data. A name alongside a job role will often be enough to identify someone. NIST's Generative AI Profile lists leakage and unauthorised use or disclosure of personal information as a data privacy risk, and OWASP lists sensitive information disclosure among its top risks for LLM applications. Our guide to using AI safely at work covers the habits in more detail; in discovery, the minimum is to remove names, contact details and reference numbers before a transcript is shared, and to use only a tool your organisation has approved for that kind of material. What is permitted is a decision for whoever owns data protection in your organisation, not for the tool or its vendor.

A fifth, quieter problem is a solution posing as a need. "The system must have a dashboard" describes a design. The need underneath might be "the supervisor must know by 10 a.m. which cases are overdue". Models tend to write requirements in the vocabulary of solutions, because most requirement documents they have seen do. When you see a noun such as a screen, a bot or a dashboard in a requirement, ask what it would let someone do.

An illustrative example

Suppose a team is replacing the way a retailer handles refund requests. They interview three people: a store manager, a customer-service agent and a finance clerk. The AI summary includes this line: "Customers expect instant refunds, and the new system must refund within one hour."

Applying the three questions:

• Who said it? The transcript shows the customer-service agent saying that customers are "annoyed at waiting". Nobody said "instant", and nobody said "one hour".
• Where is it written? No policy document mentions a refund time. The "one hour" is the model's invention.
• Who owns the decision? A refund time is a business rule, so it belongs to whoever owns the refund policy, perhaps a finance lead. The analyst does not choose it, and the model certainly does not.

The corrected record keeps the real pain point, attributed to the agent, and moves the target time into the open-questions log with the finance lead's name beside it. That small edit is the whole discipline: the summary becomes a set of checkable claims and a list of questions.

A discovery workflow with AI

This is a workable sequence. It keeps AI where it is strong and keeps the checks with you.

1. 1FrameWrite the problem statement and the questions you must answer, before any tool is involved
2. 2PrepareDraft interview questions with AI, then remove leading ones and add your own
3. 3InterviewRun the conversation yourself, with consent and a clear purpose
4. 4ProtectRemove identifiers, number the lines, and use only an approved tool
5. 5DraftAsk for a summary from the supplied sources only, with a quote for each claim
6. 6CheckVerify every quote against the transcript and tag each claim
7. 7ConfirmTake open questions and the checked summary back to the named owners

1. Frame the problem first. Who is affected, what happens today, what is the impact, and what is the evidence? Doing this before you open an AI tool stops the tool setting the agenda.
2. Prepare with AI, then edit. Ask for non-leading questions for each stakeholder type. Delete anything that proposes a solution.
3. Run the interview yourself. Say why you are recording, get consent, and follow up on surprises. This is the part with no substitute.
4. Protect the data. Remove identifiers, mark any translation, number the lines, and confirm the tool is approved for this material.
5. Draft from sources only. A prompt that works well is explicit about its boundaries:

Use only the numbered transcripts below. For each point in the summary, give the speaker and line number and a verbatim quote. If a point is not supported by a quote, write NOT PROVIDED instead of guessing. Keep a separate list of anything that sounds like a rule, and say who said it.

6. Check and tag. Open each cited line and read it. Tag each claim as supported (the source says it), unsupported (no source says it) or assumption (a belief or forecast, however confidently written). Delete or rewrite anything unsupported.
7. Confirm with owners. Take the checked summary back to the stakeholders, and put every unresolved item in the open-questions log with a named owner. Record what AI contributed and who reviewed it, so that a reviewer later can see how the document was made.

Notice what the workflow does not contain: a step in which AI decides what the project needs.

A short checklist for AI-assisted discovery

• Did I say what I was looking for before I opened the tool?
• Did the model see only material I am allowed to share?
• Does every claim carry a speaker, a line and a quote?
• Did I open the quotes and read them, rather than trusting the format?
• Are opinions, forecasts and design ideas tagged as such, not promoted to needs?
• Is every rule matched to a document or a named owner?
• Does the open-questions log have an owner against each item?
• Does the record say that AI helped, and who checked the result?

How we practise this

In our AI-Augmented Business Analysis course, the first week works on exactly this skill: separating what people said from what an AI inferred, and keeping a source for every line. The same habit carries through the later weeks, which cover turning checked discovery material into stories, rules and a sign-off pack. If you are ready to take the next step from discovery into writing, our guide to user stories and acceptance criteria with AI drafts shows how to review a draft story against its source.

Sources and further reading

• IIBA (online edition), The Business Analysis Standard, 5.3 Business Analysis Knowledge Areas
• ISO/IEC/IEEE (2018), 29148:2018 Systems and software engineering, Life cycle processes, Requirements engineering
• ISO/IEC/IEEE (2018), 29148:2018 publisher preview, section 3 definitions of requirement, elicitation, validation and verification
• NIST (2024), AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
• OWASP GenAI Security Project (2025), LLM09:2025 Misinformation and the Top 10 for LLM Applications
• Anthropic, Reduce hallucinations and Prompting best practices
• Government of India (2023), The Digital Personal Data Protection Act, 2023 (No. 22 of 2023)