Co to jest Wymagania niefunkcjonalne?

Definicja wymagań niefunkcjonalnych

Wymagania niefunkcjonalne (Non-Functional Requirements, NFR) to specyfikacje dotyczące jakości i właściwości systemu informatycznego, które nie odnoszą się bezpośrednio do jego funkcji, ale do tego, jak system powinien działać. Obejmują aspekty takie jak wydajność, użyteczność, niezawodność, bezpieczeństwo i skalowalność. Wymagania niefunkcjonalne określają standardy i ograniczenia, które system musi spełniać, aby zapewnić satysfakcjonujące doświadczenia użytkownika i zgodność z oczekiwaniami biznesowymi.

O ile wymagania funkcjonalne odpowiadają na pytanie „co system ma robić?”, wymagania niefunkcjonalne odpowiadają na pytanie „jak dobrze ma to robić?”. Często nazywane są również atrybutami jakościowymi (quality attributes) lub wymaganiami systemowymi. Mimo że bywają traktowane jako drugorzędne względem wymagań funkcjonalnych, w praktyce to właśnie niespełnione wymagania niefunkcjonalne są jedną z głównych przyczyn porażek projektów IT — system może realizować wszystkie wymagane funkcje, ale jeśli jest zbyt wolny, zawodny lub trudny w użyciu, użytkownicy go odrzucą.

Znaczenie wymagań niefunkcjonalnych w projektach IT

Wymagania niefunkcjonalne odgrywają kluczową rolę w projektach IT, ponieważ wpływają na ogólną jakość i użytkowalność systemu. Spełnienie tych wymagań jest niezbędne do zapewnienia, że system działa efektywnie i niezawodnie w różnych warunkach operacyjnych. Mają one bezpośredni wpływ na architekturę systemu — decyzje dotyczące skalowalności, dostępności czy wydajności podejmowane są na etapie projektowania architektury i trudno je zmienić na późniejszych etapach rozwoju.

Raport Standish Group CHAOS systematycznie wskazuje, że projekty IT kończą się niepowodzeniem nie z powodu brakujących funkcji, lecz z powodu problemów z wydajnością, użytecznością czy niezawodnością. Wymagania niefunkcjonalne pomagają również w identyfikacji potencjalnych ryzyk i ograniczeń technologicznych na wczesnym etapie projektu, co pozwala na odpowiednie planowanie i alokację zasobów.

Kluczowe kategorie wymagań niefunkcjonalnych

Wydajność (Performance)

Określa, jak szybko system powinien reagować na działania użytkownika i przetwarzać dane. Wydajność specyfikuje się przy użyciu mierzalnych metryk:

• Czas odpowiedzi (response time) — np. „strona produktu musi się załadować w mniej niż 2 sekundy przy połączeniu 4G”. Google wykazał, że wzrost czasu ładowania strony z 1 do 3 sekund zwiększa współczynnik odrzuceń o 32%.
• Przepustowość (throughput) — np. „system musi obsłużyć minimum 500 transakcji na sekundę”. Mierzona w TPS (Transactions Per Second) lub RPS (Requests Per Second).
• Opóźnienie (latency) — czas między wysłaniem żądania a otrzymaniem pierwszego bajtu odpowiedzi, krytyczne w systemach real-time i grach online.
• Wykorzystanie zasobów — dopuszczalne zużycie CPU, pamięci RAM, dysku i przepustowości sieci w określonych warunkach obciążenia.

Skalowalność (Scalability)

Określa zdolność systemu do obsługi zwiększonego obciążenia bez degradacji wydajności:

• Skalowalność horyzontalna — możliwość dodawania kolejnych instancji (serwerów, kontenerów) w celu rozłożenia obciążenia. Typowa dla architektur chmurowych i mikrousługowych.
• Skalowalność wertykalna — możliwość zwiększenia zasobów pojedynczego serwera (więcej RAM, szybszy CPU). Prostsza, ale z naturalnym limitem.
• Elastyczność (elasticity) — zdolność do automatycznego skalowania w górę i w dół w odpowiedzi na zmieniające się obciążenie. Mierzona np. jako „system musi obsłużyć wzrost ruchu o 300% w ciągu 5 minut bez interwencji manualnej”.

Dostępność i niezawodność (Availability & Reliability)

