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.
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.
Chris Rupp und Klaus Pohl definieren Requirements in ihrem Buch „Requirements Engineering Fundamentals“ als Bedingung oder Fähigkeit mit unterschiedlichen Schwerpunkten:
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.
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.
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.
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.