Wprowadzenie

Pora na przypadki użycia i granice systemu. W poprzedniej części (Diagram klas czyli reinżynieria analizy biznesowej) wskazałem na potencjalne ryzyka opisu user story i narzędzie niwelujące tę wadę czyli model procesu jaki opisał Zamawiający (hipotetyczny autor opisu User story). Tworzenie modelu ma dwa zadania: weryfikacja spójności i kompletności opisu Zamawiającego oraz stworzenie podstawy do określenia zakresu projektu i wyspecyfikowania wymagań funkcjonalnych czyli tak zwanych przypadków użycia. Czy tak się robi zawsze? Ja z zasady (moja metodyka opracowana na bazie doświadczeń i literatury) traktuję KAŻDY opis, nawet w postaci strukturalnej (tabele, punkty itp.), dostarczony przez Zamawiającego jako takie właśnie ryzykowne user story.

Czy to brak zaufania dla Zamawiającego? Przecież to dla niego system, Zamawiający powinien umieć określić czego potrzebuje. Hm… każdy z nas potrafi powiedzieć do czego i jaki chce samochód, czy to znaczy że potrafi wyspecyfikować  konstrukcję tego samochodu? (mój mechanik jest bardziej dosadny, zawsze mówi: nie nic gorszego od faceta, któremu wydaje się, że zna się na samochodach). Aby kupić gotowe oprogramowanie o standardowej, powszechnie stosowanej funkcjonalności, w zasadzie żaden analityk nie jest nam potrzebny. Jeżeli jednak chcemy coś, co choć troszkę ma pasować do naszego biznesu i nie jest trywialne należy do tego podejść z większa rezerwą do wszelakich oczywistości, bo nie mówimy już o przeciętnym samochodzie ale o samochodzie, którym wystartujemy w zawodach. Te zawody to Wolny Rynek, starcie z Konkurencją. Może nie zawsze jest to Formuła 1, ale też prawie nigdy nie jest to też jazda spacerowa na święta.

Analiza Biznesowa

Wróćmy do naszego modelu procesów. Ten, powstały na bazie opisu Zamawiającego pozwolił znaleźć luki i niespójności, jest jednak zbyt szczegółowy. To rzadki u mnie przypadek analizy bottom-up (od szczegółu do ogółu) jednak pierwsza sztywna zasada analityka mówi: nie istnieją sztywne zasady analizy i projektowania. Po drobnych poprawkach, uogólnieniu, model wygląda tak:

W zakresie projektu mamy wszystkie czynności, które wraz z ich produktami stanowią procesy biznesowe, zostały ona oznaczone stereotypem <<usługa aplikacji>> (stereotypy nie są częścią BPMN, można je stosować do wskazania powiązań pomiędzy obiektami na modelach BPMN i UML gdzie będą im odpowiadały przypadki  użycia).

Po stronie Klienta (użytkownika, dalej zwanego także aktorem) zastosowano uproszczenie: jest modelowany jak tak zwana czarna skrzynka.

Będziemy bazowali na definicji procesu biznesowego: proces biznesowy to  czynność lub logicznie powiązany łańcuch czynności przekształcający produkt na swoim wejściu w produkt (jego stan) na wyjściu. Różnica pomiędzy tymi produktami stanowi wartość wnoszoną biznesową przez proces.

Po stronie Sklepu mamy więc teraz procesy (czynności): Rejestracja Zamówienia, Rejestracja wpłaty, Pakowanie i wysyłka oraz Utworzenie raportu o stanie zamówienia.

Kolejna rzecz to granice systemu. Dwa założenia, które wydają się bardzo rozsądne: Firma posiada system ERP oraz płatności elektroniczne będą przedmiotem outsourcingu.  Tak więc wymagania na system to:

1. przyjmowanie zamówień,
2. przyjmowanie płatności droga elektroniczną,
3. integracja z ERP: system ten odpowiada za księgowanie faktur i zarządzanie magazynem,
4. użycie zewnętrznego operatora płatności elektronicznych.

Powyższe wydaje się rozsądne i bywa często spotykane (staram się by ten przykład aż tak nie odbiegał od rzeczywistości ;)). Wymagania powinny być zwięzłe ale tez nie powinny wykraczać poza opis co powinno być możliwe z nowym systemem. Tak więc diagram przypadków jaki stworzyłem użycia wygląda tak:

Kilka słów na temat tego diagramu. Mamy przypadek użycia dla każdej aktywności. Każdy przypadek użycia powinien zostać udokumentowany co najmniej trzema elementami:

1. stan początkowy (warunki początkowe)
2. scenariusz
3. oczekiwany stan końcowy

Kontekst stanowi model procesów wiec nie musimy tu pisać czym są poprzedzane i jakich mają następców poszczególne przypadki użycia. Wystarczy w modelach zachować tak zwane traceability (ja stosuję prostą zasadę: nazwa przypadku użycia jest taka sama jak czynności na modelu procesów, z której został wyprowadzony, nazwy te są unikalne). Nie musimy także tworzyć diagramów scenariuszy nadrzędnych łańcuchów przypadków użycia bo zastępuje je właśnie model BPMN. Na koniec uwaga: przypadek użycia powinien być samowystarczalny, innymi słowy musi mieć sens jako sam jeden (sam z siebie służy do wykonania jakiejś logicznej czynności  dającej przydatny produkt).

Scenariusz najprościej i najskuteczniej jest opisywać w postaci dialogu Aktor <-> System. Ja stosuję np. prosta tabelę z kolumnami Aktor i System:

AKTOR                            SYSTEM

Inicjuje pracę                   Wyświetla listę produktów

Zaznacza wybrane produkty i OK   Wyświetla treść zamówienia

Potwierdza zamówienie            Wyświetla dane o płatności

Wybiera system płatności i OK    Kończy i ewentualnie przekazuje sterowanie

Tworzenie diagramów przypadków użycia w zasadzie warto traktować tylko jako specyfikację koncepcji zachowując zrozumiałość dla laika. Bąbelki powinny być tylko specyfikacją funkcjonalną i niczym ponad to. Ten diagram i tak nie zastąpi diagramu klas, sekwencji czy tym bardziej opisu procesu (tu był BPMN). Jak nie trudno chyba już zauważyć, dokumentacja zmierza w kierunku kilku prostych modeli (diagramów) zamiast jednego spagetii-modelu. Często spotykam się z dokumentami, w których autor analizy wymagań wszystko udokumentował (starał się) na diagramie przypadków użycia. To bywa straszne.