Inżynieria wymagań IREB. Procesy i wybór metodyki zarządzania projektem

Jakie korzyści przynosi dobrze zaprojektowany proces inżynierii wymagań?

Nasze rozważania możemy zacząć od zastanawiania się: po co w ogóle konfigurować proces inżynierii wymagań? Po co pracować według jakiejś metodyki na danym projekcie? Odpowiedź jest prosta — po to, aby usystematyzować i ustrukturyzować pracę. Działając w pewnych określonych ramach, opieramy się na standardach, które opracowane zostały na bazie dobrych praktyk i doświadczeń.

W przypadku inżynierii wymagań, ale także w całym procesie wytwarzania oprogramowania, podstawą są wzorce projektowe. W praktyce oznacza to, że decydując się na jakąś konfigurację, zarówno przy pozyskiwaniu wymagań, jak i przy dokumentowaniu, będziemy działać zgodnie z danym standardem. W rzeczywistości projektowej niedopuszczalne jest, aby np. każdy analityk pisał wymagania w zupełnie innej formie lub testerzy pracowali w jakiś określony sposób, a analitycy w zupełne inny.

Tym samym wybranie i uzgodnienie sposobu pracy na wstępnym etapie projektu pozwala uporządkować wszystkie istotne kwestie i działać według przejrzystego wzorca. Ten z góry określa, w jaki sposób będziemy spisywać wymagania oraz jak będziemy później nimi zarządzać.

Jak wybrać metodykę wytwarzania oprogramowania?

W IREB otrzymujemy jasne wskazówki, jak ułożyć cały proces inżynierii wymagań. Mogą być one przydatne już na wczesnym etapie projektu, gdy dowiadujemy się o potrzebach i celach klienta. Jest to jednak również etap, na którym warto rozmawiać o metodyce wytwarzania systemu, co także będzie miało wpływ na kontrakt i wszelkie formalne kwestie.

Na szczęście tutaj też możemy odnieść się do wytycznych IREB, w których znajdziemy informacje, jakie czynniki wpływają na proces inżynierii wymagań i jak odnosić je do metodyki wytwarzania projektu. Przy czym sam proces inżynierii wymagań (analizy) powinien być dopasowany do ogólnej metodyki oraz sposobu pracy całego zespołu.

Przykład: jeżeli analitycy zdecydowaliby, że będą pozyskiwać wymagania w sposób tradycyjny, waterfallowy, i przystąpią do analizy, a cały zespół będzie wolał pracować przyrostowo (zwinnie, w scrumie lub w agile’u), to tych dwóch form nie da się ze sobą pogodzić. Takie aspekty muszą zostać uzgodnione wcześniej. Jeżeli pracujemy całym zespołem zwinnie, to testerzy, analitycy i developerzy pracują w jednej metodyce.

Kontekst systemu

To, którą drogę wybierzemy — czy metodyki tradycyjne, czy zwinne — determinuje również kontekst systemu. Przykładem mogą być regulacje prawne (m.in. przetargi publiczne) oraz regulowane urzędy, które nierzadko narzucają konkretne standardy pracy lub też konkretny standard dokumentacji.

To również należy rozważyć przy wyborze metodyki pracy, aby na koniec projektu mogły zostać dostarczone takie dokumenty i inne wytwory pracy, jakie były wymagane.

Dostępność interesariuszy

Kolejną kwestią, którą należy wziąć pod uwagę, wybierając metodykę projektową, jest dostępność interesariuszy. W metodykach waterfallowych interesariusze dostępni są zazwyczaj na samym początku projektu (analizy), a potem dopiero na końcu prac (odbiór). Tymczasem w metodykach zwinnych interesariusze aktywnie uczestniczą przez cały czas trwania projektu.

Oczywiście można o to zapytać wprost lub wyciągnąć wnioski z obserwacji. Jest to punkt zaczepienia w rozmowach z klientem — dobrze od początku wiedzieć, jak ten wyobraża sobie pracę w projekcie. Pamiętając, że czasami trzeba najzwyczajniej w świecie uświadomić klienta, kiedy i w jakim wymiarze będziemy potrzebować kontaktu z interesariuszami.

Inną, często problematyczną, kwestią w projektach waterfallowych jest oczekiwanie określenia wymagań od interesariuszy już na samym na początku projektu. Pojawia się tutaj pytanie, czy mają oni wystarczającą wiedzę, aby sformułować takie wymagania. Często dysponują wyłącznie rozeznaniem w zakresie celów wysokopoziomowych (np. potrzeba stworzenia aplikacji z wysokopoziomowymi funkcjonalnościami, ale bez żadnych konkretnych wymagań).

Tym samym na początkowym etapie konkretne wymagania są mgliste i zostaną doprecyzowane w trakcie trwania projektu. Niemniej jest to już dla wykonawcy systemu jakiś wyznacznik, w którym kierunku rozmawiać z takim klientem i w tym przypadku lepiej rekomendować podejście zwinne niż waterfallowe.

