Einfach und iterativ Praxiserprobte Anforderungsmodellierung

Anforderungsmodellierung ist eine Technik, die in vielen Unternehmen nicht oder nur ansatzweise praktiziert wird. Dabei kann sie vergleichsweise einfach und iterativ eingeführt werden. Im Folgenden werden einige gängige Konzepte und konkrete Taktiken präsentiert, die bereits mit wenig Aufwand Ergebnisse bringen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Linutronix GmbH

Parasoft® Deutschland GmbH

Formal Mind GmbH

Modellierung zieht in die Entwicklung ein und wird in vielen Bereichen auch schon erfolgreich eingesetzt. Oft wird dabei an grafische Modellierungssprachen wie die UML gedacht, oder an Simulationen. Aber das Spektrum ist wesentlich größer, wie wir gleich sehen werden.

Auch Anforderungen können modelliert werden. Hierunter wird oft an Konstrukte wie Anwendungsfälle (Use Cases) gedacht, doch das ist nur einer von vielen Ansätzen, und auch die Modellierung von Anwendungsfällen kann unterschiedliche Ausprägungen annehmen.

Bildergalerie

Aber egal, wie modelliert wird: Modellierung darf nicht zum Selbstzweck werden, es muss einen klaren Nutzen geben. Ein Modell kann auf vielerlei Wegen einen Mehrwert bieten. Dazu gehören im Kontext des Systems Engineering unter anderem:

• Kommunizieren

• Dokumente generieren

• Sichten erstellen

• Testfälle generieren

• Code generieren

• Fortschritt verfolgen

• Vollständigkeit prüfen

• Informationen zusammenfassen

• Automatische Verifikation durchführen

• Auswirkungen von Änderungen verstehen

• Risiko bewerten

• Konflikte erkennen

• Inkonsistenzen erkennen

• Das Modell animieren (Simulation)

• Das Modell als Spezifikation nutzen

• Das Modell zur Strukturierung der Systembeschreibung nutzen

• Wissen verwalten

• Wiederverwendung ermöglichen

Diesen Möglichkeiten steht allerdings auch oft ein höherer Aufwand entgegen. Zum Beispiel erfordert eine Codegenerierung aus dem Modell einen erheblichen Aufwand, der nicht immer gerechtfertigt ist.

Was ist ein Modell?

Ein Modell ist eine Abstraktion der Realität für einen Zweck. Nur in den für den Zweck notwendigen Teilen muss das Modell genau genug sein. Zum Beispiel ist ein Holzmodell eines Schiffs geeignet, um die Anordnung der Komponenten zu prüfen (Zweck), auch wenn das Innere massives Holz ist. Ebenso kann eine mathematische Formel ein Modell sein, dass nur in Bezug auf Strömungswiderstand eine Bedeutung hat.

Die Unified Modeling Language (UML) ist eine grafische Modellierungssprache, die häufig für die Anforderungsmodellierung (und mehr) herangezogen wird. Die UML hat viele Modellelemente, die für die Anforderungsmodellierung eingesetzt werden können, wobei der Anwendungsfall (Use Case) wohl der bekannteste ist.

Aber Anforderungen können auch ohne UML modelliert werden. Auch die natürliche Sprache ist schon ein Modell, wenn auch keine sonderlich formale. Ohne einen gewissen Formalismus können die oben aufgeführten Vorteile der Modellierung kaum wahrgenommen werden.

Das andere Spektrum der Modellierung sind formale Modellierungssprachen, die auf einer soliden mathematischen Basis aufsetzen. dazu gehören Sprachen wie bspw. Event-B, in der manche Anforderungen mathematisch bewiesen werden können, also ohne Verifizierung auskommen.

Anforderungsmodellierung klassifizieren

Das zuvor Aufgeführte gesagte soll verdeutlichen, dass es neben UML noch viele andere Ansätze der Anforderungsmodellierung gibt. Diese werden im Folgenden vorgestellt. Danach schauen wir uns an, was bei der Einführung der Anforderungsmodellierung beachtet werden sollte.

Anforderungen können auf verschiedenen Ebenen modelliert werden:

Spezifikations-Ebene: Traditionell werden Anforderungen in Dokumenten strukturiert. Hier die Kapitelstruktur als Modellierung anzusehen ist vielleicht etwas zu hoch gegriffen. Aber der Übergang vom Dokumenten-basierten Arbeiten zum Element-basierten Arbeiten erfordert ein Datenmodell, in dem die Anforderungen typisiert werden, und die Beziehungen der Typen zueinander klar definiert werden. Dies kann in der Form einfacher Entity-Relationship-Diagramme visualisiert werden (siehe Bild 1)

