Many organizations are using AI coding assistants to develop software applications. However, AI-generated code is only as good as the prompts, specifications, and other instructions the coding assistant receives. Much of the business analyst’s (BA) job, then, is making sure that those inputs are solid enough for AI to build from. That goal leads to three key questions:
- What form(s) should the requirements information take?
- How much detail and contextual information does AI need to generate the correct solution?
- What’s the appropriate role of the business analyst in developing the necessary requirements knowledge?
This article describes how one organization is using AI coding and some lessons they’ve learned along the way. A two-stage development approach using solid requirements development practices seems to be an effective strategy. The project is not yet complete, but the experience so far has revealed several important insights.
In this article, “we” refers to the development team that Iryna works in as a BA. Karl didn’t participate directly in the project.
The Project and Approach
This experience comes from a project at Globberry, a company that provides system integration services for telecommunications networks, business support systems, and enterprise IT environments. Its customers include telecom operators and large organizations in sectors such as oil and gas, utilities, and public safety, many of which rely on professional mobile radio networks for critical operations.
One of the company’s ongoing projects involves the development of a session border controller (SBC) access policy server. This is a telecom security solution designed to protect phone networks from scammers and robocalls. The solution needs to provide an intuitive web console and enforce security rules in real time. To speed up development, the team decided to adopt an AI-assisted coding approach. The AI tool has been involved from the very beginning.
The main goal is to deliver a working solution to the business in a shorter time than traditional coding would allow. The team expects AI-assisted development to produce a working prototype faster, let the team validate the concept with the customer sooner, and reduce overall development time.
The development team chose a two-stage approach:
In Stage 1, an AI tool generated an interactive prototype that helped the team validate the proposed solution with stakeholders and further explore requirements.
In Stage 2, the team is turning these findings into detailed requirements and acceptance criteria, which guide the AI in generating the application code. The process is iterative, with the team reviewing and refining the results as development progresses.
Question 1. What form(s) should the requirements information take?
In our two-stage development approach, the form of requirements information evolves as the project progresses.
Stage 1 Requirements Form
In Stage 1, we provided the AI agent with some high-level requirements information and several sources of context. These inputs included:
- A preliminary, incomplete data model with tables and fields that contained the core structure of the system.
- UI code from an existing similar product to serve as a reusable concept and design direction as a starting point.
- Initial customer requirements that described the main stakeholder expectations, project goals, business context, and principal functional expectations, but without detailed business rules, validations, or exception scenarios.
This high-level information provided the AI with enough information to generate a meaningful first version of a solution: a throwaway prototype.
The Role of Prototyping
AI-assisted software development is changing not only the speed of implementation, but also the point at which requirements become visible. Using a prototype to discover and validate requirements is a well-established business analysis technique. What’s different here is that a prototype now appears in days rather than weeks, and that it’s an executable piece of software instead of a wireframe or mockup.
We’re now considering whether the Stage 1 process would benefit from improving the initial information we provide to the AI tool before it begins any implementation. For instance, process flows are a way to derive what software functions are needed and might be of value to the AI assistant.
The generated interactive prototype has helped us discover the real business, user, and solution requirements. We need to have a cross-section of user classes evaluate the prototype to make sure we haven’t missed anything important. This evaluation could also reveal requirement conflicts among different stakeholders. The business analysis work following Stage 1 involves specifying detailed functional behaviors, business rules, validations, and exception handling for Stage 2, in which the AI tool will generate the full solution.
Stage 2 Requirements Form
In Stage 2, we’re providing the AI tool with more detailed requirements, which we’re creating based on our work with the Stage 1 prototype. Our overall development process typically looks like this:
We’re now preparing use cases with detailed descriptions and acceptance criteria to see how effectively AI can revise the initial code, how accurate the result is, and what further refinement we still need. Having explicit acceptance criteria helps both with implementation and testing, as they give AI a clearer description of the expected solution behavior.
Our intent is to ultimately establish a requirements baseline to guide the AI development. This poses a challenge, though. What form of requirements documentation would be both usable by the AI tool and readable—and reviewable—by people? Ideally, the same representation of requirements knowledge could satisfy both human readers and AI code generators. We’re still exploring that issue.
The Risk of AI-Drafted Requirements
Some teams take a stakeholder interview transcript or similar raw input and have an AI tool draft requirements information from it. The result might be beautifully feature-centric, with properly formatted user stories, reasonable acceptance criteria, a list of necessary functions, and the like. It looks great, quick and pretty. Watch out for a risk here, though.
AI-generated requirements may be well-structured, tidy, and clear. But are they the right requirements? Are they accurate and valid? Is anything missing? Don’t skip the step of having humans review generated requirements to validate them and ensure that the resultant solution will achieve the intended business objectives.
There’s another problem, too. If the AI generates many nice-looking requirements, a BA can’t easily see whether anything is missing, because their brain wasn’t engaged in the generation process. Creating other representations of requirements knowledge, such as visual analysis models, helps reveal gaps.
We tried this approach in our own project. We mapped AI-generated requirements to visual models, mainly sequence diagrams and a traceability matrix. An absent branch in a diagram or an empty cell in the matrix could immediately show that something was missing. This is much easier to notice than an omission hidden in a long list of well-written requirements. This is how we, for example, identified a missing error-handling scenario. The diagram showed what should happen when the request succeeds, but there was no corresponding branch for the error case. The gap was not obvious from the text, whereas the visualization made the missing logic much easier to see.
Question 2. How much detail and contextual information does AI need to generate the correct solution?
Our experience so far suggests that the amount of detail and context needed may vary depending on the development stage, the type of product, and whether the AI is working with an existing codebase. The AI tool also makes a difference. Some platforms follow a fixed spec-driven model, while the general-purpose assistant we used fit into our existing workflow without requiring us to follow a specific structure. We had to decide how much detail we needed in the specifications at each stage, rather than following rules built into the tool.
Initial Prototypes versus Target Solutions
Our initial inputs weren’t a complete requirements baseline. We still needed to discover and validate many details through stakeholder interactions. However, the high-level inputs were enough for the AI to generate a working front-end within just a few days. This allowed customers to interact with a working interface rather than examining simpler wireframes or mockups. These interactions immediately revealed missing business rules and hidden assumptions that we had to address before the AI could generate the ultimate solution.
Replacement Products versus New Products
Several other teams in our company are using a similar approach to ours, providing the AI tool with a limited set of new requirements to generate a working prototype quickly. A common feature of these projects is that the solution is not being created completely from scratch. In each case, it is based either on a similar existing project or on a legacy solution whose capabilities must be preserved even if the system implementation changes significantly.
An existing solution can serve as a valuable starting point for the AI. When AI has something concrete to build from, it might need less comprehensive specifications to produce a reasonable product. It’s important to distinguish the existing functionality to be retained from new functionality to add and old functionality to discard.
Our own project fits this pattern in its own way. The SBC access policy server’s functionality is new, but we gave the AI a concrete starting point by reusing the UI concept and design direction of an existing similar product, rather than beginning from a blank interface. This kind of experience—ours with a similar existing app, and other teams in the company with legacy modernization—is helping us explore whether this two-stage approach fits both types of projects. A product with no existing UI, code, or design to build on may require much more detailed initial requirements work.
Scope and Constraints
We’ve learned that we need to make scope and constraints very clear at every stage. For example, the AI tool suggested migration scripts and a more complex data model than we presented to it, although we do not yet have production data and our Stage 1 “solution” is simply a throwaway prototype. The generated solution is technically reasonable, but it’s more than we need at this point. We must be explicit not only about what the system should do, but also what lies outside the current scope. Fortunately, AI-generated prototypes are quick and cheap to develop, so even a prototype that you discard can help inspire customers, developers, and BAs with new ideas.
The High Cost of Ambiguity in Modifications
Our experience suggests that detailed and precise requirements are more important once AI starts modifying an existing codebase. Ambiguity becomes much more expensive when the AI is changing something that already exists. When AI builds something new, a wrong assumption usually means building that one part again. However, when changing existing code, an incorrect assumption can break something that other parts of the system, other users, or connected systems already depend on. This kind of problem is much harder to find than checking new features.
AI needs a lot of context even when making relatively small changes in its generated code. For example, when we ask AI to make a minor change to an API endpoint, we need to explain not only what the endpoint should do, but also who uses it, when and how it is used, what happens before and after its use, and what capabilities are in and out of scope. Without this context, AI starts making its own assumptions or asks us questions that aren’t necessarily the right questions. Incorrect assumptions can lead to errors not only in the code, but also in the tests and other parts of the solution.
Level of Detail
Crafting requirements for any product requires iterative communication among the BA, developers, and customers. Perhaps your developers or AI coding assistant will ask the right questions for clarification, requirement detailing, and understanding context.Perhaps they won’t.The BA must be alert to developers—whether human or AI—possibly making inaccurate interpretations and assumptions. They might attempt to fill knowledge gaps by doing what seems reasonable to them but isn’t right for the users.
An age-old issue with requirements is how much detail to include. For each capability you specify, ask yourself, “If this requirement is all the AI has to work from, can it make the right implementation decisions?” For something that must be implemented in a specific way, you need more detailed and precise requirements, often including design constraints.
When humans write the code, they often already know about the diversity of users and their various usage environments and contexts. They might know the history of any legacy apps the new solution will replace, what users do and don’t like about it, and the extent to which it does and doesn’t meet current needs. That knowledge greatly helps developers build a better solution.
Developers also need to know about pertinent constraints and business rules the solution must respect. Beyond functionality, developers must understand which quality attributes are more important than others. Developers need to know the various stakeholders’ expectations for usability, security, reliability, and other attributes so they can make appropriate trade-off decisions. Consider how you can provide all of this knowledge to an AI coding assistant.
Question 3. What’s the appropriate role of the business analyst in developing the necessary requirements knowledge?
The role of the business analyst remains indispensable when working with AI, shifting from traditional drafting of requirements to active verification, assumption management, and contextual bridging.
BA Core Functions and the AI Assistant
Many aspects of the BA’s traditional role carry over to AI code generation. Regardless of who constructs the solution, someone still has to perform fundamental BA functions, including these:
- Determine what the real problem is and state the organization’s business objectives.
- Identify, characterize, and prioritize the various stakeholder groups and user classes.
- Talk with representative stakeholders to understand each group’s goals, needs, constraints, and concerns.
- Prioritize functionality.
- Identify relevant business rules and the functionality to enforce them.
- Resolve conflicts that arise between requirements and among stakeholders.
- Determine how the organization and its users will transition to using the new solution.
While the BA leads the requirements process, AI can help with certain activities. AI agents can suggest questions for the BA to ask stakeholders, point out possibly overlooked exceptions and edge cases, and detect inconsistencies. Perhaps they can spot knowledge gaps, recommend functionality based on similar products, or suggest existing solutions for portions of the product. The BA can also use AI to draft initial acceptance criteria and test cases.
Active Assumption Management
We’ve identified AI-generated assumptions as a big area of concern. AI tools are prone to hallucinations, so human validation of whatever they generate is essential. The BA must actively identify and validate AI-generated assumptions, helping customers and the development team distinguish between what has actually been agreed upon and what the AI simply inferred or introduced based on common design patterns.
Similarly, we can’t simply trust the generated code’s correctness without developer review. During reviews, our developers have found evidence of inaccurate assumptions and cases where the generated solution is more complicated than necessary.
Managing the Illusion of Completeness
Rapidly produced, AI-generated software can create a dangerous “illusion of completeness.” Upon seeing a nice-looking, clickable interface, both the customer and the team might conclude that the product is much more mature than it actually is. This is a long-standing concern with software prototypes.
Recognize that you can create several different kinds of prototypes for different purposes. Interaction design prototypes are more likely to convey an illusion of completeness than are technical design prototypes. High-resolution, executable prototypes present more of this risk than do less polished prototypes, such as navigable wireframes.
In a two-stage approach as we describe here, expectation management with prototype evaluators is essential. Our Stage 1 prototype was executable and built on real UI code. That’s exactly the kind of high-resolution prototype that carries the greatest risk of this illusion. We told our prototype evaluators that they were looking at a discovery tool for surfacing requirements, not a preview of the finished product.
Beware of Analysis Debt
Even with AI assistance, humans must apply their own intelligence and judgment to ensure that the AI tools build the right solution. Skimping on these essential activities runs the risk of accruing “analysis debt.” As Erivan de Sena Ramos explains in his book Analysis Debt: Why AI Still Needs Business Analysis:
“Analysis debt is the hidden cost of moving forward on incomplete, weak or insufficiently validated analysis. It appears when assumptions become requirements, summaries become decisions, and artefacts look ready before the problem is fully understood.”
Technology is changing quickly, but the fundamental business analysis actions of understanding problems, asking the right questions, validating assumptions, and managing requirements remain largely unchanged. What is evolving is just how we can apply those principles in this new development environment. Better requirements mean less guesswork and fewer false starts by whoever—or whatever—creates the code.
Authors: Karl Wiegers and Iryna Bevz
Karl Wiegers is the Principal Consultant at Process Impact. He’s the author of numerous books, including Software Requirements (with Joy Beatty), Software Requirements Essentials (with Candase Hokanson), and Software Development Pearls.
Iryna Bevz is an experienced business analyst with a background in telecommunications and fintech, exploring in practice how AI is changing the role of the business analyst and software requirements.