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.