Definicja

Przypadek użycia (ang. Use Case) to technika służąca do przechwytywania wymagań funkcjonalnych systemu. Opisuje on sekwencję kroków, jakie podejmuje system w odpowiedzi na działanie aktora, aby dostarczyć mierzalny rezultat o wartości dla tego aktora. Jest to jeden z najstarszych i najbardziej sprawdzonych sposobów na zdefiniowanie zakresu systemu.

Struktura Przypadku Użycia

Podczas gdy User Story jest celowo lakoniczne, przypadek użycia ma zazwyczaj bardziej ustrukturyzowaną formę (tzw. specyfikacja przypadku użycia):

  1. Aktorzy: Osoby lub systemy zewnętrzne wchodzące w interakcję.
  2. Warunki wstępne: Co musi być spełnione przed startem (np. “Użytkownik jest zalogowany”).
  3. Scenariusz Główny (Happy Path): Optymalna ścieżka prowadząca do sukcesu.
  4. Scenariusze Alternatywne: Obsługa wyjątków i błędów (np. “Błędne hasło”).
  5. Warunki końcowe: Stan systemu po zakończeniu interakcji.

Diagram Przypadków Użycia (UML)

Wizualna reprezentacja przypadków użycia w notacji UML pozwala na szybkie zrozumienie zakresu systemu przez interesariuszy i zespół techniczny.

Kluczowe relacje na diagramie:

  • Include (Zawiera): Gdy jeden przypadek użycia jest niezbędną częścią innego (np. “Zaloguj” jest zawarte w “Złóż zamówienie”).
  • Extend (Rozszerza): Gdy zachowanie jest opcjonalne lub występuje w specyficznych warunkach (np. “Wybierz opakowanie prezentowe” rozszerza “Złóż zamówienie”).

Use Case vs User Story – kiedy co stosować?

W projektach zwinnych te dwie formy często ze sobą współpracują, ale służą innym celom:

Cecha User Story Przypadek użycia
Perspektywa Użytkownika (potrzeba/wartość). Systemowa (interakcja/proces).
Poziom detali Niski (wymaga rozmowy). Wysoki (opisuje kroki).
Zastosowanie Planowanie sprintu, dyskusja. Analiza złożonych procesów, projektowanie testów.
Kiedy stosować? Standardowo w Agile/Scrum. Gdy logika procesu jest skomplikowana.

Przypadki użycia w Inżynierii Wymagań

Zastosowanie przypadków użycia przynosi korzyści na wielu etapach projektu:

  • Definiowanie zakresu: Jasno widać, gdzie kończy się system, a zaczyna rola użytkownika.
  • Baza dla testerów: Scenariusze z przypadków użycia są gotowym fundamentem pod scenariusze testowe.
  • Analiza systemowa: Pomagają analitykowi systemowemu zidentyfikować niezbędne punkty integracji i przepływy danych.

Typowe błędy

  • ❌ Projektowanie interfejsu w opisie – Wpisywanie kroków typu “Użytkownik klika niebieski przycisk” (przypadek użycia powinien być niezależny od konkretnego UI).
  • ❌ Zbyt niski poziom detali – Opisywanie operacji technicznych (np. “System zapisuje w bazie”) zamiast kroków biznesowych.
  • ❌ Ignorowanie aktorów nie-ludzkich – Zapominanie, że aktorem może być inny system, serwer czasu lub harmonogram zadań.

Podsumowanie

Przypadki użycia pozostają nieocenionym narzędziem w arsenale Analityka Biznesowego i Systemowego. Pozwalają one na precyzyjne “rozpisanie” ról w systemie i upewnienie się, że żadna ścieżka błędu nie została pominięta w fazie projektowania oprogramowania.

Powiązane pojęcia:

Kliknij w pojęcie, aby przejść do jego definicji w słowniku