Die Rolle Business-Analyse: Was gebaut werden soll und warum

Im Auftakt dieser Serie habe ich die agentische Engineering-Pipeline aus der Vogelperspektive für den SDLC beschrieben, die ein neues Feature durch sechs Phasen führt, von der lesenden Kontext-Extraktion bis zur protokollierten Umsetzung, und zwischen den Rollen jeweils einen Prüfpunkt setzt. Dieser Beitrag steigt in die erste Rolle hinab, in die Business-Analyse. Wenn sie falsch arbeitet, ist alles, was danach kommt, technisch sauberer Aufwand an der falschen Sache. Ein Fehler in dieser Rolle pflanzt sich durch die gesamte Kette fort und wird mit jeder Phase viel teurer zu korrigieren.

Ich nenne die Rolle der Einfachheit halber Business-Analyse oder kurz BA, wohl wissend, dass die Bezeichnungen in der Praxis schwanken. Mancherorts heißt sie Requirements Engineering, anderswo fällt die Aufgabe einer Produktverantwortlichen zu, einer Fachexpertin oder einem Analysten an der Schnittstelle zwischen Fachbereich und Technik. Wer die Rolle ausfüllt, ist für diesen Text zweitrangig; es geht um die Tätigkeit, zu klären, was ein System tun soll und warum, und zwar so, dass eine Entwicklerin daraus etwas bauen kann, ohne raten zu müssen.

Warum gerade diese Rolle den Anfang macht

Wer im Brownfield arbeitet, hat es mit einem System zu tun, das über Jahre gewachsen ist und in dem vieles nie ausgesprochen wurde. Die größte Gefahr ist dort die falsch verstandene Anforderung, seltener die schwierige Technik. Ein Team kann einen Algorithmus aufwendig optimieren und eine Datenbank sauber umbauen, und am Ende stellt sich heraus, dass die ganze Arbeit ein Problem gelöst hat, das niemand hatte, während das eigentliche Problem unberührt blieb. Diese Sorte Fehlschlag ist im gewachsenen System häufiger als der spektakuläre technische Zusammenbruch, und sie ist leiser, weil sie erst spät auffällt.

Die Business-Analyse ist die Rolle, die diesen Fehlschlag verhindern soll. Sie steht zwischen dem, was die Fachseite will, und dem, was die Technik baut, und schließt die Lücke zwischen beidem, bevor jemand Code schreibt. Im agentischen Arbeiten ist diese Aufgabe der wichtige Schlüssel, weil ein Agent in Minuten eine plausible Anforderung formulieren kann, die sich liest, als hätte ein Mensch sie durchdacht. Eine plausible Anforderung kann trotzdem falsch sein, und im Altsystem entscheidet das über den Erfolg.

Die alte Zielvorstellung

Die beschriebene Aufgabe ist kein neues Berufsbild. Gute Business-Analyse sollte schon immer genau das leisten. Sie sammelt Fachwissen, prüft Aussagen, macht Widersprüche sichtbar, formuliert Anforderungen testbar und bereitet ein Ticket so vor, dass Entwicklung ohne Ratespiel arbeiten kann. Dieses Ziel stand in den alten Pflichtenheften des Wasserfalls oft sehr klar. Erreicht wurde es im Alltag selten. Der Grund lag häufig in den Bedingungen der Projekte. Unter Projektdruck wurde Recherche gekürzt. Riesige Datenbestände blieben nur ausschnittweise durchsucht. Fachliche Zusammenhänge mussten aus alten Tickets, verstreuten Dokumenten, gewachsenen Sonderfällen und Gesprächen zusammengesetzt werden. Wer trotzdem sauber dokumentieren wollte, brauchte Zeit, die im Projektplan selten vorgesehen war. So entstanden unvollständige Anforderungen, obwohl die Beteiligten wussten, wie eine gute Anforderung aussehen müsste.

Mit Agenten ändert sich die Ökonomie dieser Arbeit. Der Anspruch bleibt derselbe, doch die Fleißarbeit wird billig: Quellen suchen, Varianten gegeneinander legen, Glossare vorbereiten, Akzeptanzkriterien normieren, Beispiel- und Testdaten erzeugen, offene Fragen tabellieren. Vollständigkeit braucht dann keine tagelange Dokumentarbeit mehr. Sie entsteht aus vielen kleinen, überprüften Agentenschritten. Dadurch gewinnt die BA den Teil ihrer Arbeit zurück, der im Projektdruck oft zu kurz kam: fachliche Zusammenhänge herstellen, gute Fragen formulieren, Nutzungsfälle durchdenken und die Grenzen eines Features sauber ziehen. Sie wird zur fachlichen Orchestratorin eines Wasserfall-Tickets. Sie bedient den Agenten, prüft seine Vorschläge, entscheidet über Belege und hält das Ticket so vollständig, dass Entwicklung, UX und Test daran anschließen können. Das knüpft an das an, was ich im Beitrag über die Rückkehr zum Wasserfall beschrieben habe: Die Maschine nimmt der BA die Such- und Schreiblast ab. Für Urteil, Kreativität und Verantwortung bleibt mehr Raum.

