1.1. Czym zajmuje się inżynieria wymagań?

Inżynieria wymagań jest jedną z podstawowych dyscyplin inżynierii oprogramowania. Dlatego też nasze rozważania warto zacząć od określenia, czym jest inżynieria oprogramowania. Ogólnie można powiedzieć, że zajmuje się ona inżynierskim podejściem do tworzenia oprogramowania. Inżynieria oprogramowania dąży do ujęcia działań związanych z budową programów komputerowych w ramy typowe dla innych dziedzin inżynierii. W niniejszym podręczniku koncentrujemy się na przedstawieniu dyscypliny, której podstawowym zadaniem jest zebranie oraz sformułowanie wymagań dla systemu oprogramowania, czyli dyscypliny inżynierii wymagań oprogramowania (w skrócie – dyscypliny wymagań).

Dyscyplina wymagań dostarcza informacji o kształcie budowanego systemu z punktu widzenia klienta (np. użytkowników). Jest to określenie dość ogólne, albowiem na kształt systemu ma wpływ wiele czynników. Główne z nich to:

·   środowisko, w którym system będzie funkcjonował,

·   zadania, które system będzie realizował,

·   sposób, w jaki system będzie funkcjonował.

Główne produkty wykorzystywane i tworzone w ramach dyscypliny wymagań to opis środowiska (np. środowiska biznesowego) i specyfikacja wymagań. Na podstawie specyfikacji wymagań, dyscyplina projektowania wytwarza zbiór modeli projektowych, a dyscyplina implementacji realizuje system. Głównym celem dyscypliny wymagań jest zatem określenie zakresu i kształtu przyszłego systemu.

Opis środowiska (biznesu) stanowi pierwszy zasadniczy produkt wykorzystywany w dyscyplinie wymagań. Jest on opisem fragmentu świata, który jest obszarem działań danej organizacji wraz z jej otoczeniem. Formułowanie takiego opisu polega na stworzeniu precyzyjnego i zrozumiałego modelu, który zawiera wszystkie elementy środowiska (biznesowego) oraz zasady oddziaływania ich na siebie.

Opis środowiska zawiera zwykle słownik pojęć (biznesowych) reprezentujący strukturę środowiska (biznesowego) oraz składniki procesów (biznesowych). Procesy biznesowe są serią powiązanych ze sobą działań, które prowadzą do osiągnięcia celu biznesowego.

Kompletna specyfikacja wymagań wynika bezpośrednio z opisu biznesu i można ją porównać do piramidy. Na samym szczycie znajduje się wizja systemu, która dostarcza informacji na temat ogólnych cech systemu w ścisłym powiązaniu z potrzebami biznesowymi klienta. Zakres sytemu wyznaczają wymagania użytkownika w postaci uporządkowanego zbioru cech i funkcji systemu, które powinny być podstawą do zawarcia kontraktu. Wizja systemu i wymagania użytkownika tworzą wymagania zamawiającego, które są odzwierciedleniem rzeczywistych potrzeb zdefiniowanych przez biznes. Na najniższym poziomie piramidy są wymagania oprogramowania, które opisują szczegóły funkcjonalne komunikacji między użytkownikami i systemem, wszystkie wymieniane między nimi dane oraz planowany wygląd systemu.

1.2. Wymagania, ich odbiorcy i reprezentacje

Podstawowym pojęciem inżynierii wymagań jest oczywiście „wymaganie”. Przed przystąpieniem do szczegółowego omawiania inżynierii wymagań musimy zatem zdefiniować to pojęcie.

Wymaganie to własność produktu końcowego (systemu oprogramowania), którą musi on posiadać, aby spełnić oczekiwania zamawiającego. Własnością tą może być określony sposób funkcjonowania systemu lub zapewnienia niezbędnej jego jakości. Mówi się, że system spełnia wymagania, jeśli zostało potwierdzone, że posiada wszystkie własności określone tymi wymaganiami.

Zgodnie z definicją, wymagania odpowiadają na najistotniejsze w całym procesie budowy oprogramowania pytanie, „jaki system mamy zbudować?” W dobrze zorganizowanym procesie wytwórczym, wymagania sterują konstrukcją systemu.

Pisząc wymagania należy pamiętać o grupach osób, które będą z nich korzystały. Możemy tu wyróżnić osoby po stronie zamawiającego (np. firma zamawiająca), jak i po stronie wykonawcy (np. firma wykonująca system).

·        Grupy osób po stronie zamawiającego:

o   Sponsorzy

o   Klienci/dostawcy (współpracownicy) zamawiającego

o   Przygotowujący przetargi

o   Użytkownicy końcowi

·        Grupy osób po stronie wykonawcy:

o   Przygotowujący oferty

o   Wykonawcy systemu (deweloperzy)

o   Przygotowujący testy akceptacyjne

o   Kierownicy projektów

Należy zauważyć, że zadanie napisania zrozumiałej dla wszystkich tych grup specyfikacji wymagań wydaje się być zadaniem karkołomnym. Wynika to z różnego przygotowania technicznego tych osób, jak i bardzo różnej wiedzy na temat budowy systemów oprogramowania. Konieczne jest zatem zastosowanie notacji, które byłyby zrozumiałe dla określonych uczestników procesu wytwarzania oprogramowania.

Notacje wykorzystywane w dyscyplinie wymagań można podzielić na tekstowe i graficzne. Najbardziej podstawową notacją (jeśli tak to można nazwać) jest wykorzystanie nieograniczonego języka naturalnego (tekst swobodny). Taka „notacja” prowadzi jednak zazwyczaj do różnych nieporozumień z uwagi na różne sposoby formułowania takich wymagań i niejednoznaczność języka naturalnego. Dlatego też powstały różnego rodzaju notacje wykorzystujące ograniczony język naturalny (tekst kontrolowany). Oprócz notacji tekstowych, dużą popularnością cieszą się notacje graficzne, a szczególnie język UML.

1.3. Klasyfikacja wymagań

Dla powodzenia projektu konstrukcji oprogramowania kluczowe jest przedstawienie zgromadzonych wymagań w systematyczny sposób, zapewniający spełnienie omówionych wyżej kryteriów jakościowych. Dobre praktyki inżynierii wymagań wskazują na potrzebę jednoznacznego podziału specyfikacji zarówno pod kątem poziomu abstrakcji (szczegółowości) wymagań jak i ich rodzaju. Dobrze zbudowana specyfikacja wymagań powinna mieć strukturę piramidy, przedstawionej na rysunku 1.3. Szczyt takiej piramidy stanowi ogólny opis systemu – jego wizja. Elementy wizji systemu stanowią punkt wyjścia do sformułowania wymagań użytkownika określających zakres budowanego systemu. Podstawą piramidy i jednocześnie jej największym fragmentem są wymagania oprogramowania, wyrażające wszystkie szczegółowe potrzeby zamawiającego. Na wszystkich poziomach piramidy formułujemy wymagania czterech rodzajów: wymagania funkcjonalne, jakościowe, słownikowe, oraz ograniczenia środowiskowe i techniczne.

