Identyfikuj przypadki użycia na podstawie procesu biznesowego
BPMN jest coraz częściej wykorzystywany do identyfikowania wymagań dotyczących oprogramowania wspierającego procesy biznesowe. Często stwierdza się, że wymagania dotyczące oprogramowania nie są zgodne z procesami biznesowymi. Dlatego wyodrębnianie wymagań oparte na modelach procesów biznesowych zapewni zgodność między modelami procesów biznesowych a modelami oprogramowania, a tym samym zwiększy szansę na dostarczenie tego, czego oczekują użytkownicy.
Zespoły deweloperskie mogą wykorzystywać model procesu biznesowego do wizualnego dokumentowania przepływów pracy biznesowej oraz przyporządkowywać przypadki użycia do tych procesów w celu modelowania żądanych funkcji, które ma osiągnąć system. W tym poradniku szczegółowo wyjaśnimy, jak wykorzystać funkcję Model Transitor w celu ustanowienia śladów między przypadkami użycia a procesami biznesowymi.
Co to są BPMN i BPD?
BPMN zapewnia analityków biznesowych zestaw notacji graficznych do modelowania procesów biznesowych. Pierwotnie został opracowany przez Inicjatywę Zarządzania Procesami Biznesowymi (BPMI) i obecnie jest utrzymywany przez Grupę Zarządzania Obiektami (OMG). Jednym z motywacji tworzenia BPMN jest zapewnienie wspólnego języka graficznego dla osób w różnych rolach, pochodzących z różnych krajów i/lub posługujących się różnymi językami, aby zrozumieć ten sam proces biznesowy bez barier.
BPD, skrót od Diagram Procesu Biznesowego, to miejsce, w którym modelowany jest proces biznesowy za pomocą BPMN. Jest to diagram podobny do schematu przepływu, który przedstawia przebieg procesu, uczestników oraz wymianę wiadomości między nimi. Analitycy biznesowi rysują BPD(y), aby modelować sposób współpracy różnych uczestników w celu osiągnięcia celu biznesowego. Po zwalidowaniu zakończonego modelu biznesowego wobec końcowych użytkowników analityk systemowy może rozpocząć planowanie systemu.
Poniżej znajduje się prosty BPD procesu rejestracji dla organizacji. Obejmuje on większość typowych notacji modelowania, które można zobaczyć. Spójrzmy na nie.