Die menschliche Fähigkeit: das Urteil über Quellen

Was eine Business-Analystin mitbringt und ein Sprachmodell nicht hat, ist das Urteil darüber, was eine Quelle wert ist. Eine erfahrene BA liest ein altes Ticket und erkennt, dass die darin beschriebene Anforderung längst von einer späteren Entscheidung überholt wurde. Bei einer Confluence-Seite merkt sie, dass diese ein Wunschbild beschreibt, das so nie umgesetzt wurde. Im Gespräch mit einer Sachbearbeiterin hört sie zwischen den Zeilen, dass die offizielle Prozessbeschreibung und die tatsächliche Praxis auseinanderfallen. Sie unterscheidet, was belegt ist, von dem, was nur plausibel klingt, und von dem, was sich zwischen zwei Quellen widerspricht.

Ein Sprachmodell kann das nicht zuverlässig, und das liegt in seiner Natur. Ein Modell approximiert Sprache. Es erzeugt Text, der zu dem passt, was es im Prompt gesehen hat, und ein belegter Fakt klingt darin exakt so überzeugend wie eine geschickt formulierte Vermutung. Beide bestehen aus denselben grammatischen Bausteinen und klingen gleich gewiss. Ob eine Aussage in der Welt wahr ist, kann das Modell nicht beurteilen; es sieht nur, ob sie sprachlich wahrscheinlich ist. Im Brownfield-Kontext, wo Belege selten und Annahmen häufig sind, ist diese Blindheit gegenüber dem Wahrheitswert das zentrale Risiko.

Hinzu kommt die Perspektive. Eine gute BA denkt das Ergebnis aus der Sicht derjenigen, die mit dem System arbeiten, etwa der Sachbearbeiterin oder dem Kunden. Sie fragt, was diese Person erreichen will und woran sie merkt, dass sie es erreicht hat. Ein Modell, das nicht angeleitet wird, denkt aus der Sicht des Systems, weil im Trainingsmaterial die Systemsicht dominiert. Es beschreibt, was eine Funktion validiert; was eine Person tun können soll, bleibt außen vor. Diese Verschiebung der Perspektive ist subtil und zugleich folgenreich, weil sie die Verantwortung für den Erfolg von der Fachseite an die Technik abgibt, wo sie nicht hingehört.

Dazu kommt das Gespräch mit Stakeholdern. Eine BA hört einer Fachexpertin zu und erkennt, wenn das, was als eine Anforderung formuliert wird, in Wahrheit zwei sind, die nur zufällig zusammen genannt wurden. Hinter einer technisch klingenden Bitte steckt manchmal ein ganz anderes fachliches Bedürfnis, und auch das fällt ihr auf. Sie merkt, wenn eine Anforderung still voraussetzt, dass das gewachsene System sich auf eine bestimmte Weise verhält, und dass diese Voraussetzung geprüft werden muss. Dieses Zerlegen und Hinterfragen geschieht im Gespräch, im Hin und Her zwischen Menschen, und es ist die Stelle, an der ein Agent am wenigsten ersetzen kann.

Vier Grundprinzipien der Rolle

An vier Prinzipien lässt sich jeder Output der Rolle messen.

Die belegte Wahrheit liefern. Die Business-Analyse liefert eine belegte Wahrheit und überlässt die Lösung der Entwicklung. Ihre Aufgabe ist es zu beschreiben, was passieren soll und warum, für wen und mit welchem Nutzen. Wie es gebaut wird, entscheidet die Entwicklung, und sie entscheidet es erst nach einer Prüfung des Brownfields, die die BA gar nicht leisten kann, weil sie den Code nicht in der Tiefe kennt und auch nicht bewerten kann. Eine BA, die eine technische Lösung vorgibt, nimmt der Entwicklung das Urteil ab, das nur dort getroffen werden kann, und sie tut das meist, ohne die Folgen zu überblicken.