Należy tutaj podkreślić, że specyfikacja wymagań nie musi być tworzona jako jeden gruby dokument na początku całego procesu wytwarzania oprogramowania. W metodykach, wymagania są zbierane i formułowane przez cały okres projektu. W wielu projektach konieczne jest jednak sformułowanie formalnej umowy między zamawiającym a wykonawcą systemu. Kluczowym elementem takiej umowy jest specyfikacja wymagań zamawiającego (np. w zamówieniach publicznych spełniająca rolę specyfikacji istotnych warunków zamówienia). Z punktu widzenia struktury wymagań, taka specyfikacja powinna objąć dwie górne warstwy piramidy (patrz rysunek 1.1).

Rysunek 1.1: Organizacja specyfikacji wymagań

W ramach wymagań zamawiającego, zamawiający przedstawia swoje rzeczywiste potrzeby związane z wspieraną przez system dziedziną swojej działalności. Jednocześnie, określa zakres systemu na tyle jednoznacznie, żeby możliwe było dokonanie wyceny budowanego systemu przez wykonawcę.

Wizja systemu jest formułowana na wysokim poziomie ogólności i nie powinna mieć charakteru wiążącego w kontaktach między zamawiającym a wykonawcą systemu. Celem jej jest sformułowanie intencji przyświecających rozwojowi systemu i wyszczególnienie problemów odkrytych w modelu biznesu zamawiającego. Kompletna wizja systemu powinna zawierać:

• opis problemu biznesowego, który jest podstawą dla powstania nowego systemu,
• przedstawienie interesariuszy powstającego systemu, czyli osób bezpośrednio i pośrednio zainteresowanych powstaniem systemu,
• ogólne cechy i funkcje systemu oraz słownik pojęć biznesowych,
• najważniejsze ograniczenia środowiskowe i techniczne przyszłego systemu,
• opcjonalnie - motto projektu.

Wymagania użytkownika definiują system w sposób na tyle szczegółowy, aby potencjalnie stanowić mniej lub bardziej formalną podstawę do kontroli postępów prac, w tym – zawarcia kontraktu na wykonanie systemu. Typowo, na wymagania użytkownika składają się wymagania funkcjonalne wyrażone przez uporządkowaną strukturę przypadków użycia systemu lub historii użytkownika, definicje aktorów (ról użytkowników), słownik pojęć wykorzystanych podczas formułowania wymagań, istotne wymagania jakościowe oraz ograniczenia środowiskowe przyszłego systemu.

W trakcie prac nad systemem, wymagania oprogramowania podlegają dokładnej specyfikacji – uszczegółowieniu. Odpowiada za to najbardziej szczegółowy poziom piramidy wymagań, czyli wymagania oprogramowania. Precyzja określenia wymagań oprogramowania powinna zapewniać jednoznaczność implementacji systemu przez zespół deweloperski. Na ich podstawie, zespół powinien móc zaprojektować i zakodować wszystkie komponenty systemu. Oznacza to, że w ramach specyfikowania wymagań oprogramowania konieczne jest szczegółowe ustalenie z zamawiającym scenariuszy zachowania systemu, wyglądu interfejsu użytkownika oraz struktury przetwarzanych przez system danych wraz z opisem algorytmów przetwarzania danych.

Na wszystkich poziomach piramidy wymagań powinien być wyraźnie zachowany podział między różnymi rodzajami wymagań. Rodzaje wymagań stanowią „kolumny” piramidy, gdyż na kolejnych poziomach stanowią jednolitą całość, opisywaną w sposób coraz bardziej szczegółowy.

Wymagania funkcjonalne określają sposób zachowania się systemu w interakcji z jednostkami na zewnątrz tego systemu – użytkownikami (ludźmi) oraz systemami zewnętrznymi. W ramach specyfikacji wymagań funkcjonalnych powinniśmy odpowiedzieć na podstawowe pytanie: „co system ma robić?” Zestaw wymagań funkcjonalnych określa zakres funkcjonalności konieczny do zrealizowania przez zespół budujący system oprogramowania.

Wymagania jakościowe inaczej nazywamy wymaganiami pozafunkcjonalnymi. Stanowią one charakterystyki systemu określające sposób oceny działania systemu. O ile wymagania funkcjonalne definiują to, „co system powinien robić”, o tyle  wymagania jakościowe definiują to, „jak system powinien coś robić”.

Bardzo istotne dla określenia wymagań jakościowych jest przedstawienie sposobu ich weryfikacji (testowania). Musimy zapewnić mierzalność wymagań jakościowych, czyli zdefiniować sposób oceny spełnienia wymagań zgodnie z możliwie najbardziej obiektywnymi kryteriami.

Ograniczenia środowiskowe i techniczne określają warunki narzucone budowanemu systemowi przez jego otoczenie oraz konieczne do zastosowania technologie. Stanowią one wymagania w sensie narzuconych przez zamawiającego warunków, w jakich będzie tworzony i uruchamiany system.

Wymagania słownikowe definiują zakres pojęć i danych, które są używane w ramach dziedziny problemu obejmującej budowany system. Słownik powinien zawierać na bieżąco aktualizowane definicje wszystkich pojęć używanych w ramach wymagań funkcjonalnych, jakościowych oraz ograniczeń. Do formułowania wymagań słownikowych możemy w najprostszym przypadku użyć formuły słownika językowego – listy pojęć z ich definicjami. Często jednak o wiele korzystniejsze jest zastosowanie notacji graficznej, np. diagramów klas języka UML.

Zbiór wszystkich wymagań stanowi specyfikację wymagań, która może być wyrażona w sposób mniej lub bardziej sformalizowany. Przykładową strukturę takiego dokumentu specyfikacji wymagań zamawiającego przedstawia rysunek 1.2. Struktura ta jest zgodna ze strukturą dwóch górnych warstw piramidy.

Rysunek 1.2: Przykładowa struktura dokumentu specyfikacji wymagań zamawiającego

Jak wiemy, wymagania zamawiającego są uszczegóławiane w ramach specyfikowania wymagań oprogramowania. Dlatego też, dokument specyfikacji wymagań oprogramowania może zawierać uszczegółowienie elementów opisujących zakres systemu.

1.4. Jakość specyfikacji wymagań

Dla powodzenia przedsięwzięcia informatycznego istotnie jest nie tylko zgromadzenie wymagań określających rozwijany system, ale także zapewnienie odpowiedniej jakości tychże wymagań. Ogólnie, można powiedzieć, że dobre sformułowanie wymagań polega na dobrym odzwierciedleniu rzeczywistych potrzeb zamawiającego. W szczególności, dobrej jakości wymagania powinny charakteryzować się kilkoma podstawowymi cechami.

