Use case (przypadek użycia) to opis interakcji między aktorem (użytkownikiem lub systemem zewnętrznym) a systemem, prowadzącej do osiągnięcia konkretnego celu. Pełny przypadek użycia zawiera scenariusz główny (happy path), scenariusze alternatywne i wyjątki, plus warunki wstępne i końcowe.
Analityk sięga po przypadki użycia, gdy trzeba kompletnie opisać zachowanie systemu: przy specyfikacjach dla dostawców, systemach o złożonej logice, integracjach. Siła tej techniki leży w wymuszeniu pytania „a co, jeśli pójdzie inaczej?" - scenariusze alternatywne i wyjątki to miejsca, gdzie mieszka większość błędów produkcyjnych i większość przemilczanych decyzji biznesowych.
Przykład z MediFlow, UC-03 „Pacjent rezerwuje wizytę": scenariusz główny ma 8 kroków, od wyboru specjalizacji po potwierdzenie SMS. Ciekawie robi się w rozszerzeniach: 3a - brak wolnych terminów (propozycja zapisu na listę oczekujących), 5a - pacjent nie ma konta (rezerwacja gościnna z weryfikacją SMS), 7a - płatność za wizytę komercyjną nie przeszła (slot trzymany 15 minut, potem wraca do puli). Każde z tych rozszerzeń to decyzja biznesowa, którą ktoś musiał podjąć. Bez przypadku użycia podjąłby ją developer w trakcie kodowania, o 23:00.
Częsta pomyłka: mylenie use case z user story. Story to krótka obietnica rozmowy, celowo niekompletna; use case to względnie kompletny opis interakcji. To narzędzia na różne sytuacje, nie konkurencja. Druga pomyłka: pisanie wyłącznie scenariusza głównego - przypadek użycia bez wyjątków to wydmuszka, która daje złudzenie kompletności.