Jede Aussage ist etikettiert. In einem BA-Output gibt es keinen ungelabelten Fließtext. Jede Behauptung trägt eine von vier Marken: einen [Fakt] für etwas Belegbares mit benannter Quelle, eine [Annahme] für etwas Plausibles ohne Beleg, eine [Frage] für etwas Offenes, das noch geklärt werden muss, und einen [Widerspruch] für eine Stelle, an der zwei Quellen einander nicht zustimmen. Glatter, unmarkierter Text ist eine bloße Zusammenfassung und genügt nicht. Eine Zusammenfassung verwischt gerade die Unsicherheiten und Widersprüche, die das eigentliche Risiko ausmachen.

Maßgeblich ist das Ticket. Der Chatverlauf ist flüchtig, und was in einer Agent-Sitzung erarbeitet wird, aber nicht ins Ticket wandert, ist für den weiteren Verlauf verloren. Das ist der Artefakt-Kontrakt aus dem Auftakt-Beitrag, hier in seiner konkreten Form für diese Rolle. Eine Entwicklerin, die das Feature umsetzt, arbeitet mit dem Ticket. Was darin fehlt, fehlt für sie ganz, denn den Diskussionsverlauf sieht sie nicht.

E2E-Inhalte entstehen vor der Übergabe. Ein Ticket ist erst reif für die Entwicklung, wenn es den fachlichen Stoff für den späteren End-to-End-Test enthält. Dazu gehören Szenarien, Platzhalterdaten, erwartete Meldungstexte, Ausgangs- und Zielzustände, Rollenwechsel sowie relevante Übergaben an Nachbarsysteme. Das sind noch keine ausführbaren Tests. Die BA liefert die Inhalte, aus denen die Testrolle später Browser- und Workflow-E2E-Spezifikationen macht.

Wie der Agent die Rolle unterstützt

Der Agent ist in dieser Rolle ein Arbeitsapparat der BA. Er recherchiert, sortiert, formuliert Rohfassungen und erzeugt die Inhalte, aus denen später Entwicklung und Test arbeiten. Er entscheidet nichts. Er nimmt der BA den mechanischen Anteil ab. Die BA steuert ihn über präzise Aufträge, überprüft die Ergebnisse und verwirft, was nur plausibel wirkt. Wer diese Rolle ausfüllt, braucht daher weiterhin Fachwissen. Dazu kommt eine neue handwerkliche Fähigkeit: den Agenten so zu führen, dass am Ende ein vollständiges, prüfbares Ticket entsteht und kein Gesprächsprotokoll.

Der Agent arbeitet in der frühen Phase, die in der Pipeline Discovery heißt, also der Voruntersuchung, in der das Team versteht, worum es geht, bevor es festlegt, was zu tun ist. Seine erste Aufgabe ist der Aufbau eines Quelleninventars.

Ein Quelleninventar ist eine Liste aller Stellen, die etwas über den betroffenen Bereich aussagen, und jede Stelle bekommt eine Kennung, einen Titel und ein Stand-Datum im Format JJJJ-MM-TT. Das Datumsformat ist eine Regel mit Konsequenz. Vage Angaben wie “aktuell” oder “kürzlich aktualisiert” sind nicht erlaubt, denn im System wirkt eine vor drei Jahren verlassene Confluence-Seite genauso frisch wie eine eben überarbeitete. Erst das konkrete Datum macht den Unterschied sichtbar, der im Bestandssystem oft darüber entscheidet, ob eine Aussage noch gilt oder längst überholt ist.

Der Agent liest dafür viele Quellen. Er liest Tickets aus dem Vorgangssystem, Confluence-Seiten, Architecture Decision Records, also die dokumentierten Architekturentscheidungen, Runbooks, die beschreiben, wie ein System betrieben wird, alte Dokumentation und den Code selbst. Diese Breite ist seine Stärke. Ein Mensch braucht Tage, um sich durch verstreute Altdokumentation zu lesen; ein Agent legt in kurzer Zeit ein Inventar an, das eine BA dann prüfen kann. Hier verstärkt das Werkzeug die Rolle echt, weil es eine mühsame, aber notwendige Fleißarbeit beschleunigt.

Was der Agent nicht leistet, ist die Bewertung. Jede Erkenntnis, die er aus den Quellen zieht, muss die BA etikettieren. Der Agent kann einen Vorschlag machen, er kann sagen, diese Aussage stützt sich auf Ticket TICKET-417 von 2024-03-12, also schlage ich [Fakt] vor. Aber die Marke setzt der Mensch, weil nur der Mensch beurteilen kann, ob das Ticket noch gilt, ob es überholt wurde, ob es vielleicht nur einen Wunsch dokumentiert hat, der nie Realität wurde. Das Etikettieren ist die analytische Kernleistung der Rolle, und es bleibt beim Menschen.

