Die Softwareentwicklungswelt spricht derzeit von KI-unterstütztem Coding. Tools wie Claude Code, Windsurf und JetBrains Junie versprechen, unsere Produktivität zu steigern. Aber die meisten Ansätze konzentrieren sich darauf, Code schneller zu erzeugen – sie bleiben code-zentriert.

Was, wenn wir einen anderen Ansatz wählen? Was, wenn wir Anforderungen zur einzigen Quelle der Wahrheit machen und die KI den Rest erledigen lassen?

Nach jahrelanger Erfahrung in der Entwicklung von Geschäftsanwendungen begann ich, eine Methodik zu entwickeln, die Ideen des Rational Unified Process (RUP) mit modernen KI-Tools kombiniert. Die Ergebnisse sind bemerkenswert: bessere geschäftliche Ausrichtung, wartbarer Code und vollständige Rückverfolgbarkeit von den Geschäftsanforderungen bis zur Umsetzung.

Das Problem des Code-zentrierten Entwicklungsansatzes

Traditionelle Entwicklung folgt diesem Muster:

  1. Anforderungsdokumente schreiben
  2. Anwendung codieren
  3. Tests hinzufügen (eventuell)
  4. Dokumentation aktualisieren (selten)

Das Problem? Der Code wird zur Quelle der Wahrheit. Anforderungsdokumente veralten. Wenn Bugs auftreten oder Funktionen geändert werden müssen, durchsuchen wir den Code, um zu verstehen, was das System tun sollte. Es wird noch schlimmer, wenn wir die Anwendung einige Jahre später modernisieren müssen.

KI-Coding-Tools verschärfen dies, indem sie Code schneller generieren. Wir beschleunigen die gleichen Wartungsprobleme, die wir schon immer hatten.

Anforderungen als einzige Quelle der Wahrheit

Mein Ansatz dreht das um. Anforderungen bleiben im Mittelpunkt, alles andere wird davon abgeleitet:

Der komplette Workflow

  1. Katalog der Geschäftsanforderungen (manuell, gemeinsam mit den Business-Stakeholdern)
  2. Geschäfts-Use-Case-Diagramme (von KI generiert, dann mit Stakeholdern überprüft)
  3. Entity-Modelle (aus dem Anforderungskatalog abgeleitet, von Business überprüft)
  4. System-Use-Case-Diagramme (von KI generiert, vom Entwickler und/oder Business überarbeitet)
  5. System-Use-Case-Spezifikationen (von KI generiert, detailliertes Markdown, vom Entwickler und/oder Business überarbeitet)
  6. Anwendungscode (von KI generiert, vom Entwickler überprüft)

Der Schlüssel: Jeder Schritt wird vom Business-Team überprüft und angepasst. Sie validieren nicht nur die Geschäftsartefakte, sondern auch die Entity-Modelle und System-Use-Cases. So werden Fehler im Domain-Modeling erkannt, bevor sie zu teuren Code-Problemen werden.

Alles ist Code, alles wird versioniert

Alle Spezifikationen werden in Markdown geschrieben und zusammen mit dem Anwendungscode in Git gespeichert. Use-Case-Diagramme werden als PlantUML-Quellcode generiert. Das bietet uns:

  • Visuelle Diffs: Zeigt genau, was sich in den Diagrammen geändert hat
  • Vollständige Audit-Trails: Verfolgt jede Änderung von Anforderungen bis zum Code
  • Versionierung: Spezifikationen parallel zum Code versionieren
  • Kollaboratives Bearbeiten: Stakeholder können gezielte Änderungen anfordern

KI als Konsistenzmotor

Wenn sich Anforderungen ändern, aktualisieren KI-Tools wie Claude Code automatisch alle nachgelagerten Artefakte:

  • Betroffene Use-Case-Diagramme neu generieren
  • Entity-Modelle aktualisieren
  • System-Spezifikationen anpassen
  • Neuen Anwendungscode generieren
  • Rückverfolgbarkeitslinks pflegen

Keine manuelle Synchronisation. Keine veraltete Dokumentation. Kein Rätselraten, was das System tun sollte.

Die Struktur: Unabhängige Epics

Geschäftsanwendungen sind komplex, müssen aber nicht kompliziert sein. Ich organisiere alles in unabhängige Epics:

  • Event Management: UC-EVENT-001, UC-EVENT-002, etc.
  • User Management: UC-USER-001, UC-USER-002, etc.
  • Organization Management: UC-ORG-001, UC-ORG-002, etc.

Keine Abhängigkeiten zwischen Epics. Jedes Epic ist ein abgegrenzter Kontext, der unabhängig entwickelt, getestet und deployed werden kann. Das vereinfacht sowohl den KI-Generierungsprozess als auch die Systemarchitektur insgesamt.

