Wymaganie biznesowe mówi, jaki wynik ma osiągnąć organizacja lub odbiorca. Wymaganie funkcjonalne opisuje zachowanie potrzebne do osiągnięcia tego wyniku. Wymaganie niefunkcjonalne określa jakość, warunki i ograniczenia tego zachowania. Te typy nie konkurują ze sobą — tworzą powiązane poziomy opisu.
Rozróżnienie jest użyteczne, ponieważ pomaga wykryć luki. Lista samych celów jest zbyt ogólna do realizacji. Lista funkcji bez celu prowadzi do niepotrzebnego zakresu. Funkcje bez parametrów jakości mogą działać formalnie, ale zawodzić przy rzeczywistym obciążeniu lub ryzyku.
Jeden przypadek na trzech poziomach
Sklep internetowy traci klientów, ponieważ zwrot pieniędzy trwa średnio dziewięć dni. Firma chce skrócić obsługę bez zwiększania liczby błędnych wypłat.
| Typ | Przykład | Sposób weryfikacji |
|---|---|---|
| Biznesowe | W ciągu 4 miesięcy skrócić medianę czasu zwrotu z 9 do 3 dni, utrzymując błędne wypłaty poniżej 0,2% | Dane operacyjne po wdrożeniu |
| Interesariusza | Pracownik rozliczeń musi widzieć powód blokady i dokumenty potrzebne do jej usunięcia | Walidacja procesu z użytkownikiem |
| Funkcjonalne | Po pozytywnej kontroli zwrotu system tworzy dyspozycję wypłaty i nadaje sprawie status „przekazana do płatności” | Scenariusz akceptacji |
| Niefunkcjonalne | 95% dyspozycji zostaje przekazanych do bramki płatniczej w ciągu 5 minut od zatwierdzenia, przy 300 sprawach na godzinę | Test wydajności i monitoring |
| Ograniczenie | Dyspozycje muszą przechowywać identyfikator zgody przez 6 lat | Przegląd zgodności i retencji |
Jak rozumieć trzy poziomy wymagań
Wymagania biznesowe: wynik, nie projekt
Wymaganie biznesowe powinno odnosić się do mierzalnego rezultatu, ryzyka, zgodności lub zdolności organizacji. „Wdrożyć moduł zwrotów” jest inicjatywą. „Skrócić medianę czasu zwrotu do trzech dni” jest wynikiem, na podstawie którego można ocenić inicjatywę.
Miara biznesowa nie zastępuje kryteriów odbioru. System może poprawnie zrealizować funkcję, a mimo to nie poprawić całego procesu, na przykład dlatego, że sprawy nadal czekają na dokumenty. Wtedy analizujemy przyczyny i zakres zmiany, zamiast uznawać automatycznie, że funkcja była wadliwa.
Wymagania funkcjonalne: obserwowalne zachowanie
Funkcjonalność opisuje, co rozwiązanie umożliwia aktorowi albo jak reaguje na zdarzenie. Warto wskazać warunek, dane wejściowe, regułę i rezultat. „Obsługa zwrotów” jest nazwą obszaru, nie wymaganiem. „System blokuje wypłatę, gdy kwota zwrotu przekracza wartość opłaconych pozycji” daje podstawę do analizy i testu.
Funkcjonalne nie oznacza wyłącznie interfejsu. Automatyczna walidacja, harmonogram, transformacja danych, uprawnienie, komunikat i reakcja na błąd integracji również opisują zachowanie.
Wymagania niefunkcjonalne: jakość w kontekście
Wymagania jakościowe obejmują między innymi wydajność, dostępność, bezpieczeństwo, użyteczność, audytowalność, kompatybilność i odtwarzanie po awarii. Zdanie „system ma być wydajny i bezpieczny” nie pozwala niczego zaprojektować ani odebrać. Potrzebne są miernik, warunki i metoda sprawdzenia.
Część wymagań dotyczy konkretnej funkcji, a część całego produktu. Czas odpowiedzi wyszukiwarki można powiązać z funkcją. Retencja logów audytowych lub dostępność usługi może obowiązywać przekrojowo. Dlatego warto prowadzić katalog jakości i wskazywać zakres stosowania; praktyczny sposób opisuje artykuł wymagania niefunkcjonalne w praktyce.
Mapa powiązań zamiast trzech osobnych list
BR-01 Skrócenie zwrotu → SR-03 Widoczna przyczyna blokady → FR-12 Automatyczna dyspozycja i FR-14 Obsługa blokady → NFR-07 Czas przekazania do 5 minut oraz NFR-09 pełny ślad audytowy → scenariusze akceptacji i miernik biznesowy.
Taki ślad pomaga przy zmianie. Jeżeli z zakresu usuwamy FR-14, widzimy, jaki cel i użytkownik zostaną dotknięte. Jeśli cel biznesowy zmienia wartość docelową, można sprawdzić, czy wymagania jakościowe nadal ją wspierają.
Najczęstsze pomyłki klasyfikacyjne
- „System ma spełniać RODO” — to ogólne ograniczenie, które trzeba przełożyć na konkretne obowiązki.
- „Użytkownik chce szybki eksport” — łączy potrzebę interesariusza z niezmierzoną jakością.
- „API REST” — to decyzja lub ograniczenie rozwiązania, nie potrzeba biznesowa.
- „Możliwość raportowania” — nazwa funkcji bez aktora, danych i celu.
- „Wzrost przychodów o 10%” — może być celem strategicznym, ale trzeba wskazać udział projektowanej zmiany i sposób pomiaru.
Kto zatwierdza poszczególne poziomy
Właściciel wyniku biznesowego potwierdza cel, miarę i akceptowalny kompromis. Ekspert procesu waliduje potrzeby użytkowników oraz reguły domenowe. Zespół realizacyjny ocenia wykonalność funkcji i proponuje rozwiązanie. Właściciel usługi, bezpieczeństwo albo architekt mogą zatwierdzać przekrojowe wymagania jakościowe zgodnie z odpowiedzialnością organizacji.
Jedna osoba może pełnić kilka ról, lecz decyzje nadal warto rozdzielać logicznie. Product owner może zatwierdzić priorytet, ale nie powinien sam interpretować obowiązku prawnego. Architekt może wskazać koszt dostępności 99,99%, lecz właściciel biznesowy decyduje, czy warto ponieść go dla danego procesu.
Przy każdym poziomie zapisz źródło i sposób zmiany. Cel może wynikać z OKR, reguła z polityki, a standard bezpieczeństwa z katalogu organizacyjnego. Dzięki temu zespół nie prosi przypadkowej osoby o akceptację oraz potrafi zidentyfikować elementy dotknięte zmianą źródła.
Checklista kompletnego zestawu
- Cele biznesowe mają właściciela, wartość bazową i docelową.
- Potrzeby interesariuszy wynikają z realnego procesu i przypadków.
- Funkcje opisują aktora, zdarzenie, regułę oraz rezultat.
- Jakość jest wyrażona miernikiem i warunkami pomiaru.
- Ograniczenia są odróżnione od preferencji rozwiązania.
- Każdy ważny element ma ślad do celu oraz sposobu weryfikacji.
- Sprzeczności i luki między poziomami zostały przejrzane.
- Zmiana wymagania uruchamia analizę wpływu.
Klasyfikacja jest narzędziem diagnostycznym, nie celem. Jeżeli zespół spędza więcej czasu na sporze o etykietę niż na doprecyzowaniu znaczenia, zapis może pozostać w kategorii roboczej. Ważniejsze są właściciel, źródło, powiązanie z celem, sposób weryfikacji oraz wpływ zmiany na pozostałe poziomy opisu.
Jeśli masz już właściwy typ, dopracuj zapis zgodnie z poradnikiem jak napisać dobre wymaganie i dodaj mierzalne kryteria akceptacji.
