Akzeptanzkriterien schreiben, die ein KI-Agent prüfen kann
Akzeptanzkriterien (AC, acceptance criteria) sind die Bedingungen, die wahr sein müssen, bevor eine Änderung als erledigt gilt. Given/When/Then ist die Schrittform in Gherkin, der Sprache, die Cucumber für verhaltensgetriebene Entwicklung (BDD, behaviour-driven development) verwendet: Given ein Ausgangszustand, When eine Aktion geschieht, Then folgt ein beobachtbares Ergebnis. Ein Produktanforderungsdokument (PRD, product requirements document) ist der Prosatext, der Problem und beabsichtigtes Produkt benennt. Spezifikationsgetriebene Entwicklung (SDD, spec-driven development) behandelt eine strukturierte Spezifikation, nicht nur diese Prosa, als die Quelle, gegen die die Implementierung geprüft wird. EARS (Easy Approach to Requirements Syntax) ist eine Art, einen Anforderungssatz so zu begrenzen, dass seine Klauseln in fester Reihenfolge stehen. Kontinuierliche Integration (CI, continuous integration) ist eine automatische Prüfung bei jeder vorgeschlagenen Änderung; diese Website beschreibt die beiden SpecScore-Prüfungen auf der Validatoren-Seite. Diese Seite zeigt, wie man prüfbare Akzeptanzkriterien schreibt, die ein Agent der künstlichen Intelligenz (KI) verifizieren kann, mit Beispielen, und was die Kommandozeile (CLI, command-line interface) von SpecScore tatsächlich prüft.
Aktualisiert am 3. November 2026.
Was Akzeptanzkriterien sind
Ein Akzeptanzkriterium beantwortet „Was muss wahr sein?“. Es benennt eine Bedingung, die ein Reviewer, ein Test oder ein Agent annehmen oder ablehnen kann. Es benennt nicht die aufzurufende Funktion und nicht die zu ändernde Datei. Diese Entscheidungen gehören zur Implementierung.
Eine Anforderung ist die Regel. In der Anforderungsspezifikation von SpecScore ist eine Anforderung eine Überschrift #### REQ: in einem Feature: eine Pflicht, mit eigener Kennung. Ein Akzeptanzkriterium bündelt verwandte Anforderungen zu einer Bedingung. Ein Szenario ist ein konkreter Fall, der zeigt, dass die Bedingung gilt. Die Spezifikation der Akzeptanzkriterien sagt es so: Kriterien beantworten „Was muss wahr sein?“, Szenarien beantworten „Wie beweisen wir es?“.
Ein PRD kann dieselbe Absicht in Absätzen enthalten. Absätze helfen einem Menschen. Ein Agent muss trotzdem raten, welcher Satz der Bestehens-Test ist. Das Kriterium als eigenen Satz zu schreiben nimmt dieses Raten weg.
Was Akzeptanzkriterien prüfbar macht
Ein KI-Coding-Agent kann einem Kriterium nur folgen, wenn jemand später auf einen Beleg zeigen und bestanden oder nicht bestanden sagen kann. Fünf Gewohnheiten machen das möglich. Keine davon ist eine Satzschablone. Es sind Prüfungen für jede Schablone, auch für Given/When/Then und eine Checkliste.
Beobachtbar
Das Ergebnis ist etwas, das eine außenstehende Person sehen kann: eine Meldung auf der Seite, ein Datensatz, der gespeichert wurde oder nicht, eine Weiterleitung, ein abgelehntes Formular. „Das System versteht die Kundin“ ist nicht beobachtbar. „Die Seite zeigt Enter a valid email address neben dem E-Mail-Feld“ ist es.
Konkret
Nenne die handelnde Person, die Eingabe und das Ergebnis. „Schlechte Eingaben werden behandelt“ sagt nicht, welche Eingabe und welche Behandlung. „Die Kundin sendet die E-Mail not-an-email“ schon. Konkret heißt nicht, jeden Produktionswert einzufügen. Es heißt, dass eine lesende Person ein Testbeispiel erfinden und wissen kann, was geschehen soll.
Ein Verhalten
Ein Kriterium, ein Verhalten. „Nutzer können sich anmelden, ein Passwort zurücksetzen und eine Sperrmeldung sehen“ sind drei Kriterien in einem Satz. Ein Agent, der das erste umsetzt und das dritte auslässt, kann den Satz trotzdem als erledigt ausgeben. Trenne sie.
Bestanden oder nicht
Ein prüfbares Akzeptanzkriterium hat zwei Ausgänge. „Das Formular sollte sich schnell anfühlen“ hat eine Steigung, kein Ergebnis. Wenn du eine Grenze brauchst, schreibe sie: „die Checkout-Seite zeigt den Fehler ohne eine weitere Anfrage an den Server.“ Wenn du nicht sagen kannst, wie ein Fehlschlag aussieht, ist der Satz noch kein Kriterium.
Keine vagen Wörter
Streiche Wörter, die das Ergebnis verstecken: graceful, intuitiv, robust, benutzerfreundlich, nahtlos, schnell, sollte und angemessen. Ersetze jedes durch den Beleg, den du akzeptieren würdest. „Fehler elegant behandeln“ wird zu „Enter a valid email address neben dem Feld zeigen und die Bestellung nicht aufgeben.“
Given/When/Then und eine Checkliste
Zwei Formen decken die meisten Beispiele für Akzeptanzkriterien ab, die Teams wirklich behalten. Given/When/Then ist ein Szenario. Eine Checkliste ist eine Liste von Ergebnissen. Nimm das Szenario, wenn die Reihenfolge von Zustand, Aktion und Ergebnis zählt. Nimm die Checkliste, wenn du unabhängige Ergebnisse einer Aktion aufzählst.
Die Gherkin-Referenz von Cucumber gibt Schritten die Schlüsselwörter Given, When, Then, And und But. Die Referenz verwendet Englisch; Gherkin hat auch Übersetzungen dieser Wörter. Der Text nach dem Schlüsselwort wird mit Code verbunden, einer Step Definition, wenn Cucumber die Datei ausführt. SpecScore benutzt diese Schicht nicht. Das Beispiel unten ist Gherkin, damit die Form vertraut ist. Es ist keine SpecScore-Datei.
Given/When/Then
Scenario: Reject an email that is not a valid address
Given the shopper is on the checkout form
When the shopper submits the email "not-an-email"
Then the page shows "Enter a valid email address" beside the email field
And the order is not placed
Checkliste
- Submitting the email "not-an-email" shows "Enter a valid email address" beside the email field.
- The order is not placed.
Behalte ein einziges When. Eine zweite Aktion ist ein zweites Szenario. And setzt dasselbe Schlüsselwort fort: ein weiteres Given oder ein weiteres Then. Benutze And nicht, um ein zweites Verhalten einzuschmuggeln.
Eine Checkliste ist derselbe Vertrag ohne die Schlüsselwörter. Jede Zeile bleibt ein beobachtbares Ergebnis. Die Checkliste oben ist das Then des Szenarios, als Prüfungen geschrieben.
Alistair Mavins Leitfaden definiert EARS (Easy Approach to Requirements Syntax) als einen Mechanismus, der textliche Anforderungen sanft begrenzt. Die Klauseln bleiben in einer Reihenfolge. Der Leitfaden gibt die allgemeine Form: While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>. Eine Anforderung hat null oder mehr Vorbedingungen, null oder einen Auslöser, einen Systemnamen und eine oder mehr Systemantworten.
Dieser Satz ist die Pflicht: die Regel, die das System erfüllen soll. Ein Akzeptanzkriterium ist die Bedingung, die wahr sein muss, damit die Pflicht als erfüllt gilt. Ein Given/When/Then-Szenario ist ein konkreter Fall dieser Bedingung. Du kannst die Anforderung als EARS-Satz schreiben und das Kriterium frei von Beispieldaten halten.
In einem SpecScore-Feature kann die Anforderung ein EARS-artiger Satz unter einer Überschrift #### REQ: sein. Das Kriterium bleibt die abstrakte Bedingung. Das Szenario trägt das Beispiel. EARS ersetzt keines von beiden. Es begrenzt nur den Anforderungssatz.
Beispiele für Akzeptanzkriterien: vage und prüfbar
Den Beleg benennen
Vage
The checkout form should handle bad input gracefully and feel fast.
Prüfbar
When the shopper submits the email "not-an-email", the checkout page shows "Enter a valid email address" beside that field and does not place the order.
Der vage Satz versteckt zwei Forderungen (Fehler, Geschwindigkeit) und keinen Beleg. Der prüfbare Satz hat eine Aktion und zwei Ergebnisse, die ein Mensch oder ein Agent prüfen kann. Die Beispiele bleiben Englisch, weil die Schlüsselwörter des Formats Englisch sind.
Ein Verhalten
Vage
Users can sign in, reset a password, and see an error if the account is locked.
Prüfbar
When a visitor submits a known email and the matching password, the app sets a session cookie and redirects to /dashboard.
Anmeldung, Zurücksetzen und Sperre sind drei Verhalten. Der prüfbare Satz behält die Anmeldung. Zurücksetzen und Sperre bekommen je ein eigenes Kriterium, mit eigenen Eingaben und Ergebnissen.
Ergebnis, nicht der Funktionsname
Vage
The handler returns 400 from validateEmail().
Prüfbar
When the shopper submits an email that is not a valid address, the checkout page shows "Enter a valid email address" and does not place the order.
Ein Funktionsname und ein Statuscode binden das Kriterium an den heutigen Code. Das Ergebnis gilt weiter, wenn die Prüfung in eine andere Funktion wandert. Behalte Statuscodes, wenn der Statuscode das versprochene Verhalten ist, und sage ihn als beobachtbares Ergebnis.
Wie SpecScore sie speichert und was CI prüft
SpecScore veröffentlicht das Format im Repository specscore/specscore und die CLI in specscore/specscore-cli. Die beiden Dokumente beschreiben Akzeptanzkriterien nicht in genau derselben Form. Beide sind aktuell. Dieser Abschnitt sagt, welches welches ist, und danach, was specscore spec lint tatsächlich ablehnt.
Die Spezifikation der Akzeptanzkriterien — das Feature-README unter dieser URL — setzt Kriterien inline in das Feature-README. Jedes Feature hat einen Abschnitt ## Acceptance Criteria. Jedes Kriterium ist eine Überschrift ### AC: {slug}. Der Slug ist kleingeschrieben und mit Bindestrichen getrennt. Die nächste Zeile ist **Requirements:** und listet die gebündelten Anforderungen als {feature-id}#req:{slug}. Danach kommt Prosa: die zusammengesetzte Bedingung. Die Spezifikation sagt, dass diese Prosa abstrakt bleibt. Sie darf keine Given/When/Then-Schritte, keine Beispieleingaben und kein Implementierungsdetail enthalten. Wenn noch keine Kriterien existieren, lautet der Abschnitt „Not defined yet.“ und Open Questions sagt „Acceptance criteria not yet defined for this feature.“. Kriterien sind optionale Bündelung: Die Spezifikation sagt, eines anzulegen, wenn es zwei oder mehr Anforderungen bündelt, und es wegzulassen, wenn es nur eine einzelne Anforderung wiederholen würde.
Der konkrete Beweis ist eine Szenariodatei im Verzeichnis _tests/ des Features. Die Szenariospezifikation verlangt einen Titel # Scenario:, einen Abschnitt ## Steps, die Großbuchstaben GIVEN, WHEN, THEN und AND, und genau ein WHEN. Eine optionale Zeile **Validates:** verknüpft das Szenario mit {feature-path}#ac:{slug} oder mit einer Anforderung. Ein Abschnitt ## Rehearse darf ein ausführbares Skript in einem rehearse-Block enthalten, der mit einem Shebang beginnt.
Die CLI liest außerdem dünne Kriteriendateien, eine je Kriterium, unter _acs/<slug>.ac.md. Das Login-Beispiel und der Rehearse-Leitfaden dokumentieren diese Form: # AC: <slug>, optionale **Status:**, **Verifies:** und **Applies-to:**, und die Bedingung unter ## Statement. specscore rehearse acs <feature-dir> druckt eine Übersichtstabelle aus diesen Dateien. specscore rehearse acs --write ersetzt den Abschnitt Acceptance Criteria im Feature-README durch diese Tabelle und einen Kommentar, dass der Abschnitt erzeugt wird und nicht von Hand bearbeitet werden soll. Eine Datei ohne Überschrift # AC: ist ein Fehler dieses Befehls.
CI in diesem Repository ist der Dogfood-Workflow. Er installiert CLI v0.39.1 und führt specscore spec lint bei Pull Requests und bei Pushs auf main aus. Geprüft am 3. November 2026: dieses Release und der Default-Branch der CLI enthalten die Regeln unten. Der Linter prüft Struktur. Er benotet kein Englisch.
Die Regel ac-heading-format ist ein Fehler. In einem Feature-README (eine Datei, deren Titel # Feature: ist) muss eine Zeile, die wie eine Kriteriumsüberschrift aussieht, genau ### AC: <id> sein, mit einem Leerzeichen nach dem Doppelpunkt und einer Kebab-Case-Id. Eine Überschrift ### AC: <id> (verifies ...) wird ebenfalls akzeptiert. --fix repariert nur Abstände. Eine Id mit Großbuchstaben oder Unterstrichen wird gemeldet und einer Person überlassen. Die Regel verlangt die Zeile **Requirements:** nicht, verlangt den Platzhalter „Not defined yet.“ nicht und warnt nicht, wenn die Prosa Given, When oder Then enthält. Das Szenario der Spezifikation für diese Warnung ist in dieser CLI keine Lint-Regel.
Bei einem Plan, der ein Quell-Feature nennt, liest der Linter ### AC:-Überschriften im Abschnitt Acceptance Criteria dieses Features. Regel P-002 meldet einen Task-Wert **Verifies:**, der nicht <feature-slug>#ac:<ac-slug> für eine dieser Überschriften ist. Regel P-001 meldet eine Überschrift, die kein Task abdeckt und die nicht unter ## Deferred AC Coverage steht. Diese beiden Regeln öffnen _acs/*.ac.md nicht. Eine Tabelle von rehearse acs --write hat keine ### AC:-Überschriften, also sehen die Planregeln die dünnen Dateien nicht.
Derselbe Lint-Befehl prüft die Schlüsselwörter der Szenarioschritte nicht. specscore rehearse führt Szenariodateien aus: Der Rehearse-Leitfaden setzt eine Überschrift wie ## Given oder ## When über einen Befehl im Codeblock und **Use:**, um eine wiederverwendbare Prüfung aufzurufen. Eine Datei mit einem Given und mehreren When läuft als getrennte Fälle. specscore rehearse new <feature-slug>#ac:<ac-slug> liest das Feature-README und zieht Given/When/Then-Zeilen aus diesem Kriterium nach spec/features/<feature-slug>/_tests/<ac-slug>.md. Nichts davon läuft im Dogfood-Workflow. Der Workflow führt specscore spec lint aus.
Inline-Kriterium, aus der Spezifikation der Akzeptanzkriterien
## Acceptance Criteria
### AC: invalid-email-rejected
**Requirements:** checkout#req:reject-invalid-email
An email that is not a valid address is rejected, and the order is not placed.
Dünne Kriteriendatei, die Form, die rehearse acs liest
# AC: invalid-email-rejected
**Status:** accepted
**Verifies:** checkout#req:reject-invalid-email
## Statement
An email that is not a valid address is rejected, and the order is not placed.
Szenariodatei, aus der Szenariospezifikation
# Scenario: Reject an invalid email
**Validates:** [checkout#ac:invalid-email-rejected](../README.md#ac-invalid-email-rejected)
## Steps
GIVEN the shopper is on the checkout form
WHEN the shopper submits the email "not-an-email"
THEN the page shows "Enter a valid email address" beside the email field
AND the order is not placed
Rehearse-Szenario, die Form im Rehearse-Leitfaden
# Rehearse: Reject an invalid email
## Given a submitted email that is not a valid address
```bash
printf 'email=not-an-email\n' > form.txt
```
## When the response is recorded
```bash
printf 'Enter a valid email address\n' > out.txt
```
## Then the message is the invalid-email text
```bash
grep -q 'Enter a valid email address' out.txt
```
Die vier Beispiele illustrieren diese Formen. Sie sind kein vollständiger Feature-Baum, und diese Seite behauptet nicht, dass sie allein specscore spec lint bestehen. Ein Feature-README braucht auch seine anderen Pflichtabschnitte, bevor dieser Befehl sauber ist.
Wenn du eine Fragenliste brauchst, um das Kriterium aus einem vagen Wunsch zu ziehen, nimm Gute Fragen stellen. Der Login-Durchgang zeigt ein dünnes Kriterium, session-hardened, neben den anderen Artefakten.
FAQ
Was sind Akzeptanzkriterien?
Akzeptanzkriterien (AC) sind die Bedingungen, die wahr sein müssen, bevor eine Änderung als erledigt gilt. In der SpecScore-Spezifikation sind sie abstrakt: Sie sagen, was wahr sein muss, und überlassen die konkreten Schritte einem Szenario.
Was ist Given/When/Then?
Given/When/Then ist die Schrittform in Gherkin: Given ein Ausgangszustand, When eine Aktion geschieht, Then folgt ein beobachtbares Ergebnis. Cucumber dokumentiert die Schlüsselwörter in der Gherkin-Referenz. Die Szenariospezifikation von SpecScore verwendet die Großbuchstaben GIVEN, WHEN, THEN und AND, mit genau einem WHEN je Szenariodatei.
Wie schreibe ich Akzeptanzkriterien für einen KI-Coding-Agenten?
Schreibe ein beobachtbares Verhalten, mit handelnder Person, Eingabe und Ergebnis, und ohne vage Wörter. Lege Beispieldaten in ein Szenario, nicht in das abstrakte Kriterium. Der Agent kann dann gegen das Kriterium implementieren und das Szenario prüfen.
Sind Akzeptanzkriterien dasselbe wie Testfälle?
Nein. Ein Kriterium nennt die Bedingung. Ein Testfall, oder ein SpecScore-Szenario, ist ein Lauf mit konkreten Eingaben, der zeigt, dass die Bedingung gilt oder scheitert. Mehrere Szenarien können ein Kriterium stützen.
Bewertet specscore spec lint vage Formulierungen?
Nein. In CLI v0.39.1, dem Release, das die CI dieses Repositories installiert, prüft ac-heading-format die Überschrift ### AC:. Es bewertet Wörter wie „graceful“ oder „fast“ nicht und warnt nicht, wenn ein Kriterium Given/When/Then enthält. Formulierung ist eine Schreibaufgabe. Die Validatoren-Seite trennt diesen deterministischen Lint von der manuellen KI-Prüfung.
Wohin gehören Given/When/Then-Schritte in SpecScore?
In ein Szenario, nicht in das Akzeptanzkriterium. Die Spezifikation der Akzeptanzkriterien verbietet Given/When/Then-Schritte im Kriterium. Die Szenariospezifikation legt sie unter _tests/ in ## Steps. Rehearse führt eine verwandte Form aus: Überschriften und Befehle in Codeblöcken unter _tests/, dokumentiert im Rehearse-Leitfaden. Der Linter erzwingt die Schritt-Schlüsselwörter nicht.
Quellen
Gelesen am 3. November 2026. Seiten Dritter werden nur für die Definitionen zitiert, die sie veröffentlichen.