Fundamenty i zastosowania notacji EARS

W skrócie

EARS (Easy Approach to Requirements Syntax) to lekka metoda porządkowania wymagań tekstowych za pomocą kilku wzorców zdaniowych. Nie chodzi w niej o formalizację matematyczną, lecz o ograniczenie typowych wad języka naturalnego: niejednoznaczności, nieostrości, nadmiernej złożoności, przemilczeń, powtórzeń, rozwlekłości, przedwczesnego narzucania rozwiązania oraz braku możliwości weryfikacji.

Metodę opracował Alistair Mavin ze współpracownikami w Rolls-Royce podczas analizy przepisów zdatności do lotu dla systemu sterowania silnikiem lotniczym. Pierwsza publikacja naukowa opisująca EARS ukazała się w 2009 roku na konferencji IEEE Requirements Engineering.

Największą zaletą EARS jest stała kolejność członów wymagania: warunki obowiązywania, zdarzenie wyzwalające, podmiot zobowiązany oraz wymagana odpowiedź. Taki zapis ułatwia recenzję, wykrywanie braków, przypisanie odpowiedzialności i zaplanowanie weryfikacji. Nie sprawia jednak, że wymaganie staje się automatycznie wykonywalne. EARS zwiększa weryfikowalność i ułatwia wyprowadzanie przypadków testowych, ale do uzyskania wykonywalnej specyfikacji nadal potrzebne są dane testowe, procedura, środowisko, kryteria rozstrzygnięcia oraz automatyzacja.

1. Czym EARS jest, a czym nie jest

1.1. Definicja robocza

EARS to odmiana kontrolowanego języka naturalnego przeznaczona do zapisu wymagań. Posługuje się pięcioma podstawowymi wzorcami:

1. wymaganie bezwarunkowe,
2. wymaganie zależne od stanu,
3. wymaganie wyzwalane zdarzeniem,
4. wymaganie dla wariantu opcjonalnego,
5. wymaganie dotyczące sytuacji niepożądanej.

Wzorce można łączyć, tworząc wymagania złożone. Łączenie nie znosi jednak potrzeby utrzymania czytelności i atomowości wymagania.

1.2. EARS nie jest językiem formalnym

EARS nie ma formalnej semantyki porównywalnej z logiką temporalną, automatami, sieciami Petriego czy językami specyfikacji formalnej. Stała kolejność członów odzwierciedla porządek czasowy, ale nie zapewnia matematycznej jednoznaczności. Nadal mogą wystąpić:

• nieostre pojęcia dziedzinowe,
• niejawne założenia,
• nieokreślone jednostki miary,
• błędny poziom abstrakcji,
• sprzeczność z innymi wymaganiami,
• niewykonalność techniczna albo ekonomiczna.

1.3. EARS nie jest pełnym zarządzaniem wymaganiami

Metoda sama nie określa:

• sposobu identyfikowania interesariuszy i potrzeb,
• reguł ustalania priorytetów,
• struktury dokumentacji wymagań,
• sposobu zatwierdzania zmian,
• modelu wersjonowania,
• relacji nadrzędność – pochodzenie,
• sposobu zarządzania wariantami,
• procedur walidacji rozwiązania z użytkownikami.

Dlatego pojedyncze zdanie EARS powinno być częścią szerszego rekordu wymagania, zawierającego co najmniej identyfikator, źródło, uzasadnienie, priorytet, właściciela, metodę weryfikacji, stan zatwierdzenia oraz powiązania z projektem i testami.

1.4. EARS nie gwarantuje poprawności merytorycznej

Poprawna składnia nie dowodzi, że wymaganie jest potrzebne, prawdziwe, wykonalne ani kompletne. Ma to szczególne znaczenie w pracy z modelami językowymi. Model potrafi napisać płynne, składniowo poprawne wymaganie na podstawie błędnych przesłanek. Automatyczna kontrola może ocenić zgodność ze wzorcem, ale nie zastąpi walidacji biznesowej, domenowej, prawnej, bezpieczeństwa i architektury.

2. Pochodzenie i podstawa metodyczna

