# Składnia wymagań EARS wyjaśniona, z przykładami Canonical: https://specscore.md/pl/articles/ears-requirements/ Ostatnia aktualizacja: 2 listopada 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) to notacja wymagań: mały zestaw angielskich wzorców zdań, nazywany też składnią EARS, który trzyma warunek, wyzwalacz i odpowiedź systemu w stałej kolejności. Wymaganie to jeden sprawdzalny obowiązek, który system musi spełnić. [Rozwój sterowany specyfikacją](https://specscore.md/pl/spec-driven-development/) (SDD, spec-driven development) to praktyka zapisania tego obowiązku w specyfikacji przed kodem i traktowania specyfikacji jako źródła prawdy. Dokument wymagań produktu (PRD, product requirements document) to proza, która nazywa problem i zakres, zanim praca zostanie podzielona na zadania. W [SpecScore](https://specscore.md/) wymaganie (REQ) to nazwana reguła wewnątrz funkcji, a kryterium akceptacji (AC, acceptance criterion) to opcjonalny abstrakcyjny warunek wskazujący jedną lub więcej takich reguł. [Ciągła integracja](https://specscore.md/pl/validators/) (CI, continuous integration) to automatyczne sprawdzenie przy każdej proponowanej zmianie. Sprawdzenie jest poleceniem [interfejsu wiersza poleceń](https://specscore.md/pl/cli/) (CLI, command-line interface): `specscore spec lint`. [Kiro](https://kiro.dev/), agentowe zintegrowane środowisko programistyczne (IDE, integrated development environment) od Amazon Web Services (AWS), zapisuje jeden z tych wzorców. Notację po raz pierwszy opublikowali Alistair Mavin i współpracownicy z Rolls-Royce na konferencji inżynierii wymagań Institute of Electrical and Electronics Engineers (IEEE) w 2009 roku. ## Skąd wzięło się EARS Alistair Mavin, Philip Wilkinson, Adrian Harwood i Mark Novak, wtedy w Rolls-Royce PLC, opublikowali „Easy Approach to Requirements Syntax (EARS)” na 17th IEEE International Requirements Engineering Conference w 2009 roku. Identyfikator dokumentu to [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9). Reguły powstały przy wyciąganiu wymagań sterowania silnikiem z Certification Specification for Engines (CS-E), sekcja CS-E 50, przepisu zdatności do lotu. Ten tekst mieszał wymagania, wskazówki projektowe i notatki. Artykuł nazywa osiem problemów nieograniczonego języka naturalnego: niejednoznaczność, ogólnikowość, złożoność, pominięcie, powtórzenie, rozwlekłość, nieodpowiednią implementację i niemożność testowania. Mały zestaw reguł miał pozwolić każdemu takiemu wymaganiu użyć jednego z pięciu szablonów. Autorzy piszą, że notacja pasuje do wysokopoziomowych wymagań interesariuszy i nie twierdzą, że obejmuje każdy poziom dekompozycji systemu. [Własny przewodnik Mavina](https://alistairmavin.com/ears/) opisuje EARS jako sposób łagodnego ograniczenia wymagań tekstowych. Klauzule zostają w jednej kolejności, którą nazywa logiką temporalną: dowolny warunek wstępny, potem wyzwalacz, potem nazwa systemu i odpowiedź. Jego zestaw reguł to zero lub wiele warunków wstępnych, zero lub jeden wyzwalacz, jedna nazwa systemu i jedna lub wiele odpowiedzi. Artykuł z 2009 roku specjalizuje ten kształt w pięć szablonów. Ten sam przewodnik nazywa też wymagania złożone, które łączą słowa kluczowe. W studium przypadku artykułu surowy wyciąg miał 36 wymagań, a zestaw przepisany 47. Średnia długość spadła z 36,9 do 25,6 słowa. Autorzy podają, że w tym studium złożoność, pominięcie, powtórzenie, nieodpowiednia implementacja i niemożność testowania zniknęły ze zbioru przepisanego, a niejednoznaczność, ogólnikowość i rozwlekłość zmalały, ale nie zniknęły. Wymieniają też ograniczenia: mała próba, tylko wysokopoziomowe wymagania bezpieczeństwa i osąd przy klasyfikacji ogólnikowości. Te liczby są z artykułu, dla tego jednego dokumentu. ## Wzorce zdań EARS Słowa kluczowe są z artykułu z 2009 roku i z przewodnika Mavina. Artykuł dopuszcza też *During* zamiast *While* dla stanu, z tym samym znaczeniem, gdy tak czyta się jaśniej. Zdania przykładowe ilustrują szablony. To nie cytaty z artykułu. Kiro zapisuje wzorzec zdarzeniowy wielkimi literami; notacja pierwotna używa wielkiej litery na początku. Przykłady zostają po angielsku, bo składnia EARS jest angielska. ### Wszechobecne `The shall ` Zawsze aktywne. Nie ma słowa kluczowego EARS, bo nie ma warunku wstępnego ani wyzwalacza. Własna ilustracja artykułu z 2009 roku to układ sterowania, który ma zapobiec nadobrotom silnika. **Przykład:** The checkout system shall keep the order total equal to the sum of its line items. ### Zdarzeniowe `When , the shall ` Odpowiedź jest wymagana, gdy na granicy systemu wykryto wyzwalacz, i tylko wtedy. Słowo kluczowe to *When*. **Przykład:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### Stanowe `While , the shall ` Odpowiedź jest wymagana tak długo, jak system pozostaje w nazwanym stanie. Słowo kluczowe to *While*. **Przykład:** While the cart is empty, the checkout system shall keep the pay button disabled. ### Zachowanie niepożądane `If , then the shall ` Odpowiedź obsługuje awarię, zakłócenie, odchylenie albo inne zachowanie niepożądane. Słowa kluczowe to *If* i *then*. Artykuł dał temu wzorcowi własne słowa kluczowe, żeby te wymagania zostały widoczne. Autorzy zauważają, że pożądane i niepożądane bywa kwestią punktu widzenia. **Przykład:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### Funkcja opcjonalna `Where , the shall ` Odpowiedź obowiązuje tylko wtedy, gdy produkt zawiera nazwaną funkcję. Słowo kluczowe to *Where*. **Przykład:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### Złożone `While , when , the shall ` Więcej niż jedno słowo kluczowe. Przewodnik Mavina trzyma tę samą kolejność klauzul: *While* dla warunku wstępnego, potem *When* dla wyzwalacza, potem odpowiedź systemu. Artykuł z 2009 roku łączy też *While* z *If / then* dla zachowania niepożądanego w stanie. Ilustracja tej kombinacji: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **Przykład:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## Typowe błędy ### Kilka obowiązków w jednym zdaniu Artykuł traktuje zdanie złożone jako problem złożoności i je dzieli. [Specyfikacja wymagania SpecScore](https://specscore.md/requirement-specification) mówi to samo własnymi słowami: każde `REQ` musi wyrażać dokładnie jeden sprawdzalny obowiązek. ### Ukrywanie zachowania niepożądanego w When *When* jest dla oczekiwanego wyzwalacza. *If / then* jest dla zachowania, którego wolałoby się nie spotkać. Jedno słowo kluczowe dla obu sprawia, że przypadek niepożądany wygląda jak normalny. To problem pominięcia, który artykuł nazywa. ### Pisanie implementacji „The checkout system shall store the flag in Redis” nazywa projekt. Artykuł nazywa to nieodpowiednią implementacją. Odpowiedź ma mówić, co system ma osiągnąć, a nie który komponent to robi. ### Brak nazwy systemu „When the form is submitted, shall show an error” nie ma podmiotu. Zestaw reguł Mavina wymaga jednej nazwy systemu. ### Wyzwalacz po odpowiedzi „The checkout system shall show an error when the form is submitted” stawia wyzwalacz na końcu. Opublikowana kolejność to warunek wstępny, potem wyzwalacz, potem odpowiedź. ### Branie jednej linii Kiro za całe EARS Strona specyfikacji funkcji Kiro publikuje jeden wzorzec, `WHEN … THE SYSTEM SHALL …`. Wszechobecne, *While*, *If / then*, *Where* i kombinacje złożone są częścią notacji w artykule i w przewodniku Mavina. Nie ma ich na tej stronie Kiro. ## Jak Kiro używa EARS [Strona specyfikacji funkcji Kiro](https://kiro.dev/docs/specs/feature-specs/), oznaczona jako zaktualizowana 4 sierpnia 2026 i czytana 2 listopada 2026, mówi, że plik `requirements.md` używa EARS. Wydrukowany wzorzec to `WHEN [condition/event]` i potem `THE SYSTEM SHALL [expected behavior]`. Przykład strony: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. [Strona wymagań na początku](https://kiro.dev/docs/specs/feature-specs/requirements-first/) mówi, że wygenerowany `requirements.md` zawiera historyjki użytkownika z kryteriami akceptacji i zachowania systemu w tej samej formie WHEN … THE SYSTEM SHALL …. Przykład rejestracji to trzy zdania: poprawne dane rejestracji tworzą konto, istniejący adres e-mail pokazuje „Email already registered”, a niepoprawny format e-mail pokazuje błąd walidacji. Przed projektem Analyze Requirements szuka niespójności logicznych, niejednoznaczności, sprzecznych ograniczeń i luk. Strona mówi, że wybiera się to z opcji czatu albo menu Continue w edytorze po wygenerowaniu wymagań. `design.md` i `tasks.md` stoją obok wymagań. Quick Spec uruchamia wymagania, projekt i zadania bez przystanku zatwierdzenia między nimi. Ta analiza jest krokiem wewnątrz Kiro. Strona nie opisuje jej jako lintera formatu, który dodaje się do własnego CI. Jak inne narzędzia sprawdzają specyfikację, jest w [przewodniku narzędzi](https://specscore.md/pl/spec-driven-development/tools/). Porównanie obu produktów to [SpecScore vs Kiro](https://specscore.md/pl/vs/kiro/). ## To samo wymaganie w SpecScore SpecScore nie sprawdza, czy zdanie pasuje do szablonu EARS. `specscore spec lint` z repozytorium [specscore-cli](https://github.com/specscore/specscore-cli) sprawdza strukturę. Tekst pomocy wymienia pliki README, sekcje Open Questions, poziomy nagłówków, odwołania do funkcji, linki wewnętrzne i wpisy indeksu. Zdanie EARS może być prozą pod nagłówkiem `REQ`. Linter nie ocenia angielszczyzny. [Specyfikacja wymagania](https://specscore.md/requirement-specification) umieszcza każde wymaganie pod nagłówkiem tematu wewnątrz `## Behavior`, o jeden poziom niżej, zwykle `#### REQ: slug`. Slug używa małych liter, cyfr i myślników. Identyfikator to `{feature-path}#req:{slug}`. Specyfikacja mówi, że wymaganie powinno używać słów kluczowych RFC 2119 (Request for Comments 2119): MUST, MUST NOT, SHOULD, SHOULD NOT i MAY. W odwzorowaniu poniżej EARS-owe *shall* jest zapisane jako MUST. [Kryterium akceptacji](https://specscore.md/acceptance-criteria-specification) jest opcjonalne. Gdy jest użyte, to `### AC: slug` wewnątrz `## Acceptance Criteria`, a następna linia to `**Requirements:**` z tymi identyfikatorami. Specyfikacja kryteriów akceptacji mówi, że AC stwierdza warunek abstrakcyjny i nie może zawierać kroków Given/When/Then, konkretnych danych wejściowych ani szczegółu implementacji. Konkretny przebieg to [scenariusz](https://specscore.md/scenario-specification) w katalogu `_tests/` funkcji. [Specyfikacja funkcji](https://specscore.md/feature-specification) wymaga też statusu, podsumowania, problemu, zachowania, kryteriów akceptacji, pytań otwartych i stopki zgodności. Pliki poniżej to funkcja kasy. `show-field-error` to przykład zdarzeniowy. `reject-invalid-email` to przykład zachowania niepożądanego. 2 listopada 2026 `specscore spec lint` zgłosił 0 naruszeń dla tego drzewa przy specscore 0.55.1, najnowszym wydaniu opublikowanym 30 października 2026, i przy specscore 0.39.1, wersji przypiętej w [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). [Repozytorium formatu](https://github.com/specscore/specscore) jest miejscem tego przepływu. ### 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 — komórka opisu to zdanie podsumowania funkcji. Reguła lintera feature-index-row-sync odrzuciła krótszy opis. ```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 — usunięcie sekcji Open Questions dało oq-section: Open Questions section not found. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org i project.repo są wartościami, z którymi porównywana jest linia studio-toolbar. Bez nich linter zgłosił 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 ``` Dwa dalsze błędy pojawiły się, zanim ten przykład przeszedł, i oba są poprawione w plikach powyżej. Funkcja bez `**Source Ideas:**` nie przeszła `feature-source-ideas-required`; `—` jest wartością pustą. Indeks funkcji potrzebował też pola frontmatter `format: https://specscore.md/features-index-specification`. Zaliczenie lintera znaczy, że pliki spełniają te reguły strukturalne. Nie znaczy, że zdania są dobrym EARS, ani że produkt kasy istnieje. Given/When/Then dla tego zachowania byłby plikiem scenariusza w `spec/features/checkout/_tests/`, a nie kolejnym akapitem wewnątrz AC. ## Pytania ### Co znaczy EARS? Easy Approach to Requirements Syntax. To zestaw wzorców zdań dla wymagań, opublikowany przez Alistaira Mavina, Philipa Wilkinsona, Adriana Harwooda i Marka Novaka z Rolls-Royce na 17th IEEE International Requirements Engineering Conference w 2009 roku i opisany na stronie Mavina. ### Czy notacja Kiro to całe EARS? Strona specyfikacji funkcji Kiro określa jeden wzorzec: WHEN … THE SYSTEM SHALL …. Artykuł z 2009 roku i przewodnik Mavina definiują też wymagania wszechobecne, stanowe While, If/then dla zachowania niepożądanego, Where dla funkcji opcjonalnej i złożone kombinacje tych słów kluczowych. ### Czy SpecScore sprawdza składnię EARS? Nie. `specscore spec lint` sprawdza strukturę plików SpecScore. Zdanie EARS może być prozą `REQ`. Linter nie ocenia angielszczyzny. ### Gdzie trafiają przykłady Given/When/Then? Do scenariusza w katalogu `_tests/` funkcji. Kryterium akceptacji zostaje warunkiem abstrakcyjnym i według specyfikacji kryteriów akceptacji nie może zawierać kroków Given/When/Then. ## Źródła Czytane 2 listopada 2026, poza miejscami, gdzie strona drukuje własną datę aktualizacji. Strona specyfikacji funkcji Kiro podaje aktualizację 4 sierpnia 2026. - [Mavin, Wilkinson, Harwood i 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 — przewodnik EARS](https://alistairmavin.com/ears/) - [Dokumentacja Kiro — specyfikacje funkcji i EARS (strona zaktualizowana 4 sierpnia 2026)](https://kiro.dev/docs/specs/feature-specs/) - [Dokumentacja Kiro — przepływ wymagań na początku](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — specyfikacja wymagania](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — specyfikacja kryteriów akceptacji](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — specyfikacja scenariusza](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — specyfikacja funkcji](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — przepływ CI dogfood](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) ## Powiązane - [Szablon PRD w Markdown do programowania z AI](https://specscore.md/pl/articles/feature-spec-template/) - [Lintowanie specyfikacji w CI linterem specyfikacji](https://specscore.md/pl/articles/lint-specs-in-ci/) - [Jak pisać kryteria akceptacji, które agent AI może zweryfikować](https://specscore.md/pl/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/pl/vs/kiro/) - [Narzędzia rozwoju sterowanego specyfikacją](https://specscore.md/pl/spec-driven-development/tools/) - [Rozwój sterowany specyfikacją](https://specscore.md/pl/spec-driven-development/) - [Specyfikacja wymagania](https://specscore.md/requirement-specification) - [Specyfikacja kryteriów akceptacji](https://specscore.md/acceptance-criteria-specification) - [Specyfikacja funkcji](https://specscore.md/feature-specification) - [Walidatory i CI](https://specscore.md/pl/validators/)