Ein Angebot von

Requirement Traceability: Rückverfolgung von Anforderungen pragmatisch umsetzen

| Autor / Redakteur: Andreas Willert / Sebastian Gerstl

Linkbeziehungen in der Requirements Traceability: Die Anzahl der Interfaces wächst polinom zur Anzahl der Elemente, was die Rückverfolgbarkeit bei steigender Anzahl von Anforderungen verkompliziert.
Linkbeziehungen in der Requirements Traceability: Die Anzahl der Interfaces wächst polinom zur Anzahl der Elemente, was die Rückverfolgbarkeit bei steigender Anzahl von Anforderungen verkompliziert. (Bild: Willert Software Tools)

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?

Normen, die Safety-Aspekte adressieren, fordern ausnahmslos eine Traceability. Früher wurde dieser Forderung durch die aufwändige Erstellung und Pflege von sogenannten Cross-Referenz-Listen Genüge getan. Hinsichtlich Engineering-Effizienz ist die händische Pflege von Cross-Referenz-Listen in Bezug auf Nutzen zu Aufwand sicher fragwürdig.

Heute gibt es Anforderungs-Management-Lösungen, mit denen das Erstellen und Pflegen von Linkbeziehungen um ein vielfaches einfacher möglich ist. Aber noch wichtiger, es können aus diesen Links dann je nach Kontext und Fragestellung sehr ausdrucksstarke Traceability-Analysen durchgeführt und dargestellt werden, was Cross-Referenz-Listen nicht leisten können. Das wiederum ist nur möglich, wenn die Metastruktur der Linkbeziehungen die Daten so bereitstellt, wie sie für die Analyse benötigt werden, was in der Praxis leider selten der Fall ist.

Bereits bei DOORS, dem ‚Platzhirsch‘ der Anforderungs-Management-Lösungen, ist die Default-Einstellung der Linkbeziehungen so gewählt, dass alles mit Allem auf Basis eines Default Linktypes verlinkt werden darf. Projekte, in denen diese Default-Einstellung genutzt wird ohne eine Metastruktur zu konfigurieren landen nach wenigen Wochen im Link-Gewirr, in dem über mehrere Ebenen hinweg alles mit Allem verlinkt und eine aussagekräftige Analyse nicht mehr möglich ist.

Dieser Vortrag stellt im ersten Teil den Wirkmechanismus von Linkbeziehungen und darauf aufbauenden Traceability-Analysen dar. Im zweiten Teil geht es dann um die häufigsten Fehler bei der Anwendung, die dazu führen, dass qualitative Traceability-Aussagen nicht möglich sind und damit der Effizienzgewinn nicht erzielt wird.

Requirement Traceability: Die Komplexität beherrschen

Um zu verstehen, in welcher Form die Traceability Einfluss auf die Qualität und damit auch auf die Effizienz ausübt, möchte ich mit einem Blick auf die Komplexität in das Thema einsteigen. Glaubt man den aktuellen Theorien zum Thema Komplexität, dann liegt das Hauptproblem in der Wirkkette: Hidden Links -> Emergenz -> Dysfunktion. Das bedeutet, verborgene Abhängigkeiten führen bei Änderungen eines Gesichtspunktes des Systems zu sogenannten emergenten Zuständen in Bezug zu anderen Gesichtspunkten des Systems.

Ein Zusammenhang beider Gesichtspunkte ist nicht offensichtlich und bildet einen Hidden Link. Emergente Zustände sind Zustände, die nicht erwartet werden und damit auch das Verhalten innerhalb dieser Zustände nicht definiert ist. Dieses kann wiederum zu Fehlverhalten (Dysfunktion) führen, was im schlimmsten Fall Schaden verursachen kann.

Hier sehen wir den Zusammenhang zu Safety Gesichtspunkten. Am Ende soll sichergestellt werden, dass ein System keinen Schaden anrichtet, also Dysfunktion vorgebeugt wird. Gehen wir noch einen Schritt zurück. Wie entstehen denn überhaupt die sogenannten Hidden Links?

Ein Basis-Mechanismus, der seit Jahrzehnten im Engineering eingesetzt wird, um steigender Kompliziertheit zu begegnen ist ‚Teile & Herrsche‘. Im Engineering unter anderem auch in Form von hierarchischer Dekomposition angewandt. Bei jeder Teilung einer Einheit in zwei Teileinheiten ergeben sich potentiell neue Schnittstellen. Wie eingangs aufgeführten Abbildung zu sehen ist wächst bei zunehmender Teilung die Anzahl der neuen Schnittstellen polinom zur Anzahl der einzelnen Elemente.

Die Anwendung von ‚Teile & Herrsche‘ verringert also die Kompliziertheit eines einzelnen Teils, erhöht aber gleichzeitig die Kompliziertheit der Interfaces zwischen den Teilen. Bisher haben wir die Interfaces lediglich auf einer Ebene betrachtet und sprechen aus diesem Grund nur von Kompliziertheit. In der Realität haben wir dieses Beziehungsgeflecht jedoch nicht nur auf einer Ebene, sondern parallel auf mehreren Ebenen.

