O wymaganiach Kilka słów o wymaganiach w projektach informatycznych

Przypadki użycia

Historia powstania przypadków użycia

Ostatnio zastanawialiśmy się, w jaki sposób można zapisać wymagania. Jednym z nieformalnych sposobów są przypadki użycia. Zostały one zaproponowane przez Ivara Jacobsona w latach 80-tych jako opis wymagań dla systemów stosowanych w branży telekomunikacyjnej. W latach 90-tych, gdy powstawały fundamenty notacji UML postanowiono włączyć pana Jacobsona do grona twórców UMLa i w ten sposób przypadki użycia znalazły swoje miejsce jako element tej właśnie notacji. Z jednej strony pozwoliło to przypadkom użycia zyskać na popularności i stać się jednym z popularniejszych sposobów zapisu wymagań (badania pokazują, że przypadki użycia i zapis scenariuszy jest wykorzystywany w ponad 50% projektów). Z drugiej strony jednak UML spowodował, że przypadki użycia zaczęły być kojarzone wyłącznie z diagramami, na których specyfikuje się aktorów oraz funkcje do jakich mają oni dostęp. Oczywiście diagramy są ważne, pozwalają one ogarnąć ogólną wizję funkcjonalności oraz zależności między przypadkami użycia. Przypadki użycia to jednak dużo więcej niż same diagramy - ich istotą są scenariusze interakcji między aktorami systemu.

Podstawowe elementy przypadków użycia

Tak jak wspomniałem powyżej głównym elementem przypadków użycia są scenariusze interakcji (zwane równieżscenariuszami głównymi), gdyż to one niosą za sobą największą wartość jeśli chodzi o wymagania. Co jeszcze w takim razie składa się na przypadek użycia? W podstawowej wersji poza scenariuszem podajemy:

- identyfikator pozwalający w jednoznaczny sposób odwoływać się do przypadku użycia,

- nazwę określającą czego dotyczy dany przypadek użycia,

- aktorów biorących udział w interakcji

- opis wyjątków oraz rozszerzeń dla scenariusza interakcji.

Z czego wynika ten ostatni element? Otóż w głównym scenariuszy podajemy pozytywny przebieg interakcji, czyli np. jeśli opisujemy zakup książki w sklepie internetowym to scenariusz główny kończy się zakupem książki (jest to tzw. "happy day scenario"). Co z przypadkami, gdy np. książki nie ma w naszym sklepie? Właśnie do takich sytuacji wykorzystywana jest sekcje wyjątków i rozszerzeń, w których możemy opisać sytuacje wyjątkowe (np. błędnie podane hasło przez użytkownika, błąd przy nawiązaniu połączenia zdalnego, itp.) oraz rozszerzenia naszego scenariusza głównego (np. gdy książki akurat nie ma w naszym sklepie, lub gdy nasz klient chce kupić więcej niż jedną książkę?).

Poniżej znajdziecie przykład przypadku użycia z wymienionymi wcześniej elementami:

Rozszerzony przypadek użycia

Poza podstawowymi elementami w przypadku użycia można zawszeń:

- wyzwalacze (ang. trigger)  opisujące jakie zdarzenie może wywołać dany przypadek użycia

- warunki początkowe (ang. preconditions) określające jakie warunki muszą być spełnione, aby przypadek użycia mógł zostać wykonany

- warunki końcowe (ang. postconditions) mówiące o tym jakie warunki muszą być spełnione na końcu poprawnego wykonania przypadku użycia

- opis prezentujący skróconą wersję przypadku użycia

- wymagania dodatkowe określające wymagania, które nie zostały zawarte w scenariuszach, a są w jakiś sposób powiązane z przypadkiem użycia

- szkice ekranów prezentujące przykładowy wygląd systemu w danym kroku

- poza tym nazwisko autora przypadku użycia, datę utworzenia, datę ostatniej zmiany, wersję.

Poniżej znajdziecie nasz wcześniejszy przykład poszerzony o elementy dodatkowe:

Dlaczego przypadki użycia są fajne?

Jak widzimy przypadki użycia pisane są w języku naturalnym, co powoduje, że czytelnik nie potrzebuje specjalistycznej wiedzy, aby taki przypadek użycia zrozumieć. Dodatkowo z góry określona struktura ułatwia czytanie, gdyż każde wymagania zapisane jest w taki sam sposób. Pisanie takich przypadków również jest proste - każdy element wymagania ma swoje określone miejsce, więc dość prosto jest skupić się na każdym elemencie i opisać go osobno.

Czy to naprawdę jest takie proste?

Patrząc na powyższe przykłady może się wydawać, że w pisaniu przypadków użycia nie ma nic trudnego,  gdyż korzystamy tutaj z języka naturalnego, który z łatwością pozwala nam wyrażań nasze myśli. Okazuje się, że z przypadkami użycia związana są pewne pułapki, o których należy pamiętać zapisując wymagania właśnie w taki sposób. Różne "zasadzki" oraz dobre praktyki opisane są m.in. w książkach pt. "Patterns for effective use cases" oraz "Writing effective use cases".