Spezifikation Architektur Requirement: Für immer mehr Systeme, gerade auch in der Industrieautomatisierung, müssen Forderungen der Funktionalen Sicherheit erfüllt werden. Für die Software Entwicklung ist dann in der Regel die Erfüllung der IEC61508 nachzuweisen.
Auf der anderen Seite stehen kommerzielle Anforderungen an das Produkt, welche das Entwicklungsbudget oft erheblich einschränken.
Die Lösung liegt dann in einem effizienten Entwicklungsprozess, der die sicherheits-relevanten Forderungen erfüllt. Eine Voraussetzung für eine erfolgreiche Umsetzung eines solchen Prozesses ist ein tiefgehendes Verständnis der Norm und eine klare Definition und gegenseitige Abgrenzung von Begriffen. Im nachfolgenden Blog beschäftige ich mich mit den drei Begriffen Spezifikation Architektur Requirement.

Spezifikation

Wikipedia definiert sie wie folgt:
„Eine Spezifikation (vom lateinischen specificatio für die „Auflistung“ oder das „Verzeichnis“) 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 bzw. Käufer geprüft und durch den Auftraggeber abgenommen werden kann. Die Spezifikation ist auch die Grundlage, nach der der Auftragnehmer oder Verkäufer die Bezahlung fordern kann, wenn die spezifizierten Anforderungen erfüllt wurden.“
Anmerkung: Im Allgemeinen, als auch in diesem Blog, werden die Begriffe „Anforderung“ und „Requirement“ als Synonyme verwendet.

Requirement

Chris Rupp und Klaus Pohl stellen in Ihrem Buch Requirements Engineering Fundamentals folgende, von mir ins Deutsche übersetzte Definition zur Verfügung:

1. Ein Requirement ist eine Bedingung oder Fähigkeit die von einem Benutzer benötigt wird um ein Problem zu lösen oder ein Ziel zu erreichen.
2. Ein Requirement ist eine Bedingung oder Fähigkeit die von einem System oder einer System-Komponente erfüllt werden muss um einen Vertrag, einen Standard, eine Spezifikation oder ein anderes formales Dokument zu erfüllen.
3. Ein Requirement ist eine dokumentierte Bedingung oder Fähigkeit gemäß 1. und 2.

Die Definition nach 1. definiert dass ein Requirement das „WAS“ eines Produktes oder Systems beschreibt. Solche Requirements, lassen sich sehr gut und sehr leicht in textueller Form in einer Datenbank dokumentieren.
Die Definition nach 2. und 3. beinhalten Verweise auf Dokumente. In diesem Fall hängt der Inhalt eines Requirements direkt vom Inhalt dieser Dokumente ab. Im Falle dass ein Vertrag, ein Standard oder eine Spezifikation die Architektur eines Produktes/Systems beschreibt, wird also auch die Architektur eines Produktes/System zum Requirement. Darüber hinaus werden mit 2. auch juristische Aspekte des Begriffes Requirement behandelt.

Architektur

Wikipedia verweist hier auf die Definition von Helmut Balzert. Dieser beschreibt den Begriff als „eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen“. Die Architekturkomponenten bilden eine Zerlegung des Gesamtsystems, was bedeutet, dass jedes Softwareelement genau einer Architekturkomponente zugeordnet ist.
In Abgrenzung zu der Definition von Requirements nach 1. beschreibt die Architektur eindeutig das „Wie“ eines Produktes/Systems.
Architekturen lassen sich in der Regel leicht in graphischer Form darstellen. Nur Randbedingungen oder Vor- und Nachbedingungen werden besser in Text dokumentieren.

IEC 61508-3

Die IEC61508-3 definiert im Anhang A Verfahren und Maßnahmen unter anderem für folgende Themengebiete:

• A.1 Spezifikation der Anforderungen an die Sicherheit der Software
• A.2 Softwareentwurf und Softwareentwicklung – Entwurf der Softwarearchitektur
• A.4 Softwareentwurf und Softwareentwicklung – Detaillierter Entwurf

Das die Verfahren und Maßnahmen für die Architektur in den Tabellen A.2 und A.4 beschrieben sind lässt sich relativ leicht zuordnen. Im Sinne einer effizienten Entwicklung ist für die Meisten Entwicklungen anzustreben, dass eine Softwarearchitektur erstellt wird. Diese enthält dann

• Einen Überblick über alle Systemkomponenten und deren Beziehung zueinander
• Alle Softwarekomponenten
• Die wichtigsten Daten- und Kontrollflüsse zwischen den Softwarekomponenten
• Eine Traceability zwischen den Softwarekomponenten und den Source Code Modulen

In diesem Fall können die Tabellen A.2 und A.4 mit einer konsistenten Architektur erfüllt werden. Eine „harte“ Trennung in Entwurf der Software Architektur und dem Detaillierten Entwurf ist in den meisten Fällen nicht zielführend und führt zu Dokumentationsaufwand der keinen Mehrwert für die Funktionale Sicherheit des Systems liefert.

Verfahren und Maßnahmen für Requirements definiert nach 1. sind in der IEC61508 nur sehr indirekt in Tabelle A.1 definiert. Textuelle Requirements kann man als Maßnahme nur anwenden wenn man die zu verwendenden Requirements Schablonen als Semiformale Methode festlegt. Im Sinne des effizienten Entwicklungsprozesses ist dieses Vorgehen sehr zu empfehlen.

Fazit

Eine Spezifikation definiert ein Dokument, welches sowohl Requirements als auch Architektur enthalten kann. Die IEC61508 „denkt“ aber nicht in Dokumenten und daher spielt dieser Begriff in der Norm keine Rolle.
Eine bewusste Unterscheidung zwischen Requirements definiert nach 1. und der Architektur ist aber im Sinne einer effizienten Entwicklung dringend zu empfehlen. Wenn man so vorgeht legt man automatisch fest, was getestet wird. Den nur Requirements definiert nach 1. sind direkt testbar. Eine Architektur ist letztlich nur über Reviews nachweisbar. Darüber hinaus ist für eine effiziente Entwicklung auch wichtig, dass mehrere Architekturen zum Einsatz kommen können, um eine in den Requirements definierte Problemstellung zu lösen. Software und Systemplattformen sind nur mit dieser bewussten Trennung erfolgreich einsetzbar.
Für den Kunden wiederum ist es entscheidend, dass das Produkt seine Problemstellung (definiert in den Requirements) löst und nicht wie das gemacht wird (Architektur).

Die Welt ist nun aber nicht schwarz oder weiß. Dieser Spruch gilt auch für dieses Thema. In den Projekten gibt es immer wieder konkrete Fälle in denen es sinnvoll ist, Architekturelemente in Requirements zu beschreiben. Ebenso gibt es Fälle in denen Requirements in der Architektur enthalten sind. Wichtig ist diese Sonderfälle als solche zu sehen und das oben Beschriebene im Sinne des Paretto-Prinzips (80/20 Regel) umzusetzen.

Weitere HEICON Blog Beiträge zum Thema

• Wieviel Requirement Ebenen braucht man in der FuSi
• Requirement Engineering – Aspekte die schon in der Theorie zu kurz kommen!
• Kategorien von Requirements – Warum sind sie sinnvoll?
• Guter Safety Software Entwicklungsprozess – Was ist das?

Wenn Sie weitere Fragen zum Thema haben, dann unterstützt Sie HEICON gerne. Senden Sie eine Mail an: info[at]heicon-ulm.de.