In den meisten Publikationen zum Thema Requirements liegt der Schwerpunkt auf den Management Aspekten. Viel diskutiert sind die Thema Erfassen und Verwalten von Requirements. Im nachfolgenden Blog arbeite ich heraus, welche wichtigen Aspekte immer wieder zu kurz kommen. Meine Betrachtungen starten mit der Definition von Requirement Engineering im Buch „Basiswissen – Requirement Engineering“ (Klaus Pohl, Chris Rupp).

Definition „Basiswissen – Requirement Engineering“:

Klaus Pohl und Chris Rupp definieren Requirement Engineering wie folgt:
Das Requirement Engineering ist ein systematischer und disziplinierter Ansatz zur Spezifikation und zum Management von Anforderungen mit den folgenden Zielen:

1. Die relevanten Anforderungen zu kennen, Konsens unter den Stakeholdern herzustellen, die Anforderungen konform zu vorgegebenen Standards zu dokumentieren und die Anforderungen systematisch zu managen.
2. Die Wünsche und Bedürfnisse der Stakeholder zu verstehen, zu dokumentieren sowie die Anforderungen zu spezifizieren und zu managen, um das Risiko zu minimieren, dass das System nicht den Wünschen und Bedürfnissen der Stakeholder entspricht.

Klaus Pohl und Chris Rupp identifizieren vier Haupttätigkeiten die damit einhergehen:
Ermitteln, Dokumentieren, Prüfen und abstimmen, Verwalten.

Vorgehensweisen in der Entwicklung sicherheitskritischer Systeme:

Wenn man nun die Vorgehensweisen in der Entwicklung von sicherheitskritischen Systemen dagegen vergleicht, dann stellt man fest, dass dort immer ein Systemaufbruch erfolgt. Zunächst wird das Gesamtsystem mit seinen Schnittstellen zur äußeren Welt als Black-Box in System Requirements beschrieben wird.

Danach wird für das System eine Architektur definiert. Die Funktionen der in der Architektur entstandenen Blöcke werden dann wieder in Form von Black-Box Requirements beschrieben. Ein wichtiges Kriterium ist dabei die Trennung zwischen SW und HW Requirements. Da in der Regel der größte Teil der Funktionalität in SW umgesetzt wird, kann es bei der Software zu weiteren Funktionalen Blöcken kommen.

Die dadurch entstehenden SW und HW Requirements werden dann mit den System Requirements verlinkt. Dadurch entsteht eine durchgehende Traceability die den Systemaufbruch transparent und nachvollziehbar macht.

Zusammenfassung:

Der gerade beschriebene Systemaufbruch mit Hilfe des Requirement Engineering ist ein wesentlicher Aspekt in jeder Entwicklung eines Embedded Systems dar. Auch für die Verifikation vieler Robustness Aspekte ist dieser Schritt sehr wichtig.

Klaus Pohl und Chris Rupp sprechen in Ihrem IREB Standard Werk dieses Thema in Kapitel 8.2 Sichten auf Anforderungen und 8.4 Verfolgbarkeit von Anforderungen an. Der Engineering Aspekt der in diesem Thema enthalten ist, kommt aber aus meiner Sicht deutlich zu kurz. In der Praxis steht man teilweise vor ziemlich komplexen Herausforderungen, wenn man auf den verschiedenen Ebenen die richtigen Requirements erstellen will und diese dann auch noch sauber verlinkt werden sollen. All diese Aspekte lassen sich nur mit Techniken des Engineering lösen und nicht mit dem Verwalten von Anforderungen.

In diesem Sinne sehe ich die Definition von Requirement Engineering als unvollständig an. Darüber hinaus zeigt das Beispiel auch das es wichtige Unterschiede zwischen IT-Software und Embedded Software Entwicklung gibt. Es wird also Zeit dass die Embedded Community sich auch in Form von Büchern dem Thema Requirement Engineering widmet. Die Variabilität von HW Schnittstellen, die Programmierung von Embedded Betriebssystemen und der Nachweis einer 100% strukturellen Code Coverage haben wichtige Auswirkungen auf das Requirements Engineering, die aktuell in den Standard Requirements Engineering Methoden deutlich zu kurz kommen.

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).