Eine Eigenheit dieser Rolle läuft der Erwartung an ein Sprachmodell zuwider: Die glatte, gut lesbare Zusammenfassung ist hier ausdrücklich nicht das Ziel. Ein Modell ist darauf trainiert, eine widerspruchsfreie, runde Darstellung zu liefern, was in der Discovery schädlich ist. Eine runde Zusammenfassung glättet genau die Widersprüche, in denen das eigentliche Risiko steckt. Wenn zwei Quellen sich widersprechen, soll der Output den Widerspruch zeigen, mit beiden Seiten und der Marke [Widerspruch], statt eine dritte, harmonische Formulierung zu erfinden, die so tut, als gäbe es kein Problem. Die Aufgabe der Discovery ist es, die Widersprüche transparent zu machen.

Danach wird der Agent zum Produktionswerkzeug für die E2E-Inhalte. Er kann aus Akzeptanzkriterien fachliche Szenarien vorschlagen, Mustermann-Daten erzeugen, erwartete Meldungen auf Konsistenz prüfen und Prozessvarianten nebeneinanderlegen. Die BA entscheidet, welche dieser Vorschläge die fachliche Wirklichkeit treffen. Der Agent liefert Masse und Varianten. Die BA macht daraus verbindliche Inhalte für das Ticket.

Das Zusammenspiel mit UX im Feature-Workshop

Die Business-Analyse arbeitet eng mit UX zusammen, der Rolle, die beschreibt, wie sich ein Feature für die Nutzerinnen und Nutzer anfühlt. In der Pipeline treffen sich beide in einem Feature-Workshop, und dieser Workshop hat eine feste Form, die verhindert, dass man sich vorschnell auf eine Formulierung einigt, die nur an der Oberfläche stimmt.

Der Workshop beginnt damit, dass BA und UX das Feature unabhängig in eigenen Worten beschreiben. Jede Seite notiert das Ziel, den Nutzer oder die Nutzerin, den Nutzen, die Grenzen und die offenen Fragen. Das geschieht zunächst getrennt, weil die Unterschiede zwischen beiden Beschreibungen die interessanten Stellen sind. Wo BA und UX dasselbe Feature verschieden verstehen, liegt eine Unklarheit, die geklärt werden muss, bevor jemand weiterarbeitet. Aus den beiden Beschreibungen entsteht dann eine gemeinsame Team-Vorlage, ein abgestimmtes Bild des Features, auf das sich beide Rollen verständigt haben.

Ein zentraler Teil dieser gemeinsamen Arbeit ist die Definition der UX-Zustände. Ein Feature hat nicht nur den einen Verlauf, in dem alles gut geht. Es hat mehrere Zustände, die alle beschrieben werden müssen, und die Pipeline benennt sie ausdrücklich. [UX-ERFOLG] ist der Fall, in dem die Aufgabe gelingt. [UX-LEER] meint den Fall, in dem noch keine Daten da sind, eine leere Liste, ein frischer Datensatz. [UX-FEHLER] ist der Fall, in dem etwas schiefgeht. [UX-LADE] beschreibt den Zustand während des Wartens auf eine Antwort. [UX-EDGE] steht für die Randfälle, die selten auftreten, aber dann das Verhalten bestimmen.

Der Fehlerfall wird in der Praxis am häufigsten vergessen und verrät zugleich am meisten. [UX-FEHLER] beschreibt eine fachliche Meldung in Geschäftssprache. Wenn eine Sachbearbeiterin einen Schaden ohne eine notwendige Angabe speichern will, soll sie eine Meldung lesen, die in ihrer Sprache erklärt, was fehlt und warum es fehlt, und keinen technischen Code wie “Validierungsfehler in Feld 0x2F”. Diese Anforderung ist eine fachliche, und sie gehört deshalb in den BA-Teil der Beschreibung. Wie die Meldung technisch ausgelöst wird, ist Sache der Entwicklung; ihr Wortlaut und ihre Sprache gehören zur Fachseite.

Erst nachdem das Team diese gemeinsame Beschreibung geprüft und für stimmig befunden hat, werden die Tickets ins Vorgangssystem hochgeladen. Diese Reihenfolge ist bewusst gewählt: Nicht jeder Einfall wird sofort als Ticket angelegt, weil ein vorschnell angelegtes Ticket eine Verbindlichkeit suggeriert, die noch gar nicht erreicht ist. Erst der Team-Check macht aus einem Entwurf ein Ticket, das die nächste Rolle ernst nehmen kann.

Was die Rolle als Artefakte produziert

Das zentrale Artefakt der Business-Analyse ist das BA-Ticket. Es hat eine feste Struktur, und diese Struktur ist die Form, in der eine belegte Wahrheit übergeben werden kann. Jede Sektion hat einen praktischen Zweck, und auch die Reihenfolge der Sektionen hat ihren Sinn.

