Co to jest przypadki użycia? z przykładami i darmowym narzędziem

Przypadek użycia to narzędzie do identyfikacji celów biznesowych systemu. Identyfikacja przypadków użycia pomaga określić zakres systemu, zapewniając, że wszystkie wykryte wymagania będą zgodne z wartościami, potrzebami i strategią biznesową.

Co to jest przypadek użycia?

Przypadek użycia reprezentuje cel po wysokim poziomie, który ma zostać osiągnięty przez kogoś, niektórych stron lub niektórych podsystemów poprzez interakcję z systemem, który może być systemem w trakcie rozwoju lub systemem do utrzymania, w zależności od charakteru projektu oprogramowania.

Use case

Przypadki użycia nie są ani wymaganiami systemu, ani funkcjami do zaimplementowania. W rzeczywistości ważne jest, aby przypadki użycia nie były łączone z wymaganiami, ponieważ potrzebujesz jasnego zestawu przypadków użycia, które pomogą Ci zdefiniować cele biznesowe i zakres systemu. W rzeczywistości zbieranie wymagań odbywa się po identyfikacji przypadków użycia (epiców) i następnie rozdzieleniu ich na zestaw odpowiednich historii użytkownika (celów biznesowych).

Forma graficzna przypadku użycia

Przypadki użycia można wizualizować na diagramie przypadków użycia UML. Przypadek użycia jest przedstawiany jako elipsa na diagramie, a jego nazwa pojawia się w środku kształtu. Oprócz przypadku użycia, typowy diagram przypadków użycia zawiera dwa dodatkowe elementy – aktora i połączenie.

Use case diagram

Aktorem jest rola, która interaguje z systemem w celu osiągnięcia jednego lub kilku celów biznesowych reprezentowanych przez przypadki użycia. Zjawisko interakcji między aktorem a przypadkiem użycia jest przedstawiane jako powiązanie (link). Zauważ, że aktorem nie musi być konkretna jednostka fizyczna (np. Jan), ale tylko rola (np. Klient). W rzeczywistości rolę może pełnić różna osoba, a z kolei jedna osoba może pełnić wiele ról.

Jak zidentyfikować przypadek użycia?

Przypadki użycia są identyfikowane poprzez komunikację z właścicielami biznesu lub wyższymi menedżerami firmy. Nazywamy ich stakeholderami biznesowymi. Ważne jest, aby przypadki użycia identyfikować wraz z stakeholderami biznesowymi, a nie z kimkolwiek innym, ponieważ mają one jasne wyobrażenie o kierunkach i rzeczywistych działaniach firmy. Mają również uprawnienia i informacje potrzebne do podejmowania decyzji biznesowych. Dlatego zidentyfikowane przypadki użycia są zgodne z wartościami, potrzebami i strategią firmy.

Dlaczego przypadki użycia?

Wiele osób uznaje identyfikację przypadków użycia za krok nadmiarowy. Chętniej od razu przechodzą do identyfikacji wymagań systemu. Czy więc podejście przypadków użycia jest bezużyteczne?

Gdy chcesz stworzyć system o dużym zakresie, który zazwyczaj obejmuje wiele stakeholderów o różnych oczekiwaniach co do końcowego systemu, kończysz się dużą ilością wymagań w sposób trudny do zarządzania. Przypadek użycia może pełnić rolę miejsca zapasowego do przyjęcia grupy powiązanych historii użytkownika, które dzielą większy i wspólny cel biznesowy oraz zakres.

Pamiętaj, że przypadki użycia są identyfikowane poprzez komunikację z właścicielami biznesu i wyższymi menedżerami, którzy nadzorują rozwój swoich firm i mają możliwość podejmowania strategicznych decyzji biznesowych. Dlatego przypadki użycia bezpośrednio odzwierciedlają cele biznesowe, które system docelowy ma osiągnąć. Identyfikując wymagania na podstawie przypadków użycia, wymagania są bardzo prawdopodobnie w zakresie systemu i tym samym osiągając oczekiwane wartości biznesowe przez właścicieli. Ponadto przypadki użycia ułatwiają znaczące kategoryzowanie wymagań. Zaproponowane funkcje oprogramowania mogą być planowane na podstawie ważności przypadków użycia, a nie wyłącznie na podstawie opinii stakeholderów z linii frontowej, które mogą nie być w pełni zgodne z oczekiwaniami właściciela biznesu.

