Requirement- und Test Traceability – Mit Köpfchen!

Requirement- und Test Traceability: Standen Sie auch schon mal vor folgender Situation: Ihr sicherheitsgerichtetes Projekt steht kurz vor dem Abschluss, und Sie haben nahezu alle Teilprodukte untereinander in Beziehung gesetzt („verlinkt“). Es wurde erheblicher Aufwand in die Traceability gesteckt!
In einem Audit (z.B. interne QS, Kunde, Behörde) sollen Sie aufzeigen, welche Software Requirements sich aus welchen System Requirements herleiten. Jedes Software Requirement ist auf eines oder mehrere System Requirements verlinkt und auch jedes System Requirement ist auf ein oder mehrere Software- oder Hardware Requirements verlinkt.

Traceability und Audits

Trotzdem wird im Audit festgestellt, dass viele Software Requirements, zwar schon „irgendwie“ mit den verlinkten System Requirements zusammenhängen, eine durchgängige Strategie ist aber nicht erkennbar. Spätestens, wenn dann bei weiteren auditierten Beispielen festgestellt wird, dass manche Aspekte von System Requirements gar nicht in der Software (oder Hardware) umgesetzt sind wird das Audit stressig.
Nach so einer Audit-Erfahrung stellt man sich fast zwangsläufig die Frage, was den Einsatz von (teuren) Tools rechtfertigt und vor allem, ob man beim nächsten Mal den Aufwand für die Requirement- und Test Traceability nicht drastisch reduzieren sollte.
Statt dies zu tun, sollte man aber die (echten) Ursache für das Problem ausfindig machen.
Grundsätzlich ist der Einsatz von Tools sehr sinnvoll und es gibt auch den Mehrwert der Traceability.

Traceability „Alles zu Allem“

Eine wesentliche Ursache für die beschriebenen Probleme ist oft das sogenannte „Verlinken von Allem zu Allem“, als Ersatz für die Anwendung einer projektspezifischen Traceability Strategie. Bevor es die komfortable Toolunterstützung bei der Erstellung der Traceability gab, war dieses Problem aber schlicht nicht vorhanden. Der Aufwand für unüberlegte und von Hand zu erstellender Traceability war viel zu groß. Aus diesem Aspekt heraus war man gezwungen, sich sehr intensive Gedanken zu folgenden Herausforderungen zu machen und es musste eine effiziente Lösung gefunden werden:

1. Welche Maßnahmen zur Risikominimierung aus der Gefahren- und Risikoanalyse, werden in welchem(n) Requirement(s) umgesetzt?
2. Welche Software Requirements implementieren (wirklich!) welche Systemfunktionalität (=System Requirements)?
3. Welches Software Requirement leitet sich nicht aus System Requirements ab, sondern entsteht als Konsequenz von Architekturentscheidungen und sollte daher als „Derived“ Requirement (= kein Link zu einem anderen funktionalen Requirement) stehen bleiben?
4. Welcher Source Code leitet sich nicht aus funktionalen Requirements ab, sondern z.B. aus der Schnittstelle zur Hardware?
5. Welcher Source Code entsteht z.B.: auf Grund von angewandten Prinzipien wie Defensives Programmieren und nicht aufgrund von funktionalen Requirements?
6. Welche Tests verifizieren wirklich welches Requirement?
7. In welchem Architekturblock sind welche Requirements umgesetzt?

Diese Liste an Fragestellungen erhebt keinen Anspruch auf Vollständigkeit.
Sie bildet aber eine sehr gute Grundlage um das zu Beginn beschriebene Problem gar nicht erst entstehen zu lassen. Heutzutage ist es wesentlich einfacher, die einzelnen Artefakte im Software Entwicklungsprozess zu einander in Beziehung zu setzen. Es gibt eine Vielzahl von datenbankgestützten Tools die den Aufwand und die Fehleranfälligkeit für die Erstellung einer Traceability dramatisch reduzieren. Wenn man dann sich die oben beschriebenen Fragestellungen bewusst macht und entsprechende Lösungen erarbeitet, ist man auf einem guten Weg den gewünschten Mehrwert der Verlinkung einzelner Artefakte zu erzielen.

Fazit:

Der Mehrwert einer guten Traceability liegt im Wesentlichen in folgenden Aspekten:

1. Sehr effektives Mittel zur Sicherstellung, dass das vom Kunden gewünschte Produkt auch entsprechend gebaut wurde.
2. Einfache und schnelle Nachvollziehbarkeit des Weges vom System Requirement zum Source Code.
3. Unterstützung von Einflussanalysen im Falle von Änderungen.
4. Unterstützung/Vereinfachung einer Vollständigkeitsprüfung bezüglich Implementierung.
5. Unterstützung/Vereinfachung einer Vollständigkeitsprüfung bezüglich Verifikation.

Weitere HEICON Blog Beiträge zum Thema:

• RE Engineering – Aspekte die die schon in der Theorie zu kurz kommen
• Strukturelle Source Code Coverage und Requirements – Gibt’s da einen Zusammenhang?
• Wieviel Requirement Ebenen braucht man in der FuSi

Ihre individuellen Fragen zum Requirements Engineering beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).