Odpowiedź.

Proces zbierania i analizy wymagań to systematyczne identyfikowanie, organizowanie i dokumentowanie potrzeb biznesowych klienta w celu ich dalszej realizacji w systemach IT lub procesach biznesowych. Główne etapy:

1. Identyfikacja źródeł wymagań: wywiady z klientami, grupy robocze, analiza dokumentacji i bieżących procesów.

2. Zbieranie wymagań: korzystanie z sesji technicznych (warsztatów), ankiety, obserwacje, prototypowanie. Ważne jest zapewnienie zaangażowania wszystkich interesariuszy.

3. Analiza i kategoryzacja: identyfikacja sprzeczności, powielających się zadań, klasyfikacja wymagań na biznesowe/funkcjonalne/niefunkcjonalne.

4. Dokumentacja: formalizacja w postaci SRS (Specification Requirement Specification), user stories lub scenariuszy.

5. Walidacja i zatwierdzenie: przeprowadzenie przeglądów z klientem, wprowadzenie poprawek, zatwierdzenie końcowej wersji wymagań.

Kluczowe cechy:

• Głębokie zrozumienie procesów biznesowych jest niezbędne do prawidłowej interpretacji oczekiwań klienta.

• Ciągła komunikacja: zbieranie wymagań to proces iteracyjny, związany ze zmianami w trakcie projektu.

• Artefakty wymagań (diagramy, modele, specyfikacje) są krytycznie ważne dla dalszej pracy zespołu.

Pytania z haczykiem.

Czy można ograniczyć się tylko do jednego (na przykład biznesowego lub funkcjonalnego) typu wymagań?

Nie, analityk biznesowy musi uwzględnić wszystkie typy wymagań: biznesowe, użytkowników, funkcjonalne i niefunkcjonalne. W przeciwnym razie ryzykujesz uzyskanie produktu, który nie spełnia oczekiwań wszystkich interesariuszy.

Czy zawsze wystarczy przeprowadzić tylko jedną sesję zbierania wymagań?

Nie, w praktyce wymagań jest wiele, są one stopniowo doprecyzowywane, iteracyjnie. Zwykle przeprowadza się kilka sesji, aby zebrać i uzgodnić wszystko poprawnie.

Czy można zmieniać zatwierdzone wymagania bez formalnych procedur?

Nie, wszelkie zmiany muszą przejść przez proces zarządzania zmianami, w przeciwnym razie pojawi się chaos, niezgodności i nieporozumienia między zespołami.

Typowe błędy i antywzorce

• Niedostateczna praca z zainteresowanymi stronami.
• Pomijanie wymagań niefunkcjonalnych.
• Nieprecyzyjna dokumentacja, niejasne sformułowania.
• Brak zarządzania zmianami w wymaganiach.

Przykład z życia

Podczas opracowywania modułu analitycznego dla banku na początku przeprowadzono tylko jeden warsztat. Później okazało się, że funkcjonalność nie uwzględniała wymagań służby bezpieczeństwa informacji, co wymusiło znaczne poprawki produktu, co zajęło czas i budżet.