“Schon wieder von vorn?”

In der Systementwicklung kommt es häufig vor, dass verschiedene Endprodukte für verschiedene Kunden beträchtliche Gleichanteile aufweisen – wäre es dann nicht sinnvoll, das gesammelte Wissen und gewonnene Erfahrungen zu konservieren und weiterzuentwickeln, sodass zukünftige Projekte davon profitieren können? In diesem Beitrag möchte ich ein einfaches ReUse-Konzept vorstellen und dessen Vorteile beleuchten, aber auch anstehende Herausforderungen aufzeigen.

Grundsätzlich werden alle Anforderungen, die ein Potenzial zur Wiederverwendung besitzen, in einem Anforderungspool gesammelt. Sobald ein neues Projekt es erfordert, werden diese Anforderungen wiederverwendet und in die neue Spezifikation kopiert – lediglich projektspezifische Anforderungen sind ausschließlich in der Spezifikation des Projekts vorhanden.

Ein großer Vorteil dieses Pool-Gedankens ist, dass der Aufwand für die Erstellung der Anforderungen nur einmal innerhalb des Pools geleistet werden muss – neue Projekte können sehr schnell starten. Zudem besitzen alle Projekte eine gemeinsame Basis und alle Anforderungen können zentral verwaltet werden. Die Anforderungen reifen außerdem ständig weiter und Lessons Learned bleiben erhalten.

Entscheidend für den Erfolg dieses Vorgehens ist allerdings ein Mechanismus, welcher die Bearbeitung der wiederverwendeten Anforderungen direkt in den Projektdokumenten verbietet! Wäre dies möglich, entstünden in kurzer Zeit viele verschiedene Versionen ein und derselben Anforderung, und der Pool-Gedanke wäre wertlos. Wenn das Bearbeitungsverbot jedoch eingerichtet wurde, ist sichergestellt, dass wiederverwendete Anforderungen in nur einer einzigen, gültigen Version vorliegen – auch die Tester werden es ihnen danken!

Im Änderungsfall muss man dann zwei Fälle unterscheiden:

1. Die Änderung ist sinnvoll für alle Projekte oder
2. die Änderung ist projektspezifisch.

Wenn die Änderung einer Anforderung sinnvoll für alle Projekte ist, muss die Änderung direkt im Anforderungspool stattfinden und so ihren Weg in die projektspezifischen Spezifikationen finden. Ist dies nicht der Fall und die Änderung projektspezifisch und ohne Wiederverwendungspotenzial, muss die ReUse-Beziehung zwischen Anforderungspool und der projektspezifischen Spezifikation aufgehoben werden, und die Anforderung kann direkt im Projekt bearbeitet werden. Von diesem Zeitpunkt an ist die geänderte Anforderung projektspezifisch und losgelöst von Änderungen derselben Anforderung im Anforderungspool.

Diese Entscheidungen können nicht leichtfertig getroffen werden. Idealerweise wurde eine Rolle definiert, die vermittelnd agiert und sich mit den einzelnen Projektleitern abstimmt. Sofern diese Rolle vorhanden ist, benötigen die Projekte noch nicht einmal Kenntnis über den Anforderungspool, da diese direkt im jeweiligen ReUse arbeiten können.

Sie sehen, Wiederverwendung bietet einige Vorteile. Um jedoch langfristig davon profitieren zu können, müssen bestimmte Voraussetzungen geschaffen und das Vorgehen von allen Projektbeteiligten gelebt werden.

Marcel Klein

Kontaktieren Sie Marcel Klein

Marcel Klein arbeitet bei der HOOD GmbH als Consultant und als Trainer im Bereich Requirements Engineering. Seine Tätigkeitsschwerpunkte liegen in der Unterstützung unserer Kunden beim Einsatz von Requirements Engineering und zugehöriger Werkzeuge (z.B. DOORS). Zu seinen Aufgaben zählen die Erhebung, Verbesserung und Dokumentation von funktionalen und nicht-funktionalen Anforderungen, die Prozessverbesserung sowie die Erstellung von objektorientierten Modellen. Als Trainer hat er sich vor allem auf die gute Formulierung textueller Anforderungen und die nachhaltige Etablierung von Requirements Engineering in einem Unternehmen spezialisiert. Er veröffentlicht regelmäßig zu beiden Themen Artikel und Blogs.