Czym jest przypadek użycia (use case)? Definicja, przykłady i diagram

Definicja przypadków użycia

Przypadki użycia (ang. Use Cases) to opisy interakcji pomiędzy użytkownikiem (aktorem) a systemem informatycznym, które mają na celu osiągnięcie konkretnego celu. Przypadki użycia przedstawiają, w jaki sposób system powinien reagować na bodźce zewnętrzne, umożliwiając zrozumienie funkcjonalności systemu z perspektywy użytkownika. Są kluczowym elementem w procesie analizy wymagań i projektowania systemów, pomagając w zrozumieniu potrzeb użytkowników oraz komunikacji między zespołem projektowym a interesariuszami.

Koncepcję przypadków użycia wprowadził Ivar Jacobson, który pracował nad nią w Ericssonie w latach 80., przedstawił ją szerzej na konferencji OOPSLA w 1987 roku, a następnie rozwinął w książce „Object-Oriented Software Engineering: A Use Case Driven Approach” (1992). Od tego czasu przypadki użycia stały się jednym z fundamentalnych narzędzi inżynierii oprogramowania, włączonym do standardu UML (Unified Modeling Language) i szeroko stosowanym w metodologiach takich jak RUP (Rational Unified Process).

Historia przypadków użycia

Po artykule Jacobsona z OOPSLA 1987 („Object-Oriented Development in an Industrial Environment”) i jego książce z 1992 roku przypadki użycia stały się częścią metod obiektowych. Gdy Jacobson, Grady Booch i James Rumbaugh połączyli swoje metody w UML, diagramy przypadków użycia weszły do standardu, który Object Management Group przyjęła w 1997 roku. Książka Alistaira Cockburna „Writing Effective Use Cases” (Addison-Wesley, 2001) ukształtowała sposób ich pisania — to z niej pochodzą poziomy celów i format „fully dressed”, z którego korzysta dziś większość zespołów. W 2011 roku Jacobson, Ian Spence i Kurt Bittner opublikowali „Use-Case 2.0”, dostosowując technikę do pracy zwinnej: przypadki użycia dzieli się na „plastry” (slices) na tyle małe, by mieściły się w sprincie.

Znaczenie przypadków użycia w projektowaniu systemów

Przypadki użycia pełnią kilka kluczowych funkcji w procesie wytwarzania oprogramowania:

• Definiowanie wymagań funkcjonalnych — opisują co system powinien robić z perspektywy użytkownika, nie jak to robi technicznie
• Wspólny język — zapewniają pomost komunikacyjny między osobami technicznymi i biznesowymi
• Podstawa do testowania — każdy przypadek użycia może być bezpośrednio przełożony na scenariusze testowe
• Planowanie pracy — umożliwiają szacowanie pracochłonności i priorytetyzację funkcji
• Identyfikacja ryzyk — analiza scenariuszy alternatywnych i wyjątkowych pomaga wykryć potencjalne problemy
• Dokumentacja systemu — stanowią cenną dokumentację funkcjonalności systemu dla przyszłych zespołów

Kluczowe elementy przypadków użycia

Aktorzy (Actors)

Aktor to osoba, system lub urządzenie, które wchodzi w interakcję z systemem:

• Aktor główny (primary actor) — inicjuje przypadek użycia i osiąga cel (np. Klient, Administrator)
• Aktor pomocniczy (supporting actor) — wspiera realizację przypadku użycia (np. System płatności, Serwer e-mail)
• Aktor pasywny (offstage actor) — interesariusz, który nie uczestniczy bezpośrednio, ale jest zainteresowany wynikiem (np. Audytor, Regulator)

Scenariusze

• Scenariusz główny (main success scenario) — opis „happy path” — idealnego przebiegu od wyzwolenia do osiągnięcia celu
• Scenariusze alternatywne (alternative flows) — inne dozwolone ścieżki prowadzące do celu (np. logowanie przez SSO zamiast hasła)
• Scenariusze wyjątkowe (exception flows) — ścieżki obsługi błędów i sytuacji nietypowych (np. nieprawidłowe hasło, brak połączenia)

Warunki

