Czym różnią się wymagania biznesowe od funkcjonalnych

Na przeglądzie wymagań spory nie dotyczą istoty. Dotyczą tego, co gdzie umieścić.

Analityk pisze: „skrócić czas obsługi wniosku z trzech dni do czterech godzin”. Kierownik projektu skreśla i pisze swoje: „system automatycznie pobiera dane klienta z profilu”. Oba wiersze są słuszne. Oba dotyczą tego samego projektu. Tyle że pierwszy — o wyniku dla biznesu, a drugi — o zachowaniu systemu, i stoją na różnych piętrach.

Granica między wymaganiami biznesowymi a funkcjonalnymi przebiega nie po sformułowaniu, lecz po poziomie pytania. Wymaganie biznesowe odpowiada „po co”: jaki wynik uznajemy za sukces. Funkcjonalne odpowiada „co robi rozwiązanie”: jakie zachowanie ten wynik zapewnia. Jedno wymaganie biznesowe zwykle rozwija się w kilka funkcjonalnych, a to powiązanie utrzymuje śledzenie.

To cała odpowiedź. Dalej — dwa testy, które rozdzielają poziomy w minutę, i to, co się psuje, gdy poziomy są zmieszane w jednej liście.

Cztery poziomy, a spór zawsze o dwa

W zestawie wiedzy BABOK wymagania rozłożono na typy, a typów jest cztery: wymagania biznesowe, wymagania interesariuszy, wymagania wobec rozwiązania — funkcjonalne i niefunkcjonalne — oraz przejściowe, potrzebne tylko na czas przejścia, które po nim obumierają. Trzecia edycja wyszła w 2015 roku i wciąż jest aktualna, więc ten schemat nie jest wczorajszą nowinką.

Rozłóżmy to po ludzku. Wymagania biznesowe — cele i wyniki, dla których podejmuje się zmianę. Wymagania interesariuszy — czego potrzebują konkretni ludzie i grupy, by wynik okazał się dla nich użyteczny. Wymagania wobec rozwiązania — co rozwiązanie robi i jak dobrze. Przejściowe — migracja danych, szkolenia, tymczasowe integracje: wszystko, co potrzebne, by dojść do stanu docelowego, i niepotrzebne po nim.

Spór toczy się przy tym zawsze o dwa poziomy: wymagania biznesowe i funkcjonalne. Powód jest prosty. Wymagania funkcjonalne to nie osobne piętro, lecz połowa wymagań wobec rozwiązania; druga połowa, niefunkcjonalne, prawie nigdy nie trafia do sporu. Nikt nie uważa szybkości odpowiedzi za cel biznesowy.

Wymaganie funkcjonalne to nie „bardziej szczegółowe” wymaganie biznesowe. To odpowiedź na inne pytanie, zadane innej osobie.

Więcej o samym zestawie wiedzy i jego budowie — w osobnym omówieniu: czym jest BABOK.

Wymaganie biznesowe: test zmiany rozwiązania

Pierwszy test zajmuje sekundy. Zastąp rozwiązanie w całości i zobacz, co z napisanego przetrwa.

„Skrócić czas obsługi wniosku z trzech dni do czterech godzin” przetrwa zmianę CRM, rezygnację z poczty i przejście do innego wykonawcy. To wymaganie biznesowe. „System wysyła e-mail przy zmianie statusu” umrze w dniu, gdy e-mail zastąpi push. To funkcjonalne.

Drugi test jest jeszcze krótszy. Usuń ze sformułowania wszystko, co mówi o systemie. Zostało coś sensownego dla biznesu — poziom wyższy. Nie zostało nic — poziom niższy. „Wysyłać e-mail” bez systemu nie znaczy nic. „Obsłużyć wniosek w cztery godziny” znaczy wszystko.

Stąd wniosek, który zwykle się pomija. Dopóki wymaganie biznesowe nie jest sformułowane, funkcjonalnego nie ma czym uzasadnić: nie wiadomo, dlaczego wybrano właśnie takie zachowanie i co będzie uznane za sukces. Nie chodzi o to, że „dokument ma zły format” — po prostu nie ma czym odpowiedzieć na pytanie „a po co”.

Funkcjonalne: zachowanie, a nie budowa

Wymaganie funkcjonalne opisuje, co rozwiązanie robi: jaką operację, pod jakim warunkiem, z jakim wynikiem. „System wystawia fakturę przy zamknięciu zamówienia”. „Użytkownik może anulować wniosek przed potwierdzeniem płatności”. Sprawdzalne: wynik albo jest, albo go nie ma.

Tu czyha własna pułapka, w którą wpada się częściej niż w pomylenie z poziomem biznesowym. Sformułowanie niepostrzeżenie przesuwa się z zachowania na budowę. „Moduł walidacji odwołuje się do słownika” — to już architektura, a nie wymaganie. Różnica nie polega na pedanterii: dopóki opisane jest zachowanie, implementację można zmieniać bez przepisywania wymagań. Gdy tylko opisana jest budowa, każda wymiana biblioteki ciągnie za sobą poprawkę dokumentu.

