Wie Modellierung Anforderungen klarer und präziser macht

Der Wechsel von statischen Diagrammen zu ausführbaren Modellen im Requirements Engineering verbessert Präzision und Testbarkeit im Systementwurf. Anders als herkömmliche Diagramme können ausführbare Modelle das Systemverhalten simulieren, Anforderungen klären, Defekte aufdecken und das Verständnis der Stakeholder kommunizieren. Der itemis CREATE Player ermöglicht es, ausführbare Modelle direkt in das Requirements-Engineering-Tool Ihrer Wahl einzubetten – über eine URL zu einer unveränderlichen Modellversion.

Warum ausführbare Modelle?

Diagramme zu Anforderungsmengen hinzuzufügen ist im Requirements Engineering Stand der Technik, wie im INCOSE Guide to Writing Requirements nachzulesen ist. Allerdings hat die Verwendung von statischen, nicht ausführbaren Diagrammen erhebliche Nachteile. Diese Nachteile sind besonders relevant, wenn es um die Modellierung des Systemverhaltens geht, zum Beispiel mit Zustandsmaschinen.

Zustandsmaschinen können sehr nützlich sein, um die fehleranfällige Lücke zwischen Spezifikation und Implementierung zu überbrücken. Spezifikationen liegen häufig als eine Sammlung formaler oder informeller Anforderungen in natürlicher Sprache oder als Diagrammskizzen vor. Die Implementierung hingegen erfolgt in streng formalen Modellierungs- oder Programmiersprachen. Die Übersetzung von einem zum anderen kann schwierig sein, und Softwareprobleme entstehen häufig durch fehlende, unvollständige, widersprüchliche oder falsch interpretierte Anforderungen. Hier können Zustandsmaschinen als wertvolles Werkzeug dienen, um alle Beteiligten auf denselben Stand zu bringen.

Vorteile ausführbarer Modelle

Das Einbetten eines ausführbaren Modells anstelle eines Diagramms hat den Vorteil, dass das Modell simuliert werden kann – idealerweise direkt im Requirements-Management-Tool.

• Präzision und Testbarkeit: Ausführbare Modelle bieten eine klare, präzise und eindeutige Darstellung von Anforderungen und verringern die Wahrscheinlichkeit von Fehlinterpretationen. Sie können ausgeführt werden, um zu prüfen, ob das Systemverhalten mit den beabsichtigten Anforderungen übereinstimmt.
• Feedback-Schleifen: Da ausführbare Modelle getestet oder simuliert werden können, ermöglichen sie es den Stakeholdern, das Systemverhalten frühzeitig zu beobachten und schnelle Feedback-Schleifen zu erzeugen. Das hilft, Probleme früher im Entwicklungsprozess zu erkennen.
• Validierung & Verifikation: Formale Modelle ermöglichen automatisierte Prüfungen, wie Model Checking oder formale Verifikation, um zu bestätigen, dass Anforderungen logisch konsistent, erreichbar und korrekt im System implementiert sind.

Betrachten wir ein einfaches Beispiel: ein Lichtschaltersystem mit optionaler Bewegungserkennung. Die Anforderungen für ein solches System könnten wie folgt aussehen:

Anforderung 01: Das Lichtschaltersystem soll die 3 Zustände haben

• „Light Off"
• „Manual Mode"
• „Motion Detection Mode"

Anforderung 02: Im Zustand „Light Off" soll die Helligkeit des Lichts auf 0 gesetzt werden.

Anforderung 03: Das System soll vom Zustand „Light Off" in den Zustand „Manual Mode" wechseln, wenn die Taste „On" gedrückt wird.

Anforderung 04: Im Zustand „Manual Mode" soll die Helligkeit des Lichts zunächst auf 1 gesetzt und jedes Mal um 1 erhöht werden, wenn die Taste „On" gedrückt wird.

Anforderung 05: Das System soll vom Zustand „Manual Mode" in den Zustand „Motion Detection Mode" wechseln, wenn die Taste „Mot" gedrückt wird.

Anforderung 06: Im Zustand „Motion Detection Mode" soll die Helligkeit des Lichts auf 0 gesetzt werden, wenn keine Bewegung erkannt wird, und auf 3, wenn Bewegung erkannt wird.

Anforderung 07: Das System soll vom Zustand „Manual Mode" oder vom Zustand „Motion Detection Mode" in den Zustand „Light Off" wechseln, wenn die Taste „Off" gedrückt wird.

