Posted inUML

Kompleksowy przewodnik po rozwoju przypadków użycia: kluczowe koncepcje, metody i przykłady

Wprowadzenie

Rozwój przypadków użycia to kluczowy etap w cyklu życia oprogramowania, szczególnie w kontekście inżynierii wymagań i analizy i projektowania obiektowego. Łączy luki między przypadkami użycia najwyższego poziomu a szczegółowymi specyfikacjami systemu, umożliwiając programistom, analitykom i stakeholderom zrozumienie jaksystem reaguje na konkretne cele użytkownika.

Ten przewodnik zawiera kompleksowy przegląd rozwoju przypadków użycia, w tym jego celu, kluczowych koncepcji, krok po kroku metodyki, najlepszych praktyk i przykładów z rzeczywistego świata.

1. Co to jest rozwój przypadków użycia?

Rozwój przypadków użycia to proces dopracowywania przypadku użycia najwyższego poziomu do szczegółowego, działającego opisu zachowania systemu. Przekształca prostą opowieść o interakcji użytkownika w precyzyjną, testowalną i realizowalną specyfikację.

✅ Cel: Zdefiniować coco system powinien zrobić, jakjak powinien to zrobić, i w jakich warunkach, w wystarczającej szczegółowości dla rozwoju i testowania.

2. Dlaczego rozwój przypadków użycia ma znaczenie

  • Zmniejsza niejasności: Zapobiega nieprawidłowemu rozumieniu wymagań.

  • Ułatwia śledzenie: Łączy wymagania z projektem, kodem i przypadkami testowymi.

  • Wsparcie dla projektowania i implementacji: Stanowi podstawę dla diagramów klas, diagramów sekwencji i projektowania bazy danych.

  • Umożliwia testowanie: Ułatwia tworzenie scenariuszy testowych i kryteriów akceptacji.

  • Poprawia współpracę: Zapewnia wspólną rozumienie między stakeholderami, deweloperami i testerami.

3. Kluczowe koncepcje w rozwoju przypadków użycia

3.1 Przypadek użycia (UC)

Przypadek użycia opisuje sekwencję działań, które system wykonuje, aby osiągnąć wartość dla aktora (użytkownika lub zewnętrznego systemu).

Przykład: „Wypłać gotówkę” z bankomatu.

3.2 Aktor

Zewnętrzna jednostka, która współdziała z systemem. Może to być użytkownik, inny system lub wyzwalacz czasowy.

Przykład: Klient, bankomat, brama płatności.

3.3 Aktor główny i pomocniczy

  • Aktor główny: Inicjuje przypadek użycia.

  • Aktor pomocniczy: Wspiera aktora głównego (np. serwer bankowy).

3.4 Wstępne warunki

Warunki, które muszą być spełnione przed rozpoczęciem przypadku użycia.

Przykład: Użytkownik musi mieć ważną kartę i poprawny PIN.

3.5 Warunki końcowe

Warunki, które muszą być spełnione po zakończeniu przypadku użycia.

Przykład: Wypłacono gotówkę, saldo konta zostało zaktualizowane.

3.6 Główne skuteczne scenariusze (podstawowy przepływ)

Najczęstsza droga przez przypadek użycia prowadząca do sukcesu.

Przykład: Włóż kartę → Wprowadź PIN → Wybierz wypłatę → Wprowadź kwotę → Odbierz gotówkę.

3.7 Alternatywne przepływy (przepływy wyjątków)

Gałęzie w przypadku użycia, które obsługują wyjątki, błędy lub zmiany.

Przykład: Niepoprawny PIN → Spróbuj ponownie lub anuluj.

3.8 Rozszerzenia

Punkty w głównym przepływie, w których można wstawić alternatywne zachowanie (np. za pomocą „<>” w UML).

Przykład: „<>: Powiadom bank o podejrzanych działaniach.”

3.9 Wymagania niiefunkcjonalne (NFRs)

Ograniczenia dotyczące zachowania systemu (np. wydajność, bezpieczeństwo, użyteczność).