| Notacja | Opis |
|---|---|
![]() |
Pool – reprezentuje uczestnika w procesie. W BPMN zarówno pule, jak i pasy są używane do przedstawienia uczestników. Pasek jest zawarty w pule w celu modelowania podziału podstawowego pula. |
![]() |
Zdarzenie startowe – początek procesu. Można zdefiniować wyzwalacze, aby poinformować odczytujących, w jakich sytuacjach proces zostanie uruchomiony. Na przykład: gdy otrzymano e-mail / gdy jest poniedziałkowy poranek / gdy wystąpił błąd. |
![]() |
Zadanie – aktywność atomowa, którą mogą wykonywać wyznaczeni uczestnicy (zamodelowani za pomocą pula/pasa). Zadania i inne obiekty przepływu są połączone, aby utworzyć kompletny przepływ pracy biznesowej. |
![]() |
Zdarzenie końcowe – koniec procesu. Można zdefiniować wynik, aby poinformować odczytujących, co się stanie po zakończeniu procesu. Na przykład: wydać sygnał / wygenerować błąd, itd. |
W tym poradniku nie skupimy się głęboko na BPD ani na modelowaniu procesów biznesowych. Jeśli chcesz dowiedzieć się więcej o BPMN, BPD lub modelowaniu procesów biznesowych, prosimy o przeczytanie poradnika Wprowadzenie do BPMN część I do IV.
Co to jest diagram przypadków użycia?
Modelowanie przypadków użycia odnosi się do techniki zapisywania wymagań użytkownika na wysokim poziomie za pomocą diagramu przypadków użycia UML. Model przypadków użycia jest przeznaczony dla projektantów oprogramowania lub systemu, a nie dla osób z branży biznesowej.
W diagramie przypadków użycia znajdują się trzy główne elementy.
| Notacja | Opis |
|---|---|
![]() |
Przypadek użycia – Każdy przypadek użycia reprezentuje cel użytkownika, czyli cel, który użytkownik systemu chce osiągnąć. Zauważ, że przypadki użycia mogą być używane wyłącznie do pokazania tego, co użytkownik chce zrobić, a nie tego, co deweloper musi stworzyć, choć w niektórych przypadkach mogą się pokrywać. Jeśli chcesz zarejestrować lub zamodelować funkcje związane z przypadkiem użycia, możesz użyć narzędzia przepływ zdarzeń lub rozwinąć przypadek użycia zdiagram sekwencji/diagram aktywności. Pamiętaj tylko, że modelowanie przypadków użycia ma na celu modelowanie tego, co użytkownik chce osiągnąć. |
![]() |
Aktora – użytkownik systemu. Słowo „użytkownik” w tym kontekście nie ogranicza się do ludzi. Może to być system, który współdziała z naszym systemem w celu spełnienia określonego celu biznesowego. |
![]() |
Łączność komunikacyjna/Przypisanie – łączy aktora z przypadkiem użycia, aby wskazać dostęp aktora do systemu. Każda łączność komunikacyjna oznacza sekwencję transakcji między aktorem a systemem. |
Przejście z BPD do diagramu przypadków użycia
Chociaż BPD i diagram przypadków użycia nie muszą koniecznie opierać się na sobie, mogą być w pewnym stopniu powiązane w sposób uzupełniający. Zazwyczaj tworzymy oprogramowanie w celu automatyzacji lub optymalizacji określonych przepływów procesów biznesowych. Przy użyciu BPD możesz zrozumieć, jak uczestnicy współpracują ze sobą i kto jest odpowiedzialny za co, możemy określić, jakie funkcje systemu są potrzebne do wspierania. Te funkcje systemu (przepływ pracy lub proces biznesowy), które użytkownik chce, mogą być zamodelowane jako przypadki użycia i następnie opracowane przez zespół. W rezultacie możemy powiedzieć, że BPD pomaga Ci zidentyfikować przypadki użycia dla systemu, który jest w trakcie tworzenia.
Visual Paradigm to narzędzie modelowania wizualnego, które obsługuje od wykonywania procesów biznesowych po modelowanie przypadków użycia (od wymagań biznesowych do wymagań aplikacji) poprzez ustanawianie łączy śledzenia między tymi modelami za pomocą funkcji przekształcania modeli. Potrzebujemy śledzenia z następujących powodów:
- Możemy się upewnić, że system pasuje do rzeczywistego użycia, badając część przepływu procesu, którą obejmuje przypadek użycia.
- Aby odpowiedzieć na pytania typu „Dlaczego potrzebujemy tę (systemową) funkcję?”, śledząc część procesu, z której pochodzi przypadek użycia.
- Aby odpowiedzieć na pytania typu „Czy określona operacja została już zaimplementowana?”, śledząc od BPD do diagramu przypadków użycia.
BPD w porównaniu z diagramem przypadków użycia
Gdy przekształcasz BPD do diagramu przypadków użycia, możesz wygenerować aktora z lane/pool, a przypadek użycia z zadania/podprocesu. Poniższa tabela pokazuje cechy pool, lane, aktora, zadania, podprocesu i przypadku użycia pod kątem przekształcenia modelu.
| Z | Do | Opis |
|---|---|---|
![]() ![]() |
![]() |
Pool/Lane do Aktora
W BPD pool reprezentuje uczestnika procesu biznesowego, a lane to jego podział. Każdy, kto ma aktywność do wykonania, istotną dla procesu, jest uważany za uczestnika. W diagramie przypadków użycia aktor reprezentuje użytkownika systemu. Pamiętaj, że każda osoba lub rola, która nie jest użytkownikiem systemu, nie powinna być traktowana jako aktor. |
![]() ![]() |
![]() |
Zadanie/Podproces do Przypadku użycia
W BPD zadanie/podproces (działalność) odnosi się do dowolnej czynności, którą uczestnik może wykonać w celu ukończenia procesu biznesowego. W diagramie przypadków użycia przypadek użycia przedstawia cel, który użytkownik chce osiągnąć, korzystając z systemu. Pamiętaj, że działanie nie musi być związane z żadną funkcją systemu, a jeden przypadek użycia może spełniać wiele działań. |
Niektórzy ludzie mogą myśleć, że diagram przypadków użycia jest podobny do BPD, ale znacznie różni się w notacji i celu. Pamiętaj, że BPMN jest przeznaczony dla osób z branży biznesowej, a diagram przypadków użycia dla analityków systemów lub deweloperów systemów. Służą one różnym celom i przedstawiają biznes z dwóch różnych perspektyw. Dlatego w poprzedniej sekcji podsumowałem relację między BPD a diagramem przypadków użycia mówiąc: „BPD pomaga Ci zidentyfikować przypadki użycia”. BPD może jedynie dać Ci wskazówki podczas identyfikowania przypadków użycia. Nie ma zasady mówiącej, że każde zadanie istniejące w BPD jest równoważne przypadkowi użycia. Ale możemy rozwinąć proces biznesowy za pomocą przypadku użycia w celu automatyzacji funkcji przez system docelowy.
W przypadku studium przedstawię Ci kilka wskazówek, na co powinieneś zwracać uwagę podczas przekształcania BPD do diagramu przypadków użycia. Wtedy zrozumiesz, jak się różnią.
Przykład studium: Firma True Aqua do produkcji wody destylowanej
Firma True Aqua do produkcji wody destylowanej to młoda firma dostarczająca wodę destylowaną w mieście. Sprzedają wodę destylowaną do użytku komercyjnego i domowego. Poniżej znajduje się opis tekstowy ich procesu dostawy wody.
| Aby zamówić wodę destylowaną, klient albo dzwoni na hotline do zamówień, albo wysyła nam e-mail. Obecnie 90% zamówień pochodzi z telefonów, a 10% jest składanych przez e-mail. Asystent obsługi klienta, który otrzymuje zamówienie, sprawdza, czy klient jest istniejącym klientem, czy nowym. Jeśli klient nigdy wcześniej nie zamawiał, asystent utworzy dla niego konto klienta przed przystąpieniem do dostawy wody.
Dostawa wody destylowanej odbywa się raz w tygodniu w środę. Dlatego każdego poranka w środę asystent obsługi klienta przesyła zamówienia do działu logistyki w celu dostawy. Gdy menadżer w dziale logistyki otrzyma zamówienia, ustali dostawę, przypisując pracowników do różnych zamówień, drukując i publikując harmonogram. Pracownicy otrzymują telefony i dostarczają wodę klientom odpowiednio. |
Na podstawie opisu stworzono model procesu biznesowego. Teraz prosimy o stworzenie systemu komputerowego w celu optymalizacji całego procesu. Pierwszym krokiem, który musisz wykonać, jest stworzenie modelu przypadków użycia. Korzystając z BPD, spróbuj stworzyć diagram przypadków użycia.
- Pobierz Distilled Water Delivery.vpp. Możesz również znaleźć ten plik na końcu tego poradnika.
- Otwórz pobrany plik .vpp w programie Visual Paradigm. Aby otworzyć projekt, wybierzProjekt > Otwórzz paska narzędzi aplikacji.
- Otwórz BPDProces zamówienia wody destylowanej. Dokładnie przeanalizuj przebieg procesu.