Wymagania powinny być kompletne. Oznacza to, że powinny one obejmować cały zakres potrzeb zamawiającego opisany w niezbędnych szczegółach. Drugą istotną cechą wymagań jest ich jednoznaczność i poprawność. Takie wymagania powinny definiować jeden możliwy zakres systemu, i nie pozostawiać pola do różnych interpretacji. Wymagania powinny być również spójne, czyli niesprzeczne. Eliminacja sprzeczności polega na ciągłym wzajemnym porównywaniu wymagań ze sobą, szczególnie wymagań różnych rodzajów. Kolejna cecha dobrej specyfikacji wymagań to możliwość zarządzania i śledzenia. Wymagania powinny być podzielone na dobrze określone jednostki, które mogą sterować procesem wytwórczym. Łatwość zarządzania to również łatwość śledzenia produktów wynikających z wymagań. Wymagania na różnych poziomach powinny z siebie w jednoznaczny sposób wynikać. Bardzo istotną, można powiedzieć – kluczową cechą wymagań jest ich testowalność (mierzalność). Stosunkowo prosto jest sformułować testy dla wymagań funkcjonalnych. Sprawa jest trudniejsza w przypadku wymagań jakościowych. Konieczne jest opracowanie odpowiednich metryk, które pozwolą na jednoznaczne potwierdzenia spełnienia takich wymagań. Ważne jest również, aby specyfikacja wymagań była podatna na zmiany. Należy cały czas pamiętać, że zmiany wymagań są nieodłącznym elementem każdego praktycznie projektu konstrukcji oprogramowania. Należy zatem upewnić się, że specyfikacja umożliwia precyzyjne zidentyfikowanie miejsc, gdzie należy dokonać zmian w momencie zgłoszenia takich zmian przez zamawiającego.

2.1. Czynności i produkty dyscypliny wymagań

W poprzednim rozdziale zdefiniowaliśmy czym jest dyscyplina wymagań oraz określiliśmy dwa jej podstawowe produkty – opis środowiska (biznesu) oraz specyfikację wymagań. Wytwarzanie tych produktów w ramach określonych czynności wchodzi w zakres obowiązków dwóch podstawowych ról inżynierii wymagań oprogramowania – analityka biznesowego i analityka systemowego.

Podstawowe produkty pracy i czynności analityka biznesowego uwarunkowane są czynnościami będącymi w zakresie obowiązków tej roli. Podstawą do wszystkich działań jest dokonanie oceny organizacji, czego efektem jest najczęściej odpowiedni dokument. Kolejna czynnością jest identyfikacja aktorów oraz procesów biznesowych (inaczej: przypadków użycia biznesu). W jej efekcie powstaje model przypadków użycia biznesu, który zawiera opis wszystkich współpracowników danej organizacji biznesowej (ludzi, organizacje i maszyny) oraz procesów, w których oni uczestniczą. Bardzo istotną czynnością uzupełniającą jest zdefiniowanie podstawowego słownictwa biznesu.

Analityk systemowy odpowiada za pięć podstawowych produktów pracy. Najbardziej ogólnym produktem jest wizja, która obejmuje cechy systemu bezpośrednio wynikające z potrzeb biznesowych klienta. Model przypadków użycia wykorzystuje graficzną notację języka UML. Zawiera on specyfikację przypadków użycia systemu jako jednostek wymagań funkcjonalnych, aktorów (użytkowników i systemów zewnętrznych) oraz relacje między nimi. Dodatkowo, tworzone są wymagania systemowe, które definiują cechy jakościowe oraz ograniczenia. Dla wszystkich wymagań tworzony jest słownik dziedziny, który ma na celu uchwycenie terminologii dziedziny problemu oraz lepsze porozumienie w zespole deweloperskim i z klientem.

Podany powyżej zakres działań analityków nawiązuje do opisów dostarczanych przez tzw. metodyki Ujednoliconego procesu (ang. Unified Process), których prekursorem jest metodyka Rational Unified Process (RUP). Współcześnie, coraz częściej projekty stosują tzw. metodyki zwinne (ang. agile). W metodykach tych, dyscyplina wymagań zarysowana jest mniej wyraźnie.

Produkty dyscypliny wymagań pełnią bardzo istotna rolę w całym procesie wytwarzania oprogramowania. Definiują one cel projektu, jakim jest wykonanie systemu oprogramowania realizującego potrzeby klienta w określonych ramach czasowych i budżetowych. Wszystkie działania podejmowane w celu wykonania systemu oprogramowania wynikają bezpośrednio lub pośrednio z wymagań. Dla zespołu deweloperów (architekci, projektanci, programiści), wymagania są zasadniczym punktem wyjścia do zaprojektowania i implementacji systemu. Mówimy wtedy o realizacji wymagań jako synonimie realizacji systemu.

Podsumowując, należy podkreślić bardzo duży wpływ wymagań na kształt całego procesu wytwarzania oprogramowania oraz na przebieg poszczególnych jego etapów.

2.2. Wymagania w cyklu życia oprogramowania

Powiązanie dyscypliny wymagań z innymi dyscyplinami inżynierii oprogramowania może być realizowane na różne sposoby. W dobrze zorganizowanych projektach, to powiazanie przebiega zgodnie z określoną metodyką. Aby dobrze zrozumieć rolę wymagań w całym procesie konstrukcji oprogramowania, konieczne jest przedstawienie podstawowych cykli życia oprogramowania. Większość współczesnych projektów stosuje jeden z dwóch cykli wytwórczych: cykl wodospadowy (również nazywany kaskadowym) lub cykl iteracyjny.

Definicja wodospadowego cyklu życia oprogramowania, zwanego także kaskadowym lub klasycznym, została sformułowana już w roku 1970.  Główna ideą tego cyklu jest ujęcie dyscyplin wytwarzania oprogramowania w sekwencję dobrze wyodrębnionych kroków (faz lub etapów), które prowadzą do zbudowania systemu oprogramowania. Rysunek 2.1 przedstawia ogólny schemat cyklu wodospadowego. Kolejne etapy wykonywane są raz w trakcie trwania projektu i następują po sobie. Na rysunku, poszczególne etapy „wodospadu” odpowiadają dyscyplinom cyklu życia oprogramowania. Każdy etap dostarcza co najmniej jednego produktu, który podlega weryfikacji i akceptacji. Następny etap rozpoczyna się po zakończeniu poprzedniego i wykorzystuje jego produkty jako punkt wyjścia.

Rysunek 2.1: Wodospadowy cykl wytwarzania oprogramowania