• Dostępność — procent czasu, w którym system jest operacyjny. Wyrażana w „dziewiątkach”: 99.9% (three nines) oznacza maksymalnie 8.76 godziny niedostępności rocznie, 99.99% (four nines) — 52.6 minuty rocznie, a 99.999% (five nines) — zaledwie 5.26 minuty rocznie.
• MTBF (Mean Time Between Failures) — średni czas między awariami.
• MTTR (Mean Time To Recovery) — średni czas odzyskiwania sprawności po awarii. SLA (Service Level Agreement) często specyfikuje zarówno MTBF, jak i MTTR.
• RPO (Recovery Point Objective) — maksymalna akceptowalna utrata danych wyrażona w czasie, np. „RPO wynosi 1 godzinę” oznacza, że system musi umożliwiać odzyskanie danych sprzed maksymalnie godziny.
• RTO (Recovery Time Objective) — maksymalny akceptowalny czas przywracania systemu po awarii.

Bezpieczeństwo (Security)

Obejmuje ochronę danych i systemu przed nieautoryzowanym dostępem i atakami:

• Uwierzytelnianie i autoryzacja — np. „system musi wspierać wieloskładnikowe uwierzytelnianie (MFA)” lub „sesja użytkownika musi wygasać po 30 minutach bezczynności”.
• Szyfrowanie — np. „wszystkie dane w tranzycie muszą być szyfrowane TLS 1.3, dane w spoczynku — AES-256”.
• Audytowalność — np. „system musi rejestrować wszystkie operacje na danych wrażliwych z retencją logów minimum 12 miesięcy”.
• Zgodność z regulacjami — np. RODO, PCI DSS, HIPAA, NIS2.

Użyteczność (Usability)

Dotyczy łatwości obsługi i intuicyjności interfejsu użytkownika:

• Learnability — czas potrzebny nowemu użytkownikowi na opanowanie systemu, np. „nowy pracownik musi być w stanie obsłużyć podstawowe scenariusze po 2 godzinach szkolenia”.
• Efektywność — czas i liczba kroków potrzebnych do wykonania typowych zadań.
• Dostępność cyfrowa (Accessibility) — zgodność z WCAG 2.2 na poziomie AA, obsługa czytników ekranowych, kontrasty kolorów, nawigacja klawiaturowa.
• Satysfakcja użytkownika — mierzona np. wskaźnikiem SUS (System Usability Scale), z docelowym wynikiem powyżej 68 punktów.

Utrzymywalność (Maintainability)

Określa łatwość modyfikacji, naprawy i rozwijania systemu:

• Modularność — stopień, w jakim system składa się z niezależnych komponentów, które można modyfikować bez wpływu na pozostałe części.
• Testowalność — możliwość efektywnego testowania systemu, np. „pokrycie kodu testami jednostkowymi na poziomie minimum 80%”.
• Dokumentacja — wymagania dotyczące dokumentacji technicznej, API, runbooków operacyjnych.
• Dług technologiczny — dopuszczalny poziom mierzony np. narzędziami SonarQube (ocena A-E).

Przenośność (Portability)

Zdolność systemu do działania w różnych środowiskach:

• Kompatybilność platformowa — np. „aplikacja musi działać na Windows 10+, macOS 12+ i Ubuntu 22.04+”.
• Kompatybilność przeglądarkowa — np. „wspierane przeglądarki: Chrome, Firefox, Safari, Edge — dwie ostatnie wersje”.
• Konteneryzacja — np. „aplikacja musi być dostarczana jako obraz Docker i wdrażana na Kubernetes”.

Różnice między wymaganiami funkcjonalnymi a niefunkcjonalnymi

Wymagania funkcjonalne i niefunkcjonalne różnią się w swojej naturze, sposobie specyfikacji i wpływie na architekturę:

Aspekt	Wymagania funkcjonalne	Wymagania niefunkcjonalne
Pytanie	Co system robi?	Jak dobrze to robi?
Przykład	„Użytkownik może złożyć zamówienie”	„Złożenie zamówienia trwa max 3 sekundy”
Testowanie	Testy funkcjonalne, akceptacyjne	Testy wydajnościowe, obciążeniowe, bezpieczeństwa
Wpływ na architekturę	Minimalny	Fundamentalny
Zmienność	Mogą być dodawane przyrostowo	Trudne do zmiany po implementacji
Widoczność dla użytkownika	Bezpośrednia	Pośrednia (odczuwane jako jakość)

W praktyce granica między nimi bywa płynna. Na przykład „system musi generować raporty PDF” to wymaganie funkcjonalne, ale „raport PDF musi się wygenerować w mniej niż 10 sekund dla zbioru 100 000 rekordów” to już wymaganie niefunkcjonalne powiązane z tym samym obszarem.

Specyfikowanie wymagań niefunkcjonalnych

Model SMART dla NFR

Każde wymaganie niefunkcjonalne powinno być sformułowane zgodnie z zasadą SMART:

