Für immer mehr Systeme müssen Forderungen der Funktionalen Sicherheit erfüllt werden. Für die Software-Entwicklung ist dann in der Regel die Erfüllung der IEC 61508 „Funktionale Sicherheit sicherheitsbezogener elektischer/elektronischer/programmierbarer elektronischer Systeme“ nachzuweisen – insbesondere in der Automobilbranche.
Auf der anderen Seite stehen kommerzielle Anforderungen an das Produkt, welche das Entwicklungsbudget oft erheblich einschränken.
Die Lösung liegt in einem effizienten Entwicklungsprozess, der die sicherheitsrelevanten Forderungen erfüllt und über eine lückenlose Traceability nachgewiesen werden kann. Eine Voraussetzung für die erfolgreiche Umsetzung eines solchen Prozesses ist ein tiefgehendes Verständnis dieser Norm und eine klare Definition und Abgrenzung der spezifischen Begriffe. Schauen wir uns im Folgenden also die drei Begriffe „Spezifikation“, „Architektur“ und „Requirements“ an.
Spezifikation
Wikipedia definiert sie wie folgt:
Eine Spezifikation […] ist die Beschreibung eines Produktes, eines Systems oder einer Dienstleistung durch Auflistung seiner Anforderungen. Ziel der Spezifikation ist es, Anforderungen zu definieren und, falls möglich, zu quantifizieren […] mit denen das Werk oder die Dienstleistung des Auftragnehmers bei der Übergabe an den Auftraggeber […] geprüft und […] abgenommen werden kann.
Eine Spezifikation ist demzufolge die Sammlung aller messbaren Anforderungen (oder Requirements) an ein Produkt oder eine Dienstleistung.
Requirement
Chris Rupp und Klaus Pohl definieren Requirements in ihrem Buch „Requirements Engineering Fundamentals“ als Bedingung oder Fähigkeit mit unterschiedlichen Schwerpunkten:
- als eine Bedingung, die von einem Benutzer benötigt wird, um ein Problem zu lösen oder ein Ziel zu erreichen – also als das WAS eines Produktes, das sich sehr einfach in textueller Form dokumentieren lässt.
- als eine Bedingung, die von einem System erfüllt werden muss, um beispielsweise einen Standard, eine Spezifikation oder ein anderes Dokument zu erfüllen. Dies behandelt auch juristische Aspekte.
- als eine dokumentierte Bedingung gemäß Punkt 1 oder 2.
Im Gegensatz zu Punkt 1 beinhalten die Definitionen aus Punkt 2 und 3 Verweise auf Dokumente – der Inhalt des Requirements hängt direkt vom Inhalt dieser Dokumente ab. Beschreibt ein Standard oder eine Spezifikation also die Architektur einer Produktes oder Systems, wird auch die Architektur selbst zum Requirement.
Architektur
Wikipedia verweist hier auf die Definition von Helmut Balzert. Ihm zufolge beschreibt der Begriff Architektur „eine strukturierte und hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Jedes Software-Element kann dabei genau einer Architekturkomponente zugeordnet werden.
In Abgrenzung zu der Definition von Requirements beschreibt die Architektur eindeutig das WIE eines Systems. Sie lassen sich in der Regel leicht graphisch darstellen.
Spezifikation, Requirements, Architektur: Das sind die Unterschiede und Zusammenhänge
Vereinfacht gesagt definiert eine Spezifikation ein Dokument, das sowohl Requirements als auch Architektur enthalten kann. Es gibt auch immer wieder Fälle, in denen es sinnvoll ist, Architekturelemente in Requirements zu beschreiben. Mitunter sind Requirements andersherum auch in der Architektur enthalten. Dies sollten allerdings Sonderfälle bleiben, denn für eine effiziente Entwicklung ist es sinnvoll, Requirements und Architektur bewusst zu unterscheiden.
Eine solch bewusste Unterscheidung stellt eine toolgestützte Traceability natürlich vor Herausforderungen: Beispielsweise werden Architekturen in der Regel durch grafische Tools dargestellt, während sich textuelle Requirements am Besten in Datenbank verwalten lassen. Um eine lückenlose Traceability zu ermöglichen, muss das genutzte Tool entsprechend toolübergreifend arbeiten können. Eine mögliche Lösung ist beispielsweise YAKINDU Traceability.
Mehr zum Thema "Funktionale Sicherheit"
Im Whitepaper "Einbindung der funktionalen Sicherheit in den Entwicklungsprozess eingebetteter Systeme" von itemis-Mitarbeiter Helko Glathe und Richard Pohl erfahren Sie mehr zu diesem Thema. Laden Sie es sich hier direkt kostenlos herunter.
Dies ist ein Gastbeitrag aus dem HEICON-Blog von Martin Heininger.
Kommentare