Warum Anforderungsmanagement eine lebenslange Verantwortung darstellt

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Parasoft® Deutschland GmbH

LDRA Inc

Rückverfolgbarkeit und Anforderungs-Management

Die Rückverfolgbarkeit der Anforderungen ist weithin als eine bewährte Entwicklungspraxis anerkannt, mit der sich sicherstellen lässt, dass alle Anforderungen implementiert sind und dass jedes Entwicklungs-Artefakt auf eine oder mehrere Anforderungen zurückverfolgt werden kann.

Normen wie etwa DO-178C, IEC 61508, ISO 26262 und IEC 62304 verlangen die bidirektionale Rückverfolgbarkeit und unterstreichen ständig die Notwendigkeit, jede Entwicklungsstufe von der jeweils darüber liegenden abzuleiten.

Bildergalerie

Abschnitt 5.5c der Norm DO-178C typisiert dies wie folgt: „Es werden Trace-Daten entwickelt, die die bidirektionale Beziehung zwischen den untergeordneten Anforderungen und dem Quellcode aufzeigen. Diese Trace-Daten haben folgenden Zweck:

• 1. Möglichkeit der Verifikation, dass kein Quellcode eine nicht dokumentierte Funktion implementiert.

• 2. Möglichkeit der Verifikation der vollständigen Implementierung der untergeordneten Anforderungen.“

Das von den Normen verlangte Ausmaß an Rückverfolgbarkeit ist unterschiedlich und hängt davon ab, wie kritisch die jeweilige Applikation ist. Zum Beispiel werden weniger kritische Avionik-Applikationen gemäß DO-178C-Level (bzw. DAL) D als „Blackbox“ bezeichnet. Hier wird der Fokus also nicht darauf gerichtet, wie die Software entwickelt wurde und es wird keine Rückverfolgbarkeit zum Quellcode oder zur Softwarearchitektur verlangt. Stattdessen ist es lediglich notwendig, dass die Anforderungen an die Systemsoftware zu den übergeordneten Anforderungen und weiter zu den Testfällen, Testprozeduren und Testergebnissen zurückverfolgt werden können.

Bei den anspruchsvolleren DO-178C-Levels B und C dagegen wird der Quellcode-Entwicklungsprozess als wichtig angesehen, sodass Nachweise für eine bidirektionale Rückverfolgbarkeit von den übergeordneten Anforderungen über die untergeordneten Anforderungen und weiter zum Quellcode verlangt werden. Projekte auf Level A schließlich erfordern die Rückverfolgbarkeit sogar über den Quellcode hinaus bis zum ausführbaren Objektcode.

Die bidirektionale Rückverfolgbarkeit ist zweifellos ein lobenswertes Prinzip. Es kann jedoch leicht ins Wanken geraten, wenn die Anforderungen in letzter Minute geändert werden oder Code geschrieben wird, um während der Tests aufgedeckte Probleme zu korrigieren. Viele Projekte verfallen in ein von unzusammenhängender Softwareentwicklung geprägtes Muster, in dem die Anforderungen, das Design, die Implementierung und die Test-Artefakte von isolierten Entwicklungsphasen produziert werden, was zu dürftigen Verbindungen zwischen der Anforderungsstufe und dem Entwicklungs-Team führt.

Bei Prozessen wie der Wasserfall-Methode und iterativen Beispielen fließt jede Phase in die jeweils nächste, möglicherweise mit Rückmeldungen zu früheren Phasen. Die Rückverfolgbarkeit wird als Bestandteil der Beziehungen zwischen den Phasen angenommen, jedoch wird nur selten der Mechanismus angegeben, mit dem die Trace-Verbindungen aufgezeichnet werden. Die Realität sieht stattdessen so aus, dass zwar jede Phase für sich dank der Investition in moderne Tool-Technologie effizient abgewickelt werden mag, dass aber diese Tools selten automatisch zur Rückverfolgbarkeit zwischen den Entwicklungs-Ebenen beitragen. Die Folge ist, dass die Verbindungen zwischen diesen Ebenen umso schlechter gepflegt werden, je länger ein Projekt dauert.

Die Antwort auf dieses Problem sind die „Trace-Daten“ zwischen den Entwicklungsprozessen, die sich im Kern eines jeden Projekts befinden. Unabhängig davon, ob die Verbindungen physisch aufgezeichnet und gepflegt werden, existieren sie doch auf jeden Fall. Ein Entwickler schafft beispielsweise allein dadurch eine Verbindung, indem er eine Designspezifikation liest und diese bei der Implementierung zugrunde legt. Die Gesamtheit der Beziehungen zwischen diesen Prozessen und die zugehörigen Daten-Artefakte lassen sich als Requirements Traceability Matrix (RTM) betrachten, also als „Anforderungs-Rückverfolgbarkeits-Matrix“. Wenn diese RTM zum Mittelpunkt der Entwicklung gemacht wird, beeinflusst sie sämtliche Phasen der Entwicklung sicherheitskritischer Applikationen von den übergeordneten Anforderungen bis hin zum zielbasierten Testen.