Niestety, cykl wodospadowy posiada wady, które rodzą zasadnicze zagrożenia. Podstawowym problemem jest późna weryfikacja wyników prac. Problemy z realizacją wymagań klienta odkrywane są zazwyczaj dopiero w fazie testowania, a nawet dopiero w fazie wdrożenia. W cyklu wodospadowym, jakość specyfikacji wymagań możemy w pełni ocenić dopiero w fazie implementacji. Często dopiero wtedy okazuje się, że programiści nie mogą wykonać pewnych elementów kodu, gdyż brakuje dokładnej specyfikacji dziedziny problemu. Inną wadą cyklu wodospadowego jest niewielka elastyczność w radzeniu sobie ze zmianami. Bardzo trudno jest stworzyć poprawną i kompletną specyfikację wymagań już na początku projektu. Rzeczywiste potrzeby klienta są często odkrywane lub zmieniane już w trakcie trwania prac nad systemem oprogramowania.

Zagrożenia wodospadu możemy wyeliminować przez wprowadzenie wielokrotnego przechodzenia przez powiązane ze sobą dyscypliny. To podejście jest główną cechą iteracyjnego cyklu wytwarzania oprogramowania. Ilustruje to rysunek 2.2.  Jak widzimy, cykl iteracyjny zachowuje podział na dyscypliny, ale czynności w ramach wszystkich dyscyplin wykonywane są wielokrotnie.

 

Rysunek 2.2: Iteracyjny cykl wytwarzania oprogramowania

W projekcie planowane jest wiele (kilka – kilkanaście) iteracji, gdzie każda iteracja trwa zazwyczaj kilka tygodni (najczęściej od 2 do 6). Poszczególne iteracje rozpoczynają się od wyboru i wyspecyfikowania określonego zakresu wymagań, odpowiadającego przyrostowi funkcjonalności systemu. Następnie następują czynności syntetyzowania problemu – projektowanie, implementacja oraz testowane. Czynności te dotyczą zakresu wymagań wybranych do danej iteracji oraz ew. wymagań, które nie zostały prawidłowo zrealizowane w poprzednich iteracjach. Dokładnie testuje się funkcjonalność wykonaną w danej iteracji, a także przeprowadza się mniej dokładne testy funkcjonalności zrealizowanych wcześniej. Po zakończeniu testów i akceptacji ich wyników przechodzimy do kolejnej iteracji. W razie stwierdzenia błędów lub uwag od klienta, odpowiednie zadania są przydzielane do kolejnych iteracji. Po zakończeniu pewnej liczby iteracji możliwe jest wdrożenie systemu. W niektórych projektach wdrożenie wykonywane jest tylko raz – po ostatniej iteracji. Najczęściej jednak planuje się wdrożenia pośrednie. Po ostatnim wdrożeniu następuje faza konserwacji, podobnie jak w cyklu wodospadowym.

Zastosowanie cyklu iteracyjnego nie daje oczywiście gwarancji na końcowy sukces procesu wytwórczego. Zwiększa jednak szanse na jego powodzenie, przy założeniu prawidłowego stosowania jego zasad. Wszelkie problemy odkrywane są po każdej iteracji. Cykl iteracyjny pozwala na przyrostowe tworzenie systemu oprogramowania. Daje to możliwość ustalenia priorytetów dla określonych funkcjonalności systemu oraz kolejności ich wykonania i wdrożenia.

Bez względu na rodzaj przyjętego cyklu wytwarzania oprogramowania, wymagania definiują przebieg wszystkich prac związanych z dostarczeniem produktu. Istnieje jednak wyraźna różnica w podejściu do wymagań w cyklu wodospadowym i iteracyjnym, co ilustruje rysunek 2.3. Wyróżniliśmy tu trzy zasadnicze kamienie milowe – określenie potrzeb klienta, podpisanie umowy lub określenie wstępnego zakresu projektu oraz dostarczenie gotowego systemu. Jednocześnie, podzieliliśmy dyscyplinę wymagań na dwa etapy – etap wymagań zamawiającego i etap wymagań oprogramowania.

Rysunek 2.3: Wymagania w cyklu wodospadowym i iteracyjnym

Podział na dwa etapy wymagań jest zgodny z podziałem piramidy wymagań przestawionym w rozdziale 1. Wymagania zamawiającego umożliwiają stworzenie ram dla projektu, czyli jego zakresu i wynikających z niego – czasu trwania i budżetu. Wynikiem etapu wymagań zamawiającego może być np. formalna umowa (kontrakt) na wykonanie systemu lub wstępnie określony rejestr produktu. W cyklu wodospadowym, po ustaleniu ram projektu, następuje etap wymagań oprogramowania. W cyklu iteracyjnym, etap wymagań oprogramowania powtarzany jest w każdej iteracji. Warto tutaj zaznaczyć, że w cyklu iteracyjnym po każdej iteracji możliwa jest modyfikacja wymagań na poziomie wymagań zamawiającego.

Ważnym czynnikiem odróżniającym cykl wodospadowy od iteracyjnego jest sposób walidacji wymagań (testowania). W cyklu wodospadowym etap testowania przebiega pod koniec projektu, kiedy sprawdzana jest zgodność zbudowanego systemu z pełną specyfikacją wymagań. W cyklu iteracyjnym, testy systemu (aktualnego przyrostu lub wydania) odbywają się w ramach każdej iteracji.

Podsumowując warto jeszcze raz podkreślić, że cykl wodospadowy może się sprawdzić w przypadku budowy niewielkich systemów, gdzie wszystkie wymagania są znane i dobrze udokumentowane. W przypadku bardziej rozbudowanych systemów, gdzie nie wszystkie wymagania są rozpoznane, zdecydowanie należy rozważyć stosowanie cyklu iteracyjnego.

2.3. Wymagania jako podstawa zarządzania projektem

Zarządzanie wymaganiami polega na ciągłym upewnianiu się, że rozwiązujemy właściwy problem klienta, a tym samym, że budujemy właściwy system. Konieczność zarzadzania wymaganiami wynika zatem z kilku podstawowych powodów:

• Wymagania nie są oczywiste i mogą pochodzić z różnych źródeł
  
• Wymagania są różnego rodzaju i mają różny poziom szczegółowości opisu
• Wymagań jest dużo i trudno nad nimi
• Między wymaganiami i innymi produktami pracy zachodzą skomplikowane
• Wymagania mają różne właściwości
• Wymagania się zmieniają

Dla sprawnego zarządzania wymaganiami nie jest wystarczające sformułowanie samej treści wymagań. Konieczne jest wyposażenie ich w dodatkowy opis – atrybuty wymagań. Atrybuty można nazwać meta-danymi wymagań. Atrybuty nadajemy wszystkim wymaganiom, które stanowią elementy sterujące przebiegiem projektu. Typowy zbiór atrybutów wymagań obejmuje następujące elementy:

• Unikalny identyfikator
• Typ
• Waga dla klienta
• Waga dla wykonawców
• Trudność wykonania
• Status
• Wersja
• Ryzyko
• Stabilność
• Planowane wydanie
• Osoba odpowiedzialna

