Przykład procesu zarządzania wymaganiami przy użyciu Enterprise Architect Karolina Zmitrowicz Zarządzanie wymaganiami w projekcie może być trudne i czasochłonne, może być chaotyczne jeśli brak odpowiedniego procesu i wsparcia narzędziowego, może jednak być łatwiejsze i przyjemniejsze w odbiorze, jeśli zastosujemy kilka dobrych praktyk i odpowiednie narzędzie. W niniejszym artykule chciałabym przedstawić prosty sposób zarządzania wymaganiami przy użyciu narzędzia Enterprise Architect, produkcji Sparx Systems. Sama funkcjonalność narzędzia jest potężna, nie będziemy się więc zajmować jej omawianiem czemu zresztą służą liczne podręczniki i system pomocy ale skupimy się nad tym, w jaki sposób zorganizować strukturę dla przechowywania wymagań i śledzenia powiązań pomiędzy różnymi ich poziomami. Za punkt wyjścia do rozważań niech posłuży prosty problem biznesowy: zaprojektowanie i wdrożenie systemu bankowego w zakresie obsługi transakcji w oddziale oraz generowanie raportów. Załóżmy, że otrzymujemy od klienta następującą listę wymagań: REQ001 System umożliwia wyszukiwanie klienta REQ002 System umożliwia wykonywanie przelewów krajowych REQ003 System umożliwia wykonywanie wpłat gotówkowych REQ004 System umożliwia wykonywanie wypłat gotówkowych REQ005 System umożliwia generowanie raportów transakcji REQ006 System umożliwia generowanie raportów konta bankowego REQ007 System umożliwia autoryzacje transakcji przez uprawnionego kierownika Te wymagania będziemy musieli poddać analizie i stworzyć propozycję rozwiązania, które je zaimplementuje. Analiza obejmuje opracowanie nowego procesu biznesowego dla rozwiązania oraz zaprojektowanie szczegółowych wymagań systemowych. Na tym etapie możemy więc zidentyfikować trzy poziomy abstrakcji dla wymagań i samego rozwiązania: Poziom wymagań klienta (powyższa lista) Poziom procesu biznesowego Poziom rozwiązania (wymagania szczegółowe) Na początek stwórzmy więc w Enterprise Architect strukturę dla analizy. W modelu należy stworzyć trzy pakiety. Będą one reprezentować nasze poziomy abstrakcji (Rysunek 1 Struktura pakietów). 1 z 18
Rysunek 1 Struktura pakietów Dalej zacznijmy od początku, czyli od umieszczenia wymagań w repozytorium. Do pakietu Wymagania dodajemy nowy diagram wymagań (Rysunek 2 Dodawanie nowego diagramu). Rysunek 2 Dodawanie nowego diagramu Następnie dodajemy nasze wymagania do repozytorium (Rysunek 3 Dodawanie wymagania). 2 z 18
Rysunek 3 Dodawanie wymagania Należy pamiętać o prawidłowym określeniu atrybutów wymagań: typu, statusu (ważne gdyż wskazuje, czy wymaganie jest zaakceptowane), priorytetu, wersji itp. Tym sposobem dodajemy do repozytorium wszystkie wymagania (Rysunek 4 Pakiet wymagań). 3 z 18
Rysunek 4 Pakiet wymagań Ostatecznie, mamy więc wszystkie nasze wymagania w pakiecie Wymagania. Będziemy z nich korzystać jeszcze później. Przechodzimy do analizy biznesowej. Należy tu stworzyć model biznesowy implementujący wymagania. Można to zrobić na kilka sposobów m.in: Wykonać modele procesów biznesowych spełniających określone wymagania Zaprojektować tak zwane biznesowe przypadki użycia (podejście charakterystyczne dla Rational Unified Process) My stworzymy model procesu biznesowego. Użyjemy do tego diagramu aktywności w notacji UML (można też a nawet lepiej wykorzystać notację przeznaczoną do modelowania biznesowego BPMN). W pakiecie Model biznesowy należy stworzyć tyle modeli, ile identyfikujemy procesów biznesowych. W naszym przypadku modeli (umieszczanych w odpowiednich pakietach) będzie 5: Proces biznesowy dla wpłaty Proces biznesowy dla wypłaty Proces biznesowy dla przelewu Proces biznesowy dla raportów transakcji Proces biznesowy dla konta bankowego klienta 4 z 18
Rysunek 5 Model biznesowy W odpowiednich pakietach dodajemy diagramy aktywności i wykonujemy modele procesów biznesowych. Kolejny krok to analiza systemowa czyli stworzenie rozwiązania systemowego dla wymagań i procesów biznesowych. Jednym z popularnych podejść do organizowania analizy na tym poziomie jest podział problemu na trzy aspekty: Aktorzy systemowi Przypadki użycia Ekrany GUI Dodajemy więc trzy pakiety (Rysunek 6 Struktura pakietu dla analizy systemowej). Rysunek 6 Struktura pakietu dla analizy systemowej 5 z 18
W pakiecie Aktorzy będziemy przechowywać wszystkich zidentyfikowanych aktorów systemowych (Rysunek 7 Pakiet Aktorzy). Dlaczego w osobnym pakiecie? Aby mieć jedno wspólne repozytorium aktorów, z którego będziemy korzystać przy tworzeniu różnych diagramów przypadków użycia. W przypadku rozwiązań większych, niż nasz mini-bank, liczba aktorów bywa znaczna i centralne repozytorium bardzo ułatwia pracę. Rysunek 7 Pakiet Aktorzy Następnie przechodzimy do pakietu Przypadki użycia. Dodajemy do niego pod-pakiety reprezentujące moduły funkcjonalne (Rysunek 8 Struktura pakietu Przypadki użycia). W naszym przypadku niech będą to pakiety: Transakcje Raporty Rysunek 8 Struktura pakietu Przypadki użycia 6 z 18
I zaczynamy w każdym pakiecie dodajemy diagram przypadków użycia a następnie tworzymy model przypadków użycia. Ponieważ korzystamy z aktorów z pakietu Aktorzy, na diagramach przypadków użycia nie dodajemy nowych aktorów a jedynie linki do aktorów zdefiniowanych w pakiecie Aktorzy (Rysunek 9 Dodawanie aktora (link) do diagramu przypadków użycia). Rysunek 9 Dodawanie aktora (link) do diagramu przypadków użycia Tajemniczy podpis pod aktorem from Aktorzy to odniesienie do przestrzeni nazw, z której aktora pobraliśmy. Ta opcja jest bardzo przydatna w dużych projektach, z wieloma pakietami, modułami i systemami, jako że pokazuje, z którego pakietu/systemu pobraliśmy danego aktora, wymaganie, czy przypadek użycia (i nie tylko dotyczy niemal wszystkich elementów modelu). Opcję włącza się klikając prawym przyciskiem myszy na obszar diagramu i wybierając menu Properties (Rysunek 10 Włączanie opcji pokazywania przestrzeni nazw). 7 z 18
Rysunek 10 Włączanie opcji pokazywania przestrzeni nazw Mamy już diagram przypadków użycia (Rysunek 11 Diagram przypadków użycia w pakiecie Transakcje). 8 z 18
Rysunek 11 Diagram przypadków użycia w pakiecie Transakcje Tym sposobem tworzymy modele przypadków użycia dla wszystkich modułów funkcjonalnych. No dobrze, lecz co zrobić, jeśli w trakcie analizy okaże się, że zapomnieliśmy np. o jakimś aktorze? Nic prostszego dodajemy go do pakietu Aktorzy i wykorzystujemy na odpowiednim diagramie przypadków użycia. Do każdego przypadku użycia należy dodać scenariusz. Można to zrobić na kilka sposobów. 1. Wpisując scenariusz jako opis (Description) do danego przypadku użycia, przechodząc do menu Scenarios w szczegółach (dwukrotne kliknięcie na przypadek użycia) (Rysunek 12 Definiowanie scenariusza dla przypadku użycia) 2. Dodając scenariusz jako Linked Document do danego przypadku użycia (Rysunek 13 Dodawanie Linked Document do przypadku użycia) 3. Dodając diagram aktywności do do danego przypadku użycia w tym celu należy zaznaczyć odpowiedni przypadek użycia w oknie Project Browser i wybrać menu Add Activity with Activity Diagram (Rysunek 14 Dodawanie diagramu aktywności do przypadku użycia) 9 z 18
Rysunek 12 Definiowanie scenariusza dla przypadku użycia 10 z 18
Rysunek 13 Dodawanie Linked Document do przypadku użycia Rysunek 14 Dodawanie diagramu aktywności do przypadku użycia Mamy diagramy, czy to koniec analizy z przypadkami użycia? Można przejść do ekranów? 11 z 18
Jeszcze nie. Należy upewnić się, że przypadki użycia implementują wszystkie wymagania czyli powiązać wymagania z odpowiednimi przypadkami użycia. Można to zrobić na kilka sposobów, przy czym najprostsze to: Macierz śledzenia Mapowanie na diagramie Zacznijmy od drugiej opcji. W każdym pakiecie analizy systemowej dodajemy kolejny diagram oznaczając go Transakcje UC-> Wymagania, co oznacza, że na diagramie pokażemy tylko mapowanie pomiędzy przypadkami użycia a wymaganiami. Na tym diagramie umieszczamy jako linki przypadki użycia z bieżącego pakietu oraz odpowiednie wymagania i łączymy je relacją Realization (niektórzy stosują również relację <<trace>>). Po przeniesieniu przypadków użycia zauważamy, że pojawiają się także powiązania pomiędzy nimi. Ponieważ w przypadku złożonych rozwiązań utrudnia to czytanie diagramów mapowania, ukrywamy połączenia klikając prawym przyciskiem myszy na odpowiednią strzałkę i wybierając z menu opcję Visibility Hide connector. Otrzymujemy czytelny obraz mapowania (Rysunek 15 Mapowanie przypadków użycia do wymagań). Rysunek 15 Mapowanie przypadków użycia do wymagań Co wynika z diagramu? Pokazuje on, które przypadki użycia spełniają dane wymaganie. Tym sposobem określamy pokrycie wymagań. Druga możliwość określania powiązań to macierz śledzenia. W Enterprise Architect znajduje się ona w menu View -> Relationship Matrix. 12 z 18
Macierzy używamy w następujący sposób: należy określić Source oraz Target, najprościej za pomocą opcji Locate Package in Browser, wybierając odpowiednie pakiety z przeglądarki. Nas interesują pakiety Wymagania i Przypadki użycia (choć można zawęzić pole do mniejszych pod-pakietów). Następnie wybieramy typ artefaktów, które będziemy ze sobą wiązać. Dla pakietów Source oraz Target wybieramy z listy typy, odpowiednio Requirement oraz UseCase. Teraz należy wskazać, jaki typ powiązania nas interesuje. Na diagramie mapowania używaliśmy powiązania typu Realization, więc z listy Link Type wybieramy to właśnie powiązanie. Wybieramy kierunek powiązania (Direction) interesują nas powiązania zarówno typu Source-Target, jak i odwrotnie, wybieramy więc Both. Tym sposobem otrzymujemy graficzną macierz śledzenia (Rysunek 16 Macierz śledzenia). Rysunek 16 Macierz śledzenia W naszym przypadku - ponieważ definiowaliśmy powiązania ręcznie na diagramie mapowania widać już strzałki pokazujące kierunek relacji. Jednak relacje można także zaznaczać bezpośrednio w macierzy, klikając na dane pole prawym przyciskiem myszy i tworząc nowe powiązanie. Powiązania do danego elementu można sprawdzić aktywując widok śledzenia w tym celu wybieramy z menu View opcję Traceability i przypinamy okno Traceability w prawej dolnej części obszaru Enterprise Architect (Rysunek 17 Widok Traceability). W widoku Traceability możemy sprawdzić wszystkie relacje od i do związane z elementem zaznaczonym w Project Browser. 13 z 18
Rysunek 17 Widok Traceability Pozostały do zamodelowania ekrany. Przechodzimy do pakietu GUI i tworzymy tyle pod-pakietów, ile modułów funkcjonalnych (czyli tyle i takie, jak w pakiecie Przypadki użycia). Rysunek 18 Struktura pakietu GUI Następnie należy dodać wymagania typu interfejs użytkownika. 14 z 18
Możemy to znowu zrobić na kilka sposobów. Pierwszy z nich to dodanie do odpowiedniego pakietu nowego diagramu typu User interface. Na tym diagramie tworzymy prototypy ekranów (Rysunek 19 Modelowanie ekranów użytkownika - podejście 1 za pomocą interfejsów użytkownika). Rysunek 19 Modelowanie ekranów użytkownika - podejście 1 za pomocą interfejsów użytkownika Ekrany możemy uszczegółowić projektując elementy GUI (lewy narzędziownik) oraz możemy je z ze sobą powiązać pokazując przepływ nawigacji. Następnie mapujemy ekrany do odpowiednich przypadków użycia, przeniesionych jako linki na diagram interfejsu użytkownika. Ukrywamy niepotrzebne na tym diagramie relacje i otrzymujemy mapowanie GUI -> UC (Rysunek 20 Mapowanie ekranów użytkownika do przypadków użycia). 15 z 18
Rysunek 20 Mapowanie ekranów użytkownika do przypadków użycia Inna metoda modelowania GUI to wykorzystanie diagramu wymagań i wymagań typu Display z podpiętymi Linked Documents przechowującymi prototypy ekranów i najczęściej szczegółowe opisy poszczególnych elementów, walidacje, ograniczenia itp. Wymagania Display również wiążemy z odpowiednimi przypadkami użycia (Rysunek 21 Modelowanie ekranów użytkownika - podejście 2 za pomocą wymagań typu Display). 16 z 18
Rysunek 21 Modelowanie ekranów użytkownika - podejście 2 za pomocą wymagań typu Display Tym sposobem zaprojektowaliśmy podstawową strukturę organizacji wymagań. Aby model był pełny, należałoby jeszcze dodać model danych i inne wymagane dla danego zagadnienia modele przy czym ponieważ zasada organizacji jest analogiczna do opisanej, pozwolę sobie pozostawić tę pracę czytelnikom. Co dalej? Modele modelami, repozytorium w narzędziu znacznie pomaga, jednak pojawia się jeszcze temat dokumentacji. Same modele i wymagania wprowadzone do Enterprise Architect są oczywiście dokumentacją, jednakże w wielu przypadkach bardziej przejrzysta jest dokumentacja papierowa czyli standardowy, tekstowy SRS. Narzędzie umożliwia i to. W tym celu klikamy prawym przyciskiem myszy na pakiet z Project Browser, którego zawartość chcemy umieścić w dokumencie i z menu wybieramy opcję Documentation Rich Text Format (RTF) Report. Otwiera się okno generowania pliku. Wybieramy odpowiedni szablon i wskazujemy miejsce docelowe pliku wynikowego (Rysunek 22 Generowanie dokumentacji), po czym klikamy na Generate. 17 z 18
Rysunek 22 Generowanie dokumentacji W wygenerowanym dokumencie tu use case otrzymamy informacje o wszystkich przypadkach użycia i GUI z danego pakietu. Bardzo ważny jest wybór odpowiedniego szablonu od niego w dużej mierze zależy przydatność i czytelność dokumentu. Enterprise Architect ma wbudowane podstawowe szablony, jednak warto skorzytać z opcji dostosowania/projektowania szablonów do własnych potrzeb i wymagań (chociażby dołączanie zawartości Linked Document powiązanego z danym elementem modelu). Tworzenie szablonów i pełnej dokumentacji to jednak już inny temat. W niniejszym artykule mieliśmy na celu pokazanie prostego sposobu podstawowej organizacji wymagań i analizy i to udało się (mam nadzieję) osiągnąć. Powodzenia w stosowaniu opisanego podejścia i tworzeniu własnego! W artykule wykorzystano elementy autorskiego projektu rozwiązania IT stworzonego przy użyciu wersji 10 Enterprise Architect. Wersję trial Enterprise Architect można pobrać ze strony Sparx Systems. 18 z 18