Analiza biznesowa - przypadki użycia

Jednym z dziewięciu diagramów UML jest diagram przypadków użycia. Są to nie tylko ważne, ale niezbędne wymagania dotyczące projektów oprogramowania. Zasadniczo jest używany w cyklach życia oprogramowania. Jak wiemy, istnieją różne fazy w cyklu rozwoju, a najczęściej używaną fazą dla przypadków użycia byłaby faza zbierania wymagań.

Co to jest przypadek użycia?

Przypadek użycia opisuje sekwencję działań wykonywanych przez system, który zapewnia wartość aktorowi. Przypadek użycia opisuje zachowanie systemu w różnych warunkach, gdy odpowiada on na żądanie jednego z interesariuszy, zwanegoprimary actor.

Aktor jest tym, który systemu, innymi słowy, jest użytkownikiem końcowym.

W inżynierii oprogramowania i systemów przypadek użycia to lista kroków, zwykle definiujących interakcje między rolą (znaną w UML jako „aktor”) a systemem, prowadzących do osiągnięcia celu. Aktor może być człowiekiem lub systemem zewnętrznym.

Przypadek użycia określa przepływ zdarzeń w systemie. Bardziej dotyczy tego, co jest wykonywane przez system w celu wykonania sekwencji działań.

Korzyści z przypadku użycia

Przypadek użycia zapewnia następujące korzyści -

  • Jest to łatwy sposób na uchwycenie wymagań funkcjonalnych z naciskiem na wartość dodaną dla użytkownika.

  • Przypadki użycia są stosunkowo łatwe do napisania i odczytania w porównaniu z tradycyjnymi metodami wymagań.

  • Przypadki użycia zmuszają programistów do myślenia z perspektywy użytkownika końcowego.

  • Przypadek użycia angażuje użytkownika w proces wymagań.

Anatomia przypadku użycia

Nazwa : opisowa nazwa, która ilustruje cel przypadku użycia.

Opis : opisuje, co robi przypadek użycia w kilku zdaniach.

Aktor : Wymień wszystkich aktorów, którzy uczestniczą w przypadku użycia.

Warunek wstępny : warunki, które muszą być spełnione przed rozpoczęciem przypadku użycia.

Przebieg wydarzeń : opis interakcji między systemem a aktorem.

Stan postu : opisz stan systemu po wykonaniu przypadku użycia.

Wytyczne dotyczące szablonu przypadku użycia

Udokumentuj każdy przypadek użycia, używając szablonu podanego na końcu tego rozdziału. Ta sekcja zawiera opis każdej sekcji w szablonie przypadków użycia.

Identyfikacja przypadków użycia

  • Use-Case ID- Nadaj każdemu przypadkowi użycia unikalny identyfikator liczbowy w formie hierarchicznej: XY Powiązane przypadki użycia można pogrupować w hierarchii. Wymagania funkcjonalne można prześledzić wstecz do oznaczonego przypadku użycia.

  • Use-Case Name- Podaj zwięzłą, zorientowaną na wyniki nazwę przypadku użycia. Odzwierciedlają one zadania, które użytkownik musi wykonać przy użyciu systemu. Dołącz czasownik oznaczający działanie i rzeczownik. Kilka przykładów -

    • Wyświetl informacje o numerze części.

    • Ręcznie zaznacz źródło hipertekstu i utwórz łącze do celu.

    • Złóż zamówienie na płytę CD ze zaktualizowaną wersją oprogramowania.

Historia przypadków użycia

Tutaj wspominamy o nazwiskach osób, które są interesariuszami dokumentu Usecase.

  • Created By - Podaj nazwisko osoby, która początkowo udokumentowała ten przypadek użycia.

  • Date Created - Wprowadź datę, w której przypadek użycia został pierwotnie udokumentowany.

  • Last Updated By - Podaj imię i nazwisko osoby, która wykonała ostatnią aktualizację opisu przypadku użycia.

  • Date Last Updated - Wprowadź datę ostatniej aktualizacji przypadku użycia.

Definicja przypadku użycia

Poniżej znajdują się definicje kluczowych koncepcji przypadku użycia -

Aktor

Aktor to osoba lub inny podmiot zewnętrzny w stosunku do określonego systemu oprogramowania, który współdziała z systemem i wykonuje przypadki użycia w celu wykonania zadań. Różni aktorzy często odpowiadają różnym klasom użytkowników lub rolom, określonym w społeczności klientów, która będzie używać produktu. Podaj nazwę aktora (ów), który będzie wykonywał ten przypadek.