Eine Anforderung selbst kann auch modelliert werden. Einer der einfachsten Ansätze hier ist der Einsatz von Satzschablonen, wie es bspw. auch von Standards vorgeschlagen wird. Der Standard IEEE 29148-2011 führt etwa einfache Beispiele von Satzschablonen auf.

Wenn mit einem Datenmodell gearbeitet wird, dann kann jeder Elementtyp auch weiter ausmodelliert werden, bspw. über unterschiedliche Sätze von Attributen. Auch hier ist der Begriff „Modelllierung“ eher hoch gegriffen. Wirklich um Modellierung handelt es sich jedoch, wenn semi-formale Sprachen wie UML oder formale Sprachen wie Event-B eingesetzt werden. Eine Anforderung für ein Ampelsystem könnte in Event-B wie in Bild 2 gezeigt aussehen.

Modellierungs-Tiefe: Bisher haben wir informell lediglich von Anforderungen gesprochen. Anforderungen tauchen jedoch auf unterschiedlichen Ebenen auf, also bspw. Nutzer-Anforderungen, System-Anforderungen, etc. Wenn bis zur untersten Ebene modelliert wird, dann ist es grundsätzlich möglich, ohne einen händischen Schritt die Umsetzung abzuleiten. In der Praxis ist dies eigentlich nur für Software möglich. Wir reden hier also von Codegenerierung aus dem Modell.

Zu den Sprachen, die Codegenerierung ermöglichen, gehören, Event-B, UML und SysML, um nur einige zu nennen.

Anforderungsmodellierung einführen

Die Idee, auf Knopfdruck aus einem Modell eine Implementierung zu generieren, ist verführerisch, aber gefährlich, denn Modellierung will gelernt sein. Teams, die ohne entsprechende Erfahrung versuchen, vom Dokumentenbasierten Arbeiten direkt zur Codegenerierung zu springen, werden mit großer Wahrscheinlichkeit scheitern. Daher werden im Folgenden lose aufeinander aufbauende Ansätze zur Anforderungsmodellierung vorgestellt. Meine Empfehlung, wenn Sie Anforderungsmodellierung einführen wollen: Finden Sie heraus, wo Sie sich in Ihrer Organisation befinden, und gehen Sie einen, maximal zwei Schritte weiter, aber nicht mehr.

Vernünftiges dokumentenbasiertes Arbeiten

Bevor wir überhaupt an Modellierung denken können, müssen wir vernünftig mit Anforderungen umgehen können. Die bereits zitierte IEEE 29148-2011 ist hier eine gute Grundlage. Der Standard erlaubt zwar durchaus modellbasiertes Arbeiten, kann aber auch ohne Probleme auf dokumentenbasiertes Arbeiten angewendet werden. Dort ist beschrieben, wie man vernünftige Anforderungen formuliert (bspw. mit Textschablonen), wie man das Anforderungsdokument strukturiert, und wie die verschiedenen Spezifiktionen/Dokumente zueinander in Beziehung stehen.

Datenmodelle

Wenn ein strukturierter Umgang mit Anforderungen gewährleistet ist, dann sollte mit einem Datenmodell gearbeitet werden, und nicht dokumentenbasiert. Datenmodelle im Anforderungsmanagement gibt es seit über 20 Jahren und sind längst etabliert – zumindest bei Entwicklungen, bei denen es um funktionale Sicherheit geht. Um mit Datenmodellen arbeiten zu können, werden vernünftige Werkzeuge benötigt, wie IBM Rational DOORS oder Jama Software.

Der Einsatz von einem Datenmodell ist in der Regel nicht aufwendig, da die bisherige (dokumentenbasierte) Arbeitsweise sich nur wenig ändern muss – zumindest, wenn die Werkzeuge gut sind. Aber der Nutzen ist immens. Oben wurde bereits ein einfaches Datenmodell gezeigt. Ein solches Modell kann bspw. sicherstellen, dass jedes Epic durch mindestens einen Test abgedeckt ist. Auch der Umgang mit Änderungen wird sicherer. Wenn sich ein Epic ändert, sollte das Werkzeug sicherstellen, dass alle davon abgeleiteten Testfälle auf Korrektheit überprüft werden.

Einführung einer Modellierungssprache

