Der dauerhafte Vertrag über erwartetes Verhalten
Eine Funktionsspezifikation hält fest, was das Produkt tun soll, warum dieses Verhalten existiert, wer betroffen ist und wie die Korrektheit beurteilt werden kann. Sie gibt Product Engineer, Coding-Agent, Prüfern und Verifikationsagenten eine gemeinsame Referenz über ein Gespräch hinaus.
Eine Spezifikation ist nicht einfach ein langer Prompt. Sie ist ein gepflegtes Produktartefakt. Eine Änderung des vereinbarten Verhaltens sollte zu einer sichtbaren Änderung der relevanten Spezifikation mit nachvollziehbarer Historie darüber führen, was sich geändert hat und warum.
Spezifikationen nach zusammenhängenden Funktionen ordnen
Das Framework empfiehlt ein Verzeichnis specs/ mit funktionsorientierten Markdown-Dateien mit stabilen Kennungen. Eine Funktion könnte „Kunden suchen“, „Bestellanfrage genehmigen“ oder „Anwendungsrollen verwalten“ heißen. Stabile Identität ist wichtiger als ein bestimmtes Nummerierungsformat. Vermeiden Sie für jede Überarbeitung eine völlig neue versionierte Datei, wenn gewöhnliche Versionskontrolle die Historie derselben Funktion erhalten kann.
Eine zusammenhängende Spezifikation sollte überschaubar genug zum Verstehen und Verifizieren sein, jedoch nicht in Dutzende Dateien für triviale Einzelelemente zerfallen. Eine Funktion kann von einer anderen Spezifikation abhängen; verweisen Sie ausdrücklich darauf, statt Regeln widersprüchlich zu duplizieren.
Was eine Funktionsspezifikation erfassen sollte
Erfassen Sie als sinnvolles Minimum Zweck und Umfang der Funktion, Akteure oder Berechtigungen, auslösende Aktionen, erwartetes Verhalten, Geschäftsregeln, relevantes Fehler- oder Ausnahmeverhalten, Abhängigkeiten oder Beschränkungen sowie Akzeptanzbedingungen. Sind Daten beteiligt, beschreiben Sie sichtbare oder veränderte Informationen sowie wichtige Validierungs- oder Zugriffserwartungen.
Formulieren Sie konkret. „Das System sollte intuitiv sein“ lässt sich schwer verifizieren. „Ein Prüfer kann eine Anfrage nur mit Begründung ablehnen; der Antragsteller sieht anschließend die erfasste Begründung“ beschreibt beobachtbares Verhalten.
Unklarheiten klären, bevor Regeln erfunden werden
Ein Coding-Agent kann eine Lücke mit einer plausiblen Annahme füllen, die fachlich nicht freigegeben wurde. Der Product Engineer sollte folgenreiche Unklarheiten mit Stakeholdern klären und die Spezifikation aktualisieren. Unkritische Details können durch Iteration an funktionierender Software ermittelt werden; akzeptierte Verhaltensentscheidungen müssen dennoch in den dauerhaften Bestand eingehen.
Spezifikationen entwickeln sich mit dem Produkt
Frühe Spezifikationen können sich auf die zunächst vereinbarten Abläufe konzentrieren. Stakeholder-Feedback, UAT-Befunde, Wartungsänderungen und neue Funktionen können sie verändern. Entscheidend ist, dass der Bestand das aktuell beabsichtigte Verhalten darstellt. Eine Spezifikation, die das Produkt vom Vorjahr beschreibt, während sich die Implementierung geändert hat, ist keine verlässliche Referenz mehr.
Spezifikationen unterstützen unabhängige Verifikation
Ein gesonderter Verifikationsagent leitet Prüfungen aus dem eingecheckten Bestand ab, führt die Implementierung nach Möglichkeit aus und berichtet Ergebnisse bezogen auf Anforderungen. Akzeptanzkriterien verbessern diesen Prozess, bedeuten jedoch nicht, dass jede Anforderung vollständig automatisiert bewertet werden kann. Menschliche Bewertung und fachliche Nachweise bleiben wichtig.
Empfohlener Aufbau einer Spezifikation
Die Beispielvorlage des Frameworks umfasst stabile Kennung, Zusammenfassung, Zweck, Akteure, Voraussetzungen, Hauptverhalten, Geschäftsregeln, Ausnahmen, Akzeptanzkriterien, Abhängigkeiten und offene Entscheidungen. Projekte können diesen Aufbau anpassen, solange Spezifikationen verständlich, wartbar und testbar bleiben.