Plan zarządzania wymaganiami to dokument, który opisuje zasady postępowania z wymaganiami. W moim odczuciu to jeden z najważniejszych dokumentów, gdyż w jawny sposób opisuje szereg ważnych informacji dotyczących sposobu udokumentowania wymagań. To swoisty kontrakt pomiędzy analitykami a pozostałymi interesariuszami.
Dokument w zależności od projektu może się różnić. W opisie wymagań nie zapominam o przypadkach życia, Zazwyczaj staram się aby w nim był opisane poniżej zdefiniowane informacje:
Techniczne
- dot. środowiska (np.: Enterprise Architect), które przechowuje wymagania.
- dot. osoby, która jest odpowiedzialna za zarządzanie środowiskiem (np.: administrator za sprawy techniczne, merytorycznie kierownik analizy)
Identyfikacja i rozmieszczenie wymagań
- rodzaj wymagania (np.: potrzeby biznesowe, wymagania bezpieczeństwa)
- identyfikator wymagania (np.: WB – wymaganie biznesowe, WN.B – wymaganie niefunkcjonalne dot. bezpieczeństwa)
- opis przeznaczenia wymagania – (np (bardzo uproszczony opis).: wymagania biznesowe definiują potrzeby interesariuszy
- miejsce w repozytorium, gdzie przechowywane są wymagania
- nazwa dokumentu, w którym znajdzie się dany rodzaj wymagania (np.: wymagania biznesowe – wizja rozwiązania)
- mapowania wymagań – określam jakich relacji użyję do połączenia wymagań ze sobą a także z innymi artefaktami jak przykładowo aktywności z procesu biznesowego.
Atrybuty
W tym punkcie opisuję, jakimi atrybutami będę opisywał wymagania (w tym i przypadki użycia). Przykładowe atrybuty to status, priorytet. Przykładowy opis statusów i opisu priorytetów.
Status
• Proponowane – wymaganie w fazie negocjacji pomiędzy klientem a analitykami
• Zatwierdzone -wymaganie zatwierdzone do realizacji.
• Odrzucone – wymaganie odrzucone przez klienta lub analityków.
Priorytety
• Niezbędne (bardzo ważne) – podstawowe wymaganie którego realizacja jest konieczna do spełnienia minimalnych wymogów tworzonego systemu. Brak realizacji będzie oznaczał, że system nie spełnia podstawowych oczekiwań klienta.
• Istotne (ważne) – wymaganie, którego realizacja jest ważna dla skutecznego i efektywnego działania systemu. Brak jego realizacji może mieć duży wpływ na ocenę systemu przez klienta.
• Przydatne (mniej ważne)- wymaganie, które jest wykorzystywane w mniej typowych zastosowaniach. Brak ich realizacji nie ma znacznego wpływu na funkcjonalność systemu.
Oprócz statusów i priorytetów można jeszcze opisać: ryzyka, stabilność wymagania, wpływ na biznes, do kogo jest przypisane wymagania i inne. Nie zalecam dodawania dużej ilości atrybutów. Z biegiem projektu zaczynają mieć mniejsze znaczenia a ponadto wymagają czasu by je aktualizować i utrzymywać.
Dokumenty
W tej sekcji opisuję jakie dokumenty powstaną. Dla każdego dokumentu określam ich zawartość merytoryczną czyli plan rozdziałów.
Zarządzanie wymaganiami
To jedna z ważniejszych sekcji. Opisuję tu proces zmiany wymagań czyli definiuję:
- ścieżkę zgłoszenia zmian
- narzędzie do zgłoszenia zmiany (np.: JIRA, lub dokument)
- osobę odpowiedzialną za zajęcie się zgłoszeniem oraz osobę lub zespół odpowiedzialny za akceptację proponowanej zmiany
- sposób oznaczenia zmiany w repozytorium i wygenerowanych z niego dokumentów
Tak oto wygląda plan zarządzania wymaganiami. Dokument, który bardzo ułatwia sposób zarządzania wymaganiami. Jeśli Twój w Twoim projekcie jest inny dokument o podobnym charakterze, opisz go proszę w komentarzach do tego tekstu. Wymiana doświadczeń jest bezcenna 🙂