Das Ticket beginnt mit einem Header. Darin steht das Outcome, also das Ergebnis aus Nutzersicht, und dieses Outcome beginnt mit einer Persona oder einer Aktion: “Die Sachbearbeiterin kann …”. Diese Formulierung ist eine Probe. Wenn sich das Ergebnis so formulieren lässt, dass eine handelnde Person am Anfang steht und eine Fähigkeit folgt, dann ist es aus Nutzersicht gedacht. Wenn der Satz dagegen mit “Das System …” beginnt, ist er aus Systemsicht gedacht, und das ist ein Warnzeichen. Neben dem Outcome stehen im Header die Persona, der Trigger, also was das Feature auslöst, die Stakeholder und der Quellen-Stand.

Auf den Header folgt der Body in einer festen Reihenfolge von Sektionen. Zuerst das Problem oder der Bedarf: Warum gibt es dieses Feature überhaupt, welches fachliche Bedürfnis steht dahinter? Dann die Akzeptanzkriterien, formuliert als Given/When/Then in Geschäftssprache und einzeln nummeriert, [AC-1], [AC-2], und so fort. Given/When/Then ist ein einfaches Schema: Gegeben eine Ausgangslage, wenn eine Handlung geschieht, dann ein erwartetes Ergebnis. In Geschäftssprache heißt das, dass dort fachliche Begriffe stehen und keine technischen. Die Einzelnummerierung ist wichtig, weil sie jedes Kriterium prüfbar und referenzierbar macht; ein verschachteltes Kriterium, das drei Dinge auf einmal verlangt, ist in Wahrheit drei Kriterien und gehört aufgeteilt.

Danach kommen die UX-Zustände aus dem Workshop, dann die Nicht-Ziele. Die Nicht-Ziele sind eine eigene, oft unterschätzte Sektion. Sie schließen häufige Annahmen aktiv aus. Wenn ein Feature ein neues Pflichtfeld einführt, dann ist die Annahme naheliegend, dass auch der bestehende Datenbestand dieses Feld bekommen muss. Eine solche Annahme gehört unter die Nicht-Ziele, ausdrücklich verneint, damit niemand sie still mitliest. Was nicht ausgeschlossen wird, interpretiert im Zweifel jemand hinein, und im Brownfield sind solche stillen Mitannahmen erfahrungsgemäß die teuersten.

Es folgt das Quelleninventar, also die Liste der Quellen mit ihren Stand-Daten, und danach die Aussagenliste, in der jede Behauptung ihre Marke trägt und bei einem [Fakt] die Quelle benannt ist. Dann die offenen Fragen, und zwar als Tabelle. Jede Frage bekommt eine Kennung [Q-1], eine Formulierung der Frage, einen Owner, also eine namentlich verantwortliche Person, die sie beantworten soll, einen Antworttermin und eine Angabe, was passiert, wenn die Frage unbeantwortet bleibt. Diese letzte Spalte ist die wichtigste, weil sie die Frage gewichtet. Eine offene Frage, deren Nichtbeantwortung das ganze Feature blockiert, wiegt schwerer als eine, die nur ein Detail offenlässt, und die Tabelle macht diesen Unterschied sichtbar. Den Abschluss bilden die E2E-Inhalte, die Stakeholder und die Freigabe.

Zum BA-Ticket gehören mehrere Pflicht-Artefakte. Eine UX-Skizze, die den Workshop-Befund visuell festhält. Ein Snippet, also ein kleines konkretes Beispiel des erwarteten Verhaltens. Ein Glossar, das die fachlichen Begriffe definiert, und dieses Glossar hat im Brownfield-Kontext eine zusätzliche Spalte für das Pendant im Nachbarsystem. Wo ein Begriff über Systemgrenzen hinweg lebt, soll dort stehen, wie er im anderen System heißt; wo kein Pendant bekannt ist, steht ein Strich und eine offene Frage. Schließlich gehören die E2E-Inhalte dazu: Beispieldaten mit Platzhaltern, fachliche Szenarien, erwartete Meldungen und die Zustände, die der spätere Test nachweisen soll. Echte Personen, Firmen oder Vorgangsnummern kommen darin nicht vor.

Diese E2E-Inhalte sind eine Grundvoraussetzung für die Weitergabe an die Entwicklung. Sie sind noch kein Testplan und kein Testskript. Sie beschreiben den fachlichen Weg, den ein späterer Test belegen muss. Fehlt dieser Stoff, muss die Entwicklung beim Planen erraten, welche Zustände und Übergänge am Ende sichtbar geprüft werden sollen. Dann ist das Ticket für die Umsetzung zu früh.

Brownfield-Spezifika: was im Brownfield anders ist

Eine Business-Analyse im gewachsenen System unterscheidet sich von einer auf der grünen Wiese, und zwar in der Art der Aufgabe selbst. Drei Unterschiede sind so wichtig, dass die Pipeline sie als feste Regeln verankert.

Der Bestandsschutz vor Migrationszwang steht am Anfang. Ein neues Feature soll bestehende Daten nicht automatisch migrieren oder validieren; neue Pflichten greifen nur für Datensätze, die neu angelegt oder aktiv bearbeitet werden, während der Altbestand lesbar und speicherbar bleibt. Diese Trennung ist eine fachliche Entscheidung mit großer Wirkung. Fehlt sie, rutscht eine Datenmigration unausgesprochen in ein Feature-Ticket, obwohl sie ein eigenes Vorhaben ist, mit eigenen Stakeholdern, eigenem Risikoprofil und eigenem Zeitplan. Behandelt man sie als Nebensache, gerät der Zuschnitt des Tickets durcheinander, und das Feature dauert am Ende deutlich länger als geplant. Die BA hält diese Trennung deshalb ausdrücklich in den Nicht-Zielen fest.

Die zweite Eigenheit betrifft das Mapping der systemübergreifenden Begriffe, das beim Glossar schon angeklungen ist. In gewachsenen Systemen teilt ein System fast immer Daten mit anderen, und ein Begriff wie Partner, Vorgang oder Rolle kann in jedem davon etwas leicht anderes bedeuten. Solange diese Beziehung nirgends benannt ist, bleibt sie eine versteckte Fehlerquelle. Die BA muss die Cross-System-Begriffe explizit mappen, auch dann, wenn das aktuelle Feature gar keine systemübergreifende Wirkung hat, weil die nächste Änderung sie haben könnte und die Mehrdeutigkeit dann schon im Weg steht.

Am strengsten ist die Regel, dass im BA-Ticket keine technische Vorgabe stehen darf, also weder Architektur noch Datenmodell, keine Spaltennamen und keine Wahl eines Frameworks. Nach der Übergabe führt die Entwicklung eine Machbarkeitsprüfung gegen das Brownfield durch: Sie schaut, an welchen Stellen im gewachsenen Code dieselbe Logik hängt, was sich wiederverwenden lässt und was eine Änderung an einer Stelle drei Stellen weiter auslöst. Schreibt das BA-Ticket schon eine technische Lösung vor, macht es diese Prüfung wertlos, weil die Entwicklung dann nur noch eine Vorgabe abarbeitet, die jemand ohne Kenntnis des Codes gesetzt hat. In meiner Erfahrung ist die technische Vorgabe im fachlichen Ticket der häufigste Grund dafür, dass die Entwicklung ein Ticket zurückgibt. Die BA beschreibt also, was passieren soll und warum, und überlässt die Frage, wie es umgesetzt wird, der Entwicklung.

Das Quality Gate: Definition of Ready

Zwischen der Business-Analyse und der Entwicklung steht ein Prüfpunkt, in der Pipeline Definition of Ready genannt, kurz DoR, oder auch Ready for Dev. Es ist die Stelle, an der ein Mensch entscheidet, ob das Ticket reif ist, in die Umsetzung zu gehen. Das Gate hat eine Prüfliste, und die Prüfung übernimmt bewusst ein Mensch, weil es um Urteilsfragen geht, die sich maschinell nicht beantworten lassen.

Die Prüfliste fragt:

• ob das Outcome ein eindeutiger Satz ist, der mit einer Persona oder einer Aktion beginnt und sich aus Nutzersicht testen lässt;
• ob die Akzeptanzkriterien einzeln nummeriert und in Geschäftssprache formuliert sind, ohne technische Begriffe;
• ob die UX-Zustände vorhanden sind, einschließlich des Fehlerfalls in fachlicher Sprache;
• ob das Quelleninventar Stand-Daten hat und kein “aktuell” enthält;
• ob die Aussagen etikettiert sind, jede mit ihrer Marke, und bei jedem [Fakt] die Quelle benannt ist;
• ob die E2E-Inhalte vollständig sind, also fachliche Szenarien, Mustermann-Daten, erwartete Meldungen, Ausgangs- und Zielzustände sowie relevante Übergaben an Nachbarsysteme;
• ob die Pflicht-Artefakte im Repository liegen, also UX-Skizze, Snippet, Glossar mit Nachbarsystem-Spalte und E2E-Inhalte;
• ob das Ticket frei von technischer Lösung ist.

