"Inżynieria wymagań" to jest ta mityczna dyscyplina, o której wspominają sylabusy ISTQB. Takie stwierdzenie usłyszałam ostatnio od jednego z klientów. Inżynieria wymagań to dyscyplina, o której wiele osób słyszało; pojedyncze osoby kojarzą, czym się ta dyscyplina zajmuje.

 

Większość osób pełniących przeróżne funkcje w wytwarzaniu oprogramowania, z którymi na ten temat rozmawiałam, uważa, że inżynieria wymagań to obszar generalnie związany z kaskadowym wytwarzaniem oprogramowania, który w obecnych warunkach nie ma szczególnej racji bytu. W wielu przypadkach pracujemy bowiem zgodnie z szeroko rozumianymi podejściami Agile, w ramach których inżynieria wymagań nie występuje, lub występuje lecz jedynie w bardzo mocno ograniczonym zakresie. Czy aby na pewno?

 

Czy na pewno, podejmując się dostarczenia jakiegokolwiek systemu (rozumianego jako system informatyczny, system informacyjny czy ogólnie dowolna usługa biznesowa), nie myślimy o wymaganiach? Nie zastanawiamy się, w jaki sposób system powinien być skonstruowany, aby dostarczyć oczekiwaną wartość biznesową? Skąd w takim razie wiemy, co powinno zostać zrobione, w jakiej kolejności i przez kogo? Bez wymagań nie ustalimy zakresu pracy, oczekiwanego wyniku tej pracy, ani nie będziemy w stanie stwierdzić, czy prace zostały ukończone z wynikiem pozytywnym. Bez wymagań nie wiemy, jakie operacje biznesowe system powinien wspierać. W jaki sposób zatem planujemy przetestować system?

 

Te pytania są dosyć oczywiste. Podejmując się realizacji jakiegokolwiek produktu czy usługi, musimy dowiedzieć się, jakie potrzeby ów produkt czy usługa miałaby spełniać. To nic innego niż proces pozyskiwania wymagań. Proces ten nie odbędzie się bez właściwego przygotowania, które obejmuje szereg różnych czynności, wśród których kluczową jest ustalenie źródeł wymagań.

 

Typowym źródłem wymagań jest tzw. klient - to oczywiste dla większości dostawców usług i rozwiązań. Problem pojawia się w momencie zdefiniowania pojęcia “klient”. Dla niektórych klientem jest końcowy użytkownik danego rozwiązania, dla innych zaś klientem jest zamawiający daną usługę lub produkt, czyli umowny płatnik. Bez zrozumienia, o jakim kliencie mówimy, nie jesteśmy w stanie właściwie pozyskać wymagań, ponieważ nie wiemy, skąd te wymagania brać.

 

W uproszczeniu, czy na temat projektowanego systemu powinniśmy porozmawiać z użytkownikiem końcowym, czy z osobą płacącą za realizację systemu? A może z jednym i drugim? Dodatkowo, co z innymi interesariuszami? Co ze sprzedażą, marketingiem, logistyką? Przedstawiciele tych obszarów również mogą dostarczać swoje wymagania. Częścią procesu pozyskiwania wymagań jest więc ustalenie źródeł wymagań, wśród których znajdują się zarówno interesariusze, jak i dokumenty biznesowe czy regulacyjne oraz inne systemy.

 

Konsekwencją ślepego zapatrzenia się w jeden typ interesariusza jako jedyne źródło wymagań może być to, że wielu kluczowych wymagań nie pozyskamy. W efekcie dostarczony system może być postrzegany jako niekompletny lub wręcz bezwartościowy. Trudno wyobrazić sobie sytuację, w której profesjonalna firma podejmująca się realizacji projektu wytwórczego nie bierze tych aspektów pod uwagę. Innymi słowy, w ramach procesu wytwórczego uwzględniamy identyfikację źródeł wymagań oraz pozyskiwanie wymagań, nawet jeżeli oficjalnie nie posługujemy się tą nomenklaturą.

 