- Proces rozpoczyna się, gdy klient złoży zamówienie. Możemy tutaj rozważyć przypadki użycia – Złożenie zamówienia. Przypadek użycia pomoże zautomatyzować proces, udostępniając interfejs dla klienta, aby mógł złożyć zamówienie bez pomocy asystenta obsługi klienta, pomóc zweryfikować tożsamość klienta i utworzyć konto, jeśli klient nie istnieje. Kliknij prawym przyciskiem myszy na Złożenie zamówienia i wybierzPowiązane elementy > Przejście do nowego przypadku użycia…z menu podręcznego.

- To spowoduje wyświetlenie oknaPrzejście elementu modelugdzie możesz wybrać model, w którym umieścić przypadek użycia i aktora, oraz zmienić ich nazwy. W tym przypadku jesteśmy zadowoleni z nazw przypadku użycia i aktora. Pozostawmy je bez zmian. KliknijOK.

Tworzy nowy diagram przypadków użycia w UeXceler.

- Wróć do BPD.
- Rozważmy zadanieUtwórz konto klienta. W procesie biznesowym asystent obsługi klienta musi utworzyć konto dla każdego nowego klienta. W nowym systemie może to być część przypadku użyciaZłożenie zamówienia, albo osobny przypadek użycia wyzwalany ręcznie przez asystenta obsługi klienta. W rzeczywistych warunkach powinieneś wyjaśnić takie wątpliwości ze stakeholderem, ponieważ niepoprawny model przypadków użycia prowadzi do opracowania funkcji, które nie odpowiadają oczekiwaniom użytkownika. W tym przykładzie załóżmy, że użytkownik chce, aby zadanieUtwórz konto klientabyło wykonywane przez asystenta obsługi klienta. Stwórzmy przypadek użycia na jego podstawie. Kliknij prawym przyciskiem myszy naUtwórz konto klientai wybierzPowiązane elementy > Przejście do nowego przypadku użycia…z menu podręcznego.

