Wymagania funkcjonalne: jak pisać, przykład i szablon

Analityk pisze: „System powinien szybko i wygodnie pokazywać klientowi status zamówienia i nie dopuszczać do błędów”. Deweloper czyta „szybko” jako „w sekundę”, tester — jako „bez spinnera”, zleceniodawca — jako „klienci przestają dzwonić do wsparcia”. Cała trójka zgadza się z tym zdaniem, ale rozumie je inaczej. Spór zacznie się na odbiorze, gdy poprawianie będzie już drogie.

Wymaganie funkcjonalne to jedno zdanie o tym, co robi system, zapisane tak, żeby wszyscy rozumieli je jednakowo i mogli sprawdzić jednym testem. Poniżej znajduje się wzór takiego zdania, to samo zdanie o statusie zamówienia przeprowadzony przez cztery poprawki oraz szablon zestawu wymagań, który można skopiować.

Czym wymaganie funkcjonalne różni się od biznesowego, szczegółowo omawia artykuł czym wymagania biznesowe różnią się od funkcjonalnych. Tutaj — o tym, jak sformułować jedno wymaganie.

Wzór jednego wymagania

Kiedy [zdarzenie lub warunek], system powinien [działanie] [obiekt], [rezultat lub ograniczenie].

Przykład: „Kiedy klient otwiera stronę zamówienia, system powinien pokazać aktualny status dostawy i czas jego ostatniej aktualizacji”.

We wzorze są cztery części i każda ma swoją rolę. Warunek mówi, kiedy wymaganie obowiązuje — bez niego nie wiadomo, co sprawdzać. „System powinien” ustala, kto działa: nie użytkownik, nie pracownik, a system. Działanie i obiekt to właśnie zachowanie, które będzie widoczne z zewnątrz. Rezultat odpowiada na pytanie, jak poznać, że wszystko zadziałało.

Podobny szablon — EARS, Easy Approach to Requirements Syntax — wymyślili Alistair Mavin i jego współpracownicy w Rolls-Royce, gdy analizowali wymagania dla systemu sterowania silnikiem odrzutowym. Po raz pierwszy opublikowano go w 2009 roku. Idea jest ta sama: sztywna kolejność części i kilka słów kluczowych zamiast swobodnego tekstu.

Warunek nie występuje w każdym wymaganiu. „System powinien przechowywać historię zmian statusu zamówienia” obowiązuje zawsze i nie trzeba zaczynać go od „kiedy”. Ale jeśli warunek istnieje, a nie ma go w tekście, to pierwsze, o co zapyta tester.

Jedno zdanie — od złego do dobrego

Weźmy zdanie z początku artykułu i przeprowadźmy je przez poprawki. Na każdym kroku usuwamy jeden błąd.

Zdanie wyjściowe: „System powinien szybko i wygodnie pokazywać klientowi status zamówienia i nie dopuszczać do błędów”.

Poprawka 1 — dwa wymagania w jednym zdaniu. Ukryte są tu co najmniej dwa wymagania: pokazywać status i nie dopuszczać do błędów. Nie można ich sprawdzić jednym testem ani osobno odłożyć lub anulować. Rozdzielamy:

• „System powinien szybko i wygodnie pokazywać klientowi status zamówienia”.
• „System powinien nie dopuszczać do błędów przy pokazywaniu statusu”.

Poprawka 2 — ocena zamiast zachowania. „Szybko” i „wygodnie” nie poddają się sprawdzeniu: każdy czytelnik ma swoją miarę. Szybkość to osobne, niefunkcjonalne wymaganie i trzeba je zapisać w liczbach. „Wygodnie” zwykle ukrywa konkretne zachowanie — pytamy zleceniodawcę, jakie. Okazuje się, że klienci chcą wiedzieć, jak świeży jest status.

• „Kiedy klient otwiera stronę zamówienia, system powinien pokazać aktualny status dostawy i czas jego ostatniej aktualizacji”.

Poprawka 3 — negacja. „Nie dopuszczać do błędów” mówi, czego nie powinno być, ale nie mówi, co system robi zamiast tego. Deweloper nie wie, co budować, a tester — co sprawdzać. Pytamy: jaki błąd mamy na myśli? Okazuje się, że usługa dostawy czasami nie odpowiada, a strona pokazuje puste miejsce. Przepisujemy to na zachowanie:

• „Kiedy usługa dostawy nie odpowiada, system powinien pokazać ostatni otrzymany status i oznaczenie, że może być nieaktualny”.