EARS powstał w Rolls-Royce podczas analizy przepisów zdatności do lotu dla systemu sterowania silnikiem lotniczym. Materiał źródłowy zawierał cele wysokiego poziomu, wymagania jawne i domyślne, wytyczne, listy oraz informacje pomocnicze. Wydobywając i upraszczając wymagania, Alistair Mavin zauważył, że czytelne wymagania mają zbliżoną strukturę, a ich odbiór poprawia się, gdy człony występują w stałej kolejności.

W 2009 roku Mavin, Wilkinson, Harwood i Novak opisali metodę w artykule Easy Approach to Requirements Syntax (EARS). Kolejne publikacje dotyczyły zastosowań przemysłowych, pomiaru jakości oraz doświadczeń wdrożeniowych.

Metoda odpowiada na osiem klas problemów języka naturalnego opisanych w pracy źródłowej:

EARS zmniejsza ryzyko tych wad, ale nie usuwa ich automatycznie. Zwłaszcza kompletność i spójność są właściwościami zbioru wymagań, a nie pojedynczego zdania.

3. Składnia i reguły EARS

3.1. Składnia ogólna

Oficjalna składnia ogólna ma postać:

While <optional pre-condition>, when <optional trigger>, the <system name> shall <system response>

Zgodnie z podstawowym zestawem reguł wymaganie zawiera:

Oryginalny zestaw reguł dopuszcza kilka odpowiedzi systemu. W praktyce organizacyjnej warto jednak przyjąć ostrzejszą zasadę atomowości: odpowiedzi łączymy tylko wtedy, gdy tworzą jedno nierozdzielne zobowiązanie, mają wspólny sposób wdrożenia i zawsze są weryfikowane razem. To nie jest odrębna reguła EARS, lecz zalecenie dotyczące jakości, zgodne z zasadą pojedynczości wymagania.

3.2. Znaczenie słów kluczowych

Rozróżnienie When i If … Then ma charakter semantyczny. Obie konstrukcje opisują zdarzenia, ale druga oznacza sytuację niepożądaną. Dzięki temu zbiór wymagań można analizować pod kątem pokrycia obsługi błędów i wyjątków.

3.3. Kolejność członów

W wymaganiu złożonym kolejność jest następująca:

1. stan lub warunki wstępne,
2. zdarzenie wyzwalające,
3. nazwa systemu,
4. wymagana odpowiedź.

Oficjalny przykład wymagania złożonego łączy While oraz When. Włączenie warunku wariantu Where do bardziej rozbudowanej konwencji jest możliwe, ale należy je opisać jako konwencję organizacyjną, a nie jedyny kanoniczny zapis EARS.

4. Polska konwencja zapisu

Dosłowne tłumaczenia While jako „PODCZAS GDY” oraz Where jako „TAM GDZIE” są zrozumiałe, lecz brzmią nienaturalnie i mogą wywoływać skojarzenia przestrzenne. Dlatego w polskich specyfikacjach lepiej sprawdza się konwencja funkcjonalna, a nie literalna.

4.1. Zalecane odpowiedniki

4.2. Dlaczego „musi”, a nie „powinien”

W języku potocznym „powinien” bywa rozumiane jako zalecenie, a nie bezwzględne zobowiązanie. W wymaganiach normatywnych trzeba użyć konstrukcji jednoznacznej. Dopuszczalne są dwie konwencje:

• <system> musi <czasownik w bezokoliczniku>,
• tryb oznajmujący w czasie teraźniejszym – pod warunkiem, że w zasadach dokumentu jawnie zapisano, iż każde takie zdanie jest obowiązującym wymaganiem.

W tym opracowaniu przyjmujemy pierwszą konwencję, bo jest samodokumentująca i nie wymaga dodatkowej reguły redakcyjnej.

4.3. Składnia polska

Wersja podstawowa:

[DOPÓKI <stan>,] [GDY <zdarzenie>,] <system> musi <odpowiedź>.

Wariant niepożądany:

[DOPÓKI <stan>,] JEŻELI <zdarzenie niepożądane>, TO <system> musi <odpowiedź>.

