Spec-driven Development: Wenn Klarheit vor dem Code entsteht

Wenn Code schneller entsteht, muss Klarheit früher entstehen.

Eine unpräzise Anforderung wird durch KI nicht besser. Sie wird nur schneller implementiert. Das Ergebnis sieht früh fertig aus – und kann trotzdem auf einem Missverständnis beruhen.

Spec-driven Development setzt deshalb nicht den Prompt und nicht den erzeugten Code an die Spitze des Prozesses. Führend ist eine Spezifikation, die beschreibt, was die Software leisten soll und wie sich dieses Verhalten prüfen lässt.

Eine gute Spezifikation wird nicht fertig angeliefert

Auftraggeber kennen ihre Abläufe. Sie müssen sie nicht in technischer Form formulieren können. Unsere Aufgabe besteht darin, das vorhandene Wissen gemeinsam so weit zu klären, dass daraus eine verlässliche Umsetzung entstehen kann.

Der Satz „Ein abgeschlossener Beratungsfall wird an die Abrechnung übergeben“ wirft sofort Fragen auf: Was bedeutet abgeschlossen? Welche Daten müssen vorliegen? Wer gibt frei? Was geschieht bei einer wiederholten Übertragung? Wie werden spätere Änderungen behandelt?

Diese Rückfragen sind kein bürokratischer Zusatz. An ihnen entsteht die Software.

Aus einer Aussage wird überprüfbares Verhalten

Eine Spezifikation gewinnt an Wert, wenn sich daraus Tests ableiten lassen. Statt „Fälle werden automatisch übertragen“ beschreibt sie Ausgangslage, Handlung und erwartetes Ergebnis:

• Der Fall ist fachlich abgeschlossen und vollständig.

• Eine berechtigte Person gibt ihn frei.

• Das System übermittelt genau einen Abrechnungsauftrag.

• Es speichert Zeitpunkt, Tarifstand und externe Vorgangsnummer.

• Bei fehlenden Daten wird die Übergabe blockiert.

• Eine Wiederholung erzeugt keine Doppelbuchung.

Damit wird aus einer Absicht ein Verhalten, das Menschen verstehen und Maschinen prüfen können.

Delta Specs halten bestehende Systeme beweglich

Gewachsene Unternehmenssoftware lässt sich nicht vor jeder Änderung vollständig neu beschreiben. Das wäre weder sinnvoll noch wirtschaftlich.

Eine Delta Specification erfasst nur die Differenz: Was gilt heute? Was soll sich ändern? Was bleibt ausdrücklich unverändert? Welche Tests und Datenmigrationen sind betroffen?

Für KI ist dieser begrenzte Kontext besonders wertvoll. Sie arbeitet an einem klaren Ausschnitt, statt das gesamte System neu zu interpretieren. Nach der Umsetzung fließt die bestätigte Änderung in die gültige Gesamtspezifikation zurück.

Contracts schützen die Übergänge

Viele teure Fehler entstehen zwischen Systemen. Frontend und Backend erwarten unterschiedliche Felder. Eine Schnittstelle ändert einen Statuscode. Ein Drittsystem interpretiert denselben Wert anders.

Contracts beschreiben solche Vereinbarungen verbindlich. Contract Tests prüfen, ob beide Seiten sie weiterhin einhalten. Die interne Umsetzung darf sich verändern, solange die zugesagte Verbindung stabil bleibt.

Gerade in Headless-Systemen mit Drupal, Frontend, GraphQL und Drittdiensten schafft das Freiheit: Komponenten können getrennt weiterentwickelt werden, ohne stillschweigend ihre Nachbarn zu beschädigen.

Quality Gates setzen sinnvolle Grenzen

Eine Spezifikation macht KI-Entwicklung nicht autonom. Zwischen den Schritten liegen Prüfungen: Akzeptanztests, Sicherheitsanalysen, Contract Tests, Barrierefreiheitsprüfungen oder menschliche Freigaben.

Die Tiefe richtet sich nach dem Risiko. Eine kleine, reversible Oberflächenänderung braucht weniger Kontrolle als eine Funktion, die Zahlungen auslöst oder personenbezogene Daten verändert.

So entsteht kein neuer Dokumentationsapparat. Es entsteht eine Verbindung zwischen Geschäftsentscheidung, Code und Nachweis.

Mehr als ein Pflichtenheft

