Metody zbierania wymagań

Posiadanie przekrojowej wiedzy z zakresu inżynierii wymagań stanowi bar-dzo ważny czynnik umożliwiający inżynierom wymagań / analitykom

skutecz-Zarządza nie   Odkrywa

nie  

Analiza  

Dokumen towanie   Wery7ika

cja   Walidacja  

Znaczenie identyfikacji wymagań dla realizacji systemów teleinformatycznych… 83 ne określanie zakresu i istotnych właściwości tworzonego systemu wsparcia teleinformatycznego. Interesariusze reprezentujący różne szczeble w ramach podmiotów tworzących organizację federacyjną, którzy są zaangażowani w budowę systemu, często w odmienny sposób rozumieją i komunikują swoje problemy. Powoduje to konieczność wypracowania najlepszego dla danej orga-nizacji podejścia do opracowywania wymagań oraz umiejętnego doboru wła-ściwych metod, które będą wykorzystane do pracy z różnymi interesariuszami i dopasowane do ich poziomu. Przyczynia się to również do aktywnego prze-ciwdziałania niektórym z problemów opisanych w punkcie 3.3 niniejszego opracowania. Oprócz interesariuszy reprezentujących ludzi, źródło wymagań mogą stanowić również elementy środowiska organizacyjnego i legislacyjnego organizacji federacyjnej, w którym osadzony będzie system teleinformatyczny.

Ponadto należy pamiętać, że kontekst i otoczenie budowanego systemu będą zmieniać się w czasie zgodnie z naturą funkcjonowania i rozwoju tego typu organizacji. Również inżynierowie wymagań / analitycy posiadają różną wiedzę i doświadczenie w dziedzinie inżynierii wymagań, które ewoluują w czasie.

Wszystko to powoduje, że budowy złożonych systemów wsparcia teleinforma-tycznego nie sposób opierać na wykorzystaniu do opracowywania wymagań jednej metody ogólnego przeznaczenia i przeprowadzeniu z jej użyciem poje-dynczej sesji wymagań. Dlatego opracowywanie wymagań opiera się najczę-ściej na przeprowadzeniu szeregu takich sesji, które odbywają się równolegle lub sekwencyjnie. Podczas każdej z nich stosowana jest metoda lub zbiór metod dopasowane do źródła wymagań, uczestników i kontekstu danej sesji. Sesje te powtarzane są aż do momentu uzyskania konsensusu w drodze uzgodnienia i poprawnego udokumentowania wymaganych funkcji i właściwości oczekiwa-nych od systemu. Syntetyczny przegląd spotykaoczekiwa-nych w praktyce procesów opracowywania wymagań został przedstawiony w poniższej tabeli (Tabela 3.1).

Tabela 3.1. Procesy opracowywania wymagań.

Proces Charakterystyka Zastosowanie

Liniowy Proces ten odznacza się małą złożonością

i składa się z sekwencji pięciu aktywności: koncep-tualizacja problemu, analiza problemu, studium wykonalności i wybór opcji, analiza

i modelowanie, dokumentowanie wymagań.

Małe przedsię-wzięcia

Liniowo-iteracyjny

Proces ten kładzie nacisk na dostarczenie dokład-nych specyfikacji wymagań i zakłada ich wielo-krotną walidację przez interesariuszy. Składa się on z czterech aktywności tj. wydobywania, analizy i

Średnie przedsię-wzięcia

84 Inżynieria oprogramowania – badania i praktyka

Proces Charakterystyka Zastosowanie

negocjowania, dokumentowania i walidacji wyma-gań. Aktywności te często nachodzą na siebie i są realizowane w iteracjach, jednak wymagania nadal podlegają liniowym przekształceniom. Pro-ces trwa aż do uzyskania ostatecznej akceptacji wymagań przez interesariuszy.

Iteracyjny Proces ten zawiera aktywności podobne do tych, które istnieją w wyżej wymienionych procesach, lecz sam posiada iteracyjny i cykliczny charakter.

W procesie tym występują interakcje pomiędzy działaniami związanymi z wydobywaniem, specy-fikowaniem i walidacją wymagań oraz użytkowni-kiem i dziedziną problemową. Ponadto działania realizowane są nieliniowo i zakłada się pomiędzy nimi istnienie silnych związków

Spiralny Proces ten wykonywany jest w cyklach, gdzie każdy kolejny przebieg dostarcza pełną wersję wymagań, na podstawie których powinien zostać zbudowany system. Każda spirala jest dodatkowo podzielona na cztery ćwiartki tj. wydobycie, anali-zę i negocjację, dokumentowanie i walidację wy-magań. Proces ten jest w stanie zaadresować poja-wiające się zagrożenia, mogące zwiększyć koszty projektu i obniżyć jakość dostarczanego produktu, takie jak np. opóźnienia w specyfikowaniu wyma-gań, zmiany wymawyma-gań, niski ROI itp.

Duże i złożone przedsięwzięcia

