Przypadki użycia – przykład

 

W jednym ze wcześniejszych wpisów ¹, przedstawiłem moje uwagi dt. przypadków użycia. Na końcu obiecałem, że dodam jeszcze trochę praktycznych przykładów. I właśnie tym chciałbym się dziś zająć. Chciałem, aby przedstawione przykłady były „wzięte z życia”, dlatego są oparte na pewnym projekcie, który realizowałem. Przedstawię w skrócie problem, tak aby można było uchwycić o co w nim chodzi, a jednocześnie opis nie był zbyt angażujący. W oparciu o te informacje, przeprowadzę skróconą wersję analizy wymagań, efektem której będzie przypadek użycia, zapisany w formie szkicu²

Temat

Analiza będzie opierać się na przykładzie projektu budowy systemu sprzedaży B2B. Krótki opis zagadnienia:

Pewna spółka planuje prowadzenie sprzedaży B2B online w branży, w której do tej pory nie istniał podobny system. Klientami są przedsiębiorstwa produkcyjne, głównym przedmiotem sprzedaży jest rodzaj materiałów wykorzystywanych w cyklu produkcyjnym. Materiały mają różną charakterystykę (właściwości) istotne przy wyborze konkretnego produktu, można określić także powiązanie produktów w grupy pod względem rodzaju, a także pod względem właściwości wzajemnie uzupełniających się produktów. Zamówienia dostarczane są do odbiorców za pośrednictwem zewnętrznych firm logistycznych, ich gabaryty (waga, objętość, rodzaj opakowania) jest bardzo różna. Materiały wytwarzane są przez 2 głównych producentów w Polsce, a także mogą pochodzić od dostawców zagranicznych. Producent może (ale nie musi) być istotny dla zamawiającego. Zapotrzebowanie na produkty może mieć charakter zmienny, sezonowy, jednak jest to w dużym stopniu uzależnione od rodzaju produktu i dużej liczby czynników zewnętrznych. Zmienność ma wpływ zarówno na producentów jak i odbiorców, co może odbijać się na zmianach cen, okresowej niedostępności części materiałów lub opóźnieniach w dostawie. Ze względu na wielkość pojedynczego zamówienia i jego koszt, sprzedawca umożliwia opóźnione płatności, zamówienia rozłożone na wiele dostaw. Zależy mu na zachowaniu dużej płynności finansowej, nie kredytowaniu odbiorców z własnych środków, gwarancji płatności, jednocześnie na utrzymaniu stałości zamówień od klientów, swoistej monopolizacji (najlepiej jakby odbiorca zamawiał wszystkie półprodukty tylko u tego sprzedawcy) i wiedzy na temat przyszłego zapotrzebowania. Sprzedawca nie prowadzi własnego magazynu.

Zarząd spółki chciałby wdrożyć system informatyczny, który wspomoże jej działania biznesowe, czyli dostarczy funkcjonalności pozwalającej obsługiwać cykl zamówień i dostaw, wspierającej komunikację z producentami, klientami i podwykonawcami.

Dodatkowe założenia

Ponieważ omawiam tutaj tylko przykład odkrywania przypadków użycia, więc skupiam się wyłącznie na analizie przypadków użycia i pomijam lub ograniczam pozostałe części analizy wymagań. Nie pojawi się więc ani model domeny, ani opis procesów biznesowych, ani inne obszary analizy jak integracja, interfejs użytkownika, algorytmy, reguły. Bez tych obszarów, trudno w mojej opinii zrobić dobrą analizę wymagań, dlatego podkreślam, że przedstawione tu przykłady są tylko fragmentem większej całości. Oczywiście nikt nie zabroni zacząć od przypadków użycia i na tym pozostać. Jednak w efekcie powstanie, delikatnie mówiąc, kaleki opis wymagań. W rzeczywistości analiza przypadków użycia powinna powstać na jednym z dalszych etapów prac i opierać się na dużo większym zasobie informacji, niż przedstawiony powyżej opis problemu. Więc nie róbcie tego w pracy, to tylko przykład.

Przypadki użycia

Na podstawie wcześniej wykonanych kroków analizy, powinniśmy być wstanie wskazać aktorów (odpowiadających np. poszczególnym uczestnikom procesów biznesowych) oraz wykorzystywane przez nich przypadki użycia. Ponieważ, jak zaznaczyłem wcześniej, pomijamy tą część analizy, więc po prostu spróbujemy wskazać tutaj jeden z przypadków użycia i przeprowadzić jego analizę.

Jako nasz testowy okaz wybierzemy use case odpowiadający za funkcjonalność złożenia nowego zamówienia.

Etap pierwszy – szkic przypadku użycia

Identyfikator: B2B-UC-001

Nazwa: Zarejestruj nowe zamówienie

Aktor: Klient

Opis: dostarcza Klientowi funkcjonalność zgłoszenia nowego zamówienia. System musi zapewnić zarejestrowanemu Klientowi możliwość określenia szczegółów zamówienia: określenia rodzajów produktów, parametrów produktów, miejsca i terminu realizacji zamówienia (dostawy). W trakcie składania zamówienia system powinien także umożliwić zarejestrowanie Klienta i/lub zalogowanie się Klienta. System weryfikuje poprawność i kompletność wprowadzonego zamówienia – dostępność towarów, możliwości transportowe, poprawność ilości towarów, brak blokad na koncie klienta, rejestruje je i uruchamia jego procesowanie.

