Ein Angebot von

Drei Wege zur Requirements Traceability Matrix

| Autor / Redakteur: Andreas Willert / Sebastian Gerstl

Um moderne Safety-Normen zu erfüllen wird häufig nur eine Tracebility Matrix in Form einer Excel-Tabelle verwendet. Doch meist reichen solch simple Maßnahmen für ein funktionell sicheres System nicht aus.
Um moderne Safety-Normen zu erfüllen wird häufig nur eine Tracebility Matrix in Form einer Excel-Tabelle verwendet. Doch meist reichen solch simple Maßnahmen für ein funktionell sicheres System nicht aus. (Bild: SODIUS WILLERT SAS)

Um Safety-Normen wie ISO 26262 oder IEC 61508 zu erfüllen, ist eine nachweisliche Rückverfolgbarkeit der Anforderungen nötig. Dabei wird häufig auf eine Tracebility Matrix in Form eines Excel-Sheets zurückgegriffen. Doch auch wenn man damit die Normen nominell erfüllt, reicht dies für ein funktionell wirklich sicheres System meist nicht aus.

Einer der Hauptgründe, warum in der Praxis in Traceability investiert wird, ist wahrscheinlich dessen Forderung von Safety Normen (ISO 26262, IEC 61508 und weitere) im regulativen Umfeld. Um die Audits in obigem Kontext zu bestehen, wird der Nachweis einer Traceability benötigt. Dieser wird leider häufig nur als notwendiges Übel betrachtet und eine Bereitstellung daher mit möglichst wenig Aufwand und Kosten ausgeführt. Die Lösung ist dann eine Traceability Matrix z.B. in Form einer Excel-Tabelle. Auch wenn damit die Norm erfüllt wird; dem Aufwand für Erstellung und Pflege steht aus Engineering Sicht wenig Nutzen gegenüber.

In Folge werden alternative Möglichkeiten vorgestellt, die ein sehr viel besseres Kosten/Nutzen-Verhältnis und eine wirkliche Hilfe im Engineering darstellen.

1. Die Excel Cross Reference bzw. Traceability Matrix

Einer der Hauptgründe für die Traceability, aus Sicht der Normen, ist die Coverage-Analyse bzw Abdeckungs-Analyse, zum Beispiel die Anforderungen gegenüber dem Test (Spezifikation zur Verifikation). Also der Beweis, dass jede einzelne Anforderung (oder Spezifikationsaussage) durch einen Testcase (oder Verifikationsspezifikation) abgedeckt wird. Einzelne Spezifikationsaussagen oder Verifikations-Definitionen als abgeschlossene Entität werden in Folge auch als Artefakt bezeichnet.

Das ist mit einer Excel Traceability Matrix grundsätzlich möglich und wird auch häufig so praktiziert (Bild 1): In Zeilen, in denen kein ‚x‘ vorhanden ist (orange), gibt es zu einer Anforderung keinen Testcase, was eine Lücke in der Abdeckung aufzeigt, die beseitigt oder begründet werden muss.

Aber die Forderungen der Normen gehen noch einen Schritt weiter. Sie fordern, dass die Abdeckung auch auf Korrektheit gereviewt wird. Also, dass eine Person prüft, ob die Verifikation (z.B. in Form eines Testcases) auch die Anforderung vollumfänglich und richtig abdeckt. Für einen Review müssen sowohl die Definition des Testcases, als auch die der entsprechenden Anforderung (z.B. als Text) verfügbar sein. Die Excel-Matrix alleine bietet dafür keinen geeigneten Viewpoint (Domänen- und Rollen-spezifische Sicht auf Daten). Sie enthält nur die Information der Verflechtung von mehreren anderen Dokumenten, deren Aussagen/Inhalte nun in einem händischen Vorgang entsprechend Artefakt für Artefakt zusammengeführt und protokolliert werden müssen.

Einsatz einer Excel-Matrix: einfach, aber voller Nachteile