Bild 2 verdeutlicht die Bedeutung, die der RTM beigemessen werden sollte. Die Projektmanager müssen dem Erstellen und Pflegen der RTM die gleiche Priorität geben wie dem Anforderungs-Management, der Versionskontrolle, dem Änderungsmanagement, der Modellierung und dem Testen.

Die RTM muss in jedem Lebenszyklus-Modell explizit wiedergegeben werden, um ihre Bedeutung zu unterstreichen (siehe Bild 3). Mit dieser verstärkten Fokussierung rückt sie in den Mittelpunkt des Entwicklungsprozesses und wirkt sich auf sämtliche Phasen des Designs aus – von den übergeordneten Anforderungen bis zum zielbasierten Deployment.

Auf der obersten Ebene können Anforderungsmanagement- und Rückverfolgbarkeits-Tools zunächst dazu dienen, die von Standards wie der Norm DO-178C formulierten Anforderungen zu erfassen. Diese Anforderungen (oder auch Zielsetzungen) lassen sich dann bis zur Ebene 1, den applikationsspezifischen Software- und Systemanforderungen, verfolgen.

Diese übergeordneten Anforderungen auf Ebene 1 können aus einer definitiven Beschreibung des zu entwickelnden Systems (zum Beispiel eines Steuermoduls für eine Klappe an einem Luftfahrzeug) sowie der zu erfüllenden funktionalen Kriterien (z. B. Ausfahren der Klappe zur Erhöhung des Auftriebskoeffizienten) bestehen. Je nach Umfang und Komplexität des Systems kann diese Ebene weiter unterteilt werden.

Ebene 2 beschreibt das Design des in Ebene 1 definierten Systems. Um beim Beispiel der Klappe zu bleiben, kann es bei den untergeordneten Anforderungen darum gehen, wie das Ausfahren der Klappen variiert wird, da in Ebene 1 eine entsprechende Notwendigkeit formuliert ist.

Die Implementierung auf Ebene 3 bezieht sich auf den Quell- oder Assemblercode, der gemäß Ebene 2 geschrieben wurde. In unserem Beispiel ist klar, dass das Management des Ausfahrgrads der Klappe mehrere Funktionen einbezieht. Die Rückverfolgbarkeit dieser Funktionen zurück zu Ebene 2 enthält Many-to-Few-Beziehungen, sodass in einer manuell verwalteten Matrix leicht eine oder mehrere dieser Beziehungen übersehen werden.

Auf Ebene 4 mit der hostbasierten Verifikation setzt die formale Verifikation ein. Mithilfe einer Teststrategie nach dem Top-Down- oder Bottom-Up-Prinzip (oder einer Kombination aus beiden) helfen Softwaresimulations-Techniken bei der Realisierung von automatisierten Test Harnesses und Testfall-Generatoren je nach Bedarf. Die Testfälle sollten, falls erforderlich, auf Ebene 5 reproduzierbar sein.

In diesem Stadium bestätigen wir, dass die Beispielsoftware zur Steuerung der Klappenposition innerhalb ihrer Entwicklungsumgebung wie beabsichtigt funktioniert, jedoch gibt es keine Garantie dafür, dass sie dies auch in ihrer Zielumgebung tun wird. Die Norm DO-178C trägt diesem Umstand Rechnung und verlangt deshalb nach Tests „zur Verifikation der korrekten Funktion der Software in der Ziel-Computerumgebung“.

Das Testen in der Host-Umgebung allerdings gibt dem Ziel-Test (der häufig mehr Zeit benötigt) lediglich die Möglichkeit zur Bestätigung, dass die Tests in der Zielumgebung fehlerfrei bleiben. In unserem Beispiel stellen wir in der Host-Umgebung sicher, dass Funktionsaufrufe an die zum Klappensteuerungs-System gehörende Software die Werte zurückgibt, die gemäß den von ihnen erfüllten Anforderungen verlangt werden. Diese Information wird anschließend in der RTM aktualisiert.

Unser Klappensteuerungs-System wird nun in der Zielumgebung erneut getestet, um sicherzustellen, dass die Testergebnisse jenen entsprechen, die bei der Ausführung auf dem Host entstanden. Eine weitere RTM-Ebene zeigt, dass die Tests bestätigt wurden.

Pflege der RTM

Die RTM ist immer eine empfehlenswerte Methode, ob sie nun von einer Norm vorgeschrieben wird oder nicht. Das Pflegen einer RTM in Spreadsheets ist allerdings ein logistischer Albtraum, befrachtet mit einem hohen Fehlerrisiko und gegenüber dem tatsächlichen Projektstatus ständig im Rückstand.

