Dazu Akzeptanzkriterien, Tests, Epics und eine über Jahre gewachsene Dokumentation.

Eigentlich hätte damit ein ziemlich vollständiges Bild des gewünschten Systems vorhanden sein müssen.

War es aber nicht.

Viel Inhalt bedeutete noch keine Klarheit

Die einzelnen User Stories beschrieben viele konkrete Funktionen. Jede Story konnte für sich verständlich und richtig sein. Trotzdem blieben einige einfache Fragen offen:

Hatten wir wirklich alles beschrieben?

Wo gab es Lücken?

Welche Aussagen widersprachen sich?

Und wo hatten sich Fehler oder veraltete Informationen eingeschlichen?

Je größer der Bestand wurde, desto schwieriger wurden diese Fragen. Die Menge vermittelte zunächst Sicherheit. Sie sagte aber noch nichts darüber aus, ob das vorhandene Wissen vollständig war und zusammenpasste.

Das war kein Vorwurf an das agile Vorgehen. Eine User Story beschrieb einen umsetzbaren Ausschnitt. Sie war nicht dafür gedacht, das gesamte System zu erklären.

Die Probleme lagen häufig zwischen den Stories

Manche Begriffe wurden in mehreren Stories verwendet, aber unterschiedlich verstanden. Zusammenhänge waren nur indirekt beschrieben. An anderen Stellen wurde Wissen vorausgesetzt, das nirgends festgehalten war.

Eine Änderung war in einer Story beschrieben. Dabei wurde festgehalten, welche Funktion angepasst oder erweitert werden sollte und welches konkrete Verhalten anschließend erwartet wurde. Die möglichen Auswirkungen auf andere Bereiche des Systems blieben jedoch offen. Es war nicht eindeutig dokumentiert, ob beispielsweise abhängige Funktionen, Schnittstellen, Datenflüsse oder bestehende Abläufe ebenfalls überprüft werden mussten.

Ein Gherkin-Testszenario prüfte lediglich eine einzelne Erwartung innerhalb eines bestimmten Anwendungsfalls.

Die Lücken lagen deshalb nicht immer in den einzelnen Stories. Sie lagen häufig dazwischen.

Genau dort entstanden auch Widersprüche und Fehler. Bei der Betrachtung einer einzelnen Story fielen sie kaum auf.

Wir brauchten ein Gesamtbild

Um diese Fragen beantworten zu können, reichte es nicht, jede Story einzeln zu prüfen.

Wir mussten verstehen, warum etwas existierte. Wir mussten erkennen, was zusammengehörte. Und wir mussten sehen können, welche Auswirkungen eine Änderung auf andere Stellen hatte.

Dafür brauchten wir ein zusammenhängendes Gesamtbild. Es sollte zeigen, was wir bereits wussten. Es sollte aber auch sichtbar machen, wo etwas fehlte, sich widersprach oder nicht zusammenpasste.

Ein Frontier LLM konnte uns dabei unterstützen. Es konnte große Mengen an Informationen gleichzeitig auswerten, ähnliche Aussagen erkennen und auf mögliche Widersprüche hinweisen.

Es konnte aber nicht automatisch alles finden. Fehlende Informationen standen in keiner Quelle. Wissen, das nur in den Köpfen vorhanden war, blieb unsichtbar. Selbst präzise Vorgaben und Leitplanken reichten nicht. Das Frontier LLM verfolgte zu viele mögliche Spuren gleichzeitig. Es protokollierte mehr, als dass es belastbare Ergebnisse lieferte.

Mit FIN-AI gingen wir deshalb einen Schritt weiter. Wir kombinierten das Frontier LLM mit einem methodischen Vorgehen aus Business Architecture und Business Analyse. Die Methodik gab vor, welche Werkzeuge wir wann einsetzten. Sie bestimmte, welche Informationen wir herausarbeiten und welche Zusammenhänge wir prüfen mussten. Das Frontier LLM übernahm die breite Auswertung. Die Ergebnisse prüften wir gemeinsam mit den Menschen, die das System und die fachlichen Abläufe kannten.

Ein Frontier LLM fand viel. Erst die Methodik machte daraus geordnete, prüfbare und belastbare Ergebnisse.

Wie dieser Ansatz aufgebaut war und wie daraus Schritt für Schritt ein belastbares Gesamtbild entstand, berichte ich nächstes Mal.

Wie stellt ihr heute sicher, dass ein KI-Ergebnis nicht nur plausibel klingt, sondern auch vollständig und fachlich belastbar ist?