NFR-y, wymagania niefunkcjonalne, kryteria jakościowe. „Te wymagania, o których nikt nie chce mówić.” Jest wiele określeń na to, o czym chcemy dzisiaj opowiedzieć, ale jest też mnóstwo sposobów na ich ujarzmienie. Dziś spróbujemy usystematyzować nasze podejście do wymagań niefunkcjonalnych.
Co to NFR (wymagania niefunkcjonalne)?
NFR (ang. non-functional requirements) to takie wymagania, które nie opisują funkcji tworzonego systemu, ale jego cechy. Wielka trójka wymagań to: funkcjonalne (opisujące „co”, jakie możliwości są dostępne), niefunkcjonalne (jak system ma się zachowywać, jakie cechy posiadać) i Defnition of Done (kiedy pracę możemy uznać za skończoną).
Jeżeli zwykłe wymagania będziemy mogli „klikać” i ich używać, to wymagania niefunkcjonalne są pewnymi aspektami tworzonego rozwiązania. Może chodzić tu o bezpieczeństwo, wydajność, ergonomię, compliance, kwestie techniczne, architekturę, etc. Takie rzeczy, o których nie możemy zapomnieć, ale które niekoniecznie nasz klient doceni. Chociaż jest duża szansa, że dotknie go ich brak, ale niekoniecznie zauważy ich istnienie.
Słowo „niefunkcjonalne” jest tutaj kluczowe. Jeśli chcemy, aby nasza aplikacja potrafiła obsłużyć 100 zamówień na minutę bez jakichkolwiek opóźnień, to nie ma żadnego testu funkcjonalnego, który potwierdzi spełnienie tego wymagania. Musimy przetestować wydajność, a nie funkcjonalność
Nie da się jednak ukryć, że w dalszym ciągu jest to jakieś wymaganie. Tyle że, no właśnie, niefunkcjonalne.
Gdzie trzymać wymagania niefunkcjonalne?
Zwykle mówimy, że są trzy miejsca, gdzie możemy przechowywać nasze wymagania niefunkcjonalne. Mogą one stanowić osobne wymagania leżące w backlogu, mogą być umieszczone w kryteriach akceptacji innych wymagań bądź trafić do Definition of Done.
Wymagania niefunkcjonalne przechowywane jako PBI (Elementy Backlogu Produktu) sugerują, że nie są one tak „niefunkcjonalne” jak nam się wydaje. Skoro są osobnymi wymaganiami, to być może jesteśmy w stanie poświecić trochę wysiłku i ubrać je w funkcjonalności, zrobić z nich pełnoprawne User Stories? Pamiętajmy też, że nie ma nic gorszego niż refactoring całego systemu tylko dlatego, że np. postanowiliśmy wymagania wydajnościowe bądź bezpieczeństwa zostawić sobie na koniec.
Jeżeli już wydaje nam się, że wymagania niefunkcjonalne dotyczą jakiegoś wąskiego kawałka i możemy się nimi zająć tak jak „normalnymi” wymaganiami, to dorzućmy je po prostu do odpowiednich US-ów jako kryteria akceptacji. Zamiast tworzyć sztuczny twór pod tytułem „Wszystkie operacje finansowe są logowane”, po prostu wpiszmy logowanie jako kryterium akceptacji do wszystkich wymagań na operacje finansowe. Jedyne ryzyko, to znalezienie wszystkich wymagań, do których taki zapis powinien trafić.
A co z Definition of Done? Niektórzy mają pokusę, żeby właśnie tam schować wymagania niefunkcjonalne. Jest to dobre miejsce, jeżeli naszych NFR-ów jest dosłownie kilka bądź chcemy umieścić tam tylko te najważniejsze z punktu widzenia całej aplikacji (np. to, że nie chcemy korzystać z WebView albo że komunikacja z serwerem zawsze musi być szyfrowana). Jeżeli jednak będzie ich zbyt dużo, to po prostu zaśmiecą nam nasze DoD, które stanie się zupełnie nieczytelne.
Są takie metodyki, które wymagania niefunkcjonalne traktują w specjalny sposób i sugerują przechowywanie ich na osobnych listach bądź w wydzielonych częściach backlogu. I tu musimy tylko pamiętać, że te NFR-y, które nie dotyczą żadnych wymagań (nie są kryteriami akceptacji) nigdy nie będą mogły zostać oznaczone jako „skończone”. Weźmy typowe kryterium wydajnościowe pod tytułem „Czas odpowiedzi aplikacji na dowolną akcję nigdy nie przekracza 2 sekund.” Czy kiedykolwiek będziemy mogli uznać, że jest ono „Done” i o nim zapomnieć?
Czy w ogóle będziemy w stanie to jakoś sensownie przetestować?
Testowalne kontra weryfikowalne NFR-y
Przez długi czas stałem na stanowisku, że wymagania niefunkcjonalne mogą być nietestowalne. Możemy przecież sobie zażyczyć, aby nasze rozwiązanie było „ładne”, „ergonomiczne” czy „intuicyjne”. I takie rzeczy jako wskazówka na pewno są istotne. Tylko jeśli nie podamy twardych kryteriów, jak mamy potem udowodnić, że potraktowaliśmy je poważnie?
Druga szkoła mówi, że wszystkie wymagania niefunkcjonalne muszą dotyczyć jakiejś wartości mierzalnej oraz zawierać przedział wartości, który uznajemy za akceptowalny. „Przeładowanie się strony po wykonaniu akcji nie zajmuje dłużej niż 1 sekunda.” „System jest w stanie obsłużyć 30000 użytkowników jednocześnie.” „Wszystkie punkty końcowe systemu są zabezpieczone certyfikatem o określonej sile szyfrowania.” Takie ostre kryteria dają nam jasną odpowiedź na to, czy jesteśmy po zielonej, czy po czerwonej stronie. Ale czy na pewno są testowalne?
Lepszym słowem określającym wymagania niefunkcjonalne byłoby „weryfikowalne”. Jeżeli nie posiadamy środowiska testowego będącego kopią produkcji, to nie będziemy w stanie bezpośrednio sprawdzić niektórych wymagań wydajnościowych. Ale nawet w bardziej ogólnym przypadku – wiele NFR-ów będziemy testować pośrednio, na podstawie modeli, przeliczeń i dostępnych nam środowisk. Część z nich, jak np. zgodność z prawem, będziemy weryfikować po prostu w ramach kryteriów akceptacji wymagań funkcjonalnych.
Ostatnio zmieniłem zdanie i uważam, że wszystkie wymagania powinny być możliwe do zweryfikowania i udowodnienia, że je spełniliśmy. W przeciwnym wypadku trudno je nawet nazwać wymaganiami. Kwestie otwarte, takie jak „intuicyjny” czy „ładny” możemy przechowywać gdzieś na boku jako wskazówki do budowanego rozwiązania. Ale na pewno nie są to „wymagania niefunkcjonalne” w myśl omawianego dzisiaj tematu.
Nie zawsze niefunkcjonalne…
Sporo wymagań jest niefunkcjonalnych tylko z pozoru. Coś, co na bardzo ogólnym poziomie potraktujemy jako NFR może przerodzić się w dziesiątki bądź nawet setki wymagań. Weźmy nasze ulubione „System jest zgodny z obowiązującym prawem” bądź „Aplikacja spełnia wymagania RODO”. Funkcjonalne? Niefunkcjonalne?
Te stwierdzenia są tak bardzo ogólne, że wyglądają na wymagania niefunkcjonalne. Ale w takiej formie nie są weryfikowalne, a przynajmniej nie w skończonym czasie. Nikt nie będzie przecież czytał całego istniejącego w naszym kraju prawa i sprawdzał czy wzięliśmy pod uwagę każdy przepis.
Podejdziemy do tego zupełnie inaczej – najpierw zrobimy listę ustaw i rozporządzeń, które faktycznie nas dotykają, a z nich wyciągniemy… wymagania. Po prawidłowo przeprowadzonej analizie dostaniemy zestaw wymagań funkcjonalnych (co system potrafi robić) oraz niefunkcjonalnych (jakie kryteria i warunki ma spełniać). Te ostatnie zaś częściowo zostaną zapisane jako kryteria akceptacji w innych wymaganiach, a w części staną się osobnymi bytami.
A to, czy NFR-y chcemy przechowywać w „rejestrze NFR”, czy też w Definition of Done zależy już od Was. My, niczym rasowi konsultanci, pokazujemy tylko możliwe opcje.
