Wymaganie niefunkcjonalne (NFR, non-functional requirement) określa, jak dobrze system ma działać: wydajność, dostępność, bezpieczeństwo, użyteczność, skalowalność, zgodność z prawem, łatwość utrzymania. Nie opisuje funkcji - opisuje cechy jakościowe, które przenikają cały system.
Analityk biznesowy odpowiada za to, by NFR-y w ogóle powstały i miały liczby. To wymagania, o które biznes sam nie poprosi („chcemy, żeby działało" jest dla niego oczywiste), a które decydują o architekturze - i właśnie dlatego trzeba je znać na początku. Dostępność 99,9% zamiast 99% potrafi podwoić koszt infrastruktury; lepiej, żeby to była świadoma decyzja, nie odkrycie po wdrożeniu.
Przykład z MediFlow: „Wyszukiwanie wolnych terminów zwraca wyniki poniżej 2 sekund dla 95% zapytań przy 500 jednoczesnych użytkownikach. Dostępność modułu rezerwacji: minimum 99,5% w skali miesiąca, z wyłączeniem okien serwisowych zapowiedzianych 48 godzin wcześniej. Dane pacjentów szyfrowane w spoczynku i w transmisji". Każde z tych zdań da się zweryfikować testem albo audytem - i każde ma konsekwencje kosztowe, które zarząd zaakceptował świadomie.
Częsta pomyłka: odkładanie NFR-ów na koniec, do testów wydajnościowych tydzień przed startem, gdy na zmiany architektoniczne jest za późno i zostaje „jakoś to będzie". Druga, równie powszechna: NFR-y bez liczb. „System ma być bezpieczny i wydajny" to deklaracja intencji, nie wymaganie - nie da się jej przetestować, więc każdy rozumie ją inaczej, a spór o to, czy została spełniona, rozstrzyga się dopiero na produkcji albo w sądzie.