Przypadek użycia

Tworzenie przypadków użycia (ang. use case) – technika stosowana w inżynierii oprogramowania w celu opisania wymagań tworzonego systemu informatycznego^[1]. Przypadek użycia przedstawia interakcję pomiędzy aktorem (użytkownikiem systemu), który inicjuje zdarzenie oraz samym systemem jako sekwencję prostych kroków.

Historia

W 1986 Ivar Jacobson, informatyk zaangażowany w tworzenie Unified Modeling Language (UML) oraz Rational Unified Process (RUP) opisał technikę do specyfikowania przypadków użycia. Z początku używał określeń: scenariusz użytkowania (usage scenarios) i przypadki użytkowania (usage case).

W latach 90. przypadki użycia stały się powszechnie stosowanym sposobem opisu wymagań funkcjonalnych.

Opis ogólny

Przypadek użycia powinien:

opisywać w jaki sposób system powinien być używany przez aktora w celu osiągnięcia konkretnego celu
być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika
opisywać system na właściwym poziomie szczegółowości

Pisanie przypadków użycia

Poziom szczegółowości

Alistair Cockburn w swojej książce Writing Effective Use Cases^[2] wyróżnia 3 poziomy szczegółowości przypadków użycia:

nieformalny opis – kilka luźnych zdań ogólnie opisujących przypadek
formalny opis – kilka paragrafów, podsumowanie
pełny opis – formalny dokument

Nazewnictwo

Zaleca się, aby przypadki użycia posiadały nazwy odpowiadające czynnościom, które opisują. Często zaleca się stosowanie wyrażeń rozpoczynających się od czasownika w formie trybu rozkazującego^[3]. Przykładowe nazwy to: „Zarejestruj użytkownika”, „Sprawdź stan konta”.

Ścieżka główna

Przypadek użycia powinien przedstawiać podstawowy przebieg operacji, tzw. szczęśliwą ścieżkę wydarzeń^[4] („basic flow”, „happy flow”).

Przykład:

System prosi Użytkownika o zalogowanie
Użytkownik podaje swój numer identyfikacyjny oraz hasło
System stwierdza poprawność danych
Użytkownik zostaje zalogowany do systemu

Ścieżki alternatywne

Przypadki użycia mogą również zawierać dodatkowe informacje, które opisują sytuacje, gdy nie zachodzi ścieżka optymalna^[5].

Dla powyższego przykładu:

3a. System odrzuca podane dane

3a1. Powrót do kroku 1.

Zobacz też

Przypisy

↑ Glosariusz ITIL wraz ze skrótami. s. 152. [dostęp 2020-04-01].
↑ Writing Effective Use Cases (Efektywne pisanie przypadków użycia) ISBN 0-201-70225-8.
↑ „Podstawowa wiedza do stworzenia diagramu przypadków użycia.”, portal www.uml.com.pl. uml.com.pl. [zarchiwizowane z tego adresu (2016-03-04)]..
↑ Tłumaczenie potoczne.
↑ „Analiza wymagań” – autor Marek Grochowski.

Linki zewnętrzne

usability.gov (ang.)

[1] Glosariusz ITIL wraz ze skrótami. s. 152. [dostęp 2020-04-01].

[2] Writing Effective Use Cases (Efektywne pisanie przypadków użycia) ISBN 0-201-70225-8.

[3] „Podstawowa wiedza do stworzenia diagramu przypadków użycia.”, portal www.uml.com.pl. uml.com.pl. [zarchiwizowane z tego adresu (2016-03-04)]..

[4] Tłumaczenie potoczne.

[5] „Analiza wymagań” – autor Marek Grochowski.

[1]

[2]

[3]

[4]

[5]