Przykład: „Transakcja musi zostać zakończona w ciągu 3 sekund.”

4. Proces szczegółowego opisu przypadku użycia (krok po kroku)

Krok 1: Zidentyfikuj przypadek użycia

Zacznij od przypadku użycia najwyższego poziomu (np. „Złóż zamówienie”).

Użyj szablonu:
Nazwa przypadku użycia: Złóż zamówienie
Główny aktor: Klient
Zainteresowane strony: Klient, system zarządzania zamówieniami, brama płatności

Krok 2: Zdefiniuj warunki wstępne

Wylicz wszystkie warunki, które muszą zostać spełnione przed rozpoczęciem przypadku użycia.

  • Klient jest zalogowany.

  • Koszyk zawiera co najmniej jeden element.

  • Metoda płatności jest zapisana.

Krok 3: Zdefiniuj warunki końcowe

Wymień, co musi być prawdą po zakończeniu przypadku użycia.

  • Zamówienie jest utworzone w systemie.

  • Stan magazynowy jest aktualizowany.

  • Płatność jest przetwarzana.

  • Wysłano e-mail potwierdzający.

Krok 4: Napisz główny scenariusz sukcesu (podstawowy przepływ)

Opisz idealną, pomyślną drogę.

  1. Klient wybiera „Kasa” z koszyka.

  2. System wyświetla podsumowanie zamówienia.

  3. Klient potwierdza adres wysyłki.

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

  5. System przetwarza płatność.

  6. Płatność została potwierdzona.

  7. System tworzy zamówienie i generuje potwierdzenie.

  8. Potwierdzenie jest wyświetlone, a e-mail jest wysłany.

Krok 5: Identyfikacja alternatywnych przebiegów (przypadki wyjątkowe)

Wylicz możliwe odstępstwa od głównego przebiegu.

Alternatywny przebieg A: Niewystarczająca ilość towaru na stanie

  1. System sprawdza stan magazynowy.

  2. Produkt jest niedostępny.

  3. System wyświetla komunikat: „Produkt niedostępny.”

  4. Klient może usunąć produkt lub kontynuować bez niego.

Alternatywny przebieg B: Odrzucenie płatności

  1. Płatność została odrzucona.

  2. System wyświetla błąd: „Płatność odrzucona.”

  3. Klient może spróbować ponownie lub wybrać inną metodę.

Alternatywny przebieg C: Nieprawidłowy adres dostawy

  1. System weryfikuje adres.

  2. Adres jest nieprawidłowy.

  3. System prosi klienta o jego poprawę.

Krok 6: Zdefiniuj rozszerzenia (relacje <>)

Użyj rozszerzeń w stylu UML, aby pokazać zachowanie opcjonalne.

  • <>: Powiadomienie systemu magazynowego

    • Wyzwalacz: Gdy produkt jest niedostępny podczas procesu zakupu.

    • Cel: Ostrzeżenie magazynu o uzupełnieniu zapasów.

  • <>: Zastosuj kupon rabatowy

    • Wyzwalacz: Klient wprowadza poprawny kod kuponu.

    • Cel: Zmniejszenie całkowitej kwoty.

Krok 7: Dodaj wymagania niiefunkcjonalne (NFRs)

Zawieraj ograniczenia systemu.

  • Zamówienie musi zostać przetworzone w ciągu 5 sekund.

  • Płatność musi być szyfrowana przy użyciu TLS 1.3.

  • System musi obsługiwać 10 000 użytkowników równocześnie.

Krok 8: Przegląd i weryfikacja

Współpracuj z interesariuszami, aby zapewnić kompletność i poprawność.

  • Zapytaj: „Czy to obejmuje wszystkie cele użytkownika?”

  • Zapytaj: „Czy zostały rozważone wszystkie przypadki graniczne?”

  • Zapytaj: „Czy deweloper może zbudować na podstawie tego?”

5. Narzędzia i techniki szczegółowego opracowania

