Requirement Engineering für komplexe Systeme – Teil I

In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirement Engineering für komplexe Systeme so wichtig ist. Hierfür erläutere ich zunächst die ersten großen Schwierigkeiten in solchen Situationen: Das fehlende Lastenheft und die fehlende Trennung zwischen System- und Projekt-Anforderungen.

Problem 1: Lastenhefte

Als Troubleshooter habe ich mittlerweile viele Unternehmen auf dem Weg zu einem Lastenheft begleitet. In vielen Situationen lagen zu Beginn keine oder keine wirklichen Lastenhefte vor. Das ist bereits die erste Schwierigkeit.

Ich erinnere mich beispielsweise an ein Projekt, in dem es ein kleineres, wenn auch komplexeres Teilsystem eines größeren Gesamtsystems gab, welches entsprechend entwickelt und auch im Feld war. Hier ist es vorgekommen, dass diverse Schwierigkeiten sogar in die Richtung eines Rückläufers wiesen: Die Fahrzeuge mussten tatsächlich zurück in die Werkstatt und Teile dieses kleinen Teilsystems getauscht werden.

Allen Beteiligten war an diesem Punkt klar, dass ein Nachfolgesystem entwickelt werden musste. Denn das vorliegende hat zwar funktioniert, aber in einer geringen Anzahl dennoch für Ausfälle gesorgt, die durchaus zu einer Verkehrsgefährdung führen konnten. Also wurde ein neues Entwicklungsprojekt gestartet – und wir für ein Lastenheft hinzugezogen.

In diesem Projekt gab es bis zu diesem Zeitpunkt im Grunde kein Lastenheft, weder vom Hersteller noch dem Zulieferer oder dem Entwicklungsdienstleister. Alle hantierten mit irgendwelchen PowerPoint-Folien, E-Mails und Dokumenten, aber nicht mit einem Lastenheft und einer Spezifikation.

Und das ist das große Problem, das es so schwierig macht, Requirement Engineering für Produkte umzusetzen: Wenn überhaupt keine Lastenhefte da sind, können sich Entwicklungsprojekte nur unglaublich mühsam in die richtige Richtung entwickeln.

Problem 2: System-Anforderungen vs. Projekt-Anforderungen

Der zweite Punkt, der es oft für komplexe Systeme schwierig macht, ist, dass vielfach die Trennung zwischen den technischen Requirements, also zum Beispiel den System-Requirements, und dem Projektmanagement-Handbuch fehlt.

Hier noch einmal kurz zur Erläuterung: Auf der einen Seite haben wir ein System, was wir entwickeln, auf der anderen das Entwicklungsprojekt selbst. Diese unterscheiden sich ganz elementar in den Anforderungen.

Es gibt zunächst die Anforderungen an das System. Diese bleiben, auch wenn das Entwicklungsprojekt zu Ende ist. Es ist das, womit der Kunde später hantiert und es in seinem Kontext einsetzt. Es sind die technischen Anforderungen an ein System, die über das Projekt hinaus relevant bleiben.

Ein Entwicklungsprojekt hat auch Anforderungen. Diese Anforderungen sind während des Entwicklungsprojekts natürlich relevant, nach Projektende werden sie jedoch hinfällig.

Beispiele hierfür sind Meilensteine oder Entwicklungsbudgets: Beides ist total wichtig, ist das Projekt jedoch offiziell abgeschlossen, sind auch diese Meilensteine und die Budgets etc. im Grunde irrelevant.

Wir müssen trennen zwischen den technischen Anforderungen, also den Anforderungen an ein technisches System auf der einen Seite, und den Anforderungen an ein Entwicklungsprojekt auf der anderen.

Genau das wird häufig nicht gemacht. Ich erlebe das regelmäßig in den Workshops auch großer, extrem erfolgreicher Firmen: Wenn wir in den System Footprint einsteigen, kommen plötzlich Anforderungen auf den Tisch, die nicht an das System gerichtet sind – weil es eben Projektanforderungen sind.

Deshalb gibt es ja parallel zum dem System-Footprint noch den Project-Footprint. Diese Trennung ist extrem wichtig, denn Projekt-Anforderungen sind ebenso essentiell, müssen aber anderweitig festgehalten und bearbeitet werden.

Im nächsten Beitrag gehe ich auf die Problemfelder „Überblick behalten“ und „mangelnde Kommunikation“ ein.