Die Excel-Matrix würde einen geeigneten Viewpoint darstellen, wenn anstelle der jeweiligen IDs auch die entsprechenden Texte in die Traceability-Tabelle aufgenommen werden. Das bringt aber andere Nachteile mit sich: Häufig sind die beschreibenden Texte länger, was die Tabelle stark aufbläht. Der Pflegeaufwand bei Änderungen steigt, da nun alle Änderungen an den Artefakten auch in der Matrix nachgepflegt werden müssen, was in der Praxis meistens unterbleibt. Anforderungen, Spezifikation, Verifikation und Traceability-Matrix werden im Laufe der Zeit inkongruent.

Es gibt noch viele weitere Nachteile. So müssen die IDs der einzelnen Artefakte (Anforderungen, Spezifikationssaussagen, Verifikationsspezifikationen, Testcases) eindeutig verwaltet werden. Und Linkbeziehungen sind über Versionen und Varianten hinweg so nicht mit vertretbarem Aufwand handhabbar.

Bild 1: Cross Referenz-Liste zur Abbildung der Traceability auf Basis einer Excel-Tabelle
Bild 1: Cross Referenz-Liste zur Abbildung der Traceability auf Basis einer Excel-Tabelle (Bild: SODIUS WILLERT SAS)

Der eigentliche Nutzen von Traceability im Engineering

Eines der meist eingesetzten Engineering-Muster, um Komplexität zu begegnen, ist ‚Hierarchische Dekomposition‘ eine Form von ‚Teile und Herrsche‘. Die Nebenwirkung: Mit jeder weiteren Entität wachsen die Schnittstellen polinomiell (siehe Bild 2). Komplexität kann nicht eliminiert werden, sie kann nur verschoben werden. In diesem Fall von den Entitäten in die Schnittstellen.

Auf einer Ebene sind die Schnittstellen noch beherrschbar, wir sprechen eher von Kompliziertheit. Aber bei heutigen komplexen Systemen breiten sich die Schnittstellen über mehrere Ebenen aus, wie Zeit, Logik, Daten, Versionen, Varianten oder überlagerte Kontrollflüsse. Die Wirkkette steigender Komplexität ist in Bild 3 zu sehen.

Bild 2: Die Anwendung des Engineering Mechanismus ‚Teile und Herrsche‘ (Dekomposition) verschiebt die Komplexität von den Elementen auf die Schnittstellen.
Bild 2: Die Anwendung des Engineering Mechanismus ‚Teile und Herrsche‘ (Dekomposition) verschiebt die Komplexität von den Elementen auf die Schnittstellen. (Bild: SODIUS WILLERT SAS)

Traceability ist eine geeignete Maßnahme, um diese Wirkkette zu unterbrechen. Dazu muss sie aber auch im Engineering angewandt werden. Folgende Techniken sind dazu besser geeignet, als eine Excel-Traceability-Matrix. Eine der Herausforderungen ist dabei die Traceability über mehrere Fachdisziplinen (und damit verbunden über mehrere Methoden und Werkzeuge) hinweg.

2. Werkzeugübergreifende Synchronisation von Artefakten

Eine bereits seit Jahrzehnten angewandte Technik ist die werkzeugübergreifende Bereitstellung der Daten. So sind etwa die mit DOORS erstellten Anforderungen auch zu Enterprise Architekt (EA) synchronisiert und können dort mit Architektur-Elementen verlinkt werden. DOORS und EA stehen an dieser Stelle nur exemplarisch als Werkzeuge. All diese Architektur-Elemente werden dann mit den dazugehörigen Linkbeziehungen zurück zu DOORS synchronisiert.

Bild 3: Bei steigender Anzahl von Schnittstellen (vgl. Bild 2) erhöht sich in Folge die Anzahl von so genannten Hidden Links, die sich direkt negativ auf die Qualität auswirken.
Bild 3: Bei steigender Anzahl von Schnittstellen (vgl. Bild 2) erhöht sich in Folge die Anzahl von so genannten Hidden Links, die sich direkt negativ auf die Qualität auswirken. (Bild: SODIUS WILLERT SAS)

Nun können entweder in DOORS oder in EA Traceability-Matrixen automatisch erstellt und Traceability-Analysen durchgeführt werden. Auf Basis von Suspect Links lässt sich die Analyse sogar automatisieren und in das tägliche Engineering integrieren. Ändert sich ein Artefakt, z.B. eine Anforderung, dann werden alle damit verlinkten Artefakte, z.B. ein Architektur-Element, als Suspekt gekennzeichnet. Der Entwickler sieht also in seiner Domäne (in seinem Werkzeug), dass sich im Kontext dieses Elements etwas geändert hat und kann mögliche Auswirkungen berücksichtigen. Damit lässt sich das Potential an Hidden Links sehr effizient verringern.

