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ą (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 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 (CI, continuous integration) to automatyczne sprawdzenie przy każdej proponowanej zmianie. Sprawdzenie jest poleceniem interfejsu wiersza poleceń (CLI, command-line interface): specscore spec lint. Kiro, 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.
Ostatnia aktualizacja: 2 listopada 2026
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. 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 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.
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.
The <system name> shall <system response>
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.
When <trigger>, the <system name> shall <system response>
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.
While <precondition>, the <system name> shall <system response>
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.
If <trigger>, then the <system name> shall <system response>
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.
Where <feature is included>, the <system name> shall <system response>
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.
While <precondition>, when <trigger>, the <system name> shall <system response>
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.
Artykuł traktuje zdanie złożone jako problem złożoności i je dzieli. Specyfikacja wymagania SpecScore mówi to samo własnymi słowami: każde REQ musi wyrażać dokładnie jeden sprawdzalny obowiązek.
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.
„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.
„When the form is submitted, shall show an error” nie ma podmiotu. Zestaw reguł Mavina wymaga jednej nazwy systemu.
„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ź.
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.
Strona specyfikacji funkcji Kiro, 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 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. Porównanie obu produktów to SpecScore vs Kiro.
SpecScore nie sprawdza, czy zdanie pasuje do szablonu EARS. specscore spec lint z repozytorium 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 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 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 w katalogu _tests/ funkcji. Specyfikacja funkcji 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. Repozytorium formatu jest miejscem tego przepływu.
---
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*
---
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*
# Checkout specification
## Open Questions
None at this time.
# 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.
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.
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.
Nie. specscore spec lint sprawdza strukturę plików SpecScore. Zdanie EARS może być prozą REQ. Linter nie ocenia angielszczyzny.
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.
Czytane 2 listopada 2026, poza miejscami, gdzie strona drukuje własną datę aktualizacji. Strona specyfikacji funkcji Kiro podaje aktualizację 4 sierpnia 2026.
Have an idea how to improve this page?