Należy podkreślić, że w rzeczywistości dość rzadko spotyka się implementa-cję opisanych powyżej procesów opracowywania wymagań w ich modelowej formie. Najczęściej jeżeli formalne procesy są w ogóle stosowane w organiza-cjach o charakterze federacyjnym podejmujących inicjatywy związane z budo-wą systemów teleinformatycznych, to mają one tendencję do traktowania stan-dardowych procesów jako zbioru najlepszych praktyk, adaptowanych lokalnie na potrzeby danej organizacji.

W ramach procesów opracowywania wymagań można zastosować metody związane z odkrywaniem wymagań należące do kilku kategorii. Najczęściej występujący w literaturze przedmiotu podział wyróżnia następujące grupy me-tod:

Znaczenie identyfikacji wymagań dla realizacji systemów teleinformatycznych… 85

‒ klasyczne (ang. classic / traditional),

‒ poznawcze (ang. cognitive),

‒ kontekstowe (ang. contextual),

‒ współczesne (ang. modern).

Zostały one przedstawione w syntetyczny sposób w poniższej tabeli 3.2.

Tabela 3.2. Katalog metod odkrywania wymagań.

Metoda

Grupa metod

Klasyczne Poznawcze Kognitywne Współczesne

analiza domeny (ang. domain analysis) +

analiza reguł postępowania (ang. protocol analysis) +

analiza zadań (ang. task analysis) +

analizy społecznej (ang. social analysis) +

badania ankietowe (ang. surveys) +

burze mózgów (ang. brainstorming) +

CRC (ang. Class-Responsibility-Collaboration) +

drabiny znaczeniowej (ang. laddering) +

etnograficzną (ang. etnography) +

introspekcja (ang. introspection) +

praca grupowa (ang. group work) +

prototypowanie (ang. prototyping) +

przypadki użycia (ang. use cases) +

Rep-Test (ang. repertory grids) +

scenariusze (ang. scenarios) +

sesje JAD (ang. joint application development sessions) +

sortowanie kart (ang. card sorting) +

sytuowany wywiad środowiskowy (ang. contextual inquiry) + warsztaty wymagań (ang. requirements workshops) +

wywiady (ang. interviews) +

86 Inżynieria oprogramowania – badania i praktyka

Na wstępie niniejszego punktu przedstawiono powody, dla których budowa złożonych systemów teleinformatycznych dedykowanych wspomaganiu funk-cjonowania organizacji o charakterze federacyjnym nie może opierać się na wykorzystaniu do opracowywania wymagań pojedynczej metody odkrywania wymagań. Rodzi to pytanie w jaki sposób analitycy mają dokonać wyboru wła-ściwych metod, które umożliwią im uzyskanie spójnego zbioru rzeczywistych wymagań na dany system ICT, odwzorowującego potrzeby różnych interesariu-szy. Niestety literatura przedmiotu nie dostarcza jednoznacznych odpowiedzi na to pytanie. Praktyka inżynierii wymagań wskazuje za to, że najlepsze efekty uzyskuje się dzięki łączeniu omówionych metod w taki sposób, aby uwzględ-niał on cel ich zastosowania, posiadane informacje dotyczące dziedziny pro-blemowej, istniejące wymagania i ich jakość, dostępność interesariuszy. Ogólną strategię doboru metod na tej podstawie przedstawiono na poniższym rysunku (Rysunek 3.4).

Rysunek 3.4. Ogólna strategia wyboru metod odkrywania wymagań.

Znaczenie identyfikacji wymagań dla realizacji systemów teleinformatycznych… 87 3.2.5 Metody oceny ważności wymagań

Decyzja o wyborze spośród zidentyfikowanych wymagań tych, które mają zostać zrealizowane w systemie wsparcia teleinformatycznego SBN RP jest jednym z najbardziej krytycznych rozstrzygnięć mającym wpływ na powodze-nie całego przedsięwzięcia. Systemy wsparcia teleinformatycznego SBN RP, tworzone zarówno w Polsce jak i na świecie, są z reguły rozwiązaniami o dużej złożoności, zakresie funkcjonalnym i terytorialnym, w których budowę zaanga-żowanych jest wielu interesariuszy. Sytuacja ta rodzi szereg problemów zwią-zanych z ustaleniem wymagań mających znaczenie dla SBN RP jako całości, a nie tylko dla interesów ograniczonej grupy interesariuszy (np. pojedynczych ministrów, kierowników jednostek administracji rządowej i samorządowej, szefów służb itd.). W związku z tym w fazie analizy wymagań niezbędne jest podjęcie odpowiednich działań mających na celu ustalenie ich istotności oraz wyeliminowanie konfliktów pomiędzy nimi i optymalizację pod kątem korzyści uzyskiwanych z wdrożenia systemu. Działania te powinny zostać przeprowa-dzone z punktu widzenia SBN RP rozumianego jako jednej organizacji i obej-mują [YE92, WI03, SS97, KO97]:

‒ wsparcie interesariuszy w wyborze głównych wymagań dla systemu;

‒ opracowanie uporządkowanej listy reprezentującej optymalny zbiór wymagań funkcjonalnych planowanych do zrealizowania w kolejnych wydaniach systemu;