Atrybuty wymagania składają się na fiszkę („kartę katalogową”) wymagania. Przykładowa fiszka została przedstawiona na rysunku 2.4. Najważniejszymi atrybutami umożliwiającymi identyfikację wymagania jest identyfikator i nazwa. Atrybutami, które warunkują kolejność realizacji wymagań są wagi (klienta i wykonawcy).

ID: PU231	Nazwa: Dodanie nowego samochodu do magazynu
Wersja: 0.4	Waga klienta: ważne		Waga wykonawcy: średnie
ZATWIERDZONE	Trudność: 3	Wydanie: 12.09	Odpowiedzialny: Krzysiek
Treść: <treść wymagania zależna od rodzaju – krótki opis, scenariusze, itp.>

Rysunek 2.4: Przykładowy wzorzec fiszki wymagania

Podstawą do sprawnego zarządzania wymaganiami jest zatem identyfikacja wymagań i wyraźne ich wyróżnienie w ramach całej specyfikacji wymagań. Tak zdefiniowane wymagania podlegają procesowi zarządzania. Zarządzanie wymaganiami można podzielić na kilka aspektów, z których główne to zarządzanie zakresem, zarządzanie zmianami, utrzymywanie śladu oraz sterowanie wytwarzaniem.

Zarządzanie zakresem i zmianami można porównać do przepuszczania wymagań przez „bramkę kontroli jakości”, którą widzimy na rysunku 2.7. Każde wymaganie podlega ocenie pod kątem priorytetów, czyli przede wszystkim – wagi dla zamawiającego i wagi dla wykonawcy (trudności wykonania). Najwyższy priorytet mają oczywiście wymagania najważniejsze dla klienta oraz najtrudniejsze w realizacji. Oznacza to, że takie wymagania powinny być zrealizowane stosunkowo wcześnie w toku projektu, aby zapewnić niezbędny czas na ewentualne rozwiązywanie powstających problemów. Wymagania takie stanowią również tzw. minimalny używalny produkt (ang. Mimimum Viable Product, MVP). Oprogramowanie realizujące wymagania MVP może zostać oddane do użytku klientowi, gdyż stanowi kompletny produkt o minimalnej, lecz już użytecznej funkcjonalności.

W wyniku oceny wymagań, są one przypisywane do grup o określonych priorytetach. Jeśli projekt podlega cyklowi iteracyjnemu, to grupy te mogą odpowiadać kolejnym iteracjom projektu. Realizacja wymagania polega w pierwszej kolejności na ustaleniu wymagań szczegółowych (wymagania oprogramowania – WO), np. scenariuszy i wyglądu interfejsu użytkownika. Następnie projektowany i implementowany jest fragment systemu realizujący te wymagania (P+I). Po zaimplementowaniu, system jest testowany pod kątem zgodności z wymaganiami oraz ewentualnie wdrażany do użytku (T+W).

W trakcie projektu należy zawsze uwzględniać możliwość zmiany niektórych wymagań. Należy podkreślić, że każda zmiana wymagania powinna być kontrolowana. Próba zrealizowania zmian bez analizy konsekwencji może spowodować znaczne przekroczenie budżetu czy czasu oddania systemu do użytku. Proponowane zmiany mogą spowodować, że nie zostaną osiągnięte istotne cele biznesowe, mimo tego, że zostały spełnione wymagania niektórych interesariuszy.

Rysunek 2.5 ilustruje sposób utrzymywania śladów między wymaganiami. Ślad może być poprowadzony między wymaganiami na różnych poziomach lub na tym samym poziomie. Ważne jest, aby każde wymaganie posiadało ślad wychodzący z wymagania wyższego poziomu. Brak takiego śladu może bowiem oznaczać, że wymaganie nie jest zgodne z wizją systemu.

Rysunek 2.5: Utrzymywanie śladów między wymaganiami

Rysunek 2.6 ilustruje zasadę utrzymywania śladów dla całego produktu. Kluczowe jest tworzenie i utrzymywanie relacji między poszczególnymi wymaganiami a odpowiednimi elementami innych produktów pracy.

 

Rysunek 2.6: Utrzymywanie śladów dla całego produktu

Bardzo istotnym produktem pracy wynikającym bezpośrednio z wymagań są testy akceptacyjne. Szczegółowa specyfikacja wymagań, zawierająca np. przypadki użycia opisane scenariuszami, pozwala na łatwe utworzenie wartościowych testów tego rodzaju. Testy akceptacyjne mają za zadanie walidację spełnienia przez system wymagań z punktu widzenia użytkowników systemu. Bazują one najczęściej na odpowiadających wymaganiom funkcjonalnym (przypadkom użycia, historiom użytkownika) tzw. przypadkach testowych (ang. test case).

Tworzenie przypadków testowych polega na wykorzystaniu szczegółowych scenariuszy działania systemu, co ilustruje rysunek 2.10. Scenariusz testu akceptacyjnego tworzymy poprzez złożenie różnych scenariuszy w spójny ciąg umożliwiający sprawdzenie poprawności działania systemu. Na rysunku 2.10 widzimy przypadek testowy, który zawiera dwa testy składowe (pozytywny i negatywny) oraz plik z danymi testowymi.

Rysunek 2.10: Budowa przypadków testowych na podstawie przypadków użycia systemu

Równolegle do przygotowania testów akceptacyjnych, zespół wykonawczy wykorzystuje wymagania do sterowania wytwarzaniem systemu, to znaczy, porządkuje czynności dotyczące projektowania i implementacji systemu. W efekcie powstają takie produkty pracy jak model architektoniczny, modele projektowe i kod systemu. Podstawową trudnością jest oczywiście zapewnienie zgodności tych produktów (a szczególnie kodu) z wymaganiami.

Należy przede wszystkim zapewnić, że dysponujemy specyfikacją wymagań o odpowiedniej strukturze, np. takiej, która grupuje logicznie powiązane przypadki użycia i pojęcia słownika dziedziny. Architekci korzystają z odpowiednich heurystyk i budują model architektoniczny, np. w postaci modelu komponentów. Dodatkowo, dla każdego wymagania funkcjonalnego (przypadki użycia ze scenariuszami) architekci tworzą modele dynamiczne (np. modele interakcji). To z kolei jest podstawą do identyfikacji elementów kodu (np. klas i metod w językach obiektowych). Warto zauważyć, że coraz częstszą praktyką jest stosowanie narzędzi automatyzujących przekształcanie wymagań w kod. Takie podejście zakłada tworzenie modeli wymagań i nazywane jest wytwarzaniem oprogramowania sterowanym modelami (ang. Model Driven Software Development, MDSD). Współcześnie, automatyzacja często polega na definiowaniu graficznych modeli na poziomie wymagań i generowaniu znaczącej części logiki docelowej aplikacji. Takie podejście nazywane jest wytwarzaniem oprogramowania bez kodu (ang. no-code) lub prawie bez kodu (ang. low-code).

