Requirement Engineering für komplexe Systeme – Teil II

Im letzten Beitrag habe ich bereits zwei Probleme des Requirement Engineering in komplexen Systemen angesprochen: Fehlende Lastenhefte und die fehlende Trennung zwischen System- und Projekt-Anforderungen. Hier möchte ich zwei weitere, nicht weniger relevante Probleme diskutieren.

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 Requirement Engineering dann so schwierig.