Przypadki użycia (Use Cases)

Dzisiaj opowiem krótko o przypadkach użycia i ich zastosowaniu w praktyce. Projektując oprogramowanie, jak wspominałem we wcześniejszych wpisach, warto określić wymagania funkcjonalne budowanego systemu. Podczas dokonywania wywiadu, analizy wymagań, niezbędne stają się narzędzia, dzięki którym możemy porządkować wymagania klienta, aby później w przejrzysty sposób dokonać wizualizacji efektów analizy. Jednym z takich sposobów są przypadki użycia.

Przypadki użycia (use cases) służą do określania funkcji systemu, interakcji aktora z systemem. Dzięki przypadkom użycia znane są możliwości systemu. Funkcje są opisane w sposób jasny, a ich wizualizacja jasno określa przebieg każdej funkcji. Możliwe jest przejście krok po kroku po każdej funkcji. Aktorem może być użytkownik systemu, klient, administrator, ale również inny system wchodzący w interakcje z naszym systemem.

Funkcje systemowe dzięki opisaniu ich przy użyciu scenariuszy przypadków użycia mogą tworzyć algorytm przejścia przez dane biznesowe wymaganie klienta. Wyobraźmy sobie, pewnie znane każdemu, zakupy w sklepie internetowym:

  1. Klient wybiera towar w sklepie
  2. Klient przechodzi do kasy
  3. Klient podaje szczegółowe dane nt zakupu (adres dostawy, sposób dostawy, koszt)
  4. System generuje końcową ofertę cenową
  5. Klient wybiera sposób zapłaty i dokonuje płatności
  6. System autoryzuje płatność
  7. System potwierdza sprzedaż i realizuje dostawę.

Powyższy opis określa przejście przez proces zakupu od strony biznesowej – klienta. Mamy określoną drogę w przypadku powodzenia wszystkich operacji. Klient wybiera towar, przechodzi do kasy, określa wymagania dostawy, dokonuje płatności. Co jednak, gdy użytkownik wprowadzi np błędne dane z karty kredytowej? Z pomocą przychodzą alternatywne przypadki użycia.

  • 6. System nie uzyskuje autoryzacji płatności. Należy umożliwić użytkownikowi poprawieni danych płatności bądź ich zmianę sposobu płatności
  • 3. W przypadku, gdy użytkownik jest zalogowany, system wyświetla zapisane wcześniej dane użytkownika, z możliwością ich zmiany.

Przypadki użycia alternatywne dają możliwość rozwiązania w przypadku pojawienia się wątpliwości (if) i możliwości niepowodzenia danego przypadku użycia. W przypadku płatności musimy mieć możliwość zmiany formy płatności, lub edycji danych karty kredytowej. Brak takiej opcji mógłby skutecznie zniechęcić klienta, gdy będzie on musiał zamykać anulować zamówienie z powodu nieudanej płatności i braku możliwości zmiany jej sposobu.

W kroku nr 3 system umożliwia wybranie zapisanego wcześniej adresu dostawy użytkownika. Dzięki temu oszczędzany jest czas klienta.

W jaki sposób dokumentować przypadki użycia?

Najbardziej powszechnym sposobem dkumentowania przypadków użycia jest sposób graficzny – diagramy przypadków użycia

Diagramy w czytelny i szybki sposób określają funkcje systemu. Wystarczy przyjrzeć się chwilę diagramowi, aby wiedzieć, co system realizuje, oraz kto go obsługuje. Diagramy informują o tym kto, czyli jaki aktor wchodzi w interakcje z systemem. NA powyższym diagramie aktorem jest każdy z „ludzików”. Od aktorów wychodzą połączenia, czyli dostęp do danych funkcjonalności systemu. Funkcjonalności opisane są elipsach.

Kolejnym sposobem dokumentowania przypadków użycia, są ich opisy: krótki lub szczegółowy opis przypadków użycia.
W krótkim opisie określamy kiedy przypadek użycia następuję, kiedy się kończy oraz przez kogo jest wyzwalany. Niezbędne jest również określenie wyjątków występujących w obsłudze przypadku użycia.
Opis szczegółowy powinien dodatkowo zawierać scenariusze przypadków użycia. Scenariusz dokładnie określa co zachodzi podczas danego przypadku użycia (np powyższy proces zakupu w sklepie internetowym). Powinien określać scenariusze alternatywne (np brak autoryzacji płatności).

W kolejnym artykule spróbuję przedstawić diagram przypadków użycia w systemie 99CRM. Postaram się przygotować również scenariusze przypadków użycia, wtedy powyższy artykuł będzie miał odzwierciedlenie w praktyce.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *