​Use case – co to jest?

W projektach IT aż 39% niepowodzeń wynika ze źle zebranych wymagań funkcjonalnych^[1]. Przypadki użycia stanowią podstawę skutecznego projektowania oprogramowania, pomagając zespołom projektowym zrozumieć potrzeby użytkowników i przełożyć je na konkretne funkcjonalności systemu. Ta technika, opisana przez informatyka Ivara Jacobsona w 1986 roku, do dziś pozostaje fundamentem analizy wymagań – a rynek narzędzi UML ma osiągnąć wartość 4,9 mld dolarów w 2024 roku^[2].

Z tego artykułu dowiesz się m.in.:

• Czym jest use case?
• Jaka jest historia use case?
• Jakie są cele use case?
• Jakie są przykłady use case?
• Jaka jest rola use case?

Najważniejsze informacje:

• Use case to ustrukturyzowany opis interakcji między użytkownikiem a systemem, prezentujący sekwencje zachowań prowadzących do osiągnięcia konkretnego celu. Technika ta modeluje funkcjonalności systemu z perspektywy użytkownika, obejmując scenariusz główny oraz ścieżki alternatywne.
• Przypadki użycia stały się powszechną metodą specyfikowania przypadków użycia w latach 90., gdy Ivar Jacobson wraz z Gradym Boochem i Jamesem Rumbaughem stworzyli Unified Modeling Language. Standard został przyjęty przez Object Management Group w 1997 roku.
• Główne cele stosowania przypadków użycia obejmują identyfikację wymagań użytkowników, koncentrację na wartości dla użytkowników końcowych, ułatwienie komunikacji w zespole oraz stanowienie podstawy do tworzenia scenariuszy testowych i walidacji działania systemu.
• Przykłady use case obejmują procesy w sklepie internetowym (składanie zamówienia, przeglądanie produktów), systemy rezerwacyjne (rezerwacja biletu, anulowanie rezerwacji) oraz systemy bankowe (wypłata gotówki z bankomatu, transfer środków między kontami).
• Przypadki użycia pomagają w zrozumieniu wymagań i planowaniu funkcjonalności systemu, działając jako platforma komunikacji między twórcami a interesariuszami. Stanowią graficzne przedstawienie usług świadczonych przez system na zewnątrz systemu.

​Use case – definicja

Przypadek użycia (ang. use case) reprezentuje określoną funkcję systemu inicjowaną przez aktora – czyli użytkownika lub inny system wchodzący w interakcję z oprogramowaniem. Ta technika stosowana w inżynierii oprogramowania pozwala na szczegółowy opis zachowania systemu w odpowiedzi na żądania pochodzące z jego otoczenia. Diagram przypadków użycia składa się z prostych elementów: aktorów symbolizujących role, elips reprezentujących przypadki użytkowania oraz linii pokazujących związki strukturalne między nimi.

Use case to specyfikacja ciągu akcji i ich wariantów, które system może wykonać poprzez interakcję z aktorami, mająca na celu osiągnięcie z góry określonego i przydatnego dla aktora rezultatu.

Definicja use case

Przypadki użycia powinny być zwięzłe, jasne i jednoznaczne, aby uniknąć nieporozumień w zespole. Obejmują one wszystkie sposoby, w jakie można użyć systemu – wliczając ścieżki pomyślne, problematyczne i nieudane. Każdy przypadek użycia powinien mieć jasno sprecyzowany cel, który aktor ma za zadanie osiągnąć w danym momencie interakcji.

​Jaka jest historia use case?

Historia przypadków użycia sięga 1986 roku, gdy informatyk zaangażowany w rozwój metodologii obiektowych – Ivar Jacobson – opisał technikę specyfikacji wymagań. Początkowo używał terminów „scenariusze użytkowania” (usage scenarios) i „przypadki użytkowania” (usage case), co było tłumaczeniem szwedzkiego terminu „användningsfall”. Prezentacja na konferencji OOPSLA’87 w 1987 roku rozpoczęła popularyzację tej metody modelowania.

W latach 90. przypadki użycia stały się powszechnie stosowaną metodą definiowania wymagań funkcjonalnych. Jacobson współtworzył książkę „Object-Oriented Software Engineering – A Use Case Driven Approach” w 1992 roku, która upowszechniła to podejście. Wraz z Gradym Boochem i Jamesem Rumbaughem utworzyli Unified Modeling Language (UML), ustandaryzowany przez Object Management Group w 1997 roku^[3].

Ewolucja tej techniki trwa – w 2011 roku powstała wersja Use Case 2.0 adaptująca metodę do zwinnego wytwarzania oprogramowania, a w 2024 roku opublikowano „The Use-Case Foundation”. Obecnie 72% programistów wykorzystuje UML w procesie tworzenia oprogramowania^[4].

​Jakie są cele use case?