Der größte Nachteil dieser Technik ist die Synchronisation an sich. Nach jeder Änderung müsste sie theoretisch durchgeführt werden, was in der Praxis unrealistisch ist. In großen Projekten mit großen Datenmengen kann die Synchronisation bis in den Bereich von Stunden dauern. Während dieser Zeit sollten sich die Daten nicht ändern, was den Arbeitsfluss des Teams behindern kann. Ein weiterer Nachteil sind die Viewpoints. In der Regel werden Artefakte in dem jeweiligen anderen Werkzeug nur textuell dargestellt und nicht in ihrer möglichen grafischen Repräsentanz.

3. Traceability auf Basis von OSLC

Seit einigen Jahren gibt es eine Technologie, die auf einer SOA (Service-Orientierte Architektur) basiert und obige Nachteile nicht hat. OSLC (Open Services for Lifecycle Collaboration) ist ein Standard, der auf https://open-services.net von OASIS gehostet wird.

Diesem Ansatz liegt der Gedanke zu Grunde, dass verschiedene Engineering-Disziplinen gegenseitige Services (Dienste) beanspruchen, um einen nahtlosen und homogenen Workflow zwischen ihnen zu ermöglichen. Das kann zum Beispiel der Dienst für die Erstellung eines Links zu einem Artefakt sein. Um bei obigem Beispiel zu bleiben, könnte DOORS einen Dienst von EA in Anspruch nehmen, um einen eigenen Artefakt mit einem EA-Artefakt zu verlinken (wobei hier allerdings anzumerken ist, dass EA derzeit OSLC nicht unterstützt). Diese Services sind standardisiert. Unterstützt also Werkzeug A einen Dienst kann er in Verbindung mit allen anderen Werkzeugen, die diesen Dienst ebenfalls unterstützen genutzt werden – auch herstellerübergreifend.

Neben dem Verlinken von Artefakten gibt es viele weitere nützliche Dienste, beispielsweise für Configuration- oder Varianten-Management. Traceability auf Basis von Linkbeziehungen über Varianten hinweg stellt noch einmal eine neue Dimension dar, die häufig unterschätzt wird. Speziell dafür gibt es den Standard ‚GlobalConfig‘ innerhalb von OSLC.

Ein eleganter OSLC-Dienst ist etwa ‚Mouse Over‘. Damit lassen sich Linkbeziehungen verfolgen, unabhängig davon in welchem Kontext (Werkzeug, Methode, Viewpoint usw.) das verlinkte Artefakt liegt. Ist der Viewpoint im Originalkontext z.B. ein UML-Diagramm, wird dieses angezeigt, obwohl das Werkzeug, in dem der Entwickler gerade arbeitet, eventuell gar keine UML-Diagramme anzeigen kann.

Man könnte sagen, dass OSLC die Königsdisziplin im Bereich ALM und PLM darstellt. Da der Standard noch relativ jung ist, wird er leider noch nicht von allen Werkzeugen unterstützt, aber mit jedem Jahr werden es mehr. Für einige Werkzeuge gibt es auch sogenannte OSLC-Konnektoren von Drittanbietern.

Daten-Synchronisation zwischen Repositories

Es existieren am Markt verschiedene Unternehmen und Produkte, die eine Synchronisation von Daten zwischen proprietären Repositories unterschiedlicher Werkzeuge ermöglichen. Die folgende Auflistung geeigneter Tools erhebt keinen Anspruch auf Vollständigkeit:

  • PROSTEP (Open DXM Integration Framework),
  • IBM Rational (Gateway),
  • SodiusWillert (ReqXChanger),
  • SodiusWillert (SECollab),
  • Agosense (Symphony), und
  • Dassault Systems (CATIA REQTIFY).

OSLC-Lösungen

Ähnlich wie bei ECLIPSE war IBM Initiator des OSLC-Standards. Intern bezeichnet IBM die Technologie als ‚JAZZ’, das mit OSLC kompatibel ist. Weitere Hersteller, die sich für OSLC engagieren, sind auf https://open-services.net aufgeführt.