Während das eben beschriebene Datenmodell in der Regel vollständig angepasst wird, so werden bei einer (semi-)formallen Modellierungssprache fest vorgegebene Elemente benutzt. In der UML wird dann bspw. mit Klassen und Anwendungsfällen gearbeitet. Das hat den Vorteil, dass man auf vielen Jahren „Best Practices“ aufsetzen kann. Es bedeutet aber auch, dass es viele Sprachfeatures gibt, die man nicht unbedingt braucht. Und es verführt, in eine Tiefe zu gehen, mit der man unter Umständen noch nicht umgehen kann.

Daher ist es wichtig, bei der Einführung die Sprachelemente, die benutzt werden, stark einzuschränken, und die Sprache (bzw. das Werkzeug) so gut wie es geht anzupassen, um die Nutzer zu führen. Weiterhin ist es wichtig, die Nutzer ausreichend zu schulen.

Bei den Schulungen ist es hilfreich, zwischen Autoren und Lesern zu unterscheiden. In der Praxis erstellt nur ein kleiner Teil der Nutzer die Modelle, wesentlich mehr Menschen müssen diese jedoch lesen können. Durch das Anbieten von zwei Schulungen für diese zwei Gruppen werden zum einen Kosten gespart, zum anderen Nutzer nicht durch zu viel – oder zu wenig – Schulung frustriert.

Und zuletzt ein ganz wichtiger Punkt: Bei der ersten Einführung sollte nicht tiefer als notwendig modelliert werden. Hierzu ein Beispiel aus der Praxis. Bei einem Projekt für einen Logistikdienstleister wurde zum ersten Mal UML eingesetzt. Dazu wurden lediglich die Modellelemente „Klasse“ und „Anwendungsfall“ eingesetzt. Aber noch wichtiger: Ab einer bestimmten Tiefe wurden die Formalismen der UML ignoriert und natürliche Sprache eingesetzt (siehe Bild 3). Das Team erntete damit zwar den Spott von manchem UML-Experten, aber die Akzeptanz war hoch, da alle Stakeholder innerhalb von kurzer Zeit in der Lage waren, die generierten Dokumente zu verstehen.

Formalisierung

Mit so einer Basis kann die Formalität des Anforderungsmodells schrittweise erhöht werden. Dabei ist empfehlenswert, sich, soweit möglich, an bekannte und gut dokumentierte Ansätze zu halten. So ist bspw. der ICONIX-Prozess ein gutes Stück formeller als der eben beschriebene, kommt aber trotzdem mit nur vier UML-Diagrammen aus.

Ein weiterer empfehlenswerter Ansatz des schrittweisen Ausbaus ist der Einsatz von Modellierung in bestimmten Teilbereichen. Zum Beispiel werden im Eisenbahnbereich formale Sprachen wie Event-B, Z oder VDM eingesetzt, allerdings nie in der vollen Breite, sondern für bestimmte Teile des Systems, bei denen funktionale Sicherheit eine besonders große Rolle spielt.

Sinnvoller Einsatz von Anforderungsmodellen

Es gibt allerdings viele verschiedene Ansätze, von einfachen Informationsmodellen bis zu formalen Sprachen wie VDM oder B. Aber egal, was eingesetzt wird: Modellierung muss einen Sinn haben. Daher müssen der Nutzen der Modellierung und die Kosten abgewogen werden. Am besten geschieht dies über eine schrittweise Einführung.

Richtig eingesetzt kann die Anforderungsmodellierung jedoch einen enormen Mehrwert bieten, da Redundanzen verschwinden und der Umgang mit Änderungen sich drastisch verbessert, um nur einige der Vorteile zu erwähnen. Und gerade der Umgang mit Änderungen ist einer der großen Vorteile, der in unserer schnelllebigen Zeit geschätzt wird.

Modellierung reaktiver Systeme mit der UML-Erweiterung CIRO

Grundlagen des Modellbasierten System-Engineering (MBSE)

UML

Modellbasiertes Vorgehen bei Echtzeitanforderungen

Dieser Beitrag stammt aus dem Kongressband des ESE-Kongess 2017.

Der Autor

* Dr. Michael Jastram ist Systems Engineer mit Schwerpunkt auf die Anforderungsmodellierung. Er ist Gründer und Projekt Lead des Eclipse Requirements Modeling Frameworks, einem Open Source-Projekt zur Anforderungsmodellierung, das als Referenzimplementierung den offenen ReqIF-Standard umsetzt. Als Advokat für Offenheit teilt er sein Wissen über Bücher, Fachartikel, Vorträge und als Veranstalter, sowie über seinen wöchentlichen deutschsprachigen Blog System Engineering Trends und den englischsprachigen Formal Mind Blog.

(ID:45626118)