Przypadki użycia służą do opisu interakcji zachodzących pomiędzy użytkownikiem a systemem. Przeważnie przyjmują formę tekstową, aczkolwiek można je również zapisać w postaci diagramów blokowych, diagramów przebiegu, sieci Petriego lub języków programowania.* Przypadki użycia są często wykorzystywaną formą zapisu zidentyfikowanych wymagań, ponieważ dobrze zapisane stanowią prosty i czytelny materiał wyjściowy do dalszej pracy nad implementacją pożądanych funkcjonalności do systemu.

Przypadki użycia są uniwersalnym narzędziem, które można zastosować w wielu dziedzinach działalności biznesowych tj. dystrybucja, sprzedaż, obsługa klienta, komunikacja wewnętrzna w przedsiębiorstwie itd.. Budowanie ich wspomaga oraz ułatwia analizę systemów, które w jakiś sposób należy usprawnić. Poprzez dzielenie zidentyfikowanych problemów na mniejsze sytuacje problemowe, opisywanie ich, a następnie łączenie w większe struktury można dokonać kompleksowej analizy obejmującej aktorów, interakcje oraz przedmiot interakcji.

Dobrze napisane przypadki użycia charakteryzują się dużą czytelnością. Projektanci zapoznając się z ich treścią są w stanie sobie zobrazować przebieg całego opisanego scenariusza. Największe problemy występują najczęściej na etapie pisania przypadków użycia, dlatego też warto przypomnieć sobie o kilku podstawowych właściwościach tej formy*:

1. Cel podstawowy użycia

  • Tworzy się go w oparciu o zidentyfikowane cele główne aktorów oraz użytkowników

2.Relacja z punktu widzenia obserwatora zdarzeń

  • Przypadek użycia powinien opisywać akcje z punktu widzenia obserwatora, a nie z punktu widzenia aktora

3. Zachować czytelność formy

  • Do opisu sytuacji należy stosować zdania proste, cały tekst powinien być zrozumiały zarówno dla osoby technicznej jak i dla laika

4. Rozdzielić główny scenariusz od ścieżek alternatywnych

  • Zapisanie głównego scenariusza wraz z ścieżkami alternatywnymi ograniczy czytelność zobrazowanej sytuacji

Alistair Cockburn w swojej książce pt.: Writting effective use cases wymienia następujące części składowe przypadków użycia:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Identyfikacja aktorów głównych jest niezwykle ważna na początkowym etapie projektu oraz na końcowym. Pozwala projektantom skupić się na najważniejszym aspekcie prac, a mianowicie oczekiwaniach oraz umiejętnościach potencjalnych użytkowników. Dzięki identyfikacji głównych aktorów systemu tworzy się dokumentację mającą na celu przybliżyć sylwetkę użytkownika, która następnie będzie wykorzystywana w celu lepszego dopasowania efektu końcowego prac projektowych do umiejętności i rodzaju wykonywanej przez użytkowników pracy. Dzięki takiemu podejściu można również stworzyć listy wymagań wygenerowanych przez poszczególnych aktorów, które następnie będzie można zestawić w celu uzyskania kompleksowej wiedzy na temat zidentyfikowanych wymagań oraz uzupełnić priorytety korzystając np. z metody ilościowej. W trakcie implementacji wymagań do systemu aktorzy stają się nieistotni. Ich wyszczególnianie w trakcie prac projektowych obejmujących implementacje kodu tylko komplikowałoby pracę nad projektem oraz ograniczało jego możliwość dopasowania się do zmieniającego się środowiska pracy.

W przypadku, gdy aktorzy główni zostali zidentyfikowani, należy przejść do sporządzenia tekstu przedmiotowego przypadku użycia. Zakres przypadku użycia określa ramy systemu, wewnątrz którego projektant będzie implementował daną funkcjonalność. Informacja taka jest ważna dla projektantów, ponieważ już na samym początku mogą pogrupować poszczególne przypadki użycia ze względu na część systemu, które obejmują.

Wyróżnia się trzy podstawowe poziomy: cel streszczający, cel użytkownika oraz podfunkcje. Pierwszy z nich jest generalnym odwzorowaniem wszelkiego rodzaju powiązań występujących pomiędzy przypadkami użycia znajdującymi się poniżej jego poziomu. Drugi określa podstawowe czynności, które są wykonywane w trakcie realizacji jednego lub wielu celów użytkownika. Natomiast podfunkcje opisuje czynności, które powinny zostać pominięte w zapisie, jako nieistotne lub włączone do stworzonego już przypadku użycia. Dzięki tak skonstruowanej w taki sposób hierarchii przypadków użycia można uzyskać czytelny obraz całego projektowanego systemu.

