2.1. Specyfikowanie wizji systemu

Wizja systemu stanowi ona opis potrzeb zamawiającego w stosunku do potencjalnego systemu oprogramowania, wykonany na stosunkowo wysokim poziomie ogólności. Wizja systemu powinna dawać przede wszystkim odpowiedzi na następujące pytania:

• Po co budujemy nowy system?
• Jakie problemy naszego biznesu ten system rozwiąże?
• Dla kogo jest ten system?
• Jakie cechy ma mieć ten system, aby pokonać zidentyfikowane problemy?

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

Pierwszym krokiem podczas analizy zasadności budowy systemu oprogramowania 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?”.

Dla wyrażenia stwierdzenia problemu możemy 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 (ang. stakeholder). 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żytkowników systemu, klientów organizacji biznesowej, zamawiających, dział IT. Podobnie jak dla stwierdzenia problemu, dla opisu grup interesariuszy możemy wykorzystać wzorzec. Wzorzec może się składać z: nazwy interesariusza i typu, opisu interesariusza, zakresu obowiązków, kryteriów zadowolenia, zadań 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. Na cechy systemu składają się dwa zasadnicze rodzaje wymagań: cechy funkcjonalne i cechy jakościowe. Cechy są stwierdzeniami na stosunkowo wysokim poziomie ogólności, 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. 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.

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”. Identyfikator jest przykładem atrybutu wymagania. Zbiór atrybutów wymagań może obejmować na przykład następujące elementy: unikalny identyfikator, typ, status, waga dla zamawiającego, trudność wykonania, ryzyko, stabilność , osoba odpowiedzialna.

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.

2.2. Specyfikowanie wymagań użytkownika

Po podjęciu decyzji o budowie systemu powinniśmy określić jego zakres, a w ramach tego – zdefiniować jednostki wymagań, które umożliwią efektywne zarządzanie projektem. Specyfikacja wymagań użytkownika powinna dostarczyć odpowiedzi na kluczowe w procesie zarządzania projektem pytania.

• Jak obszerna będzie funkcjonalność systemu?
• Jakie dane będzie przetwarzał system?
• Kto będzie się posługiwał systemem?
• Ile system będzie kosztował i jak długo będzie trwała jego budowa?

Podstawowym założeniem dla przeprowadzenia analizy pod kątem wymagań użytkownika jest zgodność z wizją systemu oraz procesami biznesowymi. Ilustrację tej zasady widzimy na rysunku 2.1. Na podstawie procesu biznesowego zostało określone wymaganie funkcjonalne F098 na poziomie wizji systemu. W wyniku wywiadów oraz spotkań warsztatowych z klientem, wymaganie to zostało uszczegółowione poprzez ustanowienie trzech przypadków użycia (PU030, PU032 i PU033). Analogicznie, uszczegółowieniu podlegają wymagania jakościowe. W przykładzie na rysunku 2.1 widzimy, że ogólna cecha jakościowa J022 została uszczegółowiona w postaci wymagań J022-1 i J022-2.

Rysunek 2.1: Identyfikacja wymagań użytkownika na podstawie wizji i procesów biznesowych

Zidentyfikowane wymagania użytkownika dokumentujemy, aby mogły się stać podstawą do zawarcia kontraktu (mniej lub bardziej formalnej umowy) między zamawiającym a wykonawcą systemu, w tym - do określenia zasobów niezbędnych do realizacji systemu. Wymagania użytkownika powinny być zatem na tyle precyzyjne, aby nie było niedomówień co do zakresu systemu. Jednocześnie, powinny być na tyle ogólne, aby nie sugerować rozwiązań technicznych (dotyczących np. implementacji interfejsu użytkownika, baz danych, itp.), co jest dopiero zadaniem projektantów systemu.

Jednym z najczęściej spotykanych sposobów zapisu wymagań funkcjonalnych są przypadki użycia systemu. Punktem wyjścia do stworzenia modelu powinna być analiza cech systemu sformułowanych w wizji oraz analiza procesów biznesowych. Dla typowego systemu oprogramowania, model taki zawiera od kilkudziesięciu do nawet kilkuset przypadków użycia. W takiej sytuacji, konieczne jest umiejętne zarządzanie złożonością modelu. Podstawową techniką jest tutaj grupowanie w pakiety po kilka-kilkanaście przypadków użycia. Dla każdego pakietu tworzymy osobny diagram (czasami korzystne jest utworzenie dwóch-trzech diagramów). Na rysunkach 2.2 i 2.3 przedstawione są dwa przykładowe diagramy dla systemu obsługi sprzedaży samochodów.

 

