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.
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.
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.
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.
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.
Aktor główny: Inicjuje przypadek użycia.
Aktor pomocniczy: Wspiera aktora głównego (np. serwer bankowy).
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.
Warunki, które muszą być spełnione po zakończeniu przypadku użycia.
Przykład: Wypłacono gotówkę, saldo konta zostało zaktualizowane.
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ę.
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.
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.”
Ograniczenia dotyczące zachowania systemu (np. wydajność, bezpieczeństwo, użyteczność).
Przykład: „Transakcja musi zostać zakończona w ciągu 3 sekund.”
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
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.
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.
Opisz idealną, pomyślną drogę.
Klient wybiera „Kasa” z koszyka.
System wyświetla podsumowanie zamówienia.
Klient potwierdza adres wysyłki.
Klient wybiera metodę płatności.
System przetwarza płatność.
Płatność została potwierdzona.
System tworzy zamówienie i generuje potwierdzenie.
Potwierdzenie jest wyświetlone, a e-mail jest wysłany.
Wylicz możliwe odstępstwa od głównego przebiegu.
Alternatywny przebieg A: Niewystarczająca ilość towaru na stanie
System sprawdza stan magazynowy.
Produkt jest niedostępny.
System wyświetla komunikat: „Produkt niedostępny.”
Klient może usunąć produkt lub kontynuować bez niego.
Alternatywny przebieg B: Odrzucenie płatności
Płatność została odrzucona.
System wyświetla błąd: „Płatność odrzucona.”
Klient może spróbować ponownie lub wybrać inną metodę.
Alternatywny przebieg C: Nieprawidłowy adres dostawy
System weryfikuje adres.
Adres jest nieprawidłowy.
System prosi klienta o jego poprawę.
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.
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.
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?”
| 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). |
Utrzymuj przypadki użycia skupione na użytkowniku: Skup się na celach użytkownika, a nie funkcjach systemu.
Używaj spójnej nomenklatury: Używaj formatu czasownik-przecząt (np. „Zaktualizuj profil”).
Unikaj żargonu technicznego: Pisząc dla interesariuszy niebędących specjalistami technicznymi.
Używaj języka potocznego: Bądź jasny i zwięzły.
Iteruj: Udoskonal przypadki użycia wraz z rosnącym zrozumieniem.
Link do innych artefaktów: Połącz przypadki użycia z diagramami klas, przypadkami testowymi i historiami użytkownika.
Priorytet: Najpierw skup się na przypadkach użycia o wysokim znaczeniu lub wysokim ryzyku.
Główny aktor: Klient
Aktory pomocnicze: Serwer bankowy, system wykrywania oszustw
Klient jest zalogowany.
Konto źródłowe ma wystarczające środki.
Limit przelewu nie został przekroczony.
Środki zostały przelane z konta źródłowego na konto docelowe.
Transakcja została zapisana na obu kontach.
Powiadomienie wysłane obu stron.
Klient wybiera „Przelew pieniędzy” z pulpitu.
System wyświetla formularz przelewu.
Klient wprowadza konto docelowe i kwotę.
System weryfikuje konto i kwotę.
Klient potwierdza przelew.
System sprawdza zasady wykrywania oszustw.
Transakcja jest zatwierdzona i wykonana.
Wyświetlana jest wiadomość potwierdzająca.
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.
<>: 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.
Wszystkie przelewy muszą być zapisane i podlegać audytowi.
Czas odpowiedzi ≤ 2 sekundy.
Dane zaszyfrowane podczas przesyłania i w spoczynku.
| 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. |
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.
# 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.
Wypłata gotówki
Klient (właściciel konta bankowego)
Urządzenie bankomatu
Serwer bankowy (system bankowy główny)
Brama płatności (do przetwarzania transakcji)
System wykrywania oszustw
Drukarka (do generowania paragonu)
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.
Klient ma włożoną ważną kartę bankową do bankomatu.
Klient pomyślnie zautoryzował się (wpisał poprawny PIN).
Konto klienta jest aktywne i nie zablokowane.
Bankomat ma wystarczającą ilość gotówki w skrytce.
Konto klienta ma wystarczające dostępne saldo.
Limit wypłat dziennych nie został przekroczony.
Wypłacona jest żądana kwota gotówki klientowi.
Saldo konta klienta jest zmniejszone o wypłaconą kwotę.
W systemie banku tworzony jest rekord transakcji.
Drukowany jest paragon (jeśli został poproszony).
Bankomat rejestruje transakcję w celu audytu i zrównoważenia.
| 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.
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.
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.
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.
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.
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.
| 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 |
| 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). |
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).
[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.)
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).