Im AI Unified Process (AIUP) steht die Spezifikation im Zentrum. Der Use Case ist die Arbeitseinheit. Du schreibst einen System-Use-Case, die KI generiert den Code, und Tests bestätigen das Verhalten. Der Use Case ist die Quelle der Wahrheit. Der Code ist ein abgeleitetes Artefakt.

Das legt sehr viel Gewicht auf eine Sache: die Qualität des Use Case selbst.

Die KI verbessert keinen schlechten Use Case. Sie baut nur schneller das Falsche. Wenn also die Spezifikation im Zentrum steht, dann ist das Schreiben einer guten Spezifikation die wichtigste Fähigkeit. Und das beste Buch, das ich zu dieser Fähigkeit kenne, ist über 20 Jahre alt: Writing Effective Use Cases von Alistair Cockburn (Addison-Wesley, 2001).

Hier erkläre ich, warum ich es immer wieder empfehle und wie es mit AIUP und mit den anderen Use-Case-Beiträgen in diesem Blog zusammenhängt.

Das Buch handelt von einer schwierigen Frage

Cockburn ist schon auf der ersten Seite ehrlich. Einen Use Case zu schreiben bedeutet eigentlich, klaren Fliesstext zu schreiben. Das Schwierige ist nicht die Frage „Wie sieht ein guter Use Case aus?“. Es ist die Frage „Wie schreibe ich einen, damit er gut wird?“.

Er sagt auch etwas, das den Druck herausnimmt. Du brauchst keinen perfekten Use Case, um Wert zu schaffen. Selbst ein mittelmässiger Use Case ist oft nützlicher als das typische Anforderungsdokument. Also entspann dich, schreib etwas Lesbares, und du hilfst deinem Team bereits.

Diese Botschaft passt zur Idee „Keep IT simple“, und sie passt zu AIUP. Wir wollen keine vergoldeten Specs. Wir wollen klare Specs, denen ein Mensch und eine KI beide folgen können.

Vier Ideen aus dem Buch, auf denen AIUP läuft

1. Goal Levels: auf der richtigen Höhe schreiben

Cockburns nützlichste Idee sind die Goal Levels. Ein Ziel kann auf der Summary-Ebene liegen (zu hoch), auf der User-Goal-Ebene (Sea Level, der ideale Punkt) oder auf der Subfunction-Ebene (zu tief). Um hochzugehen, frag „warum?“. Um runterzugehen, frag „wie?“.

Genau diese Linie ziehe ich in What, Harness, How: The Three Layers of AIUP. Ein zu hoch geschriebener Use Case ist vage, und die KI rät. Ein zu tief geschriebener Use Case lässt Implementierung in die Spezifikation einfliessen, und dann vermischen sich das „What“ und das „How“. Cockburn gibt dir einen einfachen Test, um auf der richtigen Ebene zu bleiben.

2. Main Success Scenario plus Extensions

Ein Use Case nach Cockburn hat ein Main Success Scenario, geschrieben als einfache nummerierte Schritte im Aktiv, und eine Liste von Extensions für alles, was anders laufen kann. In den Extensions passiert das eigentliche Denken.

Wenn du Use-Case 2.0: The Forgotten Practice That Solves What User Stories Can’t gelesen hast, kommt dir das bekannt vor. Das Main Success Scenario ist der Basic Flow. Die Extensions sind die Alternative Flows. AIUP gibt der KI genau diese Struktur: ein klares Ziel, einen Schritt-für-Schritt-Ablauf, die Varianten und die Testfälle. Cockburns Extensions sind der Teil, den die meisten überspringen, und es ist auch der Teil, den die KI nicht für dich erfinden kann.

3. Stakeholder, Interessen und Garantien

Cockburn betrachtet nicht nur den Akteur vor dem System. Er betrachtet die Stakeholder im Hintergrund, deren Interessen das System schützen muss, und die Garantien, die das System auch bei einem Fehler gibt.

Das ist der Kern von Why in Spec-Driven Development the Spec Must Be Readable for All Stakeholders. Eine Spezifikation ist die gemeinsame Grundlage für alle, nicht nur für Entwickler. Cockburns Stakeholder-Denken zwingt dich zu fragen, wer sonst noch an diesem Ziel interessiert ist, und seine Garantien liefern dir die Akzeptanzkriterien, die später zu Tests werden.

4. Klare Schritte im Aktiv

Cockburn will, dass jeder Schritt ein kurzer Satz ist, im Aktiv, aus einer klaren Perspektive. Diesen Rat schrieb er 2001 für menschliche Leser. Es zeigt sich, dass es auch für KI-Leser ein perfekter Rat ist.

Ein klarer Schritt ist für einen Menschen leicht zu prüfen und für einen Agenten leicht umzusetzen. Aus demselben Grund funktioniert die Rückverfolgbarkeit von Use Cases zu Tests so gut: Wenn die Schritte sauber sind, bleibt die Verbindung von Intention zu Code zu Test ehrlich.

Altes Buch, neuer Kontext

Cockburn schrieb für eine Welt, in der Menschen den Use Case lasen und dann den Code von Hand schrieben. In AIUP wird der Use Case auch von einer KI gelesen, die den Code für uns schreibt. Das ändert eine Sache in der Praxis: Wir zerlegen einen Use Case nicht mehr in winzige Aufgaben, nur damit er in einen Sprint passt. Der ganze Use Case wird zur Arbeitseinheit, wie ich es im Use-Case-2.0-Beitrag beschreibe.

Aber die Eigenschaften, die einen Use Case gut machen, haben sich nicht geändert. Ein klares Ziel, die richtige Ebene, explizite Extensions, benannte Stakeholder und lesbare Schritte waren 2001 gut, und sie sind es heute. Wenn überhaupt, zählen sie heute mehr, denn die KI baut treu, was du geschrieben hast, inklusive der Fehler.

Hier gibt es eine schöne Linie der Herkunft. Ivar Jacobson erfand die Use Cases. Use-Case 2.0 (Jacobson, Spence, Bittner) modernisierte sie, und es ist eine der Grundlagen von AIUP. Cockburns Buch steht direkt daneben als der praktische Schreibratgeber. Zusammen decken sie das grosse Bild und das Detail ab.

Solltest du es lesen?

Ja, wenn du in der einen Fähigkeit besser werden willst, von der AIUP abhängt. Lies zuerst Teil 1, die Use Case Body Parts. Dort leben die Goal Levels, Szenarien, Extensions und Stakeholder. Teil 3 ist eine Sammlung kurzer Reminder, die du neben der Tastatur liegen lassen kannst.

Du musst nicht alles übernehmen. Nimm den Goal-Level-Test, schreib ein sauberes Main Success Scenario und steck deine echte Mühe in die Extensions. Dann gib diesen Use Case an Claude Code und schau, wie viel besser das Ergebnis wird, wenn die Spezifikation gut ist.

Die KI schreibt jetzt den Code. Dieses Buch lehrt noch immer die Use Cases. Das ist ein ziemlich guter Deal für ein 20 Jahre altes Buch.