Analityk biznesowy powinien sformalizować kryteria akceptacji (acceptance criteria) dla każdego wymagania w taki sposób, aby były one zrozumiałe i jednoznaczne dla wszystkich uczestników projektu: klienta, programistów i testerów. W tym celu stosuje się techniki specyfikacji, takie jak formułowanie kryteriów w notacji Gherkin (Given-When-Then), listy kontrolne i przykłady użycia (use cases). Analityk dokumentuje kryteria w artefaktach wymagań i dba o to, aby do każdego wymagania był zestaw obiektywnych warunków, na podstawie których można jednoznacznie potwierdzić wykonanie zadania.
Kluczowe cechy:
Czy można używać tylko historii użytkowników do opisu wymagań, bez dodatkowych kryteriów akceptacji?
Nie, historie użytkowników bez wyraźnych kryteriów akceptacji są zbyt abstrakcyjne i mogą być interpretowane różnie. Kryteria są potrzebne, aby zrozumieć, że wymaganie zostało zrealizowane poprawnie.
Czy należy włączać wymagania niefunkcjonalne (np. wydajność) do kryteriów akceptacji?
Tak, także wymagania niefunkcjonalne powinny być sformalizowane w kryteriach, inaczej istnieje ryzyko, że zostaną niezauważone lub zrealizowane nie w pełni.
Kto powinien zatwierdzać kryteria akceptacji: tylko analityk biznesowy?
Nie, zawsze konieczne jest uzgodnienie kryteriów z klientem i, jeśli to możliwe, z zespołem programistycznym, aby zminimalizować nieporozumienia.
Negatywny przypadek: Analityk biznesowy nie uzgodnił kryteriów akceptacji z klientem, a programiści zrozumieli wymagania na swój sposób. Zalety: Szybkie wdrożenie, żadne rozmowy nie opóźniały procesu. Wady: Po wydaniu 70% funkcjonalności nie odpowiadało rzeczywistym oczekiwaniom, pojawił się konflikt.
Pozytywny przypadek: Analityk spisał formalne kryteria akceptacji, uzgodnił je z obiema stronami i dołączył do historii użytkowników. Zalety: Zrozumienie między klientem a zespołem, minimalna liczba błędów po wydaniu. Wady: Na początku poświęcono nieco więcej czasu na uzgodnienia.