Prosta wskazówka: jeśli ze sformułowania wynika, jak to jest zbudowane w środku, a nie co zobaczy użytkownik lub sąsiedni system — to opis rozwiązania, a nie wymagania wobec niego. Wymagania funkcjonalne zapisuje się na różne sposoby — krótką historyjką z kryteriami akceptacji albo scenariuszem ze wszystkimi gałęziami; czym te formy się różnią, omawia artykuł User Story i Use Case: czym się różnią i co pisać.

Jak sformułować samo wymaganie funkcjonalne, żeby każdy rozumiał je tak samo — wzór, szablon do skopiowania i rozbiór jednego zdania krok po kroku — omawia artykuł wymagania funkcjonalne: jak pisać, przykład i szablon.

Kto zgłasza i co przetrwa uruchomienie

Rozdzielanie poziomów wygodniej prowadzić nie po słowach, lecz po dwóch pytaniach: kto jest źródłem wymagania i co się z nim stanie po uruchomieniu.

Ostatni wiersz najczęściej psuje rejestr. Wymagania przejściowe wyglądają jak zwykłe, leżą na wspólnej liście — i zostają tam na zawsze. Po roku nikt nie pamięta, że „wczytać stany magazynowe ze starego systemu” było potrzebne dokładnie raz.

Sprawdzenie granicy: przejść po powiązaniach

Sformułowania kłamią, powiązania — nie. Dlatego poziom sprawdza się śledzeniem, a nie redakcją.

Standard ISO/IEC/IEEE 29148 wprost wylicza, dokąd wymaganie musi być śledzone: w dół — do wymagań niższego poziomu, do architektury, do elementów systemu, które je realizują, i do obiektów weryfikacji, które je sprawdzają; w górę — do wymagań nadrzędnych, z których zostało wyprowadzone, lub do potrzeb interesariuszy. Właśnie dwustronne powiązanie warto sprawdzać.

W praktyce to dwie minuty pracy. Weź wymaganie funkcjonalne i idź w górę, aż trafisz na wymaganie biznesowe lub potrzebę interesariusza. Doszedłeś — granica jest na miejscu. Urwało się na „tak chciał klient” albo „tak się historycznie ułożyło” — przed tobą rozwiązanie bez celu, i nie ma kto go obronić przy cięciu budżetu.

Przejście w drugą stronę jest równie pożyteczne. Wymaganie biznesowe, które nie ma ani jednego funkcjonalnego potomka, albo nie jest w ogóle realizowane, albo jest realizowane przez coś, co nie zostało pisemnie uzgodnione.

W BABOK powiązania mają swoje nazwy. Jest ich dokładnie cztery: derive, depends, satisfy i validate. Dla naszego zadania ważny jest pierwszy: wymaganie funkcjonalne wyprowadza się z wymagania biznesowego, a nie odwrotnie. Jak prowadzić takie powiązania, by nie zamieniły się w martwą tabelę — osobne omówienie: matryca śledzenia wymagań.

Trzy błędy, które widać w dokumencie

Oba poziomy na jednej liście. Sąsiednie wiersze: „skrócić czas obsługi wniosku o połowę” i „przycisk zapisu blokuje się, dopóki nie wypełniono pola NIP”. Dopóki leżą obok siebie, zmiana celu łamie połowę tekstu i nikt nie rozumie, co właściwie przepisać. Leczenie to nie redakcja, lecz rozdzielenie na sekcje.

Funkcja bez rodzica. Zachowanie opisane, cel nie nazwany. Takiego wymagania nie da się ani priorytetyzować, ani obronić: nie wiadomo, co się stanie, jeśli się je wyrzuci. Sprawdzenie jest jedno — spróbuj pójść w górę. Nie wychodzi — wymaganie wisi w powietrzu.

Cel zmieniono, funkcje zostały. Najdroższy z trzech, bo niezauważalny. Zespół dalej robi to, co już niepotrzebne, i dowiaduje się o tym na demo. Jednostronne śledzenie tego błędu nie łapie: powiązanie w dół jest, a sygnału „rodzic się zmienił” nie ma.

Różne typy wymagań spokojnie żyją w jednym dokumencie — to normalne i tak zwykle bywa. Nienormalne jest, gdy leżą na jednej liście pomieszane. O tym, który dokument jakie pytanie zamyka, jest osobne omówienie: BRD, FRD i SRS.

Jak to brzmi na rozmowie rekrutacyjnej

Pytanie o różnicę zadaje się prawie zawsze i prawie zawsze odpowiada się na nie definicjami. „Wymagania biznesowe to cele biznesu, funkcjonalne to to, co robi system”. Formalnie słuszne. Kończy się niczym: rozmówca kiwa głową i idzie dalej.

Mocna odpowiedź jest krótsza i trzyma się przykładu. Jedna para sformułowań z twojego projektu — cel i funkcja, która go zapewnia. Dalej zdanie o tym, jak sprawdzasz poziom: zastąp rozwiązanie i zobacz, co przetrwa. A jeśli zapytają głębiej, o powiązanie od dołu do góry: funkcja bez rodzica to powód, by zadać pytanie, a nie wiersz w rejestrze.

Różnicę między praktykiem a streszczeniem słychać właśnie tutaj. Streszczenie zna definicje. Praktyk wie, co robić, gdy w cudzym dokumencie poziomy są pomylone.