Wariant produktowy:

DLA WARIANTU Z <cechą>, <system> musi <odpowiedź>.

Wariant złożony (jako konwencja organizacyjna):

DLA WARIANTU Z <cechą>, DOPÓKI <stan>, GDY <zdarzenie>, <system> musi <odpowiedź>.

Przy tak rozbudowanej konstrukcji warto sprawdzić, czy zdania nie należy rozbić lub zastąpić tablicą decyzyjną.

5. Pięć podstawowych wzorców

5.1. Wymaganie bezwarunkowe

Znaczenie: zobowiązanie obowiązuje zawsze albo opisuje stałą właściwość systemu.

Szablon angielski

The <system name> shall <system response>.

Szablon polski

<system> musi <odpowiedź>.

Przykłady

• System uwierzytelniania musi rejestrować każdą próbę logowania.
• Repozytorium dokumentów musi szyfrować dane osobowe przechowywane na nośnikach.
• Urządzenie musi mieć masę mniejszą niż 150 g.

Zastosowanie: inwarianty, stałe właściwości, wymagania jakościowe i mierzalne ograniczenia.

Ryzyko: ukryty wyzwalacz. Zdanie „System musi wysyłać potwierdzenie” jest niepełne, jeżeli potwierdzenie ma być wysyłane dopiero po przyjęciu zamówienia.

5.2. Wymaganie zależne od stanu

Znaczenie: zobowiązanie obowiązuje przez cały czas trwania wskazanego stanu.

Szablon angielski

While <precondition>, the <system name> shall <system response>.

Szablon polski

DOPÓKI <stan>, <system> musi <odpowiedź>.

Przykłady

• DOPÓKI trwa synchronizacja, aplikacja musi wyświetlać stan postępu.
• DOPÓKI umowa ma status „zawieszona”, system rozliczeniowy musi odrzucać dyspozycje wypłaty.
• DOPÓKI urządzenie pracuje w trybie awaryjnym, sterownik musi ograniczać prędkość obrotową do 1200 obr./min.

Test rozróżniający stan od zdarzenia: stan trwa i można zapytać „czy nadal obowiązuje?”. Zdarzenie następuje w konkretnym momencie.

Ryzyko: stan nieostry, np. „gdy system jest mocno obciążony”. Trzeba podać mierzalny próg i sposób pomiaru.

5.3. Wymaganie wyzwalane zdarzeniem

Znaczenie: system musi odpowiedzieć po wystąpieniu pojedynczego, oczekiwanego zdarzenia.

Szablon angielski

When <trigger>, the <system name> shall <system response>.

Szablon polski

GDY <zdarzenie>, <system> musi <odpowiedź>.

Przykłady

• GDY klient zatwierdza zamówienie, system magazynowy musi zarezerwować dostępny towar na 30 minut.
• GDY użytkownik wysyła formularz logowania, moduł uwierzytelniania musi zweryfikować poświadczenia.
• GDY system otrzyma komunikat o anulowaniu płatności, moduł zamówień musi zmienić stan zamówienia na „płatność anulowana”.

Ryzyko: alternatywa w wyzwalaczu, np. „gdy użytkownik loguje się lub odzyskuje hasło”. Zwykle są to dwa zdarzenia i dwa odrębne wymagania.

5.4. Wymaganie dotyczące sytuacji niepożądanej

Znaczenie: system musi zareagować na błąd, awarię, naruszenie reguły, próbę nadużycia lub inny stan niepożądany.

Szablon angielski

If <trigger>, then the <system name> shall <system response>.

Szablon polski

JEŻELI <zdarzenie niepożądane>, TO <system> musi <odpowiedź>.

Przykłady

• JEŻELI użytkownik trzykrotnie poda nieprawidłowe hasło w ciągu 10 minut, TO moduł uwierzytelniania musi zablokować logowanie na 15 minut.
• JEŻELI usługa płatnicza nie odpowie w ciągu 5 sekund, TO moduł płatności musi oznaczyć próbę jako nierozstrzygniętą i rozpocząć procedurę uzgodnienia stanu transakcji.
• JEŻELI suma kontrolna pliku jest niezgodna z wartością referencyjną, TO moduł importu musi odrzucić plik i zarejestrować zdarzenie bezpieczeństwa.