Ein echtes Beispiel: System-Use-Case-Spezifikation

So sieht ein System-Use-Case in der Praxis aus:

# Use Case: Events erstellen

**Use Case ID:** UC-EVENT-001  
**Primärer Akteur:** Manager  
**Ziel:** Managern ermöglichen, neue Events für ihre Organisation zu erstellen

## Hauptszenario
1. Manager navigiert zum Abschnitt "Events"
2. Manager klickt auf "Neues Event erstellen"
3. System zeigt das Event-Erstellungsformular an
...

## Geschäftsregeln
### BR-EVENT-001: Validierung des Event-Datums
- Enddatum muss gleich oder nach dem Startdatum liegen
- Events dürfen nicht mit Startdaten in der Vergangenheit erstellt werden

## Technische Hinweise
### Validierungsregeln
- Titel: Pflichtfeld, 3–200 Zeichen
- Startdatum: Pflichtfeld, muss in der Zukunft liegen
- Enddatum: Pflichtfeld, muss >= Startdatum sein

Dieses Detailniveau liefert KI-Tools alles, was sie benötigen, um korrekte und vollständige Implementierungen zu erzeugen. Business-Stakeholder verstehen den Hauptfluss, während Entwickler präzise technische Anforderungen erhalten.

Die Ergebnisse

Dieser Ansatz hat meine Art, Geschäftsanwendungen zu entwickeln, revolutioniert:

Bessere geschäftliche Ausrichtung: Stakeholder prüfen jedes Artefakt und stellen sicher, dass das System ihren tatsächlichen Bedürfnissen entspricht.

Wartbarer Code: Wenn sich Anforderungen ändern, wird alles konsistent aktualisiert. Kein Auseinanderlaufen von Dokumentation und Implementierung.

Schnellere Entwicklung: KI übernimmt die mühsame Arbeit, Diagramme, Spezifikationen und Code zu erzeugen. Stakeholder konzentrieren sich auf die Anforderungen und die Überprüfung der Spezifikation. Entwickler fokussieren sich auf Geschäftslogik und Architektur.

Vollständige Rückverfolgbarkeit: Von einer Geschäftsanforderung bis zu einer Codezeile bleibt jede Verbindung erhalten und sichtbar.

Qualitätssicherung: Generierter Code enthält umfassende Tests basierend auf den Use-Case-Spezifikationen.

Warum das für Geschäftsanwendungen funktioniert

Geschäftsanwendungen haben vorhersehbare technische Muster, aber mehr oder weniger komplexe Domain-Logik. Frameworks wie Vaadin, Spring Boot und jOOQ bieten stabile Grundlagen (siehe den Simon Martinelli Stack). Die eigentliche Komplexität liegt darin, die Geschäftsdomäne korrekt zu verstehen und zu modellieren.

Diese Methodik nutzt beide Stärken:

  • Menschliche Expertise übernimmt die Komplexität der Geschäftsdomäne
  • KI übernimmt die konsistente technische Umsetzung

Erste Schritte

Wenn Sie diesen Ansatz ausprobieren möchten:

  1. Mit Anforderungen beginnen: Nicht sofort mit dem Code starten. Zeit investieren, um die Geschäftsbedürfnisse zu verstehen und zu dokumentieren.
  2. Alles zu Code machen: Spezifikationen in Markdown, Diagramme mit PlantUML. Alles in Git versionieren.
  3. Mit dem Business überprüfen: Stakeholder validieren nicht nur Geschäftsartefakte, sondern auch Entity-Modelle und System-Use-Cases.
  4. KI als Konsistenzmotor nutzen: Tools wie Claude Code übernehmen Generierung und Updates.
  5. Epics unabhängig halten: Vermeiden von Abhängigkeiten zwischen Epics, um sowohl Entwicklung als auch KI-Generierung zu vereinfachen.

Die Zukunft der Geschäftsanwendungsentwicklung

Wir stehen an einem Wendepunkt. KI kann hochwertigen Code generieren, aber nur, wenn wir hochwertige Spezifikationen liefern. Organisationen, die in bessere Anforderungsprozesse investieren, werden schneller bessere Software entwickeln.

Es geht nicht darum, Entwickler durch KI zu ersetzen. Es geht darum, KI zu nutzen, um mühsame, fehleranfällige Arbeiten zu eliminieren, damit wir uns auf das Wesentliche konzentrieren können: Geschäftsbedürfnisse verstehen und Systeme entwerfen, die diese gut erfüllen.

Der Code ist der einfache Teil. Den Anforderungen gerecht zu werden, ist der eigentliche Wert. Mehr lesen: https://aiup.dev