Suchen

Requirements Engineering Migration und Austausch von Anforderungen

Autor / Redakteur: Frank Lippert * / Franz Graser

Entwicklungsanforderungen müssen mitunter in ein neues System migriert werden, wobei der Austausch der Requirements mit Kunden und Zulieferern sichergestellt bleibt. Der Artikel zeigt Best Practices auf.

Firmen zum Thema

Softwareentwicklung findet immer im Kontext von Partnern und Kunden statt. Das kann zu Problemen führen, wenn Systemanforderungen von einem Werkzeug zu einem anderen Tool migriert werden.
Softwareentwicklung findet immer im Kontext von Partnern und Kunden statt. Das kann zu Problemen führen, wenn Systemanforderungen von einem Werkzeug zu einem anderen Tool migriert werden.
(Bild: Clipdealer)

Entwicklungsabteilungen verwalten ihre Anforderungen schon lange nicht mehr in Textdokumenten oder Tabellen, sondern in professionellen und spezialisierten Tools für das Requirements Management. Diese bieten neben der üblichen hierarchischen Anordnung von Requirements zusätzliche Features wie benutzerdefinierte Attribute und Typen, verschiedene Views auf Requirements-Dokumente, eine Versionierung der Dokumente und vor allem die Nachverfolgbarkeit von Anforderungen (etwa von einem Test zu einer Anforderung).

Weit verbreitete Lösungen für das Requirements Management sind IBM Rational DOORS und PTC Integrity und Tools wie Visure, Polarion, Rectify und andere. So komfortabel und sicher diese Werkzeuge auch sind, forderten sie dennoch lange Zeit einen bestimmten Preis: Es sind Dateninseln. Das bedeutet: Der Austausch von Anforderungen war lediglich zwischen Instanzen des gleichen Werkzeugs möglich.

Seit einigen Jahren hat sich ein herstellerunabhängiges Austauschformat etabliert: das Requirements Interchange Format (RIF). Wurde dieses Format zunächst von einem Industriekonsortium, der „Hersteller Initiative Software“ – einem Zusammenschluss mehrerer Automobilfirmen – definiert und verwaltet, so entwickelte es sich seit 2011 zum international standardisierten Format ReqIF weiter, das von der Object Management Group (OMG) genormt und gepflegt wird. Erst mit dieser Austauschmöglichkeit wird es möglich, überhaupt von einem seit langem eingeführten Anforderungs-Tool auf ein anderes zu wechseln.

Migration an einem fiktiven Beispiel

Nehmen wir als Ausgangslage für unser fiktives Beispiel einen Zulieferer mechatronischer Bauteile mit mehreren Abteilungen, die auf verschiedene Standorte verteilt sind. Eine solche Ausgangslage ist heute alles andere als selten zu finden. Eine dieser Abteilungen befasst sich etwa mit der Herstellung neuer Antriebsformen. Sie verfügt über einen DOORS-Server, in dem mehrere Projekte verwaltet werden. Pro Projekt sind fünf bis 20 Requirement-Dokumente mit bis zu 2000 einzelnen Requirements abgelegt.

Abb. 1: Die Benutzeroberflächen der Marktführer IBM Rational DOORS...
Abb. 1: Die Benutzeroberflächen der Marktführer IBM Rational DOORS...
(Bild: Mixed Mode)

Das Ziel der Firma in unserem Beispiel besteht darin, von der bisherigen Anforderungsverwaltung zu einer integrierten Lösung, bestehend aus Source Code Management, Requirements- und Change-Management sowie Testmanagement, zu wechseln. Das macht eine Migration der Anforderungen unumgänglich. Gleichzeitig muss der Betrieb der bisherigen Lösung noch sichergestellt bleiben. Requirements-Dokumente müssen nach wie vor ausgetauscht werden können – sowohl mit Partnern, die noch das alte Tool im Einsatz haben, als auch mit Partnern, die bereits die neue Lösung installiert haben. Für Migration und Austauscharbeiten werden sechs Monate veranschlagt.

Nehmen wir in unserem Beispiel einen Katalog von sieben Projekten an. Es ist empfehlenswert, davon eines als Pilotprojekt auszuwählen. Eine denkbare Aufgabe ist etwa die Migration von IBM DOORS nach PTC Integrity. Als Austauschformat kommt RIF (Requirements Interchange Format) zum Einsatz, als dezidiertes Austausch-Tool für den Export vom DOORS-Format nach RIF Atego Exerpt (vom Hersteller Atego) und schließlich die Integrity-eigene RIF-Toolkette für den Import von RIF-Dokumenten zu Integrity.

Die Anforderungsmigration: Auswahl der Dokumente

Vor der Migration gilt es zunächst zu klären, welche Module überhaupt migriert werden sollen. Im Detail muss festgelegt werden, welche Objektattribute, Views und Baselines daraus von der Migration betroffen sind. Bei Bedarf werden eigene Views angelegt, die die Auswahl gesondert darstellen. Die ausgewählten Module und Anforderungen werden anschließend über Atego Exerpt als RIF-Datei exportiert.

Abb. 2: ...und PTC Integrity ähneln sich, was sicher kein Zufall ist.
Abb. 2: ...und PTC Integrity ähneln sich, was sicher kein Zufall ist.
(Bild: Mixed Mode)

Bei DOORS kann man für jedes Modul die Objektattribute einzeln definieren. Dadurch stören mehrfache Attributdefinitionen nicht, solange sie auf ein Modul beschränkt bleiben. Bei Integrity sind dagegen Definitionen für Attribute nur installationsweit möglich. Das sorgt zwar für eine größere Einheitlichkeit der Anforderungsdokumente, erfordert aber das Mapping von Attributen bei jedem Austausch. So muss etwa ein DOORS-Feld „Kunde“ oder „Customer“ in Integrity immer auf „Customer“ abgebildet werden. Beim Austausch zurück sind also die Mappings aufzubewahren, um eine richtige Zuordnung treffen zu können.

(ID:42675833)