W wielu projektach, tworzony system oprogramowania musi być dodatkowo wyposażony w instrukcję użytkownika. Taka instrukcja może stanowić osobną dokumentację systemu bądź być wbudowana w system w formie np. modułów pomocy kontekstowej. Instrukcja obsługi powinna opisywać wszelkie znane funkcjonalności oprogramowania, gdzie oczywistym źródłem tych funkcjonalności jest specyfikacja wymagań. Dobrze wykonane scenariusze na etapie wymagań mogą pozwolić na znacznie zmniejszenie nakładu pracy potrzebnej na stworzenie podręczników użytkownika.

3.1. Specyfikowanie środowiska systemu

Aby zrozumieć daną organizację biznesową powinniśmy stworzyć jej model. Definicję zakresu biznesu zaczynamy od definicji jego otoczenia. Otoczenie biznesu definiujemy jako zbiór wszystkich jednostek współpracujących z biznesem. Jeśli skupiamy się tylko na wybranym fragmencie biznesu, otoczeniem dla niego stają się też pozostałe działy przedsiębiorstwa. Na rysunku 3.1 widzimy odpowiedni przykład. Organizacją biznesową jest firma prowadząca sieć salonów sprzedaży samochodów. Jej otoczenie stanowią klienci oraz producenci oprogramowania, a dokładniej – systemy informatyczne tych producentów (tu np.: „System firmy Opal Polska”). Otoczenie może komunikować się z firmą na trzy sposoby. Pierwszy sposób jest sposobem tradycyjnym i polega na kontaktach międzyludzkich. Drugi kanał jest kanałem elektronicznym, gdzie firma udostępnia (tu np. klientowi) odpowiedni interfejs użytkownika (GUI). Ostatni kanał jest również kanałem elektronicznym, w którym firma udostępnia zewnętrznym systemom odpowiedni interfejs programistyczny (API).

Rysunek 3.1: Określenie otoczenia biznesu oraz otoczenia systemu informatycznego

Aby opisać współpracę powinniśmy przede wszystkim zidentyfikować i opisać przebieg procesów biznesowych. Żeby zrozumieć pojęcie procesu biznesowego należy zrozumieć samo pojęcie procesu. Jego ogólna definicja określa go jako serię wzajemnie powiązanych zadań, które przekształcają dane wejście w wyjście. Należy zwrócić uwagę na dwa osobne aspekty wynikające z tej definicji. Pierwszy związany jest z samym wyróżnianiem danego procesu oraz jego potencjalnymi interakcjami z innymi procesami. Z tego punktu widzenia proces posiada wejście, wyjście oraz określone granice wyznaczające co konkretnie on obejmuje. Drugi aspekt dotyczy wewnętrznej struktury procesu. W celu jej pokazania trzeba dokładnie określić w jaki sposób tworzące go zadania są ze sobą powiązane i w jaki sposób prowadzi to do uzyskania oczekiwanego wyjścia na podstawie wejścia. Typowo w tym celu poszczególne zadania przedstawiane są w postaci sekwencji uporządkowanej w czasie. Proces biznesowy jest szczególnym rodzajem procesu, który wytwarza wartość dla jego odbiorcy. Innymi słowy wartość wyjścia z procesu jest większa niż jego wejścia z punktu widzenia danego biznesu. Podsumowując, można powiedzieć, że proces biznesowy:

• posiada jasno określone granice, wejście i wyjście,
• składa się z sekwencji uporządkowanych na przestrzeni czasu czynności,
• tworzy wartość dodaną dla określonego odbiorcy (beneficjenta procesu).

Istnieje wiele sposobów modelowania procesów biznesowych, w tym dedykowane do tego notacje. Często stosowanym podejściem jest zastosowanie języka uniwersalnego, jakim jest język UML (Unified Modeling Language). W celu określenia zakresu modelowanych procesów biznesowych możemy wykorzystać diagramy przypadków użycia. Przykładowy taki diagram widzimy na rysunku 3.2. Model ten jest analogiczny do modelu przypadków użycia systemu, który omawiamy w dalszej części podręcznika. Różnica polega na tym, że modelowanie dokonywane jest na poziomie systemu biznesowego.

Rysunek 3.2: Procesy biznesowe modelowanie jako przypadki użycia biznesu

Przypadek użycia biznesu możemy opisać w języku UML, wykorzystując diagram czynności. Przykładowy diagram modelujący proces biznesowy „Zakup części zamiennych on-line” przedstawiony jest na rysunku 3.3. Pokazuje on przebieg obsługi zakupu z punktu widzenia modelowanej organizacji, ilustrując wszystkie konieczne do tego kroki. Przedstawiamy tutaj dosyć prosty proces, gdyż szczegółowe omówienie zasad modelowania biznesu leży poza zakresem niniejszych materiałów.

 

 

Rysunek 3.3: Diagram czynności opisujący proces biznesowy

Alternatywnym sposobem zapisu procesów biznesowych jest wykorzystanie języka BPMN(Business Process Modeling Notation). Jest to specjalizowany język służący głównie definiowaniu przebiegu procesów biznesowych. Na rysunku 3.4 widzimy odpowiedni przykład.

Rysunek 3.4: Przykład procesu biznesowego zapisanego w języku BPMN

3.2. Specyfikowanie wizji systemu

Wizja systemu oprogramowania jest opisem potrzeb zamawiającego, dotyczącego systemu oprogramowania, przedstawiona na stosunkowo wysokim poziomie ogólności. Specyfikacja na poziomie wizji zbiera w jedną całość opis najważniejszych problemów będących rezultatem analizy biznesu (np. problemy dotyczące klientów firmy, określone przez dział marketingu) oraz wynikających z nich cech produktu software’owego. Wizja systemu powinna dawać przede wszystkim odpowiedzi na następujące pytania:

• Po co budujemy nowy system?
• Jakie problemy biznesu zamawiającego ten system rozwiąże?
• Dla kogo jest ten system, jakie są ograniczenia w środowisku odbiorcy systemu?
• Jakie cechy ma mieć ten system, aby pokonać zidentyfikowane problemy?

Odpowiedzi na powyższe pytania szukamy przede wszystkim poprzez analizę modelu biznesu. Dokument wizji będzie efektywny, jeśli scharakteryzuje system z różnych perspektyw, w skróconej, czytelnej i zrozumiałej dla wszystkich uczestników przedsięwzięcia formie. Wizja systemu jest przedmiotem zainteresowania we wczesnych etapach realizacji przedsięwzięcia. Na jej podstawie odkrywane są bardziej szczegółowe wymagania dotyczące zakresu, pozwalające dokładnie wyznaczyć zakres przyszłego systemu.

