What You Are Actually Trying to Do
You have a requirements workshop coming up, or you are mid-elicitation on a project and the conversation keeps going in circles. You have heard that AI assistants can help with requirements gathering, and you are wondering whether that means something useful or just faster drafting of things you could already write yourself. That is the right question to be asking.
In my experience, most BAs who start using AI tools for requirements work fall into the same trap early on. They use the assistant to generate a draft user story or a BRD section, feel mildly impressed, and then quietly conclude that it saved them twenty minutes of typing. That is not requirements gathering support. That is document production. The two are very different things, and an AI assistant built for business analysts should be doing much more than the latter.
Where AI Assistants Actually Help in Requirements Gathering
Let me be specific about where I have found genuine value, because the use cases are narrower than the marketing suggests but more useful than the sceptics admit.
Pre-Workshop Preparation
Before I sit down with stakeholders, I use an AI assistant to stress-test my question set. I describe the project context, the stakeholder group, and the goals of the session, then ask the assistant what questions I am likely forgetting. This is particularly useful for identifying gaps in non-functional requirements, regulatory constraints, and edge cases that tend to get skipped in early conversations. The assistant does not know the business, but it does know the shape of the problem well enough to flag categories I have not covered.
If you want a structured starting point for this, the requirements elicitation questions resource on this site gives you a solid base to work from before you layer in AI support.
Generating Competing Interpretations
One of the most underused AI prompts in requirements work is: “Give me three different ways a stakeholder might interpret this requirement.” When I paste in a raw statement from a workshop and ask an AI assistant to surface ambiguity, it consistently catches things that I have mentally resolved without realising it. That is useful. It forces me to go back and confirm which interpretation is correct rather than assuming I already know.
Producing a First-Pass Traceability Map
If I give an AI assistant a set of business objectives and a list of requirements, it can produce a rough first-pass traceability map that I then review and correct. It is not reliable enough to trust without checking, but it gives me something to react to rather than starting from a blank page. I always verify the links, but the structure it produces saves me the scaffolding time.
Drafting Requirements for Review, Not for Approval
This is the use case most BAs already know about, but the important framing is for review, not for approval. I use AI-generated requirements drafts as a starting point for conversation with stakeholders, not as finished artefacts. When I hand a stakeholder a draft and ask them to tell me what is wrong with it, I get far more useful feedback than when I ask them an open question about what they need.
A Worked Example: Where It Helped and Where It Did Not
On a recent project for Organisation B, a public sector agency consolidating over 30 separate online service touchpoints into a single citizen-facing portal, I was brought in partway through the discovery phase. The project team had already run two rounds of stakeholder workshops but kept getting conflicting priorities from different agency leads. Each agency believed their service group was most important to the end user, and nobody had the data to settle the argument.
I used an AI assistant to help me build a pre-workshop briefing document that reframed the conversation. Instead of asking stakeholders to rank their own services, I asked the assistant to help me draft scenario-based questions that described a citizen’s journey across multiple services. The assistant generated twelve scenarios in about eight minutes. I used four of them, revised two substantially, and discarded the rest. That was still faster than writing them from scratch.
The friction came when one senior agency lead pushed back hard on the workshop design. She felt the scenarios were artificially simple and did not reflect the complexity of her agency’s service obligations. She was right. The AI-generated scenarios were clean and logical but they had flattened real-world messiness. I had to go back and redesign three of the scenarios with her input, which added a day to the preparation cycle. The lesson: AI is good at generating plausible scenarios, but plausible is not the same as accurate, and accuracy matters when the stakeholder has twenty years of domain knowledge and is watching for shortcuts.
The project is directly comparable to the kind of cross-agency consolidation work described in large-scale government digital transformation programmes, where the challenge is not writing requirements but getting competing stakeholders to agree on what the citizen actually needs. No AI assistant solves that problem. You still have to do the political work.
Where AI Assistants Still Fall Short
Here is an honest account of the limitations I have run into repeatedly.
- It cannot read the room. Requirements gathering is as much about observing what stakeholders do not say as what they do. An AI assistant working from a transcript or a set of notes misses body language, hesitation, the subject that gets changed too quickly. That interpretive layer is entirely yours.
- It does not know your organisation’s politics. On the project above, I knew which agency leads had blocked previous consolidation attempts and why. That shaped every question I asked. An AI assistant has none of that context unless you build it in explicitly, and even then it cannot weigh it the way you can.
- It hallucinates plausible requirements. If you ask an AI to generate a full requirements list for a given domain, it will produce one that looks comprehensive. Some of those requirements will be genuinely useful. Others will be technically coherent but completely irrelevant to your specific situation. Novice BAs are at real risk of treating the output as a checklist rather than a starting point.
- It cannot replace elicitation techniques. Structured workshops, interviews, observation, and document analysis are not things an AI assistant can do for you. It can help you prepare for them and process their outputs, but the core elicitation techniques still require a human being in the room.
- It struggles with conflicting requirements. When two stakeholders want incompatible things, the job is not to document both requirements and move on. It is to facilitate a resolution. AI assistants can help you articulate the conflict clearly, but they cannot negotiate it.
How to Compare AI Assistance Across Requirements Tasks
The table below reflects my actual experience using AI assistants across the main phases of requirements work. Your mileage will vary depending on the tool and how you prompt it, but this gives a realistic picture of where to invest your time.
| Requirements Task | AI Usefulness | Human Judgement Still Required |
|---|---|---|
| Pre-workshop question design | High | Domain-specific tailoring and political context |
| Surfacing ambiguity in existing requirements | High | Confirming which interpretation is correct with stakeholders |
| Drafting user stories and acceptance criteria | Medium-High | Validation against real business context |
| Generating first-pass traceability maps | Medium | Verification of all traced links |
| Facilitating stakeholder workshops | None | Entirely human-led |
| Resolving conflicting stakeholder priorities | Low | Negotiation, influence, and judgement |
| Identifying missing non-functional requirements | Medium-High | Context-specific applicability checks |
| Drafting full BRD or FRD sections | Medium | Accuracy, completeness, and stakeholder sign-off |
Getting the Most Out of AI in Your Requirements Process Right Now
If you want to start using an AI assistant more effectively in requirements gathering today, here is what I would do first.
- Feed it your project context explicitly. Before you ask it anything, give it a paragraph describing the project, the stakeholders involved, the business problem, and the constraints. The quality of what it produces is directly proportional to the quality of what you put in.
- Use it to challenge your own thinking, not just to produce outputs. Ask it to argue against your proposed approach, identify risks in your requirements, or suggest what you might have missed. It is more useful as a thinking partner than as a drafter.
- Treat every AI output as a draft for review. Never send an AI-generated requirements document to a stakeholder without reading every line yourself. You are still accountable for the accuracy and completeness of what goes out under your name.
- Build a prompt library for your recurring tasks. If you regularly run kick-off workshops, write BRDs, or produce requirements for a particular domain, invest time in building prompts that work well for those tasks and reuse them. This is where AI starts to compound value over time.
The honest answer to whether an AI assistant will improve your requirements gathering is yes, but only if you use it to sharpen your analysis rather than to skip it. The BAs who get the most out of these tools are the ones who already know what good requirements look like and use AI to pressure-test, accelerate, and challenge their work. If you are still building that foundation, start there first, and let the AI be a useful second opinion rather than the first one.
Frequently asked questions
Can an AI assistant help with requirements gathering for a business analyst?
Yes, AI assistants can genuinely support requirements gathering by helping you prepare elicitation questions, surface ambiguity in existing requirements, and draft user stories or BRD sections for review. They work best as thinking partners rather than as replacements for the analytical and facilitation work you do with stakeholders. The output always needs human review before it goes anywhere near a stakeholder.
What are the best use cases for AI in business analysis requirements work?
The strongest use cases are pre-workshop preparation, identifying missing requirement categories, generating competing interpretations of ambiguous statements, and producing first-draft documents for review. AI is less useful for stakeholder facilitation, conflict resolution, and anything that requires deep domain knowledge or organisational political awareness. It is a tool for accelerating and sharpening your work, not for replacing the core analytical judgement.
Will AI replace business analysts in requirements gathering?
No, not in the foreseeable future. Requirements gathering depends on human skills including active listening, reading political dynamics, facilitating difficult conversations, and making judgement calls about conflicting priorities. AI can support the preparation and documentation side of this work, but the elicitation and negotiation elements remain entirely human-led. If anything, BAs who use AI well will be more effective than those who do not.
How do I use ChatGPT or another AI tool to help me write requirements?
Give the AI your full project context first, including the business problem, the stakeholders involved, and any constraints you are working within. Then ask it to draft requirements, generate questions, or surface ambiguity in what you already have. Always treat the output as a starting point for your own review and do not send anything to stakeholders without checking every line yourself.
What are the limitations of AI for business requirements gathering?
AI assistants cannot observe stakeholder behaviour, read organisational politics, or resolve conflicting priorities through negotiation. They can generate plausible-sounding requirements that are irrelevant to your specific situation, and they lack the domain knowledge to distinguish between technically correct and contextually appropriate. Human judgement, elicitation skill, and stakeholder relationships remain the core of effective requirements work.
Try Ash, Your Virtual BA
If you want to see what AI-assisted requirements gathering actually looks like in practice, Ash is built specifically for business analysts. You can use Ash to stress-test your elicitation questions before a workshop, surface ambiguity in requirements you have already drafted, or get a structured starting point for your next BRD, all with the BA methodology baked in rather than bolted on. It is the difference between a generic AI tool and one that understands what you are actually trying to do. Try Ash Virtual BA.
Further reading
- IIBA’s KnowledgeHub’s AI Assistant | Business Analysis & The Power of Artificial Intelligence
- How Business Analysts Use AI to Improve Requirements, Elicitation, and Stakeholder Alignment | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.