Specification Manager

Tworząc specyfikacje wymagań można posłużyć się dwiema metodami:

1. Diagram-based – zbudować model wizualny i wymagania zapisać za pomocą różnego rodzaju diagramów UML
2. Text-based – opisać precyzyjnie w języku naturalnym funkcje systemu i ewentualne opisać zależności między wymaganiami lub ich powiązania z innymi systemami

Jeżeli ktoś używał do niedawna środowiska Sparx Enterprise Architect do modelowania wymagań, był niejako skazany na tę pierwszą, graficzną metodę. Wszak EA pozycjonował się na rynku jako „platforma do modelowania wizualnego”. W 2017 roku oczywiście nadal firma Sparx Systems uważa, że jej główną misją jest dostarczanie niedrogiego, wydajnego i przyjaznego dla użytkownika oprogramowania do modelowania. Nie tylko wizualnego, należy dodać.

30 czerwca 2017 roku na stronie Sparx w bibliotece pdf, w dziale „Modeling” pojawił się podręcznik użytkowania Menedżera Specyfikacji (Specification Manager). Funkcjonalność ta co prawda jest już dostępna od pewnego czasu, ale dopiero teraz doczekała się podręcznika z prawdziwego zdarzenia.

Cóż to takiego jest ten Specification Manager? To prosty interfejs do przeglądania i edytowania dokumentów zawartych w wybranym pakiecie, w formacie tekstowym. Wszystkie obiekty (Items) w danym pakiecie wyświetlane są w tabeli wraz z różnego typu atrybutami, które je opisują. Widok na dane w repozytorium bardzo łatwo dostosować do swoich potrzeb dodając lub usuwając poszczególne kolumny arkusza.

Dostęp do informacji jest tekstowy a nie wizualny, więc oczywiście w takiej formie wyświetlane informacje o elementach diagramów mogą mieć bardzo limitowany sens. Można by zatem zapytać, po co coś takiego jak menedżer specyfikacji w ogóle wprowadzono. Najkrótsza odpowiedź brzmi: żeby skutecznie zarządzać wymaganiami.

Opisując wymagania nietrywialnych, większych systemów IT analitycy gromadzą ogromną liczbę informacji. Oczywiście tak zebraną wiedzę zawsze można trzymać w formie papierowej, tyle że wtedy:

• Mamy zbyt dużo informacji do ogarnięcia i trudno dotrzeć do potrzebnych danych
• Powiązanie ze sobą informacji przechowywanych za pomocą różnych mediów i występujących w różnych dokumentach jest szalenie kłopotliwe
• Zawsze występują problemy z aktualnością dokumentacji papierowej
• Często dokumenty giną w przepastnej szufladzie czyjegoś biurka

Wyznawcy metodyk zwinnych (agile) mają na to receptę – whiteboard zwaną po polsku tablicą suchościeralną. Tyle, że takie medium trzymania informacji o wymaganiach ma także wady:

• Ograniczona powierzchnia białej tablicy
• Bardzo łatwo stracić dane (nadgorliwa sprzątaczka nie takie rzeczy już ścierała)

Co jest zatem rozwiązaniem problemu? Trzymanie dokumentów źródłowych i modelu wymagań w repozytorium elektronicznym.

Najczęściej w świecie używane narzędzie do zarządzania wymaganiami DOORS (Dynamic Object Oriented Requirements System) swą popularność zawdzięczało przede wszystkim łatwości obsługi. Dokumenty pozyskane w trakcie procesu zbierania wymagań można w DOORS zapisać poprzez interfejs jako żywo przypominający zwykły edytor tekstu. Żeby się tym narzędziem posługiwać nie trzeba mieć jakichkolwiek specjalistycznych, wyrafinowanych umiejętności. Pisze się tam wymagania jak w jakimś word procesorze. Tyle, że tak stworzone wymagania są zarządzane wyrafinowanymi mechanizmami kontroli wersji, opatrzone szeregiem atrybutów i zapewniony jest przede wszystkim mechanizm robienia związków powiązań (traceability). Jeżeli będziemy się prawidłowo posługiwać takim elektronicznym repozytorium, to dostaniemy spójny model wymagań oparty na solidnych fundamentach, z którego łatwo i bez kłopotów można korzystać, aby zweryfikować poprawność wymagań, czy też na ich podstawie wyprodukować oprogramowanie.

Rys. Model wymagań dostępny poprzez tekstowy interfejs w systemie DOORS.