Wizja systemu, mimo swej ogólności, powinna posiadać konkretną strukturę. Typowo, wizja zawiera stwierdzenie problemu, opis interesariuszy (grup zainteresowanych), podstawowe cechy systemu i ograniczenia ze słownikiem pojęć, a także – niekiedy – motto definiujące zasadniczy cel budowy systemu.

Pierwszym krokiem podczas analizy zasadności budowy systemu oprogramowani powinno być zdefiniowanie problemów, które ewentualny system mógłby rozwiązać. Opis problemu możemy sformułować w postaci stwierdzenia problemu (ang. problem statement). Powinno ono odpowiadać na pytanie „dlaczego potrzebujemy nowego oprogramowania?”. Stwierdzenie problemu ma postać zwięzłego i jednoznacznego opisu, który identyfikuje zagadnienie biznesowe stawiane przed budowanym systemem a także wskazuje ogólną metodę jego rozwiązania oraz potencjalne korzyści płynące z wprowadzenia takiego rozwiązania.

Dla wyrażenia stwierdzenia problemu możemy na przykład skorzystać ze wzorca: "Problem polegający na …., dotyczący ….., którego rezultatem jest …., można rozwiązać budując system …., co spowoduje (korzyści) …." .

Kolejnym elementem wizji systemu powinna być specyfikacja interesariuszy. Interesariuszami są wszystkie te osoby, na których wdrożenie nowego systemu będzie miało bezpośredni lub pośredni wpływ. Możemy wyróżnić kilka typowych grup interesariuszy:

• Użytkownicy sytemu
• Klienci organizacji biznesowej
• Inwestorzy (np. akcjonariusze)
• Zamawiający
• Dział IT

Podobnie jak dla stwierdzenia problemu, dla opisu grup interesariuszy możemy wykorzystać wzorzec, składający się np. z następujących elementów:

• Nazwa interesariusza i typ
• Opis interesariusza
• Zakres obowiązków
• Kryteria zadowolenia
• Zadania w projekcie

Po zidentyfikowaniu problemu i interesariuszy możemy zająć się określaniem cech systemu. Cechy systemu stanowią odpowiedź na potrzeby poszczególnych grup zainteresowanych systemem. Cechy systemu określają dwa rodzaje wymagań: wymagania funkcjonalne i jakościowe.  Cechy są stwierdzeniami na wysokim poziomie abstrakcji i formułujemy je przy pomocy krótkich zdań w języku naturalnym.

Ważne jest, aby formułując cechy systemu korzystać ze słownictwa używanego przez interesariuszy. Definicje poszczególnych pojęć powinniśmy umieścić w słowniku. Słownik na poziomie wizji nie musi być rozbudowany. W słowniku (np. w porządku alfabetycznym) umieszczamy używane w definicji cech systemu pojęcia, które mogą budzić wątpliwości. Poniższy przykład ilustruje wykorzystanie słownika do wyjaśnienia pojęć występujących w opisie cech systemu.

• Cecha F007: System musi umożliwiać zarządzanie modelami samochodów.
• Cecha J023: System powinien przyspieszyć przyjmowanie samochodów na stan o co najmniej 30%.
• Model samochodu – specyfikacja obejmująca nazwę producenta i nazwę modelu (np. „Fiak Tipi” lub „Opek Astal”) oraz wszystkie parametry techniczne serii samochodów.
• Samochód – konkretny egzemplarz danego modelu samochodu, posiadający unikany numer pojazdu oraz określony zestaw dodatkowego wyposażenia.

Warto też zauważyć, że w powyższym przykładzie cechy systemu zostały oznaczone identyfikatorami. Przykładowo, cechy funkcjonalne są oznaczone identyfikatorem z przedrostkiem „F”, a cechy jakościowe – z przedrostkiem „J”.

Podczas specyfikowania wizji systemu należy również wziąć pod uwagę ograniczenia. Ograniczenie oznacza zmniejszenie stopnia swobody, którą mamy podczas tworzenia i dostarczania systemu. Można wyróżnić wiele źródeł ograniczeń: techniczne, ekonomiczne, polityczne, prawne, środowiskowe i inne.

Ostatnim, opcjonalnym lecz często użytecznym elementem wizji systemu jest motto. Motto ma postać jednego czy dwóch zdań, które prosto i efektownie prezentują korzyści płynące z realizacji projektu.

3.3. Techniki pozyskiwania wymagań

Można wyróżnić dwa podstawowe źródła pozyskiwania wymagań: dokumenty oraz ludzie. Zawsze jednak najważniejszym źródłem wymagań są ludzie, gdyż dopiero bezpośrednie rozmowy pozwalają odkryć rzeczywiste potrzeby klienta. Uzyskanie od klienta wiedzy pozwalającej na napisanie poprawnej specyfikacji wymagań nie zawsze jest proste i często wymaga zastosowania odpowiednich technik współpracy z klientem.

Zacznijmy od technik współpracy z dokumentami, które stanowią punkt wyjścia do rozmów z klientem. Wiedzę o przyszłym systemie, można czerpać m.in. z instrukcji stanowiskowych, regulaminów, istniejących podręczników użytkownika systemów odziedziczonych, a także przez analizę specyfikacji procesów biznesowych. Najbardziej podstawową techniką jest technika podkreślania pojęć. Polega na podkreślaniu fraz rzeczownikowych oraz czasownikowych w analizowanym dokumencie. Dla podkreślonych fraz szukamy definicji w tekście lub próbujemy taką definicję sformułować sami. W każdym przypadku, nazwę pojęcia oraz jego definicję uzgadniamy z klientem stosując techniki podane w dalszej części tej sekcji.

Inną technika pracy z dokumentami jest wyróżnianie wymagań. Polega ona na zaznaczaniu fragmentów tekstu, które stanowią kandydatów na wymagania. Po znalezieniu konkretnego fragmentu, zaznaczamy jego treść i dokonujemy klasyfikacji wymagania (funkcjonalne, jakościowe, definicja słownikowa, ograniczenie) zgodnie z klasyfikacją piramidy wymagań. Fragment dodatkowo uzupełniamy o atrybuty – w pierwszej kolejności nadajemy mu identyfikator. Tak zaznaczony fragment przenosimy następnie do repozytorium wymagań.

Szczególnym przypadkiem wyróżniania wymagań jest poszukiwanie opisów interakcji z użytkownikiem w dokumentacji zastanych systemów oprogramowania. Instrukcje użytkownika systemów, które będą zastępowane nowym systemem stanowią cenne źródło informacji. Analiza dokumentacji takich systemów pozwala na ustalenie, która część funkcjonalności poprzedniego systemu jest warta przeniesienia do nowego. Jednocześnie, pozwala ona na zidentyfikowanie tych funkcjonalności, które wymagają usprawnienia lub rozszerzania. Poszukujemy szczególnie scenariuszy mogących stanowić podstawę do sformułowania przyszłych przypadków użycia systemu lub historii użytkownika (patrz następne rozdziały).