• Warunki wstępne (preconditions) — stan systemu wymagany przed rozpoczęciem przypadku użycia (np. „Użytkownik jest zalogowany”)
• Warunki końcowe (postconditions) — stan systemu po pomyślnym zakończeniu przypadku użycia (np. „Zamówienie zostało złożone i zapisane w bazie”)
• Gwarancje minimalne — co system gwarantuje nawet w przypadku niepowodzenia (np. „Dane nie zostały uszkodzone”)

Wyzwalacze (Triggers)

Zdarzenie inicjujące przypadek użycia — np. „Klient klika przycisk Złóż zamówienie” lub „System otrzymuje żądanie API”.

Formaty przypadków użycia

Przypadki użycia mogą być dokumentowane na różnych poziomach szczegółowości:

Format zwięzły (Brief)

Jednozdaniowe lub kilkuzdaniowe podsumowanie. Stosowane na wczesnym etapie analizy:

UC-001: Złożenie zamówienia — Klient wybiera produkty, podaje dane dostawy i dokonuje płatności. System potwierdza zamówienie i wysyła potwierdzenie e-mailem.

Format nieformalny (Casual)

Kilka akapitów opisujących główny scenariusz i kluczowe warianty. Dobry dla komunikacji z interesariuszami biznesowymi.

Format pełny (Fully Dressed)

Najbardziej szczegółowy format, zawierający wszystkie elementy strukturalne:

Element	Opis
ID	Unikalny identyfikator (np. UC-001)
Nazwa	Zwięzła, zorientowana na cel (np. „Złóż zamówienie”)
Aktor główny	Kto inicjuje (np. Klient)
Interesariusze	Lista zainteresowanych stron i ich cele
Warunki wstępne	Wymagany stan systemu
Warunki końcowe	Stan po sukcesie
Scenariusz główny	Numerowane kroki happy path
Rozszerzenia	Warianty i wyjątki (np. 3a. Jeśli hasło nieprawidłowe…)
Wymagania specjalne	NFR — wydajność, bezpieczeństwo, dostępność
Częstotliwość	Jak często przypadek jest wykonywany
Priorytet	Ważność biznesowa

Przykład pełnego przypadku użycia

UC-005: Rezerwacja sali konferencyjnej

• Aktor główny: Pracownik

• Warunki wstępne: Pracownik jest zalogowany w systemie rezerwacji

• Scenariusz główny:

  1. Pracownik wybiera datę i zakres godzin
  2. System wyświetla dostępne sale spełniające kryteria
  3. Pracownik wybiera salę i podaje temat spotkania
  4. Pracownik dodaje uczestników
  5. System weryfikuje dostępność sali w wybranym terminie
  6. System tworzy rezerwację i wysyła zaproszenia do uczestników
  7. Pracownik otrzymuje potwierdzenie rezerwacji

• Rozszerzenia:

  • 2a. Brak dostępnych sal — system sugeruje alternatywne terminy
  • 5a. Sala została zarezerwowana w międzyczasie — system informuje i wraca do kroku 2
  • 4a. Pracownik dodaje wymaganie (np. projektor, wideokonferencja) — system filtruje sale

• Warunki końcowe: Rezerwacja zapisana, zaproszenia wysłane, sala zablokowana w kalendarzu

Przykłady przypadków użycia

Dwa krótkie przykłady pokazują, jak ta sama struktura działa dla różnych celów.

Wypłać gotówkę (bankomat). Aktor główny: klient banku. Aktor pomocniczy: system centralny banku. Warunek wstępny: bankomat jest sprawny. Scenariusz główny: (1) klient wkłada kartę; (2) system prosi o PIN; (3) klient wpisuje PIN; (4) system weryfikuje go w systemie centralnym; (5) klient wybiera kwotę; (6) system sprawdza saldo i wydaje gotówkę; (7) system zwraca kartę i na życzenie drukuje potwierdzenie. Scenariusze alternatywne i wyjątkowe: błędny PIN (3a, z limitem prób), brak środków (6a), brak gotówki w bankomacie (6b), zatrzymanie karty po zbyt wielu błędnych próbach. Warunek końcowy: konto jest obciążone tylko wtedy, gdy gotówka została wydana.