Narzędzie/technika Cel
Diagram przypadków użycia (UML) Wizualizuj aktorów i przypadki użycia.
Diagram sekwencji Pokaż przepływ komunikatów między obiektami podczas przypadku użycia.
Diagram aktywności Modeluj złożone przepływy pracy i punkty decyzyjne.
Mapowanie historii użytkownika Łącz przypadki użycia z przebiegiem użytkownika i priorytetami.
Tabele decyzyjne Ujednolij złożoną logikę (np. zasady rabatów).

6. Najlepsze praktyki

  1. Utrzymuj przypadki użycia skupione na użytkowniku: Skup się na celach użytkownika, a nie funkcjach systemu.

  2. Używaj spójnej nomenklatury: Używaj formatu czasownik-przecząt (np. „Zaktualizuj profil”).

  3. Unikaj żargonu technicznego: Pisząc dla interesariuszy niebędących specjalistami technicznymi.

  4. Używaj języka potocznego: Bądź jasny i zwięzły.

  5. Iteruj: Udoskonal przypadki użycia wraz z rosnącym zrozumieniem.

  6. Link do innych artefaktów: Połącz przypadki użycia z diagramami klas, przypadkami testowymi i historiami użytkownika.

  7. Priorytet: Najpierw skup się na przypadkach użycia o wysokim znaczeniu lub wysokim ryzyku.

7. Przykład z życia: Bankowość internetowa – Przelew pieniędzy

Przypadek użycia: Przelew pieniędzy

Główny aktor: Klient
Aktory pomocnicze: Serwer bankowy, system wykrywania oszustw

Wstępne warunki

  • Klient jest zalogowany.

  • Konto źródłowe ma wystarczające środki.

  • Limit przelewu nie został przekroczony.

Warunki końcowe

  • Środki zostały przelane z konta źródłowego na konto docelowe.

  • Transakcja została zapisana na obu kontach.

  • Powiadomienie wysłane obu stron.

Główny scenariusz sukcesu

  1. Klient wybiera „Przelew pieniędzy” z pulpitu.

  2. System wyświetla formularz przelewu.

  3. Klient wprowadza konto docelowe i kwotę.

  4. System weryfikuje konto i kwotę.

  5. Klient potwierdza przelew.

  6. System sprawdza zasady wykrywania oszustw.

  7. Transakcja jest zatwierdzona i wykonana.

  8. Wyświetlana jest wiadomość potwierdzająca.

Alternatywne przepływy

  • A1: Niewystarczające środki
    → System wyświetla: „Niewystarczające środki.”
    → Klient może anulować lub zmienić kwotę.

  • A2: Wykryto oszustwo
    → System blokuje przelew i wysyła ostrzeżenie.
    → Klient musi zweryfikować przez 2FA lub skontaktować się z obsługą.

  • A3: Nieprawidłowy numer konta odbiorcy
    → System wyświetla: „Konto nie zostało znalezione.”
    → Klient może ponownie wpisać lub skorzystać z wyszukiwania konta.

Rozszerzenia

  • <>: Wyślij powiadomienie odbiorcy

    • Wyzwalacz: Przelew zakończony.

    • Cel: Poinformowanie odbiorcy.

  • <>: Nałóż opłatę za przelew

    • Wyzwalacz: Kwota przelewu > 1000 USD.

    • Cel: Odlicz opłatę 5 USD.

Wymagania niefunkcjonalne

  • Wszystkie przelewy muszą być zapisane i podlegać audytowi.

  • Czas odpowiedzi ≤ 2 sekundy.

  • Dane zaszyfrowane podczas przesyłania i w spoczynku.

8. Powszechne pułapki i sposób na ich uniknięcie

Pułapka Rozwiązanie
Zbyt ogólnie (np. „System powinien przetwarzać zamówienia”) Używaj konkretnych, mierzalnych działań.
Zbyt techniczny język Używaj języka potocznego; unikaj słów technicznych lub terminów baz danych.
Brak ścieżek wyjątkowych Używaj alternatywnych przepływów, aby pokryć błędy.
Brak jasnych kryteriów sukcesu Jasno określ postwarunki.
Brak przeglądu ze strony interesariuszy Zaangażuj użytkowników, testerów i analityków biznesowych.