Idąc tym tropem, pozyskane zgodnie ze sztuką wymagania powinny być przedmiotem pewnej analizy. Nie możemy bowiem zakładać, że informacje pozyskane z różnych źródeł będą kompletne, spójne i wystarczające do zaprojektowania naszego systemu. Powinniśmy dokonać analizy i syntezy zebranej informacji. Dzięki temu możliwe jest zrozumienie powiązań między poszczególnymi wymaganiami, potencjalnych ograniczeń mogących wpłynąć na koncepcję planowanego systemu, oraz odkrycie potencjalnych sprzeczności w wymaganiach. Jest to kolejny proces w inżynierii wymagań. Pominięcie tego procesu z reguły powoduje dość szybko zauważalne efekty – próbujemy implementować niesprawdzone, nie do końca zrozumiane wymagania. Próbujemy stworzyć system, którego zakresu i sposobu działania jeszcze nie ustaliliśmy - zebraliśmy po prostu informacje o pożądanych właściwościach tego systemu.

 

Sytuacja ta można porównać do próby zrobienia ciasta bazując wyłącznie na liście składników, bez posiadania przepisu. Opracowanie “przepisu” na produkt wymaga zatem analizy zebranych informacji. Częścią tej analizy może być tak zwana walidacja – w prostych słowach, swego rodzaju kontrola jakości. Zebrane informacje niekoniecznie są kompletne, a także niekoniecznie odzwierciedlają rzeczywiste potrzeby interesariuszy. Celem walidacji jest sprawdzenie, czy zestaw wymagań jest wystarczająco zrozumiały, kompletny i jednoznaczny, aby być w stanie opracować na jego podstawie system. Bez walidacji może okazać się, że wymagania przekazane do realizacji są zwyczajnie niekompletne. W takiej sytuacji zespół wytwórczy, zamiast skupić się na wytworzeniu systemu, będzie zmuszony do wyjaśniania wymagań, uzupełniania brakujących informacji, często wracać z pytaniami do interesariuszy. Tym sposobem marnujemy czas zarówno zespołu wytwórczego, jak i interesariuszy biznesowych. Nie jest to zbyt profesjonalne podejście do realizacji projektów. Aby nie dopuścić do podobnych sytuacji w ramach projektów, powinniśmy przewidzieć czynności analizy i walidacji wymagań.

 

Powinniśmy również przewidzieć to, że wymagania mogą się zmienić. A jeżeli się zmienią, to może to wpłynąć na pewne aspekty planowanego produktu, ale i samego procesu wytwórczego. Zagadnieniami tymi zajmuje się proces zarządzania zmianami wymagań oraz śledzenia powiązań pomiędzy wymaganiami a innymi produktami pracy wytwórczych. Dla przykładu, zmiana jednego wymagania może spowodować konieczność zmiany lub przynajmniej rewizji innych wymagań. To z kolei może powodować konieczność zmiany architektury, kodu źródłowego, testów i tak dalej. Im większy projekt, im większy zakres, tym bardziej dojrzałego procesu do obsługi potencjalnych zmian i ich konsekwencji potrzebujemy. Brak tego procesu może powodować, że nie będziemy w stanie dostarczyć systemu na czas, lub dostarczymy lecz o kompletnie nieodpowiednim poziomie jakości.

 

Inżynieria wymagań jest więc nieodłączną częścią budowy jakiegokolwiek systemu, niezależnie od tego, czy mówimy o wytwarzaniu systemów informatycznych, budowie domu, biurowca, czy też projektowaniu usługi biznesowej – w każdym z tych obszarów ma zastosowanie inżynieria wymagań. Dziedzina ta często bywa mylona z analizą biznesową czy projektowaniem (które to obszary są bardzo mocno z inżynierią wymagań powiązane, nie są jednak synonimami), i często bywa niedoceniana. Wynika to między innymi z braku świadomości jej znaczenia i obszaru zastosowania. Warto jednak zdawać sobie sprawę z tego, że podejmując się opracowania jakiegokolwiek produktu czy usługi, albo wykonamy odpowiednie czynności inżynierii wymagań, albo godzimy się na potężne ryzyko dostarczenia produktu nie spełniającego potrzeb odbiorców.

 

 

Artykuł powstał we współpracy z Karoliną Zmitrowicz, autorką kilkunastu publikacji z obszaru zarządzania jakością, testowania, analizy biznesowej.

 

Wkrótce nakładem Wydawnictwa Helion ukażą się dwie nowe publikacje autorki:


Analiza biznesowa w IT. Lessons learned

Certyfikowany inżynier wymagań. Opracowanie na podstawie planu nauczania IREB® CPRE®. Przykładowe pytania egzaminacyjne z rozwiązaniami