Jak opisywać przypadki użycia?

Przypadki użycia pozwalają nam określić, w jaki sposób użytkownik będzie mógł korzystać z systemu. Diagram umożliwia jednym rzutem oka sprawdzić kto może wykonywać jakie czynności. Widać na nim jednak tylko nazwę przypadku. Co ona dokładnie oznacza? Jak to działa? Wszystkie potrzebne do projektowania algorytmów szczegóły przedstaw w opisie.

Poniżej przykład prostego opisu, który dostarcza przydatnych informacji.
Opis przypadku użycia, tabela, PU, analiza IT
Pola w opisie:

  • Identyfikator – ciąg znaków jednoznacznie identyfikujący wymaganie w formacie np. PU/X/99, gdzie: PU – przypadek użycia, X – symbol kategorii (np. od nazwy części systemu), 99 – kolejna liczba porządkowa
  • Nazwa – nazwa przypadku użycia, np. Dodawanie faktury, Przeglądanie raportu nadgodzin,
  • Aktor – rola, zewnętrzny system lub urządzenie korzystające z przypadku użycia; przypadek użycia świadczy usługę na rzecz aktora i dostarcza mu wartościowy rezultat, np. Manager, System magazynowy, Bankomat
  • Zdarzenie inicjujące – zdarzenie, które rozpoczyna wykonanie przypadku użycia, jest powodem jego uruchomienia, np. rozpoczął się nowy miesiąc, zakończyła się kalkulacja prowizji, wybranie opcji dodania faktury
  • Warunki początkowe – warunki, jakie muszą być spełnione w systemie, aby wykonanie przypadku użycia było możliwe, np. zamknięty poprzedni miesiąc księgowy, istnieje co najmniej 1 użytkownik bez obliczonej składki
  • Opis przebiegu interakcji – poszczególne kroki wykonania przypadku użycia na zmianę aktora i systemu – akcja i reakcja na styku aktor-system, np. użytkownik wybiera opcję dodania faktury, system wyświetla formularz dodania faktury zawierający pola…
  • Sytuacje wyjątkowe – sytuacje, które powodują, że wykonanie przypadku użycia z sukcesem nie będzie możliwe; warunki i spodziewana reakcja systemu na tę sytuację, np. brakuje parametru w konfiguracji – system wyświetla komunikat o brakującym parametrze. Obliczenie nie zostaje wykonane.
  • Przebiegi alternatywne – inny zestaw kroków prowadzący również do zakończenia przypadku użycia z sukcesem, np. wniosek urlopowy składa przełożony w imieniu pracownika wybierając pracownika ze swoich podwładnych
  • Warunki końcowe – skutki wykonania przypadku użycia z sukcesem, dające się zaobserwować w interfejsie systemu lub w jego interakcji z otoczeniem, np. na liście urlopów pojawił się dodany urlop, powiadomienie zostało wysłane do pracownika i do przełożonego, liczba dni urlopowych do wykorzystania w danym roku zmniejszyła się
  • Powiązania – lista identyfikatorów powiązanych przypadków użycia i wymagań

Sprawdź!

Aby przekonać się, że dobrze przygotowałeś opisy, sprawdź czy:

  1. opisy przypadków użycia zawierają wymagane elementy (identyfikator, nazwa, aktorzy, itd.)
  2. warunki początkowe dotyczą jedynie systemu informatycznego (nie są ze świata rzeczywistego, system je rejestruje i jest w stanie zweryfikować, czy zaszły)
  3. warunki końcowe przedstawiają rezultat widoczny w systemie
  4. warunki, przebieg (kroki) i wyniki opisane są w sposób jednoznaczny i dokładny (zamiast „pojawiają się informacje o zamówieniu” wymienione są te informacje, których oczekujemy np. numer, data, nazwisko klienta, itp.)

Źródła:

  1. Graessle P., Baumann H., Baumann P., UML 2.0 w akcji. Przewodnik oparty na projektach, Helion,  Gliwice 2006

Zbuduj fundamenty pracy marzeń jako analityk

Dołącz do 6000 analityków i otrzymaj PDF ze wskazówkami.
Poznaj też serię innych bezpłatnych materiałów i aktualizacje o bieżących projektach

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

8 komentarze “Jak opisywać przypadki użycia?”

  1. jarek

    Kompleksowo, ale opis przebiegu interakcji moim skromnym zdaniem jest zbyt odchudzony. Wielu praktyków podkresla istotnosc opisywania interakcji zgodnie z zasada „Who’s got the ball?”. Ten opis jest krótki, ale przy bardziej skomplikowwanych przypadkach mogą pojawić się trudności:)

    Odpowiedz
  2. jarek

    , czyli:
    1. System wyświetla użytkownikowi dostępne szablony dokumentu.
    2. Użytkownik wybiera żądany szablon.
    3. System wyświetla wybrany, pusty szablon.
    4. Uzytkownik uzupelnia szablon i zapisuje stan prac.
    5. System zapisuje dokument.
    Oczywiscie to tylko mój punkt widzenia;)

    Odpowiedz

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Shopping Cart