Ryzyko: użycie JEŻELI do zwykłego wariantu biznesowego. Status klienta Premium nie jest błędem – to stan albo cecha wariantu.

5.5. Wymaganie dla wariantu opcjonalnego

Znaczenie: zobowiązanie dotyczy wyłącznie produktu, konfiguracji, planu taryfowego albo rynku ze wskazaną cechą.

Szablon angielski

Where <feature is included>, the <system name> shall <system response>.

Szablon polski

DLA WARIANTU Z <cechą>, <system> musi <odpowiedź>.

Przykłady

• DLA WARIANTU Z uwierzytelnianiem wieloskładnikowym, moduł logowania musi wymagać drugiego składnika uwierzytelnienia.
• DLA PLANU PREMIUM, moduł raportowy musi umożliwiać eksport danych do pliku XLSX.
• DLA WDROŻENIA NA RYNKU UE, moduł rejestracji musi wymagać potwierdzenia zapoznania się z informacją o przetwarzaniu danych.

Ryzyko: użycie wzorca do opisu miejsca w interfejsie albo przejściowego stanu użytkownika. Cecha wariantu powinna istnieć w katalogu wariantów, konfiguracji lub przełączników funkcji.

6. Wymagania złożone, atomowość i antywzorce

6.1. Wymaganie złożone

Oficjalny wzorzec złożony łączy stan i zdarzenie:

While <precondition>, when <trigger>, the <system name> shall <system response>.

Przykład z domeny lotniczej:

Przykład z systemu biznesowego:

Wymagania dotyczące sytuacji niepożądanych również mogą zawierać warunek stanowy:

6.2. Atomowość

EARS dopuszcza jedną lub kilka odpowiedzi. Zarządzanie wymaganiami wymaga jednak, by dało się jednoznacznie przypisać status: zaplanowane, wdrożone, zweryfikowane albo odrzucone. Dlatego odpowiedzi warto rozdzielić, gdy:

• mogą zostać wdrożone niezależnie,
• mają różne priorytety,
• są weryfikowane innymi metodami,
• podlegają różnym właścicielom,
• mogą zmieniać się w różnym czasie,
• jedna może być spełniona bez drugiej.

Nie chodzi o mechaniczne rozbijanie każdego zdania ze spójnikiem „i”. Na przykład „system musi zapisać zdarzenie i zwrócić identyfikator zapisu” może być jednym zobowiązaniem, jeżeli identyfikator jest wynikiem tego samego zapisu, a obie części są nierozdzielne.

6.3. Antywzorce

6.4. Budżet złożoności

Nie ma kanonicznej reguły EARS mówiącej, że po trzech warunkach trzeba bezwzględnie zmienić notację. To rozsądna heurystyka redakcyjna, a nie element definicji metody. Jeżeli liczba warunków prowadzi do trudnej do przejrzenia kombinatoryki, sięgnij po:

• tablicę decyzyjną lub DMN,
• diagram stanów,
• diagram sekwencji,
• BPMN dla przebiegu procesu,
• model reguł albo formułę matematyczną.

EARS może wtedy wskazywać zobowiązanie i odsyłać do właściwego modelu, na przykład:

7. Jakość wymagania poza samą składnią

Zgodność z EARS jest jedną z cech dobrze zapisanego wymagania, ale nie warunkiem wystarczającym. Standard ISO/IEC/IEEE 29148:2018 oraz przewodnik INCOSE zwracają uwagę między innymi na konieczność, poprawność, odpowiedni poziom abstrakcji, pojedynczość, wykonalność, jednoznaczność i weryfikowalność.

7.1. Ocena pojedynczego wymagania

Dobre wymaganie powinno być:

