Requirements Traceability Analyse oder wieviele Links fehlen noch?

Welcher Requirements Manager hat diese Frage noch nicht von seinem Projekt Manager gestellt bekommen? Aber was verbirgt sich hinter dieser Frage?

PM-1)     In der Regel möchte der Projekt Manager wissen, wie es um die Traceability in seinem Projekt steht (Traceability Coverage Analyse). Die Motivation für diese Frage kann z.B. die Auskunftspflicht gegenüber einer Behörde hinsichtlich der Umsetzung ihrer Anforderungen oder die Vorschriftenlage in einem regulierten Bereich sein.

PM-2)     Implizit erwartet der Projekt Manager eine Aussage, wann eine ausreichende Traceability erreicht ist oder möchte wenigstens einen diesbezüglichen Trend erkennen (Traceability Coverage Metric). Mit Hilfe dieser Informationen kann der Projektmanager die aktuelle Lage einschätzen und ggf. korrektive Maßnahmen einleiten.

Obwohl sich die Frage „Wieviele Links fehlen noch?“ zunächst trivial anhören mag, stellt sie den Requirements Manager doch vor Herausforderungen:

RM-1)     Wieviele Links sind den überhaupt erforderlich? (Expected Links Assessment, Requirements Apportionment)

RM-2)     Wieviele Links sind zwar da, aber nicht erforderlich? (Obsolete Links Analyse)

RM-3)     Und schließlich, wieviele Links fehlen noch. (Missing Links Analyse)

Versetzen wir uns einmal in die Rolle des Requirements Managers, der mit der Frage RM-1 konfrontiert wird. Gehen wir hierfür von einem Projekt aus, in dem eine System Spezifikation mit 2000 Systemanforderungen erstellt wird und sich hieraus Anforderungen für 30 Komponenten mit in Summe über 30000 Requirements ableiten. In den wenigsten Fällen wird der Requirements Manager in der Lage sein, für jede System Anforderung die Relevanz für die Komponenten beurteilen zu können. 

Ein erster Lösungsansatz könnte darin bestehen, einfach alle System Anforderungen mit allen Komponenten Anforderungen zu verlinken. Der Requirements Manager hätte dann die Gewissheit, dass keine Links fehlen. Falls er aber mit der Frage RM-2 konfrontiert würde, könnte er nur verlegen zu Boden schauen und mit den Schultern zucken. Es muss also ein andere Lösung her.

Dieser andere Lösungsansatz geht davon aus, das die Frage RM-1 am Besten vom verantwortlichen System Ingenieur geklärt werden kann, da dieser das Gesamtsystem vor Augen hat und deshalb auch über eine Vorstellung verfügen sollte, welchen Beitrag die Komponenten im Gesamtsystem leisten. Deshalb führt bei diesem Lösungsansatz der Requirements Manager zunächst zusammen  mit dem System Ingenieur eine Bewertung der System Requirements hinsichtlich ihrer Relevanz für die Komponenten durch (Expected Links Assessment) und vermerkt das Resultat dieser Bewertung in einem geeigneten Aufzählungsattribut je Systemanforderung (Requirements Apportionment).

Der Requirements Manager kann jetzt durch geeignete Filtertechniken ein Liste von Anforderungen je Komponenten zusammenstellen und diese Komponenten Verantwortlichen zur Verfügung stellen. Diese können dann anhand dieser Listen die erforderlichen Links generieren. (Obsolete Link Analyse & Missing Link Analyse)

Um die Frage PM-1 beantworten zu können, wird der Requirements Manager Auswertungen erstellen, in welchen die erforderlichen Links mit den vorhandenen Links verglichen werden. Diese Auswertung kann je Kombination System Anforderung – Komponenten Anforderung zu vier verschiedenen Fällen führen:

a)      Es wird ein Link von der System Anforderung zur Komponenten Anforderung erwartet und es ist ein entsprechender Link vorhanden (OK).

b)      Es wird ein Link von der System Anforderung zur Komponenten Anforderung erwartet und es ist kein Link vorhanden (Missing Link).

c)       Es wird kein Link von der System Anforderung zur Komponenten Anforderung erwartet und es ist ein Link vorhanden (Obsolete Link).

d)      Es wird kein Link von der System Anforderung zur Komponenten Anforderung erwartet und es ist kein Link vorhanden (OK).

Während die Fälle a) und d) keine Probleme verursachen, stellen die Fälle b) und c) einen Konflikt dar. Eine Auswertung von Fall b) liefert eine Antwort auf die Frage RM-3, während die Auswertung von Fall c) eine Antwort auf die Frage RM-2 liefert.

Zur Auflösung der Konflikte gibt es grundsätzlich zwei Ansätze, die der System Ingenieur und der Komponenten Verantwortliche gemeinsam diskutieren können:

• Der Komponenten Verantwortliche zieht den fehlenden Link (Fall b) bzw. entfernt den unerwarteten Link (Fall c)
  oder
• Der System Ingenieur korrigiert das Assessment hinsichtlich der Relevanz dieser Komponente.

Mit regelmäßigen Auswertungen kann der Requirements Manager einerseits die Komponenten Verantwortlichen auf den Status Ihrer Traceablity hinweisen und Konfliktfälle mit dem System Ingenieur klären. Vor allem aber ist der Requirements Manager in der Lage, jederzeit dem Projekt Manager eine Auskunft auf die beiden Fragen PM-1 und PM-2 zu geben, damit der Projekt Manager ggf. rechtzeitig korrektive Maßnahmen einleiten kann und hinsichtlich der Traceability keinen „Blindflug“ unternehmen muss. Ein weiterer Vorteil dieser Methode ist, dass sich die Diskussion auf Konfliktfälle konzentriert, da diese im Fokus der Analyse stehen. Der größte Vorteil liegt meines Erachtens in der Realisierung einer großen Schleife, in welcher in einer Top-Down Vorgehensweise ein Requirements Apportionment durch den System Ingenieur vorgegeben wird und anschließend in einer Bottom-Up Vorgehensweise die Umsetzung der Verlinkung durch den Komponenten Verantwortlichen folgt. 

Markus Eberhardt

Kontaktieren Sie Markus Eberhardt

Markus Eberhardt ist seit 2011 Senior Consultant bei der HOOD Group für Requirements Engineering und Management. Bei Agile-by-HOOD arbeitet er als Coach mit Leidenschaft und viel Herr Markus Eberhardt ist als Senior Consultant bei der HOOD GmbH sowohl im agilen Umfeld als auch im klassischen Requirements Engineering (RE) und Requirements Management tätig. Sein Spezialgebiet ist der wertorientierte Einsatz von bewährten Praktiken des Requirements Engineering im agilen Umfeld. Die Zertifizierungen des IREB, als Scrum Master, in SAFe und CARS bilden hierfür ein breites methodisches Fundament. Große Erfahrung besitzt er zum Beispiel mit IBM Rational DOORS zur Erfassung und Verwaltung von Anforderungen, sowohl aus Sicht des Anwenders als auch aus Sicht der Betriebsführung sowie mit dem äquivalenten Einsatz von TFS. Sein Wissen gibt Herr Eberhardt in Workshops, Trainings und durch Coaching in Projektteams weiter.