Das Pflichtartefakt dieses Gates ist zweiteilig: das etikettierte Quelleninventar und das fertige Ticket mit E2E-Inhalten. Beide müssen vorliegen, sonst ist die Frage des Gates nicht beantwortbar. Das Quelleninventar belegt, dass die Wissensbasis ehrlich ist, mit ihren Lücken und Widersprüchen, und das Ticket zeigt, dass aus dieser Basis eine prüfbare Anforderung geworden ist.

Die wichtigste Eigenschaft des Gates ist seine Härte. Fehlt ein Punkt, geht das Ticket zurück. Es wird nicht still weiterverarbeitet und nicht mit einem mündlichen “das klären wir später” durchgewunken, auch nicht in der Annahme, die Entwicklung werde die Lücke schon füllen. Eben diese stille Weiterverarbeitung schleppt Fehler tief in die Kette hinein, wo sie teuer werden. Ein Ticket, das die Definition of Ready nicht besteht, ist nicht fertig, und ein nicht fertiges Ticket beginnt keine Umsetzung. Diese Strenge mag im Moment lästig wirken. Sie hält die Fehlerkosten aber niedrig, weil die Korrektur noch im Text geschieht, solange das System noch nicht läuft.

Wie die Compliance-Regeln in dieser Rolle wirken

Die Compliance-Anforderungen, die der Auftakt-Beitrag als sechstes Prinzip beschrieben hat, sind in die Arbeitsweise der Business-Analyse eingebaut. In dieser Rolle wirken sie an vier konkreten Stellen.

Datenminimierung. In der Softwareentwicklung heißt das, dass personenbezogene Daten dort nicht hingehören. Die Beispieldaten im BA-Ticket sind deshalb ausschließlich Platzhalter, Mustermann GmbH, Erika Mustermann, Max Mustermann. Ein BA-Ticket landet irgendwann in einer Schulung, einer Präsentation, einem Export oder einem geteilten Arbeitsbereich. Wer von Anfang an mit Platzhaltern arbeitet, muss echte Daten nicht hinterher herausfiltern, eine Aufräumarbeit, bei der ohnehin selten alle Stellen erwischt werden. Der Projektkontext, mit dem der Agent arbeitet, enthält nur das fachlich Nötige, als Klartext, ohne reale Daten.

Quellen mit Stand-Datum. Dass jede Quelle ein Stand-Datum hat und es kein “aktuell” gibt, ist nicht nur eine Frage der Sorgfalt, sondern auch der Nachvollziehbarkeit. Wer später prüfen will, auf welcher Wissensbasis eine Anforderung entstanden ist, findet im Quelleninventar datierte Belege statt vager Verweise. Das ist die Provenienz, die ein Audit-Trail braucht, in der einfachsten denkbaren Form.

Markierung der KI-erzeugten Inhalte. Der EU AI Act, die Verordnung 2024/1689, verlangt Transparenz über den Einsatz von KI. In dieser Rolle bedeutet das, dass jedes vom Agenten erzeugte Stück als KI-erzeugt markiert wird, mit einem Vermerk, der auf die Operation, die verantwortliche Person und die Version des Modells oder der Anweisung verweist. Wenn der Agent einen Vorschlag für eine Aussagen-Etikettierung gemacht hat, ist nachvollziehbar, dass der Vorschlag von einem Modell kam und ein Mensch ihn bestätigt oder korrigiert hat. Die Marke selbst setzt der Mensch, der Vorschlag kommt markiert vom Agenten, und beides steht in der Spur.

Das DoR-Gate als menschliche Freigabe. Der Grundsatz der gesamten Pipeline lautet, dass der Agent vorschlägt und der Mensch entscheidet, und die menschliche Aufsicht gilt ausnahmslos. Das DoR-Gate ist der Ort, an dem diese Aufsicht in der Business-Analyse konkret wird. Eine namentlich verantwortliche Person bestätigt das Ticket, bevor es weitergeht, und sie steht damit für seinen Inhalt gerade. Die Unterstützung durch den Agenten mindert diese Verantwortung nicht. Ein Ticket, das ein Modell vorgeschlagen und ein Mensch nur abgenickt hat, ohne es zu prüfen, verletzt diesen Grundsatz, auch wenn formal eine Freigabe vorliegt. Eine Freigabe zählt nur, wenn ihr eine echte Prüfung vorausgegangen ist.

Ein durchgespieltes Beispiel

Ein kurzes Beispiel mit Platzhaltern zeigt, wie die Regeln zusammenwirken. Eine Fachabteilung der Mustermann GmbH meldet einen Bedarf: Bei der Erfassung eines Vorgangs soll künftig eine bestimmte Angabe verlangt werden, die bisher freiwillig war. Bei diesem ersten Satz würde ein vorschnelles Vorgehen sofort ein Ticket anlegen, das ein neues Pflichtfeld verlangt.

