1.1. Rola wymagań w inżynierii oprogramowania

Podstawowym pojęciem inżynierii wymagań jest oczywiście „wymaganie”. Wymaganie to jako własność produktu końcowego (systemu oprogramowania), którą musi on posiadać, aby spełnić oczekiwania zamawiającego. Mówi się, że system spełnia wymagania, jeśli zostało potwierdzone, że posiada wszystkie własności określone tymi wymaganiami.

Na tej podstawie możemy również określić, czym jest inżynieria wymagań. Jest to dyscyplina inżynierii oprogramowania, która obejmuje działania polegające na zbieraniu, analizowaniu, negocjowaniu i specyfikowaniu (zapisywaniu) wymagań. Głównym produktem tej dyscypliny jest specyfikacja wymagań, która jest podstawą efektywnego kosztowo wytworzenia systemu oprogramowania zgodnego z oczekiwaniami zamawiającego.

Można powiedzieć, że jakość wymagań jest kluczowym elementem powodzenie każdego projektu konstrukcji systemu oprogramowania. Źle sformułowane wymagania są bardzo częstą przyczyną niepowodzeń. Z drugiej strony, 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. Aby zapewnić jednoznaczność i poprawność, należy stale upewniać się, że wymagania są przejrzyste dla zamawiającego, ale również – że są zrozumiałe dla deweloperów.

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. Sprzeczności często prowadzą do problemów podczas realizacji systemu.

Kolejna cecha dobrej specyfikacji wymagań to możliwość zarządzania. Wymagania powinny być podzielone na dobrze określone jednostki, które mogą sterować procesem wytwórczym. Powinny one być na tyle małe, aby można było je przydzielać do wykonania w stosunkowo krótkich odcinkach czasu (np. w ciągu jednej iteracji/sprincie). Jednocześnie, poszczególne wymagania powinny mieć przypisane  odpowiednie atrybuty pozwalające na efektywne przydzielanie ich do wykonania w trakcie projektu.

Bardzo istotną, można powiedzieć – kluczową cechą wymagań jest ich testowalność (mierzalność). Wymaganie, którego nie jesteśmy w stanie przetestować jest nic niewarte. 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, aby źródłem wymagań były osoby (zamawiający, użytkownicy) dobrze umocowane i reprezentatywne. W szczególności mogą to być kluczowi użytkownicy (np. kierownicy zespołów, doświadczeni konsultanci wewnętrzni, mentorzy) oraz kluczowi sponsorzy projektu (kierownicy wysokiego szczebla, którym zależy na powodzeniu projektu).

Bardzo istotnym składnikiem inżynierii wymagań jest zarządzanie wymaganiami. Polega na ciągłym upewnianiu się, że rozwiązujemy właściwy problem i budujemy właściwy system. Dzieje się to poprzez systematyczne podejście do: 1) zbierania, 2) organizowania, 3) dokumentowania, 4) wykorzystywania, zmieniających się wymagań na system oprogramowania. Zarządzamy wymaganiami ponieważ nie są one oczywiste i pochodzą z wielu źródeł. Poza tym, zarządzanie dotyczy różnych rodzajów wymagań oraz różnych poziomów ich szczegółowości. W typowym systemie oprogramowania możemy wyróżniać setki lub nawet tysiące wymagań, które musimy w odpowiedni sposób uporządkować. Należy również zawsze pamiętać, że wymagania podlegają ciągłym zmianom, wynikającym np. ze zmian otoczenia biznesowego lub warunków w ramach organizacji zamawiającej oprogramowanie.

Kluczowe w zarządzaniu wymaganiami jest umiejętne podzielenie całego zbioru wymagań klienta na odpowiednie jednostki, czyli pojedyncze wymagania. Każde wymaganie to jedna charakterystyka systemu, który mamy zbudować. Aby móc efektywnie zarządzać wymaganiami musimy je móc w jednoznaczny sposób identyfikować. Wymaganie powinno mieć nazwę (jedno krótkie zdanie) oraz treść (reprezentację, w postaci kilku akapitów tekstu, czy niedużego modelu graficznego). Wymagania powinny także mieć odpowiedni zbiór atrybutów, które ułatwiają zarządzanie nimi. Bardzo pomocne jest, na przykład, nadanie wymaganiom numerów identyfikacyjnych, priorytetów, czy określenie osób za nie odpowiedzialnych.

Zarządzanie wymaganiami to również zarządzanie zmianami wymagań. Jest to nieodłączny element każdego projektu. Zmiany wymagań wynikają ze zmieniających się warunków prawnych, biznesowych czy organizacyjnych. Zmiany mogą też wynikać z niezdecydowania klienta lub niezrozumienia jego potrzeb. Mogą też wynikać z polityki wewnątrz organizacji zamawiającej oprogramowanie. Niezależnie od przyczyn, należy podkreślić, że praktycznie nie istnieją nietrywialnie projekty, podczas których nie dochodzi do zmiany wymagań. Niestety, czasami nawet najmniejsza zmiana sformułowania wymagania może rodzić bardzo poważne konsekwencje dla realizowanego systemu. Dlatego też, każda zmiana wymagań powinna być traktowana z bardzo dużą uwagą.

1.2. Specyfikowanie środowiska systemu