• Specific (Konkretne) — precyzyjnie określone, bez ogólników typu „system musi być szybki”.
• Measurable (Mierzalne) — wyrażone w liczbach, np. „czas odpowiedzi < 200ms dla 95. percentyla”.
• Achievable (Osiągalne) — realistyczne przy danym budżecie i technologii.
• Relevant (Istotne) — powiązane z celami biznesowymi.
• Time-bound (Określone w czasie) — z jasnym kontekstem, np. „przy obciążeniu 10 000 jednoczesnych użytkowników”.

Frameworki klasyfikacji

• ISO 25010 (SQuaRE) — standard definiujący 8 charakterystyk jakościowych: wydajność, kompatybilność, użyteczność, niezawodność, bezpieczeństwo, utrzymywalność, przenośność i adekwatność funkcjonalna.
• FURPS+ — model Hewlett-Packard klasyfikujący wymagania jako: Functionality, Usability, Reliability, Performance, Supportability, plus ograniczenia (design, implementation, interface, physical).
• Drzewo atrybutów jakościowych (Quality Attribute Tree) — metoda z Architecture Tradeoff Analysis Method (ATAM), hierarchicznie rozkładająca atrybuty na konkretne scenariusze.

Narzędzia do weryfikacji wymagań niefunkcjonalnych

Każda kategoria NFR wymaga dedykowanych narzędzi testowych:

• Wydajność i obciążenie — JMeter, Gatling, k6 (Grafana Labs), Locust. Umożliwiają symulację tysięcy jednoczesnych użytkowników i pomiar czasów odpowiedzi.
• Bezpieczeństwo — OWASP ZAP, Burp Suite, SonarQube (SAST), Trivy (skanowanie kontenerów), Snyk (analiza zależności).
• Dostępność cyfrowa — axe DevTools, WAVE, Lighthouse (audyt accessibility).
• Użyteczność — Hotjar, Microsoft Clarity (heatmapy i nagrania sesji), Maze (testy zdalne).
• Monitorowanie w produkcji — Datadog, New Relic, Grafana + Prometheus, Elastic APM — pozwalają weryfikować, czy NFR są spełniane w środowisku produkcyjnym.

Kompromisy między wymaganiami niefunkcjonalnymi

Wymagania niefunkcjonalne często pozostają ze sobą w konflikcie, co wymusza kompromisy architektoniczne:

• Bezpieczeństwo vs. wydajność — szyfrowanie, walidacja i logowanie zwiększają bezpieczeństwo, ale obniżają wydajność.
• Dostępność vs. spójność — twierdzenie CAP (Brewer) mówi, że system rozproszony nie może jednocześnie gwarantować spójności, dostępności i tolerancji partycji sieci.
• Skalowalność vs. prostota — architektura mikrousługowa oferuje lepszą skalowalność, ale wprowadza złożoność operacyjną.
• Użyteczność vs. bezpieczeństwo — silne mechanizmy uwierzytelniania zwiększają bezpieczeństwo, ale mogą utrudniać korzystanie z systemu.

Architecture Decision Records (ADR) to popularna technika dokumentowania takich kompromisów — każdy ADR opisuje kontekst decyzji, rozważane opcje, podjętą decyzję i jej konsekwencje.

Wymagania niefunkcjonalne w kontekście chmury i DevOps

W środowiskach chmurowych wymagania niefunkcjonalne nabierają nowego wymiaru:

• Infrastructure as Code (IaC) — narzędzia takie jak Terraform, Pulumi czy AWS CDK pozwalają definiować wymagania dotyczące infrastruktury (auto-scaling, redundancja, regiony) jako kod, który podlega wersjonowaniu i code review.
• Observability — trzy filary obserwowalności (logi, metryki, trace’y) pozwalają na ciągłą weryfikację NFR w produkcji. SLO (Service Level Objectives) i error budget to nowoczesne podejście do zarządzania niezawodnością, spopularyzowane przez Google w koncepcji Site Reliability Engineering.
• Chaos Engineering — praktyka celowego wprowadzania awarii do systemu (np. za pomocą Chaos Monkey od Netflix) w celu weryfikacji NFR dotyczących odporności i czasu odzyskiwania.

Podsumowanie

Wymagania niefunkcjonalne determinują postrzeganą jakość systemu informatycznego i mają fundamentalny wpływ na jego architekturę. Skuteczne zarządzanie NFR wymaga ich precyzyjnego specyfikowania w formie mierzalnych metryk (czas odpowiedzi, percentyle, procent dostępności), systematycznej weryfikacji za pomocą dedykowanych narzędzi testowych oraz ciągłego monitorowania w środowisku produkcyjnym. Frameworki takie jak ISO 25010 i metody jak ATAM pomagają w systematycznej klasyfikacji i analizie kompromisów między atrybutami jakościowymi. W erze chmury i DevOps wymagania niefunkcjonalne stają się integralną częścią pipeline’u CI/CD, weryfikowane automatycznie przy każdym wdrożeniu.