Erschwerend kommt hinzu, dass die Grenzen zwischen zwei Komponenten, bezogen auf verschiedene Ebenen, nicht unbedingt gleich verlaufen. Zum Beispiel entsprechen logische Komponenten nicht exakt den physikalischen Komponenten. Sehr gut zu sehen bei der Darstellung von U-Bahnnetzen. Die grafische Darstellung des Fahrplans entspricht nur sehr bedingt dem realen Verlauf der U-Bahn.

Ebenen des Software Engineering.
Ebenen des Software Engineering. (Bild: Willert Software Tools)

Betrachten wir exemplarisch das Software Engineering, dann haben wir es in der Regel mit den hier im Bild sehenden Ebenen zu tun. Aus Applikationssicht kommen in der Regel noch weitere Ebenen hinzu, z.B. in Form von überlagerten Kontrollflüssen, wie beispielsweise Not-Aus, Software Update oder Service & Diagnose Modus. Auf jeder Ebene ergeben sich Interfaces einzelner Gesichtspunkte zueinander und die wenigsten davon sind in heutigen Systemen dokumentiert.

Das Wissen über diese Interfaces befindet sich in der Regel in den Köpfen der Entwickler. Haben wir unser System häufig genug in Komponenten zerteilt, und ziehen sich nun Abhängigkeiten über mehrere der obigen Ebenen kreuz und quer über die Komponenten hinweg, dann sind wir bei komplexen Systemen angelangt. Häufig wird vergessen, dass nach jeder hierarchischen Dekomposition der Schritt der Aggregation (Zusammensetzen einzelner Komponenten zu einem Gesamtsystem) folgen muss.

Spätestens an dieser Stelle müssen alle Schnittstellen und vor Allem deren Auswirkungen im Gesamtsystem wieder homogen zueinander passen. Wird ein Zusammenhang übersehen ist das der Einstieg in die Wirkkette Hidden Links -> Emergenz -> Dysfunktion.

Um einem Gedankengang grundsätzlich vorzubeugen: ‚Teile & Herrsche‘ ist immer noch die Grundlage und unverzichtbar zum Managen von Kompliziertheit. Zum Managen von Komplexität benötigen wir darüber hinaus Mechanismen, um die steigende Komplexität der Interfaces in den Griff zu bekommen.

Unser Gehirn als Engpass

Die Neurobiologie besagt, dass unser Gehirn auf der bewussten Ebene ca. 7 +/- 2 Artefakte und/oder Beziehungen in einem Augenblick überblicken (Begreifen) kann. Verglichen mit der Anzahl an potentiellen Artefakten und Schnittstellen komplexer Systeme ist das nicht viel. Stellen Sie sich vor, Sie haben gerade 7 Artefakte parat und deren Zusammenhänge logisch durchdacht, dann fällt Ihnen ein 8. Artefakt ein.

Im selben Moment fällt eines der vorherigen Artefakte, wie bei einem Schieberegister, aus Ihrem Fokus heraus und das geschieht, ohne dass unser Bewusstsein uns darauf aufmerksam macht. Wir merken für gewöhnlich nicht, dass wir in diesem Moment gerade etwas vergessen. Stattdessen befinden wir uns in dem Irrglauben alles zu berücksichtigen. Gibt es nun zufällig einen logischen Zusammenhang zwischen dem 8. neuen Artefakt und dem gerade herausgefallenen haben wir eine potentielle Situation für die Entstehung eines ‚Hidden Link‘.

Wenn wir nun bedenken, dass heutige komplexe Systeme tausende an Artefakten haben, die über deutlich mehr als 7 Ebenen potentiell in Beziehung stehen können, ist es naheliegend, dass es ein Trugschluss ist, dass unser Gehirn in der Lage ist, die möglichen Auswirkungen von Änderungen vollständig zu durchdringen. Abgesehen davon versagt unser Gedächtnis bereits, wenn es die möglichen Zusammenhänge einer begrenzten Auswahl an Artefakten aus dem Stegreif aufführen sollte. Und jetzt stellen Sie sich noch die Entwicklung eines komplexen Systems auf Basis von vielen Gehirnen vor, in denen keines der Gehirne das Gesamtsystem mit all seinen potentiellen Zusammenhängen kennt, sondern immer nur Anteile des Systems.

Wenn also ein einzelnes Gehirn (selbst, wenn es ein optimales Gedächtnis hätte) nicht mehr alle Zusammenhänge kennt, bleibt die spannende Frage: Welche anderen Gehirne des Teams soll es zu Rate ziehen, um mit Sicherheit alle Abhängigkeiten herauszufinden? Noch eines zeigt die Neurobiologie.

Wahrscheinlich wäre unser Unterbewusstsein in der Lage uns aus dem Dilemma zu helfen, denn unser Unterbewusstsein scheint einem optimalen Gedächtnis sehr nahe zu kommen. (Thema Alpha Mode, siehe auch ESER No. 26: Unser Gehirn als Werkzeug) Nur ist die Menschheit noch nicht in der Lage deterministisch mit dem Unterbewusstsein zu arbeiten, und so lange müssen wir andere Wege gehen, wenn wir komplexe Systeme entwickeln möchten, die sich am Ende deterministisch verhalten sollen.

