Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> numer wersji <miesiąc rrrr>dd-mm-rrrr Strona 1 z 14
Krótki opis dokumentu Opracowano na podstawie Właściciel dokumentu Weryfikacja merytoryczna MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI opisuje plan zarządzania wymaganiami<krótki opis usługi> Departament Informatyki Imię i nazwisko, stanowisko Data Podpis Weryfikacja formalna Imię i nazwisko, Data Podpis stanowisko Zatwierdził Imię i nazwisko, Data Podpis stanowisko Data druku DD.MM.RRRR Liczba stron Nazwa pliku Plan_zarządzania_dokumentami Status z (zatwierdzony)r (roboczy)lub z (zatwierdzony) HISTORIA ZMIAN Nr wersji Data Opis Działanie (*) Rozdziały(**) Autorzy 1.00 DD.MM.RRRR Utworzenie nowego dokumentu (*) Działanie: N-Nowy, Z-Zmiana, W-Weryfikacja (**) Rozdziały: numery rozdziałów lub W-Wszystkie N W <nazwisko autora><nazwisko autora> Lista dystrybucyjna Sposób określenia listy dystrybucyjnej produktu musi być zgodny z planem komunikacji w projekcie. Imię i nazwisko / Rola Organizacja Zgłoszono do odbioru Sposób przekazania do odbioru produktu musi być zgodny z planem jakości w projekcie. Imię i nazwisko Data: Podpis: Imię i nazwisko Data: Podpis: Imię i nazwisko Data: Podpis: Strona 2 z 14
Akceptacja Sposób odbioru przez Zamawiającego (jego akceptacji) produktu musi być zgodny z planem jakości w projekcie. Imię i nazwisko Data: Podpis: Imię i nazwisko Data: Podpis: Imię i nazwisko Data: Podpis: Strona 3 z 14
Spis treści Wykaz uŝytych skrótów oraz symboli... 5 1. Wstęp... 6 1.1 Cel i struktura produktu... 6 1.2 Odbiorcy produktu... 6 1.3 1.4 Zakres produktu... 6 Referencje... 6 2. Zarządzanie wymaganiami... 7 2.1 Organizacja, zakres odpowiedzialności i zasady komunikacji... 7 2.2 Narzędzia, środowisko i infrastruktura... 7 3. Program zarządzania wymaganiami... 8 3.1 Sformułowanie wymagań... 8 3.2 Zatwierdzanie wymagań... 8 3.3 3.4 Kontrola wymagań... 8 Atrybuty wymagań... 9 3.4.1 Identyfikator... 9 3.4.2 Nazwa... 9 3.4.3 Opis... 9 3.4.4 Status... 9 3.4.5 WaŜność... 9 3.4.6 Szacowana pracochłonność... 9 3.4.7 Ryzyko... 10 3.4.8 Stabilność... 10 3.4.9 Docelowa wersja... 10 3.4.10 Przypisany do... 10 3.4.11 Uzasadnienie... 10 3.4.12 <Inne>... 10 3.5 Raporty i miary... 10 3.6 Zarządzanie zmianą wymagań... 11 3.6.1 Uzgadnianie i akceptacja wniosków zmiany... 11 3.6.2 Zasady kontroli zmian... 11 3.7 Procesy i działania... 11 4. Lista tabel... 12 5. Lista załączników... 13 Strona 4 z 14
WYKAZ UśYTYCH SKRÓTÓW ORAZ SYMBOLI Niniejsza sekcja prezentuje definicje pojęć, akronimów i skrótów wykorzystywanych w niniejszym produkcie, których wyjaśnienie nie występuje w Słowniku projektu. Sposób opisu uŝytych skrótów i symboli w produkcie musi być zgodny ze planem komunikacji w projekcie. Skrót / Symbol Znaczenie Strona 5 z 14
1. WSTĘP Wprowadzenie do produktu Plan zarządzania wymaganiami" przedstawia cel, odbiorców, zakres i referencje produktu 1.1 Cel i struktura produktu Przedstawienie celu Planu zarządzania wymaganiami. Celem produktu jest: Dostarczenie podstawowego produktu kierującego planowaniem i kontrolą procesu zarządzania wymaganiami Określenie typów wymagań oraz sposobu ich opisu Określenie produktów końcowych wymagań Plan zarządzania wymaganiami musi być zgodny z załoŝeniami w planie komunikacji projektu. 1.2 Odbiorcy produktu Sekcja zawiera informacje o adresatach produktu. Sekcję naleŝy uzupełnić na bazie RASCI projektu.. 1.3 Zakres produktu W tej części naleŝy opisać zakres informacji zawartych w tym dokumencie, dotyczących systemu, do którego odnosi się Plan zarządzania wymaganiami oraz inne dokumenty, na które niniejszy dokument ma wpływ. np: Specyfikacja procesów i wymagań biznesowych Specyfikacja wymagań systemu informatycznego. 1.4 Referencje Sekcja zawiera listę wszystkich dokumentów, do których znajdują się odniesienia w niniejszym produkcie. KaŜdy dokument referencyjny identyfikowany jest co najmniej przez tytuł, autora, datę opublikowania; opcjonalnie przez numer referencyjny czy teŝ inny identyfikator, np. pozycję Dziennika Ustaw. 1. <<Tytuł, autor, data>> Strona 6 z 14
2. ZARZĄDZANIE WYMAGANIAMI 2.1 Organizacja, zakres odpowiedzialności i zasady komunikacji Sekcja zawiera opis, kto będzie odpowiedzialny za poszczególne działania opisane w procesie zarządzania wymaganiami. 2.2 Narzędzia Sekcja zawiera opis narzędzi, które będą uŝywane do realizacji zadań związanych z zarządzaniem wymaganiami podczas realizacji projektu i/lub podczas cyklu Ŝycia produktu. Strona 7 z 14
3. PROGRAM ZARZĄDZANIA WYMAGANIAMI 3.1 Sformułowanie wymagań Opis typów wymagań wykorzystywanych w trakcie realizacji systemu informatycznego jak i zdefiniowanie konwencji ich nazewnictwa, oznaczenia i numeracji. PoniŜej została przedstawiona przykładowa tabela z rodzajami wymagań. Tabela 1. Typy wymagań Typy wymagań Typ wymagania Konwencja Opis Funkcjonalne UŜyteczności Niezawodności Wydajności Wspieralności Nazewnictwo, oznaczenia i numeracja. Nazewnictwo, oznaczenia i numeracja. Nazewnictwo, oznaczenia i numeracja. Nazewnictwo, oznaczenia i numeracja. Nazewnictwo, oznaczenia i numeracja. Opis aspektów, jakich dotyczy dany typ wymagania. Opis aspektów, jakich dotyczy dany typ wymagania. Opis aspektów, jakich dotyczy dany typ wymagania. Opis aspektów, jakich dotyczy dany typ wymagania. Opis aspektów, jakich dotyczy dany typ wymagania. 3.2 Zatwierdzanie wymagań Definicja zasad zatwierdzania wymagań, zidentyfikowanych wymagań, a szczególnie zasad wprowadzania zmian w zaakceptowanych wymaganiach. 3.3 Kontrola wymagań Definicja zasad kontroli. Dla kaŝdego wymagania naleŝy wymienić dodatkowe reguły lub wskazówki niezbędne do zastosowania w celu śledzenia jego powiązań z innymi wymaganiami. NaleŜy opisać wszystkie zasady, których naleŝy się trzymać, np. kaŝda zaakceptowana cecha oprogramowania musi być powiązana przynajmniej z jednym przypadkiem uŝycia lub przynajmniej z jednym wymaganiem dodatkowym. Strona 8 z 14
3.4 Atrybuty wymagań Dla kaŝdego zdefiniowanego rodzaju wymagań naleŝy określić atrybuty, za pomocą których będzie on opisywany, i krótko wyjaśnić ich znaczenie. PoniŜej przedstawiono przykładową listę atrybutów wymagania. 3.4.1 Identyfikator Unikalny identyfikator wymagania nadawany zgodnie z konwencją numeracji wymagań. 3.4.2 Nazwa Unikalna nazwa wymagania nadawana zgodnie z konwencją nazewnictwa wymagań. 3.4.3 Opis Pełny opis wymagania. 3.4.4 Status Ustalany po negocjacjach i przeglądzie przez zespół zarządzający projektem. SłuŜy do śledzenia postępu analizy wymagania przy definiowaniu linii bazowej projektu. Tabela 2. Status wymagań Status wymagań Status wymagań Zaproponowany Zaakceptowany Odrzucony Zintegrowany Opis Stosowany do opisywania wymagań, które są wciąŝ dyskutowane, lecz nie zostały jeszcze przejrzane i zaakceptowane na drodze formalnej, np. przez grupę roboczą składającą się z Analityka Systemowego, Kierownictwa Projektu i reprezentanta Głównego UŜytkownika. Wymaganie uznane za przydatne i wykonalne oraz zaakceptowane do wdroŝenia w sposób formalny. Wymaganie odrzucone w sposób formalny Wymaganie zintegrowane z linią bazową projektu w określonym czasie 3.4.5 WaŜność Atrybut uŝywany w zarządzaniu zakresem projektu i określaniu priorytetów rozwoju oprogramowania. PoniŜej został przedstawiony przykładowy wykaz korzyści. Wartości atrybutu powinny być nadane zgodnie z techniką MoSCoW. 3.4.6 Szacowana pracochłonność PoniewaŜ niektóre wymagania wymagają więcej czasu i zasobów od innych, estymowanie niezbędnych do ich realizacji np. liczby dni roboczych, linii kodu lub punktów funkcyjnych jest Strona 9 z 14
najlepszą metodą do oszacowania ich złoŝoności i moŝliwości realizacji w określonym czasie. Atrybut uŝywany w zarządzaniu zakresem projektu i określaniu priorytetów dla kolejności realizowanych wymagań. 3.4.7 Ryzyko Atrybut opiera się na prawdopodobieństwie wystąpienia w projekcie niepoŝądanych zdarzeń, takich jak przekroczenie kosztów, opóźnienia czy nawet zamknięcie projektu. Większość kierowników projektów uwaŝa za wystarczające zastosowanie takich kategorii ryzyka, jak wysokie, średnie i niskie, niemniej moŝliwa jest klasyfikacja bardziej precyzyjna. Ryzyko moŝna często szacować pośrednio, mierząc zagroŝenie dla ustalonego harmonogramu prac. 3.4.8 Stabilność Atrybut ten opiera się na prawdopodobieństwie zmiany wymagania lub zmiany rozumienia wymagania. Jest on wykorzystywany do ustalania priorytetów rozwoju oprogramowania i definiowania elementów, dla których dodatkowe wyjaśnienia są najbardziej właściwym kolejnym krokiem. 3.4.9 Docelowa wersja Ustala wersję produktu, w której wymaganie pojawi się po raz pierwszy. Atrybut ten moŝe być wykorzystywany do definiowania zakresu wdroŝenia danej wersji linii bazowej. UmoŜliwia zarządzanie zakresem wdroŝenia poszczególnych wersji (wdraŝane są wyłącznie wymagania o statusie Zintegrowany i ustalonej wersji docelowej). 3.4.10 Przypisany do Przypisywane wymagania do poszczególnych zespołów odpowiedzialnych za ich dalszą analizę, spisanie wymagań i implementację. Atrybut ten pozwala na zarządzanie zakresem odpowiedzialności w projekcie. 3.4.11 Uzasadnienie Atrybut pozwala śledzić źródło wymagania. Wymagania pojawiają się z konkretnej przyczyny. Atrybut ten pozwala na zarejestrowanie wyjaśnienia bądź odniesienia do wyjaśnienia. Na przykład moŝe to być odniesienie do wymagania biznesowego bądź do fragmentu sprawozdania ze spotkania z Głównym UŜytkownikiem. 3.4.12 <Inne> Dowolne dodatkowe atrybuty specyficzne dla realizowanego systemu informatycznego.. 3.5 Raporty i miary Opis zawartości, format i cel wymaganych raportów/miar. Strona 10 z 14
3.6 Zarządzanie zmianą wymagań 3.6.1 Uzgadnianie i akceptacja wniosków zmiany Opis procesu, w ramach którego propozycje nowych wymagań i zmian istniejących juŝ wymagań są przedstawiane, przeglądane i oceniane. Proces ten powinien obejmować działania dotyczące negocjowania zmian wymagań z Zamawiającym. 3.6.2 Zasady kontroli zmian Opis zasad uczestnictwa i procedury, do których powinien stosować się zespół odpowiedzialny za kontrolę zmian przy ocenianiu i akceptowaniu wniosków zmian. 3.7 Procesy i działania Opis procesów i działań, które mają zastosowanie do zarządzania wymaganiami, takie jak przeglądy, w tym przeglądy celów projektu, przeglądy zakresów odpowiedzialności, harmonogramów i procedur. Strona 11 z 14
4. LISTA TABEL Tabela 1. Typy wymagań... 8 Tabela 2. Status wymagań... 9 Tabela 3. Załączniki... 13 Strona 12 z 14
5. LISTA ZAŁĄCZNIKÓW Tabela 3. Załączniki Wykaz załączników Lp. Załącznik Uwagi 1. 2. 3. 4. 5. Strona 13 z 14
6. DOKUMENTY POWIĄZANE Tabela 4. Załączniki Wykaz dokumentów Lp. Uwagi 1. 2. 3. 4. 5. Strona 14 z 14