Łatwo można dostrzec pewne podobieństwa pomiędzy interfejsem DOORS i Specification Managerem. Nic w tym dziwnego – inspiracją w obu wypadkach była praca ze „zwykłymi” dokumentami biurowymi. Nie trzeba znać ani UML, ani BPMN żeby „tekstowo” opisywać swoje potrzeby, procesy biznesowe czy wymagania jakościowe co do systemu IT. Dla kogoś nawykłego do tworzenia dokumentów za pomocą jakiegokolwiek pakietu typu Office, nauczenie się korzystania ze Specification Managera to kwestia bardziej minut niż godzin.

Przyjrzyjmy się bliżej menedżerowi specyfikacji.

W okienku Specification Managera mamy wyświetlone:

1. Nazwę danego elementu z repozytorium
2. Opis elementu
3. Atrybuty elementu takie jak Status, Stereotyp, Priorytet, Trudność implementacji i inne

Możemy nawigować po repozytorium w górę i w dół, a gdy zaczniemy edytować opis jakiegoś elementu, zapala się z lewego boku podświetlenie informujące o tym fakcie.

Naciskając prawy klawisz myszy mamy do wyboru szereg operacji na repozytorium. Możemy dodawać do niego i kasować elementy, dodawać pod-elementy („Add New Child”), przemieszczać elementy w repozytorium czy tworzyć dokumenty połączone z danym elementem („Create Linked Document”).

Na belce Menedżera Specyfikacji można umieścić bardzo pożyteczne pole „All Indicators”. W tak opisanej kolumnie będą się wyświetlać ikony oznaczające, że do danego elementu są przykładowo podpięte ryzyka, dokumenty tworzone w repozytorium i obsługiwane natywnie przez Enterprise Architect’a oraz dokumenty umieszczone na dysku twardym lub dysku sieciowym, a otwierane specyficznymi dla typu dokumentu programami.

Może być do danego repozytorium podczepiony szereg plików zewnętrznych. (patrz poniżej)

Zielony „ptaszek” sygnalizuje, że do elementu podpięty jest Przypadek Testowy. Dzięki temu z łatwością można zaprojektować testy mające sprawdzić czy dana funkcjonalność została zaimplementowana prawidłowo.

Zbiór wymagań zapisany w repozytorium można (i należy) systematycznie przeglądać celem ich recenzowania i szukania w nich błędów . Gdy jakąś niedogodność lub usterkę znajdziemy, możemy doczepić do danego elementu tzw. listę dyskusyjną (ikona „dymek”), by potem poprzez dialog z właściwymi udziałowcami projektu wypracować poprawne brzmienie wymagania (w przykładzie poniżej znaleziono błąd polegający na braku loga naszej firmy w planie testów).

Dla wyznawców idei „Jeden obraz wart więcej niż tysiąc słów”, którzy nie wyobrażają sobie modelowania wymagań w inny sposób niż za pomocą diagramów, spojrzenie przez pryzmat interfejsu tekstowego może także być bardzo przydatne. Przykładowo mamy diagram wymagań dotyczących tematu Zarządzania Użytkownikami. Z rysunku możemy błyskawicznie wywnioskować, jakie są zależności pomiędzy wymaganiami. Widzimy, że na wymaganie REQ011 składają się wymagania REQ016, REQ017, REQ018 i REQ024, a z kolei na REQ018 składają się REQ025 i REQ027.

Rys. Diagram wymagań

Dzięki rysunkowi na pewno można szybko zrozumieć koncepcję Zarządzania Kontami Użytkowników . Jak jednak mówi przysłowie „Diabeł kryje się w szczegółach”, a tych na diagramie po prostu nie widać. Mamy tylko informację o nazwach poszczególnych wymagań i ich wzajemnych relacjach. Gdy chcemy zobaczyć dokładniejszy opis wymagania lub jego atrybuty, musimy otworzyć właściwości elementu (properties). Jednego elementu!

Korzystając z widoku na grupę wymagań, jaką zapewnia Specification Manager, możemy zobaczyć nie tylko nazwy wymagań, ale i ich treść. Jeżeli zaś z wymaganiami powiązane są jakieś dokumenty przechowywane czy to w repozytorium, czy też poza jego granicami, możemy do nich błyskawicznie dotrzeć.

Na szczęście pracując z narzędziem Enterprise Architect nie musimy podejmować decyzji, który ze sposobów tworzenia repozytorium wymagań jest lepszy, graficzny czy tekstowy. Możemy korzystać z nich obu! Bardzo Państwu polecam używanie Specification Manager’a.