The Business Analyst Who Tried to Use Intelligence in the Age of AI
Key Takeaways
- AI can optimize the wrong thing: When tools reward structure and completeness over clarity, they can reinforce bad requirements instead of improving them
- Clarity beats completeness: The best requirements say exactly what’s needed—no more, no less—especially for technical audiences
- Know your audience, not just the template: What developers, testers, and stakeholders need to see is different, and AI doesn’t always get that right
- Interrogate the tool as well as your output: Understanding how an AI tool asks questions, structures responses, and pulls context is key to using it effectively
- Good judgment can’t be automated: AI can assist, but deciding what matters, what’s relevant, and what’s usable still depends on the analyst
Disclaimer: The views and opinions expressed in this article are those of the author and may not reflect the perspectives of IIBA.
This article is part of AI Wednesdays, an ongoing 2026 series that explores how business analysis professionals are using AI in real, practical ways. Each article is written by a practitioner and shares experience-based insights to help you use AI with greater confidence—starting small, building familiarity over time, and applying it where it adds real value.
Once upon a time, a business analysis professional was happily writing requirements at work when AI came to town. She, along with other business analysis professionals on her team, was told that she must enter her requirements into a new AI tool that would score their work. This new AI tool would provide feedback and rewrite requirements based on responses to iterative questions until it finally “passed” them.
The score was based on “success metrics” and ranged from 1 (worst) to 10 (best). The business analysis professionals were then told that scores lower than 8 would not pass, and that these requirements would be deemed unacceptable for submission.
Now, as you can imagine, all the professionals were in quite a panic. They wrote their requirements and waited anxiously as the AI tool scored their work. They answered question after question after question in hopes of getting a perfect 10.
After multiple iterations, they finally settled for the minimum passing grade, just so they could get on with their jobs and their day.
But one business analysis professional was troubled by this new way of working. As she saw it, the focus centred on AI functionality and scores—not actual requirements. The requirement as a “usable representation of a need” was getting lost in the glare of this shiny new tool.
And the professional’s work was now being validated based on AI metrics rather than usability.
What Makes a Requirement Actually Useful
If a business analysis professional is writing requirements specifically for a JAVA development team to add one new field, for example, the usable aspect of the requirement should be a priority. This can easily be forgotten when drowning in AI algorithms that aren’t specifically tailored to your target audience.
Developers and testers shouldn’t have to sift through a maze of AI-generated slop to determine what they need to code and test. Do they really need to read three paragraphs about the history of a bank regulation that prompted that field update? The answer is no.
Time and time again, this business analysis professional lamented how this particular use of AI was negatively impacting standard core business analysis principles. In her opinion, they were missing the mark, and it was causing more work for everyone, especially the business analysis professionals.
So, what did she do when her protests and concerns were ignored? She did what business analysis professionals do best. She submitted a business case to a JAVA development team to make her point!
An Experiment in AI Gone Wrong
Using the shiny new AI tool, she submitted the following to illustrate that a good AI score does not equal a good requirement. (This is a true story.)
| Problem Submitted by the Business Analysis Professional | Original Score |
Wasting away again in Margaritaville Searching for my lost shaker of salt |
1/10 |
| AI-Generated Questions and Her Responses | Score |
|
AI question: What does the “shaker of salt” represent in business terms? AI question: What is an alternative for the “shaker of salt?” AI question: Who is responsible for the “shaker of salt”? AI question: Who should be notified if the “shaker of salt” is not located? AI question: Who should communicate the status of “shaker of salt”? |
Pending |
| AI’s Revised Description | Updated Score |
|
Current state: While in Margaritaville, the user cannot find their saltshaker, leading to frustration and a diminished experience. Future state: While in Margaritaville, a seagull will notify the business analysis professional of the saltshaker’s location. The business analysis professional is responsible for making the saltshaker accessible to the user. The user’s experience is considered restored when they receive salt and can season the food. |
8.2/10 |
As you can see, the business analysis professional used the AI tool to get from the low score of 1 to a passing score of 8.2 by writing requirements that are 100% unusable!
After a few laughs (and senior management snarls), everyone got the point. Moreover, the business analysis professional’s display of weaponized sarcasm also had an unintended side effect: she learned a bit about how this AI tool was designed.
It was clearly technology-specific (i.e., user-based) and followed broad business analysis formats (business objective, current state, and future state). It also had repeatable patterns of questioning, reorganization, and summarization (business problem, solution, ownership, alternate flow). The fact that this AI knew that salt was used to “season the food” was, in this professional’s opinion, another one of life’s mysteries never to be understood or solved.
Back to Basics: Writing Better Requirements With AI
The business analysis professional was then asked to join an AI pilot team to help work with the AI developers and other business analysis professionals to see what made sense. In time, integration with AI became less overwhelming and more deliberate and focused.
For example, she learned how to write, manage, and validate her requirements in a way that would allow AI to provide value without adding negative impact and confusion. She learned that for very specific use cases, less is more. If she entered a lot of information, the AI would ask a lot of questions and generate a lot more information, most of which wasn’t usable.
As a result, this new way of working forced her to go back to basics by writing clear, concise requirements in smaller, more measurable increments to prevent AI from hijacking her work (and sanity).
Based on her experience, here are some key questions to ask when working with AI to develop requirements:
- Does the AI algorithm meet standardized business analysis criteria?
- Does it guide you to determine the specific need, change, and solution?
- What template is used to organize AI questions and summaries?
- Does it pull in context that may or may not be useful to your audience? For example:
- Does a developer need to know about a compliance requirement?
- Does a senior manager need to review an XML code requirement?
- Does it automatically pull in departmental, corporate, or industry jargon and acronyms?
- Is the algorithm too broad or too specific for your requirements?
- Does AI differentiate between requirement types—i.e., business, data, or functional?
- Are some of the AI questions and generated text simply irrelevant?
- What’s the source of the AI database, and how does it iterate and expand?
- Is the AI tool specific to your line of business, or is it more generalized?
- Are the final AI-edited requirements and summaries clear, concise, and usable?
A Guide to the Business Analysis Body of Knowledge (BABOK Guide) states: “Changes occur within a context. The context is everything relevant to the change that is within the environment.” AI is not the context. AI is not the environment. AI is only one of many factors relevant to the change we need to make within a given environment.
Making AI Work for You, Not the Other Way Around
In summary, adding AI to the long list of challenges and opportunities we have encountered throughout our business analysis careers will surely enrich our overall skill sets and expertise. We should take the time to learn about the AI tools we’re using to see how they can enhance requirements in a thoughtful, useful, and focused way.
For example, build templates for different requirement types, such as functional vs. high-level. Create a repository of different examples to draw upon each time you need to write a specific type of requirement. Analyze and break down your requirements before you enter them into an AI tool. Taking the time to plan your overall requirements approach will prevent you from getting lost in an endless sea of AI questions, answers, and words.
As business analysis professionals, we must ensure that AI is aligned with our specialized skill sets and competencies. We can use our shared experiences as well as the vast wealth of knowledge imparted to us by organizations, communities, and resources so that AI works for us—not the other way around.
In the age of AI, it’s the business analysis professional’s responsibility to protect and defend the requirement at all costs. If we don’t, it will just be another lost shaker of salt…
Explore the BABOK Guide to strengthen how you apply insight, judgment, and tools like AI in your work.
Author’s note: Although AI was the inspiration for this article, it wasn’t used in any way, shape, or form to compose this article (except in the AI business case example). All text was generated solely by a human being striving to coexist peacefully with AI at work. The use of AI in her personal life, however, remains a constant struggle. This Generation X business analysis professional has yet to use self-checkout at any store and will walk out rather angrily if that’s the only option available.
About the Author
Diane Donnelly is a Certified Business Analyst Professional (CBAP) who has gained valuable experience executing technology and business initiatives in the financial services industry, including the support of mutual funds, annuities, and life insurance products. For over 25 years, she has implemented projects that placed a strong emphasis on the integration of technological solutions with product, legal, and regulatory requirements. Diane is currently employed as a Senior Business Analyst working for a large insurance company in the Tri-State area. She resides in upstate New York with her husband, dog, and 38-year-old pet turtle.
