Opis przypadku użycia wyjaśnia, jak aktor osiąga cel poprzez interakcję z systemem. Uzupełnia on diagram przypadków użycia:

• Diagram przypadków użycia:Pokazuje aktorów, zakres systemu i relacje.

• Opis przypadku użycia:Wyjaśnia szczegółowe zachowanie, warunki, reguły i wyniki.

Diagram dostarcza mapy; opis dostarcza trasy.

1. Czym jest przypadek użycia?

Przypadek użycia reprezentuje cenny cel, który zewnętrzny aktor osiąga za pomocą systemu.

Przykłady:

• Klient składa zamówienie

• Pracownik zgłasza wniosek o zwrot kosztów

• Pacjent umawia wizytę

• Administrator tworzy konto użytkownika

• Klient resetuje hasło

Dobry przypadek użycia jest:

• Zorientowany na cel

• Wartościowy dla aktora

• Opisany z perspektywy użytkownika

• Niezależny od konkretnych układów ekranów

• Skupiony na obserwowalnym zachowaniu systemu

Słabe i ulepszone nazwy przypadków użycia

Użyj krótkiego zwrotu czasownikowo-rzeczownikowego, takiego jak Złóż wniosek o zwrot kosztów, Śledź przesyłkę, lub Zatwierdź wniosek o kredyt.

2. Kluczowe pojęcia

2.1 Aktorzy

Aktor to zewnętrzna rola, która oddziałuje z systemem.

Aktor może być:

• Osoba

• Organizacja

• Inny system oprogramowania

• Urządzenie sprzętowe

• Harmonogramowany lub czasowy wyzwalacz

Przykłady:

• Klient

• Agent wsparcia

• Pracownik magazynu

• Brama płatności

• Usługa e-mail

• Administrator

Aktor to rola, niekonkretna osoba. Na przykład „Klient” jest zazwyczaj lepszy niż „Jan Kowalska”.

Aktorzy główni i wspierający

Aktor wspierający inicjuje scenariusz użycia w celu osiągnięcia celu.

Aktor wspierający pomaga systemowi podczas wykonywania.

Przykład:

• Aktor główny: Klient

• Aktor wspierający: Brama płatności

• Scenariusz użycia: Złóż zamówienie

Klient inicjuje zamówienie, podczas gdy brama płatności autoryzuje płatność.

2.2 Granica systemu

Granica systemu definiuje, co znajduje się wewnątrz modelowanego systemu.

Dla sklepu internetowego granica może obejmować:

• Przeglądaj produkty

• Dodaj produkt do koszyka

• Złóż zamówienie

• Wykonaj płatność

• Śledź zamówienie

Poniższe elementy znajdują się poza granicą:

• Klient

• Brama płatności

• Firma kurierska

• Dostawca poczty elektronicznej

Granica zapobiega niejasnościom dotyczącym odpowiedzialności systemu.

2.3 Scenariusz użycia

Scenariusz użycia powinien opisywać pełną interakcję, która prowadzi do znaczącego rezultatu.

Na przykład:

Złóż zamówienie:Klient wybiera produkty, podaje informacje o dostawie, płaci za zamówienie i otrzymuje potwierdzenie zamówienia.

„Zweryfikuj numer karty kredytowej” może być funkcją systemu, ale zazwyczaj jest zbyt drobna, aby stanowić samodzielny cel użytkownika. Może być natomiast częścią Złóż zamówienie lub Wykonaj płatność.

2.4 Warunki wstępne

Warunek wstępny określa, co musi już być prawdziwe przed rozpoczęciem scenariusza użycia.

Przykłady:

• Klient posiada aktywne konto.

• Produkt jest dostępny do sprzedaży.

• Pracownik jest uwierzytelniony.

• Termin wizyty istnieje.

• Koszyk zakupowy zawiera co najmniej jeden przedmiot.

Warunek wstępny nie jest akcją wykonywaną przez scenariusz użycia.

Słaby warunek wstępny:

Klient się loguje.

Lepszy warunek wstępny:

