Odpowiedź.

Historia pytania:

Początkowo skupiano się na formalizacji wymagań dotyczących funkcjonalności, ale z czasem stało się jasne, że kryteria "niewidoczne" na pierwszy rzut oka (wydajność, bezpieczeństwo, odporność na awarie itp.) są krytycznie istotne dla udanej implementacji i żywotności produktów. Ignorowanie ich prowadziło do awarii i nieprzewidywalnego zachowania oprogramowania po uruchomieniu.

Problem:

Wymagania niefunkcjonalne często są rejestrowane w sposób szablonowy, bez badania kontekstu. Wskazuje się je dla „zapewnienia formalności” lub formułuje zbyt abstraktnie, np.: „System powinien być wygodny” lub „System powinien być szybki”. To nie daje programistom, architektom i testerom jasnych KPI.

Rozwiązanie:

Analityk systemowy przeprowadza sesje z biznesem, IT i specjalistami ds. eksploatacji, aby zidentyfikować rzeczywiste ograniczenia, rejestruje metryki liczbowe (np. SLA, TPS, wskaźniki latencji), opisuje wymagania niefunkcjonalne w sposób wyraźny w specyfikacjach, a następnie zapewnia ich testowalność poprzez powiązanie z przypadkami testowymi i artefaktami architektonicznymi projektu.

Kluczowe cechy:

Użycie ilościowych (mierzalnych!) charakterystyk.
Uwzględnienie etapu formalizacji i uzasadnienia poprzez uzgodnienia z kluczowymi ekspertami IT.
Powiązanie wymagań z metodami ich testowania.

Pytania z pułapką.

Czy można pozostawić grupy wymagań jako "System powinien być dostępny 24/7" bez szczegółowych ustaleń?

Nie, należy koniecznie precyzować parametry dostępności (np. 99,95%) i warunki przywracania.

Czy wystarczy wskazać, że „czas odpowiedzi powinien być szybki”?

Nie, takie sformułowania są nieprzydatne. Należy wskazać, na przykład: Czas odpowiedzi < 3 sekundy przy 95% zapytań przy obciążeniu X.

Czy wymagania niefunkcjonalne są sformalizowane, jeśli są zapisane tylko w ogólnym Tz bez dalszej szczegółowej dokumentacji?

Nie, należy je zdekomponować i powiązać z rozwiązaniami architektonicznymi i planami testowania, w przeciwnym razie pozostaną niewykonalne lub niewalidowalne.

Typowe błędy i antywzorce

Pozostawianie niejasnych sformułowań, które uniemożliwiają testowanie.
Kopiowanie wymaganych wskaźników z innych projektów bez analizy specyfiki.
Ignorowanie konsultacji z IT/SRE i eksploatacją.

Przykład z życia

Negatywny przypadek: Projekt e-bankowości uruchomiono z wymaganiem "dostępność 24/7, szybka praca", bez doprecyzowania SLA.

Plusy:

Szybkie przygotowanie wymagań.

Minusy:

Częste awarie, nierozwiązane spory z outsourcerem.
Klienckie reklamacje.

Pozytywny przypadek: Analityk współpracował z działem eksploatacji, zarejestrował 99,9% uptime, maksymalny czas odpowiedzi 2 sekundy, opisał scenariusze degradacji.