Deweloper pyta na daily: "a co ma się stać, jak pacjent kliknie potwierdź, ale termin już ktoś zajął?". Cisza. W backlogu jest user story "jako pacjent chcę zarezerwować wizytę", pięć kryteriów akceptacji i ani słowa o kolizji terminów. Sprint się sypie, bo nikt nie spisał scenariuszy alternatywnych.
Dokładnie od tego jest przypadek użycia. To technika, która zmusza Cię do przejścia interakcji użytkownika z systemem krok po kroku - razem ze wszystkim, co może pójść nie tak.
Czym jest przypadek użycia i kiedy działa lepiej niż user story
Przypadek użycia (use case) to opis interakcji między aktorem (użytkownikiem lub innym systemem) a systemem, prowadzącej do celu, który ma wartość dla tego aktora. Nie jest to opis ekranu ani specyfikacja techniczna. To historia dialogu: aktor robi coś, system odpowiada, aktor robi kolejny krok, aż cel zostaje osiągnięty albo coś staje na drodze.
User story mówi kto chce czego i po co. Use case mówi jak dokładnie przebiega droga do tego celu i co się dzieje na zakrętach. Te techniki się nie wykluczają - w wielu zespołach story trafia do backlogu, a use case powstaje dla tych historyjek, w których przebieg jest złożony i pełen wyjątków. Jeśli chcesz porównać oba podejścia od strony user stories, mam o tym osobny tekst: jak pisać user stories.
Kiedy use case wygrywa:
- Proces ma wiele rozgałęzień. Płatności, rezerwacje, obieg wniosków - wszędzie tam, gdzie "happy path" to ułamek rzeczywistości.
- Integrujesz systemy. Aktor nie musi być człowiekiem. System płatności, rejestr PESEL, zewnętrzne API - use case porządkuje, kto inicjuje co i kiedy.
- Pracujesz w projekcie regulowanym lub fixed-price. Bank, ubezpieczyciel, sektor publiczny - tam potrzebujesz kompletnego opisu zachowania, nie obietnicy rozmowy przy tablicy.
- Zespół rozproszony lub dostawca zewnętrzny. Im mniej wspólnych rozmów na żywo, tym więcej musi udźwignąć dokument.
Kiedy odpuścić: prosta zmiana w UI, dodanie pola do formularza, drobna reguła walidacji. Pisanie use case'a na "zmień etykietę przycisku" to marnowanie czasu wszystkich.
Anatomia use case: aktor, cel, warunki wstępne, scenariusz główny, rozszerzenia
Dobry przypadek użycia ma stały szkielet. Kolejność sekcji bywa różna w różnych organizacjach, ale zestaw jest ten sam:
Nazwa - czasownik + dopełnienie, z perspektywy celu aktora: "Zarezerwuj wizytę", "Anuluj zamówienie", "Zgłoś szkodę". Nie "Obsługa wizyt" (to moduł, nie cel) i nie "Ekran rezerwacji" (to UI).
Aktor główny - ten, kto inicjuje interakcję i chce osiągnąć cel. Piszemy rolę, nie stanowisko z HR: Pacjent, Rejestratorka, System płatności.
Interesariusze i ich interesy - często pomijana sekcja, a to ona pilnuje kompletności. Przychodnia chce, żeby terminy się nie dublowały. Lekarz chce widzieć powód wizyty. NFZ chce poprawnych danych rozliczeniowych. Każdy interes musi być gdzieś w scenariuszu obsłużony - jeśli nie jest, masz dziurę.
Warunki wstępne (preconditions) - co musi być prawdą, zanim use case wystartuje. Nie opisujesz tego w krokach, bo system tego nie sprawdza w trakcie - to założenie. Przykład: "Pacjent jest zalogowany i ma uzupełnione dane kontaktowe".
Gwarancje / warunki końcowe (postconditions) - co jest prawdą po sukcesie (wizyta zarezerwowana, termin zablokowany, potwierdzenie wysłane) i co system gwarantuje nawet przy porażce (żaden termin nie wisi zablokowany na zawsze).
Scenariusz główny (main success scenario) - ponumerowana sekwencja kroków od wyzwolenia do osiągnięcia celu. Zawsze najprostsza ścieżka, na której wszystko się udaje.
Rozszerzenia (extensions) - scenariusze alternatywne i wyjątki, podpięte numeracją pod kroki scenariusza głównego. O nich za chwilę, bo to najważniejsza część.
Jak napisać scenariusz główny - przykład: rezerwacja wizyty w przychodni, linia po linii
Zasada numer jeden: każdy krok to jedno zdanie w stronie czynnej, z jawnym podmiotem. Widać, kto działa - aktor czy system. Zasada numer dwa: krok opisuje intencję, nie klikanie. "Pacjent wybiera termin", nie "Pacjent klika w kafelek z godziną 14:30 w widoku kalendarza".
Scenariusz główny dla "Zarezerwuj wizytę":
- Pacjent wybiera specjalizację lekarza.
- System wyświetla lekarzy danej specjalizacji wraz z wolnymi terminami.
- Pacjent wybiera lekarza i termin wizyty.
- System tymczasowo blokuje wybrany termin i prezentuje podsumowanie rezerwacji do potwierdzenia.
- Pacjent potwierdza rezerwację.
- System zapisuje wizytę, zwalnia blokadę na rzecz stałej rezerwacji i wysyła pacjentowi potwierdzenie.
- System wyświetla szczegóły zarezerwowanej wizyty.
Przejdźmy po tym linia po linii, bo w każdym kroku kryje się decyzja projektowa:
- Krok 1-2 to para "żądanie - odpowiedź". Naprzemienny rytm aktor/system to naturalny puls use case'a. Jak masz pięć kroków systemu pod rząd, to prawdopodobnie opisujesz algorytm, nie interakcję.
- Krok 2 nie mówi, czy to lista, kafelki czy kalendarz. UI zostawiasz projektantowi. Dzięki temu use case przeżyje redesign.
- Krok 4 wprowadza blokadę terminu. To decyzja biznesowa przemycona w kroku: dwóch pacjentów nie może potwierdzać tego samego slotu naraz. Gdybyś pisał tylko user story, ta reguła najpewniej wypłynęłaby dopiero na produkcji.
- Krok 6 robi trzy rzeczy naraz i to jest w porządku, bo z perspektywy aktora to jedna odpowiedź systemu. Rozbijanie na trzy kroki dodałoby szumu bez wartości.
- Scenariusz ma 7 kroków. Praktyczny przedział to 3-9. Ponad dziewięć? Sprawdź, czy nie skleiłeś dwóch celów w jeden use case albo nie zszedłeś na poziom klikania.
Scenariusze alternatywne i wyjątki - tu kryje się większość błędów w projektach
Scenariusz główny umie napisać każdy. Wartość analityka biznesowego mierzy się w rozszerzeniach, bo to one wyciągają na stół pytania, na które biznes musi odpowiedzieć przed developmentem, a nie po awarii.
Rozszerzenia numerujesz według kroku, w którym się rozgałęziają: 2a, 4a, 5a. Każde ma warunek (kiedy wchodzi) i własne kroki, które kończą się powrotem do scenariusza głównego albo zakończeniem use case'a.
Dla naszej rezerwacji:
2a. Brak wolnych terminów dla wybranej specjalizacji. 2a1. System informuje o braku terminów i proponuje zapis na powiadomienie o zwolnionym terminie. 2a2. Pacjent zapisuje się na powiadomienie albo kończy. Use case kończy się niepowodzeniem (cel nieosiągnięty, ale interakcja obsłużona).
4a. Wybrany termin został w międzyczasie zajęty. 4a1. System informuje o kolizji i odświeża listę wolnych terminów. 4a2. Powrót do kroku 3.
5a. Pacjent nie potwierdza rezerwacji w czasie trwania blokady. 5a1. System zwalnia blokadę terminu i informuje pacjenta o wygaśnięciu. 5a2. Powrót do kroku 2.
6a. Wysyłka potwierdzenia się nie powiodła. 6a1. System zapisuje wizytę mimo błędu wysyłki i ponawia wysyłkę potwierdzenia. 6a2. Kontynuacja od kroku 7.
Zwróć uwagę na 6a - to jest dokładnie ten typ decyzji, którego nikt nie podejmie świadomie, jeśli nie zada pytania na etapie analizy. Czy błąd SMS-a ma wywalić całą rezerwację? Oczywiście, że nie. Ale w kodzie pisanym bez tej decyzji równie dobrze może wywalać.
Skąd brać rozszerzenia? Przejdź scenariusz główny krok po kroku i przy każdym zadaj trzy pytania: co, jeśli aktor zrobi coś innego? Co, jeśli dane są niepoprawne lub ich brak? Co, jeśli system lub integracja zawiedzie? Do tego dołóż interesy interesariuszy z nagłówka - każdy nieobsłużony interes to kandydat na rozszerzenie.
Jedno ostrzeżenie: nie każdy warunek zasługuje na rozszerzenie. Walidacje pól (e-mail bez małpy, telefon za krótki) lepiej zebrać w jedną regułę biznesową podpiętą pod use case, zamiast produkować 3a-3f o formacie danych.
Poziomy szczegółowości wg Cockburna (cel użytkownika vs podfunkcja) - jak nie przedobrzyć
Alistair Cockburn w "Writing Effective Use Cases" opisał poziomy celów, do których pisze się przypadki użycia. Trzy najbardziej praktyczne:
- Poziom celu użytkownika (sea level) - jeden aktor, jedno posiedzenie, jeden cel z wartością: "Zarezerwuj wizytę", "Anuluj wizytę". Test Cockburna: czy po wykonaniu aktor może wstać od komputera zadowolony? To domyślny poziom - tu powinna lądować zdecydowana większość Twoich use case'ów.
- Poziom podfunkcji (fish level, pod wodą) - fragment potrzebny większym celom: "Wyszukaj lekarza", "Uwierzytelnij użytkownika". Piszesz osobno tylko wtedy, gdy ten sam fragment powtarza się w kilku use case'ach. Inaczej zostaje krokiem.
- Poziom podsumowujący (kite level, nad wodą) - cele długoterminowe spinające wiele posiedzeń: "Prowadź leczenie pacjenta". Przydatny jako mapa kontekstu, nie jako specyfikacja do implementacji.
Najczęstszy błąd? Pisanie wszystkiego na poziomie podfunkcji. Powstaje wtedy dokumentacja typu "Wprowadź dane pacjenta", "Zatwierdź formularz", "Wyświetl komunikat" - dziesiątki mikro-use-case'ów, z których żaden nie niesie celu biznesowego, a całość czyta się jak instrukcję obsługi mikrofalówki. Jeśli nazwa Twojego use case'a nie odpowiada na pytanie "po co aktor w ogóle usiadł do systemu", zszedłeś za nisko.
Drugi błąd to przedobrzenie w głąb: pełny formalny szablon dla każdego przypadku. Cockburn sam rozróżnia format swobodny (casual - parę akapitów prozą) i pełny (fully dressed). Rezerwacja z płatnością i integracjami? Pełny format. Prosty podgląd historii wizyt? Dwa akapity wystarczą. Dobierz ciężar narzędzia do ryzyka.
Use case tekstowy a diagram przypadków użycia UML
Częste nieporozumienie: diagram przypadków użycia w UML to NIE jest przypadek użycia. Diagram pokazuje tylko mapę - aktorzy (ludziki), owale z nazwami use case'ów, granica systemu i relacje między nimi. Cała treść, czyli scenariusze i rozszerzenia, żyje w tekście.
Diagram jest świetny na start warsztatów z interesariuszami: na jednej stronie widać zakres systemu, kto z niego korzysta i czego brakuje ("a gdzie odwołanie wizyty przez rejestratorkę?"). Ale zespół deweloperski z samego diagramu nie zbuduje nic - owal "Zarezerwuj wizytę" nie mówi o blokadzie terminu ani o kolizji slotów.
W praktyce: zacznij od diagramu, żeby uzgodnić zakres i aktorów, potem pisz teksty dla owali w kolejności priorytetów. Z relacjami include/extend na diagramie ostrożnie - to najczęściej nadużywany element notacji i źródło jałowych sporów. Jeśli chcesz ogarnąć diagramy porządnie, zajrzyj do tekstu o diagramach UML w praktyce analityka.
Przypadki użycia (razem ze scenariuszami) to też technika opisana w BABOK Guide, więc pojawia się na egzaminach certyfikacyjnych - jeśli myślisz o certyfikacie, sprawdź porównanie certyfikacji BA.
Gotowy szablon use case + checklista jakości przed przeglądem z interesariuszami
Szablon do skopiowania:
Nazwa: [czasownik + dopełnienie, cel aktora]
Aktor główny: [rola inicjująca]
Interesariusze i interesy:
- [kto]: [czego oczekuje od tej interakcji]
Warunki wstępne: [co musi być prawdą przed startem]
Gwarancja sukcesu: [stan po pomyślnym zakończeniu]
Gwarancja minimalna: [co system gwarantuje nawet przy porażce]
Wyzwalacz: [zdarzenie rozpoczynające]
Scenariusz główny:
1. [Aktor] ...
2. [System] ...
...
Rozszerzenia:
Xa. [warunek]:
Xa1. [krok]
Xa2. [powrót do kroku N / koniec use case'a]
Reguły biznesowe: [odwołania do reguł, np. walidacje]
Wymagania niefunkcjonalne: [jeśli specyficzne dla tego UC]
Kwestie otwarte: [pytania do rozstrzygnięcia]
Checklista jakości - przejdź ją, zanim zaprosisz ludzi na przegląd:
- Nazwa zawiera czasownik i wyraża cel aktora, nie nazwę modułu ani ekranu.
- Aktor główny to rola, a use case kończy się osiągnięciem (lub jawnym nieosiągnięciem) jego celu.
- Scenariusz główny ma 3-9 kroków i naprzemienny rytm aktor-system.
- Każdy krok jest w stronie czynnej z jawnym podmiotem ("System wyświetla...", nie "Wyświetlana jest...").
- Zero szczegółów UI: żadnych przycisków, ekranów, kolorów, pól formularza.
- Każdy krok scenariusza głównego przeszedł trzy pytania: inne działanie aktora? złe dane? awaria?
- Każde rozszerzenie ma warunek i jasne zakończenie (powrót do kroku albo koniec).
- Każdy interes interesariusza z nagłówka jest gdzieś obsłużony.
- Warunki wstępne to założenia, a nie ukryte kroki ("pacjent zalogowany" - tak; "pacjent się loguje" - to krok, nie warunek).
- Poziom celu jednolity - żadnych podfunkcji udających cele użytkownika.
- Walidacje i wyliczenia wyniesione do reguł biznesowych, nie rozpisane jako rozszerzenia.
- Sekcja "kwestie otwarte" jest szczera - lepiej przynieść na przegląd trzy pytania niż trzy ukryte założenia.
Na samym przeglądzie czytaj scenariusz na głos, krok po kroku, i pytaj przy każdym: "czy tak to u Was wygląda?". Interesariusze rzadko przeczytają dokument przed spotkaniem, ale w rozmowie wyłapią błędny krok w dziesięć sekund.
Najlepszy sposób na opanowanie tej techniki to napisanie kilku use case'ów na realnych zadaniach i skonfrontowanie ich z czyimś feedbackiem - samo czytanie nie zbuduje odruchu szukania rozszerzeń. Jeśli chcesz ćwiczyć na praktycznych wyzwaniach z recenzją od innych analityków, załóż darmowe konto na platformie Analify i sprawdź moduł wyzwań oraz peer review.
Najczęstsze pytania
Czy na diagramie przypadków użycia stosować relacje include i extend?
Lepiej nie, ale trzeba je umieć przeczytać - wciąż uczy się ich na kursach i na uczelniach, więc trafisz na nie na cudzych diagramach. Na naszym webinarze z cyklu "projekt e2e" (10 listopada 2025) padły trzy powody, żeby ich nie używać: diagram przypadków użycia nie ma pokazywać wnętrza usługi, dekompozycja przez include łamie hermetyzację, a sam nawyk to pozostałość po projektowaniu strukturalnym, gdzie diagram był mapą funkcji w kodzie. Jeśli ciągnie Cię do wyciągnięcia wspólnego fragmentu w osobny owal, zwykle znaczy to, że schodzisz na poziom podfunkcji - a ten jest po prostu krokiem scenariusza, nie osobnym przypadkiem użycia.
Jak zidentyfikować przypadki użycia i nie rozmnożyć ich bez potrzeby?
Zacznij nie od listy funkcji systemu, tylko od tego, co krąży w procesie biznesowym. Heurystykę, która oszczędza godziny sporów, podał nasz webinar z cyklu "projekt e2e" (10 listopada 2025): jeden dokument, formularz albo komunikat wymieniany na poziomie procesu to jeden przypadek użycia. Przed rozmnożeniem chroni druga bramka, równie prosta: jeśli aktor nie korzysta z danej usługi wprost, to nie jest przypadek użycia i nie ma go na diagramie. Nazwy trzymaj w duchu menu aplikacji: nie "Bilety", tylko "Zakup biletów".
Czym przypadek użycia różni się od mapy procesu biznesowego?
Mapa procesu pokazuje przepływ pracy między rolami: kto co robi, w jakiej kolejności i gdzie droga się rozgałęzia. Przypadek użycia bierze z tego przepływu jedną interakcję i rozpisuje dialog aktora z systemem krok po kroku. W lekcji o modelowaniu wymagań z naszego minikursu oba modele stoją obok siebie celowo: mapa procesu pokazała, że rezerwacja terminu w ogóle istnieje i kto ją obsługuje, a dopiero sekcja rozszerzeń w przypadku użycia wymusiła pytanie, co się dzieje, gdy termin zajmie w międzyczasie ktoś inny. Różne modele łapią różne braki, więc rzadko wybiera się tylko jeden.
Czy przypadki użycia mają sens w Scrumie, skoro zespół pracuje na user stories?
Mają, o ile traktujesz je jako warstwę analizy, a nie konkurencję dla backlogu. W wątku o historyjkach użytkownika na forum Analify przywołano Jarosława Żelińskiego, który przekazywanie historyjek wprost deweloperowi nazywa ogromnym ryzykiem: "Historyjka, nawet w sformalizowanej formie, niesie tylko subiektywne 'spojrzenie z zewnątrz', a programista zaczyna domyślać się i gdybać, niejednokrotnie przekraczając dozwolone granice". Druga noga tego argumentu to klasyfikacja wymagań z BABOK Guide: biznesowe, interesariuszy, rozwiązania i przejściowe. User story dobrze siada na poziomie wymagań interesariuszy, a przypadek użycia dokłada to, co dzieje się przy odmowie, kolizji i awarii - czyli warstwę, której sama historyjka z założenia nie opisuje.