Klient jest uwierzytelniony.

2.5 Warunki końcowe

Warunek końcowy określa, co jest prawdziwe po zakończeniu scenariusza użycia.

Przykłady:

• Zamówienie zostało zarejestrowane.

• Płatność została autoryzowana.

• Wysłano wiadomość e-mail z potwierdzeniem.

• Wniosek o zwrot kosztów ma status złożony.

• Konto użytkownika jest oznaczone jako aktywne.

Warunki końcowe powinny opisywać wyniki, a nie szczegóły implementacji.

Słaby warunek końcowy:

Tabela zamówień jest aktualizowana.

Lepszy warunek końcowy:

Zamówienie jest zapisywane i gotowe do realizacji.

2.6 Główny scenariusz sukcesu

Główny scenariusz sukcesu, zwany również podstawowym przepływem lub ścieżką szczęśliwą, opisuje normalną, udaną interakcję.

Każdy krok powinien opisywać:

1. Interakcję między aktorem a systemem

2. Odpowiedź systemu

3. Znaczącą akcję biznesową

Przykład:

1. Klient wybiera produkty.

2. System wyświetla aktualny koszyk.

3. Klient wprowadza dane dostawy.

4. System weryfikuje dane dostawy.

5. Klient składa zamówienie.

6. System żąda autoryzacji płatności.

7. Brama płatności autoryzuje płatność.

8. System rejestruje zamówienie.

9. System wyświetla potwierdzenie zamówienia.

Unikaj szczegółów specyficznych dla interfejsu, chyba że są one niezbędne dla wymagania.

Słaby krok:

Klient klika niebieski przycisk w prawym dolnym rogu.

Lepszy krok:

Klient składa zamówienie.

2.7 Scenariusze alternatywne

Scenariusz alternatywny opisuje poprawną wariację głównego scenariusza.

Przykłady:

• Klient wybiera odbiór w sklepie zamiast dostawy.

• Klient płaci przy użyciu zapisanej metody płatności.

• Administrator zatwierdza zgłoszenie z warunkami.

• Użytkownik uwierzytelnia się przy użyciu jednorazowego kodu.

Scenariusze alternatywne mogą ponownie dołączyć do głównego przepływu.

Przykład:

A1. Klient używa zapisanej metody płatności
Na kroku 6 klient wybiera zapisaną metodę płatności. System żąda autoryzacji przy użyciu tej metody, a następnie kontynuuje na kroku 7.

2.8 Scenariusze wyjątkowe

Scenariusz wyjątkowy opisuje niepowodzenie lub stan abnormalny.

Przykłady:

• Płatność została odrzucona.

• Produkt jest niedostępny.

• Uwierzytelnianie nie powiodło się.

• Usługa zewnętrzna jest niedostępna.

• Wymagane dane są nieprawidłowe.

Scenariusz wyjątkowy powinien wyjaśniać:

• Gdzie występuje problem

• Co robi system

• Co widzi aktor

• Czy przypadek użycia kończy się, czy wznowia się

Przykład:

E1. Płatność odrzucona
Na kroku 7 bramka płatności odrzuca transakcję. System wyświetla powód, oznacza zamówienie jako nieopłacone i pozwala klientowi wybrać inną metodę płatności.

2.9 Relacje include i extend

include

Użyj include gdy jeden przypadek użycia zawsze wywołuje inne, wielokrotnego użytku zachowanie.

Przykład:

• Złóż zamówienie include Oblicz całkowitą kwotę

• Złóż zamówienie include Uwierzytelnij klienta

• Wypłać gotówkę include Zweryfikuj PIN

Włączone zachowanie jest wymagane.

Złóż zamówienie <<include>> Oblicz całkowitą kwotę

extend

Użyj extend gdy opcjonalne lub warunkowe zachowanie uzupełnia bazowy przypadek użycia.

Przykład:

• Złóż zamówienie może być rozszerzone przez Zastosuj kod rabatowy

• Kasa może być rozszerzona przez Dodaj wiadomość prezentową