Wygeneruj miesięczny raport dla regulatora (aktor systemowy). Aktor główny: harmonogram — aktor wyzwalany czasem, a nie osoba. Scenariusz główny: pierwszego dnia roboczego miesiąca system pobiera dane, waliduje je względem schematu regulatora, generuje plik i go wysyła. Scenariusz wyjątkowy: walidacja się nie udaje, system wstrzymuje wysyłkę i tworzy zadanie dla działu compliance. Takie przypadki użycia łatwo pominąć na warsztatach skupionych na ludziach — a często wiążą się z ustawowymi terminami.

Przypadki użycia a modele procesów biznesowych

Przypadek użycia opisuje cel jednego aktora w systemie. Proces biznesowy obejmuje wielu aktorów, działy i często kilka systemów — od zgłoszenia reklamacji po zwrot pieniędzy i analizę jakości. Oba poziomy się uzupełniają: model procesu pokazuje kolejność pracy i przekazania, a każde zadanie użytkownika w procesie jest kandydatem na przypadek użycia. W przewodniku BPMN 2.0 w praktyce pokazujemy, jak opisać poziom procesu przed zamówieniem oprogramowania, a w artykule o wymaganiach funkcjonalnych i niefunkcjonalnych — wymagania, których same przypadki użycia nie obejmują: wydajność, bezpieczeństwo i dostępność.

Diagramy przypadków użycia (UML)

Diagramy przypadków użycia to graficzne reprezentacje w standardzie UML, które wizualizują relacje między aktorami a systemem:

Elementy diagramu

• Aktor — figurka człowieka (stick figure) z nazwą
• Przypadek użycia — elipsa z nazwą
• Granica systemu — prostokąt otaczający przypadki użycia
• Asocjacja — linia łącząca aktora z przypadkiem użycia

Relacje między przypadkami użycia

• Include (zawiera) — jeden przypadek użycia zawsze wywołuje inny (np. „Złóż zamówienie” include „Zweryfikuj dane karty”)
• Extend (rozszerza) — opcjonalne rozszerzenie zachowania (np. „Złóż zamówienie” extend „Zastosuj kod rabatowy”)
• Generalizacja — hierarchia aktorów lub przypadków (np. „Klient Premium” dziedziczy po „Klient”)

Kiedy stosować diagramy vs. opisy tekstowe

• Diagramy — do prezentowania ogólnego zakresu systemu, komunikacji ze stakeholderami, przeglądu funkcjonalności
• Opisy tekstowe — do szczegółowej specyfikacji zachowania, podstawy do implementacji i testów
• Najlepsza praktyka — diagram jako „mapa”, opisy tekstowe jako „szczegółowe instrukcje”

Przypadki użycia w różnych metodologiach

W modelu kaskadowym (Waterfall)

• Przypadki użycia tworzone są w fazie analizy wymagań
• Stanowią formalny dokument zatwierdzany przez stakeholderów
• Są podstawą do projektowania, implementacji i testowania

W Agile / Scrum

Przypadki użycia są powiązane z User Stories, ale się od nich różnią:

Aspekt	Przypadek użycia	User Story
Szczegółowość	Wysoka — pełne scenariusze	Niska — „jako X chcę Y aby Z”
Zakres	Kompletna interakcja	Fragment funkcjonalności
Format	Ustrukturyzowany	Swobodny, z kryteriami akceptacji
Kiedy	Faza analizy	Refinement / planning
Rozmiar	Duży (wiele stories)	Mały (1 sprint)

W praktyce Agile, przypadki użycia mogą być rozbijane na user stories podczas backlog refinementu. Jeden przypadek użycia = kilka do kilkunastu user stories. Podejście Use-Case 2.0 formalizuje to rozbicie: scenariusz główny i ważne scenariusze alternatywne stają się osobnymi „plastrami” i historyjkami, a scenariusze wyjątkowe — kryteriami akceptacji.

W BDD (Behavior Driven Development)

Przypadki użycia naturalnie przekładają się na scenariusze BDD w formacie Gherkin:

Given [warunek wstępny]
When [akcja aktora]
Then [oczekiwany rezultat]

Narzędzia do tworzenia przypadków użycia

Narzędzia do modelowania UML

• Enterprise Architect — kompletne narzędzie UML, popularne w korporacjach
• Visual Paradigm — modelowanie UML z generowaniem dokumentacji
• PlantUML — diagramy jako kod (text-based), integracja z IDE
• draw.io (diagrams.net) — darmowe, przeglądarkowe narzędzie do diagramów
• Lucidchart — kolaboracyjne diagramy online