- Znowu jesteśmy zadowoleni z nazwy przypadku użycia i aktora. Pozostaw wszystko w okniePrzejście elementu modelubez zmian. KliknijOK. Diagram use case został uaktualniony o nowy przypadek użycia i aktora. Spójrzmy na to.

- Wróć do BPD. Przejdźmy do podprocesuZorganizuj dostawę. Menadżer działu logistycznych może używać systemu do planowania i powiadamiania pracowników o dostawie wody. Dlatego jest to również przypadkiem użycia systemu. Kliknij prawym przyciskiem myszy na podprocesieZorganizuj dostawę i wybierzPowiązane elementy > Przejście do nowego przypadku użycia…z menu podręcznego.
- Sprawdź aktora Menadżer w okniePrzejście elementu modelu oknie. Jeśli pozostawimy nazwę aktora jakoMenadżer, jest to niejasne w modelu przypadków użycia, ponieważ w firmie może być wiele działów z różnymi menadżerami. Dlatego zmień nazwę aktora naMenadżer działu logistycznego.

- KliknijOK. Diagram przypadków użycia został uaktualniony.

- Wróć do BPD. Ostatnia zadanieDostarcz wodęto zadanie, które może wykonać tylko człowiek i nie ma nic wspólnego z interakcją z systemem. Dlatego nie musimy tworzyć przypadku użycia dla niego.
- Załóżmy, że menadżer regionalny chce, by system wspierał nową funkcję, która może generować raport pokazujący statystyki zamówień. Ta funkcja może pomóc mu przeanalizować i dopasować strategię marketingową. Choć ta funkcja nie została zamodelowana w modelu procesu biznesowego, możemy ją narysować bezpośrednio w diagramie przypadków użycia. Otwórz diagram przypadków użycia. Narysuj aktoraMenadżer regionalny. Utwórz przypadek użyciaGeneruj raport statystycznyz niego z powiązaniem między nimi.

- Załóżmy, że klient chce pozwolić klientowi na przeglądanie faktur i anulowanie zamówienia. Ponadto klient chce pozwolić menadżerowi działu logistycznego na drukowanie raportu logistycznego. Narysuj odpowiednie przypadki użycia.

- Uporządkuj diagram.

- Relacja przejścia pozwala śledzić model procesu biznesowego z modelu przypadków użycia (i odwrotnie). Spróbujmy. Umieść wskaźnik myszy nadZłóż zamówienie przypadek użycia.

- Kliknij na Model Transitor zasób w prawym dolnym rogu kształtu. Wybierz Przejście od > Proces zamówienia wody destylowanej<.Złóż zamówienie z menu podręcznego.

Otwiera BPD z zadanym Złóż zamówienie wybranym.