Informacją, która zawarta powinna być w przypadku użycia jest zapis dotyczący uczestników oraz ich interesów. Każdy scenariusz tworzony jest w oparciu o interakcje. W celu lepszego zrozumienia problemu należy określić na początku, pomiędzy kim lub czym te interakcje będą zachodzić oraz jakie interesy będą realizować.

Warunek początkowy określa stan, który został już osiągnięty i był warunkiem przejścia do danego przypadku użycia. Zazwyczaj warunek początkowy wiąże się z realizacją przypadku użycia znajdującego się wyżej w hierarchii. W przypadku zakupów przez Internet warunkiem początkowym, aby zakupić przedmiot jest uprzednia rejestracja w systemie.

W przypadku użycia powinny się również znaleźć minimalna gwarancja, gwarancja powodzenia oraz wyzwalacze. Minimalna gwarancja określa, co w sytuacjach awaryjnych system jest w stanie wykonać. Przy podpunkcie gwarancja powodzenia zapisuje się jak powinien zakończyć się przypadek użycia w sytuacji, gdy zrealizowany zostanie główny scenariusz powodzenia. Wyzwalacze są to wszelkiego rodzaju sytuacje, które powodują rozpoczęcie przypadku użycia. Dzięki danym podpunktom projektant dostaje informacje o zabezpieczeniach, które należy uwzględnić w systemie oraz jakie zachowanie inicjuje działanie systemu.

Scenariusz główny powodzenia zawiera informacje o przebiegu przypadku użycia przy założeniu, że interakcja przebiega bez zakłóceń. Istnieją dwie szkoły pisania tekstu scenariusza. Niektórzy zalecają pisanie przypadków użycia krok po kroku z uwzględnieniem każdej kolejnej czynności wykonywanej przez użytkownika, natomiast inni uznają taki szczegółowy zapis za niepotrzebny, a wręcz zamazujący obraz całej interakcji. Zalecają pisanie krótkich przypadków użycia, przykładając szczególną wagę do ukazania zamiarów aktora. W swoim przykładzie zamieszczonym poniżej zastosowałam się do wskazówek zwolenników pisania krótkich przypadków użycia.

Rozszerzenie obejmuje wszystkie zdarzenia, w których wystąpiła sytuacja nieprzewidziana w scenariuszu głównym powodzenia. Poniżej prezentuje przykład przypadku użycia opisującego wypłatę pieniędzy z bankomatu dokonywaną przez klienta banku XYZ.

Wypłata pieniędzy z bankomatu przy użyciu karty debetowej

Aktor główny: klient banku XYZ
Zakres:

Poziom: Cel użytkownika

Uczestnicy i interesy:

Klient- wypłacić pieniądze w szybki sposób w dowolnym momencie

Bank XYZ- ograniczenie kosztów związanych z obsługą klientów w filii banku

Warunek początkowy: Użytkownik posiada rachunek bankowy, środki na koncie oraz kartę debetową

Minimalna gwarancja: Klient wypłacił gotówkę

Gwarancja powodzenia: Klient wypłaca wybraną przez siebie kwotę z bankomatu, a jego konto zostaje obciążone tę samą kwotę, następuje rejestracja transakcji.

Główny scenariusz powodzenia:
1. Klient wsuwa kartę debetową do czytnika
2. Bankomat odczytuje identyfikator banku oraz numer konta i kontaktując się z głównym komputerem stwierdza ich poprawność
3. Klient wpisuje PIN. Bankomat stwierdza jego poprawność
4. Klient wybiera przycisk „wypłata” i podaje kwotę, która będzie wielokrotnością 50zł
5. Bankomat informuje główny system bankowy o koncie klienta i pobranej przez niego kwocie, a następnie otrzymuje akceptacje i nowe saldo
6. Bankomat wydaje gotówkę, kartę i potwierdzenie z nowym saldem
7. Bank odnotowuje transakcję w dzienniku

Rozszerzenia:

2a. Klient posiada kartę, której bankomat nie obsługuje

2a1. Bankomat podaję informację o zidentyfikowanym problemie, a następnie odrzuca transakcje

2b.Karta klienta jest uszkodzona

2b1. Bankomat podaje informacje o zidentyfikowanym problemie, a następnie odrzuca transakcje