• potrzebne – wynikać z celu, potrzeby, regulacji albo wymagania nadrzędnego;
• odpowiednie do poziomu – nie mieszać potrzeby biznesowej z projektem komponentu;
• pojedyncze – opisywać jedno zobowiązanie, które można śledzić niezależnie;
• jednoznaczne – mieć jedno rozumienie dla wszystkich właściwych odbiorców;
• wykonalne – możliwe do realizacji przy akceptowalnym koszcie i ryzyku;
• weryfikowalne – mieć wskazaną metodę i jednoznaczne kryterium rozstrzygnięcia;
• poprawne – wiernie oddawać źródło i intencję;
• zgodne z konwencją – stosować ustaloną terminologię, jednostki i format.

7.2. Ocena zbioru wymagań

Zbiór wymagań powinien być:

• kompletny względem zakresu i scenariuszy,
• spójny wewnętrznie,
• wolny od sprzeczności i nieuzasadnionych powtórzeń,
• wyrażony na jednolitym poziomie abstrakcji,
• identyfikowalny w obie strony: do źródeł i do elementów rozwiązania,
• możliwy do walidacji względem celów użytkowników i organizacji.

EARS pomaga ujednolicić formę, ale sam nie rozstrzyga o tych właściwościach.

7.3. Weryfikacja a walidacja

W kontekście wymagań warto rozróżnić dwa pytania:

• weryfikacja wymagania: czy wymaganie jest zapisane poprawnie i bez wad konstrukcyjnych?
• walidacja wymagania: czy wymaganie opisuje właściwą potrzebę i prowadzi do oczekiwanej wartości?

Automatyczna kontrola składni wspiera przede wszystkim weryfikację. Walidacja wymaga udziału właściwych interesariuszy oraz dowodów domenowych.

8. Od wymagania do metody weryfikacji i testu

8.1. EARS zwiększa testowalność, ale nie generuje pełnego testu

Warunek, zdarzenie i odpowiedź tworzą dobry szkielet scenariusza testowego:

To mapowanie jest użyteczne, ale nie jest izomorfizmem ani transformacją bezstratną. Test wymaga dodatkowych decyzji:

• konkretnych danych wejściowych,
• sposobu przygotowania stanu,
• obserwowalnego punktu pomiarowego,
• wartości granicznych,
• oczekiwanego zachowania przed progiem i po nim,
• obsługi współbieżności i czasu,
• kryterium zaliczenia,
• środowiska i wersji komponentów.

8.2. Przykład poprawnego rozdzielenia wymagań

Zamiast jednego zdania z kilkoma niejawnymi zachowaniami:

warto doprecyzować co najmniej dwa wymagania:

WYM-AUTH-01
JEŻELI użytkownik poda nieprawidłowe hasło trzy razy w ciągu 10 minut,
TO moduł uwierzytelniania musi zablokować logowanie tego konta na 15 minut.

WYM-AUTH-02
GDY upłynie 15 minut od rozpoczęcia blokady czasowej,
moduł uwierzytelniania musi usunąć blokadę czasową tego konta.

Dopiero z tych wymagań można wyprowadzić komplet scenariuszy dla wartości granicznych: drugiej i trzeciej próby, chwili tuż przed upływem 15 minut oraz chwili tuż po nim. Automatycznego odblokowania nie powinien dopowiadać autor testu, jeżeli nie wynika ono z wymagania.

8.3. Metody weryfikacji

Nie każde wymaganie weryfikuje się testem wykonywanym w oprogramowaniu. W karcie wymagania trzeba wskazać jedną lub kilka metod:

• test – pobudzenie systemu i obserwacja odpowiedzi;
• analiza – obliczenia, inspekcja danych lub dowód ilościowy;
• inspekcja – przegląd dokumentu, konfiguracji, kodu lub produktu;
• demonstracja – pokaz działania bez precyzyjnego pomiaru laboratoryjnego;
• przegląd dowodów – np. certyfikat, raport bezpieczeństwa, wynik oceny zgodności.

8.4. Gherkin jako notacja scenariuszy

Gherkin opisuje scenariusze zachowania, a nie pełny model wymagań. EARS i Gherkin uzupełniają się:

