Dobre wymaganie pozwala co najmniej trzem osobom dojść do podobnego rozumienia: właściciel potrzeby wie, jaki efekt zatwierdza, wykonawca rozumie oczekiwane zachowanie, a tester potrafi sprawdzić rezultat. Sam poprawny gramatycznie zapis nie wystarcza — wymaganie musi mieć uzasadnienie, granice i warunki.
Nie istnieje jeden format odpowiedni do każdego tematu. Prosta user story może wystarczyć do małej zmiany interfejsu, natomiast reguła rozliczeniowa wymaga tabeli decyzyjnej, przykładów danych i źródła prawnego. Jakość zależy od informacji, nie od nazwy szablonu.
Przykład przed i po
Przed: „System powinien szybko wysyłać przypomnienia”
Nie wiadomo, który system, do kogo wysyła wiadomość, jakie zdarzenie ją uruchamia, co znaczy „szybko”, jak traktować dni wolne ani co zrobić, gdy brakuje adresu. Każda osoba musi dopowiedzieć własną wersję.
Po: wymaganie z warunkami
REQ-PAY-014: Jeżeli faktura pozostaje w statusie „oczekuje na akceptację” przez 2 pełne dni robocze, system rozliczeń wysyła przypomnienie do aktualnego akceptującego na służbowy adres e-mail, nie później niż do godziny 09:00 następnego dnia roboczego. System zapisuje datę i wynik wysyłki w historii faktury. Nie wysyła kolejnego przypomnienia, dopóki odbiorca ani status nie ulegną zmianie.
Do zapisu należy dodać regułę kalendarza roboczego, zachowanie przy braku adresu i kryteria akceptacji. Nie oznacza to, że każde wymaganie ma być jednym długim akapitem. Część informacji lepiej przenieść do powiązanej tabeli reguł.
Anatomia wymagania
| Element | Rola | Pytanie kontrolne |
|---|---|---|
| ID i nazwa | Ułatwiają odwołania oraz wersjonowanie | Czy zespół wskazuje ten sam element? |
| Uzasadnienie | Łączy zakres z potrzebą biznesową | Jaki cel lub ryzyko wspiera? |
| Aktor/odbiorca | Wskazuje perspektywę i uprawnienia | Kto inicjuje lub odczuwa zachowanie? |
| Warunek | Określa zdarzenie i stan początkowy | Kiedy wymaganie ma zastosowanie? |
| Oczekiwany rezultat | Opisuje obserwowalne zachowanie | Co ma być inne po wykonaniu? |
| Reguły i wyjątki | Usuwają zgadywanie na krawędziach | Jakie wartości, limity i błędy występują? |
| Kryteria akceptacji | Uzgadniają sposób weryfikacji | Jak rozstrzygniemy spełnienie? |
Sześć cech dobrego wymagania
Potrzebne i powiązane z celem
Każde wymaganie powinno mieć źródło: potrzebę, regułę, ryzyko albo obowiązek. Brak powiązania nie oznacza automatycznie, że funkcja jest zbędna, ale wymaga wyjaśnienia jej wartości.
Jednoznaczne i spójne
Unikaj słów „odpowiedni”, „intuicyjny”, „itp.” oraz „w razie potrzeby”, jeśli nie mają definicji. Nazwy statusów i danych powinny pochodzić ze wspólnego słownika. Sprawdź też, czy nowa reguła nie przeczy istniejącemu wymaganiu.
Atomowe, ale nie pozbawione kontekstu
Wymaganie obejmujące rejestrację, płatność, raport i administrację trudno oszacować oraz odebrać. Podział ma jednak zachować wspólne uzasadnienie i relacje. Dziesięć urwanych zdań bez modelu całości również tworzy chaos.
Wykonalne i testowalne
Zespół musi znać ograniczenia techniczne, prawne i czasowe. Testowalność oznacza, że istnieje obiektywna obserwacja lub pomiar, a nie tylko subiektywne stwierdzenie „działa dobrze”.
Priorytetowe i śledzone
Priorytet ma wskazywać kolejność decyzji lub wartość, a nie przekonanie, że wszystko jest krytyczne. Ślad do celu, decyzji i testu pozwala przeprowadzić analizę wpływu przy zmianie.
Dobierz format do informacji
- User story pomaga prowadzić rozmowę o użytkowniku i wartości.
- Przypadek użycia porządkuje wieloetapową interakcję, warianty i błędy.
- Tabela decyzyjna sprawdza się przy kombinacjach warunków i wyników.
- Model procesu pokazuje zdarzenia, odpowiedzialności i kolejność pracy.
- Przykłady danych wyjaśniają obliczenia, formaty i przypadki brzegowe.
- Kryteria jakościowe opisują wydajność, dostępność i bezpieczeństwo.
Porównanie dwóch popularnych formatów znajdziesz w tekście user story a przypadek użycia.
Wymaganie w cyklu doprecyzowania
Pierwsza wersja nie musi być kompletna. Na etapie odkrywania wystarczy hipoteza wartości i najważniejszy scenariusz. Przed planowaniem zespół dodaje reguły, zależności i przykłady potrzebne do oszacowania. Przed realizacją uzgadnia kryteria oraz ryzyka. Kluczowe jest oznaczenie dojrzałości, aby szkic nie wyglądał jak zatwierdzony zakres.
Po implementacji wymaganie nie powinno być przepisywane tak, by zawsze pasowało do produktu. Jeżeli zachowanie zmieniono, trzeba zapisać decyzję, zaktualizować zakres i zachować historię. Inaczej dokument przestaje wyjaśniać, co miało powstać, a zaczyna tylko opisywać zastany stan.
Przegląd z rzeczywistymi danymi
Przed zatwierdzeniem przejdź przez wymaganie na dwóch lub trzech przykładach danych. Dla przypomnienia o fakturze użyj daty przed weekendem, zmiany akceptującego i braku adresu. Konkretny przypadek ujawnia niejasne definicje szybciej niż kolejne czytanie abstrakcyjnego zdania.
Poproś biznes, wykonawcę i testera, aby niezależnie powiedzieli, jaki wynik przewidują. Różne odpowiedzi są dowodem braku, nie problemem komunikacyjnym uczestników. Zapisz rozstrzygnięcie jako regułę albo kryterium i ponownie przejdź przez przykład.
Checklista gotowości wymagania
- Wymaganie ma identyfikator, właściciela i źródło.
- Opisuje obserwowalny rezultat, a nie wyłącznie zadanie implementacyjne.
- Aktor, zdarzenie i warunki początkowe są jasne.
- Pojęcia oraz statusy mają uzgodnione definicje.
- Reguły, wyjątki i zachowanie przy błędzie są opisane lub powiązane.
- Nie przeczy innym elementom zakresu.
- Zespół ocenił wykonalność i zależności.
- Kryteria akceptacji rozróżniają wynik poprawny od błędnego.
- Priorytet wynika z wartości, ryzyka lub kolejności.
- Otwarte pytania są jawne i mają właścicieli.
Dobre wymaganie można zwykle skrócić bez utraty informacji przez przeniesienie wspólnych definicji do słownika, reguł do tabeli, a wariantów do scenariuszy. Nie skracaj jednak kosztem kontekstu. Czytelnik powinien bez śledztwa wiedzieć, jaki rezultat jest oczekiwany i gdzie znaleźć szczegóły obowiązujące dla danego przypadku. Odnośniki muszą pozostać aktualne.
Po napisaniu opisu wykonaj osobny przegląd jakości wymagania. Jeśli problemem są warunki odbioru, przejdź do poradnika jak opisać kryteria akceptacji.
