Requirements Engineering für komplexe Systeme
In diesem Beitrag möchte ich auf die Frage eingehen, warum Requirements 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. Außerdem gehe ich darauf ein wie wichtig es ist, den Überblick zu behalten und was gute Kommunikation ausmacht.
Problem 1: Lastenhefte
Als Systemingenieur und Projektleiter 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.
Problem 3: Den Überblick behalten
Gerade komplexe Systeme führen zwangsweise zu einer Spezialisierung bei den Entwicklern – und zu einem Verlust des Überblicks.
Bei einfacheren Systemen sind insgesamt vielleicht fünf Leute involviert, hier können wir das Gesamtsystem meist überblicken. Bei Projekten, die hochgradig komplex und sogar über mehrere Entwicklungsteams verteilt sind, sieht das anders aus.
In diesen Fällen müssen die jeweiligen Spezialisten sehr tief in ihre Materie eindringen, um ein Problem zu lösen. Besonders für das Projekt-Management, aber auch für die anderen Beteiligten wird der Überblick so zur großen Herausforderung.
Vor allem in Entwicklungsprojekten gibt es oft regelrechte Hierarchien mit Projektleitern als Teammitglieder und vielen zusätzlichen Teilprojekt-Leitern etc. Solche Strukturen führen entsprechend zu Spezialisierungen, diversen Fokussierungen auf eigene Kerngebiete – und oft zum Verlust des Verständnisses für das Gesamtsystem.
In einem von mir betreuten Projekt gab es z.B. einen Software-Ingenieur, der absoluter Spezialist für Bootloader war. Parallel gab es einen weiteren Spezialisten, der für die zweite Funktionalität, nämlich Diagnosefähigkeit, zuständig war.
Diese hing eng mit dem Bootloader zusammen, da dieser auch zur Aktualisierung bzw. dem Flashen der Software im Fahrzeug genutzt wurde. Dies war jedoch nicht mehr das Kerngebiet des Bootloader-, sondern des Diagnose-Kollegen.
Diese Experten waren zudem über die ganze Welt verteilt, sodass es eigentlich niemanden gab, der einen kompletten Überblick über alle Requirements und das Gesamtsystem hatte. Für alle wurde die Situation dadurch extrem anspruchsvoll.
Problem 4: Mangelnde Kommunikation
Ein weiterer Ursprung großer Schwierigkeiten: Ich erlebe sehr häufig ein regelrechtes Silo-Denken in fachlichen ebenso wie in Produktbereichen.
So habe ich vor ein paar Jahren z.B. ein Projekt eines großen Automotive-Zulieferers in Paris begleitet. Als Troubleshooter habe ich hier unter anderem ein Feldproblem behoben. Die Situation war komplex und beinhaltete übergreifende Bereiche zwischen Automobilhersteller und Zulieferer.
Die Kernursache für die vorgefundenen Fehler? Es wurde nicht richtig kommuniziert. So gab es Informationen auf dem Campus, die auch offiziell von dem Zulieferer-System zur Verfügung gestellt wurden – allerdings gab es offiziell niemanden, der als Abnehmer dieser Daten diente.
Genauer gesagt hat der Zulieferer solche Signale nicht ausführlich getestet, da er davon ausging, dass kein weiteres Steuergerät diese Informationen abnimmt. Das war weit gefehlt – doch schlimmer war die Reaktion auf meine geäußerten Sorgen: „Warum soll ich denn mit dem Kunden reden?“ Besser kann man wohl kaum zeigen, was es bedeutet, wenn keine Kommunikation vorliegt.
Ein anderes Mal habe ich dieses Problem bei einem komplexen Elektromobilitäts-Projekt mit zwei großen Teilsystemen erlebt. Meine Aufgabe war eigentlich das Mentoring des einen Teilbereichs, allerdings gab es eine Software-Schnittstelle zwischen den Teilsystemen, die noch undefiniert war und dringend besprochen werden musste.
Also habe ich einen kurz-knackigen Workshop einberufen – der von den beiden Lead-Software-Ingenieuren nur mit großem Widerstand wahrgenommen wurde. Sie wollten schlicht nicht mit anderen Kollegen über ihre eigenen Anforderungen sprechen.
Wir überzeugten sie schließlich mit der Tatsache, dass auf Systemebene diese Schnittstelle klar definiert sein muss – doch dieses Silo-Denken und diese Kommunikationsverweigerungen gehören eher zum Alltag, als dass sie Ausnahmen darstellen. Und genau das macht Requirements Engineering dann so schwierig.
