System rejestracji online dla MediFlow - sieci 12 przychodni - przeszedł testy akceptacyjne w piątek. Każda funkcja działała: pacjent wybierał lekarza, slot, dostawał SMS z potwierdzeniem. W poniedziałek o 7:00, gdy ruszyły zapisy na szczepienia, 3 tysiące osób weszło do systemu jednocześnie. Strona ładowała się 40 sekund albo nie ładowała wcale. Rejestratorki wróciły do telefonów, kolejka pod przychodnią urosła, a zarząd zadzwonił do dostawcy z pytaniem „dlaczego to nie działa". Otóż działało - robiło dokładnie to, co opisano w wymaganiach. Tyle że nikt nie napisał, że ma to robić dla trzech tysięcy osób naraz w czasie poniżej dwóch sekund.
To jest dokładnie ten moment, w którym projekt rozbija się nie o brak funkcji, ale o brak wymagań niefunkcjonalnych. Funkcjonalne mówią co system robi. Niefunkcjonalne mówią jak dobrze ma to robić - i to one decydują, czy użytkownik wróci, czy ucieknie do konkurencji. W tym artykule pokażę Ci, czym są wymagania niefunkcjonalne, jakie mają kategorie, jak je formułować, żeby były mierzalne, a nie życzeniowe, oraz gdzie analitycy najczęściej się potykają.
Czym są wymagania niefunkcjonalne (NFR)
Wymagania niefunkcjonalne (ang. Non-Functional Requirements, NFR) to cechy jakościowe systemu - atrybuty, które określają, w jaki sposób system ma realizować swoje funkcje. Nie opisują nowych funkcjonalności, tylko nakładają ograniczenia i poprzeczki na te, które już zdefiniowano. W literaturze często spotkasz też termin „atrybuty jakości" (quality attributes) - to praktycznie synonim.
Najprostsza intuicja: jeśli zdanie zaczyna się od „system umożliwia", „użytkownik może", „aplikacja pozwala" - to prawdopodobnie wymaganie funkcjonalne. Jeśli zaczyna się od „system działa", „odpowiedź pojawia się w", „dostępność wynosi", „dane są chronione" - to niefunkcjonalne. Funkcja to czasownik. NFR to przysłówek do tego czasownika: szybko, bezpiecznie, niezawodnie, dostępnie.
Test do stosowania od zaraz: dokończ zdanie „system...". Jeśli naturalnie pasuje czasownik - „system WYSYŁA powiadomienie", „system GENERUJE fakturę" - masz wymaganie funkcjonalne. Jeśli pasuje przymiotnik albo miara - „system JEST dostępny 99,9% czasu", „system ODPOWIADA w 2 sekundy" - masz niefunkcjonalne. ROBI czy JEST: tyle wystarczy w 9 przypadkach na 10.
Funkcjonalne: „Pacjent może zarezerwować wizytę online."
Niefunkcjonalne: „Rezerwacja wizyty zostaje potwierdzona w czasie poniżej 2 sekund dla 95% żądań przy 3000 jednoczesnych użytkowników."
Zauważ, że to to samo zachowanie opisane z dwóch stron. Bez wymagania funkcjonalnego nie ma czego mierzyć. Bez niefunkcjonalnego nie wiadomo, kiedy funkcja jest „gotowa na produkcję", a kiedy tylko „działa na laptopie programisty".
Wymagania funkcjonalne i niefunkcjonalne - przykłady z trzech domen
Sama definicja nie nauczy Cię pisać dobrych wymagań - przykłady tak. Zacznijmy od strony funkcjonalnej: każdy przykład w dwóch wersjach, mglistej (tak to zwykle wygląda w pierwszym mailu od biznesu) i poprawionej (testowalnej). Zasada nadrzędna: wymaganie musi być sprawdzalne - jeśli nie da się jednoznacznie orzec „spełnione/niespełnione", to nie jest wymaganie, tylko życzenie.
E-commerce
- ❌ „Klient powinien móc łatwo wyszukiwać produkty." → ✅ „System umożliwia wyszukiwanie produktów po nazwie, kategorii i kodzie EAN; wyniki zawierają nazwę, cenę i dostępność."
- ❌ „Obsługa zwrotów." → ✅ „Zalogowany klient może zgłosić zwrot zamówienia w ciągu 14 dni od dostawy, wskazując produkty i powód z listy; system generuje etykietę zwrotną PDF."
- ❌ „System wysyła powiadomienia o zamówieniu." → ✅ „System wysyła e-mail po: złożeniu zamówienia, nadaniu przesyłki i dostarczeniu - każdorazowo z numerem zamówienia i linkiem do śledzenia."
- ❌ „Rabaty dla stałych klientów." → ✅ „System nalicza rabat 5% dla klientów z min. 3 zamówieniami opłaconymi w ostatnich 12 miesiącach; rabat widoczny w koszyku przed płatnością."
Bankowość
- ❌ „Użytkownik może zarządzać przelewami." → ✅ „Użytkownik może zdefiniować przelew cykliczny: kwota, rachunek odbiorcy, częstotliwość (tygodniowa/miesięczna), data pierwszego i ostatniego wykonania."
- ❌ „System weryfikuje transakcje." → ✅ „Przelew powyżej 10 000 zł wymaga dodatkowego potwierdzenia kodem z aplikacji mobilnej przed przekazaniem do realizacji."
- ❌ „Klient widzi historię." → ✅ „Użytkownik może przeglądać i filtrować historię operacji z ostatnich 13 miesięcy po dacie, kwocie, typie operacji i odbiorcy oraz wyeksportować wynik do CSV."
HR
- ❌ „Pracownik składa wniosek urlopowy elektronicznie." → ✅ „Pracownik składa wniosek urlopowy ze wskazaniem zakresu dat; system weryfikuje dostępny limit i przekazuje wniosek do akceptacji bezpośredniego przełożonego."
- ❌ „System przypomina o szkoleniach." → ✅ „System wysyła przypomnienie o obowiązkowym szkoleniu BHP 30, 14 i 3 dni przed upływem ważności certyfikatu - do pracownika i jego przełożonego."
- ❌ „Raportowanie nieobecności." → ✅ „System generuje miesięczny raport nieobecności per zespół (urlopy, L4, inne) w podziale na dni robocze, dostępny dla ról HR i kierownik."
Niefunkcjonalne odpowiedniki tych wymagań - z liczbami i warunkami brzegowymi - znajdziesz w kategoriach poniżej.
Kategorie wymagań niefunkcjonalnych
Istnieje kilka taksonomii (najbardziej znana to model ISO/IEC 25010), ale w codziennej pracy analityka wystarczy zapamiętać kilka najważniejszych kategorii. Przejdę przez nie z przykładami z systemu MediFlow.
Wydajność (performance)
Jak szybko system reaguje i ile obciążenia uniesie. Tu mieszczą się czasy odpowiedzi, przepustowość (liczba operacji na sekundę), zużycie zasobów i zachowanie pod szczytowym obciążeniem.
- Czas wyświetlenia listy dostępnych slotów lekarza ≤ 1,5 s dla 95. percentyla.
- System obsługuje 3000 jednoczesnych sesji rejestracji bez degradacji czasu odpowiedzi powyżej 2 s.
- Wygenerowanie miesięcznego raportu wizyt dla jednej przychodni ≤ 30 s.
Skalowalność (scalability)
Zdolność systemu do obsłużenia rosnącego obciążenia. To nie to samo co wydajność „tu i teraz" - skalowalność mówi o tym, co się stanie, gdy MediFlow otworzy 5 nowych przychodni albo gdy ruszą zapisy na szczepienia.
- System pozwala na dodanie kolejnych instancji aplikacji (skalowanie horyzontalne) bez przerwy w działaniu.
- Architektura obsługuje 10-krotny wzrost liczby pacjentów w ciągu 12 miesięcy bez przebudowy.
Bezpieczeństwo (security)
W systemie medycznym to kategoria krytyczna - przetwarzasz dane wrażliwe (dane o zdrowiu). Tu wchodzą uwierzytelnianie, autoryzacja, szyfrowanie, audyt dostępu i zgodność z RODO oraz przepisami sektorowymi.
- Dane medyczne pacjentów są szyfrowane w spoczynku (AES-256) i w tranzycie (TLS 1.2+).
- Każdy dostęp rejestratorki do kartoteki pacjenta jest zapisywany w dzienniku audytowym z identyfikatorem użytkownika i znacznikiem czasu.
- System jest odporny na ataki SQL injection i XSS (potwierdzone testem penetracyjnym przed wdrożeniem).
Użyteczność i dostępność (usability, accessibility)
Jak łatwo i komfortowo korzysta się z systemu - oraz czy mogą z niego korzystać osoby z niepełnosprawnościami. Część pacjentów MediFlow to seniorzy, więc to nie kosmetyka, tylko warunek adopcji.
- Pacjent rezerwuje wizytę w maksymalnie 4 krokach (ekranach).
- Interfejs spełnia wytyczne WCAG 2.1 na poziomie AA (kontrast, nawigacja klawiaturą, etykiety dla czytników ekranu).
- Nowa rejestratorka wykonuje samodzielnie rejestrację telefoniczną po ≤ 30 min szkolenia.
Niezawodność i dostępność operacyjna (reliability, availability)
Jak często system pada i jak szybko wraca do życia. Tu żyją wskaźniki SLA, MTBF (średni czas między awariami) i MTTR (średni czas naprawy).
- Dostępność systemu w godzinach pracy przychodni (6:00-20:00) ≥ 99,9% w skali miesiąca.
- Czas przywrócenia działania po awarii (MTTR) ≤ 30 minut.
- Żadne potwierdzone zamówienie wizyty nie ginie w przypadku awarii serwera (trwałość transakcji).
Pozostałe kategorie warte sprawdzenia
- Przenośność (portability) - działanie na różnych przeglądarkach i urządzeniach (Chrome, Safari, telefon, desktop).
- Utrzymywalność (maintainability) - łatwość wprowadzania zmian, jakość kodu, pokrycie testami.
- Zgodność prawna (compliance) - RODO, ustawa o prawach pacjenta, ewentualne wymogi NFZ.
- Lokalizacja (i18n/l10n) - język, format dat, strefa czasowa - istotne, gdy planujesz ekspansję.
Mierzalność: serce dobrego NFR
To jest cała gra. Wymaganie niefunkcjonalne, którego nie da się zmierzyć, jest bezwartościowe - bo nikt nie udowodni, że zostało spełnione ani że zostało złamane. „System ma być szybki" to nie wymaganie, to nadzieja.
Źle → dobrze → jeszcze lepiej
| Źle (życzeniowe) | Dobrze (mierzalne) | Jeszcze lepiej (z kontekstem) |
|---|---|---|
| System ma być szybki. | Strona ładuje się w ≤ 3 s. | Lista slotów ładuje się ≤ 1,5 s dla 95% żądań przy 3000 jednoczesnych użytkowników, mierzone na łączu 4G. |
| System ma być bezpieczny. | Dane są szyfrowane. | Dane medyczne szyfrowane AES-256 w spoczynku i TLS 1.2+ w tranzycie; brak podatności krytycznych w teście penetracyjnym OWASP Top 10. |
| System ma być dostępny. | Dostępność 99,9%. | Dostępność ≥ 99,9% w oknie 6:00-20:00 w skali miesiąca, mierzona z zewnętrznego monitoringu co 60 s. |
| System ma być łatwy w obsłudze. | Rejestracja w ≤ 4 krokach. | 80% nowych pacjentów kończy rezerwację bez kontaktu z infolinią, mierzone w pierwszym miesiącu po wdrożeniu. |
Zauważ wzorzec: dobre NFR ma liczbę, jednostkę i - najlepiej - warunek brzegowy (przy jakim obciążeniu? mierzone czym? dla jakiego percentyla?). Pojedynczy „średni czas odpowiedzi 2 s" potrafi ukryć fakt, że co dwudziesty użytkownik czeka 20 sekund. Dlatego doświadczeni analitycy mówią percentylami (p95, p99), nie średnimi.
Reguła kciuka: jeśli nie potrafisz wymyślić testu, który jednoznacznie powie „spełnione / niespełnione", to nie napisałeś jeszcze wymagania - napisałeś slogan.
Jak dokumentować wymagania niefunkcjonalne
NFR nie żyją w próżni. Najgorsze, co możesz zrobić, to wrzucić je do osobnego rozdziału „Wymagania niefunkcjonalne", który nikt nie czyta po pierwszym tygodniu. Oto co działa w praktyce:
- Powiąż NFR z funkcjami i scenariuszami. Zamiast globalnego „system ma być szybki", przypisuj poprzeczki do konkretnych operacji: rezerwacja, wyszukiwanie slotów, generowanie raportu. Różne operacje mają różne budżety czasowe.
- Stosuj format scenariusza jakości. Sprawdzona struktura: źródło bodźca → bodziec → środowisko → reakcja systemu → miara reakcji. Przykład: „Gdy 3000 pacjentów (źródło) wysyła żądanie rezerwacji (bodziec) w godzinie szczytu (środowisko), system potwierdza rezerwację (reakcja) w ≤ 2 s dla p95 (miara)".
- Trzymaj NFR w jednym rejestrze, ale linkuj do user stories. W Jira/Confluence załóż dedykowaną stronę z tabelą NFR i odwołuj się do niej z kryteriów akceptacji konkretnych historyjek. Wtedy tester widzi poprzeczkę tam, gdzie jej potrzebuje.
- Przypisz właściciela i sposób weryfikacji. Każdy NFR powinien mieć przy sobie: jak go zweryfikujemy (test wydajnościowy? audyt? penetracyjny?) i kto za to odpowiada.
- Wersjonuj. Wymagania niefunkcjonalne zmieniają się wraz ze skalą biznesu. To, co wystarczało przy 4 przychodniach, nie wystarczy przy 12. Trzymaj je pod kontrolą wersji.
Jeśli budujesz pełną specyfikację, NFR są naturalną częścią dokumentu SRS - więcej o jego strukturze znajdziesz w artykule o specyfikacji wymagań SRS. A jeśli pracujesz zwinnie, NFR wchodzą do kryteriów akceptacji historyjek albo do „definicji ukończenia" (Definition of Done) całego zespołu.
Częste błędy przy wymaganiach niefunkcjonalnych
- Całkowite pominięcie NFR. Najczęstszy grzech. Zespół skupia się na funkcjach koszyka i płatności, a wydajność i bezpieczeństwo „jakoś się zrobią". Nie zrobią się - wyjdą na jaw w produkcji, najdroższym możliwym miejscu.
- NFR bez liczb. „Wydajny", „intuicyjny", „niezawodny" bez wartości to materiał na spór, nie na test akceptacyjny. Kto inny rozumie „szybko" jako 200 ms, kto inny jako 5 s.
- Poprzeczki z sufitu. „99,999% dostępności" brzmi imponująco, ale kosztuje fortunę i często nie jest potrzebne. NFR ma wynikać z realnej potrzeby biznesowej, nie z licytacji „kto wpisze więcej dziewiątek".
- Średnie zamiast percentyli. Średni czas odpowiedzi maskuje skrajne przypadki. Klient zapamięta tę jedną rezerwację, która trwała 30 s, nie tysiąc, które trwały 0,5 s.
- NFR niemierzony po wdrożeniu. Spisanie poprzeczki to połowa pracy. Bez monitoringu produkcyjnego nie wiesz, czy SLA jest dotrzymywane. Wymaganie „dostępność 99,9%" bez narzędzia mierzącego dostępność to fikcja.
- Konflikty między NFR. Maksymalne bezpieczeństwo (wielostopniowe uwierzytelnianie przy każdej akcji) bije się z użytecznością (minimalna liczba kliknięć). Te kompromisy trzeba ujawnić i rozstrzygnąć świadomie, a nie zostawić na łeb deweloperowi.
Dwie historie z życia na dowód, że to nie teoria:
- RODO doklejane na końcu. System gotowy, odbiór za tydzień - i pytanie inspektora: „a gdzie realizacja prawa do usunięcia danych?". Dokładanie anonimizacji do gotowej architektury kosztowało więcej niż cały wcześniejszy moduł. Wymagania zgodności zbiera się NA POCZĄTKU, bo one kształtują architekturę.
- Przegrany przetarg przez dostępność. Oferta odrzucona formalnie: wymóg WCAG w SIWZ, którego nikt w zespole nie przeczytał uważnie. NFR-y bywają warunkiem wejścia, nie ozdobnikiem.
Mini-case MediFlow: NFR od ogółu do konkretu
Wróćmy do poniedziałkowej katastrofy. Gdyby analityk MediFlow zadał na etapie elicytacji kilka prostych pytań, problem by się nie wydarzył:
- „Ile osób będzie korzystać z rejestracji jednocześnie w godzinie szczytu?" → odkrycie scenariusza zapisów na szczepienia → NFR wydajnościowy na 3000 sesji.
- „Co się stanie, gdy serwer padnie w trakcie rezerwacji?" → NFR niezawodnościowy: trwałość potwierdzonych transakcji.
- „Kto i jak często widzi dane medyczne pacjenta?" → NFR bezpieczeństwa: audyt dostępu, szyfrowanie.
- „Czy z systemu skorzysta 75-letnia pacjentka?" → NFR użyteczności i dostępności: WCAG AA, maks. 4 kroki.
Każde z tych pytań to most między rozmową z interesariuszem a konkretną, mierzalną poprzeczką. Dobre wymagania niefunkcjonalne rzadko leżą na powierzchni - wydobywa się je technikami elicytacji wymagań, dopytując o obciążenie, szczyt, awarie i grupy użytkowników, o których nikt sam z siebie nie wspomni.
Ściąga: 12 pytań o NFR na warsztat z interesariuszem
Interesariusze sami z siebie nie mówią o NFR-ach - trzeba o nie zapytać. Zapisz tę listę przed najbliższym warsztatem wymagań:
- Ilu użytkowników będzie korzystać z systemu równocześnie w szczycie?
- Jaki czas odpowiedzi uznacie za nieakceptowalny?
- Co się dzieje z Waszą pracą, gdy system nie działa godzinę? Dzień?
- W jakich godzinach system musi działać bezwzględnie?
- Ile danych możecie stracić w najgorszym razie - kwadrans, godzinę, dobę?
- Jakie dane osobowe będą przetwarzane i jak długo wolno je trzymać?
- Kto NIE może widzieć poszczególnych danych?
- Czy są regulacje branżowe, które Was obowiązują (KNF, NFZ, sektor publiczny)?
- Kim jest najmniej techniczny użytkownik systemu?
- Czy z systemu będą korzystać osoby z niepełnosprawnościami (a jeśli sektor publiczny - to nie pytanie, to wymóg)?
- Na jakich urządzeniach i łączach ludzie będą pracować (magazyn z czytnikiem to nie biuro ze światłowodem)?
- Jak zmierzycie, że system „działa dobrze" pół roku po wdrożeniu?
FAQ - wymagania niefunkcjonalne
Czym różnią się wymagania funkcjonalne od niefunkcjonalnych?
Funkcjonalne opisują co system robi (jaką funkcję udostępnia), niefunkcjonalne - jak dobrze ma to robić (jak szybko, bezpiecznie, niezawodnie). Funkcjonalne to czasowniki działania, niefunkcjonalne to atrybuty jakości nałożone na te działania.
Czy wymagania niefunkcjonalne dotyczą tylko dużych systemów?
Nie. Nawet prosta aplikacja ma NFR - czas ładowania, działanie na telefonie, ochrona danych logowania. Różnica jest w skali poprzeczek, nie w tym, czy w ogóle istnieją. W systemach przetwarzających dane wrażliwe (medyczne, finansowe) NFR bezpieczeństwa są wręcz najważniejsze.
Jak ustalić wartości liczbowe dla NFR?
Z trzech źródeł: oczekiwań biznesu (ilu użytkowników, jaki szczyt), benchmarków rynkowych (konkurencja, standardy branżowe jak WCAG) oraz analizy ryzyka (co się stanie, gdy nie dotrzymamy). Wartości powinny wynikać z potrzeby, nie z ambicji „im więcej dziewiątek, tym lepiej".
Gdzie zapisywać wymagania niefunkcjonalne w projekcie zwinnym?
Najczęściej w kryteriach akceptacji konkretnych historyjek (gdy dotyczą jednej funkcji) lub w globalnej „definicji ukończenia" zespołu (gdy dotyczą całego produktu, np. „każdy ekran spełnia WCAG AA"). Plus dedykowany rejestr NFR w Confluence dla przejrzystości.
Kto odpowiada za testowanie NFR?
To praca zespołowa: wydajność weryfikują testy obciążeniowe, bezpieczeństwo - testy penetracyjne i audyty, użyteczność - testy z użytkownikami, dostępność - automatyczne i ręczne audyty WCAG. Analityk dba o to, by każde NFR miało przypisaną metodę weryfikacji już na etapie dokumentacji.
Podsumowanie
Wymagania niefunkcjonalne to nie dodatek do specyfikacji - to warunek, czy system przeżyje kontakt z prawdziwymi użytkownikami w prawdziwym szczycie obciążenia. Funkcje decydują o tym, czy produkt może coś zrobić. NFR decydują o tym, czy zrobi to wtedy, kiedy naprawdę trzeba, dla tylu osób, ile naprawdę przyjdzie, w sposób bezpieczny i znośny do użycia.
Zapamiętaj trzy rzeczy: każde NFR ma liczbę i jednostkę, każde ma sposób weryfikacji, a każde wynika z realnej potrzeby biznesu, a nie z licytacji dziewiątek. Reszta to już rzemiosło, które wyćwiczysz na projektach.
Chcesz przećwiczyć rozróżnianie wymagań funkcjonalnych od niefunkcjonalnych na realnych przykładach? Zajrzyj do przewodnika po specyfikacji SRS albo sprawdź swoją wiedzę w testach na platformie Analify - to najszybszy sposób, żeby wyłapać luki, zanim wyłapie je produkcja.