9. Wnioski

Ustalanie przypadków użycia to nie tylko ćwiczenie dokumentacyjne — to proces strategiczny zapewniający, że system spełnia rzeczywiste potrzeby użytkowników z jasnością, precyzją i kompletnością. Systematyczne rozszerzanie przypadków użycia najwyższego poziomu na szczegółowe, wykonalne specyfikacje pozwala zredukować ryzyko, poprawić komunikację i stworzyć solidne podstawy dla skutecznego wdrożenia oprogramowania.

✅ Ostatni poradnik: Traktuj ustalanie przypadków użycia jako iteracyjną rozmowę — nie jako jednorazową czynność. Doskonal go w miarę zdobywania nowych informacji o systemie i jego użytkownikach.

Dodatek: Szablon do ustalania przypadków użycia

# Nazwa przypadku użycia: [np. Aktualizacja profilu]

**Główny aktor**: [np. Klient]  
**Dodatkowi aktorzy**: [np. Baza danych, Usługa e-mail]  
**Interesariusze**: [np. Klient, Zespół wsparcia]

### Warunki wstępne
- [Lista warunków]

### Warunki końcowe
- [Lista wyników]

### Główne scenariusze sukcesu (podstawowy przepływ)
1. [Krok 1]  
2. [Krok 2]  
...

### Alternatywne przepływy
- **A1: [Nazwa]**  
  1. [Krok]  
  2. [Krok]  
- **A2: [Nazwa]**  
  ...

### Rozszerzenia (<<extend>>)
- **<<extend>>: [Nazwa]**  
  - Tryger: [Kiedy]  
  - Cel: [Dlaczego]

### Wymagania niemerytoryczne
- [Wydajność, bezpieczeństwo, użyteczność itp.]

### Uwagi
- [Dodatkowe kontekst lub założenia]

Śledząc ten przewodnik, zespoły mogą opanować sztukę ustalania przypadków użycia i tworzyć systemy, które są nie tylko funkcjonalne, ale także rzeczywiście zgodne z oczekiwaniami użytkowników.

Dodatek – Opis przypadku użycia: Wypłata gotówki z bankomatu:

Nazwa przypadku użycia

Wypłata gotówki

Główny aktor

Klient (właściciel konta bankowego)

Dodatkowi aktorzy

  • Urządzenie bankomatu

  • Serwer bankowy (system bankowy główny)

  • Brama płatności (do przetwarzania transakcji)

  • System wykrywania oszustw

  • Drukarka (do generowania paragonu)

Interesariusze i ich interesy

  • Klient: Chce wypłacić gotówkę w sposób bezpieczny i skuteczny.

  • Bank: Zapewnia integralność transakcji, zapobiega oszustwom i poprawne aktualizacje kont.

  • Operator bankomatu: Zapewnia dostępność maszyny i stan gotówki.

  • Zespół bezpieczeństwa: Monitoruje podejrzane zachowania i zapobiega oszustwom.

Wstępne warunki

  1. Klient ma włożoną ważną kartę bankową do bankomatu.

  2. Klient pomyślnie zautoryzował się (wpisał poprawny PIN).

  3. Konto klienta jest aktywne i nie zablokowane.

  4. Bankomat ma wystarczającą ilość gotówki w skrytce.

  5. Konto klienta ma wystarczające dostępne saldo.

  6. Limit wypłat dziennych nie został przekroczony.

Warunki końcowe

  1. Wypłacona jest żądana kwota gotówki klientowi.

  2. Saldo konta klienta jest zmniejszone o wypłaconą kwotę.

  3. W systemie banku tworzony jest rekord transakcji.

  4. Drukowany jest paragon (jeśli został poproszony).

  5. Bankomat rejestruje transakcję w celu audytu i zrównoważenia.