Przykłady przypadków użycia

Oto kilka przykładów ilustrujących zastosowanie przypadków użycia. Przykład podany tutaj ma jedynie cel ilustracyjny – nie ma jednoznacznej metody, jakie przypadki użycia powinny zostać zidentyfikowane dla konkretnego systemu docelowego. Zasadą ogólną w procesie identyfikacji przypadków użycia jest zawsze aktywne uczestnictwo i zaangażowanie stakeholderów biznesowych.

System

Przypadki użycia

  • Bankomat
    • Wypłata gotówki, przelew pieniędzy, darowizna, płatność rachunków, zmiana PIN
  • Online album zdjęć
    • Przesłanie zdjęcia, udostępnienie zdjęcia, usunięcie zdjęcia
  • Aplikacja do śledzenia zdrowia
    • Zapisz trening, wygeneruj statystyki treningu, wyzwanie celu

Na podstawie powyższych przykładów, moglibyśmy przeprowadzić następujące dyskusje:

Przypadek użycia prowadzi do osiągnięcia obserwowalnego celu

Przykład przypadku użycia – Bankomat

Bankomat to klasyczny przykład przy wyjaśnianiu pojęcia przypadku użycia lub analizy przypadków użycia. Możesz się zastanawiać, dlaczego nie ma przypadku użycia dla „Logowania”, które jest nieodzownym krokiem we wszystkich operacjach bankomatu. Jak już powiedziano, przypadki użycia to cele biznesowe do osiągnięcia. Dają one obserwowalny wynik dla aktora, który interaguje z systemem w celu osiągnięcia przypadku użycia. Tutaj „logowanie” to tylko część innych operacji. Samo logowanie nie daje żadnego obserwowalnego wyniku – nikt nie zaloguje się do bankomatu i od razu odejdzie, prawda? Dlatego nie traktujemy „logowania” jako przypadku użycia.

Czy „zmiana PIN” nie byłaby zbyt mała, by stanowić przypadek użycia? Odpowiedź brzmi: identyfikacja przypadków użycia nie opiera się ani na ilości pracy, jaką użytkownik musi wykonać, ani na liczbie funkcji systemu do zaimplementowania. O ile jest to cel biznesowy, który stakeholder biznesowy chce, by system docelowy osiągnął, to jest przypadkiem użycia. W tym przypadku traktujemy zmianę PIN przez klienta za pomocą bankomatu jako przypadek użycia.

Przykład przypadku użycia – Online album zdjęć

Typowy album fotografii online pozwala użytkownikom oznaczać przesłane zdjęcia. Czy „oznacz zdjęcie” to przypadki użycia? Odpowiedź brzmi: zależy. Jeśli stakeholderzy biznesowi chcą pozwolić użytkownikom uzyskać dostęp do systemu w celu oznaczenia ich zdjęć, nawet bez wykonywania czegoś innego w trakcie sesji, to „oznacz zdjęcie” powinno być przypadkiem użycia. Jednak jeśli uważają, że oznaczanie zdjęcia to tylko część procesu przesyłania zdjęcia, a nie ma innej możliwości oznaczenia zdjęcia później, to „oznacz zdjęcie” nie powinno być przypadkiem użycia. Inny przypadek to sytuacja, w której stakeholderzy chcą tylko pozwolić użytkownikom edytować przesłane zdjęcia pod względem dowolnych właściwości, takich jak tytuł, opis, tagi itp. Wtedy bardzo prawdopodobne jest stworzenie przypadku użycia „edytuj zdjęcie”. Można więc zauważyć, że identyfikacja przypadku użycia to nie krok przypadkowy. Można wyobrazić sobie, że możliwość oznaczania zdjęć będzie wspierana zupełnie inaczej w przypadkach użycia „oznacz zdjęcie” i „edytuj zdjęcie”.