Rozszerzające zachowanie nie jest zawsze wykonywane.

Zastosuj kod rabatowy <<extend>> Złóż zamówienie

Przydatna zasada:

• Include: „To zawsze dzieje się jako część przypadku użycia.”

• Extend: „To może się zdarzyć w określonych warunkach.”

Nie używaj include i rozszerz tylko po to, aby podzielić każdy przepływ na małe części. Nadmierna dekompozycja sprawia, że model jest trudny do zrozumienia.

2.10 Uogólnienie

Uogólnienie reprezentuje dziedziczenie między aktorami lub przypadkami użycia.

Przykład:

• Pracownik jest aktorem ogólnym.

• Kierownik jest aktorem specjalistycznym, który dziedziczy zachowanie Pracownika.

Kierownik --|> Pracownik

Stosuj uogólnienie, gdy element specjalistyczny jest naprawdę rodzajem elementu uogólnionego, a nie tylko dlatego, że dwa elementy dzielą kilka kroków.

3. Standardowy szablon opisu przypadku użycia

Poniższy szablon dobrze sprawdza się w dokumentach wymagań, specyfikacjach projektów i modelach analizy.

ID przypadku użycia:
Nazwa przypadku użycia:
Cel:
Zakres:
Poziom:
Główny aktor:
Aktorzy wspierający:
Zainteresowane strony i ich interesy:

Wyzwalacz:

Warunki wstępne:

Minimalne gwarancje:

Gwarancje sukcesu:

Główny scenariusz sukcesu:
1.
2.
3.

Alternatywne przepływy:
A1.
A2.

Przepływy wyjątkowe:
E1.
E2.

Wymagania specjalne:
- Wydajność
- Bezpieczeństwo
- Użyteczność
- Dostępność
- Zgodność

Zasady biznesowe:

Wymagania dotyczące danych:

Częstotliwość i wolumen:

Założenia:

Otwarte pytania:

Powiązane przypadki użycia:

Wyjaśnienie pól

4. Przykład: Złóż zamówienie

UC-001 — Złóż zamówienie

Cel:
Umożliwienie klientowi zakupu jednego lub więcej produktów.

Zakres:
Sklep internetowy

Poziom:
Cel użytkownika

Główny aktor:
Klient

Aktorzy wspierający:

• Brama płatności

• Usługa magazynowa

• Usługa e-mailowa

• Usługa dostawy

Zainteresowane strony i ich interesy:

• Klient: Chce pomyślnie zakupić produkty i otrzymać potwierdzenie.

• Sklep: Chce zarejestrować ważny zamówienie i pobrać płatność.

• Magazyn: Potrzebuje dokładnych informacji o realizacji zamówienia.

• Brama płatności: Potrzebuje ważnego żądania płatności.

• Usługa dostawy: Potrzebuje kompletnego adresu dostawy.

Wyzwalacz:
Klient przesyła koszyk zakupów do finalizacji zamówienia.

Warunki wstępne:

• Klient ma co najmniej jeden przedmiot w koszyku.

• Produkty są dostępne do zamówienia.

• Klient podaje poprawny adres dostawy.

• System może komunikować się z usługą płatności.

Minimalne gwarancje:

• Żadne nieopłacone zamówienie nie jest traktowane jako potwierdzone.

• Klient jest informowany, jeśli zamówienie nie może zostać ukończone.

• Zarezerowane zapasy są zwalniane, jeśli płatność nie powiedzie się.

Gwarancje sukcesu:

• Płatność została autoryzowana.

• Zamówienie zostało zarejestrowane.

• Zapas został rezerwowany.

• Klient otrzymuje potwierdzenie.

• Informacje o realizacji są udostępniane magazynowi.

Główny scenariusz sukcesu

1. Klient przegląda koszyk zakupowy.

2. System wyświetla produkty, ilości, ceny, podatki, koszt dostawy i łączną kwotę.

3. Klient podaje informacje o dostawie.

4. System weryfikuje informacje o dostawie.

