In meinen täglichen Projekten in der Automobilbranche und der Automatisierungstechnik treffe ich immer wieder auf die Frage, wie viele Requirement Ebenen denn nun geschrieben werden müssen. Das ist eine spannende Frage, insbesondere wenn man viel Erfahrung mit Luftfahrtprojekten hat.
Daher möchte ich in diesem Blogbeitrag dieses Thema einmal etwas näher beleuchten. Zunächst möchte ich die Vorgaben der FuSi-Standards IEC 61508, ISO 26262 und DO 178B/C vergleichen. Abschließend gebe ich noch Projekterfahrungshinweise, die auf meiner mehr als 15 jährigen Erfahrung beruhen.
Aus meiner Sicht unterteilt sich eine gute Software Spezifikation in zwei wesentliche Teile: Architektur/Design und textuelle Requirements.
Die Architektur beschreibt, meist überwiegend in grafischer Form, die Struktur und den Aufbau der Software. Insbesondere werden auch Daten- und Kontrollflüsse dargestellt. Der Schwerpunkt von textuellen Requirements wiederum liegt auf der Beschreibung der Funktionalität, sowie den zeitlichen Anforderungen an das System.
Die Ausgangsfrage dieses Blogs bezieht sich auf die Anzahl der Ebenen von textuellen Requirements. Nicht mitgezählt wird hier die Ebene der System-Requirements, welche immer vorhanden sein muss.

IEC 61508:

Die IEC 61508 definiert im Teil 3, Tabelle A1 eine Requirement Ebene. Wobei sehr interessant ist, dass bei den empfohlenen Verfahren und Maßnahmen für semi-formale Methoden keine Maßnahmen wie Requirements Schablonen etc. genannt sind. Man könnte hier fast den Eindruck gewinnen, als ob textuelle Requirements bei der Erstellung der IEC 61508 gar nicht im Fokus standen. Denn alle weiteren Verfahren und Maßnahmen (Tabelle A2 und A4) beziehen sich eindeutig auf die Architektur und das Design der Software.
Damit ist festzuhalten, dass man gemäß der IEC 61508 maximal eine Ebene von textuellen Software Requirements erstellen muss.

ISO 26262:

Der den Software Prozess beschreibende Teil 6 der ISO26262-2011 fordert im Kapitel 6 „Specification of software safety requirements“, die Erstellung einer Requirement Ebene. Im Kapitel 8 „Software unit design and implementation“, Tabelle 7 „Notations for software unit design“ wird als eine mögliche Methode auch die Erstellung von natürlich sprachlichen Requirements für die Beschreibung der Software Units vorgeschlagen. Als weitere Methoden können aber stattdessen auch „informal notations“, „semi-formale notations“ oder „formale notations“ gewählt werden.
Die ISO 26262 fordert also für die Software auf jeden Fall die Erstellung einer Ebene von Requirements. Eine zweite Ebene von textuellen Requirements kann erstellt werden, muss aber nicht.

DO 178B/C:

Der Luftfahrtstandard DO 178B/C definiert eindeutig zwei Requirement Ebenen (DO-178 Tabelle A2). Diese sind als High-Level Requirements und Low-Level Requirements mit eindeutigen Namen benannt. Dementsprechend hat sich in der Luftfahrtbranche das Erstellen von zwei Ebenen von Requirements (zumindest für die kritischeren Projekte (DAL A, B, C)) als nicht diskutierbarer Standard durchgesetzt.

Praxiserfahrungen und Fazit Requirement Ebenen:

Für ein DAL A, B oder C Projekt in der Luftfahrt haben Sie keine Wahl, es müssen zwei Ebenen von Software Requirements erstellt werden. Im Umkehrschluss ergibt sich für mich daraus aber auch die Feststellung, dass es für alle anderen Projekte (insbesondere in der Automobilindustrie und der Automatisierungstechnik) nicht zwingend notwendig ist, mit 2 Ebenen von textuellen Requirements zu arbeiten. Insbesondere bei Projekten, bei denen der Umfang und die Komplexität der Software begrenzt sind, sollte versucht werden, mit einer Ebene von Software Requirements auszukommen. Die jahrzehntelange Erfahrung in der Luftfahrt zeigt generell, dass die zweite Ebene von Requirements, die sogenannten Low-Level Requirements (Luftfahrt) bzw. Unit Design Requirements (Automotive) in sehr großen und komplexen Softwareprojekten durchaus ihre Berechtigung haben. Gleichzeitig muss aber auch kritisch festgestellt werden, dass es sehr kostenintensiv ist, solche Requirements zu erstellen. Die Erfahrung zeigt, dass es in vielen Projekten, in der Praxis sehr schwer ist, gute, textuelle Low-Level Requirements zu schreiben. Meist sind sie entweder zu detailliert, d.h. Pseudo-Code mit viel zu vielen, nicht notwendigen Details, oder sie sind zu abstrakt, sodass sie nicht testbar sind, obwohl sie eigentlich die unterste Ebene beschreiben sollen.
Meiner Erfahrung nach kommt man in vielen Projekten der Automobilindustrie und der Automatisierungstechnik gut mit einer Ebene von textuellen Requirements aus. Man sollte sich vielmehr darauf konzentrieren, gute, testbare, eindeutige und vollständige Requirements mit dieser einen Ebene zu erstellen, anstatt den Aufwand in oft technisch nicht begründete zwei Ebenen von Requirements zu stecken.
Es soll aber auch nicht unerwähnt bleiben, dass oft die Notwendigkeit der Ermittlung der strukturellen Code Coverage dazu führt, dass man meint man bräuchte mehrere Ebenen von Requirements. Richtig daran ist, dass dies für komplexe Projekte voll und ganz zutreffend ist. Genauso stimmt es aber auch, dass für mehr als 50% der Projekte die ich bisher gesehen habe, die Komplexität nicht so hoch war, dass das Argument der Code Coverage ausgereicht hätte, um eine zweite Ebene von Requirements zu definieren.

Weitere HEICON Blog Beiträge zum Thema:

• Requirement- und Test Traceability – Mit Köpfchen!

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