Requirement Traceability: Ausweg aus dem Dilemma

Um dieses Ziel zu erreichen haben sich folgende Maßnahmen als grundlegend hilfreich herausgestellt.

  • 1. Strukturierung und Elimination von Ebenen und Beziehungen auf Basis von Architektur-Design
  • 2. Einschränkung der Ausprägung von Schnittstellen auf Basis von Contract-Based-Design (Auch DbC Design by Contract)
  • 3. Strukturierte Speicherung von Link-Beziehungen zwischen System-Artefakten und darauf basierenden Traceability-Analysen

Die 1. Maßnahme beruht darauf, über geeignete Ausprägung der Schnittstellen das Beziehungsgeflecht einfach und verstehbar zu halten. Z.B. durch ein geeignetes Kommunikationsverfahren den gegenseitigen Impact von Funktionen auf der Zeitebene zu verringern. Bezogen auf obiges Beispiel z.B: durch asynchrone Kommunikation, die auf blockierende Semaphoren verzichtet und damit keine Auswirkung auf der Zeitebene verursacht. Diesen Aspekt werden wir an dieser Stelle nicht weiter verfolgen, was nicht bedeuten soll, dass er nicht eine mindestens gleichwertige Maßnahme ist, um Komplexität zu beherrschen (Siehe auch ESER No. 31: Archtitektur & Design)

Die 2. Maßnahme Contract-Based-Design ist eine hervorragende Möglichkeit Ausprägungen von Schnittstellen einzuschränken oder auch die Basis, um diese automatisiert zu prüfen. Auch diesen Aspekt werden wir an dieser Stelle nicht weiter verfolgen, was nicht bedeutet dass er nicht hoch wirksam ist.

Wir verfolgen hier die 3. Maßnahme, Analysen auf Basis von Traceability. Der Sinn erschließt sich inzwischen von allein, wenn in komplexen Systemen die Zusammenhänge von Artefakten über mehrere Ebenen von unseren Gehirnen nicht mehr vollständig überblickt werden können, liegt es nahe, die Zusammenhänge strukturiert zu dokumentieren oder noch besser in Modellen zu hinterlegen. Das ist im übrigen, was alle Safety Normen mit der Traceability fordern.

Praktiziert wurde es in der Vergangenheit (und auch heute noch sehr häufig) in Form von Cross-Referenz-Listen. In diesen tabellarischen zumeist Excel-Listen stehen z.B. die Zusammenhänge von Kundenanforderungen zu Systemeigenschaften und von dort wiederum zu den System-Implementationen.

Abgesehen davon, dass die Pflege solcher Listen aufwändig ist und aus diesen Listen schnell einmal die Summe aller Abhängigkeiten zu analysieren nicht wirklich praktikabel ist, bleibt noch das Problem, dass diese Abhängigkeiten keine 1:1 Beziehungen, sondern n:n Beziehungen besitzen, was in zweidimensionalen Darstellungen (wie Excel-Tabellen) zu vielfacher Redundanz führt.

Besser geht es auf Basis von Datenbanken (Multidimensional) und geeigneten Werkzeugen, in denen Abhängigkeiten von Artefakten einfach mit der Maus durch Drag & Drop als so genannte Link-Beziehung gespeichert werden können und n:n Beziehungen ohne Bildung von Redundanz möglich sind.

Diese Werkzeuge können dann auf Basis dieser Links sehr elegant sogenannte Trace-Analysen erstellen und übersichtlich darstellen. Solch eine Traceability-Analyse vor Änderungen zu berücksichtigen, ist was die Normen im eigentlichen Sinn fordern. Bevor eine Änderung am System durchgeführt wird sollte dessen Auswirkung auf das Gesamtsystem möglichst vollständig analysiert werden.

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

08.02.19 - Anforderungsmanagement ist nicht mit dem Start eines Projekts abgeschlossen. In der Softwareentwicklung müssen Requirements und Entwicklungskomponenten von Beginn an wie auch dauerhaft verbunden und gepflegt werden. lesen

Grundlagen des Modellbasierten System-Engineering (MBSE)

Grundlagen des Modellbasierten System-Engineering (MBSE)

17.04.18 - Software und Systeme werden zunehmend schwieriger versteh- und beherrschbar. Infolgedessen wenden sich immer mehr Entwickler modellbasiertem System-Engineering (MBSE) zu. Was gibt es dabei zu beachten? lesen

Requirements Engineering –Qualitätssicherung durch Anforderungsmanagement und Rückverfolgbarkeit

Requirements Engineering –Qualitätssicherung durch Anforderungsmanagement und Rückverfolgbarkeit

19.05.15 - Qualitätssicherung kann nicht nur Code-Analyse und Test bedeuten. Denn sie allein stellen nicht sicher, dass Systemanforderungen korrekt umgesetzt wurden. Daher kommt es bei Sicherung der Code-Qualität auch auf konkretes Anforderungsmanagement an. lesen

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2016 entnommen.)

* 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? Infos finden Sie unter www.mycontentfactory.de (ID: 44851379 / Requirements)