Share ZU:
6 August 2013 @ Markus Eberhardt

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:

Matrix_Link

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. 

Diskussion

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*dieses Feld ist erforderlich

Profile Picture

Markus Eberhardt

Kontaktieren Sie Markus Eberhardt

Markus Eberhardt ist seit 2011 bei der HOOD Group und spezialisiert auf Requirements Engineering und Management, mit einem besonderen Fokus auf den wertorientierten Einsatz bewährter Praktiken im agilen Umfeld. Neben seiner Beratungstätigkeit ist Markus Eberhardt auch in der Forschung aktiv, insbesondere im Bereich Requirements Engineering und Künstliche Intelligenz (KI). Er leitet das Teilvorhaben KI4RE im Rahmen des Forschungsvorhabens progressivKI. Sein breites methodisches Fundament wird durch Zertifizierungen des IREB, als Scrum Master, in SAFe und CARS untermauert. Er verfügt über umfangreiche Erfahrung in der Nutzung und Verwaltung von Anforderungen mit IBM Rational DOORS, sowohl aus der Perspektive des Anwenders als auch in der Administration. Sein Wissen teilt er in Workshops, Trainings und durch Coaching in Projektteams.

Wissen, das bewegt!

Verpasse keinen der spannenden Artikel mehr auf blog.hood-group.com und melde dich für unseren Newsletter an! Erfahre alle 2 Wochen als Erster von den neuesten Branchentrends, erhalte exklusive Experten-Tipps und bleib über unsere Veranstaltungen immer auf dem Laufenden. Alles direkt in dein Postfach.

Jetzt abonnieren und keine wichtigen Insights mehr verpassen!