5. Klient wybiera metodę płatności.

6. Klient składa zamówienie.

7. System sprawdza dostępność produktów.

8. System żąda autoryzacji płatności od Bramki Płatności.

9. Bramka Płatności autoryzuje płatność.

10. System tworzy zamówienie.

11. System rezerwuje zamówione produkty.

12. System wysyła potwierdzenie zamówienia do klienta.

13. System wyświetla numer zamówienia i przewidywaną datę dostawy.

Scenariusze alternatywne

A1. Klient używa zapisanego adresu

Na kroku 3 klient wybiera wcześniej zapisany adres. System wyświetla adres i przechodzi do kroku 4.

A2. Klient używa zapisanej metody płatności

Na kroku 5 klient wybiera zapisaną metodę płatności. System używa tej metody i przechodzi do kroku 6.

A3. Klient wybiera odbiór w sklepie

Na kroku 3 klient wybiera odbiór w sklepie zamiast dostawy. System wyświetla dostępne sklepy i daty odbioru, a następnie przechodzi do kroku 5.

Scenariusze wyjątkowe

E1. Produkt jest niedostępny

Na kroku 7 system stwierdza, że produkt jest niedostępny. System identyfikuje niedostępny produkt, aktualizuje koszyk i prosi klienta o sprawdzenie zamówienia.

E2. Płatność została odrzucona

Na kroku 9 bramka płatności odrzuca płatność. System nie potwierdza zamówienia, zwalnia rezerwacje magazynowe, wyświetla komunikat o błędzie i pozwala klientowi wybrać inną metodę płatności.

E3. Bramka płatności jest niedostępna

Na kroku 8 bramka płatności nie odpowiada w ramach skonfigurowanego czasu oczekiwania. System oznacza próbę płatności jako oczekującą, informuje klienta i zapobiega podwójnemu złożeniu zamówienia.

Zasady biznesowe

• Zamówienie musi zawierać co najmniej jeden produkt.

• Ilość produktu musi być większa od zera.

• Produktu nie można zamówić, gdy dostępny stan magazynowy jest niewystarczający.

• Płatność musi zostać autoryzowana przed potwierdzeniem zamówienia.

• Ceny i podatki są obliczane zgodnie z aktualnymi zasadami cenowymi.

• Klient może anulować zamówienie wyłącznie przed rozpoczęciem realizacji.

Wymagania szczególne

• Podsumowanie zamówienia powinno być wyświetlane w ciągu dwóch sekund przy normalnym obciążeniu.

• Dane płatności nie mogą być przechowywane w postaci zwykłego tekstu.

• Podwójne zgłoszenia nie mogą tworzyć podwójnych zamówień.

• System musi rejestrować ślad audytowy dla zmian w statusie płatności i zamówienia.

5. Poziomy przypadków użycia

Opisy przypadków użycia mogą być sporządzane na różnych poziomach szczegółowości.

Przypadek użycia na poziomie podsumowania

Przypadek użycia na poziomie podsumowania opisuje szeroki proces biznesowy.

Przykład:

Realizacja zamówienia klienta

Może to obejmować:

• Odbiór zamówienia

• Kompletacja produktów

• Pakowanie zamówienia

• Wysyłka zamówienia

Przypadek użycia na poziomie celu użytkownika

Jest to zazwyczaj najbardziej przydatny poziom do analizy wymagań.

Przykład:

Złóż zamówienie

Opisuje cel, który główny aktor może osiągnąć w jednym posiedzeniu.

Scenariusz użycia na poziomie podfunkcji

Opisuje mniejsze, wielokrotnie wykorzystywane zachowanie systemu.

Przykłady:

• Oblicz całkowitą wartość zamówienia

• Zweryfikuj płatność

• Wygeneruj fakturę

Scenariusze użycia na poziomie podfunkcji są przydatne, gdy zachowanie jest wielokrotnie wykorzystywane lub jest technicznie złożone, ale nie powinny zastępować scenariuszy użycia zorientowanych na cele użytkownika.

