Odpowiedź.

Historycznie w projektach IT główną uwagę poświęcano wymaganiom funkcjonalnym: co system powinien robić. Tymczasem kwestie wydajności, niezawodności, skalowalności, dostępności, bezpieczeństwa i utrzymania (to właśnie te cechy obejmuje termin „wymagania niefunkcjonalne”, WNF) przez długi czas pozostawały drugorzędne i często w ogóle nie były formalizowane.

Problem

Ignorowanie lub formalne opisanie WNF prowadzi do poważnych problemów w eksploatacji: system okazuje się nieprzygotowany na oczekiwane obciążenia, nie wytrzymuje cyberataków, jest trudny w utrzymaniu i skalowaniu lub jest niedostępny dla wymaganej liczby użytkowników.

Rozwiązanie

Wsp współczesny analityk systemowy ma obowiązek inicjować, formalizować, analizować i dokumentować WNF. Obejmuje to:

współpracę z architektami, zespołami DevOps i eksploatacyjnymi w celu określenia ograniczeń technologicznych i infrastrukturalnych;
gromadzenie wymagań od biznesu (np. w zakresie SLA);
tworzenie wyczerpującej listy WNF z konkretnymi wartościami progowymi;
wprowadzanie środków do ich kontrolowania na etapie wdrożenia i wsparcia;
utrwalanie wymagań w osobnych sekcjach specyfikacji.

Kluczowe cechy:

WNF są obowiązkowe dla wszelkich dużych projektów.
Określane wspólnie z technicznymi i biznesowymi interesariuszami.
Muszą być jednoznaczne, testowalne i związane z celami biznesowymi.

Pytania z pułapkami.

Jaka jest różnica między "jakością produktu" a "wymaganiami niefunkcjonalnymi"?

Jakość produktu to szersze pojęcie, które obejmuje nie tylko parametry formalizowane, ale również subiektywne oceny (np. wygodę UX/UI). WNF to jasno mierzalne cechy (wydajność, niezawodność itd.), podlegające automatycznej walidacji.

Czy analityk może zlecić określenie wszystkich wymagań niefunkcjonalnych architektowi?

Nie, analityk ma obowiązek wspólnie z architektem i biznesem zidentyfikować te wymagania na etapie analizy, w przeciwnym razie wymagania będą niekompletne lub opisane tylko z technicznego punktu widzenia, bez uwzględnienia potrzeb biznesowych.

Czy można formułować wymagania niefunkcjonalne tylko w postaci ogólnych fraz ("system powinien być niezawodny")?

Nie, takie sformułowania są bezużyteczne w kontrolowaniu i testowaniu. Wymagana jest konkretyzacja: na przykład, "czas przywracania usługi po awarii nie powinien przekraczać 10 minut".

Typowe błędy i antywzorze

Formułowanie wymagań bez testowalnych kryteriów ("szybko", "fajnie", "niezawodnie").
Pomijanie całych klas WNF (np. bezpieczeństwo dla systemów wewnętrznych).
Niezgodność wymagań między zamawiającym a wsparciem.

Przykład z życia

Negatywny przypadek: Projekt krajowego portalu usług publicznych nie sformalizował wymagań dotyczących obciążeń szczytowych. System "upadał" w dniu uruchomienia popularnych usług, pojawiały się incydenty związane z bezpieczeństwem.

Zalety:

Szybkie MVP

Wady:

Ogromne koszty na poprawki
Utrata zaufania użytkowników
Problemy z wsparciem

Pozytywny przypadek: Analityk na początku projektu zakładu automatyzacji przemysłowej zidentyfikował wspólnie z eksploatacją, że przestoje systemu są ważniejsze niż nowe funkcje. Opracował SLA, scenariusze awaryjne, określił konkretne metryki.