Mamy więc podstawą wersję przypadku użycia, a raczej jego zarys. Składa się z:

• Identyfikator – unikalne oznaczenie danego przypadku użycia (lub szerzej: danego elementu dokumentacji wymagań i architektury), wbrew pozorom ważny element opisu, przydatny w praktycznie każdym nietrywialnym projekcie – gdy mamy 100 UC, 200 wymagań, 50 reguł biznesowych, ileś wymagań niefunkcjonalnych itd i chcemy je wszystkie w sensowny sposób śledzić
• Nazwa – zdanie (wskazany tryb rozkazujący) określające co zostanie wykonane
• Aktor – kto będzie wykorzystywał dany przypadek użycia
• Opis – najważniejszy element, tekst wyjaśniający o co chodzi w tym przypadku użycia. Jak widać opis jest dość ogólny i nie zawiera wielu szczegółów. Jednakże, musi być także konkretny i pozostawiać jak najmniej miejsca na interpretację. Na marginesie – pojawiające się w opisie pojęcia (np: zamówienie, produkt, itp) powinny być ściśle zdefiniowane w innych obszarach analizy (model dziedziny)

Podsumowując – mamy zarys tematu, wiemy czego dotyczy opisywana funkcjonalność i z jakich czynności powinna się składać. Jednak nadal czegoś brakuje. Przejdźmy więc do następnego etapu.

Etap drugi – granice i oczekiwania

Dla lepszego zdefiniowania warunków, ograniczeń i potrzeb aktorów wskazane jest określenie granic, czyli opisania z jednej strony kiedy UC może i powinien zostać uruchomiony a z drugiej – kiedy i w jaki sposób UC kończy się. Do opisu przypadku użycia dodajemy więc pola:

Wyzwalacz (trigger): przypadek użycia jest uruchamiany na żądanie użytkownika
Warunki początkowe: użytkownik musi być zalogowany
Warunek końcowy: zamówienie w statusie nowe jest zarejestrowane, powiązane z kontem klienta; zamówienie spełnia wszystkie reguły zamówienia w statusie nowe (patrz model dziedziny/reguły biznesowe)
Minimalny warunek końcowy: z kontem klienta jest powiązana informacja o uruchomieniu składania zamówienia, w logach systemowych zarejestrowana jest informacja o przebiegu składania zamówienia i przyczynach zakończenia

Dodaliśmy informacje, które pozwolą określić jaki kontekst musi być zapewniony aby UC mógł być uruchomiony (warunki początkowe). Co więcej oznacza to także, że jeżeli te warunki nie są zapewnione to UC nie może być uruchomiony. Dodaliśmy też informację jakie zdarzenie uruchamia przypadek użycia (wyzwalacz). Akurat w tym wypadku jest to dość banalne zdarzenie, jednak warto zaznaczyć, że jest to dość istotny element opisu przypadku użycia. W szczególności dla przypadków, które opisują automatyczne czynności systemu oraz takich które wywoływane są z innych przypadków użycia. Przykładowo, po zakończeniu UC którym się tu zajmujemy powinien zostać uruchomiony inny UC – Zweryfikuj zamówienie. Wyzwalaczem dla tego przypadku użycia będzie zdarzenie Zarejestrowano zamówienie w statusie nowe.

