# EARS-Anforderungssyntax erklärt, mit Beispielen Canonical: https://specscore.md/de/articles/ears-requirements/ Zuletzt aktualisiert: 2. November 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) ist eine Anforderungsnotation: eine kleine Menge englischer Satzmuster, auch EARS-Syntax genannt, die eine Bedingung, einen Auslöser und eine Systemantwort in fester Reihenfolge hält. Eine Anforderung ist eine prüfbare Pflicht, die ein System erfüllen muss. [Spezifikationsgetriebene Entwicklung](https://specscore.md/de/spec-driven-development/) (SDD, spec-driven development) heißt, diese Pflicht vor dem Code in eine Spezifikation zu schreiben und die Spezifikation als Quelle der Wahrheit zu behandeln. Ein Product Requirements Document (PRD) ist die Prosa, die Problem und Umfang nennt, bevor die Arbeit in Aufgaben zerlegt wird. In [SpecScore](https://specscore.md/) ist eine Anforderung (REQ) eine benannte Regel in einem Feature, und ein Akzeptanzkriterium (AC, acceptance criterion) ist eine optionale abstrakte Bedingung, die auf eine oder mehrere dieser Regeln zeigt. [Kontinuierliche Integration](https://specscore.md/de/validators/) (CI, continuous integration) ist eine automatische Prüfung bei jeder vorgeschlagenen Änderung. Die Prüfung ist ein Befehl der [Kommandozeile](https://specscore.md/de/cli/) (CLI, command-line interface): `specscore spec lint`. [Kiro](https://kiro.dev/), eine agentische integrierte Entwicklungsumgebung (IDE, integrated development environment) von Amazon Web Services (AWS), schreibt eines dieser Muster. Die Notation veröffentlichten Alistair Mavin und Kollegen bei Rolls-Royce 2009 auf einer Requirements-Engineering-Konferenz des Institute of Electrical and Electronics Engineers (IEEE). ## Woher EARS kommt Alistair Mavin, Philip Wilkinson, Adrian Harwood und Mark Novak, damals bei Rolls-Royce PLC, veröffentlichten „Easy Approach to Requirements Syntax (EARS)“ auf der 17th IEEE International Requirements Engineering Conference 2009. Der Dokumentbezeichner ist [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9). Sie bauten die Regeln, während sie Anforderungen an die Triebwerksregelung aus der Certification Specification for Engines (CS-E), Abschnitt CS-E 50, einer Lufttüchtigkeitsvorschrift, herauszogen. Dieser Text mischte Anforderungen, Entwurfsleitfäden und Notizen. Der Aufsatz nennt acht Probleme unbeschränkter natürlicher Sprache: Mehrdeutigkeit, Vagheit, Komplexität, Auslassung, Doppelung, Wortreichtum, unpassende Implementierung und Nicht-Testbarkeit. Ein kleines Regelwerk sollte jede solche Anforderung in eine von fünf Schablonen bringen. Die Autoren sagen, die Notation passe für Stakeholder-Anforderungen auf hoher Ebene, und sie beanspruchen nicht, jede Zerlegungsstufe eines Systems abzudecken. [Mavins eigene Anleitung](https://alistairmavin.com/ears/) beschreibt EARS als eine Weise, textuelle Anforderungen sanft zu begrenzen. Die Klauseln bleiben in einer Reihenfolge, die er temporale Logik nennt: jede Vorbedingung, dann der Auslöser, dann der Systemname und die Antwort. Sein Regelwerk ist null oder viele Vorbedingungen, null oder ein Auslöser, ein Systemname und eine oder viele Antworten. Der Aufsatz von 2009 spezialisiert diese Form auf fünf Schablonen. Dieselbe Anleitung benennt auch komplexe Anforderungen, die die Schlüsselwörter kombinieren. In der Fallstudie des Aufsatzes enthielt der Rohauszug 36 Anforderungen und die umgeschriebene Menge 47. Die mittlere Länge fiel von 36,9 auf 25,6 Wörter. Die Autoren berichten, dass in dieser Studie Komplexität, Auslassung, Doppelung, unpassende Implementierung und Nicht-Testbarkeit in der umgeschriebenen Menge fehlten, während Mehrdeutigkeit, Vagheit und Wortreichtum sanken, aber nicht verschwanden. Sie nennen auch die Grenzen: eine kleine Stichprobe, nur Sicherheitsanforderungen auf hoher Ebene und Urteil bei der Einstufung von Vagheit. Diese Zahlen sind die des Aufsatzes, für dieses eine Dokument. ## Die EARS-Satzmuster Die Schlüsselwörter sind die aus dem Aufsatz von 2009 und aus Mavins Anleitung. Der Aufsatz erlaubt auch *During* statt *While* für einen Zustand, mit derselben Bedeutung, wenn das klarer liest. Die Beispielsätze illustrieren die Schablonen. Sie sind keine Zitate aus dem Aufsatz. Kiro schreibt das ereignisgetriebene Muster in Großbuchstaben; die ursprüngliche Notation nutzt Satzanfang. Die Beispiele bleiben Englisch, weil die EARS-Syntax Englisch ist. ### Allgegenwärtig `The shall ` Immer aktiv. Es gibt kein EARS-Schlüsselwort, weil es keine Vorbedingung und keinen Auslöser gibt. Die eigene Illustration des Aufsatzes von 2009 ist ein Regelsystem, das Überdrehzahl des Triebwerks verhindern soll. **Beispiel:** The checkout system shall keep the order total equal to the sum of its line items. ### Ereignisgetrieben `When , the shall ` Die Antwort ist erforderlich, wenn an der Systemgrenze ein Auslöser erkannt wird, und nur dann. Das Schlüsselwort ist *When*. **Beispiel:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### Zustandsgetrieben `While , the shall ` Die Antwort ist erforderlich, solange das System im genannten Zustand bleibt. Das Schlüsselwort ist *While*. **Beispiel:** While the cart is empty, the checkout system shall keep the pay button disabled. ### Unerwünschtes Verhalten `If , then the shall ` Die Antwort behandelt einen Ausfall, eine Störung, eine Abweichung oder anderes unerwünschtes Verhalten. Die Schlüsselwörter sind *If* und *then*. Der Aufsatz gab diesem Muster eigene Schlüsselwörter, damit diese Anforderungen sichtbar bleiben. Die Autoren merken an, dass erwünscht und unerwünscht manchmal eine Frage des Blickwinkels ist. **Beispiel:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### Optionale Funktion `Where , the shall ` Die Antwort gilt nur, wenn das Produkt die genannte Funktion enthält. Das Schlüsselwort ist *Where*. **Beispiel:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### Komplex `While , when , the shall ` Mehr als ein Schlüsselwort. Mavins Anleitung hält dieselbe Klauselreihenfolge: *While* für die Vorbedingung, dann *When* für den Auslöser, dann die Systemantwort. Der Aufsatz von 2009 kombiniert *While* auch mit *If / then* für unerwünschtes Verhalten in einem Zustand. Eine Illustration dieser Kombination: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **Beispiel:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## Typische Fehler ### Mehrere Pflichten in einem Satz Der Aufsatz behandelt einen zusammengesetzten Satz als das Komplexitätsproblem und teilt ihn. Die [SpecScore-Anforderungsspezifikation](https://specscore.md/requirement-specification) sagt dasselbe in ihren Begriffen: jedes `REQ` muss genau eine prüfbare Pflicht ausdrücken. ### Unerwünschtes Verhalten in When verstecken *When* ist für einen Auslöser, den man erwartet. *If / then* ist für das Verhalten, dem man lieber nicht begegnet. Ein Schlüsselwort für beides lässt den unerwünschten Fall wie den normalen aussehen. Das ist das Auslassungsproblem, das der Aufsatz benennt. ### Die Implementierung schreiben „The checkout system shall store the flag in Redis“ nennt einen Entwurf. Der Aufsatz nennt das unpassende Implementierung. Die Antwort soll sagen, was das System erreichen muss, nicht welche Komponente es tut. ### Kein Systemname „When the form is submitted, shall show an error“ hat kein Subjekt. Mavins Regelwerk verlangt einen Systemnamen. ### Auslöser nach der Antwort „The checkout system shall show an error when the form is submitted“ setzt den Auslöser an das Ende. Die veröffentlichte Reihenfolge ist Vorbedingung, dann Auslöser, dann Antwort. ### Kiros eine Zeile für ganz EARS halten Kiros Seite zu Feature-Specs veröffentlicht ein einziges Muster, `WHEN … THE SYSTEM SHALL …`. Allgegenwärtig, *While*, *If / then*, *Where* und komplexe Kombinationen gehören zur Notation im Aufsatz und in Mavins Anleitung. Auf dieser Kiro-Seite stehen sie nicht. ## Wie Kiro EARS verwendet [Kiros Seite zu Feature-Specs](https://kiro.dev/docs/specs/feature-specs/), als aktualisiert am 4. August 2026 markiert und am 2. November 2026 gelesen, sagt, die Datei `requirements.md` nutze EARS. Das dort gedruckte Muster ist `WHEN [condition/event]` gefolgt von `THE SYSTEM SHALL [expected behavior]`. Das Beispiel der Seite: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. Die [Seite Requirements-First](https://kiro.dev/docs/specs/feature-specs/requirements-first/) sagt, ein erzeugtes `requirements.md` enthalte User Stories mit Akzeptanzkriterien und Systemverhalten in derselben Form WHEN … THE SYSTEM SHALL …. Das Registrierungsbeispiel sind drei Sätze: gültige Registrierungsdaten legen ein Konto an, eine schon vorhandene E-Mail zeigt „Email already registered“, und ein ungültiges E-Mail-Format zeigt einen Validierungsfehler. Vor dem Entwurf sucht Analyze Requirements nach logischen Widersprüchen, Mehrdeutigkeit, kollidierenden Einschränkungen und Lücken. Die Feature-Spec-Seite sagt, man wähle das aus den Chat-Optionen oder dem Continue-Menü im Editor, nachdem die Anforderungen erzeugt wurden. `design.md` und `tasks.md` stehen neben den Anforderungen. Quick Spec läuft Anforderungen, Entwurf und Aufgaben ohne eine Freigabe dazwischen. Diese Analyse ist ein Schritt in Kiro. Die Feature-Spec-Seite beschreibt sie nicht als Format-Linter, den man der eigenen CI hinzufügt. Wie andere Werkzeuge eine Spezifikation prüfen, steht im [Werkzeugführer](https://specscore.md/de/spec-driven-development/tools/). Der Vergleich der beiden Produkte ist [SpecScore vs Kiro](https://specscore.md/de/vs/kiro/). ## Dieselbe Anforderung in SpecScore SpecScore prüft nicht, ob ein Satz einer EARS-Schablone entspricht. `specscore spec lint` aus dem Repository [specscore-cli](https://github.com/specscore/specscore-cli) prüft Struktur. Der Hilfetext nennt README-Dateien, Open-Questions-Abschnitte, Überschriftenebenen, Feature-Verweise, interne Links und Indexeinträge. Ein EARS-Satz kann die Prosa unter einer `REQ`-Überschrift sein. Der Linter benotet das Englisch nicht. Die [Anforderungsspezifikation](https://specscore.md/requirement-specification) setzt jede Anforderung unter eine Themenüberschrift in `## Behavior`, eine Ebene tiefer, typisch `#### REQ: slug`. Der Slug nutzt Kleinbuchstaben, Ziffern und Bindestriche. Der Bezeichner ist `{feature-path}#req:{slug}`. Die Spezifikation sagt, eine Anforderung solle Schlüsselwörter aus RFC 2119 (Request for Comments 2119) nutzen: MUST, MUST NOT, SHOULD, SHOULD NOT und MAY. In der Abbildung unten steht EARS-*shall* als MUST. Ein [Akzeptanzkriterium](https://specscore.md/acceptance-criteria-specification) ist optional. Wenn eines verwendet wird, ist es `### AC: slug` in `## Acceptance Criteria`, und die nächste Zeile ist `**Requirements:**` mit diesen Bezeichnern. Die Spezifikation der Akzeptanzkriterien sagt, das AC nenne eine abstrakte Bedingung und dürfe keine Given/When/Then-Schritte, konkrete Eingaben oder Implementierungsdetails enthalten. Ein konkreter Ablauf ist ein [Szenario](https://specscore.md/scenario-specification) im Verzeichnis `_tests/` des Features. Die [Feature-Spezifikation](https://specscore.md/feature-specification) verlangt außerdem Status, Zusammenfassung, Problem, Verhalten, Akzeptanzkriterien, offene Fragen und eine Adherence-Fußzeile. Die Dateien unten sind ein Checkout-Feature. `show-field-error` ist das ereignisgetriebene Beispiel. `reject-invalid-email` ist das Beispiel für unerwünschtes Verhalten. Am 2. November 2026 meldete `specscore spec lint` 0 Verstöße für diesen Baum mit specscore 0.55.1, der am 30. Oktober 2026 veröffentlichten letzten Version, und mit specscore 0.39.1, der in [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) festgelegten Version. Das [Format-Repository](https://github.com/specscore/specscore) ist der Ort dieses Workflows. ### spec/features/checkout/README.md ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### spec/features/README.md — die Beschreibungszelle ist der Zusammenfassungssatz des Features. Die Linter-Regel feature-index-row-sync wies eine kürzere Beschreibung zurück. ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### spec/README.md — ohne den Abschnitt Open Questions kam oq-section: Open Questions section not found. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org und project.repo sind die Werte, gegen die die Studio-Toolbar-Zeile geprüft wird. Ohne sie meldete der Linter studio-toolbar: studio toolbar requires project host/org/repo. ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` Zwei weitere Fehler traten auf, bis dieses Beispiel durchlief, und beide sind in den Dateien oben behoben. Ein Feature ohne `**Source Ideas:**` scheiterte an `feature-source-ideas-required`; `—` ist der leere Wert. Der Feature-Index brauchte außerdem das Frontmatter-Feld `format: https://specscore.md/features-index-specification`. Ein bestandener Lauf heißt, die Dateien erfüllen diese Strukturregeln. Er heißt nicht, die Sätze seien gutes EARS, und nicht, dass das Checkout-Produkt existiert. Given/When/Then für dieses Verhalten wäre eine Szenariodatei unter `spec/features/checkout/_tests/`, nicht ein weiterer Absatz im AC. ## Fragen ### Wofür steht EARS? Easy Approach to Requirements Syntax. Es ist eine Menge von Satzmustern für Anforderungen, veröffentlicht von Alistair Mavin, Philip Wilkinson, Adrian Harwood und Mark Novak von Rolls-Royce auf der 17th IEEE International Requirements Engineering Conference 2009 und auf Mavins Website beschrieben. ### Ist Kiros Notation ganz EARS? Kiros Feature-Spec-Seite legt ein Muster fest: WHEN … THE SYSTEM SHALL …. Der Aufsatz von 2009 und Mavins Anleitung definieren außerdem allgegenwärtige Anforderungen, zustandsgetriebenes While, unerwünschtes If/then, optionales Where und komplexe Kombinationen dieser Schlüsselwörter. ### Prüft SpecScore die EARS-Syntax? Nein. `specscore spec lint` prüft die Dateistruktur von SpecScore. Ein EARS-Satz kann die Prosa eines `REQ` sein. Der Linter benotet das Englisch nicht. ### Wohin gehören Given/When/Then-Beispiele? In ein Szenario im Verzeichnis `_tests/` des Features. Ein Akzeptanzkriterium bleibt eine abstrakte Bedingung und darf laut Spezifikation der Akzeptanzkriterien keine Given/When/Then-Schritte enthalten. ## Quellen Gelesen am 2. November 2026, außer wo eine Seite ihr eigenes Aktualisierungsdatum druckt. Die Kiro-Feature-Spec-Seite sagt, sie sei am 4. August 2026 aktualisiert worden. - [Mavin, Wilkinson, Harwood und Novak — Easy Approach to Requirements Syntax (EARS), 17th IEEE International Requirements Engineering Conference, 2009, DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Alistair Mavin — EARS-Anleitung](https://alistairmavin.com/ears/) - [Kiro-Dokumentation — Feature-Specs und EARS (Seite aktualisiert am 4. August 2026)](https://kiro.dev/docs/specs/feature-specs/) - [Kiro-Dokumentation — Requirements-First-Ablauf](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — Anforderungsspezifikation](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — Spezifikation der Akzeptanzkriterien](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — Szenariospezifikation](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — Feature-Spezifikation](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — Dogfood-CI-Workflow](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) ## 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/) - [Akzeptanzkriterien schreiben, die ein KI-Agent prüfen kann](https://specscore.md/de/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/de/vs/kiro/) - [Werkzeuge für spezifikationsgetriebene Entwicklung](https://specscore.md/de/spec-driven-development/tools/) - [Spezifikationsgetriebene Entwicklung](https://specscore.md/de/spec-driven-development/) - [Anforderungsspezifikation](https://specscore.md/requirement-specification) - [Spezifikation der Akzeptanzkriterien](https://specscore.md/acceptance-criteria-specification) - [Feature-Spezifikation](https://specscore.md/feature-specification) - [Validatoren und CI](https://specscore.md/de/validators/)