Odpowiedź

W historii analizy systemowej jednym z najtrudniejszych zadań jest identyfikacja i sformalizowanie nieoczywistych, niejasnych lub ukrytych wymagań. Często klient sam nie jest w stanie jasno wyjaśnić, czego dokładnie potrzebuje, lub używa terminów, nie ujawniając rzeczywistych oczekiwań.

Kluczowe cechy:

• Niejawne wymagania są identyfikowane przez analizę, aktywne słuchanie, pytania wyjaśniające, wywiady i obserwację.
• Sformalizowanie odbywa się w języku zrozumiałym zarówno dla klienta, jak i dla deweloperów (na przykład stosując user stories, scenariusze BPMN).
• Należy zapiszać i uzgodnić doprecyzowane sformułowania z klientem, aby uniknąć wieloznaczności.

Historia pytania

Problem nieformalizowanych wymagań jest znany od czasów pierwszych projektów wdrożeniowych. Początkowo stosowano proste wywiady, obecnie używa się również mapowania historii użytkowników, prototypowania oraz facylitacji.

Problem

Niejawne wymagania prowadzą do błędnych postanowień zadań, niepotrzebnych nakładów pracy i konfliktów między stronami.

Rozwiązanie

Stosować techniki wywiadu, wizualizacji (mapy procesów, prototypy), facylitacji i dokładnego dokumentowania wyników. Sprawdzać feedback po każdym etapie sformalizowania wymagań.

Pytania z pułapką.

Czy można sformalizować wszystkie wymagania przed rozpoczęciem projektu?

Nie, wiele wymagań jest doprecyzowywanych i identyfikowanych w trakcie pracy w miarę prototypowania i doprecyzowania projektu.

Czy warto zapisywać tylko jawnie wyrażone życzenia klienta?

Nie, analityk powinien pracować także z niejawnie wyrażonymi oczekiwaniami, analizować cele biznesowe, identyfikować ukryte potrzeby.

Czy zadaniem analityka systemowego jest tylko przetłumaczenie wymagań na specyfikację techniczną?

Nie, analityk również odpowiada za sformalizowanie, uzgodnienie i doprecyzowanie wymagań, identyfikację sprzeczności.

Typowe błędy i antywzorce

• Nie zapisywać międzyczasowych uzgodnień.
• Uważać, że wszystkie wymagania są równie ważne.
• Dokumentować tylko to, co zostało jawnie powiedziane, nie analizując rzeczywistych procesów.

Przykład z życia

Negatywny przypadek:
Analityk zapisał wszystko, co powiedział klient w projekcie, nie doprecyzowując szczegółów. Zalety: szybki rozpoczęcie rozwijania, oszczędność czasu na analizę.
Wady: wiele przeróbek, konflikty z klientem z powodu błędnych oczekiwań.

Pozytywny przypadek:
Analityk robił prototypy, prowadził sesje doprecyzowujące, zapisywał niejawne wymagania razem z klientem.
Zalety: wysoka dokładność wymagań, zadowolony klient, mniej konfliktów.
Wady: koszty facylitacji i zbierania feedbacku.