Diagram przypadków użycia vs Specyfikacja przypadków użycia

Table of Contents hide

1 Przypadek użycia vs Specyfikacja przypadku użycia

2 Cechy przypadków użycia

3 Zwinne podejście do przypadków użycia

4 Na czas i wystarczająco

5 Szczegółowa specyfikacja przypadku użycia

6 Szablon przypadku użycia — przykład wypłaty z bankomatu

7 Specyfikacja przypadku użycia

8 Zobacz więcej przykładów diagramów przypadków użycia

9 Powiązane linki

Pokazanie tylko diagramu przypadków użycia w UML notacja nie jest wystarczająca. Każdy przypadek użycia powinien być opatrzony tekstem wyjaśniającym cel przypadku użycia oraz funkcjonalność, która jest realizowana podczas jego wykonania.

specyfikacja przypadku użycia jest zazwyczaj tworzona w fazie analizy i projektowania w sposób iteracyjny.

Na początku pisze się tylko krótki opis kroków potrzebnych do przeprowadzenia normalnego przebiegu przypadku użycia (tj. jaką funkcjonalność zapewnia przypadek użycia).
W miarę postępu analizy kroki są rozwijane, aby dodać więcej szczegółów.
Na koniec do przypadku użycia dodawane są wyjątki.
Każdy projekt może przyjąć standardowy szablon przypadku użycia do tworzenia specyfikacji przypadku użycia.

Przypadek użycia vs Specyfikacja przypadku użycia

Przypadek użycia opisuje zadanie wykonywane przez aktora, które przynosi wartość biznesową dla firmy. Przypadek użycia może być wizualizowany jako diagram przypadków użycia lub/i w sformatowanej specyfikacji tekstowej:

Przypadek użycia (zadanie – które klient chce wykonać) może być:

Interaktywny — Przypadek użycia systemu opisuje interakcję aktora z systemem w dążeniu do zdefiniowanego celu biznesowego
Ręczny — Sekwencja działań wykonywanych przez aktora
Zautomatyzowany — Sekwencja kroków wykonywanych przez program lub skrypt

Cechy przypadków użycia

Przypadek użycia ma:

Tylko jeden cel
Jedno miejsce początkowe
Jedno miejsce końcowe
Wiele ścieżek prowadzących od początku do końca
tj. Określenie zachowania dla różnych możliwych warunków
Każdy warunek może wymagać określonych działań

Na przykład – Klient płaci rachunek:

Istnieje wiele ścieżek do osiągnięcia celu:

Płatność telefoniczna
Pocztą
Osobiście
przez czek
gotówką itp.

Ścieżka, która nie prowadzi do celu:

Karta kredytowa została odrzucona

Zwinne podejście do przypadków użycia

Model przypadków użycia i jego poszczególne przypadki użycia ewoluują poziom po poziomie w czasie. Nie wszystkie przypadki użycia modelu będą musiały być określone na tym samym poziomie szczegółowości.

Na czas i wystarczająco

Przypadki użycia mogą być pisane na różnych poziomach danych i zakresu, każdy z nich ma swoje przeznaczenie:

Podsumowanie: Ogólne opisy i szerokie przeglądy funkcjonalności systemu lub procesów biznesowych.
Poziom użytkownika : Opisy związane z zadaniami użytkowników i ich interakcjami z systemem; opisy konkretnego procesu biznesowego. Przypadki użycia na poziomie użytkownika są zazwyczaj uważane za poziom zadania, które jest główną pracą użytkownika.
Podfunkcja: Opisy niższych aktywności, które są używane do ukończenia podczęści głównego przypadku użycia.

Uwaga: Niektóre przypadki użycia mogą być wystarczająco określone do poziomu II. Zatrzymujesz się, gdy osiągniesz wystarczający poziom szczegółowości w sposób just-in-time i just-enough.

Szczegółowa specyfikacja przypadku użycia

Szczegółowy przypadek użycia to tekstowa reprezentacja ilustrująca sekwencję zdarzeń wraz z innymi powiązanymi informacjami o przypadku użycia w określonym formacie. Ludzie zazwyczaj przyjmują standardowy szablon przypadku użycia do rejestrowania szczegółowych informacji o przypadkach użycia.

Szablon przypadku użycia — przykład wypłaty z bankomatu

Jak wspomniano wcześniej, istnieje kilka stylów notacji dla przypadków użycia (np. styl diagramu, zjednoczony język modelowania, format tekstowy). Niezależnie od używanej notacji, powinna być łatwa do zrozumienia. Możesz używać szablonów, takich jak te od Alistair Cockburn, ale można również użyć tego, co najlepiej pasuje do twojego zespołu.