# Akzeptanzkriterien schreiben, die ein KI-Agent prüfen kann Canonical: https://specscore.md/de/articles/acceptance-criteria/ Aktualisiert am 3. November 2026. [Akzeptanzkriterien](https://specscore.md/acceptance-criteria-specification) (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](https://cucumber.io/docs/gherkin/reference/), der Sprache, die [Cucumber](https://cucumber.io/docs/bdd/) 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](https://specscore.md/de/spec-driven-development/) (SDD, spec-driven development) behandelt eine strukturierte Spezifikation, nicht nur diese Prosa, als die Quelle, gegen die die Implementierung geprüft wird. [EARS](https://alistairmavin.com/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](https://specscore.md/de/validators/). 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. ## 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](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) 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](https://specscore.md/acceptance-criteria-specification) 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](https://cucumber.io/docs/gherkin/reference/) 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 ```gherkin 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 ```markdown - 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. ## Wie das zu EARS-Anforderungen steht Die Satzmuster sind beschrieben in [EARS-Anforderungssyntax erklärt, mit Beispielen](https://specscore.md/de/articles/ears-requirements/). [Alistair Mavins Leitfaden](https://alistairmavin.com/ears/) 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 , when , the shall . 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** ```text The checkout form should handle bad input gracefully and feel fast. ``` **Prüfbar** ```text 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** ```text Users can sign in, reset a password, and see an error if the account is locked. ``` **Prüfbar** ```text 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** ```text The handler returns 400 from validateEmail(). ``` **Prüfbar** ```text 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](https://github.com/specscore/specscore) und die CLI in [specscore/specscore-cli](https://github.com/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](https://specscore.md/acceptance-criteria-specification) — 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](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) 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/.ac.md`. Das [Login-Beispiel](https://specscore.md/example-login) und der [Rehearse-Leitfaden](https://specscore.md/rehearse) dokumentieren diese Form: `# AC: `, optionale `**Status:**`, `**Verifies:**` und `**Applies-to:**`, und die Bedingung unter `## Statement`. `specscore rehearse acs ` 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](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). 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: ` sein, mit einem Leerzeichen nach dem Doppelpunkt und einer Kebab-Case-Id. Eine Überschrift `### AC: (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 `#ac:` 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 #ac:` liest das Feature-README und zieht Given/When/Then-Zeilen aus diesem Kriterium nach `spec/features//_tests/.md`. Nichts davon läuft im Dogfood-Workflow. Der Workflow führt `specscore spec lint` aus. ### Inline-Kriterium, aus der Spezifikation der Akzeptanzkriterien ```markdown ## 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 ```markdown # 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 ```markdown # 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 ~~~~markdown # 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](https://specscore.md/asking-good-questions). 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](https://specscore.md/de/validators/) 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. - [Cucumber — Gherkin-Referenz](https://cucumber.io/docs/gherkin/reference/) - [Cucumber — verhaltensgetriebene Entwicklung](https://cucumber.io/docs/bdd/) - [Alistair Mavin — EARS](https://alistairmavin.com/ears/) - [EARS-Anforderungssyntax erklärt, mit Beispielen](https://specscore.md/de/articles/ears-requirements/) - [SpecScore — Spezifikation der Akzeptanzkriterien](https://specscore.md/acceptance-criteria-specification) - [specscore/specscore — Feature Akzeptanzkriterien](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — Feature Szenario](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — Feature Anforderung](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [SpecScore — Feature-Spezifikation](https://specscore.md/feature-specification) - [SpecScore — Rehearse](https://specscore.md/rehearse) - [SpecScore — Login-Beispiel](https://specscore.md/example-login) - [SpecScore — Gute Fragen stellen](https://specscore.md/asking-good-questions) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) - [Dogfood-Workflow (CLI v0.39.1)](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore-cli — ac-heading-format](https://github.com/specscore/specscore-cli/blob/main/pkg/lint/ac_heading.go) - [specscore-cli — Planregeln P-001 und P-002](https://github.com/specscore/specscore-cli/blob/main/pkg/lint/plan_rules.go) ## Verwandt - [PRD-Vorlage in Markdown für KI-Coding](https://specscore.md/de/articles/feature-spec-template/) - [Spezifikationen in CI linten mit einem Spezifikationslinter](https://specscore.md/de/articles/lint-specs-in-ci/) - [EARS-Anforderungssyntax erklärt, mit Beispielen](https://specscore.md/de/articles/ears-requirements/) - [Spezifikationsgetriebene Entwicklung](https://specscore.md/de/spec-driven-development/) - [Werkzeuge für spezifikationsgetriebene Entwicklung](https://specscore.md/de/spec-driven-development/tools/) - [Spezifikation der Akzeptanzkriterien](https://specscore.md/acceptance-criteria-specification) - [Gute Fragen stellen](https://specscore.md/asking-good-questions) - [Ein Login-Feature, am Beispiel](https://specscore.md/example-login) - [Rehearse](https://specscore.md/rehearse) - [Was SpecScore prüft](https://specscore.md/de/validators/) - [CLI](https://specscore.md/de/cli/)