W dzisiejszych czasach elementem niemal każdej organizacji biznesowej jest jakiś system oprogramowania. Systemy oprogramowania wspierają co najmniej część działalności przedsiębiorstw, a w wielu przypadkach są fundamentem tej działalności, jak np. w przypadku handlu elektronicznego. Różnego rodzaju organizacje i przedsiębiorstwa funkcjonujące w określonych środowiskach biznesowych również stanowią fragmenty otaczającego nas świata. Aby zrozumieć daną organizację biznesową powinniśmy stworzyć jej model.

Dokonując analizy przedsiębiorstwa, pierwszym pytaniem, na które powinniśmy odpowiedzieć jest: gdzie przebiega granica naszego biznesu? Definicję zakresu biznesu zaczynamy od definicji jego otoczenia. Otoczenie biznesu definiujemy jako zbiór wszystkich jednostek współpracujących z biznesem. Tymi jednostkami współpracującymi mogą być klienci, podwykonawcy, dostawcy podzespołów, spedytorzy, zleceniodawcy, instytucje państwa, agenci, itd. Biznes może również współpracować bezpośrednio z zewnętrznymi systemami informatycznymi.

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. Ogólna definicja określa proces jako serię wzajemnie powiązanych zadań, które przekształcają dane wejście w wyjście. Należy zwrócić uwagę na dwa aspekty wynikające z tej definicji. Pierwszy aspekt 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, 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, jak BPMN (Business Process Modeling Notation). Model czynności zawarty w języku UML posiada elementy, które są w znacznym stopniu analogiczne do elementów języka BPMN. Zaletą takiego rozwiązania jest możliwość łatwej synchronizacji modeli procesów biznesowych z innymi modelami. Na przykład, w celu określenia zakresu modelowanych procesów biznesowych możemy wykorzystać diagramy przypadków użycia. Przykładowy taki diagram widzimy na rysunku 1.1.

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

Przypadek użycia biznesu możemy opisać wykorzystując diagram czynności. Przykładowy diagram modelujący proces biznesowy „Zakup części zamiennych on-line” przedstawiony jest na rysunku 1.2.

 

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

1.3. Struktura specyfikacji wymagań – rodzaje wymagań

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.

Rysunek 1.3: Organizacja specyfikacji wymagań

Należy tutaj podkreślić, że specyfikacja wymagań nie musi (a często – nie powinna) być tworzona jako jeden gruby dokument na początku całego procesu wytwarzania oprogramowania. W metodykach iteracyjnych (zarówno zwinnych jak i sformalizowanych), 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. Z punktu widzenia struktury wymagań, taka specyfikacja powinna objąć dwie górne warstwy piramidy. 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 ma charakter bardzo ogólny 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, czyli krótki „slogan” oddający główny cel powstania produktu informatycznego.

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ę jednostek funkcjonalnych (np. przypadków użycia), definicje użytkowników i systemów zewnętrznych, słownik pojęć dziedziny wykorzystywanych podczas formułowania wymagań, istotne wymagania jakościowe oraz ograniczenia środowiskowe przyszłego systemu.

W trakcie prac na 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ć?” W szczególności, specyfikacja powinna określać m.in. usługi dostarczane przez system, sposób reakcji na komunikaty dochodzące spoza systemu, sposób zachowania w określonych sytuacjach i przy aktualnym stanie systemu. 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ć”. System może realizować wszystkie wymagania funkcjonalne, lecz nadal nie spełniać oczekiwań zamawiającego. Może np. działać zbyt wolno, być zawodny lub nie spełniać kryteriów bezpieczeństwa.

Ograniczenia środowiskowe i techniczne określają warunki narzucone budowanemu systemowi przez jego otoczenie oraz konieczne do zastosowania technologie. Ograniczenia nie są zatem wymaganiami w sensie potrzeb zamawiającego. Stanowią one wymagania w sensie narzuconych przez zamawiającego warunków, w jakich będzie tworzony i uruchamiany system. Te warunki mogą dotyczyć środowiska, w jakim będzie pracował system (np. wyposażenie stanowisk pracy, warunki pogodowe), technologii wymaganych podczas budowy sytemu (np. posiadane licencje na system bazy danych)  lub jego działania (np. posiadany przez zamawiającego sprzęt).

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ń. Definicje te wykonywane są na różnym poziomie szczegółowości. Na poziomie wizji, często wystarczy krótkie 1-2 zdaniowe wyjaśnienie znaczenia danego pojęcia. Na poziomie wymagań użytkownika konieczne jest określenie co najmniej najważniejszych atrybutów pojęć oraz wyspecyfikowanie relacji między pojęciami. Wymagania oprogramowania wprowadzają konieczność zdefiniowania wszystkich szczegółów dotyczących struktur danych, czyli stworzenie szczegółowego modelu danych.

Zbiór wszystkich wymagań stanowi specyfikację wymagań, która może być wyrażona w sposób mniej lub bardziej sformalizowany. Często wymagane jest stworzenie formalnego dokumentu, który będzie stanowił załącznik do umowy miedzy zamawiającym z wykonawcą. Przykładową strukturę takiego dokumentu specyfikacji wymagań zamawiającego przedstawia rysunek 1.4. Struktura ta jest zgodna ze strukturą dwóch górnych warstw piramidy.

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

Warunki projektu mogą również narzucać tworzenie dokumentów wymagań już po zawarciu kontraktu. Struktura takich dokumentów może być rozwinięciem struktury specyfikacji wymagań zamawiającego, przedstawionej na rysunku 1.4. 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.