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.
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:
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.
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. 
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.
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».
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.
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».
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. 
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ń :-).