Narzędzia do zarządzania wymaganiami

• Jira — z użyciem epic/story hierarchy i pluginów (np. Requirements Yogi)
• Confluence — szablony przypadków użycia
• Azure DevOps — Work Items z typem „Use Case”
• IBM DOORS — enterprise’owe zarządzanie wymaganiami

Wyzwania i pułapki

Częste błędy

• Za dużo szczegółów UI — opisywanie elementów interfejsu zamiast interakcji i celów; przypadek użycia nie powinien mówić „kliknij przycisk Zapisz”, lecz „Użytkownik zatwierdza dane”
• Zbyt niski poziom — opisywanie operacji CRUD zamiast celów biznesowych
• Brak scenariuszy alternatywnych — skupienie się wyłącznie na happy path; scenariusze wyjątkowe często zajmują 80% kodu
• Za dużo przypadków — próba opisania każdej drobnej interakcji; fokus na kluczowe funkcjonalności
• Język techniczny — przypadki użycia powinny być zrozumiałe dla osób nietechnicznych
• Brak aktualizacji — przypadki użycia stają się bezwartościowe, jeśli nie są aktualizowane wraz z ewolucją systemu

Kiedy NIE stosować przypadków użycia

• Bardzo małe projekty, gdzie User Stories wystarczą
• Prototypy i POC, gdzie formalna dokumentacja spowalnia
• Systemy batch/ETL bez interakcji użytkownika (lepsze: diagramy sekwencji lub procesów)

Przypadki użycia w kontekście IT consulting

W projektach realizowanych z udziałem zewnętrznych specjalistów (staff augmentation) przypadki użycia pełnią szczególną rolę:

• Onboarding — pomagają nowym członkom zespołu szybko zrozumieć funkcjonalność systemu
• Komunikacja klient-dostawca — zapewniają wspólne rozumienie zakresu projektu
• Estymacja — umożliwiają precyzyjniejsze szacowanie pracochłonności
• Walidacja — stanowią podstawę do weryfikacji, czy dostarczone oprogramowanie spełnia wymagania
• Transfer wiedzy — ułatwiają przekazanie systemu między zespołami

Analitycy biznesowi i systemowi z doświadczeniem w tworzeniu przypadków użycia są jednymi z najczęściej poszukiwanych specjalistów w projektach IT consulting, szczególnie w sektorach regulowanych (bankowość, telekomunikacja, administracja publiczna).

Najlepsze praktyki

• Pisz z perspektywy aktora — „Klient wprowadza adres dostawy”, nie „System przyjmuje adres”
• Nazywaj zorientowane na cel — „Złóż zamówienie”, nie „Formularz zamówienia” czy „Moduł zamówień”
• Utrzymuj spójny poziom abstrakcji — nie mieszaj celów strategicznych z operacjami CRUD
• Numeruj kroki — ułatwia referencje w scenariuszach alternatywnych i testach
• Angażuj stakeholderów — waliduj przypadki użycia z użytkownikami końcowymi i ekspertami domenowymi
• Iteruj — przypadki użycia ewoluują; pierwsza wersja rzadko jest ostateczna
• Łącz z testami — każdy scenariusz powinien mieć odpowiadający mu test akceptacyjny
• Stosuj szablony — standaryzacja formatu ułatwia tworzenie i przeglądanie

Podsumowanie

Przypadki użycia to sprawdzone i wciąż aktualne narzędzie inżynierii oprogramowania, które pomaga organizacjom definiować, komunikować i weryfikować wymagania funkcjonalne systemów informatycznych. Ich siła tkwi w prostym, zorientowanym na użytkownika podejściu, które jest zrozumiałe zarówno dla osób technicznych, jak i biznesowych. Choć w erze Agile częściowo zastępowane przez user stories, przypadki użycia zachowują swoją wartość w projektach o złożonej logice biznesowej, wymaganiach compliance i kontekstach, gdzie formalna dokumentacja jest niezbędna. Umiejętność tworzenia dobrych przypadków użycia pozostaje cenną kompetencją analityków biznesowych i systemowych.