Rysunek 2.2: Przykładowe przypadki użycia dla systemu sprzedaży samochodów

Rysunek 2.3: Przykład przypadków użycia realizujących operacje CRUD

Alternatywnym do przypadków użycia sposobem formułowania wymagań funkcjonalnych są historie użytkownika. Historie użytkownika opisują oczekiwania klienta w stosunku do tworzonego systemu za pomocą krótkich zdań mieszczących się np. na kartkach z notesu. Zdanie stanowiące historię użytkownika powinno określać podmiot historii (użytkownik, który czegoś chce od systemu), cel biznesowy realizowany przez system i oczekiwany przez użytkownika, oraz motywację klienta stojącą za konkretnym oczekiwaniem. Do formułowania historii użytkownika można wykorzystać następujący prosty wzorzec:

• Jako <rodzaj użytkownika> chcę <jakiś cel>, aby <jakiś powód>

Kilka przykładowych historii użytkownika dla wcześniej przedstawionej wizji, napisanych zgodnie z powyższym wzorcem przedstawia rysunek 2.4.

Rysunek 2.4: Przykłady historii użytkownika

Drugim kluczowym składnikiem specyfikacji wymagań zamawiającego jest specyfikacja wymagań jakościowych, inaczej nazywanych wymaganiami pozafunkcjonalnymi. Bardzo istotne jest, aby zapewnić kompletność i jednoznaczność tego rodzaju wymagań. Kontrolę kompletności może nam zapewnić zachowanie zgodności z określoną taksonomią wymagań jakościowych. Istnieje wiele takich taksonomii, przy czym tutaj przestawimy chyba najbardziej szczegółową i wyczerpującą z nich, zawartą w normie ISO/IEC 25010:2011. Model jakości opisany w normie ISO 25010 zawiera następujący podział rodzajów wymagań jakościowych:

• Przydatność funkcjonalna (ang. Functional suitability) – dotyczy spełniania przez system wyrażonych wcześniej potrzeb.
• Efektywność wydajnościowa (ang. Performance efficiency) – dotyczy wydajności osiąganej przez system przy założonych zasobach.
• Kompatybilność (ang. Compatibility) – dotyczy współpracy z innymi systemami oprogramowania.
• Użyteczność (ang. Usability) – dotyczy dostosowania sposobu użycia systemu do potrzeb użytkowników.
• Niezawodność (ang. Reliability) – dotyczy zapewnienia określonego poziomu działania systemu przy założonych zasobach.
• Bezpieczeństwo (ang. Security) – dotyczy ochrony danych przez system.
• Łatwość utrzymania (ang. Maintainability) – dotyczy minimalizacji nakładów pracy wymaganych podczas utrzymywania systemu w eksploatacji.
• Przenośność (ang. Portability) – dotyczy możliwości działania oprogramowania na różnych środowiskach.

Aby móc sprawdzić stopień realizacji wymagań jakościowych należy określić dla nich metryki i związany z tym sposób testowania. Istotą testów cech jakościowych systemu jest jak największa obiektywizacja ich pomiaru. Pomiar można zdefiniować jako proces, w którym liczby lub znaki są przypisywane atrybutom obiektów świata rzeczywistego w taki sposób, aby opisać je zgodnie z jednoznacznie zdefiniowanymi zasadami. Pomiarom towarzyszą metryki – miary własności. Biorąc pod uwagę takie ogólne określenie pomiaru, można określić ogólny schemat definiowania metryk wymagań jakościowych. W skład metryki powinny wchodzić następujące elementy:

• sposób pomiaru (w tym: wymaganą liczbę wykonywanych pomiarów),
• zbiór możliwych wartości pomiaru (wraz z jednostką dla wartości liczbowych),
• oczekiwaną (akceptowalną) wartość (w tym: charakterystykę błędów).

Przykładowo, możemy w oparciu o analizę działania przedsiębiorstwa dojść do wniosku, że wcześniej przedstawiona cecha J023 powinna się przekładać na wykonanie w systemie czynności związanych z dodaniem na stan nowego samochodu w czasie poniżej 2 minut.  W takim wypadku opis odpowiedniego wymagania jakościowego wraz z jego metryką może wyglądać tak, jak przedstawiono na rysunku 2.5 – wymaganie JU038.

Rysunek 2.5: Przykłady wymagań jakościowych wraz z metrykami