• EARS porządkuje zobowiązanie systemu,
• Gherkin konkretyzuje wybrane przykłady i oczekiwania,
• automatyzacja testu łączy kroki scenariusza z kodem wykonawczym.

Jedno wymaganie może prowadzić do wielu scenariuszy, a jeden scenariusz może sprawdzać kilka ściśle powiązanych wymagań. Identyfikowalność zachowaj przez identyfikatory, a nie przez założenie relacji jeden do jednego.

9. EARS w cyklu życia wymagań

9.1. Miejsce w procesie

EARS najlepiej stosować po wstępnym rozpoznaniu potrzeby, a przed szczegółowym projektowaniem. Typowy ciąg prac wygląda następująco:

1. identyfikacja celu i interesariuszy,
2. analiza procesu, danych, reguł i ograniczeń,
3. zapis potrzeb oraz wymagań nadrzędnych,
4. normalizacja wybranych wymagań behawioralnych do EARS,
5. przegląd jakości pojedynczych wymagań i całego zbioru,
6. przypisanie metody weryfikacji,
7. projekt rozwiązania,
8. implementacja i weryfikacja,
9. walidacja rezultatów z interesariuszami,
10. utrzymanie powiązań podczas zmian.

9.2. Historyjka użytkownika a EARS

Historyjka użytkownika opisuje rolę, zamiar i wartość:

Jako klient chcę otrzymać potwierdzenie zamówienia,
aby wiedzieć, że zamówienie zostało przyjęte.

EARS opisuje zobowiązanie systemu:

GDY system zamówień przyjmie zamówienie,
moduł powiadomień musi wysłać potwierdzenie
na zweryfikowany adres poczty elektronicznej klienta.

Oba artefakty pełnią różne funkcje. Historyjka nie zastępuje wymagania systemowego, a EARS sam z siebie nie opisuje wartości dla użytkownika.

9.3. Wymagania a decyzje architektoniczne

Wymaganie odpowiada na pytanie, co system ma zapewnić i w jakich warunkach. Decyzja architektoniczna opisuje, jak zostanie to osiągnięte i dlaczego wybrano dane rozwiązanie.

Jeżeli technologia jest narzucona przez kontrakt, regulację albo środowisko docelowe, zapisz ją jako ograniczenie projektowe z podanym źródłem, na przykład:

OGR-ARCH-07
Usługa musi przechowywać klucze kryptograficzne
w zatwierdzonym sprzętowym module bezpieczeństwa zgodnym z profilem SEC-12.

Bez wyraźnego powodu nie mieszaj takiego ograniczenia z wymaganiem behawioralnym.

9.4. Minimalna identyfikowalność

Każde wymaganie powinno mieć powiązania co najmniej z:

• potrzebą, celem albo źródłem regulacyjnym,
• elementem projektu lub decyzją architektoniczną,
• zadaniem implementacyjnym,
• przypadkiem weryfikacyjnym,
• wynikiem weryfikacji,
• wydaniem, w którym obowiązuje.

10. Ograniczenia i granice stosowalności

10.1. Złożona logika decyzyjna

Kombinacje wielu warunków, progów i wyjątków lepiej przedstawiać w tablicy decyzyjnej lub DMN. Przepisywanie dużej tabeli na wiele zdań EARS może utrudnić kontrolę kompletności i wzajemnego wykluczania się reguł.

10.2. Bogate modele stanów

EARS opisuje odpowiedzi w określonych stanach, ale nie zastąpi diagramu stanów, gdy trzeba pokazać wszystkie stany, przejścia, zdarzenia, strażników i działania.

10.3. Sekwencje i współbieżność

Złożone protokoły, kolejność komunikatów, wyścigi i zachowania współbieżne wymagają diagramów sekwencji, modeli współbieżności albo specyfikacji formalnej. Pojedyncze zdania nie pokazują całości relacji czasowych.

10.4. Wymagania jakościowe

EARS może zapisywać wymagania wydajnościowe, niezawodnościowe i bezpieczeństwa, jeżeli zawierają mierzalne kryteria. Sam wzorzec nie podpowiada jednak, jakie obciążenie, percentyl, okno pomiarowe, środowisko i tolerancję przyjąć.

