Koexistenz zwischen Anforderungs- und Modellierungswerkzeug

Auf dem Requirementsengineering Barcamp 2016 in Köln hatte ich eine Session zu genau diesem Thema. Auf der einen Seite die Anforderungen, auf der anderen Seite die Architektur. Diese beiden Aspekte werden oft durch unterschiedliche Werkzeuge abgedeckt. In vielen Sessions und Gesprächen auf dem Barcamp war es Konsens, dass sowohl Anforderungen als auch Modelle ihre Berechtigung haben. Doch wie kann man damit umgehen, wenn Anforderungen mit einem Werkzeug und die Modelle in einem anderen Werkzeug bearbeitet werden? In diesem Artikel fasse ich die Ergebnisse und Inhalte der Session kurz zusammen.

Warum Verbinden?

Zunächst einmal stellte sich die Frage, warum Anforderungen und Architektur überhaupt verbunden sein sollten? Das ist eine durchaus berechtigte Frage. Die Architektur ist die Lösungsbeschreibung, während die Anforderung die Problembeschreibung darstellt. Es ist sinnvoll eine Verbindung zwischen der Anforderung und der Lösung herzustellen, um auf einfache Art und Weise die Anforderungen auf Subsysteme und Komponenten herunterzubrechen. Daraus ergibt sich der Mehrwert, dass man nicht nur weiß, was das System tut, sondern auch welche Komponenten dabei mitwirken und wie das System funktioniert. Damit ist es möglich festzustellen, welche Anforderungen durch welche Komponenten realisiert werden (Allokation). Kommt es zu einer Änderung der Anforderungen oder der technischen Lösung, so ist es möglich festzustellen, worauf sich die Änderung auswirkt. Diese Traceability ist ein mächtiges und sehr praktisches Werkzeug. Ein anderer Aspekt ist, dass es eine starke Wechselwirkung zwischen Anforderungen und Architektur gibt. Anforderungen führen zu einer Architektur und umgekehrt ergeben sich aus der Architektur neue Anforderungen. Wer mehr darüber wissen will, kann sich auch gerne den Artikel Anforderungen vs. Architektur – das zigzag Pattern anschauen.

Lösungsansätze

In der Session haben wir 5 Lösungsansätze diskutiert, die ich hier kurz beschreiben möchte. Die Reihenfolge stellt dabei keine Wertung dar.

1) Architektur und Anforderungen bewusst getrennt

Es ist durchaus legitim diese Trennung zu akzeptieren. Es gibt die Welt in der man sich mit Anforderungen und Tests beschäftigt und es gibt Architektur. Diese werden in getrennten Dokumenten ausgeleitet und stehen nebeneinander. Eine Verbindung existiert nicht wirklich und das wird auch bewusst akzeptiert.

2) Anforderungen in Modell integrieren

Anforderungen sind Teil von SysML und können somit in den Modellen enthalten sein. Damit ist es möglich Anforderungen und Architektur in einem Werkzeug zu bearbeiten. Hier kann ich den Artikel Requirements Engineering mit Enterprise Architect empfehlen.

3) Händisches Vorgehen

Nicht unüblich ist es, aus den Modellen „Bilder“ für Anforderungsdokumente zu benutzen. In diesem Fall verwendet man das Modell als Quelle für Ansichten, die dann im Requirements-Werkzeug genutzt werden. Auch dieses Vorgehen ist durchaus nicht verwerflich. Alles, was dabei hilft, das System besser zu beschreiben ist erlaubt :-).

4) Externe Traceability

Die Traceability wird über externe Werkzeuge oder Mapping Tabellen hergestellt. Diese Lösung halte ich für problematisch und nicht wirklich geeignet.

5) Werkzeuge zur Synchronisation

Die Werkzeuge haben standardisierten Schnittstellen ReqIF (Requirements Interchange Format), über die Daten importiert und synchronisiert werden können. Damit ist es möglich die Anforderungen und Architekturelemente in beiden Werkzeugen bearbeiten zu können. Es gibt eine Vielzahl von Toolherstellern, die Adapter zur Synchronisation anbieten. Als Beispiele möchte ich den ReqXChanger von Willert und den LieberLieber Connector erwähnen. Hier gibt es aber auch noch viele weitere.

Was sonst noch wichtig war?

Bei der Session gab es einige spannende Themen und die 45 Minuten sind wie im Flug verstrichen. Besonders hervorheben möchte ich die folgenden 3 Aspekte:

• Es gibt keine Werkzeuge, die Out-of-the-box funktionieren. Komplexe Werkzeuge für Anforderungsmanagement oder Modellierung müssen konfiguriert und an die eigenen Bedürfnisse und Prozesse angepasst (und validiert) werden. Das ist mit Aufwand verbunden, der sich aber rechnet. Schließlich sind das die Werkzeuge der täglichen Arbeit und effizientes Arbeiten ist nur möglich, wenn die Werkzeuge funktionieren.
• Anforderungen und Architektur sind nicht in Stein gemeißelt und ändern sich. Erfahrungswerte besagen, dass sich 2-5 % der Anforderungen pro Monat ändern! Das ist eine ordentliche Hausnummer und damit wird auch klar, dass Werkzeuge bei diesen kontinuierlichen Änderungen absolut notwendig sind.
• Es werden „Kümmerer“ benötigt. Ein Kümmerer ist ein Mensch, der innerhalb eines Projektes übersetzt und Kommunikation fördert. Es bringt nichts die besten Anforderungen oder Systemmodelle zu haben, wenn diese nicht kommuniziert und erklärt werden. Viele Menschen haben nicht die Zeit hundert seitige Spezifikationen zu lesen und viele verstehen Modelle nicht ohne Erklärung. Daher ist es wichtig, dass diese Informationen aufbereitet und vorgestellt werden. Hier ist ein Systemingenieur, ein technischer Projektleiter oder einfach ein Kümmerer notwendig.

Mir hat das Barcamp und die Session sehr viel Spaß gemacht und ich kann nur jeden ermuntern, an solchen Veranstaltungen teilzunehmen. Es ist enorm, wie viel Wissen und Erfahrungen man aus einem Barcamp mitnehmen kann.

Abschließen möchte ich heute mit einem Zitat über Barcamps, das mir sehr gefällt.

• Wenn du kommst, sei bereit, mit anderen BarCampern zu teilen.
• Wenn du gehst, sei bereit, mit der Welt zu teilen.

Quelle: http://barcamp-siegen.de/die-barcamp-regeln/

Viele Grüße

Goran Madzar

Kontaktieren Sie uns!