Wymagania niefunkcjonalne  – NFR

Planując modernizację procesu, całego działu a nawet całej firmy w pierwszej kolejności rozważamy jakie funkcje musiałby mieć system, żeby ułatwić życie pracownikom i klientom. Szereg technik i notacji wspiera budowanie map procesów, przepływów, projektów interfejsów i wszystkiego, co jest potrzebne, by transformacja okazała się sukcesem pod kątem biznesowym. Znacznie mniej mówi się o aspekcie technicznym i prawnym rozwiązania, bo jest często niezrozumiały dla klienta, nie buduje w jego oczach wartości produktu a co gorsza może generować spore koszty. Prawda jest jednak taka, że prawdziwe koszty generuje właśnie pomijanie tego aspektu.

Czym są wymagania niefunkcjonalne?

Są tacy, jak znany w świecie IT Dave Farley, których sama ta nazwa doprowadza do szału. Zresztą nie tylko jego. Bo jak to tak, brzmi jakby nie miały wpływu na funkcjonalność, to po co w ogóle zawracać sobie nimi głowę?

Dave sugeruje „wymagania przekrojowe”, inni „wymagania jakościowe”, ale jednak powszechnym terminem pozostaje „non-functional requirements”. Termin jednak niechętnie pojawia się w języku polskim.

Sama definicja na Wikipedii (angielska, polskiej nawet nie ma) jest tak niejasna, że nie wiadomo co z niej wynika:

„W inżynierii systemów oraz inżynierii wymagań wymaganie niefunkcjonalne (NFR, ang. non-functional requirement) to wymaganie określające kryteria, które mogą być używane do oceny działania systemu, a nie konkretnych zachowań.”

A czym się różni działanie od zachowania tak właściwie? Tego autor nie sprecyzował, ale ja się postaram.

Wymagania funkcjonalne i niefunkcjonalne – przykłady

Weźmy sobie przykład klienta, który chce zamówić aplikację kalkulatora w formie webowej. Bardzo łatwo zweryfikować czy poprawnie dodaje małe liczby, nieco trudniej walidować szereg operacji na miliardach, ale jest to w zasięgu użytkownika z drugim, sprawdzonym egzemplarzem. Warto sprawdzić, czy kalkulator ma wbudowaną pamięć, umie operować na ułamkach oraz czy ma bardziej zaawansowane funkcje których potrzebujemy, jak np. całki. Schody zaczynają się z przypadkami brzegowymi – jak sobie poradzi z dzieleniem przez 0? Jeśli wybuchnie, możemy stracić całą historię obliczeń! Jaki jest limit wyniku?

To wszystko ta bardziej intuicyjna dla użytkownika sfera funkcjonalna, co produkt może zrealizować i czy realizuje to poprawnie. Ale za tym aspektem kryje się cała masa pułapek czyhających na zamawiającego:

1. Co jeśli z naszego internetowego kalkulatora ma korzystać 1000 osób jednocześnie – na pewno wytrzyma taki ruch? Na pewno niechcący nie poda wyniku moich obliczeń koledze?
2. A co jeśli mamy w zespole osobę słabo widzącą, czy da się łatwo powiększyć czcionkę?
3. Czy kalkulator działa równie dobre w Polsce co w Japonii?
4. Czy kalkulator działa całą dobę? Może trzeba mu czyścić pamięć raz w tygodniu przez godzinę i nie można go wtedy używać?
5. Do kogo mogę się zgłosić, jeśli nie rozumiem jego zaawansowanych funkcji? Czy pomoc jest w cenie?
6. Czy do kalkulatora mają dostęp osoby postronne? Czy w razie wycieku moje obliczenia są szyfrowane?
7. Czy dane użytkowników, którzy korzystają z kalkulatora podlegają retencji zgodnie z RODO?
8. Brakuje mi jednej funkcji matematycznej. Czy kalkulator da się w ogóle rozszerzyć o dodatkowe?
9. Czy mogę importować dane z Excela do kalkulatora? (akurat tutaj granica już jest nieco rozmyta…)
10. Czy kalkulator działa na telefonach Apple’a?

To wcale nie są nieważne aspekty, prawda? A to tylko czubek góry lodowej!

Wymagania niefunkcjonalne systemu  – kategorie

Nie ma jednej słusznej klasyfikacji, choć kilka instytucji proponuje swoje spojrzenie i jest ono raczej zbliżone i ściśle związane z pojęciem jakości sytemu i architektury. Pozwolę sobie zaproponować swoje, stanowiące syntezę m.in. ISO 9126 i CISQ:

