Wettstreit der Notationen Teil 4

Folge 4: Vereinigung der Notationen in der Analyse

Problem – Die friedliche Koexistenz

Lassen Sie uns einmal zusammenfassen, was wir bisher haben. Zum einen haben wir, methodisch betrachtet, zwei sich wunderbar ergänzende Ansätze zur Repräsentation von Anforderungen: die modellbasierte und die textbasierte Repräsentation (siehe Folge 2 „Malen oder schreiben“). Zum anderen haben wir auf der Toolseite leider zwei sich eher schlecht ergänzende Werkzeugarten zur Dokumentation und Verwaltung der Anforderungen (siehe Folge 3 „Tools – Fluch oder Segen?“).

Das Resultat aus dieser Situation? Oft genug existieren Anforderungsmodelle und natürlichsprachliche Anforderungen in einem Projekt, da verschiedene Personen bzw. Personengruppen mit verschiedenen Repräsentationen arbeiten. Aufgrund der Tool-Lücke existieren diese aber ohne Verbindung zueinander.

Warum das schlecht ist? Hier mal einige Argumente, die mir spontan einfallen:

  • Redundanzen: Anstatt sich zu ergänzen, werden Inhalte doppelt dokumentiert.
  • Inkonsistenzen: Die verschiedenen Repräsentationen laufen inhaltlich auseinander (z. B. werden Änderungen gerne nur an einer Stelle durchgeführt).
  • Fehlende Nachvollziehbarkeit: Ohne Verbindung lässt sich schwer nachvollziehen, wie die Repräsentationen ineinander greifen. Das Wissen über Zusammenhänge steckt nur in den Köpfen oft einiger weniger Personen und ist nicht nachvollziehbar für Reviewer, Wartung, Folgeprojekte, Change Management etc.
  • Mehr Aufwand für Folgeprozesse: Falls z. B. Entwickler das Modell  und die Tester die natürlichsprachlichen Anforderungen als Input nehmen, entsteht ein hoher Aufwand für das Mapping der Tests auf die entwickelten Systemteile/Systemfunktionen.
  • Lagerbildung im Team: Oft kommt es zu einer Spaltung im Team und anstelle des WIR heißt es dann die „Modellierer“ und die „Schreiber“. Eine Verbindung veranlasst jeden sich auch mit der Arbeit der anderen Teammitglieder zu beschäftigen.

Lösungsansätze – Kooperation statt Koexistenz!

Zwei grundlegende Möglichkeiten das Problem der „Toollücke“ zu beheben:

  • Integration der Modelle in das RM-Tool (Requirements-Management-Tool)
  • Integration der natürlichsprachlichen Anforderungen in das Modellierungs-Tool

Die Möglichkeit beide Repräsentationen in einem dritten Tool zu kombinieren, lasse ich hier einmal unbetrachtet, denn erstens käme hierdurch noch ein weiterer Toolbruch hinzu und zweitens habe ich noch keine solche Lösung in der Praxis gesehen.

Betrachten wir zunächst die Integration der Modelle in das RM-Tool. Idealerweise beginnt dies damit, dass die textuellen Anforderungen anhand der Modelle strukturiert werden. Dies schafft eine indirekte Verbindung und eine gemeinsame Basis. Die „Schreiber“ erkennen den Aufbau des Modells wieder und die „Modellierer“ finden sich in den Anforderungen zurecht. Weitere Informationen zu diesem Ansatz finden sie unter dem Stichwort STABLE in unserem Blog. Der explizite Verweis einer Anforderung oder eines Abschnitts auf ein Modellelement kann über folgende Wege geschehen:

  • Referenzierung des Modellelemente-Namens bei der Anforderung (z. B. in einem Attribut)
  • Referenzierung einer eindeutigen ID bei der Anforderung (z. B. in einem Attribut)
  • Import des Modells, so dass jedes Modellelement einem Objekt im RM-Tool entspricht und Verlinkung der Anforderung mit dem zugehörigen Modell-Objekt im RM-Tool

Der letzte Weg ist zwar sehr gut, da er in beide Richtungen nachvollziehbar ist (von den Anforderungen auf die Modell-Objekte und von den Modell-Objekten auf die Anforderungen). Aufgrund des hohen Aufwandes für den Import und die Pflege der Modell-Objekte, ist er jedoch nur mit einer Automatisierung des Imports praktikabel.

Nun zu unserer zweiten Möglichkeit: der Integration der natürlichsprachlichen Anforderungen in das Modellierungs-Tool. Die Anforderungen werden entweder per Hand oder über einen Import-Mechanismus in Modellelemente überführt. Seit der SysML, mit der ein Requirements Diagramm eingeführt wurde, haben wir hierfür auch ein passendes Notationselement. Diese Anforderungs-Modellelemente können dann mit den entsprechenden Modellelementen verbunden werden (z. B. über eine Dependency-Beziehung mit dem Stereotypen „trace“).

Ein Nachteil der zweiten Methode ist, dass Modellierungstools die Anforderungen nur in einer flachen Liste importieren und auch keine Möglichkeiten zur Filterung oder Sortierung bieten wie RM-Tools. Bei einigen hundert Anforderungen verliert man dann schnell den Überblick. Hier sollte vor dem Import ein wenig Denkarbeit stattfinden, um die Anforderungen z.B. anhand ihrer Kapitel in der Spezifikation oder anhand ihres Types zu paketieren und im Modell in einer Ordnerstruktur oder in verschiedenen Diagrammen abzulegen.

Die beiden heute vorgestellten Wege die Tool-Lücke zu überbrücken, sind natürlich nur Behilfsmittel, der Import und Export geht häufig nur recht umständlich über csv-Dateien und ist alles andere als komfortabel. Unserer Meinung nach werden bald integrierte Lösungen entstehen mit einer echten Schnittstelle…aber bis dahin muss sich die Projekt-Welt schließlich weiter drehen :).

Wie immer sind Sie herzlich eingeladen uns Ihre Erfahrungen und Anmerkungen zu diesem Thema mitzuteilen. Wir freuen uns über jeden sachdienlichen Hinweis! Schreiben Sie uns einfach an heureka@sophist.de

Schreibe einen Kommentar Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert