Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Oft falsch verstanden: Modellierung von Anforderungen

Egal ob agil oder V-Modell - ein Treiber für Effektivität

Autor: Dr. Michael Jastram, Formal Mind

Beitrag - Embedded Software Engineering Kongress 2017

 

Anforderungsmodellierung ist eine Technik, die in vielen Unternehmen nicht oder nur ansatzweise praktiziert wird, und die vergleichsweise einfach und iterativ eingeführt werden kann. Da der Kosten- und Zeitdruck in vielen Unternehmen enorm ist, befinden sich hier "low hanging fruit", mit denen die Entwicklung effektiver gestaltet werden kann. Da es viele unterschiedliche Ansätze gibt, werden hier sowohl die Konzepte vermittelt, die einem helfen, was in die eigene Arbeit passt, als auch konkrete Taktiken, die mit wenig Aufwand Ergebnisse bringen.

Motivation

Modellierung zieht in die Entwicklung ein und wird in vielen Bereichen auch schon erfolgreich eingesetzt. Oft wird dabei an grafische Modellierungssprachen wie die UML oder an Simulationen gedacht. 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 ein Ansatz von vielen, und auch die Modellierung von Anwendungsfällen kann unterschiedliche Ausprägungen annehmen.

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 [SET18]:

  • 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, das 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 z.B. Event-B (EB), in der manche Anforderungen mathematisch bewiesen werden können, also ohne Verifizierung auskommen.

Anforderungsmodellierung klassifizieren

Das eben 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:

Spezifikationsebene:
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 und die Beziehungen der Typen zueinander klar definiert werden. Dies kann in der Form einfacher Entity-Relationship-Diagramme (siehe dazugehörige Abbildung, PDF) visualisiert werden.

Anforderungsebene:
Eine Anforderung selbst kann auch modelliert werden. Einer der einfachsten Ansätze hier ist der Einsatz von Satzschablonen, wie es z.B. auch von Standards vorgeschlagen wird (29148). Wenn mit einem Datenmodell gearbeitet wird, dann kann jeder Elementtyp auch weiter ausmodelliert werden, z.B. über unterschiedliche Sätze von Attributen. Auch hier ist der Begriff "Modelllierung" eher hoch gegriffen. Wirklich um Modellierung handelt es sich jedoch, wenn semiformale Sprachen wie UML oder formale Sprachen wie Event-B eingesetzt werden. Eine Anforderung für ein Ampelsystem könnte in Event-B folgendermaßen aussehen (RH; siehe dazugehörige Abbildung, PDF).

Modellierungstiefe:
Bisher haben wir informell lediglich von Anforderungen gesprochen. Anforderungen tauchen jedoch auf unterschiedlichen Ebenen auf, also z.B. 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 (29148) 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 (z.B. 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 eines Datenmodells 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 z.B. 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)formalen Modellierungssprache fest vorgegebene Elemente benutzt. In der UML wird dann z.B. 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 möglich 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 werden 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 (IREB). 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 dazugehörige Abbildung, PDF).

Das Team erntete damit zwar den Spott von manchem UML-Experten, aber die Akzeptanz war hoch, da alle Stakeholder innerhalb 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. Z.B. ist der ICONX-Prozess (ICONIX) 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.

Fazit

Es gibt 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.

Literatur und Quellen

[29148] Der Standard IEEE 29148-2011 führt einfache Beispiele von Satzschablonen auf.

[ICONIX] http://se-trends.de/iconix-methode/

[IREB] http://re-magazine.ireb.org/issues/03-an-eye-for-detail/modeling-requirements-with-constraints

[SET18] Michael Jastram: "18 Dinge, die Sie mit Systemmodellen machen können"

[RH] Michael Jastram (Editor): Rodin Handbook

[UML] http://www.omg.org/spec/UML/

 

Beitrag als PDF downloaden

Modellierung - MicroConsult Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.

Modellierung - Fachwissen

Wertvolles Fachwissen zum Thema Modellierung /Embedded- und Echtzeit-Softwareentwicklung steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.