Główny przypadek sukcesu (podstawowy przepływ)

Krok Działanie systemu Odpowiedź uczestnika
1 Bankomat prosi: „Wprowadź swój PIN.” Klient wprowadza PIN.
2 Bankomat weryfikuje PIN przy użyciu serwera bankowego. System potwierdza, że PIN jest poprawny.
3 Bankomat wyświetla menu główne: „Wypłać gotówkę, Sprawdź saldo, Przelej, Wyjdź.” Klient wybiera „Wypłać gotówkę.”
4 Bankomat prosi: „Wprowadź kwotę do wypłaty.” Klient wprowadza kwotę (np. 100 $).
5 Bankomat weryfikuje:

  • Kwota mieści się w dziennym limicie.

  • Konto ma wystarczające środki.

  • Bankomat ma wystarczającą ilość gotówki. | System potwierdza ważność. |
    | 6 | Bankomat prosi o autoryzację serwera bankowego. | Serwer bankowy zatwierdza transakcję. |
    | 7 | Bankomat wypłaca gotówkę z sejfu. | Klient otrzymuje gotówkę. |
    | 8 | Bankomat prosi: „Czy chcesz paragon?”. | Klient wybiera „Tak” lub „Nie”. |
    | 9 | Jeśli „Tak”: bankomat drukuje paragon z:

  • Data/czas

  • Kwota wypłacona

  • Pozostała kwota

  • Identyfikator transakcji | Klient zbiera paragon. |
    | 10 | Bankomat wyświetla: „Dziękujemy. Proszę wyjmij kartę.” | Klient wyjmuje kartę. |
    | 11 | Bankomat powraca do stanu gotowości. | System jest resetowany. |

✅ Wynik sukcesu: Klient otrzymuje gotówkę i (opcjonalnie) paragon. Konto jest aktualizowane.

Alternatywne przebiegi (scenariusze wyjątkowe)

A1: Wprowadzono nieprawidłowy PIN (3 próby)

  • Wyzwalacz: Klient wprowadza niepoprawny PIN trzy razy.

  • Działanie systemu: Bankomat blokuje kartę i wyświetla: „Karta zablokowana. Skontaktuj się z bankiem.”

  • Działanie uczestnika: Klient kończy działanie i kontaktuje się z bankiem.

  • Warunek końcowy: Karta jest tymczasowo zablokowana; transakcja jest zapisana.

⚠️ Uwaga: Jest to środek bezpieczeństwa zapobiegający nieautoryzowanemu dostępowi.

A2: Niewystarczające środki

  • Wyzwalacz: Klient wprowadza kwotę przekraczającą dostępne saldo.

  • Działanie systemu: ATM wyświetla: „Niewystarczające środki. Aktualne saldo: $X.”

  • Działanie uczestnika: Klient wybiera „Anuluj” lub wprowadza mniejszą kwotę.

  • Warunek końcowy: Brak wypłaty gotówki; żadna zmiana konta.

A3: Niewystarczające środki w bankomacie

  • Wyzwalacz: Klient wprowadza poprawną kwotę, ale skarbonka bankomatu jest pusta lub poniżej minimalnej ilości.

  • Działanie systemu: ATM wyświetla: „Gotówka niedostępna. Spróbuj ponownie później.”

  • Działanie uczestnika: Klient anuluje lub wraca później.

  • Warunek końcowy: Transakcja nie została przetworzona; żadna zmiana konta.

A4: Kwota wypłaty przekracza limit dzienny

  • Wyzwalacz: Klient próbuje wypłacić więcej niż limit dzienny (np. 1000 $).

  • Działanie systemu: ATM wyświetla: „Przekroczono limit wypłat dziennych. Spróbuj mniejszą kwotę.”

  • Działanie uczestnika: Klient zmniejsza kwotę lub anuluje.

  • Warunek końcowy: Transakcja nie została przetworzona.