Przypadki użycia służą przede wszystkim identyfikacji i dokumentacji wymagań funkcjonalnych. Pomagają zespołom zrozumieć, jakie funkcjonalności powinien mieć projektowany system oraz jakie przypadki użycia może napotkać użytkownik na swojej drodze. Właściwa identyfikacja aktorów pozostaje istotna dla poprawnego zaprojektowania całego rozwiązania.

Koncentracja na wartości dla użytkownika to drugi istotny cel. Use cases skupiają się na potrzebach użytkowników i na tym, jak najlepiej je zaspokoić. Formułowanie celów w przypadkach użycia kieruje całym procesem projektowym i implementacyjnym w projektach IT. Przypadki użycia powinny zawierać zarówno główny przebieg, jak i ewentualne alternatywne ścieżki.

Trzecim celem jest usprawnienie komunikacji – technika ta ułatwia komunikację między twórcami systemu, inwestorami i właścicielami. Dobrze zdefiniowane przypadki użycia umożliwiają przygotowanie dokładnych scenariuszy testowych. Organizacje stosujące UML odnotowują 40% spadek opóźnień projektowych i 25% wzrost satysfakcji klientów^[5].

Przypadki użycia działają jak most między wymaganiami biznesowymi a rozwiązaniami technicznymi. Dobrze opisany przypadek użycia potrafi zaoszczędzić tygodnie pracy zespołu i miliony złotych w budżecie projektu.

Michał Włodarczyk, Head of Customer Success

​Jakie są przykłady use case?

Oto trzy przykłady use case:

​Składanie zamówienia w e-commerce

W systemach e-commerce przypadek użycia „Złóż zamówienie” ilustruje pełną interakcję klienta z platformą zakupową. Aktor główny – klient – inicjuje proces, wybierając produkty i dodając je do koszyka. Scenariusz główny obejmuje przejście do kasy, wybór metody płatności, potwierdzenie zamówienia oraz przetworzenie transakcji. Scenariusze alternatywne uwzględniają brak środków na koncie, problemy z autoryzacją płatności czy niedostępność produktu. Ten use case obrazuje, jak system powinien działać z punktu widzenia użytkownika końcowego.

​Wypłata gotówki z bankomatu

Przypadek użycia „Wypłać gotówkę” w systemie bankomatowym stanowi klasyczny przykład zastosowania tej techniki. Aktor wkłada kartę, system sprawdza jej poprawność, użytkownik wybiera opcję wypłaty i wprowadza kwotę. Warunki wstępne określają, że karta musi być aktywna, a stan systemu wymaga dostępności środków. Scenariusze alternatywne obejmują nieprawidłowy PIN, brak gotówki w bankomacie lub niewystarczające środki na koncie – każdy z nich ma zdefiniowaną ścieżkę obsługi.

​Rezerwacja biletu na film

W aplikacjach rezerwacyjnych przypadek użycia „Zarezerwuj bilet” demonstruje wieloetapowy proces. Użytkownik musi być zalogowany (warunek wstępny), następnie wybiera film, datę, godzinę i miejsce. System weryfikuje dostępność i przetwarza płatność. Warunki końcowe definiują oczekiwany stan systemu – bilet zostaje przypisany do konta użytkownika, miejsce oznaczone jako zajęte. Przypadki użycia są nieocenione podczas testowania oprogramowania takiego typu, ponieważ pozwalają zweryfikować różne scenariusze użytkownika.

​Jaka jest rola use case?

Przypadki użycia pełnią rolę fundamentalnego narzędzia w analizie i projektowaniu systemów informatycznych. Są podstawą wdrażania oprogramowania, które odpowie na potrzeby użytkowników – pomagają zespołom w zrozumieniu, jakie funkcjonalności powinien mieć projektowany system. W procesie tworzenia przypadków użycia zespoły definiują zachowania od strony użytkownika, co przekłada się na lepsze zrozumienie wymagań.

Aktorzy w przypadku użycia to podmioty wchodzące w interakcję z systemem. Aktor reprezentuje rolę, którą pełni użytkownik w stosunku do systemu – może nim być człowiek, organizacja, program komputerowy lub inny system. Każdy przypadek użycia musi być przyporządkowany minimum jednemu aktorowi, a każdy aktor przyporządkowany jest minimum jednemu przypadkowi użycia.

W kontekście testowania przypadki użycia są nieocenione podczas weryfikacji oprogramowania. Pomagają w weryfikacji, czy system spełnia oczekiwania użytkownika końcowego. Przy 66% projektów technologicznych kończących się częściowym lub całkowitym niepowodzeniem^[6], dobrze opisany przypadek użycia pomaga zrozumieć działanie systemu i minimalizować ryzyko błędów. Przypadki użycia pomagają w identyfikacji funkcji i sposobów ich wykorzystania przez różnych użytkowników, co bezpośrednio wpływa na jakość końcowego produktu.