10.5. Ograniczenia projektowe

Nie każde ograniczenie da się naturalnie wyrazić jako odpowiedź systemu. Wymagania regulacyjne, technologiczne i organizacyjne mogą potrzebować odrębnych typów rekordów.

10.6. Systemy probabilistyczne

W systemach AI pojedyncza odpowiedź nie zawsze jest deterministyczna. EARS trzeba łączyć z protokołem oceny, statystyką, monitorowaniem oraz zarządzaniem ryzykiem. ISO/IEC 42001:2023 i ISO/IEC 23894:2023 stanowią szerszy kontekst zarządczy, którego EARS nie zastępuje.

10.7. Ryzyko pozornej precyzji

Uporządkowany zapis może sprawiać wrażenie większej pewności, niż rzeczywiście osiągnięto. Wymaganie z liczbami też bywa błędne, jeżeli progi nie wynikają z potrzeb, danych lub analizy ryzyka.

11. Zestaw narzędziowy

11.1. Skrócona ściągawka

11.2. Lista kontrolna pojedynczego wymagania

1. Czy wskazano jeden jednoznaczny podmiot zobowiązany?
2. Czy wymaganie opisuje jedno zobowiązanie, które można śledzić niezależnie?
3. Czy wybrano właściwy wzorzec?
4. Czy stan ma czas trwania, a zdarzenie jest punktem wyzwalającym?
5. Czy wariant odnosi się do konfiguracji produktu, a nie do miejsca lub chwilowego stanu?
6. Czy sytuacja oznaczona JEŻELI…TO jest rzeczywiście niepożądana?
7. Czy odpowiedź jest obserwowalna?
8. Czy kryteria liczbowe mają jednostki, progi, warunki i punkt pomiaru?
9. Czy wszystkie terminy mają jednoznaczne definicje?
10. Czy usunięto zaimki i odwołania wymagające domyślania się kontekstu?
11. Czy zdanie nie zawiera ukrytej decyzji projektowej?
12. Czy wymaganie wynika ze wskazanego źródła?
13. Czy ma odpowiedni poziom abstrakcji?
14. Czy jest wykonalne?
15. Czy wskazano metodę weryfikacji i kryterium zaliczenia?
16. Czy przeanalizowano stany brzegowe i sytuacje niepożądane?
17. Czy nie koliduje z innymi wymaganiami?
18. Czy ma powiązanie z projektem, zadaniem i testem?

11.3. Minimalna karta wymagania

ID:                   WYM-<obszar>-<numer>
Typ:                  [potrzeba | wymaganie systemowe | wymaganie oprogramowania |
                       ograniczenie | wymaganie jakościowe | wymaganie AI]
Wzorzec EARS:         [bezwarunkowy | stanowy | zdarzeniowy |
                       sytuacja niepożądana | wariantowy | złożony]
Treść:                <jednoznaczne wymaganie>
Źródło:               <cel, interesariusz, regulacja, wymaganie nadrzędne>
Uzasadnienie:         <dlaczego wymaganie jest potrzebne>
Priorytet:            <skala organizacji>
Właściciel:           <rola odpowiedzialna za treść>
Metoda weryfikacji:   [test | analiza | inspekcja | demonstracja | przegląd dowodów]
Kryterium zaliczenia: <jednoznaczny warunek>
Powiązania:           <projekt, zadania, testy, wydanie>
Status:               [szkic | zrecenzowane | zatwierdzone | wdrożone | zweryfikowane]

11.4. Rozszerzenie karty dla AI

Model i wersja:         <identyfikator modelu lub reguła wyboru>
Dane / źródła wiedzy:   <wersjonowany zbiór lub repozytorium>
Miara:                  <np. macro-F1, odsetek odpowiedzi ugruntowanych>
Próg:                   <wartość i tolerancja>
Segmenty:               <grupy oceniane odrębnie>
Procedura oceny:        <identyfikator metody>
Nadzór człowieka:       [brak | na żądanie | wymagany przed wykonaniem | kontrola po fakcie]
Zapis audytowy:         <jakie dane są utrwalane>
Warunek ponownej oceny: <zmiana modelu, danych, instrukcji lub dostawcy>

