Zarządzanie relacjami pomiędzy wymaganiami

Zarządzanie wymaganiami to ważny element procesu wytwórczego oprogramowania. Jednym z jego elementów budowanie i zarządzanie relacjami pomiędzy wymaganiami.
Najczęściej spotykanym jest podejście stosowane czy też nawet promowane przez Sparx Systems.
Enterprise Architect w swojej dokumentacji proponuje, by wymagania były łączone ze sobą za pomocą agregacji lub kompozycji.

Zarządzanie wymaganiami - relacje w Enterprise Architect

To dobre, choć uproszczone podejście do tego zagadnienia, które nie jest zgodne ze znanymi mi standardami. Sparx Systems zaadoptował relację języka UML na potrzeby zarządzania relacjami pomiędzy wymaganiami. Nie mniej jednak jeśli ktoś zna UML to relacje te nie są trudne do odszyfrowania.  To najczęściej wykorzystywany sposób.

W wielu projektach, przy napiętym harmonogramie i dość często budżecie nie ma przestrzeni na to by zarządzać relacjami pomiędzy wymaganiami w bardziej  wyrafinowany sposób. Dobrze, że czasami w ogóle wymagania są zdefiniowane :-).

Zarządzanie wymaganiami, zarządzanie relacjami pomiędzy wymaganiami to nie tylko rozwiązania oferowane przez dokumentację do Enterprise Architect. Jednym ze znanych formalnych opisów procesu zarządzania relacjami pomiędzy wymaganiami jest SysML. SysML oferuje szereg relacji. Oto one:

Zarządzanie wymaganiami - relacje

Co oznaczają poszczególne relacje?

Zagnieżdżenie (ang. containment) to relacja, która umożliwia połączenie wymagań nadrzędnych z podrzędnymi, przez co tworzona jest wielopoziomowa, hierarchiczna struktura wymagań systemowych. Wymaganie nadrzędne uznaje się za spełnione tylko i wyłącznie wtedy, gdy zostaną spełnione wszystkie jego wymagania podrzędne. To podejście jest pokazane z w dokumentacji Enterprise Architect w postaci relacji agregacji.

zarządzanie wymaganiami - relacja zagnieżdżenie (ang. containment) 

Zależność wyprowadzania (ang. Derive ) pozwala na wyprowadzenie wymagania docelowego z wymagania źródłowego.  Zazwyczaj pojedyncze wymaganie źródłowe wspierane jest przez szereg wymagań docelowych, powiązanych osobnymi zależnościami wyprowadzania. Cechy systemu, reprezentowane przez wymaganie docelowe, są pochodnymi cech systemu, reprezentowanych
przez wymaganie źródłowe. Relacja jest oznaczana stereotypem «deriveReqt». Na poniższym rysunku użyłem elementów z toolbox dedykowanego dla SysML.  zarządzanie wymaganiami - relacja zależność wyprowadzania (ang. Derive )

Zależność realizacji (ang. Satisfy) oznacza, że dany element musi spełnić dane wymaganie. Tymi elementami mogą być przypadki użycia, klasy, komponenty i inne byty. Zmiana wymagania wpływa na zamianę elementu. Relacja jest oznaczana stereotypem «satisfy». Odpowiednikiem tej relacji podejściu oferowanym przez Sparx Systems  jest realizacja.

zarządzanie wymaganiami - relacja zależność realizacji (ang. Satisfy)

Relacja powielenia (ang. Copy) ma zastosowanie wtedy, gdy jedno wymaganie jest tożsame z jednym bądź wieloma wymaganiami. Przykładem niech będzie wymaganie dot. bezpieczeństwa, które jest kopiowane na kilka systemów.  W momencie poprowadzenia zależności powielania pomiędzy dwoma wymaganiami przyjmuje się, że wymaganie docelowe ma charakter tylko do odczytu, tj. przyjmuje ono tożsamą treść w stosunku do wymagania źródłowego. Relacja jest oznaczana stereotypem «copy».

zarządzanie wymaganiami - relacja powielenia (ang. Copy)

Zależność weryfikowania (ang. Verify) to relacja, która teoretycznie wykracza poza zakres wymagań, gdyż służy do wskazani tych bytów, które weryfikują wymaganie.
Weryfikowanie poszczególnych wymagań pod kątem tego, czy zostały one zrealizowane podczas kodowania systemu to dobra a nawet bardzo dobra praktyka. Jednym elementów, który może weryfikować są przypadki testowe. W języku SysML przypadki testowe wiąże się z wymaganiami z wykorzystaniem zależności weryfikowania, oznaczonej stereotypem «verify».
Do pojedynczego wymagania przydzielić można szereg testowych przypadków użycia.

zarządzanie wymaganiami - relacja zależność weryfikowania (ang. Verify)

Zależność precyzowania (uszczegóławiania) (ang. Refine) pozwala na wprowadzenie do diagramu wymagań systemowych licznych detali. Te detale to różne artefakty takie jak diagram aktywności prezentujący proces wyliczenia składki, ekran użytkownika GUI itp..  Zależność ta stwarza możliwość wyjaśnienia ogólnego tekstu zapisanego w wymaganiu źródłowym. Relacja jest oznaczana stereotypem «refine».zarządzanie wymaganiami - zależność precyzowania (uszczegóławiania)

Zależność śledzenia (ang. Trace)  jest moją ulubioną zależnością. Ulubioną pewnie dlatego, że  korzystam z niej najczęściej.  Zależność śledzenia, oznaczana stereotypem «trace», umożliwia zaprezentowanie nieformalnego związku pomiędzy wymaganiem a dowolnym elementem modelu systemu, w tym innym wymaganiem. Osobiście relację trace, śledzeniem relacji między wymaganiami, stosuję do połączenia przypadków użycia z usługami aplikacyjnymi i połączenia przypadków użycia z aktywnościami na diagramie BPMN. zarządzanie wymaganiami - zależność śledzenia (ang. Trace)

Warto by w każdym projekcie zarządzanie relacjami pomiędzy wymaganiami zostało spisane. Moim zdaniem nie warto jest stosować wszystkich typów relacji oferowanych przez SysML. Być może to co oferuje Enterprise Architect w domyślnym toolbox’ie będzie wystarczające. Opisanie używanych relacji nie tylko ograniczy ich zakres, ale również pozwoli odpowiedzieć na dwa pytania – jaki jest cel użycia danej relacji i jaki będzie koszt utrzymania modelu z wieloma typami relacjami.

Chodzi o to by przypadkiem nie popaść w uzależnienie się od wzajemnych zależności wymagań :-).

Podobne wpisy
Jesienny The Rational Edge ezine

Właśnie ukazał się jesienny The Rational Edge ezine (http://ibm.com/developerworks/ecma/campaign/er.jsp?id=376126&imid=68950291&end). Dla fanów RSA jest bardzo ciekawy artykuł, w którym Steve Arnold więcej

Podstawowe dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to podstawowe dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Średniozaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to średniozaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Zaawansowane dobre praktyki inżynierii wymagań

Poniżej opisane wskazówki to zaawansowane dobre praktyki opracowane przez Ian Sommerville i Pete Sawyer. Więcej na ten temat możesz przeczytać więcej

Reklama
MODESTO - licencje Enterprise Architect
Scroll to Top