Wymagania w projektach IT mogą (choć nie zawsze powinny) zmieniać się w każdej fazie cyklu życia oprogramowania. Na etapie analizy są one ustalane, w czasie kodowania mogą się pojawić wątpliwości, wiec czasami wymagania są doprecyzowywane, w trakcie testów akceptacyjnych mogą się pojawić błędy, których rozwiązanie wymaga dodatkowej analizy a w trakcie użytkowania systemu pojawiają się nowe potrzeby, które również trzeba udokumentować. W tym wpisie dowiesz się, jakie techniki pomagają w zapanowaniu nad tym pozornym chaosem.
Określ zbiór stały zbiór metadanych dla każdego wymagania
Metadane to informacje o informacjach. W tym przypadku samo wymaganie będzie zawierało treść wymagania a metadane pozwolą na zidentyfikowanie autora wymagania, daty pozyskania, statusu realizacji wymagania oraz wersji wymagania. Zbiór metadanych z którego sam korzystam to:
- Identyfikator wymagania – pozwala jednoznacznie odnosić się do wymagania i wskazywać powiązania pomiędzy nimi.
- Autor wymagania – osoba, która je zgłosiła.
- Status wymagania – informacje o tym na jakim etapie procesu zarządzania wymaganiami jest dane wymaganie (przykładowo: nowe, zrealizowane, zatwierdzone, odrzucone).
- Wersja wymagania – pomaga stworzyć dokument z konfiguracją wymagań oraz określić, które wymagania są najbardziej zmienne.
- Kategoria wymagania – pozwala potem przekrojowo przeglądać wymagania np. wg. modułów aplikacji (np. Zarządzanie uprawnieniami, Raporty, Administracja systemem).
Dzięki powyższym, jesteśmy w stanie wielowymiarowo analizować wymagania, ich pochodzenie, status, powiazania i kompletność dokumentacji.
Zdefiniuj proces zarządzania zmiana wymagań
Określ w jaki sposób (np. formularz zgłoszeniowy) i przez kogo (osoby uprawnione) nowe wymagania mają być zgłaszane. Następnie określ skład zespołu oceniającego wymagana (klasyfikacja czy jest to nowe wymaganie, zmiana istniejące, czy jest zasadne czy nie) oraz przebieg prac nad wymaganiem np:
- Rejestracja zgłoszenia
- Klasyfikacja zgłoszenia i jego estymata
- Doprecyzowanie wymagania
- Akceptacja/odrzucenie
- Nadanie priorytetu
- Zaplanowanie wykonania
- Odbiór wymagania
Utwórz rejestr wymagań, który pozwoli pod koniec projektu ocenić jakoś prac analitycznych, zmienność klienta, stosunek wymagań do CR (wniosków o zmianę).
Przygotuj sobie listę kontrolną prac przy zmianach wymagań
Lista kontrolna pozwoli Ci upewnić się, że zatwierdzona zmiana wymagania została uwzględniona we wszystkich wymaganych dokumentach oraz, że wszystkie zainteresowane osoby zostały o niej poinformowane. Przykład:
- Dokumenty do aktualizacji:
- Specyfikacja wymagań
- Przypadki użycia
- Scenariusze testowe
- Instrukcja użytkownika
- Instrukcja administratora
- Poinformowane osoby:
- Pozostali analitycy zaangażowani w projekt
- Architekt
- Kierownicy zespołów deweloperskich
Korzystaj w odpowiednich narzędzi
Stosuj narzędzia, które wspomagają śledzenie powiazań pomiędzy wymaganiami (np. Enterprise Architect). Jeżeli nie dysponujesz takimi narzędziami i całą dokumentację przechowujesz w plikach tekstowych – upewnij się, że masz narzędzie, które zapisuje kolejne wersje tych dokumentów (np. biblioteka Sharepoint z włączonym wersjonowaniem lub server SVN/GIT). Proces zgłaszania nowych wymagań, gdy system już istnieje możesz oprzeć na systemie biletowym np. JIRA, Mantis.
Zostaw komentarz