Die Business-Analyse beginnt anders. Der Agent baut das Quelleninventar, findet ein altes Ticket von 2023, das die Angabe einmal als optional eingeführt hat, eine Confluence-Seite von 2024, die einen Prozess beschreibt, und Hinweise im Code darauf, wie die Angabe heute gespeichert wird. Nun etikettiert die BA. Dass die Angabe heute optional ist, belegt durch Ticket und Code, ist ein [Fakt]. Ein zweiter [Fakt] stammt aus dem Gespräch: Die Fachabteilung verlangt sie für alle künftigen Vorgänge. Ob auch die bestehenden Vorgänge sie bekommen sollen, hat niemand ausgesprochen; das bleibt eine [Annahme], die geprüft werden muss. Und die Confluence-Seite beschreibt einen Prozess, der mit der tatsächlichen Praxis der Sachbearbeitung nicht übereinstimmt, ein [Widerspruch].

Aus dieser etikettierten Basis entsteht das Ticket. Das Outcome: “Die Sachbearbeiterin kann einen Vorgang nur dann abschließen, wenn die Angabe vorhanden ist, und erhält andernfalls eine fachliche Meldung, die erklärt, welche Angabe fehlt.” Ein Akzeptanzkriterium [AC-1] beschreibt den Erfolgsfall, [AC-2] den Fehlerfall in Geschäftssprache. Der UX-Zustand [UX-FEHLER] formuliert die Meldung in fachlicher Sprache. Unter den Nicht-Zielen steht ausdrücklich: Der Datenbestand wird nicht verändert, bestehende Vorgänge ohne die Angabe bleiben gültig und speicherbar, eine Migration ist nicht Teil dieses Tickets. Die offene Frage [Q-1] in der Tabelle: Sollen bestehende Vorgänge bei der nächsten Bearbeitung nachgepflegt werden, Owner die Fachabteilung, mit Termin und der Notiz, dass eine Bejahung ein eigenes Migrationsvorhaben auslöst. Der [Widerspruch] zwischen Confluence-Seite und Praxis wird in der Aussagenliste festgehalten, damit die Entwicklung ihn nicht ahnungslos überschreibt.

Für den E2E-Test produziert die BA außerdem den fachlichen Inhalt. Erika Mustermann legt für die Mustermann GmbH einen Vorgang an. Die notwendige Angabe fehlt. Beim Abschluss erscheint die Meldung in Geschäftssprache, der Vorgang bleibt im bearbeitbaren Zustand, und die Übergabe an das Nachbarsystem findet in diesem Zustand nicht statt. Diese Angaben sind bewusst konkret, denn der spätere Test braucht sichtbare Inhalte und erwartete Zustände. Die Entwicklung sieht damit schon vor der Umsetzung, welches Verhalten am Ende belegt werden muss.

Was hier nicht im Ticket steht, ist mindestens so wichtig wie das, was darin steht. Es steht kein Spaltenname darin und keine Vorgabe, ob die Prüfung im Frontend oder im Backend geschieht, auch keine Wahl einer Bibliothek. Diese Entscheidungen trifft die Entwicklung nach ihrer Machbarkeitsprüfung, sobald das Ticket bei ihr liegt.

Ausblick

Der nächste Beitrag der Serie wendet sich der Entwicklung zu. Dort wird sich zeigen, was aus einem BA-Ticket wird, das die Definition of Ready bestanden hat: wie die Entwicklung das Brownfield gegen die Anforderung prüft, wie aus dem Was ein Wie wird, wie aus dem Epic die kleinen, einzeln umsetzbaren Tickets entstehen und wie ein Agent über viele Schritte hinweg arbeiten kann, ohne die Kontrolle zu verlieren. Die Übergabe zwischen Business-Analyse und Entwicklung ist die Stelle, an der sich entscheidet, ob die saubere Vorarbeit hält, und sie ist der Grund, warum das DoR-Gate so streng ist, wie es ist.

Die Rolle der Business-Analyse lässt sich mit einer einzigen Übung erproben, noch bevor der nächste Beitrag erscheint. Nehmen Sie die nächste Anforderung, die auf Ihrem Tisch landet, und etikettieren Sie jeden Satz darin. Was davon ist ein Fakt mit Quelle, was eine Annahme, was eine offene Frage, was ein Widerspruch? Meist wird die Liste der Annahmen und Fragen länger, als Ihnen lieb ist, und das rechtfertigt die Rolle. Eine Anforderung, die sich vollständig in belegte Fakten auflösen lässt, ist selten; viel häufiger zeigen sich beim Etikettieren ein paar Annahmen, die man für längst geklärt hielt.