3a.Bankomat stwierdza niepoprawność PINu

3a1. Klient ponownie wpisuje numer PINu

3a2. Klient rezygnuje z przypadku użycia

5a.Klient nie posiada wybranej kwoty na koncie

5a1. Klient zmienia kwotę wypłaty

5a2. Klient rezygnuje z przypadku użycia

5b.Wybrana kwota przewyższa dzienny limit wypłaty z konta

5b1. Klient zmienia kwotę wypłaty

5b2. Klient rezygnuje z przypadku użycia

5c.Bankomat nie posiada środków, aby wypłacić daną kwotę

5c1. Klient zmienia kwotę wypłaty

5c2. Klient rezygnuje z przypadku użycia

Przypadki użycia, tak jak już zostało wspomniane, wykorzystywane są w wielu sytuacjach. Dzięki swojej strukturze mogą realizować trzy główne cele:

1. Organizacja wymagań funkcjonalnych

  • Wszystkie wymagania funkcjonalne, które zostały zidentyfikowane na poprzednim etapie prac projektowych poddawane jest analizie, a następnie zapisywane w formie przypadku użycia. Należy się zastanowić czy podany przez użytkownika opis jest pełny oraz odpowiedniej wielkości. Dzięki jednej uniwersalnej strukturze zapisu organizacja przypadków użycia (grupowanie, wyznaczanie relacji itp.) staje się o wiele prostszym zajęciem.

2. Przedstawianie historii krok po kroku

  • Każdy ze scenariuszy zapisany jest w postaci szeregu kroków, które należy wykonać w celu zakończenia zadania. Opis historii zawiera informacje m.in. o:
  • i) Początku i końcu interakcji
  • ii) Opis interakcji w przypadku uczestnictwa aktorów (kiedy miała miejsce, jakie informacje zostały przesłane)
  • iii) Wyjątki przy przepływie zdarzeń

3. Możliwość połączenia w diagram, który stanowić będzie ogólny zarys projektu

  • W przypadku połączenia przypadków użycia w diagram uzyskujemy czytelny spis treści wszystkich zależności występujących pomiędzy poszczególnymi przypadkami użycia.

Przypadki użycia przeważnie wykorzystuje się do podanych poniżej celów:***

    • Ustalenia wymagań funkcjonalnych
    • Ustalenia wymagań wobec restrukturyzacji procesów gospodarczych firmy
    • Udokumentowania procesów gospodarczych firmy
    • Pomocy przy identyfikacji wymagań uczestników i użytkowników
    • Udokumentowania wnętrza systemu
    • Udokumentowania zachowania projektu lub zrębu projektu

Poniżej zaprezentowany został diagram przypadków użycia w sytuacji korzystania przez klienta z bankomatu. Klient wkładając kartę do czytnika oraz wpisując kod PIN dokonuje autentykacji w systemie bankomatu. Następnie posiada trzy możliwości zachowania się (przypadki użycia):

1) Wpłaca pieniądze

2) Wypłaca pieniądze

3) Sprawdza stan swojego konta

W przypadku, gdy klient chce wypłacić pieniądze z konta, system przesyła informacje do banku w celu uzyskania akceptacji transakcji. Bank akceptuje transakcje jednocześnie aktualizując (pomniejszając) stan konta kwotą, którą klient wypłaca oraz naliczoną prowizją od transakcji. Bank po dokonaniu transakcji zapisuje jej przebieg w dzienniku transakcji. Podobnie dzieje się w przypadku wpłacania pieniędzy oraz sprawdzania stanu konta. Przykład ten przedstawia obraz tej samej transakcji, co w poprzednim przykładzie, ale pokazany na poziomie streszczenia.

Przykład diagramu przypadków użycia:

Zalety:

  • Służą do opisu prostych systemów, jak również tych o złożonej strukturze
  • Uniwersalność zastosowania, za ich pomocą można opisać dowolne zjawisko biznesowe
  • Wygodny sposób zapisu poszczególnych historii użycia
  • Przypadki użycia nie wymagają od użytkownika wiedzy technicznej oraz innych specjalnych kwalifikacji

Wady:

  • Przy zapisie przypadków użycia stosuje się uproszczenia, które mogą wpływać na pogorszenie jakości informacji

Bartosz Chrabski IBM Polska
Emilia Kwiatkowska

 

*Alistair Cockburn, Writting effective use cases

**Alistair Cockburn, Writting effective use cases

***Alistair Cockburn, Writting effective use cases

pstrong