Kategoria	Opis	Podkategorie
Dostępność (Availability)	Zapewnienie pożądanego czasu działania systemu uwzględniając zdarzenia zaplanowane i niezaplanowane	• Odtwarzanie po awarii (Disaster recovery) • Czas działania (Uptime)
Niezawodność (Reliability)	Zdolność do poprawnego i spójnego funkcjonowania	• Możliwość odzyskiwania (Recoverability) • Odporność na błędy (Fault tolerance) • Odporność na użytkowników (Robustness) • Trwałość (Durability) • Integralność danych (Data integrity) • Kopie zapasowe (Backup)
Wydajność (Performance)	Zapewnienie, że system przetwarza dane w oczekiwanym wolumenie, w tym w okresach szczytowych	• Skalowalność (Scalability) • Rozszerzalność (Extensibility) • Przepustowość (Throughput) • Pojemność (Capacity)
Bezpieczeństwo (Security)	Zapewnienie ochrony systemu przed złośliwymi podmiotami, zarówno wewnętrznymi, jak i zewnętrznymi	• Bezpieczeństwo ogólne (Safety)
Użyteczność (Usability)	Łatwość korzystania z systemu przez użytkowników końcowych	• Dostępność dla osób z niepełnosprawnościami (Accessibility)
Zgodność regulacyjna (Regulatory)	Zapewnienie, że system spełnia zobowiązania prawne, globalne i lokalne	• Zgodność (Compliance) • Certyfikacja (Certification)
Zarządzalność (Manageability)	Zarządzalność to łatwość, z jaką administratorzy mogą zarządzać ekosystemem aplikacji dzięki użytecznej narzędziom i monitoringowi. Jest to zdolność systemu lub grupy systemów do dostarczania kluczowych informacji zespołom operacyjnym i wsparcia w celu debugowania, analizy i zrozumienia przyczyn awarii.	• Obserwowalność (Observability) • Obsługa błędów (Error handling)
Utrzymywalność (Maintainability)	Utrzymywalność to łatwość utrzymania systemu. Wdrożenie systemu to tylko początek, bez wsparcia szybko zaczną się problemy z poprawnym funkcjonowaniem i legislacją.	• Serwisowalność (Serviceability) • Testowanie (Testing)
Interoperacyjność (Interoperability)	Interoperacyjność to zdolność do wymiany informacji i komunikacji z wewnętrznymi i zewnętrznymi aplikacjami oraz systemami.	– Integracje z innymi systemami – Import i eksport danych

Wymagania niefunkcjonalne aplikacji  – przykłady

Każdy klient będzie miał inne potrzeby w zakresie wymagań niefunkcjonalnych, zależne od branży, etapu rozwoju, lokalnego rynku, środków na inwestycje, apetytu na ryzyko i wielu innych czynników. Poniżej podam po jednym przykładzie z każdej kategorii, które są dosyć uniwersalne, żeby lepiej przybliżyć naturę takich wymagań.

Kategoria	Przykład
Dostępność	System MUSI być dostępny przez 99,9% czasu we wszystkich wskazanych regionach
Niezawodność	Automatyczna kopia zapasowa MUSI być tworzona przynajmniej raz dziennie i przechowywana przez minimum 30 dni
Wydajność	Wszystkie strony powinny się ładować poniżej sekundy przy łączu światłowodowym (min 250Mbps)
Bezpieczeństwo	Algorytmy szyfrujące MUSZĄ używać klucza o minimalnej długości 256 bitów dla algorytmów symetrycznych
Zgodność regulacyjna	Zbieranie, przechowywanie, dostęp i retencja danych personalnych MUSZĄ być zgodne z dyrektywą RODO
Zarządzalność	Wszystkie zmiany danych dokonywane poza interfejsem MUSZĄ odbywać się w oparciu o procedurę korekty danych, która jest udokumentowana wraz z uzasadnieniem, zlecającym, datą i wykonawcą
Utrzymywalność	Żadne wdrożenie nowej wersji systemu nie może powodować niedostępności przez więcej niż 30 minut
Interoperacyjność	Interfejsy systemu dostępne zewnętrznie MUSZĄ być udokumentowane zgodnie ze standardem OpenAPI w wersji 3+

Jak widać, nie są to niestety aspekty przejrzyste dla osób nietechnicznych, a zarazem są konieczne, by system funkcjonował w sposób stabilny i zgodny z prawem.

Podsumowanie

W kolejnych artykułach będę rozwijał każdą z tych kategorii w szczegółach, co pomoże lepiej zrozumieć zawiłości tej dziedziny. Na szczęście, jako osoba zamawiająca nowe usługi, lub mająca wątpliwości do jakości obecnych możesz skorzystać z pomocy ekspertów Legal Consulting.