6. Pisanie wysokiej jakości opisów scenariuszy użycia

Używaj języka zorientowanego na aktora

Pisz z perspektywy aktora:

Klient składa zamówienie.

Unikaj sformułowań zorientowanych na implementację:

OrderController wywołuje usługę zamówień.

To drugie należy do dokumentacji projektowej, a nie do biznesowego scenariusza użycia.

Zachowaj atomowość każdego kroku

Unikaj łączenia zbyt wielu działań:

Klient wprowadza dane, wybiera płatność, potwierdza zamówienie i otrzymuje e-mail.

Popraw to, rozdzielając interakcję:

1. Klient wprowadza dane dostawy.

2. System weryfikuje dane.

3. Klient wybiera metodę płatności.

4. Klient potwierdza zamówienie.

5. System wysyła potwierdzenie.

Opisuj zachowanie obserwowalne

Czytający powinien być w stanie określić, czy wymaganie zostało zaimplementowane.

Słabe:

System przetwarza żądanie.

Silniejsze:

System weryfikuje żądanie, rejestruje zgłoszenie, przypisuje mu numer zgłoszenia i wyświetla status przesłania.

Unikaj przedwczesnego projektowania interfejsu użytkownika

Zastosuj:

Klient podaje informacje o dostawie.

Zamiast:

Klient wprowadza adres do pola tekstowego i klika zielony przycisk Dalej.

Druga wersja niepotrzebnie ogranicza interfejs.

Zachowaj główny przepływ jako sukces

Nie wypełniaj przepływu podstawowego każdym możliwym błędem. Umieszczaj błędy w przepływach wyjątków.

Identyfikuj reguły biznesowe oddzielnie

Reguły biznesowe często dotyczą wielu przypadków użycia. Ich oddzielne utrzymywanie zapobiega powtarzaniu się niespójnych tekstów.

Zdefiniuj zachowanie w przypadku niepowodzenia w sposób jawny

Dla każdego ważnego niepowodzenia określ:

• Czy dane są zapisywane

• Czy transakcja jest cofana

• Czy aktor może ponowić próbę

• Czy administrator jest powiadamiany

• Czy przypadek użycia kończy się, czy zostaje wznowiony

7. Od wymagań do przypadków użycia

Praktyczny przepływ pracy wygląda następująco:

1. Zidentyfikuj modelowany system.

2. Wymień zewnętrznych aktorów.

3. Zapytaj, co każdy aktor chce osiągnąć.

4. Przekształć każdy cel w nazwę przypadku użycia.

5. Zdefiniuj granice systemu.

6. Opisz główny scenariusz sukcesu.

7. Dodaj przepływy alternatywne i wyjątkowe.

8. Dodaj reguły biznesowe i wymagania specjalne.

9. Narysuj diagram przypadków użycia.

10. Przejrzyj model ze stronami zainteresowanymi.

11. Powiąż przypadki użycia z wymaganiami, testami i artefaktami projektowymi.

Analiza relacji aktor-cel

Przydatnym pytaniem jest:

Jaki wynik biznesowy ten aktor potrzebuje od systemu?

8. Notacja diagramu przypadków użycia

Najczęstsze elementy to:

• Aktor:Rola zewnętrzna

• Przypadek użycia: Możliwość systemu lub cel aktora

• Granica systemu: Zakres systemu

• Zależność: Aktor bierze udział w przypadku użycia

• Zawiera: Wymagane, wielokrotnie wykorzystywane zachowanie

• Rozszerza: Zachowanie opcjonalne lub warunkowe

• Uogólnienie: Specjalistyczny aktor lub przypadek użycia

Diagram przypadków użycia nie powinien próbować przedstawiać:

• Każdy krok procesu

• Tabele bazy danych

• Atrybuty klas

• Szczegółowe reguły biznesowe

• Układy ekranów

• Wewnętrzne algorytmy

Te elementy należą do diagramów aktywności, diagramów klas, diagramów sekwencji lub zapisanych wymagań.

9. Przykład diagramu PlantUML