Wird die RTM dagegen in einem geeigneten Tool erstellt, erfolgt nicht nur ihre Pflege automatisch, sondern es eröffnet sich auch die Möglichkeit für Filter, Qualitäts-Checks, Fortschrittsüberwachung und das Generieren von Kennzahlen (Bild 4). Die RTM ist damit keine mühsame, zeitraubende und nur widerwillig am Ende eines Projekts ausgeführte Aufgabe mehr, sondern wird zu einem wirkungsvollen Hilfsmittel, das zur effizienten Abwicklung eines Projekts beitragen kann. Die Anforderungen werden zu nutzbaren Artefakten für die Implementierung und das Testen. Hinzu kommt, dass viele der Trace-Verbindungen einfach durch Ausführen der alltäglichen Entwicklungsarbeiten erfasst werden können, wodurch sich das Erstellen der RTM beschleunigt und die Qualität ihrer Inhalte steigt.

Moderne Requirements-Traceability-Lösungen dehnen die Abbildung der Anforderungen bis zu den Verifikationsaufgaben im Zusammenhang mit dem Quellcode aus (Bild 4 zeigt ein Beispiel hierfür). Mit einem solchen Requirements-Traceability-Tool lässt sich die Zielsetzung einer 100-prozentigen Anforderungs-Abdeckung zweifelsfrei messen, unabhängig von der Zahl der Anforderungs-, Design- und Implementierungs-Ebenen. Hierdurch gestaltet sich das Überwachen des Fortschritts, den die Systemfertigstellung macht, höchst unkompliziert.

Konnektivität und der unendliche Entwicklungs-Lebenszyklus

Bei der Entwicklung eines traditionellen, isolierten Systems ist dieses Verfahren eindeutig nützlich genug. Konnektivität aber verlangt nach der Fähigkeit zur Reaktion auf Schwachstellen, die erst im Feld entdeckt werden – und dies im Prinzip über die gesamte Lebensdauer des Produkts hinweg. Jede neue aufgedeckte Schwachstelle führt zu einer geänderten oder neuen Anforderung, auf die eine umgehende Reaktion erforderlich ist, auch wenn das System selbst von den Entwicklern schon längere Zeit nicht mehr in die Hand genommen wurde. In diesem Fall erhält die Fähigkeit, das Notwendige zu isolieren und automatisch nur die betroffenen Funktionen zu testen, einen deutlich höheren Stellenwert.

Mit der Konnektivität verändert sich die Auffassung, dass der Entwicklungsprozess mit der Markteinführung des Produkts oder gar mit dem Abschluss der Produktion endet. Sobald im Feld eine neue Schwachstelle festgestellt wird, führt dies zu einer Änderung an den Anforderungen, verbunden mit dem zusätzlichen Druck, der aus dem Wissen resultiert, dass in einem solchen Fall eine zügige Reaktion auf die geänderten Anforderungen potenziell dazu beitragen kann, Leben zu retten und das Firmenimage zu verbessern. Diese lebenslange Verpflichtung lässt die automatisierte Anforderungs-Rückverfolgbarkeit in einem neuen Licht erscheinen.

Fazit

Das Erstellen einer Requirements Traceability Matrix (RTM) kann vertraglich verlangt oder als empfehlenswerte Methode für erfolgreiche Projekte anerkannt sein. Das Anlegen einer sinnvollen und fehlerfreien RTM aber ist nur möglich, wenn die Anforderungen von hinreichender Qualität sind und der Prozess so gemanagt wird, dass folgendes gewährleistet ist:

• Die Anforderungen decken funktionale sowie safety- und security-bezogene Aspekte ab.

• Es wird akzeptiert, dass sich die Anforderungen über die gesamte Lebensdauer des Projekts hinweg ändern können.

• Der verwendete Entwicklungsprozess berücksichtigt Änderungen und reagiert auf sie.

• Es wird auf die Qualität der Anforderungen geachtet.

• Die Entwicklung wird von den Anforderungen getrieben.

• Eine RTM wird schon am Beginn des Projekts erstellt.

• Die RTM wird zum Verwalten des Fortschritts und zur Verbesserung der Projektqualität genutzt.

• Die RTM wird verwendet, um schnell und effektiv auf Sicherheitslücken zu reagieren, die nach dem Produkt-Deployment zutage treten.

Am Ende kommt dabei ein Projekt heraus, das innerhalb des gesetzten Zeit- und Budgetrahmens fertig wird, Diskrepanzen zwischen der Vision des Auftraggebers und dem tatsächlich Gelieferten vermeidet und einen effektiven Support-Mechanismus für im Einsatz befindliche vernetzte Systeme hervorbringt.

Der Autor

* Mark Pitchford erwarb seinen Abschluss als Bachelor of Science an der Trent University, Nottingham, und ist seit mehr als 20 Jahren Diplomingenieur. Von 2007 bis 2014 arbeitete er als FAE bei LDRA. Im Anschluss wechselte er als Technical Manager für den Bereich EMEA zu Lynx Software Techno¬logies, bevor er im Februar 2017 zu LDRA zurückkehrte. Dort ist er als Tech¬nical Specialist tätig.

Einfach und iterativ

Praxiserprobte Anforderungsmodellierung

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

(ID:45733902)