Willi Mako
// PROTOCOL:

CONTRL-Regeln: Verbindlichkeit & Anwendung einfach erklärt

ID#D20-1A
STATUSREAD_ONLY
AUTHORSYS_ADMIN
TAGS [PROZESS]

Informationen zur Verbindlichkeit und Anwendung der Regeln im Kontext der CONTRL

1. Abgrenzung zu anderen Richtlinien und Handbüchern

Die in diesem Kapitel dargelegten Regeln unterscheiden sich von anderen Richtlinien oder Handbüchern durch ihren spezifischen Bezug zur CONTRL (Controlled Natural Language for Requirements and Logic) sowie durch ihre doppelte Verankerung in zwei zentralen Dokumenten:

  • Allgemeingültige Regeln mit CONTRL-Fokus: Die hier beschriebenen Vorgaben sind nicht als isolierte Empfehlungen zu verstehen, sondern als integraler Bestandteil der CONTRL-Syntax und -Semantik. Während andere Richtlinien (z. B. allgemeine Sprachstandards für technische Dokumentation oder branchenspezifische Normen wie ISO/IEC 29148 für Anforderungsdokumente) oft breiter gefasst sind, konzentrieren sich diese Regeln auf die präzise Formulierung von Anforderungen und logischen Aussagen in der CONTRL. Sie definieren beispielsweise:

    • Strukturvorgaben (z. B. Satzbau, Schlüsselwörter wie "shall", "must", "if-then"),
    • Semantische Einschränkungen (z. B. Vermeidung von Mehrdeutigkeiten, Definition von Operatoren),
    • Konsistenzregeln (z. B. Referenzierung von Begriffen, Vermeidung von Widersprüchen).
  • Identität mit dem CONTRL-Anwendungshandbuch: Die wörtliche Übereinstimmung mit dem gleichnamigen Kapitel im CONTRL-Anwendungshandbuch unterstreicht die normative Funktion dieser Regeln. Im Gegensatz zu rein informativen Leitfäden (z. B. Best-Practice-Dokumenten) oder unternehmensinternen Styleguides handelt es sich hier um verbindliche Vorgaben, die direkt aus der CONTRL-Spezifikation abgeleitet sind. Andere Handbücher (z. B. für UML oder SysML) behandeln zwar ähnliche Themen, nutzen jedoch andere Notationen und Logikstrukturen.

  • Zielgruppe und Anwendungsbereich: Während allgemeine Richtlinien oft für ein breites Publikum (z. B. Entwickler, Projektmanager) formuliert sind, richten sich diese Regeln primär an Autoren von Anforderungen (z. B. Systemingenieure, Sicherheitsanalysten) und Werkzeugentwickler, die CONTRL in modellbasierten Entwicklungsprozessen einsetzen. Sie sind nicht als Ersatz, sondern als Ergänzung zu anderen Standards zu verstehen – etwa wenn CONTRL als formale Sprache für die Spezifikation von Sicherheitsanforderungen (z. B. nach ISO 26262) genutzt wird.


2. Verbindlichkeit der Regeln in Anwendungsszenarien der CONTRL

Die Regeln sind nicht universell verbindlich, sondern nur in spezifischen Kontexten, in denen CONTRL als formale oder semi-formale Sprache eingesetzt wird. Die Verbindlichkeit ergibt sich aus:

a) Vertragliche oder normative Vorgaben

Die Regeln sind verbindlich, wenn:

  • CONTRL explizit als Sprache für Anforderungen vereinbart wurde (z. B. in Verträgen, Lastenheften oder Entwicklungsrichtlinien). Beispiel: Ein Automobilhersteller schreibt vor, dass Sicherheitsanforderungen für ein Steuergerät in CONTRL zu formulieren sind. Hier müssen die Regeln dieses Kapitels eingehalten werden, um die Nachvollziehbarkeit und maschinelle Verarbeitbarkeit der Anforderungen zu gewährleisten.
  • Branchenstandards die Nutzung von CONTRL vorschreiben oder empfehlen. Beispiel: In der Luftfahrt (DO-178C) oder Medizintechnik (IEC 62304) kann CONTRL als Methode zur formalen Spezifikation eingesetzt werden. Die Regeln dienen dann als Grundlage für die Zertifizierung von Systemen.

b) Werkzeuggestützte Anwendung

