Wettstreit der Notationen Teil 5

Folge 5: Analyse trifft Design

Nachvollziehbarkeit zwischen Anforderungen und Designmodell

In der letzen Folge „Vereinigung der Notationen in der Analyse“ haben wir uns angesehen, wie wir natürlichsprachige Anforderungen und UML-Anforderungsmodelle miteinander verbinden können.
Heute wollen wir uns ansehen, mit welchen Mitteln wir Anforderungen (sowohl grafische als auch textuelle) mit dem Architekturmodell verbinden können.

Wir wollen also die in der Analyse gefundenen Anforderungen auf die Komponenten in der Architektur verteilen und so die Aufgaben der einzelnen Komponenten beschreiben. Dies ist ein wichtiger Schritt, der allzu oft übergangen wird. Viele Analyseergebnisse werden einfach unbeachtet auf die Seite gelegt und im weiteren Entwicklungsverlauf nicht weiterverwendet.

In manchen Bereichen (z. B. Medizintechnik oder Luftfahrt) erzwingen Vorschriften und Gesetze diese Traceability zwischen Anforderungen und der Architektur, es gibt aber auch viele weitere Gründe dafür:

  • Nachweisbarkeit: Wurden alle Anforderungen bei der Realisierung berücksichtigt?
  • Identifikation von Goldrandlösungen im System: Welche Funktionen im System waren evtl. gar nicht gefordert?
  • Auswirkungsanalyse (auch „Impact-Analyse“): Welche Auswirkungen hat die Änderung von Ziel 08/15 auf Anforderung 4711? Man denke an den Schmetterlingseffekt!
  • Wiederverwendung: Welche Anforderungen oder Komponenten können in andere Projekte übernommen werden?
  • Zurechenbarkeit: Wieviel Aufwand ist in die Realisierung eines Zieles, eines Use-Cases oder einer einzelnen Anforderung geflossen?
  • Wartung und Pflege: Ursachenforschung, Aufwandsabschätzung für Fehlerbehebungen etc.

Wie können wir die Verbindung zwischen Anforderungen und dem Architekturmodell nun in der Praxis herstellen? Im Grunde genauso wie wir in der letzten Folge die Verbindung zwischen Modell und natürlichsprachigen Anforderungen erstellt haben. Entweder im RM-Tool oder im Modellierungstool.

Im RM-Tool fügen wir den Verweis auf das Architekturelement falls möglich als Attribut oder als einfache textuelle Referenz ein. Die Referenz sollte eine Eindeutige ID beinhalten, da sich der Name der Architekturelemente ändern könnte und es dann wieder zu Inkonsistenzen kommt. Eine weitere Möglichkeit ist der Import des Architekturmodelles in das RM-Tool, so dass jede Komponente einem Objekt im RM-Tool entspricht und mit den Anforderungsobjekten über Links verbunden werden kann.

Im Modellierungs-Tool können wir über die Abhängigkeitsbeziehung mit einem entsprechenden Stereotypen darstellen, welche der Anforderungen eine Komponente realisiert.

Zum Abschluss dieser Folge noch ein Hinweis: Wichtig ist, dass die Verbindungen im Vorfeld geplant und nicht einfach kreuz und quer eingefügt werden. Zusätzlich gibt es beispielsweise auch noch Testfälle, Schnittstellenbeschreibungen und weitere Ergebnisse, die mit den Anforderungen und dem Architekturmodell verbunden werden sollten, um einen nachvollziehbaren Entwicklungsprozess zu gestalten. Was man also braucht ist ein Traceability-Konzept, das besagt welche Artefakte wie verbunden werden.

Wie immer sind Sie herzlich eingeladen uns unter der angegebenen e-Mailadresse Ihre Erfahrungen und Anmerkungen zu diesem Thema mitzuteilen. Wir freuen uns über jeden sachdienlichen Hinweis!

Falls Sie Interesse an weitere Informationen rund um die hier angesprochenen Themen haben, schreiben Sie uns einfach eine Mail an heureka@sophist.de.

Schreibe einen Kommentar

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