Techniki pracy z dokumentami stanowią punkt wyjścia dla zastosowania technik współpracy z ludźmi. Techniki te mają na przede wszystkim na celu ustanowienie efektywnych kanałów komunikacji między klientem a wykonawcą. Muszą one zapewnić porozumienie między ekspertami w dziedzinie problemu, inżynierami oprogramowania, analitykami biznesowymi, analitykami systemowi i przyszłymi użytkownikami.

Najważniejszą i najczęściej stosowaną techniką współpracy z ludźmi jest wywiad. Jest to forma rozmowy między reprezentantem wytwórcy oprogramowania, a osobą zainteresowaną powstaniem systemu informatycznego. Celem przeprowadzenia wywiadów z klientem, podobnie, jak innych technik omawianych w tym rozdziale, jest opisanie pewnego fragmentu rzeczywistości, który ma zostać przedstawiony w specyfikacji wymagań. Rozmowa w formie wywiadu może być mniej lub bardziej sformalizowana czy ukierunkowana.

Wywiad typu sesja pytań i odpowiedzi to najbardziej elementarna forma wywiadu. Obie strony powinny być do niego przygotowane i znać wcześniej tematykę rozmowy. Osoba odpowiedzialna za zbieranie wymagań powinna przygotować listę pytań, które zostaną zadane podczas wywiadu. Od reprezentanta odbiorcy systemu wymagamy zorientowania w kontekście wywiadu. Bardzo istotnym elementem sesji pytań i odpowiedzi jest wyjaśnianie terminologii. Każde pojęcie użyte przez klienta powinno być dokładnie wyjaśnione i opisane w sposób zrozumiały dla wszystkich.

Rozwinięciem wywiadów z użytkownikami jest terminowanie (ang. tutoring). Polega ono na wspólnej pracy analityków z zamawiającymi przez okres niezbędny do zrozumienia ich zadań. Terminowanie jest jedną z najlepszych metod na poznanie sposobu działania danej dziedziny poprzez opis i analizę czynności wykonywanych przez przyszłych użytkowników systemu. Jest to również metoda najmniej kosztowna dla klienta, gdyż nie jest konieczne wydzielanie osobnego czasu na rozmowę.

O ile podczas „tradycyjnego” wywiadu osoby wcielają się w role „pytającego” i „udzielającego odpowiedzi”, to podczas terminowania role te można określić odpowiednio jako „uczeń” i „mistrz”. W przypadku inżynierii wymagań, uczeń jest reprezentantem wytwórcy oprogramowania, a mistrz jest potencjalnym przyszłym użytkownikiem systemu. Uczeń poznaje pracę mistrza poprzez obserwację wykonywanych czynności i zadawanie pytań w trakcie pracy. Pytania powinny być częste i dotyczyć wszelkich szczegółów pracy mistrza. Należy przyjąć zasadę, że każde pytanie jest „na miejscu”. Uczeń pyta: „po co to zrobiłeś?”, „jak często się to dzieje?”, „jak to uzyskać”, „a co jeśli…” itp. Pytania mają źródło w obserwacji pracy mistrza, ale powinny opierać się o wypracowany wcześniej model działania danego stanowiska pracy.

Wywiady z użytkownikami, niezależnie od ich przyjętej formy, są często jedyną metodą zbierania wymagań. Może to prowadzić do problemów, szczególnie w sytuacji, kiedy reprezentanci klienta mają różne zdanie na omawiane tematy. O wiele skuteczniejszą metodą uzgadniania sprzeczności jest praca w grupie. Takie warsztaty wymagań umożliwiają konfrontację wielu punktów widzenia wynikających z różnych kompetencji i poglądów.

Ciekawą technika pracy grupowej jest organizacja sesji JAD (ang. Joint Application Development – wspólne wytwarzanie aplikacji). Sesje takie możemy organizować podczas całego procesu wytwarzania i rozwoju oprogramowania. Tutaj skoncentrujemy się na sesjach dotyczących zbierania i dokumentowania wymagań – na różnych poziomach piramidy wymagań. Są one prowadzone w formie warsztatów, w których uczestniczą reprezentanci klienta (głównie przyszli użytkownicy systemu), oraz reprezentanci wykonawcy – analitycy wymagań. Ogólnie, w wyniku przeprowadzonych warsztatów powinien powstać uzgodniony fragment specyfikacji wymagań. Uczestnicy powinni się przede wszystkim koncentrować na uzgodnieniu wspólnego stanowiska, które znajduje odzwierciedlenie w tekście i modelach wymagań.

Format sesji JAD wymaga podziału zadań między kilka podstawowych ról:

• Sekretarz – osoba nie uczestnicząca w dyskusjach, a jedynie rejestrująca ich przebieg
• Moderator – kieruje  warsztatem – jego przebiegiem i podziałem czasu poświęcanego na konkretne punkty planu dyskusji
• Lider projektu – osoba zarządzająca zespołem rozwijającym system
• Kierownik reprezentujący sponsora – osoba na stanowisku kierowniczym z organizacji sponsora projektu
• „Zwykły” uczestnik – reprezentant zespołu klienta
• Obserwator - członek zespołu rozwijającego system

Główną korzyścią z sesji JAD jest swobodna (jednakże ukierunkowana) wymiana informacji między uczestnikami projektu. Sesje są bardzo dobrą metodą na włączenie użytkowników w formułowanie wymagań, które bezpośrednio będą się przekładać na działanie budowanego systemu. Wadami korzystania z warsztatów wymagań są dość wysokie koszty. Często problemy poruszane na warsztatach dublują tematy poruszane podczas wywiadów. W innych przypadkach materia biznesu jest zbyt skomplikowana, nawet jeśli dyskutuje się ją podczas serii kilku wielodniowych spotkań.

Na koniec omawiania technik współpracy z klientem warto wspomnieć o burzach mózgu. Jest to interesująca technika pracy grupowej, której celem jest wspomaganie procesów twórczych – zwiększenie kreatywności. Podczas takich sesji powstaje bardzo dużo pomysłów stanowiących ślepe uliczki. Jednakże, niektóre pomysły, po odpowiednim przetworzeniu czy też połączeniu z innymi mogą znacznie zwiększyć jakość wytworzonych wymagań. Uwolnienie kreatywności uczestników wspomagane jest poprzez odpowiedni format sesji: w pierwszej fazie każdy uczestnik może zgłaszać dowolne pomysły, zadawać pytania i wymieniać z innymi poglądy dotyczące danego tematu sesji. Na tym etapie istnieje zakaz wygłaszania sądów nt. stwierdzeń uczestników sesji. Druga część burzy mózgów polega na wskazaniu i ocenie przez ekspertów dziedzinowych pomysłów zgłoszonych na początku sesji.