Wymagania niefunkcjonalne określają, jak dobrze rozwiązanie ma działać i w jakich warunkach. To nie „dodatki techniczne”. Czas reakcji, dostępność, odporność na błąd czy ślad audytowy mogą decydować o tym, czy funkcja jest użyteczna i bezpieczna.
Najczęstszy problem polega na używaniu przymiotników zamiast miar: „szybki”, „skalowalny”, „intuicyjny”, „wysoko dostępny”. Takie słowa wyrażają intencję, ale każdy odbiorca rozumie je inaczej. Wymaganie potrzebuje kontekstu operacyjnego, wartości oraz sposobu sprawdzenia.
Szablon wymagania jakościowego
W warunkach [obciążenie, kanał, stan] dla [zakres funkcji lub systemu] wartość [miernik] ma wynosić [próg lub przedział], mierzona [metoda i punkt pomiaru]. W razie przekroczenia [oczekiwana reakcja, alert lub degradacja].
Przykład: „Przy 200 równoległych użytkownikach 95. percentyl czasu od zatwierdzenia wyszukiwania do wyświetlenia pierwszej strony wyników nie przekracza 2 sekund, mierzonych w przeglądarce na środowisku o parametrach produkcyjnych, dla zbioru 5 milionów rekordów”.
Katalog przykładów: od ogólnika do kryterium
| Cecha | Za ogólnie | Przykład mierzalny |
|---|---|---|
| Wydajność | Raport ma generować się szybko | 95% raportów do 100 tys. wierszy powstaje w 30 s przy 20 równoległych zleceniach |
| Dostępność | System zawsze dostępny | Miesięczna dostępność usługi wynosi 99,9% poza oknem serwisowym śr. 22:00–23:00 |
| Odtwarzanie | Dane nie mogą zginąć | RPO wynosi 15 min, RTO 2 godz.; test odtworzenia wykonywany kwartalnie |
| Bezpieczeństwo | Bezpieczne logowanie | Dostęp administratora wymaga MFA; po 5 błędnych próbach konto blokowane na 15 min i rejestrowany jest alert |
| Audyt | Pełna historia zmian | Dla zmiany limitu zapisujemy autora, czas, wartość przed i po oraz źródło; log tylko do odczytu przez 6 lat |
| Użyteczność | Formularz intuicyjny | Co najmniej 8 z 10 nowych użytkowników kończy scenariusz bez pomocy w 4 min; najwyżej jeden błąd krytyczny |
Jak doprecyzować najważniejsze cechy jakościowe
Wydajność: sama średnia ukrywa problem
Średni czas odpowiedzi może wyglądać dobrze, mimo że część użytkowników czeka kilkanaście sekund. Dlatego często lepszy jest percentyl, np. 95. lub 99. Trzeba też wskazać wolumen danych, liczbę równoległych operacji, punkt pomiaru oraz rodzaj transakcji. Wynik z laptopa dewelopera nie potwierdza zachowania całej usługi produkcyjnej.
Dostępność i odporność: co oznacza niedostępność
Warto zdefiniować granice usługi, godziny krytyczne, dozwolone okna serwisowe i sposób liczenia przerw. Osobnym wymaganiem jest zachowanie przy awarii zależności. Sklep może przyjąć zamówienie i opóźnić potwierdzenie płatności albo całkowicie zablokować sprzedaż — wybór ma konsekwencje biznesowe.
RPO określa dopuszczalną utratę danych w czasie, a RTO dopuszczalny czas przywrócenia usługi. Te liczby powinny wynikać z analizy skutku, nie z kopiowania standardu innego systemu.
Bezpieczeństwo i zgodność: wymagaj zachowania
„Zgodny z RODO” jest oczekiwaniem, lecz nie gotowym wymaganiem. Trzeba ustalić kategorie danych, podstawę przetwarzania, role dostępu, okres retencji, obsługę usunięcia, eksport oraz audyt. Wymagania powinny wskazywać źródło obowiązku i właściciela interpretacji. Analityk nie zastępuje prawnika ani specjalisty bezpieczeństwa.
Przypadek: portal zgłoszeń serwisowych
Portal poprawnie rejestruje zgłoszenia, ale w poniedziałki rano użytkownicy czekają po 12 sekund. Zespół odkrywa, że pierwotne wymaganie „odpowiedź do 2 sekund” nie wskazywało liczby użytkowników ani tego, czy mierzymy API, czy pełny ekran. Testowano pojedyncze żądanie na pustej bazie.
Po analizie biznes potwierdza okres szczytu: 600 użytkowników i 80 rejestracji na minutę. Zespół rozdziela miary dla otwarcia formularza, wyszukania klienta i zapisu zgłoszenia. Określa percentyle, realistyczny zbiór danych i monitorowanie produkcyjne. Dzięki temu kryterium prowadzi do decyzji architektonicznych oraz późniejszego alertu, a nie tylko jednorazowego testu.
Jak ustalać wartości progowe
- Zbadaj obecny poziom i wpływ na użytkownika lub proces.
- Sprawdź obowiązek regulacyjny, umowę SLA i zależności zewnętrzne.
- Porównaj koszt różnych progów — 99,99% może wymagać innej architektury niż 99,9%.
- Ustal minimalny poziom akceptowalny oraz wartość docelową, jeśli rozwój będzie etapowy.
- Potwierdź metodę testu przed implementacją i zapewnij dane testowe.
- Zaprojektuj monitoring, aby wymaganie działało także po odbiorze.
Budżety jakościowe i świadome kompromisy
Cechy jakościowe często konkurują. Silniejsze szyfrowanie i dodatkowe kontrole mogą zwiększyć czas odpowiedzi; większa dostępność podnosi koszt infrastruktury; bardzo długa retencja ułatwia audyt, ale zwiększa ryzyko i koszt przechowywania. Dlatego wartości progowe wymagają właściciela biznesowego oraz konsultacji technicznej.
Praktycznym narzędziem jest budżet: całe doświadczenie użytkownika ma zmieścić się w dwóch sekundach, więc zespół rozdziela czas między przeglądarkę, API i zależności. Podobnie miesięczny budżet niedostępności dla 99,9% wynosi około 43 minut. Zużycie budżetu można monitorować i powiązać z zasadą wstrzymania ryzykownych wdrożeń.
Jeżeli oczekiwany poziom jest dziś niewykonalny, nie usuwaj wymagania po cichu. Zapisz poziom minimalny, docelowy, etap dojścia i ryzyko zaakceptowane przez właściciela. Pozorna zgodność z nierealnym progiem jest gorsza niż jawny plan poprawy.
Checklista przeglądu NFR
- Wymaganie dotyczy określonej funkcji, usługi lub procesu.
- Miernik ma jednostkę, próg i uzasadnienie biznesowe.
- Warunki obejmują obciążenie, dane i istotne zależności.
- Wskazano punkt oraz narzędzie pomiaru.
- Zdefiniowano zachowanie po przekroczeniu progu.
- Zespół ocenił wykonalność, koszt i kompromisy.
- Środowisko i dane testowe pozwalają wykonać wiarygodny test.
- Po wdrożeniu istnieje monitoring i właściciel reakcji.
Organizacja może utrzymywać domyślne standardy jakości dla klas systemów. Wymaganie projektowe powinno wówczas wskazać obowiązujący profil i opisać wyjątki, zamiast kopiować cały katalog. Standard musi mieć wersję, właściciela i metodę potwierdzenia, inaczej odnośnik „zgodnie ze standardem” pozostanie równie niejasny jak przymiotnik.
Aby umieścić jakość w szerszej hierarchii, zobacz porównanie typów wymagań. Gotowy zapis warto następnie ocenić za pomocą przeglądu jakości wymagania.
