Moim zdaniem błędem wielu projektantów programów (systemów) jest mniemanie, że projektują “biznes”. Nie! Projektują narzędzie biznesu a to jest istotna różnica. Krawiec nie modeluje i nie szyje człowieka tylko projektuje i szyje to, co człowiek na siebie założy, dlatego dobry garnitur musi mieć rozporek ale już nie koniecznie kieszeń na papier toaletowy. Jednak ten manekin musi być “taki jak człowiek”, model biznesu w oprogramowaniu także.

Kiedy i po co modelują?

Co to są te przypadki użycia? Najogólniej to lista czynności, które opisujemy tak by programista na ich podstawie wiedział jakie funkcjonalnosci ma realizować program. Moja praca nie raz dotyczy wykonania specyfikacji wymagań na system IT a to często są właśnie przypadki użycia. Praca moja na przypadkach użycia się kończy. Dalej już programiści a ja nim nie jestem. Ale do rzeczy. Opis przypadków użycia jest tak na prawdę zbiorem podstawowych wymagań funkcjonalnych i musi być jednoznaczny, spójny i kompletny.

Jak ja sobie z tym radzę?

Po wielu podejściach do tworzenia przypadków użycia uznałem, że należy najpierw opisać co jest w ogóle celem tworzenia tego systemu, co on ma wspomagać lub automatyzować. Jak? Należy najpierw zamodelować tę wspomaganą czynność w zupełnym oderwaniu od systemów. Jak już zdefiniujemy i zoptymalizujemy samą czynność można zabierać się do wyszczególniania przypadków użycia czyli tak na prawdę zaprojektować tę “druga stronę lustra”.

Jak ja to robię?

Tworzę model procesów (używam notacji i metodyki BPMN ale w prostszych przypadkach może to być np. diagram czynności UML), od którego proponuję zacząć. Potem wskazuję (wybieram) te czynności, które będą “komputeryzowane” (bo nie koniecznie wszystkie). W metodyce którą stosuję jest pojęcie czarnej skrzynki. Jest to np. projektowany jeszcze hipotetyczny system. Tworząc model procesów łączę czarną skrzynkę z wybranymi czynnościami (procesami) i optymalizuje tak powstały model. Prosty przykład poniżej:

Proszę zwrócić uwagę, że przerywane linie od modelu do czarnej skrzynki to kompletna lista przypadków użycia. Wystarczy je tylko zebrać i udokumentować np. tak jak w RUPie opisowo za pomocą tabel lub strukturalnego takstu. Podejście to wymaga troszkę więcej pracy ale ryzyko pominięcia czegoś istotnego jest minimalne dlatego warto ten czas poświęcić. Po drugie klient może łatwo taki model zweryfikować i zatwierdzić bo jest zrozumiały dla niefachowców. Kto choć raz zetknął z odbiorem systemu ten wie jak to ważne.

_______

2012: obecnie stosuję metodę prostszą, oznaczanie czynności zakwalifikowanych jako przypadki użycia, zamiast budowania złożonego diagramu zawierającego  pulę System. Więcej o przejściu z modelu procesu na przypadki użycia.