Inne aspekty

Wpływ na ostateczną rekomendację podejścia do procesu wytwarzania oprogramowania będą miały również takie czynniki, jak:

• złożoność i krytyczność systemu dla firmy,
• czas i budżet projektu,
• zmienność wymagań w zależności od zmian rynkowych i działań konkurencji.

Przy czym warto pamiętać, że jeśli taka zmienność jest wysoka, także rekomenduje się wdrożenie iteracyjne.

Aspekty procesu w inżynierii wymagań IREB

W metodyce IREB do wspomnianych czynników dodajemy dodatkowo tzw. aspekty, czyli elementy, które musimy rozważyć, aby skonfigurować proces. Twórcy IREB podali trzy aspekty, decydujące o wyborze metodyki:

1. aspekt czasu,
2. aspekt celu,
3. aspekt docelowego odbiorcy.

W przypadku każdego z tych aspektów mamy do wyboru jedną z dwóch przeciwstawnych sobie opcji. Przy aspekcie czasu będzie to opcja liniowa versus integracyjna, przy celu nakazowa lub eksploracyjna, a w przypadku aspektu docelowego odbiorcy, opcja zorientowana na klienta albo na rynek. Skonfigurowanie procesu, czyli de facto wybór metody sposobu pracy, polega na wybraniu po jednym elemencie z każdego z trzech aspektów, co w efekcie daje różne ich konfiguracje. 

Przechodząc do konkretów:

• Aspekt czasu, czyli w jaki sposób wymagania będą rozłożone w czasie. Liniowo, a więc z góry lub iteracyjnie, czyli przyrostowo (wymagania uszczegóławiane będą w trakcie trwania projektu). Jeśli wybierzemy opcję iteracyjnie, rekomendowane będą metodyki agile’owe (scrum, kanban), jeżeli jednak mówimy o procesie liniowym, pozostają te sterowane planem, czyli tradycyjne (waterfall, Prince 2).

• Aspekt celu ma podział na nakazowy i eksploracyjny. Nakazowy charakteryzuje się tym, że specyfikacja wymagań stanowi swego rodzaju umowę — wszystkie wymagania, o których mówimy, są wiążące i muszą zostać wdrożone. Natomiast w podejściu eksploracyjnym znane są cele, a wymagania będą określane w trakcie trwania procesu.

W usłudze outsourcingu czy też wytwarzaniu przetargowym firmy wybierają najczęściej sposób nakazowy. Natomiast jeżeli klient mówi o swoich celach, a nie o wymaganiach i chciałby, żeby wymagania były uszczegółowione później, to tutaj warto rekomendować podejście eksploracyjne, czyli pójście w metodyki zwinne.

• Ostatnim aspektem, który warto rozważyć przy wyborze metodyki projektowej, jest aspekt zorientowania na rynek albo zorientowania na klienta. O zorientowaniu na klienta mówimy wtedy, kiedy wytwarzany system jest do użytku danej organizacji. Natomiast zorientowanie na rynek będzie wtedy, kiedy system budowany jest z zamysłem sprzedawania jako produkt lub usługa.

Proces iteracyjny a liniowy

W przypadku procesu liniowego interesariusze powinni już na początkowym etapie z góry określić wszystkie wymagania oraz uwzględnić, jak działają procesy. Za to po drugiej stronie, gdzie przyjmujemy podejście iteracyjne, wychodzimy od wysokiego poziomu i razem z biznesem doprecyzowujemy wymagania w miarę trwania projektu.

Co więcej, przy podejściu iteracyjnym zawsze pada pytanie o czas (aby praca iteracyjna miała sens, konieczny jest zapas czasu). W przypadku projektu, gdzie mamy dostarczyć jakąś funkcjonalność lub proces np. w miesiąc, nie ma przestrzeni na działanie iteracyjne. Wówczas, aby zdążyć, należy oczekiwać konkretnych i szczegółowo określonych wymagań, co tym samym determinuje wybór procesu liniowego.

Natomiast jeśli dla biznesu ważna jest możliwość wprowadzania zmian i żonglowania zakresem wymagań w czasie trwania projektu, to zdecydowanie lepiej sprawdzą się procesy iteracyjne niż liniowe.

Proces nakazowy a eksploracyjny

Przy wyborze pomiędzy procesem nakazowym a eksploracyjnym pomoże odpowiedź na pytanie: co jest ważniejsze w projekcie — funkcjonalność i zakres czy koszty i terminy? Oczywiście zazwyczaj okazuje się, że wszystko ?