Poprawka 4 — implementacja zamiast zachowania. Podczas dyskusji deweloper proponuje doprecyzować pierwsze zdanie: „System powinien co pięć minut odpytywać usługę dostawy o status i zapisywać go w bazie”. To nie wymaganie, a sposób jego realizacji. Za miesiąc usługa dostawy zacznie sama przysyłać powiadomienia, odpytywanie stanie się niepotrzebne — i wymaganie trzeba będzie przepisać, choć dla klienta nic się nie zmieniło. Zostawiamy to, co widać z zewnątrz, a sposób zostawiamy rozwiązaniu technicznemu.

Wynik: z jednego nieprecyzyjnego zdania powstały dwa sprawdzalne wymagania funkcjonalne oraz jedno niefunkcjonalne, dotyczące szybkości, które zapisuje się osobno:

1. „Kiedy klient otwiera stronę zamówienia, system powinien pokazać aktualny status dostawy i czas jego ostatniej aktualizacji”.
2. „Kiedy usługa dostawy nie odpowiada, system powinien pokazać ostatni otrzymany status i oznaczenie, że może być nieaktualny”.

Te cztery błędy nie zostały wymyślone na potrzeby przykładu. Standard wymagań ISO/IEC/IEEE 29148 wprost wymienia, czego unikać w sformułowaniu: stopnia najwyższego, subiektywnych ocen, niejasnych zaimków, porównań, furtek w rodzaju „w miarę możliwości” i negacji. Listy zasad są wszędzie, ale na jednym zdaniu widać, jak każda z tych zasad zmienia sens.

Szablon zestawu wymagań

Pojedyncze wymaganie żyje krótko, jeśli nie ma z czym go powiązać. Dlatego wymagania prowadzi się tabelą: każde ma numer, na który można się powołać, źródło, z którego wyrosło, i sposób sprawdzenia.

Zaznacz całą tabelę i wklej do Confluence, Excela lub Google Sheets: kolumny się zachowają.

Co robi każda kolumna:

• ID — krótki numer. Powołują się na niego w zadaniach, przypadkach testowych i sporach: „WF-02 nie zostało wykonane” jest jaśniejsze niż powtarzanie całego zdania.
• Sformułowanie — jedno zdanie zbudowane na wzorze powyżej.
• Źródło — wymaganie biznesowe, dla którego potrzebna jest funkcja. Jeśli źródła nie da się znaleźć, to powód, by zapytać, po co wymaganie w ogóle jest na liście. Na tej kolumnie opiera się trasowanie — jak je zbudować, omówiono w artykule macierz trasowania wymagań: przykład i jak ją prowadzić.
• Kryterium sprawdzenia — co zrobi tester i co zobaczy. Jeśli kryterium nie da się napisać, sformułowanie trzeba poprawić jeszcze raz.
• Priorytet — tutaj MoSCoW: Must, Should, Could, Won’t. Pasuje każda skala, którą zespół rozumie jednakowo.

Czego w szablonie celowo nie ma: sekcji dokumentu, strony tytułowej, słownika. To budowa dokumentu, a nie wymagania. Jaki dokument jest potrzebny do zadania, omówiono w artykule BRD, FRD i SRS: jaki dokument kiedy jest potrzebny.

Gdzie kończy się wymaganie funkcjonalne

Jeśli wymaganie jest zapisane jako historyjka lub scenariusz, wzór jest ten sam, zmienia się tylko otoczka: jak wybrać między nimi, omówiono w artykule User Story i Use Case: czym się różnią i co pisać.

To, co zostało po poprawce 2 — „szybko” — nie jest wymaganiem funkcjonalnym. Mówi nie o tym, co robi system, ale jak dobrze. Takie wymagania pisze się osobno i też mierzalnie: czas odpowiedzi w sekundach, dostępność w procentach.

Jak to brzmi na rozmowie kwalifikacyjnej

W naszym banku pytań z prawdziwych rozmów kwalifikacyjnych wymagania funkcjonalne — czym są i czym różnią się od wymagań biznesowych — występują w 15 pytaniach, a 7 z nich oznaczono jako junior. Temat pojawia się już na poziomie początkowym.

Słaba odpowiedź to definicja i lista cech: „wymagania funkcjonalne opisują, co robi system, powinny być pełne, jednoznaczne i sprawdzalne”. Prawda, ale tak odpowie każdy, kto przeczytał podręcznik.

Mocna odpowiedź pokazuje tok rozumowania. Weź jedno złe zdanie — na przykład „system powinien szybko i wygodnie…” — i w minutę przeprowadź je przez poprawki: rozdzielić, usunąć ocenę, zastąpić negację zachowaniem, oddzielić zachowanie od implementacji. Nazwij wzór i powiedz, że każde wymaganie ma źródło i kryterium sprawdzenia. Różnicę słychać od razu: ta osoba nie powtarza podręcznika, tylko pracuje.