Plan zarządzania wymaganiami

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 🙂

 

 

 

 

Podobne wpisy
Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Średniozaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Zaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top