W takiej sytuacji należy dokładnie przyjrzeć się zakresowi funkcjonalności. Jeśli okaże się, że na potrzeby pierwszego wdrożenia w nieprzekraczalnym terminie wystarczająca będzie uproszczona, okrojona funkcjonalność, to warto obrać kierunek eksploracyjny. Z drugiej strony, jeśli funkcjonalność jest nie do ruszenia, wymagana w całości, to rekomendowany będzie proces nakazowy.

Proces zorientowany na klienta a proces zorientowany na rynek

Przy procesach zorientowanych na klienta jesteśmy w stanie zidentyfikować użytkowników systemu, którymi zazwyczaj są pracownicy osoby zamawiającej i od których należy pozyskać wymagania. A następnie zweryfikować, czy dostarczają oczekiwaną wartość. 

Natomiast w przypadku produktów, które mają być wystawione na rynek, a których użytkownikami będą osoby pobierające czy instalujące daną aplikację, występują trudności w zweryfikowaniu odbiorców. Do weryfikacji dojdzie dopiero na końcu, gdy Ci zaczną już korzystać z aplikacji.

Dlatego tak ważne jest, aby feedback od użytkownika został zebrany jak najszybciej po wypuszczeniu oprogramowania na rynek. W takim podejściu lepiej sprawdzą się metodyki zwinne niż waterfallowe.

Typowe konfiguracje w IREB

Twórcy IREB sugerują trzy typowe konfiguracje, które w ich ocenie najlepiej sprawdzają się podczas prowadzenia projektu software’owego.

Angażujący proces

Jest to zestawienie procesów: iteracyjnego, eksploracyjnego i zorientowanego na klienta. Typowa sytuacja, w której biznes zamawia aplikację na użytek wewnętrzny. Konfiguracja procesów wskazuje na metodyki zwinne, a głównym przypadkiem użycia tej konfiguracji będzie układ, w którym to zamawiający i wykonujący aplikację/system ściśle ze sobą współpracują, a interesariusze (czyli na przykład biznes) jest mocno zaangażowany w proces inżynierii wymagań. 

Jakie produkty tworzyć będziemy w takim projekcie? Prototypy, makiety, product backlog czy historyjki użytkownika. Czyli typowe elementy dokumentacji, o które pyta zamawiający. Jeśli zaś chodzi o komunikację, jest to ciągła interakcja zespołu wykonującego z biznesem.  

Ważna jest tu rola product ownera, czyli osoby po stronie biznesu, który odpowiada za kierunek i funkcjonalności wytwarzanego systemu. Czasami zdarza się, że po stronie wykonawczej pojawia się rola product ownera proxy. Szczególnie wtedy, kiedy sam product owner jest osobą merytoryczną i podejmuje decyzje biznesowe, ale potrzebuje wsparcia w zarządzaniu projektem. 

Kontraktowy proces

Na kolejną konfigurację składają się procesy: liniowy, nakazowy i zorientowany na klienta. To z kolei sytuacja, w której zamawiający zamawia system na własne potrzeby, ale cały zespół pracuje waterfallowo. Tym samym specyfikacja wymagań stanowi podstawę do kontraktu pomiędzy stroną zamawiającą i wykonawczą. Różnica jest również taka, że interakcja interesariuszy, czyli biznesu, będzie niewielka. Po etapie analizy, ci pojawią się dopiero przy odbiorach.

O jakich dokumentach i efektach pracy będziemy tu mówić? Klasyczna specyfikacja wymagań, różne spisane dokumenty, modele, diagramy (UML czy BPMN).

Zorientowany na produkt

Trzecia z typowych konfiguracji — organizacja zamawia system, który będzie sprzedawać użytkownikom. Współgra to z procesem iteracyjnym, agile’owym.

Wytwory pracy będą bardzo podobne jak przy pierwszym typie (backlog, historyjki czy prototypy). Różnica polega na tym, że jeżeli produkt kierowany jest na rynek, a nie do wewnątrz organizacji, nie będziemy mieć bezpośredniego dostępu do wszystkich potencjalnych użytkowników. Tym samym najlepiej przeprowadzić warsztaty product discovery czy badania UX.

W takim projekcie wydania będą częstsze niż w przypadku systemu wewnętrznego.

Metodyka IREB

Metodyka IREB oferuje pewien algorytm pracy w projekcie software’owym, pomiędzy wykonawcą a zamawiającym.

Oczywiście software house’y, realizujące dziesiątki, a nawet setki projektów, są świadome tego, co jest ważne w projekcie i o co należy na początku zapytać klienta, aby dobrze ułożyć proces wytwórczy.

Zrozumienie, jak wybierać i konfigurować procesy inżynierii wymagań zgodnie z wytycznymi IREB, umożliwia firmie dostosowanie się do oczekiwań klientów, zapewniając jednocześnie dobrze zdefiniowane procesy. To kluczowa wiedza, zwłaszcza w przypadku firm realizujących wiele projektów, umożliwiająca efektywne planowanie pracy i skuteczną komunikację z klientami.