Autor: Iwona Kula
Punktem startowym naszych rozważań będzie wyjaśnienie pojęcia inżynierii wymagań. Dyscyplina zdefiniowana jest w sylabusie IREB następująco:
Celem IW jest specyfikowanie i zarządzanie wymaganiami dla systemów w taki sposób, aby wytwarzane i wdrażane systemy spełniały oczekiwania i potrzeby interesariuszy.
Co to tak naprawdę oznacza?
Wyobraźmy sobie następującą sytuację. Żyjesz w zgiełku dużego miasta. W pewnym momencie czujesz potrzebę spokoju, być może większego kontaktu z naturą, chcesz żeby Twoje dzieci dorastały w zdrowym, spokojnym środowisku. Myślisz o wybudowaniu dla siebie i Twojej rodziny domu. Twój wymarzony dom ma być położony w pięknej i spokojnej okolicy blisko zielonych przestrzeni, idealnie rzeczki lub jeziorka, i ma wystarczać na potrzeby czteroosobowej rodziny (plus pies, względnie 10 kotów).
Czy rozpocząłbyś budowę domu mając tylko i wyłącznie powyższe informacje? Wyobrażam sobie że nie, intuicyjnie wiedziałbyś że jest zbyt dużo niedomówień i ryzyk, w tym również dość krytyczne ryzyko związane z próbą rozpoczęcia budowy domu bez ustalonego projektu, pozwoleń i innych wymagań formalnych. Budowy domu nie rozpoczniesz więc ad hoc, bo zdajesz sobie sprawę, że projekt ten jest zbyt złożony, jest cała masa czynników, które należy uwzględnić, w tym rzecz jasna ograniczenia budżetowe.
Prawdopodobnie projekt budowy swojego wymarzonego domu rozpoczniesz od inżynierii wymagań. Zapewne ustalisz wymagania interesariuszy (Twoje, członków Twojej rodziny, być może dalszych krewnych, których lubisz zapraszać na wakacje). Ustalając te wymagania zastanowisz się nie tylko nad bieżącymi potrzebami, ale i prawdopodobnie tymi, które mogą pojawić się w przyszłości (dla przykładu potrzebami dorastających dzieci, które w chwili obecnej mogą zadowolić się posiadaniem wspólnego pokoju, ale już za chwilę będą walczyć o swoją własną przestrzeń). Pewną inspiracją mogą też być dla Ciebie domy znajomych, sąsiadów, projekty znalezione w sieci. Podczas gdy Twoja wizja idealnego domu nabiera rumieńców, zdasz sobie również sprawę że oprócz wymagań interesariuszy-rodziny, musisz uwzględniać wymagania i ograniczenia pochodzące z innych źródeł – wymagania związane z prawem budowlanym, zasadami projektowania budynków mieszkalnych itp.. Zauważysz, że źródeł wymagań może być wiele.
Znając już interesariuszy i ich potrzeby, mając świadomość pewnych ograniczeń, będziesz mógł pokusić się o znalezienie rozwiązania – czyli opracowanie projektu domu, który spełni zdefiniowane wymagania.
W podobny sposób działa inżynieria wymagań w projektach informatycznych. Pierwszym krokiem jest zwykle określenie problemu biznesowego i interesariuszy, których ów problem dotyczy. Następnie powinniśmy określić potrzeby i oczekiwania tych interesariuszy (czyli wymagania), zrozumieć ograniczenia wynikające z kontekstu, dokonać analizy ryzyka. Na tej podstawie możemy zaproponować pewne rozwiązania (zwane umownie systemami), które umożliwią spełnienie potrzeb i oczekiwań interesariuszy, dostarczając im tak zwaną wartość (biznesową). Systemem może być oprogramowanie, sprzęt, usługa – zasadniczo dowolna rzecz, która spełnia stwierdzone potrzeby interesariuszy.
Jest to podstawowy cel inżynierii wymagań – opracowanie koncepcji rozwiązania spełniającego oczekiwania i potrzeby interesariuszy.
Samo pojęcie wymagania jest najczęściej zdefiniowane następująco.
Wymaganiem jest potrzeba postrzegana przez pewnego interesariusza. wymaganiem jest również właściwość, którą system powinien posiadać, aby przykładowo być zgodne z przepisami standardami zapisami kontraktu.
Wymagania dotyczące systemów można podzielić na kilka kategorii.
Powyższa klasyfikacja z reguły odnosi się do wymagań systemowych, zwanych też produktowymi, lub wymaganiami rozwiązania. Są to wymagania związane bezpośrednio z produktem który będziemy wytwarzać.
Warto zwrócić uwagę na to, że wymagania funkcjonalne są stosunkowo łatwe do pozyskania zrozumienia i opisania kropka wymagania jakościowe natomiast sprawiają więcej problemów. Pierwszym problemem może być to, że dla wielu klientów wymagania jakościowe są poniekąd oczywiste. Klient zlecający budowę systemu oczekuje, że system ten będzie szybki, łatwy w obsłudze, niezawodny itp. Cechy te mogą być dla klienta na tyle oczywiste, że może ich nawet nie wyrazić. Jeśli inżynier wymagań nie dopyta o atrybuty jakościowe, istnieje bardzo duże ryzyko, że w efekcie powstanie system, który posiada wymaganą funkcjonalność, natomiast nie spełnia wymagań jakościowych. W sytuacji ekstremalnej może to oznaczać odrzucenie systemu. Dla przykładu, wyobraźmy sobie sklep internetowy posiadający wszystkie wymagane funkcjonalności, jednak zaprojektowany w taki sposób, że użytkownik końcowy nie jest w stanie tych funkcjonalności znaleźć. Mamy więc problem z użytecznością. Jest spore ryzyko, że zdeterminowany użytkownik końcowy przez kilka minut będzie próbował znaleźć poszukiwane funkcje, w końcu podda się i skorzysta z rozwiązania konkurencji. Nie bez powodu wymagania jakościowe noszą taką a nie inną nazwę – właściwie to one determinują jakość systemu postrzeganą przez odbiorców końcowych. Z punktu widzenia celu inżynierii wymagań, jakim jest „specyfikowanie i zarządzanie wymaganiami dla systemów w taki sposób, aby wytwarzane i wdrażane systemy spełniały oczekiwania i potrzeby interesariuszy” istotne jest więc nie tylko pozyskiwanie wymagań funkcjonalnych, ale i w szczególności wymagań jakościowych oraz ograniczeń.
Nieco szerszą klasyfikacją wymagań jest klasyfikacja wymagań ze względu na poziomy abstrakcji inaczej poziomy szczegółowości. I tu IREB wyróżnia następujące typy wymagań:
Zwiększenie przychodów ze sprzedaży o 20% w ciągu kolejnych 12 miesięcy.
Wymagania biznesowe z reguły definiuje klient.
Możliwość naliczania zniżek w przypadku sprzedaży większej liczby produktów
Możliwość naliczania zniżek w przypadku klientów powracających.
Możliwość szybkiego zakupu produktu Bez konieczności zakładania konta.
System umożliwia użytkownikowi dodanie produktu do koszyka.
W typowych przypadkach wymagania biznesowe i wymagania interesariuszy definiuje Klient (zamawiający), natomiast wymagania systemowe określa dostawca rozwiązań. Bywają oczywiście odstępstwa od tej zasady, przykładowo przy długofalowej współpracy klienta z dostawcą, dostawca bardzo często bierze udział w analizach biznesowych i pomaga klientowi określić wymagania na poziomie biznesu.
Upraszając powyższą klasyfikację wymagań, można stwierdzić, że wymagania biznesowe i interesariusze, opisują obszar problemu biznesowego, a wymagania systemowe dotyczą obszaru rozwiązania (czyli opisują w jaki sposób system będzie działał). Wymagania domenowe mogą dotyczyć zarówno poziomu biznesowego, jak i poziomu rozwiązania.
Typowym zadaniem inżyniera wymagań jest pozyskiwanie wymagań, następnie ich analiza (w tym poszukiwanie i zrozumienie zależności i powiązań), identyfikacja i usuwanie konfliktów (sprzeczności), walidacja wymagań, czyli w uproszczeniu sprawdzanie ich jakości, dokumentowanie wymagań na różne sposoby, zarządzanie wymaganiami. Czynności te występują w różnych konfiguracjach. przykładowo pozyskiwanie wymagań może obejmować elementy analizy wymagań i dokumentacji. Dokumentacja wymagań w postaci modelu często angażuje czynności walidacji. Proces zarządzania wymaganiami Jest procesem który trwa podczas całego cyklu życia produktu. Procesy te są przedmiotem poszczególnych rozdziałów syllabusa IREB CPRE.
Mając już powyższą wiedzę, zastanówmy się kim wobec tego jest inżynier wymagań i jaką pełni rolę.
Inżynier wymagań to osoba, która zajmuje się pozyskiwaniem dokumentacją zarządzaniem wymaganiami. W projektach rolę inżyniera wymagań mogą pełnić analitycy, projektanci, czasami kierownicy projektów. Inżynierię wymagań może zatem wykonywać osoba, piastująca stanowisko o zupełnie innej nazwie. Warto przy tym wspomnieć że na rynku IT, niestety panuje dosyć duży chaos jeśli chodzi o nazewnictwo ról związane z szeroko pojętą analizą.
W ogłoszeniach o pracę można natknąć się na następujące nazwę stanowisk: analityk biznesowy, analityk systemowy, inżynier wymagań, analityk IT, analityk biznesowo systemowy i inne.
Analityk biznesowy zajmuje się o wiele szerszym obszarem, niż inżynieria wymagań. Pomaga on określić potrzeby biznesowe w danej organizacji, zaproponować rozwiązania dla problemów biznesowych, wspiera dostarczenie tego rozwiązania i ocenia dostarczoną wartość biznesową. Działa na poziomie biznesu. Jego obszar zainteresowania, umownie rozpoczyna się od momentu rozpoznania problemu biznesowego i zidentyfikowaniu potrzeb, a kończy na wdrożeniu wartości biznesowej (w uproszczeniu – na wdrażaniu i ocenie rozwiązania). Szczegółowe wyjaśnienie roli analityka biznesowego można znaleźć w BABOK Guide. Analityk systemowy z kolei zajmuje się projektowaniem systemu na poziomie funkcjonalnym, czasami integracyjnym. Obie rolę wykonują do pewnego stopnia czynności inżynierii wymagań. Różnica polega na tym, że o ile analityk biznesowy zajmuje się głównie wymaganiami biznesowymi i wymaganiami interesariuszy, analityk systemowy działa w obszarze wymagań systemu, na skraju projektu technicznego.
Inżynier wymagań jest zatem ogólnym określeniem roli zajmującej się pozyskiwaniem, analizą i zarządzaniem wymaganiami. W zależności od tego, czy mówimy o wymaganiach na poziomie biznesowym, czy na poziomie rozwiązania, inżynier wymagań może nosić nazwę analityk biznesowy lub systemowy.
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.