Jede Phase läuft in kurzen Iterationen, in denen alle Disziplinen zusammenarbeiten, nicht nacheinander. Phasen überlappen sich während des gesamten Projektlebenszyklus.
Ein Diagramm, das zeigt, wie die vier Phasen ineinandergreifen, von den ersten Anforderungen bis zur Produktion. Die Farben markieren die Phasen: Blau für Anfang, Grün für Ausarbeitung, Rot für Konstruktion, Orange für Übergang.
Der Name ist Absicht. Der Unified Process der späten 1990er hatte die Grundlagen richtig: Use Cases als zentrale Artefakte, vier Phasen, kurze Iterationen, Architektur zuerst. Der AI Unified Process führt dieses Erbe weiter als Use-Case-getriebene Entwicklung (Use-Case-Driven Development, UCDD) und architekturzentrierte Entwicklung (Architecture-Centric Development, ACD). Was dem Original fehlte, war ein Weg, Spezifikation, Code und Tests synchron zu halten, sobald das Projekt lief. Genau das kann KI gut.
Im Unified Process treiben Use Cases jede Disziplin: Analyse, Design, Implementierung und Test. Der AI Unified Process behält das bei. Ein System-Use-Case ist die Einheit, die der Agent implementiert, gegen die die Tests geschrieben werden und die das Business prüft und abnimmt. Code, der eine Geschäftsregel durchsetzt, trägt eine Markierung UC-XXX BR-YYY, und jeder Test trägt die Id seines Use Cases. So bleibt der Use Case der rote Faden von der Anforderung bis zum laufenden Code.
Im Unified Process steht die Architektur in der Elaboration fest, bevor die Construction Fahrt aufnimmt, und jede Iteration baut darauf auf. Der AI Unified Process macht sie für den Agenten explizit. Das Entitätsmodell, die Stack-Datei docs/architecture/stack.md und die Architecture Decision Records legen Schichten, Technologien und Konventionen fest. Die Layer-Skills bauen jeden Use Case in diesem Rahmen, und eine Abweichung von einem ADR ist eine Frage an einen Menschen, keine Entscheidung, die der Agent allein trifft.
Die meisten Projekte beginnen bei einem System, das bereits läuft und nicht brechen darf. Manche beginnen auf der grünen Wiese. Dieselbe Methodik deckt beides ab.
Beginn beim laufenden System. Der Software Engineer leitet Entitätsmodell, Use-Case-Modell und Spezifikationen aus dem bestehenden Code ab. Software Engineer und Requirements Engineer prüfen diese Artefakte anschließend gemeinsam, und schaffen so die Spezifikationsbasis für alle weiteren Iterationen. /spec-review kann die bereits vorhandenen Befunde als Baseline festhalten, sodass nur neue Probleme den Build scheitern lassen. Eine grosse Codebasis wird nach Modulen aufgeteilt, /stack erkennt die Schichten, die das Projekt bereits hat, und jede spätere Änderung gleicht den bestehenden Code mit einem geänderten Use Case ab, statt ihn neu zu generieren. Pflegen oder modernisieren: die zwei Wege →
Die KI entwirft Use Cases, Geschäftsprozesse und ein Entitätsmodell aus den Anforderungen und fragt zuerst nach, was sie nicht selbst entscheiden kann; was noch niemand beantworten kann, steht in docs/open_questions.md, bis ein Product Owner es tut; der Requirements Engineer überarbeitet und verantwortet sie, und /spec-review prüft die Spezifikationen gegeneinander, bevor Code entsteht. Der KI-Agent generiert anschließend Code und Tests direkt aus diesen Artefakten, im Rahmen von Entscheidungsrechten, die das Team festlegt: was er allein entscheidet, was er zuerst erfragt und was er nie tut. Der Software Engineer prüft das Ergebnis; jedes Artefakt lässt sich auf eine Anforderung zurückführen.
Use Cases beschreiben einzelne Ziele. Der Geschäftsprozess zeigt, wie sie zusammenspielen, und genau das müssen die End-to-End-Tests abdecken.
Der Geschäftsprozess wird in BPMN 2.0 modelliert, erhält eine ID wie BP-001 und wird im Repository neben den übrigen Artefakten abgelegt. /business-process entwirft ihn aus den Anforderungen und dem Use-Case-Diagramm, mit einer Lane pro Akteur; Business Analysts verfeinern ihn in jedem BPMN-Modeler. Jede Aktivität entspricht einem Use Case: Die Use-Case-ID gehört in den Namen der Aktivität, zum Beispiel «UC-009 Book visit»; andernfalls wird die Aktivität über den Namen einem Use Case zugeordnet.
Jeder Pfad vom Start-Ereignis zu einem End-Ereignis wird zu einem End-to-End-Test-Case. Er verkettet die Use Cases seiner Aktivitäten in Prozessreihenfolge, und die Lanes, die der Pfad durchläuft, werden zu den Rollen des Test Case.
Im Coding-Agenten leitet /test-case BP-001 die Test Cases ab. In AI Unified Process Studio bietet der Prozess-Editor denselben Schritt mit einem Generieren-Button an, und das Ergebnis kommt als Pull Request.
Use Cases sind normalerweise disjunkt: Kein Schritt gehört zu zwei Use Cases. Ein Test Case braucht keine Use Cases, die sich überschneiden. Die Use Cases hängen über die Daten zusammen, weil die Nachbedingung eines Use Case die Vorbedingung des nächsten erfüllt. Eine Bestellung, die in einem Use Case erfasst wird, ist die Bestellung, die im nächsten freigegeben wird.
Arbeit kommt selten als brandneuer Use Case herein. Sie kommt als Feature-Wunsch, als Änderung oder als Fehlermeldung, und alle drei sind Änderungen an einem Use Case.
Fügt einen Use Case hinzu oder erweitert bestehende um neue Akteure und neue Abläufe. Die Änderung wirkt sich bis in den Anforderungskatalog aus, und eine wirklich neue Fähigkeit kann auch die Vision verschieben.
Work-Item-Typ: Enhancement.
Verändert einen bereits bestehenden Use Case: eine geänderte Geschäftsregel, ein zusätzliches Feld, ein anderer alternativer Ablauf. Zuerst ändert sich die Spezifikation, alles Nachgelagerte folgt daraus.
Work-Item-Typ: Enhancement.
Spezifikation und Code widersprechen sich. Meistens ist der Code falsch. Manchmal war die Spezifikation falsch oder der Test hat die falsche Erwartung festgehalten; dann gehört die Korrektur in die Spezifikation.
Work-Item-Typ: Bug.
Prinzipien, die den Erfolg in agiler, iterativer Entwicklung sicherstellen.
Use Cases gehören dem Requirements Engineering und werden über die Lebensdauer des Systems gepflegt, keine Prompts, die ein Entwickler schreibt und verwirft.
KI übernimmt repetitive Arbeit; Menschen konzentrieren sich auf Geschäftslogik.
Spezifikationen, Code und Tests entwickeln sich gemeinsam in kurzen Zyklen.
Umfassende Tests gewährleisten konsistentes Verhalten, wann immer KI den Code ändert.
Kontinuierliche Validierung mit Geschäftsbenutzern in jeder Iteration.
Jede Codezeile lässt sich auf eine Geschäftsanforderung zurückführen.
Spec-Driven Development ist nicht eine einzige Sache. Alle verwenden den Begriff, und alle meinen etwas leicht anderes. Die Werkzeuge, die das Etikett tragen, sitzen auf drei sehr unterschiedlichen Ebenen. Der AI Unified Process ist bewusst für die zweite gebaut.
Die Spezifikation wird vor dem Code geschrieben und dem KI-Agenten als Input übergeben. Sobald das Feature ausgeliefert ist, hat sie ihren Zweck erfüllt und wird verworfen. Ein halbes Jahr später weiss niemand mehr, warum der Code so aussieht, wie er aussieht.
Lebensdauer: ein Change Request. Hier sitzen heute die meisten Spec-Driven-Werkzeuge.
Die Spezifikation bleibt im Repository und wird bei jeder Änderung nachgeführt. So entsteht Dokumentation, die tatsächlich stimmt, weil der Agent sie liest, bevor er den Code anfasst. Genau das macht die Arbeit an bestehenden Systemen überhaupt erst möglich.
Lebensdauer: die Lebensdauer des Systems. Hier sitzt der AI Unified Process.
Die Spezifikation ist das Einzige, was ein Mensch bearbeitet, der Code wird jedes Mal daraus generiert. Die experimentellste der drei Ebenen und eine bekannte Idee: Model-Driven Development hat vor zwanzig Jahren genau das versucht.
Lebensdauer: die Spezifikation ist dauerhaft, der Code ist Wegwerfware.
Es geht nicht um perfekte Spezifikationen, es geht um iterative Verbesserung.
Kritiker argumentieren, dass KI-Code-Generierung nur mit erschöpfenden Spezifikationen funktioniert, die deterministische Ausgaben erzwingen. Das setzt voraus, dass wir perfekte Anforderungen im Voraus benötigen.
Realität: Perfekte Spezifikationen sind unmöglich und unnötig. Der wahre Wert kommt von iterativer Verbesserung.
Durch kurze Zyklen werden Spezifikationen klarer, die KI-Generierung verbessert sich und Tests werden stärker. Jede Iteration baut auf der vorherigen auf.
Wichtige Erkenntnis: Tests gewährleisten konsistentes Verhalten unabhängig davon, wie die KI Code generiert. Dies ermöglicht sichere Evolution und Modernisierung.
Ein Agent, der „fertig“ meldet, stellt eine Behauptung auf. Leitplanken verlangen den Beweis dafür, im Build und in der Session. Die AI Unified Process PetClinic zeigt sie an einer echten Anwendung.
Architekturtests machen aus dem Architekturdokument ausführbare Regeln. Traceability-Tests verbinden Anforderungen, Use Cases, Geschäftsregeln, Test Cases und Tests in beide Richtungen: Ein Test, der auf einen umbenannten Ablauf zeigt, schlägt fehl, und ebenso ein Use Case mit Status: Done, dessen alternativer Ablauf nie getestet wurde.
Kernpunkt: Der Build findet Abweichungen, egal wer oder was die Änderung gemacht hat.
Claude Code Hooks halten den Agenten an die Sensoren. Ein Stop-Hook lässt den Turn nicht enden, solange geänderter Code oder geänderte Spezifikationen keinen frischen, grünen Testlauf hinter sich haben. Ein Status-Guard verweigert Done oder Tested für einen Use Case, solange kein Coverage-Audit abgeschlossen ist.
Kernpunkt: Beweis ist ein Testreport oder ein abgeschlossenes Audit, nie eine Konsolenausgabe, die nur sauber aussieht.
Status:-Zeilen, ein Stop-Hook, der grüne Sensoren verlangt, und ein Smoke-Test für die Hooks selbst.
start, direkt nach dem Reverse Engineering, und main, mit allen Use Cases umgesetzt, sodass die ganze Demo ein einziger Diff ist.
Workshops, Beratung und massgeschneiderte Einführungen des AI Unified Process. Vereinbaren Sie einen Termin, um zu besprechen, wie der AI Unified Process zu Ihrem Stack und Team passt.