Hält die SysML was sie verspricht?

Eine Anforderung gehört meist genau zu einem Prozessschritt, der sich in logischen Abhängigkeiten zu anderen Prozessschritten befindet. Um die Prozesse zu durchschauen und zu spezifizieren, eignen sich die Verhaltensdiagramme der UML oder SysML bestens. Dementsprechend macht es wesentlich mehr Sinn, die Anforderungen den Prozessschritten zuzuordnen, deren Verhalten sie genauer spezifizieren. Anforderungen, die sich nicht auf Prozesse beziehen, spezifizieren die Strukturen eines Systems detaillierter. Bei diesen Anforderungen ist deren Zusammenhang mit dem Strukturelement relevant. Hier empfiehlt sich die Modellierung der Strukturen in Form eines Strukturdiagramms (z.B. Klassendiagramms). Auch hier sollte die Anforderung genau dem Strukturelement zugeordnet werden, das es näher beschreibt. Die Beziehung zwischen Diagrammelement (egal ob aus einem Strukturdiagramm oder einem Verhaltensdiagramm) und der einzelnen Anforderung ist die wirklich relevante Information, die verwaltet werden muss. Diese Information wurde bisher in den meisten Projekten auch verwaltet – meist als Link oder als Referenz. Da eine Anforderung vor allem aus Text und einigen Verwaltungsinformationen (z.B. ID; Autor, Priorität, juristische Verbindlichkeit) besteht, werden hier meist Werkzeuge verwendet, die Text und Verwaltungsinformationen optimal handhaben konnten und Aspekte wie Mehrbenutzerfähigkeit, Sichtenbildung, Statusauswertungen optimal unterstützten.

Da die klare Referenzierung von Anforderungen auf Modellelemente auch bisher schon „state of the art“ war, bringt uns das Anforderungsdiagramm als Neuigkeit vor allem die Möglichkeit der grafischen Visualisierung von Anforderungen. Genau diese Funktionalität ist aber anhand der Anzahl an Anforderungen, die zu verwalten sind, meist sinnlos. Den einzigen Hoffnungsschimmer, den wir der Einführung dieses Diagramms abgewinnen können, ist, dass nun evtl. die Modellierungstoolhersteller Anforderungen ernster nehmen. Die meisten Modellierungstools besitzen schon heute entweder die Möglichkeit, textuelle Anforderungen und Attribute zu verwalten oder realisieren Schnittstellen zu Requirements Management Tools. Beide Spielarten sind für Projekte in der Industrie jedoch meist etwas zu wenig weit gedacht. Für einen Analytiker, der sich bisher mit Anforderungen in Word abkämpfte, ist es natürlich ein echter Fortschritt, nun die Abhängigkeiten zwischen Modell und Anforderungen halbwegs sauber innerhalb eines Modellierungstools verwalten zu können. Für einen Analytiker, der bisher mit einem gut angepassten Requirements Management Tool seine Anforderungen verwaltete, müssen die Toolhersteller noch einiges an ihren Produkten nachbessern.

Abb. 6: Einsatz natürlicher Sprache und Diagramme in der Systementwicklung
Nicht jeder Projektbeteiligte kommt mit Modellen zurecht

Der Weg, möglichst alles in ein grafisches Modell zu gießen, wird bei einigen Projektbeteiligten auf Widerstand stoßen. Natürliche Sprache hat nun mal den Vorteil, dass sie von den meisten Menschen verstanden wird, sie muss nicht erst gelernt werden. Auch wenn nicht so viel zu lernen ist, so kommt man ohne Vorwissen nicht mit den Diagrammen zurecht. Wenn wir uns vor Augen führen, wer alles als Projektbeteiligter zu integrieren ist (Manager, Fachbereichsmitarbeiter mit allen erdenklichen Qualifikationen – nur eben keiner Informatikvorbildung), dann ist klar, dass wir nicht alle auf eine Notationsschulung schicken können. Unserer Erfahrung nach kostet es schon einiges an Mühe, die Stakeholder an Use-Case-Diagramme und z.B. Aktivitätsdiagramme oder Zustandsautomaten zu gewöhnen. Mit diesen beiden Diagrammtechniken, eingebettet in Prosaanforderungen, die die zugehörigen Anforderungen beschreiben, ist das Entgegenkommen der Stakeholder meist erschöpft. Somit wird bei vielen Industrieprojekten Prosa auch weiterhin eine wichtige Rolle in Spezifikationen spielen.

Fazit

Wenn heute in der Systementwicklung Modelle mit ihren Diagrammen eingesetzt werden, dann existieren weiterhin parallel dazu natürlichsprachliche Anforderungen. Der Versuch, diese ebenfalls in Form eines Modells darzustellen, ist oft nicht sinnvoll, da an manchen Stellen Sprache einfach das geeignetere Darstellungsmedium ist. Für die Systementwicklung ist es wichtig, die Stärken der unterschiedlichen Dokumentationsformen zu kennen und jede Darstellungsart gezielt einzusetzen – dabei aber den Leser der Spezifikation nicht aus dem Auge zu verlieren. Modelle spielen und spielten dabei immer eine wichtige Rolle, egal, ob es sich hier um UML- oder SysML-Diagramme handelt. Dass es dabei wichtig ist, Verknüpfungsmöglichkeiten zwischen natürlicher Sprache und Modellen systematisch zu verwenden, ist schon seit Jahren bekannt und entscheidet häufig über den Projekterfolg. Dass die SysML nun eine neue Diagrammart mit Notationselementen anbietet, um all diese Verknüpfungen grafisch darzustellen, ist eine Neuerung, die aber auf Grund der hohen Anzahl an Anforderungen, die darzustellen wären, meist mehr Verwirrung stiftet als Klarheit bringt.

Carsten Pflug ist seit 2002 bei SOPHIST und weder ein Auslaufmodell noch ein Ladenhüter. Kaum war die UML 2 von der OMG verabschiedet, hat sich Carsten mit dem neuen Standard intensiv auseinandergesetzt und unterstützt so mit seinem aktuellem Know-how unsere Kunden beim Modellieren. Im Bereich des Requirements Engineerings und dem Requirements Management hat er in einigen Projekten bereits bewiesen, dass er sehr gut mit Anforderungen umzugehen weiß – und sich dabei zum DOORS-Insider gemausert. Kontakt: Carsten.Pflug[at]SOPHIST.de.

Chris Rupp liefert durch Ihre Publikationen und Vorträge immer wieder wichtige Impulse für die Bereiche Requirements Engineering und Objektorientierung. Erfindungen von Ihr und den SOPHISTen legten die Basis des modernen Requirements Engineering. Chris ist Geschäftsführerin der SOPHISTGROUP. Kontakt: Chris.Rupp[at]SOPHIST.de.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.