Ein klassisches Pflichtenheft beschreibt einen vereinbarten Stand. Eine lebende Spezifikation begleitet die Entwicklung. Sie ist mit Tickets, Tests, Schnittstellen und Änderungen verbunden und bleibt nach dem Release nutzbar.

Modelle und Werkzeuge können wechseln. Die fachliche Logik bleibt verständlich.

Wie E-Fork damit arbeitet

Wir verbinden Fachmodell, Spezifikation, Umsetzung und Qualitätsnachweis. KI hilft beim Erkennen offener Fragen, beim Ableiten von Tests, bei abgegrenzten Implementierungen und bei der Aktualisierung der Dokumentation.

Welche Geschäftsregel richtig ist und welches Risiko ein Unternehmen akzeptiert, entscheidet sie nicht.

Sie möchten KI-gestützte Entwicklung besser steuerbar machen?

Wir prüfen, wo wenige Akzeptanzkriterien genügen, wo Delta Specs helfen und welche Schnittstellen einen Contract benötigen. Die Methode passt sich dem System an – nicht umgekehrt.

• Was ist Spec-driven Development?

  Spec-driven Development ist ein Entwicklungsansatz, bei dem eine strukturierte und fortlaufend gepflegte Spezifikation die Umsetzung steuert. Aus ihr werden Aufgaben, Akzeptanztests, Schnittstellenverträge und Qualitätsprüfungen abgeleitet. So bleiben fachliche Absicht und technischer Nachweis miteinander verbunden.

• Was ist der Unterschied zu einem Lasten- oder Pflichtenheft?

  Ein Lastenheft beschreibt aus Sicht des Auftraggebers, was ein System leisten soll. Das Pflichtenheft erläutert aus Sicht des Auftragnehmers, wie diese Anforderungen umgesetzt werden sollen. Spec-driven Development ersetzt diese Dokumente nicht grundsätzlich, sondern führt ihre Inhalte näher an die laufende Entwicklung heran. Anforderungen werden dabei fortlaufend präzisiert, mit Tickets, Entscheidungen, Code und Tests verknüpft und bei Änderungen gemeinsam aktualisiert. Soweit sinnvoll, werden Akzeptanzkriterien automatisiert geprüft. Die Spezifikation wird damit nicht nur zur Planungsgrundlage, sondern zu einem aktiven und überprüfbaren Bestandteil der Entwicklung.

• Muss eine Spezifikation vollständig sein, bevor die Entwicklung beginnt?

  Nein. Sie muss für den jeweils bearbeiteten Bereich eindeutig genug sein. Offene Punkte bleiben als Entscheidungen sichtbar und werden in geplanten Klärungs- und Review-Schleifen bearbeitet. Bei bestehenden Systemen beschreiben Delta Specs gezielt nur die jeweilige Änderung.

• Was geschieht, wenn Anforderungen noch nicht präzise formuliert werden können?

  Das ist in komplexen Projekten normal. E-Fork strukturiert das vorhandene Fachwissen, stellt gezielte Rückfragen und arbeitet mit Szenarien, Gegenbeispielen und Prototypen. Diese Anforderungselizitation führt schrittweise zu einem gemeinsam bestätigten und prüfbaren Verständnis.

• Verursachen Rückfragen und Iterationen nicht zusätzlichen Aufwand?

  Kurzfristig benötigen fachliche Klärung und Abstimmung zusätzliche Zeit. Dieser Aufwand wird bewusst eingeplant, weil Änderungen an Anforderungen deutlich günstiger sind als Umbauten an bereits integrierter Software. Zugleich werden spätere Freigaben und Erweiterungen verlässlicher.

• Was bedeutet Traceability konkret?

  Traceability bedeutet Rückverfolgbarkeit. Eine Geschäftsregel wird mit ihrer Umsetzung, den zugehörigen Tests und späteren Änderungen verbunden. Dadurch bleibt nachvollziehbar, warum eine Funktion existiert und welche Folgen eine Anpassung haben kann.

• Was ist ein Quality Gate?

  Ein Quality Gate ist ein verbindlicher Prüfpunkt vor dem nächsten Entwicklungs- oder Veröffentlichungsschritt. Das kann ein erfolgreicher Testlauf, eine Sicherheitsprüfung, ein Contract Test oder eine menschliche Freigabe sein.

Sie haben Fragen zu diesem Thema? Hinterlassen Sie uns einfach eine Nachricht über das Kontaktformular.