Poniższy przykład modeluje Złóż zamówienie przypadek użycia i powiązane zachowanie.

@startuml
kierunek od lewej do prawej

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Klient
actor "Brama płatności" jako Płatność
actor "Usługa magazynowa" jako Magazyn
actor "Usługa e-mail" jako E-mail
actor "Usługa dostawy" jako Dostawa

rectangle "Sklep internetowy" {
    usecase "Przeglądaj produkty" jako Przegląd
    usecase "Zarządzaj koszykiem" jako Koszyk
    usecase "Złóż zamówienie" jako ZlozZamowienie
    usecase "Oblicz całkowitą wartość zamówienia" jako ObliczSume
    usecase "Sprawdź dostępność produktu" jako SprawdzStock
    usecase "Autoryzuj płatność" jako AutoryzujPlatnosc
    usecase "Zarezerwuj zapasy" jako ZarezerwujMagazyn
    usecase "Wyślij potwierdzenie zamówienia" jako WyślijPotwierdzenie
    usecase "Śledź zamówienie" jako ŚledzZamowienie
    usecase "Zastosuj kod rabatowy" jako ZastosujRabat
}

Klient --> Przegląd
Klient --> Koszyk
Klient --> ZlozZamowienie
Klient --> ŚledzZamowienie

Płatność --> AutoryzujPlatnosc
Magazyn --> SprawdzStock
Magazyn --> ZarezerwujMagazyn
E-mail --> WyślijPotwierdzenie
Dostawa --> ŚledzZamowienie

ZlozZamowienie ..> ObliczSume : <<include>>
ZlozZamowienie ..> SprawdzStock : <<include>>
ZlozZamowienie ..> AutoryzujPlatnosc : <<include>>
ZlozZamowienie ..> ZarezerwujMagazyn : <<include>>
ZlozZamowienie ..> WyślijPotwierdzenie : <<include>>

ZastosujRabat ..> ZlozZamowienie : <<extend>>

@enduml

Interpretacja

• Ten Klient inicjuje Złóż zamówienie.

• Złóż zamówienie zawsze obejmuje obliczenia, sprawdzanie stanów magazynowych, autoryzację płatności, rezerwację zapasów i potwierdzenie.

• Zastosuj kod rabatowy jest opcjonalne, więc rozszerza Złóż zamówienie.

• Zewnętrzne usługi uczestniczą w określonych zachowaniach systemu.

• Granica systemu to Sklep internetowy prostokąt.

Dokładne rozmieszczenie elementów jest kontrolowane przez silnik renderowania. Ważne decyzje modelowania to aktorzy, przypadki użycia, granice i relacje.

10. Tworzenie diagramu w Visual Paradigm VPasCode

VPasCode to przeglądarkowa platforma tekst-do-diagramu obsługująca PlantUML, Mermaid, Graphviz i inne formaty diagramów. Zapewnia edycję źródła i renderowanie na żywo, umożliwiając aktualizację diagramu w miarę zmian w kodzie.

Podstawowy przepływ pracy

1. Otwórz edytor VPasCode.

2. Utwórz nowy diagram PlantUML.

3. Wklej źródło PlantUML.

4. Potwierdź, że edytor rozpoznaje składnię PlantUML.

5. Przejrzyj podgląd na żywo.

6. Edytuj aktorów, przypadki użycia, relacje i stylowanie w panelu źródłowym.

7. Eksportuj lub skopiuj wyrenderowany diagram.

8. Dodaj diagram do dokumentacji projektu.

VPasCode obsługuje diagramy przypadków użycia PlantUML i oferuje renderowanie w czasie rzeczywistym w przeglądarce. Oferuje również przykłady i opcje stylowania dla diagramów PlantUML.

Przykładowe polecenie do generowania przy użyciu AI

Jeśli korzystasz z funkcji generowania diagramów przy użyciu AI, przydatne polecenie to:

Utwórz diagram przypadków użycia PlantUML dla sklepu internetowego.

Główny aktor:
- Klient

