Bei Spec-Driven Development (SDD) steht die Spezifikation im Zentrum. Sie ist nicht nur ein Dokument für Entwickler oder Architekten. Sie ist die gemeinsame Grundlage für alle, die am Produkt arbeiten. Genau hier liegt der Knackpunkt: Wenn die Spec nur für Techniker verständlich ist, verfehlt SDD seinen Zweck.

Die Spec ist mehr als ein technisches Dokument

In klassischen Projekten gibt es oft eine Trennung. Das Business schreibt User Stories oder Anforderungen. Die Entwickler übersetzen das in technische Designs. Irgendwo dazwischen geht Wissen verloren. Missverständnisse entstehen. Am Ende baut das Team etwas, das nicht ganz passt.

SDD will diese Lücke schliessen. Die Spec wird zum Single Source of Truth. Aus ihr entsteht der Code, oft mit Unterstützung von KI. Wenn aber nur Entwickler die Spec lesen können, hat das Business keine Chance, Fehler früh zu erkennen. Und Fehler in der Spec werden direkt in den Code übernommen.

Business Stakeholder müssen die Spec verstehen

Stell dir vor, ein Product Owner liest die Spec und sagt: „Moment, das ist nicht, was wir wollten.“ Genau das ist der Moment, in dem SDD seinen Wert zeigt. Aber dieser Moment kann nur passieren, wenn der Product Owner die Spec auch wirklich versteht.

Lesbar heisst dabei nicht, dass jedes Detail vereinfacht sein muss. Es heisst, dass die Spec in einer Sprache geschrieben ist, die Fachexperten kennen. Begriffe aus der Domäne, klare Sätze, wenig Fachjargon aus der IT. Use Cases und Beispiele helfen mehr als UML-Diagramme.

Wenn ein Bankfachmann die Spec für ein neues Kreditmodul liest, soll er die Geschäftsregeln erkennen. Er muss nicht wissen, welche Klassen oder Datenbanktabellen entstehen. Er muss aber sicher sein, dass die Regel „Kredite über 100’000 brauchen eine zweite Prüfung“ korrekt erfasst ist.

Die Vorteile einer lesbaren Spec

Wenn alle Stakeholder die Spec verstehen, ändert sich die Zusammenarbeit grundlegend.

Erstens werden Fehler früher gefunden. Ein Fachexperte erkennt eine falsche Geschäftsregel sofort. Im Code wäre sie für ihn unsichtbar.

Zweitens entstehen weniger Annahmen. Entwickler müssen nicht mehr raten, was gemeint ist. Sie können direkt nachfragen, weil die Spec eine gemeinsame Sprache schafft.

Drittens wird die KI-gestützte Entwicklung sicherer. Wenn eine KI aus der Spec Code generiert, ist die Qualität des Codes nur so gut wie die Qualität der Spec. Eine unklare Spec führt zu unklarem Code. Eine lesbare und präzise Spec führt zu präzisem Code.

Viertens steigt das Vertrauen. Stakeholder, die das Dokument lesen können, fühlen sich einbezogen. Sie sehen, was gebaut wird. Sie können Feedback geben. Das Projekt wird zu einem gemeinsamen Vorhaben, nicht zu einer Black Box.

Was das in der Praxis bedeutet

Eine gute Spec im Sinn von SDD hat ein paar einfache Eigenschaften.

Sie nutzt die Sprache der Domäne. Wenn das Business von „Police“ spricht, steht in der Spec „Police“, nicht „InsuranceContract“. Domain-Driven Design hilft hier sehr.

Sie zeigt Beispiele. Konkrete Szenarien sind oft klarer als abstrakte Beschreibungen. Ein Use Case mit echten Daten sagt mehr als ein generischer Ablauf.

Sie trennt das Was vom Wie. Was soll passieren? Welche Regeln gelten? Wie das technisch umgesetzt wird, gehört nicht in die fachliche Spec. Solche Details kommen später dazu, in einem eigenen Abschnitt oder einem separaten Dokument.

Sie ist versioniert und lebt mit dem Produkt. Eine Spec ist kein Wasserfall-Dokument, das einmal geschrieben und dann vergessen wird. Sie wird gepflegt, geprüft und angepasst.

Im AI Unified Process sind dafür zwei Artefakte zentral: System Use Cases und das Entity Model. Beide sind genau so geschrieben, dass Business und Technik sie gemeinsam lesen können.

Ein System Use Case beschreibt einen konkreten Ablauf zwischen Akteur und System. Vorbedingung, Hauptablauf, Alternativabläufe, Nachbedingung. Keine Klassen, keine API-Definitionen, keine Datenbankdetails. Ein Fachexperte kann den Ablauf Schritt für Schritt prüfen und sagen, ob er der Realität entspricht.

Das Entity Model zeigt die zentralen Begriffe der Domäne und ihre Beziehungen. „Eine Police hat einen Versicherungsnehmer. Eine Police kann mehrere Deckungen haben.“ Solche Sätze sind für Fachexperten verständlich. Gleichzeitig liefern sie der KI und den Entwicklern eine klare Grundlage für das Datenmodell.

Beide Artefakte sind keine technischen Diagramme im klassischen Sinn. Sie sind fachliche Beschreibungen mit so viel Struktur, dass daraus Code entstehen kann.

Wie der AI Unified Process das umsetzt

Der AI Unified Process (AIUP) macht diese Idee konkret. Er definiert eine Reihe von Spec-Artefakten, die bewusst für alle Stakeholder geschrieben sind.

Die System Use Cases bauen auf Use-Case 2.0 auf. Sie beschreiben das Verhalten des Systems aus Sicht des Anwenders. Das Format ist schlank und in natürlicher Sprache. Ein Product Owner kann es lesen, ein Entwickler kann daraus Tests und Code ableiten, eine KI kann daraus erste Implementierungen generieren.

Das Entity Model nutzt die Sprache der Domäne und folgt den Prinzipien von Domain-Driven Design. Es zeigt Aggregate, Entities und ihre Beziehungen. Aber eben nicht als technisches UML-Diagramm, sondern als fachliches Modell mit klaren Begriffen.

Damit wird die Spec im AIUP zu dem, was sie sein soll: eine gemeinsame Grundlage. Nicht ein Dokument für Entwickler, das man dem Business „auch mal zeigt“. Sondern ein lebendiges Artefakt, an dem Business und Technik gemeinsam arbeiten.

Fazit

SDD funktioniert nur, wenn die Spec für alle lesbar ist. Sie ist die Brücke zwischen Business und Technik. Sie ist die Quelle, aus der Code entsteht. Und sie ist der Ort, an dem Missverständnisse aufgedeckt werden, bevor sie teuer werden.

Wer SDD ernst nimmt, schreibt Specs nicht für Entwickler. Er schreibt sie für alle, die zum Erfolg des Produkts beitragen. Genau das macht den Unterschied zwischen einem Dokument, das in einer Schublade liegt, und einer Spec, die das Projekt wirklich trägt.