Odpowiedź.

Analityk biznesowy odpowiada za pełne zbieranie, uzgadnianie i dokumentowanie nie tylko wymagań funkcjonalnych, ale również niefunkcjonalnych: szybkość działania systemu, bezpieczeństwo, skalowalność, dostępność, wygodę interfejsu. W tym celu ściśle współpracuje z interesariuszami (szczególnie z biznesem i IT), korzysta ze scenariuszy i analizuje standardy. Musi nie tylko zebrać jawne oczekiwania, ale także wykryć ukryte wymagania (na przykład regulacje dotyczące ochrony danych). W rezultacie analityk formułuje wymagania niefunkcjonalne w dokumentacji, uzgadnia je z zespołem projektowym i technicznym, a także kontroluje spełnienie tych wymagań przez cały czas trwania projektu.

Kluczowe cechy:

• Identyfikowanie ukrytych i specyficznych wymagań poprzez wywiady i analizę standardów
• Zapełnianie dokumentacji i uzgadnianie wymagań niefunkcjonalnych
• Kontrola zgodności realizacji z uzgodnionymi kryteriami niefunkcjonalnymi

Pytania z pułapką.

Czy wystarczy po prostu opisać wymagania niefunkcjonalne w tekście bez metryk i konkretów?

Nie, abstrakcyjne sformułowania ("szybko", "bezpiecznie") są nieprzydatne do walidacji. Wymagane są jasne parametry: na przykład, czas reakcji nie więcej niż 2 sekundy.

Czy wymagania niefunkcjonalne są tylko zmartwieniem specjalistów technicznych?

Nie, analityk musi zidentyfikować i sformułować takie wymagania wspólnie z biznesem, ponieważ ich niespełnienie prowadzi do niezadowolenia kluczowych interesów biznesowych.

Czy możliwe jest opóźnienie pracy nad wymaganiami niefunkcjonalnymi do końcowych etapów projektu?

Nie, takie wymagania są często krytyczne dla architektury rozwiązania. Ich identyfikacja na późnych etapach prowadzi do przeróbek i wysokich kosztów.

Typowe błędy i antywzorce

• Niejasne, formalne lub zbyt ogólne opisy niefunkcjonalnych cech
• Ignorowanie standardów bezpieczeństwa, SLA, wymogów prawnych
• Późne identyfikowanie wymagań niefunkcjonalnych z ryzykiem znaczących przeróbek

Przykład z życia

Negatywny przypadek: Opisano w TZS oczekiwaną "wygodę" i "szybkość działania", nie zapisano konkretnych metryk. Zalety: Mniej kosztowne w momencie pisania dokumentu Wady: Nie mogliśmy zgłosić zastrzeżeń do zespołu, gdy wynik nie zadowolił klienta.

Pozytywny przypadek: Uzgodniono: "Czas ładowania strony — do 2 sekund przy obciążeniu do 1000 użytkowników, poziom SLA — 99,95%". Sformułowano wymagania dotyczące ochrony danych osobowych. Zalety: Jasna weryfikacja wyniku, zmniejszenie ryzyka przeróbek, przejrzystość dla wszystkich uczestników. Wady: Wymagało czasu i uzgodnień z IT i prawnikami.