Przykład przypadku użycia – aplikacja do śledzenia zdrowia

Chociaż przypadki użycia nie są wymaganiami, nie oznacza to, że są abstrakcyjne i nie mają skupienia. Weźmy jako przykład aplikację do śledzenia zdrowia. Zapisz trening, wygeneruj statystyki treningu i wyzwanie celu to wszystko wystarczająco jasne, aby określić zakres funkcji. Czy utrzymanie dobrego zdrowia może być przypadkiem użycia? No cóż, jest to złe rozwiązanie, ponieważ jego zakres jest zbyt szeroki. Każda aplikacja do śledzenia zdrowia stara się pomóc użytkownikowi osiągnąć ten cel, jednak z takim dużym celem nie jesteśmy pewni, jakie funkcje aplikacje naprawdę będą w stanie zrealizować!

Jak napisać przypadek użycia?

Najprostsza forma przypadku użycia składa się z + lub, które opisują cel biznesowy. Oto kilka przykładów:

  1. Zarejestruj konto
  2. Złóż zamówienie
  3. Wypłać gotówkę
  4. Opublikuj stanowisko
  5. Zbadaj niepowodzenie przypadków

Jak już powiedziano, przypadki użycia są przeznaczone do identyfikacji celów biznesowych. Nie należy ich używać do pisania wymagań ani do opisywania interakcji między użytkownikiem a systemem. Wszystkie te kroki zostaną szczegółowo omówione w kolejnych etapach rozwoju, ale nie teraz.

Korzystanie z przypadku użycia i historii użytkownika

Historie użytkownika to również ważny narzędzie w rozwoju agilnym. Każda historia użytkownika składa się z krótkiego opisu napisanego z punktu widzenia użytkownika. Oto przykłady historii użytkownika:

  1. Użytkownik chce zapłacić kartą kredytową.
  2. Użytkownik chce zapłacić przez PayPal.
  3. Użytkownik chce opcjonalnie dołączyć ubezpieczenie wysyłki podczas kasy.
  4. Użytkownik chce wybrać inne miejsce dostawy podczas kasy.
  5. Użytkownik chce otrzymać SMS po pomyślnym utworzeniu zamówienia.

Przypadek użycia to narzędzie do definiowania zakresu funkcji, podczas gdy historia użytkownika ujawnia, co użytkownik robi lub musi zrobić jako część swojej pracy, co w końcu prowadzi do stworzenia niektórych wymagań. Możemy wykorzystać te dwa sposoby zbierania wymagań do identyfikacji odpowiednich wymagań. Oto kroki ich wykonania: Po pierwsze, skontaktuj się z stakeholderami biznesowymi w celu zidentyfikowania celów biznesowych jako przypadków użycia. Następnie skup się na konkretnym przypadku użycia, skontaktuj się z użytkownikami z linii frontowej w celu zidentyfikowania historii użytkownika w ramach tego przypadku użycia. Ponieważ identyfikacja historii użytkownika jest prowadzona przez przypadek użycia, wymagania znalezione na końcu będą zgodne z celami biznesowymi.

Use case and user stories

Visual Paradigm dostarcza wszystkie narzędzia, które potrzebujesz w rozwijaniu oprogramowania agilnego, które obejmuje narzędzie do rysowania diagramów przypadków użycia UML, (agilna) historia użytkownika, sprint, storyboard i szkice do projektowania UX, narzędzie do zarządzania zadaniami, itd.

Bibliografia

  1. Diagram przypadków użycia – Język Modelowania Unifikowanego (UML)
  2. Co to jest diagram przypadków użycia?
  3. Utwórz diagram przypadków użycia UML
  4. Najlepsze praktyki i przykłady diagramu przypadków użycia
  5. Szablony diagramu przypadków użycia
  6. Opis przypadku użycia w Visual Paradigm dla UML
  7. diagram przypadków użycia
  8. Jak narysować diagram przypadków użycia?

Leave a Reply