Anbieter von OSLC-Konnektoren für Werkzeuge, die aktuell kein OSLC unterstützen, sind unter anderem:

  • Tasktop (Sync) ,
  • SodiusWillert (OSLC Connect for Jira),
  • SodiusWillert (OSLC Connect for Windchill).

Fazit: Für und wider der drei Traceability-Methoden

Eine einfache Möglichkeit für die Verwaltung von Dokumenten, Engineering-Disziplin und werkzeugübergreifenden Verlinkung von Artefakten ist eine elementare Voraussetzung für verlässliche und aussagekräftige Traceability Analysen im täglichen Umfeld des Engineering. Das kann etwa auf Basis von Suspect Links erfolgen. Die Möglichkeit, den Artefakten Zustände anzuhängen, vereinfacht die Verfolgung von Änderungen oder das protokollieren von Reviews.

All diese Möglichkeiten bilden die Basis für Effizientes Engineering, in dem Fehler früher erkannt und damit Voraussetzung von Continuous Engineering werden. Somit ergeben sie heute nicht nur im regulativen Umfeld Sinn. Aber um das zu bewerkstelligen, werden Engineering-Werkzeuge benötigt, die weit über die Fähigkeiten von Word- und Excel-Dateien hinausgehen.

Abschließend gilt auch hier die Grundregel: Nichts auf der Welt ist kostenlos. Der initiale Aufwand zur Bereitstellung der Infrastruktur für eine Excel-Cross-Referenz- (Traceability-) Liste ist minimal. Der Nutzen ist es allerdings ebenfalls. Rechnet man dann auch noch den Aufwand für Erstellung und Pflege hinzu, der sich in der Folge daraus ergibt, wird der Einsatz dieser augenscheinlich einfachen Technik sehr fragwürdig.

Lösungen zur Synchronisation der Daten zwischen Werkzeugen liegen im Bereich von wenigen hundert Euros für einen Arbeitsplatz bis hin zu einigen tausend Euros für Teamlösungen. Der Aufwand für das Verlinken von Artefakten und der daraus automatisierten Traceability ist dafür vergleichsweise gering. Der Nutzen einer aktuellen Traceability ist allerdings erheblich größer.

Die Unterstützung der OSLC-Technologie kostet dagegen an sich erst einmal nichts. Aber die dafür notwendige IT-Infrastruktur stellt schon erheblich höhere Anforderungen und damit Kosten dar.

Wenn die OSLC-Unterstützung durch Konnektoren von Drittanbietern kommt, müssen auch diese bezahlt werden. Das liegt dann schon im Bereich von tausenden von Euros für ein größeres Team. Aber in dieser Technologie liegt vergleichsweise hohes Potential an Effizienz- und Qualitätssteigerung im Engineering. Das Bestehen eines Safety-Audits ist dann nur noch Nebensache.

Requirement Traceability: Rückverfolgung von Anforderungen pragmatisch umsetzen

Requirement Traceability: Rückverfolgung von Anforderungen pragmatisch umsetzen

25.06.19 - In sicherheitskritischen Anwendungen ist heute eine Rückverfolgbarkeit der gestellten Anforderungen verpflichtend, wenn man die gängigen Normen einhalten will. Wie lassen sich Traceability-Analysen wirkungsvoll umsetzen? Und welche potentielle Fehlerquellen lauern in der Umsetzung? lesen

Prinzipien der Einfachheit beim Requirements Engineering

Prinzipien der Einfachheit beim Requirements Engineering

22.08.19 - Oft gehen Entwickler mit dem hehren Ziel, die Anforderungen an ihr Projekt so genau wie möglich zu erfassen, an die Arbeit. Doch dies kann zu einem Ausarten der Komplexität führen, die sich irgendwann nicht mehr überschauen lässt. Daher lohnt es sich, auch mal den Anforderungsstall ordentlich auszumisten. lesen

Dieser Beitrag ist erschienen im Sonderheft Embedded Software Engineering der Fachzeitschrift ELEKTRONIKPRAXIS (Download PDF)

* Andreas Willert ist Gründer und CEO der Willert Software Tools GmbH.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 46165475 / Entwurf)