Zapraszam do lektury 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. W tej części omówimy koncepcję inżynierii wymagań i główne pojęcia z nią związane.
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 w praktyce oznacza?
Czym jest inżynieria wymagań?
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.
Koncepcja wymagania
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, czy zapisami kontraktu.
Rodzaje wymagań
Wymagania dotyczące systemów można podzielić na kilka kategorii.
Wymagania funkcjonalne opisują, co system powinien robić, jakie usługi, zachowania dostarczy użytkownikowi. Przykładowo dla systemu Allegro wymaganiem funkcjonalnym może być możliwość wyszukiwania produktu przez użytkownika.
Kolejnym rodzajem wymagań są wymagania jakościowe. Te wymagania opisują, w jaki sposób system działa. Innymi słowy, jak system realizuje swoje funkcje. Przykładami wymagań jakościowych jest użyteczność, w szczególności intuicyjność obsługi systemu, czy wymagania wydajności, na przykład czas odpowiedzi systemu na działania użytkownika.
Ostatnim rodzajem wymagań wskazanym przez IREB są ograniczenia. Ograniczenia to specyficzne rodzaje wymagań, które ograniczają przestrzeń rozwiązania .W przypadku Allegro przykładem ograniczenia może być ograniczenie pojemności koszyka do 50 pozycji. Innymi słowy funkcjonalność dodawanie produktów do koszyka ma ograniczenie - maksymalna liczba elementów w koszyku to 50.
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, 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 w ogóle nie wyrazić. Jeśli inżynier wymagań o atrybuty jakościowe nie dopyta, 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ń.
Poziomy abstracji wymagań
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ń:
Wymagania biznesowe, które można utożsamiać z celami biznesowymi na poziomie organizacji. Przykładem wymagania biznesowego jest:
Zwiększenie przychodów ze sprzedaży o 20% w ciągu kolejnych 12 miesięcy.
Wymagania biznesowe z reguły definiuje klient.
Wymagania interesariuszy to potrzeby I życzenia określonych interesariuszy niezbędne w celu spełnienia wymagań biznesowych. Przykładami wymagań interesariuszy mogą być:
Możliwość monitorowania poziomu sprzedaży na bieżąco.
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.
Wymagania użytkowników to specyficzny rodzaj wymagań interesariuszy. Z punktu widzenia interesariusza typu użytkownik końcowy sklepu wymaganiem może być:
Możliwość szybkiego zakupu produktu Bez konieczności zakładania konta
Wymagania systemowe dotyczą stricte systemu który rozwijamy. Wymagania te możemy klasyfikować jego funkcjonalne i jakościowe. Przykładem wymagania systemowego może być:
System umożliwia użytkownikowi dodanie produktu do koszyka.
Wymagania domenowe dotyczą konkretnego obszaru biznesowego. Przykładem mogą być wymagania związane z RODO lub wymagania wynikające ze standardów obowiązujących w konkretnych branżach, jak na przykład branży motoryzacyjnej.
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.
Czynności inżynierii wymagań
Typowym zadaniem inżynieri 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 przez praktycznie cały cykl życia produktu. Procesy te są przedmiotem poszczególnych rozdziałów syllabusa IREB CPRE i będą omawiane w szczegółach w kolejnych publikacjach.
Mając już powyższą wiedzę, zastanówmy się kim wobec tego jest inżynier wymagań i jaką rolę pełni.
Rola inżyniera wymagań
Inżynier wymagań ta osoba, która zajmuje się pozyskiwaniem, dokumentacją i 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 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 nazwy stanowisk: analityk biznesowy, analityk systemowy, inżynier wymagań, analityk IT, analityk biznesowo systemowy. Zapewne lista ta nie jest pełna :)
W wielu firmach myli się znaczenie pojęć analizy biznesowej i analizy systemowej, nie mówiąc już o samej inżynierii wymagań. Pojęcia to częste stosowane są zamiennie (co w niektórych przypadkach może mieć rację bytu, w innych jest po prostu nieprawdziwe).
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.
Co warto wiedzieć o inżynierii wymagań?
Wiele rzeczy :) To poteżny obszar, obejmujący wiele procesów, metod i technik. Będziemy je systematycznie omawiać. W dalszej kolejności omówimy zasady inżynierii wymagań.
Comments