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.