Die Regeln sind technisch verbindlich, wenn CONTRL in Software-Tools (z. B. Anforderungsmanagement-Systeme, Modellierungswerkzeuge) implementiert ist:

  • Parser und Validierungstools nutzen die Regeln, um Anforderungen auf Syntaxfehler, Mehrdeutigkeiten oder logische Widersprüche zu prüfen. Beispiel: Ein Tool wie ReqIF oder ein CONTRL-spezifischer Editor markiert Abweichungen von den Regeln (z. B. fehlende Schlüsselwörter) als Fehler und verhindert die Weiterverarbeitung.
  • Automatisierte Analysen (z. B. Konsistenzprüfungen, Traceability) setzen die Einhaltung der Regeln voraus. Beispiel: Bei der Generierung von Testfällen aus CONTRL-Anforderungen müssen die Regeln befolgt werden, um korrekte und vollständige Testabdeckung zu gewährleisten.

c) Modellbasierte Systementwicklung (MBSE)

In modellgetriebenen Entwicklungsprozessen (z. B. nach SysML oder AUTOSAR) sind die Regeln verbindlich, wenn:

  • CONTRL zur Formalisierung von Anforderungen genutzt wird, die in Modelle (z. B. Zustandsdiagramme, Aktivitätsdiagramme) überführt werden. Beispiel: Eine Anforderung wie "If the system detects a failure, then it shall enter safe state within 100 ms" muss in CONTRL exakt nach den Regeln formuliert sein, um in ein verifizierbares Modell umgewandelt werden zu können.
  • Sicherheitskritische Systeme (z. B. nach ISO 26262 ASIL D) erfordern eine eindeutige und nachweisbare Spezifikation. Hier sind Abweichungen von den Regeln nicht tolerierbar, da sie zu Fehlinterpretationen führen könnten.

d) Rechtliche und regulatorische Kontexte

In hochregulierten Branchen (z. B. Luftfahrt, Eisenbahn, Kerntechnik) können die Regeln indirekt verbindlich werden, wenn:

  • Aufsichtsbehörden (z. B. EASA, FDA) die Nutzung formaler Sprachen wie CONTRL für die Dokumentation von Sicherheitsanforderungen fordern. Beispiel: Bei der Zulassung eines Flugzeugsystems muss nachgewiesen werden, dass alle Anforderungen eindeutig, widerspruchsfrei und vollständig sind. CONTRL mit seinen Regeln dient hier als Nachweisinstrument.
  • Haftungsfragen im Schadensfall eine Rolle spielen. Gerichte oder Gutachter können die Einhaltung der Regeln prüfen, um festzustellen, ob Anforderungen korrekt spezifiziert wurden.

3. Nicht-verbindliche Anwendungsszenarien

Die Regeln sind nicht verbindlich, wenn:

  • CONTRL nur als informelle Notation genutzt wird (z. B. als Vorlage für natürlichsprachliche Anforderungen ohne Tool-Unterstützung).
  • Andere Sprachen oder Methoden (z. B. UML, natürliche Sprache) für die Spezifikation verwendet werden.
  • Die Regeln explizit durch projektspezifische Anpassungen ersetzt oder ergänzt werden (z. B. durch unternehmensinterne Styleguides).

4. Zusammenfassung der Verbindlichkeit

Anwendungsszenario Verbindlichkeit der Regeln Begründung
Vertraglich vereinbarte CONTRL-Nutzung Hoch Einhaltung ist Voraussetzung für die Erfüllung von Lieferverpflichtungen.
Werkzeuggestützte CONTRL-Anwendung Hoch Tools erzwingen die Regeln durch Syntaxprüfung und Validierung.
Modellbasierte Entwicklung (MBSE) Hoch Formale Anforderungen müssen in Modelle überführbar sein.
Sicherheitskritische Systeme Sehr hoch Regulatorische Vorgaben erfordern nachweisbare Eindeutigkeit.
Informelle Nutzung Niedrig Keine technische oder rechtliche Durchsetzung.

Hinweis: Die Regeln sind kein Selbstzweck, sondern dienen der Qualitätssicherung in Entwicklungsprozessen. Ihre Verbindlichkeit leitet sich stets aus dem konkreten Anwendungsfall und den damit verbundenen Anforderungen (z. B. Zertifizierung, Tool-Integration) ab. Bei Unsicherheiten ist eine Abstimmung mit den beteiligten Stakeholdern (z. B. Auftraggeber, Tool-Hersteller, Zertifizierungsstellen) erforderlich.