W celu zapewnienia spójności specyfikacji wymagań konieczne jest zdefiniowanie używanego słownictwa. Na poziomie wymagań użytkownika definicje pojęć danej dziedziny problemu powinny być znacznie bardziej precyzyjne niż na poziomie wizji. Pojęcia umieszczamy w słowniku dziedziny. Słownik dziedziny stanowi uporządkowany zbiór pojęć wraz z ich znaczeniami, za pomocą których można opisać wszystkie aspekty związane z określonym fragmentem rzeczywistości, a które są używane w specyfikacji wymagań użytkownika. Pojęcia w słowniku tworzą sieć powiązań (relacji) wzajemnych, tworząc pewnego rodzaju mapę danej dziedziny problemu.

Przykładowa reprezentacja graficzna słownika została przedstawiona na rysunku 2.6. Zawiera ona wybrane pojęcia z dziedziny sprzedaży samochodów, czyli tej, której dotyczą wymagania przedstawione w poprzedniej części tego rozdziału.

Rysunek 2.6: Przykładowa reprezentacja graficzna słownika dziedzinowego jako diagramu klas

8.3. Specyfikowanie wymagań oprogramowania

Wymagania oprogramowania stanowią uszczegółowienie wymagań użytkownika. Na tym poziomie piramidy wymagań, przypadki użycia zdefiniowane podczas formułowania wymagań użytkownika są opisywane w szczegółach, poprzez m.in. zdefiniowanie interakcji pomiędzy aktorami a systemem w postaci scenariuszy przypadków użycia. W miarę tworzenia scenariuszy uszczegóławiany i uzupełniany jest słownik dziedziny oraz ustalany jest wygląd interfejsu użytkownika. Powstają również tzw. scenopisy, które łączą opis działania przypadków użycia z wyglądem poszczególnych „scen”, czyli elementów wyświetlanych użytkownikowi. Kompletna specyfikacja wymagań oprogramowania zawiera również rozbudowaną specyfikację wymagań jakościowych, gdzie nowe lub zaktualizowane wymagania wynikają z uszczegółowienia wymagań funkcjonalnych i słownika.

Podsumowując rolę wymagań oprogramowania, można powiedzieć, że dają one odpowiedź na trzy pytania:

• Jakie są szczegóły funkcjonowania systemu?
• Jakie dane będą przetwarzane przez system?
• Jakie inne szczegółowe cechy powinien mieć system?

Tego typu szczegóły są bardzo podatne na zmiany w miarę postępów prac nad systemem. Dlatego też, zazwyczaj formułuje się je bezpośrednio przed implementacją wybranego fragmentu funkcjonalności systemu. W cyklu iteracyjnym, dopiero po wybraniu zestawu przypadków użycia (lub historii użytkownika) do realizacji w danej iteracji, dokonuje się ich szczegółowego wyspecyfikowania.

Scenariusze określają w sposób precyzyjny interakcję użytkownika z systemem, prowadzącą do osiągnięcia określonego celu biznesowego. Scenariusz przypadku użycia powinien spełniać trzy cechy:

• opisywać sekwencję interakcji między aktorem i systemem,
• zaczynać się od interakcji aktora (w większości przypadków),
• kończyć się, kiedy zostanie osiągnięty cel przypadku użycia, lub kiedy na drodze do tego celu nastąpiła porażka.

Przypadek użycia jest zbiorem scenariuszy prowadzących do tego samego celu, w tym tych zakończonych porażką (rezygnacją, błędem lub sytuacją wyjątkową). Scenariusze przypadku użycia powinny definiować wszystkie alternatywne przebiegi obsługujące sytuacje wyjątkowe, z wyjątkiem tych najbardziej oczywistych, które mogą być opisane dla wielu przypadków użycia wspólnie (np. anulowanie wykonania operacji).

Pierwsze zdanie scenariusza jest w większości przypadków akcją inicjującą sekwencję współpracy pomiędzy użytkownikiem a systemem. Sekwencja taka jest zawsze inicjowana przez aktora dla głównych przypadków użycia (połączonych bezpośrednio z aktorem). Scenariusz może się zakończyć sukcesem (osiągnięciem celu biznesowego) bądź porażką (np. w wypadku wystąpienia sytuacji wyjątkowej).

Przykłady scenariuszy przypadku użycia spełniające powyższe zasady widzimy na rysunku 2.7. Zdania scenariuszy w tym przykładzie pisane są w prostej kontrolowanej gramatyce, która z jednej strony jest wystarczająca do kompletnego opisania interakcji aktor-system, a z drugiej na tyle prosta, aby scenariusze były przejrzyste i jednoznaczne. Oprócz zdań w gramatyce kontrolowanej, opisujących sekwencje wymiany komunikatów pomiędzy systemem a użytkownikiem, w scenariuszu mogą występować również zdania sterujące.

Rysunek 2.7: Przykładowe scenariusze przypadku użycia

