Odpowiedź.

Historia pytania:

Wraz ze wzrostem skali i złożoności projektów IT wielokrotnie zdarzała się sytuacja, w której wymagania od klienta biznesowego wpływały w postaci abstrakcyjnych życzeń, które przy przekazywaniu do zespołu programistycznego stawały się czymś innym. Powodem jest rozbieżność w terminologii, oczekiwaniach i poziomie abstrakcji między biznesem a IT.

Problem:

Jeśli nie przemyśli się etapu dekompozycji, wymagania mogą stać się niekompletne (brak krytycznych szczegółów), zbyt rozmyte (niemożliwe do oszacowania i zrealizowania) lub w ogóle zniekształcone z powodu leksykalnych pułapek, niezauważonej terminologii i niejasności.

Rozwiązanie:

Analityk systemowy systematycznie dekomponuje każde wymaganie: formalizuje terminy biznesowe, przekształca cele biznesowe w funkcje i zadania, opisuje scenariusze użytkownika i zachowanie systemu, odnosi do kryteriów akceptacji/testów. Ważne jest stosowanie modeli (UML, BPMN), glosariuszy, list kontrolnych i bezpośrednich przeglądów między zespołami.

Kluczowe cechy:

Budowanie glosariusza terminów wspólnie z klientem
Stosowanie diagramów i atomowych sformułowań wymagań
Przekładanie wymagań na język kryteriów akceptacji i testów

Pytania z zaskoczeniem.

Czy można pozostawić życzenia biznesowe w swobodnej formie z dalszym opracowaniem na etapie rozwoju?

Nie, istnieje duże ryzyko nieporozumienia i błędów w realizacji.

Czy należy dochodzić do szczegółów realizacji (na przykład jak przechowywać dane) na etapie analizy?

Nie, analiza dotyczy "czego" i "dlaczego", a nie "jak". Szczegóły techniczne są odpowiedzialnością architektury i programowania.

Czy zawsze jedna zapis wymagań = jeden moduł/cecha?

Nie, często wymagana jest dekompozycja — duże wymagania dzielą się na pod-funkcje i historie użytkowników z osobnymi kryteriami akceptacji.

Typowe błędy i antywzorce

Mieszanie języka biznesowego i terminów technicznych bez glosariusza
Opis wymagań w postaci "rozmytych życzeń"
Naruszenie atomowości — jedno wymaganie zawiera wiele różnych bytów

Przykład z życia

Negatywny przypadek: Klient przekazał listę życzeń "Użytkownik powinien widzieć całą analitykę sprzedaży", w TŻ skopiowano w niezmienionej formie.

Plusy:

Szybkość przygotowania dokumentacji

Minusy:

Niejasne, jakie dokładnie metryki i w jakim zakresie są potrzebne
Ciągłe poprawki

Pozytywny przypadek: Analityk zapytał klienta, sporządził listę niezbędnych metryk, określił role użytkowników, opracował prototypy raportów, uzgodnił glosariusz terminów.