Aktorzy wspierający:
- Bramka płatności
- Usługa magazynowa
- Usługa e-mail
- Usługa dostawcza

Główne przypadki użycia:
- Przeglądaj produkty
- Zarządzaj koszykiem
- Złóż zamówienie
- Śledź zamówienie

Złożenie zamówienia musi obejmować:
- Oblicz całkowitą wartość zamówienia
- Sprawdź dostępność produktu
- Autoryzuj płatność
- Zarezerwuj zapasy
- Wyślij potwierdzenie zamówienia

Zastosowanie kodu rabatowego powinno rozszerzać złożenie zamówienia.

Użyj granicy systemu o nazwie Sklep internetowy.

Traktuj wygenerowany kod jako punkt wyjścia. Przejrzyj, czy:

• Aktorzy są rzeczywiście zewnętrzni

• Scenariusze użycia reprezentują cele użytkownika

• zawierają i rozszerzająsą używane poprawnie

• Granica systemu jest poprawna

• Relacje odzwierciedlają rzeczywiste zachowania biznesowe

VPasCode obsługuje również przełączanie się między edycją diagramów opartą na tekście a graficznymi narzędziami modelowania Visual Paradigm, co może być przydatne, gdy zespoły chcą edycji opartej na kodzie źródłowym w celu wersjonowania oraz edycji wizualnej w celu dopracowania układu.

11. Utrzymywanie diagramów scenariuszy użycia PlantUML

Używaj sensownych aliasów

Aliasy ułatwiają utrzymywanie relacji:

usecase "Złóż zamówienie" jako PlaceOrder
Klient --> PlaceOrder

Dodaj komentarze

' Podstawowa transakcja klienta
usecase "Złóż zamówienie" jako PlaceOrder

Komentarze pomagają innym członkom zespołu zrozumieć źródło i utrzymać diagram.

Utrzymuj skupienie diagramu

Jeśli diagram zawiera zbyt wiele scenariuszy użycia:

• Stwórz diagram kontekstowy

• Stwórz osobne diagramy według obszaru biznesowego

• Używaj grupowania pakietów

• Łącz powiązane diagramy poprzez dokumentację

• Unikaj pokazywania każdej podfunkcji na najwyższym poziomie

Używaj spójnego nazewnictwa

Wybierz jedną konwencję i stosuj ją konsekwentnie:

• Złóż zamówienie

• Anuluj zamówienie

• Śledź zamówienie

Unikaj mieszania stylów, takich jak:

• Złóż zamówienie

• OrderCancellation

• tracking_function

Przechowuj źródło wraz z projektem

Typowa struktura repozytorium może wyglądać następująco:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

Przechowywanie .pumlźródła pod kontrolą wersji umożliwia przeglądanie zmian i ich powtarzalność.

12. Śledzenie

Dojrzały proces wymagań łączy przypadki użycia z innymi artefaktami projektu.

Śledzenie pomaga odpowiedzieć na:

• Które wymagania są objęte?

• Które przypadki użycia nie zostały przetestowane?

• Które elementy projektu wspierają cel biznesowy?

• Co jest zagrożone, jeśli wymaganie ulegnie zmianie?

13. Typowe błędy

Modelowanie wewnętrznych komponentów jako aktorów

Baza danych lub wewnętrzna usługa zazwyczaj nie jest aktorem, jeśli znajduje się wewnątrz granic systemu.

Aktor musi być zewnętrzny w stosunku do systemu, który jest modelowany.

Traktowanie ekranów jako przypadków użycia

Ekran jest elementem interfejsu użytkownika, a niekoniecznie celem użytkownika.

Użyj:

Złóż wniosek o zwrot kosztów

Zamiast:

Ekran wniosku o zwrot kosztów

Używanie include dla każdego wspólnego kroku

Sam fakt wspólnego sformułowania nie uzasadnia użycia przypadku użycia włączonego. Użyj include gdy zachowanie jest obowiązkowe i ma samodzielne znaczenie.

Używanie extend dla normalnych kroków

