Przypadki użycia służą do dokumentacji funkcjonalności systemu i bazują na dwóch wspólnie wykorzystywanych koncepcjach:
- Diagramach przypadków użycia
- Specyfikacjach przypadków użycia
Obiekty:
Przypadek użycia (PU): Przypadek użycia reprezentuję funkcję systemu, która reprezentuję osiągnięcie jakiegoś celu w systemie. Nazwa przypadku użycia powinna odzwierciedlać cel osiągnięty przez realizację PU.
Aktor: Aktorzy znajdują się poza granicami systemu i reprezentują ludzi i inne systemy, które wchodzą w interakcję z modelowanym systemem.
Granica systemu: Granica systemu służy do oddzielenia PU, które są częścią modelowanego systemu, od jego otoczenia (aktorów, innych systemów). Opcjonalnie nazwa granicy może zawierać nazwę modelowanego systemu.
Relacje:
Relacja pomiędzy aktorem a PU (użycia): Relacja modeluje wystąpienie interakcji pomiędzy PU a aktorami, którzy komunikują się z systemem w celu realizacji PU.
Relacja rozszerzenia (extend): Relacja rozszerzenie modeluje sytuację, w której scenariusz realizacji źródłowego przypadku użycia (PU A) może rozszerzyć scenariusz realizacji docelowego przypadku użycia (PU B). Rozszerzenie to jest wywoływane po spełnieniu warunków zawartych w scenariuszu realizacji docelowego przypadku użycia.
Relacja włączenia (include): Relacja włączenia modeluje sytuację, w której scenariusz docelowego przypadku użycia (PU B) jest włączany do scenariusza realizacji źródłowego przypadku użycia (PU A).
Przykład diagramu przypadków użycia
Diagramy przypadków prezentują funkcjonalność systemu z perspektywy jego otoczenia – aktorów, oraz powiązania pomiędzy tymi funkcjonalnościami. Diagramy te, poza nazwą określającą cel PU, nie dokumentują natomiast żadnych innych informacji na temat poszczególnych PU, jak na przykład przebiegu interakcji pomiędzy aktorami a przypadkami użycia, czy też warunków wymaganych do realizacji danego przypadku użycia.
Zadaniem specyfikacji przypadku użycia jest kompleksowe udokumentowanie poszczególnych przypadków użycia. Do specyfikacji przypadku użycia należy skorzystać z przyjętego w projekcie szablonu, który zapewni, że żadne wymagane informacje nie zostaną pominięte.
Najczęściej szablony specyfikacji przypadków użycia wykorzystują tabele, w których poszczególne wiersze reprezentują sekcję dotyczącą określonego typu informacji na temat opisywanego PU.
Specyfikacja przypadku użycia powinna zawierać następujące sekcje:
- Oznaczenie: Unikalny identyfikator przypadku użycia
- Nazwa: Unikalna nazwa PU określająca jego cel
- Autorzy: Nazwy autorów zaangażowanych w opis PU
- Priorytet: Nadana ranga dla PU
- Krytyczność: Określa jak wiele szkody może wyrządzić niepowodzenia realizacji PU
- Źródło: Oznaczenie źródła, z którego powodzi PU (np. interesariusz, dokument, system)
- Osoba odpowiedzialna: Interesariusz, który jest odpowiedzialny za dany PU
- Opis: Krótki opis PU
- Wyzwalacze: Nazwa zdarzenia, która powoduje uruchomienie PU
- Aktorzy: Lista aktorów, którzy wchodzą w interakcję z danym PU
- Warunki wstępne: Lista warunków, które muszą być spełnione aby PU mógł być uruchomiony
- Warunki końcowe: Lista stanów systemu jakie muszą być osiągnięte po poprawnym wykonaniu scenariusza głównego PU
- Rezultat: Opis rezultatów jakie są osiągane podczas realizacji PU
- Główny scenariusz: Opis scenariusza głównego określającego ścieżkę wykonania PU
- Scenariusze alternatywne: Opis scenariuszy alternatywnych określających oraz zdarzeń powodujących przejście do realizacji scenariusza alternatywnego
- Scenariusze wyjątków: Opis scenariuszy dla wyjątków oraz zdarzeń powodujących przejście do realizacji scenariusza wyjątku
- Wymagania jakościowe: Odsyłacze do wymagań jakościowych, które dotyczą opisywanego PU
Przykład opisu przypadku użycia zamieszczam poniżej:
Do specyfikacji przypadków użycia używam oczywiście Enterprise Architect’a.
Tekst zainspirowany książką: Klaus Pohl, Chris Rupp „Requirements engineering fundamentals : a study guide for the Certified Professional for Requirements Engineering exam : foundation level”, IREB compliant Wydawnictwo: Rocky Nook Inc, 2011
„Scenariusze alternatywne: Opis scenariuszy alternatywnych określających oraz zdarzeń powodujących przejście do realizacji scenariusza alternatywnego”
Brakuje mi w tej definicji informacji, co jest scenariuszem alternatywnym. W podanym przykładzie scenariusz alternatywny wygląda jak scenariusz główny. Podane czynności dzieją się w momencie uruchomienia głównej ścieżki- są jej częścią. Spodziewałabym się, że scenariusz alternatywny będzie wykorzystany, jeśli coś pójdzie nie tak w scenariuszu głównym.
Scenariusza alternatywny to działanie, które doprowadza nas do celu, ale inną drogą, z dodatkowymi opcjami. Jeśli coś „idzie nie tak” to mamy wyjątek.