Introduction
Business Analysts have always been taught to write SMART requirements. In the context of this article: Specific, Measurable and Testable requirements. We define what a system should do, document the business rules and describe how users interact with the solution. Those principles have not changed.
However, as more and more organisations move toward building AI solutions, there comes a point where every team realises that the traditional way no longer hits the mark when it comes to AI requirements.
That realisation came after feedback from developers. They weren’t asking for more detail, but for completely different information. It became clear that two aspects of my traditional requirements approach needed to change.
- The ‘traditional way’ is missing something: AI solutions require the focus to be on user intent, context, business rules and constraints.
- And maybe some good news: The traditional way is potentially capturing too much. I will explain.
Traditional software versus AI-enabled software
Traditional software follows predefined logic.
If a user performs Action A, the system performs Result B.
We have always focused on documenting those rules and behaviours in detail because developers implemented the logic exactly as specified.
AI-enabled systems work differently.
Rather than programming every decision, we need to define the problem the AI is trying to solve, the outcomes we expect, the boundaries it must operate within and the situations where human judgement is still required.
The role of the Business Analyst shifts from documenting every possible path to ensuring the business intent is understood. I have tried using the traditional way for AI and there is only one outcome: Unless I can define every possible outcome that a non-deterministic solution might reach, I’m always going to miss something.
It is a game I cannot win. Changing the way I write requirements makes far more sense than trying to predict every possible response.
What hasn’t changed
Many of the fundamentals of good business analysis remain exactly the same. We still need to:
- Understand the business problem.
- Engage stakeholders.
- Challenge assumptions.
- Identify business rules.
- Define success measures.
- Manage risks.
- Validate outcomes.
Good communication is just as important as it has always been.
AI does not remove the need for good business analysis. AI can still struggle to capture tacit knowledge that stakeholders often communicate implicitly through experience, context and even non-verbal cues.
What I have changed when writing AI requirements
Rather than focusing solely on what the system should do, I place greater emphasis on documenting:
- The decisions the AI is expected to support.
- Business constraints and guardrails.
- Situations requiring escalation to a human.
- Measures of success.
- Assumptions and known limitations.
This gives delivery teams a clearer understanding of what the organisation is trying to achieve, rather than simply describing system behaviour.
A practical template for AI requirements
After discussing the topic with other Business Analysts, researching different approaches and experimenting on AI delivery projects, I eventually settled on the following template. With a few improvements expected to come. A summary of the changes are below:
| Section | Heading | Unchanged / New |
| Introduction | User story | Unchanged |
| Business objective | ||
| In scope | ||
| Out of scope | ||
| Behaviour | Intent name | NEW |
| What does the user want to do | ||
| Inputs What data points does the AI need in order to be successful? | ||
| Outcomes What are the different outcomes that we want to happen? | ||
| Decision points Decisions that the AI needs to make. Based on the Inputs and the Intent available to it and the Rules in place. | ||
| Escalations When should the AI escalate to a human? | ||
| Rules These are immutable rules, or universal truths which the AI must always abide by. If you’re looking for a pop culture example of immutable rules, RoboCop’s Prime Directives are a good one. They define boundaries that can never be broken, regardless of the situation. | ||
| Functional requirements Currently, I still capture these because: 1. During this transition phase, it is good to keep them in for the development team (familiarity or existing process) 2. There may be some additional functional requirements worth calling out specifically, or ‘doubling-down’ on for the reader of the document However, if I were handing the requirements document directly to an AI agent, I would probably remove this heading all together. | Changed / Expected to be removed as needed | |
| Non-functionals | Unchanged | |
| Analytics (Monitoring, Reporting etc) | Unchanged |
An example
Focusing on the NEW headings only, here is an example for a food delivery app:
| Heading | Example |
|---|---|
| Intent name | Place a food order |
| What does the user want to do? | The customer wants to order a meal for delivery to their current location as quickly and accurately as possible. |
| Inputs | – Customer’s spoken or typed request (“I’d like a <food item>) – Delivery address or current location – Current restaurant menus and pricing – Restaurant opening hours – Restaurant policies – Item availability – Previous orders (optional) – Dietary preferences or allergies (if known) – Payment method availability – Estimated delivery times |
| Outcomes | Order successfully created and submitted to the restaurant, or Order not possible. Alternative menu items are suggested, or Order not placed. Customer is informed that delivery is unavailable or Customer declines to select alternative items if their original request is unavailable. |
| Decision points | – Which restaurant best matches the user’s request? – Is the requested item currently available? – Does the customer need clarification? – Should substitutions be offered? – Is delivery available for the customer’s location? – Is enough information available to place the order? – Is the payment method valid before submitting the order? |
| Escalations | – Customer disputes pricing. – Payment repeatedly fails. – Restaurant reports an issue after the order is submitted. – The AI cannot determine what the customer wants after multiple attempts. – A customer requests an exception outside restaurant policy |
| Rules | – Never submit an order without explicit customer confirmation. – Never invent menu items or prices. – Never substitute an item without customer approval. – Always display the total cost before payment. – Always respect restaurant opening hours and delivery areas. – Always protect customer payment details and personal information. – Always comply with declared dietary restrictions and allergies. – Never modify an order after submission |
The above is just an example and I find that the Rules heading in particular becomes more than one line, when working on a real example.
In summary
As AI becomes responsible for more implementation decisions, Business Analysts need to spend less time prescribing every possible behaviour and more time clearly communicating intent, outcomes, rules and constraints.
I’d be interested to hear how other Business Analysts are adapting their approach to requirements for AI-enabled solutions.