Proces zmiany wymagań
Zaktualizowano: 12 gru 2022
Skoro już wiemy jak poprawnie pisać wymagania to w poniższym artykule napiszę więcej na temat procesu zarządzania wymaganiami, a konkretnie procesu zmiany wymagań.
Zmiana wymagań
Tak długo, jak wymagania mają status „roboczy” i są przedmiotem wewnętrznego procesu, inżynier systemów ma znaczną wolność w ich modyfikowaniu. Sytuacja ulega zmianie w momencie, gdy mamy kompletny zestaw wymagań, który został sprawdzony i zatwierdzony w ramach tzw. Przeglądu Wymagań (ang. Requirements Review). W tym momencie ta wolność zostaje ograniczona formalnym procesem zmiany wymagań.
Dlaczego?
Istnieją co najmniej dwa ważne powody ku temu, aby ostrożnie podchodzić do zmian wymagań, które zostały formalnie zaakceptowane i opublikowane w ramach projektu.
Powód 1 - Zestaw wymagań staje się informacją wejściową dla pracy inżynierów
Jednym z celów tworzenia zestawu wymagań w projekcie jest przekazanie do zespołów inżynierskich informacji, jak np. „co i jak dobrze system ma robić”, będących podstawą do ich pracy. Wraz z przekazaniem tych informacji, inżynierowie rozpoczynają proces projektowania, zatem późniejsza, niekontrolowana zmiana w wymaganiach, może nie trafić do ich świadomości, powodując rozdźwięk pomiędzy wymaganiami a pracami projektowymi.
Powód 2 – Zatwierdzone wymagania są wynikiem zbiorowej mądrości
Idea przeglądu wymagań i ich formalnego zatwierdzenia zakłada, że dzięki udziałowi zewnętrznych recenzentów - specjalistów w dziedzinach związanych z realizowanym projektem - uda się zapewnić najwyższą możliwą jakość. W związku z tym, zestaw wymagań, który zostaje zamrożony w trakcie przeglądu jest wynikiem zbiorowej mądrości i doświadczenia wszystkich jego uczestników, i jako taki nie powinien być zmieniany arbitralnie przez jedną osobę.
Jakże zatem powinien wyglądać proces formalnej zmiany wymagań?
Proces zmiany
Gdy zachodzi potrzeba zmiany wymagania, inżynier systemów jest odpowiedzialny za przygotowanie informacji, które posłużą jako wkład do podjęcia decyzji o akceptacji lub odrzuceniu zmiany.
Powinny one obejmować co najmniej:
Zakres i powód proponowanej zmiany
Wszystkie wymagania, na które proponowana zmiana będzie miała wpływ - tzw. Analiza wpływu (ang. Impact analysis)
Taki zestaw informacji, w postaci formalnego dokumentu tzw. Wniosku o Zmianę (ang. Change request), powinien zostać przekazany osobom, które wchodzą w skład Komisji Kontroli Zmiany (ang. Change Control Board).
Po zapoznaniu się z dokumentem, Komisja zbiera się, aby przeprowadzić dyskusję i podjąć decyzję. Najważniejszymi punktami dyskusji i pytaniami, na które gremium musi sobie odpowiedzieć są:
Jaki wpływ proponowana zmiana będzie miała na pozostałe wymagania projektowe? – odpowiedź na to pytanie jest kluczowa dla świadomej odpowiedzi na kolejne dwa, ponieważ zazwyczaj występuje wiele współzależności pomiędzy wymaganiami, co w praktyce może oznaczać, że próba zmiany jednego z nich spowoduje zmiany również i w innych.
Jaki wpływ proponowana zmiana będzie miała na stopień realizacji celów projektu i potrzeb klienta?
Jaki wpływ proponowana zmiana będzie miała na budżet i harmonogram projektu?
Poziom formalizmu tego procesu bardzo zależy od wielkości projektu oraz procedur wewnątrz organizacji, które go realizują. Przy dobrej koordynacji i responsywnym zespole, proces ten może trwać kilka dni, nie będąc przesadnym obciążeniem dla uczestników. Obowiązkiem inżyniera systemów jest zadbanie, aby efekt proponowanych zmian był oceniony świadomie, a w przypadku wprowadzenia zmian, zakomunikowany całemu zespołowi projektowemu.
Jak zakomunikować zmianę wymagań
Niezależnie od narzędzie jakiego używamy do zarządzania wymaganiami, najlepszym rozwiązaniem jest umieszczenie informacji o wprowadzonych zmianach, wraz z odniesieniem do zaakceptowanego Wniosku o Zmianę, w formie tzw. Dziennika Zmian (ang. Change Log), na początku dokumentu zawierającego zestaw wymagań.
Dzięki temu inżynierowie będą mogli patrzeć na zaktualizowany zestaw wymagań z perspektywy całości, jak i z perspektywy wprowadzonych zmian.
Kwestia komunikacji w codziennej pracy inżyniera systemów będzie opisana szerzej w przyszłych artykułach.
