top of page

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ą:

  1. 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.

  2. Jaki wpływ proponowana zmiana będzie miała na stopień realizacji celów projektu i potrzeb klienta?

  3. 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.

Comments


DSC_4515_edited_edited_edited_edited_edited.jpg

Cześć,
mam na imię Krzysztof

Inżynier systemów w wiodącej Polskiej firmie z branży kosmicznej Creotech Instruments.

Wiceprezes polskiego oddziału Międzynarodowej Rady Inżynierów Systemów (INCOSE).

Archiwum postów

Tagi

Nie ma jeszcze tagów.
bottom of page