Podstawowym typem zdania scenariusza w gramatyce kontrolowanej jest zdanie typu POD(D) (Podmiot, Orzeczenie, Dopełnienie bliższe, opcjonalne Dopełnienie dalsze).  Zdanie POD(D) składa się z podmiotu określającego wykonawcę akcji (np. „system”, „kierownik”), orzeczenia określającego wykonaną akcję (np. „zapisuje”, „wybiera”) oraz dopełnień określających pojęcia, którego ta akcja dotyczy (np. „model samochodu”, „okno dodania modelu samochodu”). Zdania POD(D) odpowiadają pojedynczym komunikatom wymienianym pomiędzy użytkownikiem a system. Zdania takie numerujemy w celu podkreślenia ich kolejności w sekwencji interakcji.

Zdania sterujące warunkowe pozwalają na kontrolowanie przebiegu scenariuszy przypadków użycia. Użycie zdania warunkowego pozwala na rozgałęzienie sterowania w zależności od spełnienia bądź niespełnienia danego warunku. Zdania warunkowe w proponowanej tutaj notacji, zapisywane są w nawiasach kwadratowych. Scenariusz alternatywny może zarówno prowadzić do spełnienia celu biznesowego (prowadząc do jego spełnienia inna drogą niż scenariusz główny) jak i do porażki (może np. obsługiwać sytuację wyjątkową lub błąd).

Zdania powrotu pozwalają na ponowne połączenie rozgałęzionych scenariuszy bądź zdefiniowanie powtarzanych interakcji (pętli). Definiując powrót trzeba określić scenariusz i numer zdania, które nastąpi po wykonaniu wszystkich zdań danego scenariusza.

Zdania wywołania (ang. invoke) określają krok scenariusza, w którym uruchamiany jest inny przypadek użycia. Mogą one mieć charakter zarówno warunkowy, jak i bezwarunkowy. Po wykonaniu wywołanego przypadku użycia sterowanie powraca do bieżącego przypadku i wykonanie przypadku jest kontynuowane od miejsca wywołania.

Rysunek 8.9: Przykładowy scenariusz przypadku użycia z zdaniami wywołań

Podczas specyfikowania wymagań oprogramowania, korzystamy ze słownika stworzonego na etapie wymagań użytkownika. Słownik ten uzupełniamy o pojęcia pojawiające się podczas tworzenia szczegółowych wymagań systemowych. Definicje pojęć już istniejących w słowniku są również uszczegóławiane na tym etapie.

Przykłady fragmentów słownika rozbudowanego o elementy interfejsu użytkownika zostały pokazane na rysunkach 2.9 i 2.10. Na diagramach klas, elementy interfejsu użytkownika zostały oznaczone stereotypami. Elementy główne (okienka) zostały oznaczone stereotypem «UI element», a elementy aktywne (opcje, przyciski) – stereotypem «UI trigger» (wyzwalacz). Z okienkami zostały powiązane relacjami agregacji odpowiednie klasy słownika dziedziny.

Rysunek 2.9: Przykład słownika na poziomie wymagań oprogramowania

Rysunek 2.10: Przykład słownika na poziomie wymagań oprogramowania z elementami interfejsu użytkownika związanymi z wieloma przypadkami użycia

Opisy scenariuszy i dokładne modele (słowniki) dziedziny nie dostarczają kompletu informacji koniecznych dla zaprojektowania i zaimplementowania systemu. Dlatego też, najczęściej konieczne jest zdefiniowanie wyglądu elementów interfejsu użytkownika. W najprostszym przypadku może to być tzw. szkielet interfejsu użytkownika (ang. wireframe), który polega na naszkicowaniu prostymi kreskami układu elementów ekranowych (okienka z zawartymi w nich polami, przyciskami itp.). Jeśli potrzebny jest bardziej dokładna definicja, wykonujemy tzw. makietę interfejsu użytkownika (ang. mockup). Najbardziej dokładny jest prototyp interfejsu użytkownika (ang. UI prototype), który często wykonywany jest w docelowym narzędziu, w którym będzie implementowany cały system.

Warto zauważyć, że wybrany stan interfejsu użytkownika stanowi swego rodzaju scenę. Poszczególne kroki scenariuszy przypadków użycia mogą powodować przejście do kolejnej sceny, czyli np. wyświetlenie kolejnego okienka. Takie sekwencje scen możemy nazwać scenopisami (ang. storyboard). Przykład scenopisu dla przypadku użycia z rysunku 2.7 przedstawia rysunek 2.11.

 

Rysunek 2.11: Przykładowy scenopis scenariuszy przypadku użycia