Autor: Iwona Kula
Zapraszamy do kolejnej części cyklu publikacji mających na celu omówienie głównych punktów w programie certyfikacji IREB oraz wspierających przygotowanie do egzaminu certyfikacyjnego IREB CPRE. Przedmiotem tej części publikacji będą podstawowe zasady inżynierii wymagań.
IREB opracowało zestaw kluczowych zasad, które stanowią swego rodzaju wytyczne i wskazówki mające zastosowanie do wszystkich czynności zadań i działań w ramach procesu inżynier wymagań. Zasady te są uszczegółowione w kolejnych rozdziałach sylabusa Stanowią podstawę praktyk rekomendowanych przez organizację IREB.
1. Orientacja na wartość: wymagania są środkiem do osiągnięcia celu, a nie celem samym w sobie. 2. Interesariusze: IW polega na zaspokajaniu oczekiwań i potrzeb interesariuszy. 3. Wspólne zrozumienie: efektywny rozwój systemów nie jest możliwy bez wspólnego zrozumienia. 4. Kontekst: systemy nie mogą być zrozumiane w izolacji. 5. Problem – Wymaganie – Rozwiązanie: nierozłączna trójka (ang. inevitably intertwined triple) 6. Walidacja: niezwalidowane wymagania są bezużyteczne. 7. Ewolucja: zmieniające się wymagania nie są wyjątkiem, a regułą. 8. Innowacja: więcej tego samego nie wystarczy. 9. Systematyczna i zdyscyplinowana praca: nie możemy się obejść bez IW.
Wbrew obiegowym opiniom, wymagania same w sobie nie są celem, a środkiem do osiągnięcia celu. Z reguły klient nie zamawia wymagań i nie płaci za ich opracowanie. Produktem, który wnosi wartość do biznesu klienta i na którym klientowi zależy jest zazwyczaj produkt końcowy, czyli system. Inżynieria wymagań ma na celu opracowanie koncepcji tego rozwiązania, jest, więc zasadniczo niezbędna do ustalenia ostatecznego kształtu i zakresu systemu, jednakże trudno traktować produkty inżynierii wymagań, jako wartościowe z punktu widzenia klienta. Nie oznacza to oczywiście, że można zrezygnować z inżynierii wymagań i skupić się wyłącznie na budowie systemu. Oznacza to tylko tyle, że poziom szczegółowości wymagań, jak i poszczególne czynności inżynierii wymagań powinny zostać dobrane w taki sposób, żeby generować właściwą wartość przy uwzględnieniu kosztów, jakie należy ponieść na wykonywanie czynności związanych z pozyskiwaniem i obsługą wymagań.
Istnieją pewne obszary i projekty, w których inżynieria wymagań może stać się szczególnie istotna. Są to bardzo często tak zwane projekty krytyczne (dla przykładu projekty z obszaru motoryzacji lub lotnictwa), gdzie poziom ryzyka związany z wytwarzanym produktem jest tak duży, że wymagania muszą być opracowane bardzo szczegółowo, muszą spełniać określone standardy jakości, nierzadko być wyspecyfikowane zgodnie z wytycznymi wskazanymi w standardach dziedzinowych. Podobne wymagania dotyczą samego procesu inżynierii wymagań znakomitym przykładem może być wymóg tak zwanego pełnego śledzenia powiązań. Przy tego typu sytuacjach wartością inżynierii wymagań jest zapewnienie zgodności z określonymi standardami i regulacjami.
Często zapominamy o tym, że nie projektujemy systemu dla siebie, a dla kogoś. Tym kimś mogą być użytkownicy zewnętrzni reprezentujący jakiś segment rynku, pracownicy firmy zamawiającej rozwiązanie, umowny “każdy” zainteresowany produktem. Co to w praktyce oznacza? Oznacza to to, że pozyskując wymagania, analizując je, projektując system nie możemy podążać tylko i wyłącznie za własnym punktem widzenia i sugerować się wyłącznie swoim doświadczeniem i perspektywą. To interesariusze i ich potrzeby są kluczowi do zrozumienia istoty problemu biznesowego, wskazania właściwego rozwiązania i dostarczenia systemu, który spełni określone potrzeby biznesowe i umożliwi realizację wskazanych celów.
Jednym z pierwszych kroków w inżynierii wymagań powinno być określenie interesariuszy. Zarówno interesariuszy wewnętrznych, to znaczy związanej z realizacją projektu (technicznych i biznesowych), jaki zewnętrznych w stosunku do projektu.
Istnieje wiele metod i technik wspomagających określenie i analizy interesariuszy. Przykładem takiej techniki może być diagram cebuli Aleksandra. Prostsze techniki klasyfikacji interesariuszy zakładają podział interesariuszy na klasy ważności. I tak dla przykładu interesariusze krytyczni to ci, których potrzeby są na tyle istotne, że jeśli nie zostaną one zaspokojone poprzez system, system może być postrzegany jako bezwartościowy. Interesariusze określani jako ważni to ci, których potrzeby powinny być zaspokojone, jeśli natomiast któraś z nich nie zostanie zaadresowana, może to znacznie wpłynąć na użyteczność i kompletność systemu, mimo że ogólnie może on być oceniony jako akceptowalny. Natomiast, jeśli nie zostaną spełnione potrzeby interesariuszy określanych jako nieznaczni, nie będzie to miało wpływu na odbiór systemu, lub też ten wpływ będzie marginalny.
Diagram cebuli Aleksandra
Interesariusze pełnią różne role w kontekście systemu. Są użytkownicy końcowi produktu, są decydenci biznesowi, są sponsorzy, są członkowie zespołu wytwórczego. Istnieje też konkurencja, która również może być postrzegana jako interesariusze naszego projektu.
Należy pamiętać o tym, że interesariusze to jedno z głównych źródeł wymagań. Wszelkie luki w identyfikacji interesariuszy lub błędy związane z ich analizą mogą skutkować problemami z wymaganiami – na przykład pewnych wymagań może zabraknąć. Może też być sytuacja, gdzie zapominając o pewnym interesariuszu doprowadzamy do sytuacji, w których podejmujemy błędne decyzje albo biznesowe albo techniczne – ponieważ brakuje nam informacji niezbędnych do podjęcia właściwej decyzji.
Właściwa identyfikacja interesariuszy jest też ważna z tego powodu, że bardzo często potrzeby i oczekiwania interesariuszy są sprzeczne. Jest to obszar zainteresowania procesu zarządzania konfliktami wymagań, omówiony szczegółowo w dalszych częściach sylabusa.
W typowe przedsięwzięcia (w szczególności informatyczne) zwykle uwikłane są dwie strony – dostawca i klient. Każda ze stron reprezentuje pewien punkt widzenia, pewną wiedzę i kompetencje, pewne doświadczenia. Dodatkowo klient ma oczekiwania wymagania i życzenia związane z projektowanym systemem. Aby zapewnić, że dostawca jest w stanie te potrzeby i oczekiwania spełnić, konieczne jest wspólne zrozumienie.
Z jednej strony dostawca powinien rozumieć biznes, w którym klient funkcjonuje. Zrozumienie to jest niezbędne, aby prawidłowo doradzić, podpowiedzieć, jakie są możliwości rozwiązania danego problemu, zaproponować właściwe rozwiązania lub podjąć odpowiednie decyzje techniczne. Bez rozumienia biznesu, jego ograniczeń i reguł, pozyskanie właściwych wymagań i zaprojektowanie właściwego systemu jest niemalże niemożliwe. Z drugiej strony klient powinien mieć podstawową wiedzę o tym, jak wytwarzane są produkty, jak wygląda proces rozwoju systemu, jego utrzymanie, jakie są jego obowiązki jako zamawiającego w stosunku do dostawcy. Wiedza to jest niezbędna do zapewnienia prawidłowej współpracy. Obie strony powinny więc się rozumieć. Inżynieria wymagań jest w pewnym sposobem na zapewnienie tego zrozumienia. Wymagania same w sobie umożliwiają nie tylko zrozumienie i udokumentowanie tego, co potrzebuje klient, sam proces dochodzenia do wymagań to proces, w którym wymieniamy informacje, dzielimy się wiedzą i te wiedzę uzupełniamy. Przepływ wiedzy następuje w obie strony:
W sylabusie poziomu podstawowego wskazano dwa typy wspólnego zrozumienia
Niekiedy w projektach celem jest osiągnięcie praktycznego wspólnego zrozumienia – ma to miejsce zwykle w przypadku projektów mających na celu zrealizowanie ustalonego, dokładnie określonego zakresu. Wymagania stanowią swoisty kontrakt pomiędzy dostawcą a klientem. Wszystkie informacje, które są istotne do prawidłowego zaimplementowania systemu są udokumentowane w zaakceptowanej przez strony specyfikacji.
Niekiedy nie ma potrzeby tworzenia i utrzymywania dokumentacji na wysokim poziomie, ponieważ dostawca rozumie potrzeby i oczekiwania klienta. Obie strony mają do siebie zaufanie i współpracują celem stworzenia systemu. Jest to dość typowy przykład metod zwinnych bazujących na porozumieniu, bezpośredniej komunikacji i partnerstwie.
Co ciekawe, należy mieć świadomość tego, że niezależnie od podejścia do wytwarzania systemu i relacji biznesowych, obie strony mogą mieć fałszywe poczucie wspólnego zrozumienia tematu. Oznacza to, że stronom wydaje się, że się rozumieją, natomiast w praktyce może się okazać, iż mówią tym samym językiem o różnych sprawach lub każdy ma co innego na myśli. Pewnym sposobem minimalizacji ryzyka takiego zjawiska jest zastosowanie określonych środków usprawniających komunikację. Przykładem może być słownik projektowy, w którym definiujemy pojęcia mogące być różnie rozumiane przez różnych uczestników projektu. Innym przykładem może być użycie prototypowania do potwierdzenia wymagań, oceny wariantów rozwiązania, generalnie upewnienia się, czy w podobny sposób wyobrażamy sobie system.
Należy zwrócić uwagę na to, że osiągnięcie wspólnego zrozumienia może być w niektórych przypadkach znacznie utrudnione. Przykładem mogą być projekty globalne, w których zespoły rozproszone są po całym świecie, i gdzie praktycznie nie ma możliwości bezpośredniej komunikacji z członkami zespołu.
Każdy produkt, usługa czy ogólnie system istnieje w pewnym otoczeniu. Znajomość tego otoczenia ma kluczowy wpływ na możliwość stworzenia właściwego rozwiązania. Wyobraźmy sobie prosty przykład – załóżmy, że jako klient proszę dostawcę o stworzenie i dostarczenie wygodnego krzesła. Bez znajomości kontekstu dostawca nie jest w stanie określić:
Bez powyższych informacji odważny dostawca może podjąć próbę zaimplementowania krzesła, próba ta będzie jednak raczej skazana na niepowodzenie. Może się okazać, że dostarczyliśmy drewniane krzesło na wzór krzeseł użytkowanych kiedyś na uczelniach wyższych, a oczekiwaniem klienta jest wygodne miękkie profilowane krzesło- fotel do pracy z komputerem.
Przykład jest trywialny. Jednakże, jeśli przeanalizujemy sytuację na przykładach bardziej złożonych systemów, problem braku kontekstu staje się jeszcze bardziej krytyczny.
Sam kontekst systemu jest zdefiniowany następująco:
Kontekst systemu jest tą częścią środowiska systemu, która jest istotna dla zrozumienia systemu i dotyczących go wymagań.
Elementem kontekstu są interesariusze, w tym użytkownicy końcowi. W kontekście są systemy, z którymi system nasz współpracuje, są procesy biznesowe, które nasz system ma wspierać, regulacje, które obowiązują w danym obszarze biznesowym. Kontekst to nasze źródło wymagań.
Kontekst systemu
Opracowując wymagania na system korzystamy (często nieświadomie) z definicji kontekstu by wskazać właściwe źródła wymagań.
Jednym z kluczowych zadań inżynierii wymagań jest pozyskanie wymagań celem opracowanie koncepcji rozwiązania. Rozwiązaniem tym jest nasz umowny system. Zakres systemu jest zdefiniowany przez jego granicę. Granica oddziela system od kontekstu i zwykle na samym początku inżynierii wymagań jest niejasna – część wymagań będzie dopiero omawianych, części wymagań nie znamy, część wymagań może być zaklasyfikowana jako could have i dopiero na późniejszym etapie inżynierii wymagań zostanie podjęta decyzja, czy wymagania te będą w zakresie systemu, czy nie.
Granica systemu – granica pomiędzy systemem a otaczającym go kontekstem.
Co ciekawe kontekst też ma swoją granicę. Granica ta oddziela to, co ważne z punktu widzenia systemu, od środowiska, którego nie bierzemy pod uwagę podczas projektowania naszego rozwiązania.
Granica kontekstu – granica między kontekstem systemu a tymi częściami domeny aplikacji, które są nieistotne dla systemu i jego wymagań.
Pracując nad projektem systemu inżynier wymagań powinien uwzględniać nie tylko wymagania dla samego systemu, ale kontekst i jego granice. Szczególnie dlatego, że o ile możemy dyskutować i decydować o definicji systemu i jego granicy, to na kontekst, i potencjalne zmiany w kontekście nie mamy żadnego wpływu. Przykładowo nie mamy wpływu na to, czy zmieni się dany przepis, nie mamy wpływu na to czy pojawi się konkurencja i będziemy zmuszeni do zmiany strategii. Mamy natomiast wpływ na to, żeby posiadać informacje o kontekście, jak ten kontekst może nas wpływać i właściwie zarządzać wynikającym z kontekstu ryzykiem.
Przed rozpoczęciem czynności związanych z projektowaniem rozwiązania, powinniśmy zastanowić się, jaki problem biznesowy chcemy rozwiązać. Problemem jest cokolwiek, co powoduje, że interesariusze nie są zadowoleni ze stanu obecnego (AS IS). Problemem biznesowym może być to, że dany proces biznesowy trwa długo, problemem może być konieczność wykonywania pewnych czynności ręcznie, problemem może być ograniczona liczba kanałów sprzedaży. Na podstawie definicji problemu biznesowego jesteśmy w stanie określić właściwe wymagania. A na podstawie tych wymagań podejmujemy próbę znalezienia rozwiązania. Ta sekwencja problem wymagania rozwiązanie w niektórych przypadkach jest krytyczna do znalezienia właściwego rozwiązania dla właściwej potrzeby.
Rozważmy prosty przykład. Jestem konsumentem robiącym zakupy w różnych sklepach. Potencjalnemu dostawcy rozwiązań zlecam projekt mający na celu dostarczenie aplikacji mobilnej umożliwiającej dodawanie list zakupów i zarządzanie tymi listami. W tej sytuacji klient-konsument określił nie problem i nie wymagania, a rozwiązanie.
Z punktu widzenia klienta taki sposób rozumowania jest dosyć kuszący – łatwiej wyobrazić sobie konkretne rozwiązanie, niż zastanowić się, do czego to rozwiązanie miałoby być potrzebne. Z punktu widzenia dostawcy ryzkiem może być to, że bez znajomości realnego problemu biznesowego nie wiemy czy wytworzone rozwiązanie spełni pokładane w nim oczekiwania. W praktyce może się okazać, że dostarczyliśmy klientowi aplikację mobilną umożliwiającą tworzenie list zakupów i to rozwiązanie działa całkiem dobrze. Natomiast w użytkowaniu może się okazać, że realną potrzebą klienta nie jest tworzenie list zakupów, a bardziej rozsądne zarządzanie środkami finansowymi (poprzez na przykład nie kupowanie rzeczy, które już się ma lub nie kupowanie pierwszej z brzegu rzeczy, a możliwość porównania cen i wyboru sklepu, w którym oferta będzie najkorzystniejsza – co z kolei może wiązać się z możliwością robienia zakupów online.
Prawdziwy problem biznesowy może być zatem kompletnie inny, niż ten zakładany (czy raczej domniemany) na etapie tworzenia rozwiązania.
Z tego też powodu, jeżeli chcielibyśmy zapewnić, że nasze rozwiązania dostarczają realną wartość biznesową, powinniśmy najpierw zastanowić się nad problemem biznesowym, który chcemy rozwiązać, następnie określić wymagania (wszystko to, co potrzebne żeby dany problem rozwiązać), a dopiero później przejść do określenia rozwiązań.
Warto przy tym zwrócić uwagę na to, że w większości przypadków jest więcej niż jedno rozwiązanie dla danego problemu biznesowego.
Rozwiązaniem może być aplikacja mobilna porównując ceny, innym rozwiązaniem może być istniejący serwis Ceneo, jeszcze innym kompletnie poza systemowym rozwiązaniem może być opieranie się na opinii znajomych- ekspertów w dziedzinie tanich zakupów. Jedyny szkopuł w tym, że jeżeli nie wiemy, co jest problemem biznesowym, po pierwsze nie jesteśmy w stanie określić właściwych wymagań i odpowiedniego rozwiązania, po drugie nie wiemy, jakie możliwości w ogóle istnieją. Z kolei – dość typowe dla niektórych klientów – zaczynanie rozmowy od rozwiązań, może spowodować, że strony (klient i dostawca) założą, że to właśnie zdefiniowane rozwiązanie jest jedyną możliwością i nawet nie pomyślą o innych alternatywach.
Dobrą praktyką jest oddzielenie od siebie koncepcji problemu biznesowego, wymagań oraz rozwiązań. Każda z tych koncepcji dotyczy innego obszaru i ma inne znaczenie oraz cel. Celem specyfikowania problemów biznesowych jest wskazanie obszarów problematycznych, tak zwanych „bóli” (ang. Pain point). Kolokwialnie rzecz ujmując zastanawiamy się nad tym, co klienta (ogólniej interesariuszy) boli. Celem definiowania wymagań jest określenie warunków, cech, właściwości i zachowań, które umożliwią spełnienie danej potrzeby, rozwiązanie danego problemu biznesowego. Mówiąc o rozwiązaniu wskazujemy już konkretne systemy software’owe, sprzętowe, ogólnie usługowe, które będą pewnym sposobem implementacji wymagań umożliwiających nam rozwiązanie danego problemu.
Walidacja to dosyć ogólny termin związany z zarządzaniem jakością. Posługując się definicją jednego ze standardów ISO, możemy stwierdzić, że walidacja to wszystkie działania mające na celu upewnienie się, że produkt, który wytwarzamy spełnia oczekiwania odbiorców dotyczące docelowego użycia produktu. Innymi słowy upewniamy się, że stworzyliśmy właściwy produkt – właściwy to znaczy taki, który umożliwia rozwiązanie danego problemu biznesowego i spełnia oczekiwania interesariuszy.
Walidacja to potwierdzenie, przez dostarczenie dowodu obiektywnego, że zostały spełnione wymagania odnośnie konkretnego użycia lub zastosowania (PN-EN ISO 9000:2001).
O walidacji można mówić w odniesieniu do produktu końcowego, czyli systemu, ale można też – a nawet powinno się – poddawać walidacji wymagania i inne istotne z punktu widzenia procesu wytwórczego produkty pracy.
Walidacja: proces potwierdzania, że element (system, produkt pracy lub jego część) odpowiada potrzebom interesariuszy.
Wymagania są podstawą projektu systemu. Złej jakości wymagania to potężne ryzyko stworzenia złej jakości systemu. Logiczną konsekwencją tej zależności jest zatem próba zapewnienia, że wymagania są jak najlepszej jakości.
Do oceny jakości wymagań możemy użyć szeregu kryteriów jakościowych, metod i technik (jak chociażby popularne techniki przeglądu), warto jednak mieć świadomość tego, że walidacja to nie tylko kontrola spełnienia cech jakościowych, to przede wszystkim ocena zgodności produktu z oczekiwaniami i potrzebami interesariuszy.
Jeżeli na tym etapie założymy, że naszym rozważanym produktem są wymagania, to w ramach walidacji powinniśmy upewnić się, czy te wymagania są zrozumiałe przez interesariuszy, a ich treść prawidłowo reprezentuje określone potrzeby i oczekiwania. Dodatkowo powinniśmy upewnić się, że w wymaganiach uwzględnione są wszystkie istotne ograniczenia, warunki wynikające z kontekstu systemu.
Dla przykładu, wyobraźmy sobie wymaganie dotyczące możliwości wysyłki przesyłki. Załóżmy, że treść tego wymagania brzmi: “system ma umożliwiać wysłanie przesyłki”.
Na pierwszy rzut oka to wymaganie brzmi zrozumiałe. Jednak po głębszej (ale wcale nie dogłębnej) analizie możemy stwierdzić, że:
Dodatkowo nie mamy żadnych informacji dotyczących warunków granicznych i reguł biznesowych. Przykładowo nie wiemy, czy są jakieś ograniczenia dotyczące wielkości i wagi przesyłki, nie wiemy również, czy jest możliwa wysyłka krajowa przy zagraniczna, czy też może obie formy.
Takich pytań dotyczących tego jednego wymagania będzie o wiele więcej. I na tym między innymi polega walidacja wymagań – na sprawdzeniu jakości, wartości informacyjnej, ocenie czy wymaganie prawidłowo reprezentuje rzeczywistą potrzebę.
Proces walidacji jest niezbędny do upewnienia się, że idziemy w dobrym kierunku i minimalizacji ryzyka dostarczenia niewłaściwego produktu. Walidacja powinna więc być nieodłączną częścią każdego procesu wytwarzania. Dobrym przykładem sposobu zintegrowania procesów walidacji w proces wytwarzania są praktyki obecne w metodach zwinnych, jak na przykład demo przyrostu produktu, umożliwiające sprawdzenie, czy wynik prac zrealizowanych w danej interakcji spełnia oczekiwania interesariuszy. Innym przykładem skutecznej techniki walidacji, może być określanie kryteriów akceptacji dla poszczególnych wymagań. Sama próba zidentyfikowania kryteriów akceptacji już waliduje nasze rozumienie tematu i umożliwia osiągnięcie porozumienia, co do zakresu i treści wymagań.
Zmienne wymagania to utrapienie większości projektów informatycznych. Niestety zmiana jest nieodłączną częścią cyklu życia wymagań i produktów. Zmiany mogą być konsekwencją różnych zdarzeń – zarówno zdarzeń zachodzących w kontekście system (np. pojawienie się konkurencji) jak i zdarzeń związanych z samą realizacją projektu (np. zmieniające się priorytety implementacji). Najczęstsze przyczyny zmian to:
Warto zauważyć, że zmiany wymagań wynikają głównie ze zmian w kontekście. Jak już wiadomo, kontekst to podstawowe źródło wymagań i nasz punkt odniesienia umożliwiający opracowanie właściwego rozwiązania. Zmiany w kontekście z natury rzeczy, wymuszają więc potrzebę przeanalizowania dotychczasowej koncepcji na nasz system i podjęcia odpowiednich działań, w przypadku konieczności wprowadzenia zmian. Nie można faktu zmienności biznesu ignorować – odpowiedź na zmiany to nieodłączna część inżynierii wymagań. Procesowo można do tematu zmian wymagań podejść na dwa sposoby:
To pierwsze podejście jest zwykle utożsamiane z metodami zwinnymi, w których zmiana jest nieodłączną częścią projektu. Ma to zastosowanie wówczas gdy wiemy, że biznes jest zmienny, znamy pewne wymagania, natomiast spora część zakresu systemu pozostaje niewiadomym.
Drugie podejście – utrzymywanie stabilności wymagań – to zwykle domena tak zwanych projektów tradycyjnych, w których ustalony zakres wymagań stanowi kontrakt pomiędzy klientem a dostawcą.
Oba podejścia mają oczywiście swoje wady i zalety, wymagają też pewnych rozwiązań procesowych. Jest to dokładnie umówione w dalszej części sylabusa.
Zasada numer 8 związana jest z dostarczaniem wartości interesariuszom. Można oczywiście dostarczyć klientowi dokładnie to, czego chce, natomiast w tym przypadku musimy liczyć się z pewnym ryzykiem. Przytoczę tutaj jedno z dość powszechnych powiedzeń w dziedzinie IT: “to, czego klient chce, a to, czego potrzebuje, to dwie różne sprawy”. Innymi słowy, spełnienie wyrażonych oczekiwań i potrzeb klienta niekoniecznie oznacza, że dostarczone rozwiązanie będzie zaspakajało wszystkie potrzeby interesariuszy. W większości przypadków oprócz jawnych potrzeb mamy też do czynienia z potrzebami ukrytymi – te, jak sama nazwa wskazuje, mogą być w pewnym sensie nieznane, nieujawnione, lub po prostu niewyartykułowane. Przykładem może być dość częste w przypadku rozwiązań informatycznych w zagadnienie użyteczności. Zazwyczaj klient zamawiający system informatyczny przedstawia dostawcy listę różnych wymagań. Wśród tych wymagań zapewne dominującą część stanowią wymagania funkcjonalne. Wymagania jakościowe, jak zostało wyjaśnione w poprzedniej części naszego cyklu, są trudne do zidentyfikowania i do wyspecyfikowania. Mało tego, wielu klientów postrzega je jako cechy oczywiste – oczywiste przecież jest to, że system, który zamawiam powinien być łatwy w obsłudze i intuicyjny. W efekcie to wymaganie albo nie zostanie w ogóle wyspecyfikowane, albo zostanie wyspecyfikowane źle (klasyczny przykład złej jakości wymagania: “system ma być użyteczny”). W tym momencie rolą inżyniera wymagań jest rozpoznanie faktycznych potrzeb interesariuszy, być może przeanalizowanie podobnych rozwiązań i ich charakterystyk, i zaproponowanie takich wymagań, które umożliwią pokrycie tych potrzeb w jak najlepszym stopniu. W idealnej sytuacji, naszym celem jako inżynierów wymagań jest nie tylko spełnienie potrzeb interesariuszy, ale i ich przekroczenie.
Wracając do naszego przykładu – celem byłoby stworzenie systemu, który jest nie tylko po prostu użyteczny – jest na tyle intuicyjny, że użytkownicy potrafią go używać w zasadzie bez żadnych szkoleń przygotowania, a dodatkowo korzystanie z systemu budzi pozytywne doświadczenie (w tym miejscu zachęcam do zapoznania się z koncepcją User Experience).
Wprowadzenie innowacji niekoniecznie musi wiązać się z wytworzeniem totalnie nowego produktu lub podejście do tematu. Innowacją mogą też być drobne zmiany, niewymagające wielkiego wysiłku, a dostarczające wartości dodanej interesariuszom bądź biznesowi.
Przedmiotem innowacji może być nie tylko sam produkt i jego wymagania, mogą to być również procesy. Zadania i czynności inżynierii wymagań, metody i techniki – można je wykonywać tak samo, jak robią to inni, można też wprowadzić do nich zmiany, które będą powodowały, że współpraca z klientem będzie skuteczniejsza, przyjemniejsza, dodatkowo pozostawi u klienta pozytywne wspomnienia i doświadczenia.
Przekroczenie potrzeb interesariuszy ma też bardzo pragmatyczny z punktu widzenia dostawcy cel – klient zadowolony, klient zachwycony, to klient, który poleci produkt i jego twórcę innym. To klient, który prawdopodobnie wróci, jeśli będzie miał potrzebę realizacji kolejnej zmiany biznesowej. Innymi słowy – z punktu widzenia dostawcy – wprowadzając nawet drobne innowacje do systemu oraz procesów, budujemy swoją przewagę konkurencyjną.
IREB stoi na stanowisku, że inżynieria wymagań jest niezbędną częścią każdego przedsięwzięcia. Nawet w przypadku małych projektów, w których nie ma potrzeby wielkiej formalizacji, istnieją pewne czynności, które powinny zostać wykonane. W innym przypadku sami generujemy niepotrzebne ryzyka.
W dalszych rozdziałach sylabusa IREB wskazano i wyjaśniono poszczególne czynności, zadania i ich produkty pracy, techniki i metody inżynierii wymagań. Czynności te można uporządkować w ramach procesu inżynierii wymagań, narzucając pewną kolejność wykonywania zadań i powstawania artefaktów. Kolejność ta jest jednak mocno zależna od kontekstu projektowego i organizacyjnego. IREB ma w tym temacie (jak i w innych zresztą) bardzo praktyczne podejście – procesy, praktyki i standardy dostosowuje się do problemu, kontekstu i środowiska. Nie ma jednego standardu, który pasowałby wszędzie. Nie ma jednej metody, która byłaby zawsze skuteczna. W ramach inżynierii wymagań powinniśmy więc dobrać właściwy zestaw narzędzi metod i technik, aby osiągnąć nasze cele uwzględniając uwarunkowania zewnętrzne.
Podejście do interpretacji zawartości sylabusa IREB CPRE wg. Karoliny Zmitrowicz.
Program IREB daje nam wiedzę o możliwych czynnościach i metodach, od nas zależy jak tę wiedzę wykorzystamy. Dostajemy swego rodzaju narzędziownik, z którego wybieramy właściwe procesy, metody i techniki w zależności od potrzeb. Korzyścią z lektury sylabusa jest posiadanie wiedzy o różnych możliwościach – bez tej wiedzy nasze możliwości wyboru i doboru właściwej metody są bardzo mocne ograniczone.
Zapraszamy do udziału w szkoleniu, które przygotowuje do egzaminu i uzyskania certyfikatu IREB® CPRE Foundation Level (poziom podstawowy).
Zachęcamy również do zapoznania się na naszym blogu z pierwszą częścią publikacji, dotyczącą przygotowania do egzaminu IREB.
Autor: Karolina Zmitrowicz
Ekspert z kilkunastoletnim doświadczeniem w branży IT i szeroką wiedzą w zakresie procesów IT, pełni wiodącą funkcję w strukturach międzynarodowej organizacji IREB (International Requirements Engineering Board) oraz wspiera inne stowarzyszenia i organizacje branżowe. Twórca programów szkoleniowych, autor wielu publikacji książkowych.