A5: Transakcja odrzucona przez serwer banku

  • Wyzwalacz: Serwer bankowy odrzuca transakcję (np. z powodu ostrzeżenia o oszustwie, zablokowanie konta).

  • Działanie systemu: ATM wyświetla: „Transakcja została odrzucona. Skontaktuj się z bankiem.”

  • Działanie uczestnika: Klient anuluje i kontaktuje bank.

  • Warunek końcowy: Brak wypłaty gotówki; brak zmiany konta.

Rozszerzenia (<> relacje)

Rozszerzenie Wyzwalacz Cel
<>: Powiadom system wykrywania oszustw Gdy wypłata jest dokonywana w obcym kraju lub przekracza typowe zachowanie Zaznacz podejrzane działania do przeglądu
<>: Wyślij powiadomienie SMS do klienta Po pomyślnej wypłacie Poinformuj klienta o transakcji (zwiększone bezpieczeństwo)
<>: Naładuj opłatę za wypłatę Dla niepodstawowych właścicieli kont lub niektórych typów kont Naładuj opłatę za określone usługi
<>: Wydrukuj historię transakcji Jeśli klient wybierze „Wydrukuj historię” w menu Zaoferuj wydrukowany podsumowanie ostatnich transakcji

Wymagania niiefunkcjonalne (NFRs)

Kategoria Wymaganie
Wydajność Transakcja musi zostać przetworzona w ciągu 3 sekund.
Bezpieczeństwo Wszystkie komunikaty są szyfrowane (TLS 1.3). PIN nigdy nie jest przechowywany ani przesyłany w postaci jawnej.
Niezawodność Bankomat nie może wypłacać gotówki, chyba że serwer bankowy potwierdzi autoryzację.
Użyteczność Interfejs musi być dostępny (np. duże przyciski, przewodnictwo głosowe dla osób niewidomych).
Dostępność Bankomat musi być w pełni działający 99,9% czasu.
Audyt i zgodność Wszystkie transakcje muszą być zapisane i śledzone przez 7 lat (zgodnie z przepisami bankowymi).

Uwagi

  • Bankomat musi być regularnie konserwowany, aby zapewnić dostępność gotówki i niezawodność sprzętu.

  • Jeśli karta nie zostanie wyjęta w ciągu 30 sekund po zakończeniu transakcji, zostanie automatycznie zatrzymana (funkcja antykradzieżowa).

  • System obsługuje wiele walut i oblicza kursy wymiany (jeśli dotyczy).

Diagram przypadków użycia (podsumowanie UML)

[Klient] --(Wypłać gotówkę)--> [Bankomat]
[Bankomat] --(Zweryfikuj PIN)--> [Serwer bankowy]
[Bankomat] --(Sprawdź środki)--> [Serwer bankowy]
[Bankomat] --(Wypłać gotówkę)--> [Skarbiec z gotówką]
[Bankomat] --(Drukuj paragon)--> [Drukarka]
[Bankomat] --(Powiadom system o oszustwie)--> [System wykrywania oszustw]

(Uwaga: w pełnym diagramie UML relacje przypadków użycia typu <> i <> byłyby wyświetlane.)

✅ Podsumowanie

To rozbudowany przypadek użycia dla „Wypłata gotówki” zapewnia jasne, strukturalne i testowalne specyfikacje, które:

  • Zbiera cele użytkownika i zachowanie systemu.

  • Obsługuje rzeczywiste wyjątki.

  • Wspiera bezpieczeństwo, zgodność i użyteczność.

  • Stanowi podstawę dla projektowania, testowania i wdrożenia.

Jest odpowiedni do użycia w sprintach agile, dokumentach projektowych systemu lub formalnych specyfikacjach wymagań.

📘 Kolejne kroki:

  • Przekształć to w diagram sekwencji pokazywać interakcje obiektów.

  • Utwórz przypadki testowe na podstawie każdego przepływu (głównego i alternatywnego).

  • Link do diagramy klas (np. Konto, Transakcja, Bankomat, Wykrywacz oszustw).