Opis

Podaj krótki opis przyczyny i wyniku tego przypadku użycia lub ogólny opis sekwencji działań i wyniku wykonania przypadku użycia.

Warunki wstępne

Wymień wszelkie działania, które muszą mieć miejsce, lub wszelkie warunki, które muszą być spełnione, zanim przypadek użycia będzie można rozpocząć. Ponumeruj każdy warunek wstępny.

Examples

  • Tożsamość użytkownika została uwierzytelniona.
  • Komputer użytkownika ma wystarczającą ilość wolnej pamięci do uruchomienia zadania.

Warunki wysyłania

Opisz stan systemu na zakończenie wykonania przypadku użycia. Ponumeruj każdy warunek postu.

Examples

  • Dokument zawiera tylko prawidłowe tagi SGML.
  • Cena towaru w bazie danych została zaktualizowana o nową wartość.

Priorytet

Wskaż względny priorytet implementacji funkcjonalności wymaganej do wykonania tego przypadku. Zastosowany schemat priorytetów musi być taki sam, jak zastosowany w specyfikacji wymagań oprogramowania.

Częstotliwość użycia

Oszacuj, ile razy ten przypadek użycia zostanie wykonany przez aktorów w odpowiedniej jednostce czasu.

Normalny przebieg wydarzeń

Podaj szczegółowy opis działań użytkownika i odpowiedzi systemu, które będą miały miejsce podczas wykonywania przypadku użycia w normalnych, spodziewanych warunkach. Ta sekwencja dialogowa ostatecznie doprowadzi do osiągnięcia celu określonego w nazwie i opisie przypadku użycia. Opis ten można zapisać jako odpowiedź na hipotetyczne pytanie: „Jak mogę <wykonać zadanie określone w nazwie przypadku użycia>?” Najlepiej zrobić to jako ponumerowaną listę czynności wykonywanych przez aktora na przemian z odpowiedziami dostarczanymi przez system.

Kursy alternatywne

Dokumentuj inne, legalne scenariusze użycia, które mogą mieć miejsce w tym przypadku użycia oddzielnie w tej sekcji. Podaj alternatywny kurs i opisz wszelkie różnice w kolejności wykonywanych czynności. Ponumeruj każdy kurs alternatywny, używając identyfikatora przypadku użycia jako przedrostka, a następnie „AC”, aby wskazać „kurs alternatywny”. Przykład: XYAC.1.

Wyjątki

Opisz wszelkie przewidywane błędy, które mogą wystąpić podczas wykonywania przypadku użycia, i zdefiniuj, jak system ma reagować na te warunki. Opisz również, jak system ma zareagować, jeśli wykonanie przypadku użycia nie powiedzie się z nieoczekiwanego powodu. Ponumeruj każdy wyjątek, używając identyfikatora przypadku użycia jako przedrostka, a następnie „EX”, aby wskazać „Wyjątek”. Przykład: XYEX.1.

Zawiera

Wymień wszystkie inne przypadki użycia, które są uwzględnione („nazywane”) przez ten przypadek użycia. Wspólne funkcje, które pojawiają się w wielu przypadkach użycia, można podzielić na oddzielne przypadki użycia, które są zawarte w tych, które wymagają tej wspólnej funkcjonalności.

Specjalne wymagania

Zidentyfikuj wszelkie dodatkowe wymagania, takie jak wymagania niefunkcjonalne, dla danego przypadku, które mogą wymagać uwzględnienia podczas projektowania lub wdrażania. Mogą to być wymagania dotyczące wydajności lub inne cechy jakościowe.

Założenia

Wymień wszelkie założenia przyjęte w analizie, które doprowadziły do ​​zaakceptowania tego przypadku użycia w opisie produktu i napisania opisu przypadku użycia.

Uwagi i problemy

Wymień wszelkie dodatkowe komentarze na temat tego przypadku użycia lub wszelkich pozostałych nierozwiązanych problemów lub TBD (do ustalenia), które należy rozwiązać. Określ, kto rozwiąże każdy problem, termin i ostateczne rozwiązanie.

Zarządzanie zmianami i kontrola wersji

Kontrola wersji to zarządzanie zmianami w dokumentach, dużych witrynach internetowych i innych zbiorach informacji. Zmiany są zwykle identyfikowane za pomocą kodu liczbowego lub literowego, określanego jako numer wersji lub poziom zmiany. Każda wersja jest powiązana z sygnaturą czasową i osobą dokonującą zmiany.