• Twitter
  • LinkedIn
  • Xing
+49 7353 981781
Heicon Ulm
  • HOME
  • UNTERNEHMEN
  • PRODUKTE
  • HEICON BLOG
  • Deutsch
    • Deutsch
    • English
  • Menü Menü
Du bist hier: Startseite1 / A_Requirement Engineering2 / Requirement- und Test Traceability – Mit Köpfchen!

Requirement- und Test Traceability – Mit Köpfchen!

A_Requirement Engineering

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.

Requirement und Test 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).

2. Dezember 2019/von HEICON Global Engineering GmbH
Schlagworte: DO178, EN50128, EN50657, Funktionale Sicherheit, ISO26262, Requirements, Rückwärtsverfolgbarkeit, Traceability, Vorwärtsverfolgbarkeit
Eintrag teilen
  • Teilen auf Facebook
  • Teilen auf Twitter
  • Teilen auf WhatsApp
  • Teilen auf LinkedIn
https://heicon-ulm.de/wp-content/uploads/2020/03/DI1A6236_klein_Requirement_Eng.png 475 684 HEICON Global Engineering GmbH https://heicon-ulm.de/wp-content/uploads/2020/07/heicon-logo-5.png HEICON Global Engineering GmbH2019-12-02 20:24:272021-06-06 18:34:48Requirement- und Test Traceability – Mit Köpfchen!
Das könnte Dich auch interessieren
ISO26262ISO 26262: Rückwirkungsfreiheit – Was ist das?
ISO26262ISO 26262 ASIL Dekomposition – Chancen und Risiken!
Funktionale SicherheitDie non-intrusive Messung der strukturellen Coverage
BahnEN50128 konfigurierbare Systeme: Fluch oder Segen?
Funktionale SicherheitRückwirkungsfreiheit – Die gelebte Praxis!
Funktionale SicherheitStrukturelle Source Code Überdeckung – Aufwand ohne Nutzen?

Kategorien

  • A_Requirement Engineering
  • B_Validation und Verifikation
  • C_Konfig-/ Änderungsmanagement
  • D_Security
  • FuSi_Allgemein
  • FuSi_Automotive
  • FuSi_Bahn
  • FuSi_Industrie
  • FuSi_Landwirtschaft
  • FuSi_Luftfahrt

Kontakt

HEICON Global Engineering GmbH
Dipl. Ing. (FH) Martin Heininger
Kreuzweg 22
88477 Schwendi

Tel.: +49 7353 – 98 17 81
Mobil: +49 176 – 24 73 99 60

Email: info[at]heicon-ulm.de

IMPRESSUM  |  DATENSCHUTZ

ISO 26262 ASIL Dekomposition – Chancen und Risiken!ISO26262ISO26262ISO 26262 Safety Case – Erfolgsfaktoren: Management und Traceability
Nach oben scrollen