Das sind durchweg sinnvolle Anforderungen, die in folgende Skizze übersetzt oder durch sie begleitet werden könnten:

Erfahrene Ingenieure werden schnell bemerken, dass die Anforderungen nicht alle Details abdecken, die für eine robuste und benutzerfreundliche Implementierung notwendig wären. Aber lassen wir das beiseite und erstellen einen ausführbaren Statechart Player streng auf Basis der Spezifikation:

Dieses System sieht gut aus und die Anforderungen sind erfüllt. Jeder Zustand kann aktiviert werden und die Helligkeit wird wie spezifiziert gesetzt.

Aus Nutzersicht wird man beim Interagieren mit dem System jedoch feststellen, dass es nicht möglich ist, direkt in den „Motion Detection Mode" zu wechseln, da zunächst der „Manual Mode" aktiviert werden muss. Außerdem gibt es keinen direkten Übergang vom „Motion Detection Mode" in den „Manual Mode". Das könnte beabsichtigt sein, aber es macht durchaus Sinn zu überprüfen, ob die Spezifikation angepasst werden sollte.

Darüber hinaus ist das Verhalten des „Manual Mode" fraglich: Die Helligkeit kann bis zum Maximalwert der Variable „brightness" erhöht werden, was auch immer das sein mag. Es ist weder eine Begrenzung noch eine Bedingung spezifiziert, und es ist unklar, ob die Helligkeit danach wieder auf eins zurückspringen soll.

Betrachten wir den „Motion Detection Mode" weiter: Es ist offensichtlich keine Hysterese/Verzögerungszeit berücksichtigt. Je nach Definition der Schnittstellen „motion_detected" und „no_motion_detected" könnte das System zwischen den beiden Zuständen hin- und herschalten.

Und schließlich muss beim Aufsetzen einer Zustandsmaschine ein Eingangs- oder „Init"-Punkt definiert werden. Sehr wahrscheinlich soll der Ausgangszustand „Light Off" sein, aber das ist nicht spezifiziert und damit dem Softwareentwickler überlassen.

Das ist ein sehr einfaches Beispiel, aber es verdeutlicht eindrücklich die Vorteile, bereits in einem sehr frühen Stadium mit einem Systementwurf interagieren zu können.

Integration ausführbarer Zustandsmaschinen in Ihr Requirements-Engineering-Tool

itemis CREATE hat ein Feature namens Statechart Player integriert, das die öffentliche (oder private) gemeinsame Nutzung einer ausführbaren Version einer Zustandsmaschine ermöglicht – sogar die Integration in gängige Kollaborationstools wie IBM Doors, PTC Codebeamer, Atlassian Confluence oder Atlassian Jira. So kann das Systemverhalten problemlos mit Projektmitgliedern im Haus oder sogar über Unternehmensgrenzen hinweg geteilt werden.

Von Anforderungen zu ausführbaren Modellen

Ein Statechart Player ist schreibgeschützt, d. h. das angezeigte Modell kann nicht mehr verändert werden. Wenn das Modell geändert werden muss, muss dies außerhalb des Players erfolgen. Anschließend muss eine neue Version des Statechart Players erstellt werden, die eine andere URL erhält. Unveränderliche URLs haben den Vorteil, dass Baselines einer Anforderungsmenge bei ihrer Verwendung über die Zeit hinweg gültig bleiben, ohne dass das Modell gleichzeitig mit der Anforderungsmenge versioniert werden muss. Das gilt natürlich nicht nur für Anforderungsmengen, sondern für alle Artefakte, in denen Statechart-Player-URLs gespeichert sind.

In unserem Beispiel haben wir die Zustandsmaschine „von Hand" modelliert, den Statechart Player erstellt und die Player-URL als Link zur Anforderungsmenge hinzugefügt.

Je nachdem, wie die Anforderungen spezifiziert sind, gibt es verschiedene Möglichkeiten, die ausführbaren Modelle aus den Anforderungen abzuleiten. Wenn die Anforderungen in natürlicher Sprache spezifiziert sind, kann dies mithilfe von KI-Unterstützung erfolgen. Mehr zu diesem Thema können Sie auf LinkedIn nachlesen.

Toolchain Integration bei itemis — Modellierungswerkzeuge wie itemis CREATE nahtlos in Ihre bestehende Requirements-Engineering- und Entwicklungsumgebung integrieren: Toolchain Integration →