‒ uzyskanie kompromisu dotyczącego wymagań wchodzących w zakres projektu względem ograniczeń takich jak: harmonogram, budżet, zasoby i jakość;

‒ zrównoważenie korzyści z każdego wymagania włączonego do realizacji względem kosztów jego implementacji.

‒ zrównoważenie oddziaływania wymagań wybranych do realizacji na ar-chitekturę oprogramowania i jego przyszły rozwój oraz związane z tym koszty.

‒ oszacowanie oczekiwanej satysfakcji interesariuszy i włączenie do reali-zacji tylko tej część wymagań pozwalających stworzyć system spełnia-jący ich oczekiwania, który będzie przydatny w realizacji określonych celów w ramach SBN RP;

‒ uzyskanie przewagi względem dotychczas eksploatowanych rozwiązań technicznych;

‒ zminimalizowanie kosztów związanych z koniecznością wprowadzania poprawek wynikających z błędnego wyboru wymagań przeznaczonych do implementacji oraz zmaksymalizowanie stabilność planów budowy systemu;

88 Inżynieria oprogramowania – badania i praktyka

‒ obsługę sprzecznych wymagań w procesie ich negocjacji i rozwiązywa-nia nieporozumień pomiędzy interesariuszami;

‒ ustalenia istotności każdego wymagania, aby budowany system dostar-czał największej wartości przy najniższych kosztach jego opracowania.

Powyższa lista pokazuje jak istotne jest znaczenie ustalania priorytetów wymagań i podejmowania decyzji o tym, które z nich zostaną zaimplemento-wane w systemie wsparcia teleinformatycznego SBN RP. Ruhe podsumowuje to następująco: "wyzwaniem jest, aby wybrać właściwe wymagania z początko-wego zbioru wymagań kandydujących tak, aby spełnione zostały różne kluczowe interesy, ograniczenia techniczne i preferencje krytycznych interesariuszy, a ogólna wartość produktu była zmaksymalizowana" [RE02]. Niektórzy współ-cześni autorzy uważają, że proces nadawania priorytetów wymaganiom jest trywialny [SS97], inni z kolei traktują go jako zadanie o średniej trudności [WI03], a część uważa za jedno z najbardziej złożonych działań w inżynierii wymagań [LP93]. Jednak wszyscy z nich uważają prawidłowe nadanie prioryte-tów wymagań za zasadniczą aktywność przekładającą się bezpośrednio na osta-teczny sukces projektu. Jednocześnie niektóre podręczniki dotyczące inżynierii wymagań nie podnoszą tej kwestii w jakimkolwiek stopniu [RR02].

Dotychczas opisano wiele metod umożliwiających ustalenia priorytetów po-szczególnych obiektów w zbiorze. Celem każdej z tych metod jest przypisanie do poszczególnych obiektów wartości, które pozwalają na ustalenie relacji po-rządkujących między nimi. W przypadku rozważań będących przedmiotem niniejszego punktu, obiektami tymi są wymagania. Priorytety wymagań mogą zostać określone przy użyciu różnych metod i skal pomiarowych. Poniżej wy-mienione zostały najczęściej przywoływane w literaturze metody ustalania prio-rytetów:

‒ metoda AHP;

‒ binarne drzewo poszukiwań;

‒ metoda grupowania;

‒ metoda rankingowania;

‒ głosowanie kumulatywne;

‒ metoda dziesięciu głównych wymagań;

‒ metoda QFD;

‒ zaadaptowany model CAPM;

‒ metoda DCPT;

‒ metoda EVOLVE;

‒ metoda Cost-Value;

‒ metoda Quantitative Win-Win;

Część z wymienionych wyżej metod zakłada, że każde wymaganie ma przy-pisany pewien priorytet, natomiast inna część grupuje wymagania ze względu

Znaczenie identyfikacji wymagań dla realizacji systemów teleinformatycznych… 89 na ich istotność. Metody te w większości nie uwzględniają podejścia grupowe-go do podejmowania decyzji, ani siły głosu poszczególnych interesariuszy.

Abstrahują one również od aspektów związanych z zależnościami pomiędzy wymaganiami a kosztami, wartością, ludźmi i ich kompetencjami, aspektami technicznymi itd. Wyjątek stanowią metody DCPT, EVOLVE, Cost-Value oraz Quantitative Win-Win, które stanowią próbę uwzględnienia bardziej złożonych, wieloaspektowych zagadnień w obszarze ustalania priorytetów wymagań intere-sariuszy. Na polskim gruncie badań dotyczących tego obszaru ciekawą alterna-tywę do tych metod zaproponował Sobczak w postaci Techniki Wielopłaszczy-znowej Priorytetyzacji Wymagań (TWPW). Metoda ta integruje zagadnienia technologiczne, organizacyjne oraz ekonomiczne i oparta jest o koncepcję stra-tegicznej karty wyników (ang. balanced scorecard) Kaplana-Nortona[SA05].

3.3 Praktyczne problemy związane z inżynierią wymagań w organizacjach