Przypadek użycia (ang. use case) to opis interakcji aktora (użytkownika lub systemu zewnętrznego) z systemem, prowadzącej do celu o wartości dla aktora. Kompletna specyfikacja zawiera: aktora, cel, warunki początkowe, scenariusz główny (happy path), scenariusze alternatywne i wyjątki oraz warunki końcowe. Diagram przypadków użycia należy do UML, ale prawdziwa wartość siedzi w specyfikacji tekstowej - diagram to tylko spis treści.
Analityk pisze przypadki użycia, by udokumentować wymagania funkcjonalne w sposób, który wymusza myślenie o sytuacjach nietypowych. To właśnie rozszerzenia i wyjątki wyłapują luki, których nie widać w jednolinijkowych user stories.
Przykład (MediFlow). UC-03 "Umów wizytę online". Aktor: pacjent. Scenariusz główny, 8 kroków: od wyboru placówki po potwierdzenie SMS. I teraz mięso - rozszerzenia: 4a. brak wolnych terminów u wybranego specjalisty → system proponuje zapis na listę rezerwową lub terminy w pozostałych placówkach sieci; 6a. wybrany slot został w międzyczasie zajęty (ktoś był szybszy o 3 sekundy) → komunikat plus trzy najbliższe alternatywy; 7a. numer telefonu nie przechodzi walidacji → blokada z czytelnym wskazaniem błędu. Każde z tych rozszerzeń to realne wymaganie, które bez struktury use case'a wyszłoby dopiero na testach albo na produkcji.
Częsta pomyłka. Poprzestanie na diagramie - bańki, ludziki, strzałki - bez specyfikacji tekstowej. Diagram z dziesięcioma owalami nie mówi zespołowi nic o tym, co system ma robić, gdy slot jest zajęty. Druga pomyłka: wpisywanie szczegółów interfejsu do kroków ("użytkownik klika zielony przycisk w prawym górnym rogu") - przypadek użycia opisuje intencje i odpowiedzi systemu, a nie wygląd ekranu, bo ten zmieni się pięć razy, zanim ktokolwiek skończy czytać.