Przejdźmy teraz na drugi koniec czyli punkty opisu pod tytułem „warunki końcowe”. Te dwa punkty pozwalają nam określić jaka sytuacja musi zostać zapewniona po zakończeniu przypadku użycia gdy przypadek zakończy się sukcesem (warunek końcowy) lub porażką (minimalny warunek końcowy. Pierwszy jest w miarę oczywisty – określa stan, który spodziewamy się osiągnąć po zakończeniu wykonywania przypadków użycia. Ale po co ten drugi? Wbrew pozorom, może to być nawet istotniejsza informacja. Pozwoli nam uniknąć sytuacji, gdy coś pójdzie nie tak i zostawimy system w stanie nieustalonym. W szczególności jest to istotne, gdy zaczynamy mówić o bardziej technicznych UC na przykład integracyjnych.

Dodatkowo, warto tu rozróżnić dwa rodzaje sukcesu – sukces przypadku użycia i sukces testu sprawdzającego przypadek użycia. Pierwszy oznacza, że przypadek się powiódł i został osiągnięty warunek końcowy, drugi zależny jest od rodzaju testu i oznacza że test przebiegł poprawnie (nie stwierdzono odstępstw od scenariusza testów), czyli może to także oznaczać osiągnięcie minimalnego warunku końcowego jeżeli test sprawdzał właśnie taki przebieg.

Etap trzeci – scenariusze i alternatywy

Mamy więc przypadek który ma już dobrze zdefiniowane ramy, oczekiwania i warunki. Brakuje jeszcze określenia przebiegu. Co prawda mamy już zarysowany główny scenariusz, który określa co się dzieje w trakcie wykonywania takiego przypadku użycia, jednak – po pierwsze jest jeszcze dość ogólny a po drugie – to nie jest jedyny scenariusz. Scenariusze powinny wskazywać czynności, nazywać działania i ich rezultaty podejmowane przez obie strony (system i aktora) dążących do osiągnięcia celu. Główny scenariusz jest po prostu rozwinięciem opisu, powinien dodać szczegóły, ale nadal opisywać najczęściej spotykany, najbardziej popularny sposób postępowania.

Główny scenariusz: Zarejestrowany użytkownik przegląda listę oferowanych produktów. Po wybraniu jednego z produktów klient dodaje go zamówienia. System prosi klienta o określenie ilości produktów (uwaga: zależne od rodzaju produktu). Klient może wykonać ten krok dowolną liczbę razy, kolejność dodawania produktów nie jest istotna. Klient podejmuje decyzję o złożeniu zamówienia. System potwierdza że konto klienta jest aktywne i zatwierdzone. System potwierdza poprawność zamówienia: dostępność towarów, prawidłową ilość. System sprawdza rodzaj rozliczeń klienta – dostępne formy płatności i potwierdza, że klient nie ma zablokowanych płatności. System sprawdza możliwości transportowe – określa wymagany rodzaj transportu i jego dostępność. System prezentuje konfigurację klientowi. Klient określa datę dostawy, adres dostawy. Klient zatwierdza zamówienie. System rejestruje zamówienie i przekazuje je do zatwierdzenia.

Określiliśmy główny scenariusz powodzenia, jednak nadal czegoś brakuje. Przystępujemy więc do wymyślania wszelkich innych możliwych sytuacji „co by było gdyby”. Przykładowo: scenariusz główny nie uwzględnia sytuacji gdy: użytkownik zalogował się ale jego konto nie jest aktywne i zatwierdzone (w omawianym przypadku rejestracja konta musiała być potwierdzana przez pracowników) lub konto posiada blokady sprzedaży (kolejny pomysł zamawiającego omawiany system – konto mogło być zablokowane za nieterminową płatność) lub też zamówienie nie może być zrealizowane z powodu braku towarów lub innych ograniczeń. Dla wszystkich wymyślonych alternatyw musimy teraz opisać scenariusze, przykładowo:

Scenariusz alternatywny – zablokowane konto: W trakcje weryfikacji konta klienta, system stwierdza że konto klienta nie jest aktywne (nie zostało zatwierdzone) lub posiada inną blokadę. System prezentuje użytkownikowi informację o tym fakcie, umożliwia przesłanie wiadomości do administracji dt. konta. System rejestruje także informację o składanym zamówieniu oraz przypisuje do konta klienta konfigurację zamówienia w stanie oczekujące.

I tak dalej – każdy istotny scenariusz alternatywny powinien zostać opisany.

Co dalej

Historię z przypadkiem użycia można ciągnąć dalej i dalej. Można przede wszystkim rozbudować scenariusze, zapisując je w mniej lub bardziej formalnej strukturze (poczynając od wypunktowania kroków, kończąc na modelu UMLowym scenariuszy w postaci diagramów aktywności). Można rozbudowywać opisane już wyżej warunki, można ściślej powiązać UC z pozostałymi obszarami analizy. Można jeszcze wiele zdziałać. Wszystko jednak zależy od jednego kluczowego ustalenia – Definicji: Skończone. W każdym projekcie, czy nawet na każdym jego etapie powinniśmy mieć ustalone gdzie kończymy, co jest wystarczającym, zadowalającym zestawem informacji.

Powyższy artykuł nie obejmuje także informacji o relacjach między przypadkami użycia. Chwila zastanowienia się nad scenariuszami (zwłaszcza głównym) wystarczy, aby stwierdzić że coś tam jest nie tak. Kroki są za „grube”, są na tyle ogólne, że za dużo pozostaje jeszcze do wyjaśnienia. I w tym momencie wchodzą powiązane przypadki użycia. Wrócę do tego tematu jeszcze. Moje doświadczenie wskazuje, że w pełni sformalizowane przypadki użycia przeważnie nie są najwłaściwszym rozwiązaniem. Kiedyś starałem się każdy przypadek opisać jak najdokładniej, rozpisując scenariusze do najdrobniejszych kroków, z których każdy miał nawet własny identyfikator. Jednak, zderzając się wielokrotnie ze zmiennością wymagań, nieścisłością żądań klientów, doszedłem do wniosku, że w taki sposób zbyt dużo wysiłku idzie na marne. Obecnie, w większości sytuacji, może poza najbardziej technicznymi i kluczowymi obszarami jak integracja czy przetwarzanie danych, przyjmuję bardziej elastyczne, „zwinne” podejście. Przypadek musi być na tyle szczegółowo opisany, aby nie budził pytań interpretacyjnych („co autor miał na myśli”), był zrozumiały i czytelny oraz był łatwo testowalny. Nie musi być rozpisany ze szczegółami do najdrobniejszego kroku.. Ale o zwinnych analizach może następnym razem.