In the opening of this series I described the agentic engineering pipeline from the bird’s-eye view for the SDLC, which guides a new feature through six phases, from the read-only extraction of context to the logged implementation, and places a checkpoint between each of the roles. This post descends into the first role, business analysis. If it gets it wrong, everything that follows is technically clean effort spent on the wrong thing. A mistake in this role propagates through the entire chain and becomes much more expensive to correct with every phase.
For simplicity I call the role business analysis, or BA for short, well aware that the labels vary in practice. In some places it is called requirements engineering, elsewhere the task falls to a product owner, a subject matter expert or an analyst at the boundary between the business side and the technical side. Who fills the role is secondary for this text; what matters is the activity, to clarify what a system should do and why, in such a way that a developer can build something from it without having to guess.
Why this role goes first
Anyone working in the brownfield is dealing with a system that has grown over years and in which much was never spelled out. The greatest danger there is the misunderstood requirement, rarely the difficult technology. A team can laboriously optimize an algorithm and cleanly rebuild a database, and in the end it turns out that all the work solved a problem nobody had, while the actual problem remained untouched. That kind of failure is more common in a grown system than the spectacular technical collapse, and it is quieter, because it only shows up late.
Business analysis is the role meant to prevent this failure. It stands between what the business side wants and what the technical side builds, and it closes the gap between the two before anyone writes code. In agentic work this task becomes the key, because an agent can formulate a plausible requirement in minutes that reads as if a human had thought it through. A plausible requirement can still be wrong, and in a legacy system that decides success.
The old target picture
The task described here is not a new profession. Good business analysis was always meant to do exactly this. It gathers domain knowledge, checks statements, makes contradictions visible, formulates requirements so they can be tested, and prepares a ticket in such a way that development can work without guessing. This target picture was often very clear in the old requirement specifications of waterfall projects. In daily project work, it was rarely reached. The reason often lay in the conditions of the projects. Under project pressure, research was shortened. Huge data sets were searched only in excerpts. Business context had to be assembled from old tickets, scattered documents, grown special cases and conversations. Anyone who still wanted clean documentation needed time that was rarely planned for. That is how incomplete requirements arose, even though the people involved knew what a good requirement should look like.
With agents, the economics of this work change. The claim remains the same, but the legwork becomes cheap: finding sources, comparing variants, preparing glossaries, normalizing acceptance criteria, generating example and test data, tabulating open questions. Completeness no longer needs days of documentation work. It emerges from many small, checked agent steps. That gives the BA back the part of the work that often fell short under project pressure: establishing business context, asking good questions, thinking through use cases and drawing the boundaries of a feature cleanly. She becomes the business orchestrator of a waterfall ticket. She operates the agent, reviews its suggestions, decides about evidence and keeps the ticket complete enough for development, UX and test to continue from it. This connects to what I described in the post on the return to waterfall: the machine takes the search and writing load off the BA. More room remains for judgment, creativity and responsibility.
The human ability: judgment about sources
What a business analyst brings and a language model does not have is the judgment about what a source is worth. An experienced BA reads an old ticket and recognizes that the requirement described in it was long since overtaken by a later decision. With a Confluence page she notices that it describes a wishful picture that was never implemented in that form. In conversation with a case worker she hears between the lines that the official process description and actual practice diverge. She distinguishes what is documented from what merely sounds plausible, and from what contradicts itself across two sources.
A language model cannot do this reliably, and that lies in its nature. A model approximates language. It produces text that fits what it has seen in the prompt, and a documented fact reads in the text exactly as convincing as a skillfully worded guess. Both consist of the same grammatical building blocks and sound equally certain. Whether a statement is true in the world the model cannot judge; it sees only whether it is linguistically probable. In the brownfield context, where evidence is rare and assumptions are common, this blindness to the truth value is the central risk.
A second piece is perspective. A good BA thinks the result through from the point of view of those who work with the system, such as the case worker or the customer. She asks what this person wants to achieve and how they will know that they have achieved it. A model that is not guided thinks from the system’s point of view, because the system view dominates in the training material. It describes what a function validates; what a person should be able to do falls away. This shift of perspective is subtle and at the same time consequential, because it hands responsibility for success from the business side to the technical side, where it does not belong.
There is also the conversation with stakeholders. A BA listens to a subject matter expert and recognizes when what is formulated as one requirement is in truth two that merely happened to be named together. Behind a technically phrased request there is sometimes a quite different business need, and she notices that too. She catches when a requirement silently assumes that the grown system behaves in a particular way, and that this assumption must be checked. This breaking down and questioning happens in conversation, in the back and forth between people, and it is the point where an agent can least replace.
A language model cannot tell from a sentence whether it is documented; it goes by what is linguistically probable. Business analysis checks every statement for its evidence before an unchecked guess becomes code.
Four core principles of the role
Every output of the role can be measured against four principles.
Deliver the documented truth. Business analysis delivers a documented truth and leaves the solution to development. Its task is to describe what should happen and why, for whom and with what benefit. How it is built is decided by development, and it is decided only after an examination of the brownfield that the BA cannot perform at all, because she does not know the code in depth and cannot assess it either. A BA who prescribes a technical solution takes away from development the judgment that can only be made there, and she usually does so without being able to survey the consequences.
Every statement is labeled. In a BA output there is no unlabeled running text. Every claim carries one of four marks: a [Fact] for something verifiable with a named source, an [Assumption] for something plausible without evidence, a [Question] for something open that still has to be clarified, and a [Contradiction] for a point where two sources do not agree with each other. Smooth, unmarked text is a mere summary and is not enough. A summary blurs precisely the uncertainties and contradictions that make up the actual risk.
The ticket is authoritative. The chat history is fleeting, and whatever is worked out in an agent session but does not make it into the ticket is lost for the rest of the process. That is the artifact contract from the opening post, here in its concrete form for this role. A developer who implements the feature works from the ticket. Whatever is missing from it is missing for her entirely, because she does not see the course of the discussion.
E2E content exists before the handover. A ticket is ready for development only when it contains the business material for the later End-to-End test. This includes scenarios, placeholder data, expected message texts, start and target states, role changes and relevant handovers to neighboring systems. These are not executable tests yet. The BA delivers the content from which the test role later creates browser and workflow E2E specifications.
How the agent supports the role
In this role the agent is a working apparatus for the BA. It researches, sorts, drafts and produces the content from which development and test later work. It decides nothing. It takes the mechanical part of the work off the BA. The BA steers it through precise assignments, reviews the results and discards what merely sounds plausible. Whoever fills this role still needs domain knowledge. A new craft skill is added: guiding the agent so that the result is a complete, testable ticket, not a conversation log.
The agent works in the early phase that the pipeline calls Discovery, that is, the preliminary investigation in which the team understands what the matter is about before it determines what is to be done. Its first task is to build a source inventory.
A source inventory is a list of all the places that say something about the area concerned, and each place gets an identifier, a title and a date in the format YYYY-MM-DD. The date format is a rule with consequences. Vague labels like “current” or “recently updated” are not allowed, because in the system a Confluence page abandoned three years ago looks just as fresh as one revised yesterday. Only the concrete date makes the difference visible, the difference that in a legacy system often decides whether a statement still holds or is long outdated.
For this the agent reads many sources. It reads tickets from the tracking system, Confluence pages, Architecture Decision Records, that is, the documented architecture decisions, Runbooks that describe how a system is operated, old documentation and the code itself. This breadth is its strength. A human needs days to read through scattered legacy documentation; an agent builds an inventory in a short time that a BA can then review. Here the tool genuinely amplifies the role, because it speeds up tedious but necessary legwork.
What the agent does not provide is the assessment. Every finding it draws from the sources must be labeled by the BA. The agent can make a suggestion, it can say this statement relies on ticket TICKET-417 from 2024-03-12, so I propose [Fact]. But the human sets the mark, because only the human can judge whether the ticket still holds, whether it has been overtaken, whether it perhaps only documented a wish that never became reality. The labeling is the analytical core contribution of the role, and it stays with the human.
One peculiarity of this role runs counter to what one expects of a language model: the smooth, easily readable summary is expressly not the goal here. A model is trained to deliver a contradiction-free, rounded presentation, which is harmful in Discovery. A rounded summary smooths over exactly the contradictions in which the actual risk sits. When two sources contradict each other, the output should show the contradiction, with both sides and the mark [Contradiction], instead of inventing a third, harmonious formulation that pretends there is no problem. The task of Discovery is to make the contradictions transparent.
After that, the agent becomes a production tool for the E2E content. It can propose business scenarios from acceptance criteria, generate Mustermann data, check expected messages for consistency and place process variants side by side. The BA decides which of these suggestions match the business reality. The agent provides volume and variants. The BA turns them into binding content for the ticket.
The interplay with UX in the feature workshop
Business analysis works closely with UX, the role that describes how a feature feels for the users. In the pipeline both meet in a feature workshop, and this workshop has a fixed form that prevents settling prematurely on a formulation that only holds on the surface.
The workshop begins with BA and UX describing the feature independently in their own words. Each side notes the goal, the user, the benefit, the boundaries and the open questions. This happens separately at first, because the differences between the two descriptions are the interesting points. Where BA and UX understand the same feature differently, there is an ambiguity that has to be clarified before anyone goes on. From the two descriptions a shared team template then emerges, an aligned picture of the feature that both roles have agreed on.
A central part of this shared work is the definition of the UX states. A feature does not have only the one course in which everything goes well. It has several states, all of which have to be described, and the pipeline names them explicitly. [UX-SUCCESS] is the case in which the task succeeds. [UX-EMPTY] means the case in which there is no data yet, an empty list, a fresh record. [UX-ERROR] is the case in which something goes wrong. [UX-LOADING] describes the state while waiting for a response. [UX-EDGE] stands for the edge cases that occur rarely but then determine the behavior.
The error case is forgotten most often in practice and at the same time reveals the most. [UX-ERROR] describes a business message in business language. When a case worker wants to save a claim without a required piece of information, she should read a message that explains in her language what is missing and why it is missing, and not a technical code like “Validation error in field 0x2F”. This requirement is a business one, and it therefore belongs in the BA part of the description. How the message is technically triggered is a matter for development; its wording and its language belong to the business side.
Only after the team has reviewed this shared description and found it coherent are the tickets uploaded to the tracking system. This order is deliberate: not every idea is immediately created as a ticket, because a prematurely created ticket suggests a commitment that has not been reached at all yet. Only the team check turns a draft into a ticket that the next role can take seriously.
What the role produces as artifacts
The central artifact of business analysis is the BA ticket. It has a fixed structure, and this structure is the form in which a documented truth can be handed over. Each section has a practical purpose, and the order of the sections has its purpose too.
The ticket begins with a header. It contains the outcome, that is, the result from the user’s point of view, and this outcome begins with a persona or an action: “The case worker can …”. This formulation is a test. If the result can be phrased so that an acting person stands at the beginning and a capability follows, then it is thought through from the user’s point of view. If, on the other hand, the sentence begins with “The system …”, it is thought through from the system’s point of view, and that is a warning sign. Alongside the outcome the header contains the persona, the trigger, that is, what sets off the feature, the stakeholders and the source date.
The header is followed by the body in a fixed order of sections. First the problem or the need: why does this feature exist at all, what business need lies behind it? Then the acceptance criteria, formulated as Given/When/Then in business language and numbered individually, [AC-1], [AC-2], and so on. Given/When/Then is a simple scheme: given a starting situation, when an action occurs, then an expected result. In business language this means that business terms appear there and no technical ones. The individual numbering is important, because it makes each criterion testable and referenceable; a nested criterion that demands three things at once is in truth three criteria and should be split up.
After that come the UX states from the workshop, then the non-goals. The non-goals are a section of their own, often underestimated. They actively exclude common assumptions. If a feature introduces a new mandatory field, then the assumption is obvious that the existing data stock must also get this field. Such an assumption belongs under the non-goals, expressly negated, so that no one silently reads it along. What is not excluded gets read into the text by someone in case of doubt, and in the brownfield such silent co-assumptions are, in my experience, the most expensive.
Then comes the source inventory, that is, the list of sources with their dates, and after that the statement list, in which every claim carries its mark and, for a [Fact], the source is named. Then the open questions, and as a table. Each question gets an identifier [Q-1], a wording of the question, an owner, that is, a named responsible person who is to answer it, an answer deadline, and a note on what happens if the question remains unanswered. This last column is the most important, because it weights the question. An open question whose non-answer blocks the entire feature weighs more than one that only leaves a detail open, and the table makes this difference visible. The conclusion is formed by the E2E content, the stakeholders and the sign-off.
Several mandatory artifacts belong to the BA ticket. A UX sketch that captures the workshop finding visually. A snippet, that is, a small concrete example of the expected behavior. A glossary that defines the business terms, and this glossary has, in the brownfield context, an additional column for the equivalent in the neighboring system. Where a term lives across system boundaries, it should state there what it is called in the other system; where no equivalent is known, there is a dash and an open question. Finally, the E2E content belongs there: example data with placeholders, business scenarios, expected messages and the states the later test is supposed to demonstrate. Real people, companies or case numbers do not appear in it.
This E2E content is a basic requirement for the handover to development. It is not yet a test plan and not a test script. It describes the business path that a later test must demonstrate. If this material is missing, development has to guess during planning which states and transitions should be visibly checked in the end. Then the ticket is too early for implementation.
Brownfield specifics: what is different in the brownfield
A business analysis in a grown system differs from one on a greenfield in the very kind of work. Three differences are so important that the pipeline anchors them as fixed rules.
The protection of existing data over forced migration comes first. A new feature should not automatically migrate or validate existing data; new obligations apply only to records that are newly created or actively edited, while the old stock stays readable and storable. This separation is a business decision with great effect. Without it, a data migration slips unspoken into a feature ticket, although it is an undertaking of its own, with its own stakeholders, its own risk profile and its own schedule. Treated as a side matter, it throws the scope of the ticket into disorder, and the feature ends up taking far longer than planned. The BA therefore makes this separation explicit in the non-goals.
The second peculiarity concerns the mapping of the cross-system terms, already touched on with the glossary. In grown systems a system almost always shares data with others, and a term like partner, case or role can mean something slightly different in each of them. As long as this relationship is named nowhere, it remains a hidden source of error. The BA must map the cross-system terms explicitly, even when the current feature has no cross-system effect at all, because the next change might have it and then the ambiguity is already in the way.
The strictest rule is that no technical specification may appear in the BA ticket, neither architecture nor data model, no column names and no choice of a framework. After the handover, development performs a feasibility check against the brownfield: it looks at the points in the grown code where the same logic hangs, what can be reused and what a change in one place triggers three places further on. If the BA ticket already prescribes a technical solution, it makes this check worthless, because development then only works through a specification that someone set without knowledge of the code. In my experience, the technical specification in the business ticket is the most common reason that development sends a ticket back. The BA therefore describes what should happen and why, and leaves the question of how it is implemented to development.
The quality gate: Definition of Ready
Between business analysis and development stands a checkpoint, called Definition of Ready in the pipeline, DoR for short, or also Ready for Dev. It is the point at which a human decides whether the ticket is ready to go into implementation. The gate has a checklist, and the check is deliberately carried out by a human, because it concerns questions of judgment that cannot be answered mechanically.
The checklist asks:
- whether the outcome is an unambiguous sentence that begins with a persona or an action and can be tested from the user’s point of view;
- whether the acceptance criteria are numbered individually and formulated in business language, without technical terms;
- whether the UX states are present, including the error case in business language;
- whether the source inventory carries dates and contains no “current”;
- whether the statements are labeled, each with its mark, and the source is named for every [Fact];
- whether the E2E content is complete, that is, business scenarios, Mustermann data, expected messages, start and target states and relevant handovers to neighboring systems;
- whether the mandatory artifacts are in the repository, that is, UX sketch, snippet, glossary with the neighboring-system column and E2E content;
- whether the ticket is free of a technical solution.
The mandatory artifact of this gate is twofold: the labeled source inventory and the finished ticket with E2E content. Both must be present, otherwise the gate’s question cannot be answered. The source inventory shows that the knowledge base is honest, with its gaps and contradictions, and the ticket demonstrates that this base has become a testable requirement.
The most important property of the gate is its hardness. If a point is missing, the ticket goes back. It is not quietly processed further and not waved through with a verbal “we’ll clarify that later”, nor on the assumption that development will fill the gap. This very silent processing drags errors deep into the chain, where they become expensive. A ticket that does not pass the Definition of Ready is not finished, and an unfinished ticket starts no implementation. This strictness may feel annoying in the moment. It keeps the cost of errors low, though, because the correction still happens in the text, while the system is not yet running.
A ticket that does not pass the Definition of Ready goes back. Expensive errors in a grown system mostly arise at the unfinished tickets that someone passed on unchecked out of convenience.
How the compliance rules work in this role
The compliance requirements that the opening post described as the sixth principle are built into the way business analysis works. In this role they act at four concrete points.
Data minimization. In software development this means that personal data do not belong there. The example data in the BA ticket are therefore exclusively placeholders, Mustermann GmbH, Erika Mustermann, Max Mustermann. A BA ticket ends up at some point in a training, a presentation, an export or a shared workspace. Whoever works with placeholders from the start does not have to filter out real data afterward, a cleanup job in which not all places are caught anyway. The project context the agent works with contains only what is needed for the business, as plain text, without real data.
Sources with a date. That every source has a date and that there is no “current” is not only a matter of care, but also of traceability. Whoever later wants to check on what knowledge base a requirement arose finds dated evidence in the source inventory instead of vague references. That is the provenance an audit trail needs, in the simplest conceivable form.
Marking the AI-generated content. The EU AI Act, Regulation 2024/1689, requires transparency about the use of AI. In this role that means that every piece produced by the agent is marked as AI-generated, with a note that refers to the operation, the responsible person and the version of the model or the instruction. When the agent has made a suggestion for labeling a statement, it is traceable that the suggestion came from a model and that a human confirmed or corrected it. The mark itself is set by the human, the suggestion comes marked from the agent, and both stay in the trail.
The DoR gate as human sign-off. The principle of the entire pipeline is that the agent suggests and the human decides, and human oversight applies without exception. The DoR gate is the place where this oversight becomes concrete in business analysis. A named responsible person confirms the ticket before it moves on, and in doing so vouches for its content. The support from the agent does not lessen this responsibility. A ticket that a model suggested and a human merely nodded through, without checking it, violates this principle, even if formally a sign-off exists. A sign-off only counts when a real check has preceded it.
A worked example
A short example with placeholders shows how the rules work together. A business department of Mustermann GmbH reports a need: when recording a case, a certain piece of information that was optional until now should in future be required. With this first sentence a premature approach would immediately create a ticket that demands a new mandatory field.
Business analysis begins differently. The agent builds the source inventory, finds an old ticket from 2023 that once introduced the information as optional, a Confluence page from 2024 that describes a process, and hints in the code on how the information is stored today. Now the BA labels. That the information is optional today, documented by ticket and code, is a [Fact]. A second [Fact] comes from the conversation: the business department demands it for all future cases. Whether the existing cases should get it too has not been voiced by anyone; that remains an [Assumption] to be checked. And the Confluence page describes a process that does not match the actual practice of case work, a [Contradiction].
From this labeled base the ticket emerges. The outcome: “The case worker can close a case only if the information is present, and otherwise receives a business message that explains which information is missing.” An acceptance criterion [AC-1] describes the success case, [AC-2] the error case in business language. The UX state [UX-ERROR] formulates the message in business language. Under the non-goals it expressly states: the data stock is not changed, existing cases without the information remain valid and storable, a migration is not part of this ticket. The open question [Q-1] in the table: should existing cases be retrofitted at their next editing, owner the business department, with a deadline and the note that an affirmation triggers a migration undertaking of its own. The [Contradiction] between the Confluence page and practice is recorded in the statement list, so that development does not overwrite it unawares.
For the E2E test, the BA also produces the business content. Erika Mustermann creates a case for Mustermann GmbH. The required information is missing. On closing, the message appears in business language, the case remains in an editable state, and the handover to the neighboring system does not happen in this state. These details are deliberately concrete, because the later test needs visible content and expected states. Development can see before implementation which behavior must be demonstrated in the end.
What is not in the ticket here is at least as important as what is in it. There is no column name in it and no specification of whether the check happens in the frontend or the backend, nor any choice of a library. Development makes these decisions after its feasibility check, once the ticket reaches it.
Outlook
The next post in the series turns to development. There it will become clear what becomes of a BA ticket that has passed the Definition of Ready: how development checks the brownfield against the requirement, how the what turns into a how, how the small, individually implementable tickets emerge from the Epic, and how an agent can work across many steps without losing control. The handover between business analysis and development is the point where it is decided whether the clean preliminary work holds, and it is the reason the DoR gate is as strict as it is.
The business analysis role can be tried out with a single exercise, even before the next post appears. Take the next requirement that lands on your desk and label every sentence in it. Which of it is a fact with a source, which an assumption, which an open question, which a contradiction? Usually the list of assumptions and questions grows longer than you would like, and that justifies the role. A requirement that fully resolves into documented facts is rare; far more often a few assumptions you thought long settled show up during labeling.