Jeśli zachowanie zawsze występuje, nie powinno być modelowane jako rozszerzenie.

Opisywanie szczegółów implementacji

Unikaj odwołań do:

• Kontrolerów

• Tabele bazy danych

• Punkty końcowe API

• Klasy

• Metody wewnętrzne

chyba że dokument jest specyficznie projektem technicznym.

Pominięcie zachowania w przypadku błędów

Scenariusz użycia jest niekompletny, jeśli wyjaśnia tylko sukces. Należy uwzględnić odrzucenie płatności, nieprawidłowe dane, przekroczenie czasu oczekiwania, błędy autoryzacji oraz niedostępne zasoby.

Zbyt szerokie scenariusze użycia

„Zarządzanie całym biznesem” nie jest działaniem operacyjnym. Podziel szerokie cele na scenariusze użycia na poziomie celów użytkownika.

Zbyt małe scenariusze użycia

„Walidacja pola” i „Wyświetlenie komunikatu” są zazwyczaj krokami systemowymi, a nie niezależnymi celami aktorów.

14. Lista kontrolna przeglądu

Przed zatwierdzeniem opisu scenariusza użycia sprawdź:

Zakres i aktorzy

• Czy granica systemu jest jasna?

• Czy wszyscy zewnętrzni aktorzy zostali zidentyfikowani?

• Czy aktorzy są rolami, a nie indywidualnymi nazwami?

• Czy systemy wspierające są modelowane tylko wtedy, gdy są zewnętrzne?

Jakość celu

• Czy scenariusz użycia dostarcza wartość głównemu aktorowi?

• Czy nazwa jest wyraźnym frazowym połączeniem czasownika i rzeczownika?

• Czy scenariusz użycia jest na odpowiednim poziomie?

Jakość przepływu

• Czy główny scenariusz opisuje pomyślny wynik?

• Czy każdy krok jest atomowy i obserwowalny?

• Czy ścieżki alternatywne zostały udokumentowane?

• Czy ścieżki wyjątków zostały udokumentowane?

• Czy zachowanie w przypadku odzyskiwania jest jasne?

Warunki i wyniki

• Czy warunki wstępne są testowalne?

• Czy gwarancje sukcesu są jawne?

• Czy zdefiniowano minimalne gwarancje?

• Czy reguły biznesowe są oddzielone od kroków proceduralnych?

Jakość diagramu

• Czy wszystkie przypadki użycia znajdują się w odpowiedniej granicy?

• Czy powiązania aktorów są znaczące?

• Czy ”
  include” są obowiązkowe?

• Czy ”
  extend” są opcjonalne lub warunkowe?

• Czy diagram jest czytelny bez nadmiaru szczegółów?

Jakość wymagań

• Czy każdy ważny krok można przetestować?

• Czy uwzględniono wymagania niefunkcjonalne?

• Czy niezdecydowane pytania zostały odnotowane?

• Czy przypadek użycia jest powiązany z wymaganiami i przypadkami testowymi?

15. Zalecana struktura dostarczanych materiałów

Dla kompletnego pakietu projektu użyj następującej struktury:

1. Kontekst systemu
2. Katalog aktorów
3. Diagram przypadków użycia
4. Katalog przypadków użycia
5. Szczegółowe opisy przypadków użycia
6. Reguły biznesowe
7. Wymagania niefunkcjonalne
8. Macierz śledzenia
9. Otwarte pytania i założenia
10. Pliki źródłowe PlantUML

Silny opis przypadku użycia jest wystarczająco precyzyjny dla analityków, zrozumiały dla interesariuszy i testowalny przez zespół zapewnienia jakości. Najlepszym przepływem pracy jest użycie opisu tekstowego do ustalenia zachowania, diagramu przypadków użycia do komunikowania zakresu i powiązań oraz PlantUML w VPasCode, aby model wizualny był łatwy do edycji i utrzymania.

Źródło

Ten post dostępny jest również w Deutsch, English, Español, فارسی, Français, English, Bahasa Indonesia, Portuguese and Ру́сский