11.5. Polecenie do automatycznej kontroli jakości

Jesteś recenzentem wymagań. Nie zakładaj, że poprawna składnia oznacza
poprawność merytoryczną. Dla każdego wymagania:

1. Rozpoznaj wzorzec EARS albo wskaż, że wymaganie nie pasuje do EARS.
2. Sprawdź: podmiot, warunki, zdarzenie, odpowiedź i moc zobowiązania.
3. Wykryj wiele niezależnych zobowiązań, nieostre terminy, niejawne zaimki,
   brak jednostek, klauzule ucieczki i ukryte decyzje projektowe.
4. Oceń osobno:
   a) zgodność ze składnią,
   b) pojedynczość,
   c) weryfikowalność,
   d) kompletność lokalną,
   e) pytania merytoryczne wymagające decyzji człowieka.
5. Nie dopowiadaj brakujących reguł biznesowych. Oznacz je jako [PYTANIE].
6. Zaproponuj poprawiony zapis bez zmiany intencji.
7. Wskaż metodę weryfikacji i dane potrzebne do przygotowania testu.
8. Dla wymagania AI sprawdź dodatkowo: model, dane, miarę, próg, segment,
   niepewność, nadzór człowieka i reakcję na niespełnienie kryterium.

Zwróć wynik w tabeli: ID | ocena | naruszenia | pytania | propozycja | weryfikacja.

Bibliografia i źródła

Źródła EARS

1. Mavin, A.; Wilkinson, P.; Harwood, A.; Novak, M., Easy Approach to Requirements Syntax (EARS), IEEE International Requirements Engineering Conference, 2009, DOI: 10.1109/RE.2009.9.
2. Mavin, A.; Wilkinson, P., Big Ears (The Return of Easy Approach to Requirements Engineering), IEEE International Requirements Engineering Conference, 2010, DOI: 10.1109/RE.2010.39.
3. Gregory, S., Easy EARS: Rapid Application of the Easy Approach to Requirements Syntax, IEEE Requirements Engineering Conference, 2011.
4. Mavin, A.; Wilkinson, P.; Gregory, S.; Uusitalo, E., Listens Learned (8 Lessons Learned Applying EARS), IEEE Requirements Engineering Conference, 2016, DOI: 10.1109/RE.2016.38.
5. Mavin, A. i in., Ten Years of EARS, IEEE Software, 2019.
6. Oficjalny opis składni i wzorców: alistairmavin.com/ears.

Standardy i przewodniki dotyczące wymagań

1. ISO/IEC/IEEE 29148:2018, Systems and software engineering – Life cycle processes – Requirements engineering: iso.org/standard/72089.html.
2. INCOSE, Guide to Writing Requirements, Version 4 – Summary Sheet, 2023.

Spec-Driven Development (stan na 11 lipca 2026)

1. Kiro, Requirements-First Workflow: kiro.dev.
2. Kiro, Feature Specs: kiro.dev.
3. GitHub, Spec Kit: github.com/github/spec-kit.
4. GitHub Spec Kit, wydanie 0.12.11 z rozszerzeniem EARS: github.com/github/spec-kit/releases.
5. Rozszerzenie społecznościowe EARS Requirements Syntax: github.com/dhruv-15-03/spec-kit-ears.
6. Böckeler, B., Understanding Spec-Driven Development: Kiro, spec-kit, and Tessl, 2025: martinfowler.com.
7. Tessl, Announcing skills on Tessl: the package manager for agent skills, 29 stycznia 2026: tessl.io/blog.
8. Tessl, aktualne pozycjonowanie platformy: tessl.io.

Systemy AI

1. ISO/IEC 42001:2023, Information technology – Artificial intelligence – Management system: iso.org/standard/42001.
2. ISO/IEC 23894:2023, Artificial intelligence – Guidance on risk management: iso.org/standard/77304.html.