Zerrissenheit in der modernen Systementwicklung

„Zerrissenheit“ ist das täglich Brot auf dem langen Marsch von der Stakeholder-Gemeinde mit ihren wechselhaften Anforderungen bis zu einer entsprechenden Systemgestaltung und Auslegung. Erfahrene EntwicklerInnen stellen sich dieser, oft im Grunde politischen Kompromissfindung, oder ziehen sich in Ihren Expertenturm zurück, in der Erwartung, dass die Designentscheidungen von anderer Stelle kommen. Dass entgegengesetzte Stakeholder-Meinungen Ausgleich finden und Entscheidungen in der Lösungsfindung herbeigeführt werden, so dass es nicht zur Zerrissenheit kommt, ist nur mit kombinierten Kompetenzen in Führung, Methodik und Technik machbar. Es geht weit über das hinaus, was man im Grundlagen-Lehrbuch über Requirements Management zu verstehen lernt. Das dort vermittelte Wissen über die Verwaltung von Anforderungsdaten ist zwar notwendig, wenngleich nicht ausreichend. Vernünftige und angemessene Informationsmodelle für die Handhabung von Entwicklungsartefakten wie Anforderungs- und Testdaten, sowie Änderungs- oder Aufgabenobjekten zu finden, bedeutet für manches Projekt eben nicht, sich aus der Standardvorlage oder Vorgängerkiste zu bedienen.


Zerrissenheit in den Arbeitsprozessen

Heute ist es so, dass bei den nächsten System-Generationen – etwa mit modernster Navigation und Stufe 5 Autonomie ausgerüsteten Transportmitteln, oder einem multi-physikalischen Diagnose- oder Therapiegerät mit KI-unterstützten Bildanalyseverfahren – die Entwicklung der auf der Basis von “Leading Edge” Halbleitertechnologien und mächtigen Software-Stacks beruhenden Innovations-Komponenten, eine Organisationsmaschinerie in Gang setzt, die hunderte von Ingenieuren und Managern über viele Firmen-Grenzen hinweg in Bewegung hält. Dass immer komplexere Arbeitsprozesse und Informationsplattformen den Entwicklungsgang begleiten, scheint ein sich zwangsläufig aus dem Entwicklungsobjekt ableitender Effekt zu sein. Die Veränderer können dabei selbst Opfer der Veränderung werden. Spalterische Kräfte sind zwangsläufig am Werk, jedes Problem öffnet einen Entscheidungsraum, der, wenn er nicht systematisch und adäquat methodisch bearbeitet wird, zu den berühmten Sackgassen-Lösungen und unbeabsichtigter Vor-Zurück-Entwicklungsarbeit führt. Wenn es bis zur Nutzungsphase zu keiner Klärung gespaltener Ansichten kommt, so führt es zu Kommunikationsfehlern oder nicht mehr stattfindender Kommunikation. Ergebnisse wie ein falsch geschliffener Spiegel eines Weltraumteleskops, falsch reagierende Flughaltesysteme oder nicht kindersichere Schließsysteme kosten im Extremfall nicht nur Milliarden von Euro, sondern verursachen Tragödien und menschliches Leid.

Jetzt auf der Vorgabenseite noch weitere Seiten und Kapitel an die extrem gewachsenen Arbeitsprozess-Normen und Vorgehensstandards zu hängen, ist zwar das übliche Verfahren, aber in den Entwicklungsteams finden sich eh kaum noch “T”-Shapes, die sich neben ihrem technologischen Expertenwissen, das heutzutage schon einen Kosmos für sich darstellt, auch noch tiefsinnig mit Vorgehensmodellen, Qualitätsprozessen und Richtlinien á la ISO9000, IATF 16949, VDI225, IEC12207 oder ISO15504 beschäftigen wollen. Dazu gibt es ExpertInnen, Fachabteilungen, Gremien und Forschungszweige und die Hoffnung, dass diese für die lästige Verwaltungsarbeit die richtigen Prozesse, Tools und Methoden bereitstellen. In der Praxis kommt es dann auf die Tool-Plattform und ihre Nutzungsszenarien an. Dazu muss dann noch die Nutzerakzeptanz passen. Eine Fehlentwicklung ist es sicherlich, wenn Dienstleister für reine Dateneingabe und Pflegefunktionen ihre Spuren in den Werkzeugen hinterlassen müssen, damit der Firmenmitarbeiter von dieser Tool-Last befreit ist.
Alles in allem muss man sagen, neigt dieses System zunehmend zur Übertreibung und untergründige Ängste, Fehler zu machen, führen zu einer “Viel hilft viel” Gedanken-Haltung und der eher zynischen Interpretation für den Begriff „Team“ als Abkürzung für: „Toll, ein anderer machts“.

Welches „Viel“ hilft viel?

Das ist nicht ganz zielführend, aber das alles hat heute zu einer glücklicherweise angemessenen Berücksichtigung des Projekt-Budgets für die Themen Anforderungen, Lastenheft, Design-Spezifikation und Requirements Engineering geführt. Schon ältere Projekt-Analysen haben gezeigt, dass in der Regel ein höheres Invest in dieses Thema zu weniger Kostenüberschreitung führt, [Partsch 2010] zieht dazu eine NASA Untersuchung heran:

Der Graph geht implizit davon aus, dass jeder Euro, der in RE-Prozessvorgaben, Tool- und Methoden-Experten, Requirements-Ingenieure und prophylaktische Qualitätssicherung gesteckt wird, zumindest die Wahrscheinlichkeit einer Kostenüberschreitung reduziert.
Zwei Datenpunkte zeigen sogar, dass ein RE-Aufwand von größer 10% in der Gesamtheit zu einer Unterschreitung der geschätzten Projektaufwände führte.
Bei einer einfachen betriebswirtschaftlichen Betrachtung – d.h. man geht von einem linearen Zusammenhang aus – läge das Aufwandsmaximum für (ein vernünftiges RE-Budget) einen optimalen RE-Einsatz bei ca. 15%. Diese einfache Betrachtung würde aber dazu führen, dass man mit noch mehr RE Negativ-Kosten erhalten würde. Das weist schon darauf hin, das es nicht ganz so einfach ist. Eine extreme andere Position lässt sich aus diesen, -wohl wie immer- Einstein nur in den Munde gelegten Worten entnehmen:

Vernünftige und angemessene RE-Maßnahmen zu treffen, ergibt sich nicht einfach von selbst. Die weiter oben erwähnten System- und Organisationskomplexitäten zerschlagen dieses Ansinnen, ein subtiler Grenzbereich tut sich auf. Vordergründig Vernünftiges entpuppt sich dann als Übertreibung, Clownerei oder Schildbürgerstreich. Im Projekt herrscht “Zerrissenheit” zwischen auseinanderdriftenden “Viel hilft viel”- und “Weniger ist Mehr”-Protagonisten.

ERAEOS – Das extreme Anti-Engineering- Leiden

Die Produktentwicklung leidet dann unter ERAEOS (Extreme Requirements Anti-Engineering Overloading Symptom) – einem unstillbaren und nicht enden wollenden Verlangen nach Requirements Engineering. Das ist aber im Endeffekt Anti-Engineering. Alle grundsätzlichen Maßnahmen, die tatsächlich die Effektivität im Entwicklungslauf verbessert haben, werden negiert und das RE-Budget verbrennt in einem überladenen Informationsmodell, das zur Wartungsfalle geworden ist. Der Zusammenhang lässt sich prinzipiell folgendermaßen darstellen:

Ein Stachelkleid für Anforderungssammlungen

Vorhaben, die immer wieder weitere Änderungspakete schnüren müssen, immer wieder neue Aufwandschätzungen, Ramp-Up-, Ramp-Down- und Burndown-Metriken produzieren, sind mit ziemlicher Sicherheit auf dem ERAEOS Pfad unterwegs. Dieser stellt ein “El Dorado” für pedantische Arbeitsprozess-Designer und „Passagierschein A38“-Enthusiasten dar. Hier finden sich in der Regel überkomplexe Informationsmodelle mit Ihren Verstehern und Vorgehens-Verkomplizierern, die den sich um Abarbeitung mühenden “Task Forces” gerne noch ein Aufwandspaket mehr bescheren. Die Lifecycle Management Tool-Kette wird dann eher mit einem Wimmelbild von Ali Migutsch zu vergleichen sein. Es ist eine Ironie in sich, dass auch hier die Aussage Alan Coopers gilt: “The inmates run the Asylum“, die wichtigen Daten über das „Was“,“Wie“,“Wo“ und „Wann“ der Produktentwicklung sind mit einem Stachelkleid überzogen und nur die „Inmates“ spazieren darin herum.    

Der zweite Pfad

Dabei gibt es einen zweiten Pfad, der die RE-Effektivität im Projekt nachhaltig stärken kann. Dieser baut auf Transparenz und Vereinfachung von Werkzeug und Kommunikation auf. Um diese Maßnahmen zu verdeutlichen, folgen hier zwei konstruierte Beispiele:

Beispiel I: vom Ableitungswasserfall zur Wespentaille

Entwicklung serientauglicher komplexer Fahrzeug-Sensorik, die im Rennen um die beste Fahrzeug-Autonomie für den Hersteller einen strategischen Vorteil verspricht, geht einher mit einem Anforderungsprozess, der im Umfeld von großen Fahrzeugpaletten und volumenstarken Marktsegmenten eine mittlere Bibliothek an Anforderungsdokumenten mit sich bringt. Den Kern bildet ein umfangreiches Lastenheft. Darin sind in der Regel mehr als 50 weitere Dokumente referenziert. Weitere anzuwendende Standards, Normen oder projektspezifische Sonderdokumente sind üblich.

Auf der Seite des Zulieferers kümmert sich der, mit der Entwicklung betraute Organisationsteil darum aus den Kundenanforderungen die System-Anforderungsebene abzuleiten. Dies ist in unserem Beispiel im Wesentlichen eine Copy-Paste-Aufgabe, da der Kunde bereits detailliert die geforderte Systemfunktionalität und die Leistungsfähigkeit mit Ziel-KPIs beschreibt. Der Ansatz wird über alle anlandenden Anforderungs-Kundendokumente ausgeweitet. Bildlich kann man sich das Schema wie folgt vorstellen:

Vordergründig macht so niemand etwas falsch, oder kann sogar für sich in Anspruch nehmen, dass er oder sie absolut prozesskonform handelt, wenn jede, als Anforderungsdaten identifizierte Quelle dem System-Prozess unterworfen wird. So kann man in diesen Projekten “Requirements Engineers” dabei beobachten, wie OEM-Anforderungen an die Zeichnungsqualität oder referenzierte AUTOSAR-Normen (frei erhältliche Software Modul-Spezifikationen) in einer Weise zerlegt, heruntergebrochen und an verschiedenste Gewerke mehrfach allokiert werden, als wären es die Kernanforderungen im eigentlichen Lastenheft, für die ein solches Vorgehen natürlich gerechtfertigt wäre. Für große Zulieferer-Firmen könnte man ins Feld führen, dass die Kassenlage und die Farshore Ingenieurs-Kosten diese Vorgehensweise bezahlbar machen und sie irgendwie auf den ersten Blick kaum schaden kann. Im Gegenteil – es werden Argumente für deren Notwendigkeit gefunden. Auf den zweiten Blick sollte man hier schon ein Schadensrisiko erkennen können. Allein die Frustration und Resignation von Funktionsentwicklern, die sich immer wieder mit kaum nachvollziehbaren Review-Inhalten und obskuren Anforderungsmetadaten herumschlagen müssen, kann ein Fluktuationstreiber sein. Oft sind sich diese Projekte aber nicht bewusst, dass EREAOS sie befallen hat.

Die Wespentaille – „Design to Cost“ gilt auch für Informationsmodelle

Kostensparender und effizienter ist man mit dem Wespentaillen-Verfahren unterwegs. Das oder die definierten Kernlastenhefte werden einem RE- Prozess mit detaillierten Reviews unterworfen. Referenzierte gewerksspezifische Anforderungsdokumente werden durchgereicht und auf den Gewerksebenen weiterbearbeitet. So kann ein Gewerksexperte entscheiden, welche Teile detailliert im Gewerks- oder Subsystem RE-Prozess bearbeitet werden.


Der Wespentaille-Ansatz hat einen Zusammenhang mit der QFD (Quality Function Deployment)-Technik des „Bottleneck Engineerings“. Die funktionalen Kapitel der Anforderungen an das Zielsystem sollten erkennbar durch diesen Prozess gegangen sein.

Beispiel II  Anforderungs-Wartungs-Fallenbau

Wir konstruieren den Fall eines Sub-Lieferanten für einen intelligenten Sensorkopf. Wir nehmen die „Sandwich“-Perspektive eines Tier-1-Systemzulieferers ein, unser Kunde: der Transportsystem-Hersteller. Der Sensorkopf soll vom Sub-Lieferanten entwickelt werden, wir entwickelt das Komplettsystem Sensor-System, bestehend aus Kopf, Image-Processing-Einheit und Transport-System-Anbindung. Der Transportsystem-Hersteller hat ein eigenes, sehr kompetentes Team mit viel Erfahrung aus Vorgängerprojekten. Der geforderte Leistungsumfang des Sensorkopfs wird auch von diesem Team sehr genau im Lastenheft verankert. Wie sich die Anforderungsarbeit in dieser Lieferkette aufteilt zeigt folgende Skizze:

Das sieht erst mal nach Lehrbuch-Ansatz aus. Die Prozesse, die sich in diesen Informationsmodellen abspielen, lassen sich in etwa folgend beschreiben.

Lasten-Pflichtenheft Copy Paste Modify

Aufgrund der oben beschriebenen Gegebenheiten liegt es nahe, die Lastenheft-Anforderungen des Transport System-Bauers vollständig ins Pflichtenheft zu übernehmen. Im RE-Werkzeug wird eine “System Requirements Specification” aufgebaut und dem Projekt zu Grunde gelegt. In Qualitätskriterien geübte Requirements-Spezialisten fangen an, die System Requirements zu pflegen, aufzuteilen, weil „Atomizität“ wichtig ist, den Text zu ändern um „Verständlichkeit “ zu erhöhen und abzuleiten, um eindeutig einem System-Architektur-Element die Anforderung zuweisen zu können.

Pflichtenheft-Subsystem-Lastenheft Copy Paste Modify

Da ein Großteil der Inhalte auch für den Sub-Lieferanten anwendbar ist, wird dieser Teil unter Zuhilfenahme von Copy-Link-Toolfunktionen ins Sub-System-Anforderungsmoduldokument transferiert. Die Verzeichnisstruktur im Sub-System-Anforderungsmoduldokument wurde anders als im System-Anforderungsdokument gewählt. Das Sub-System-Anforderungsmoduldokument wird wöchentlich mit der Sensorkopf-Entwicklungsfirma werkzeugbasiert ausgetauscht, und Statusinformationen werden neben weiteren Metadaten abgeglichen. Auf der Ebene des Subsystem-Lastenheftes werden von Requirements Engineers ebenfalls ähnliche Qualität verbessernde Modifikationen wie schon auf Systemebene durchgeführt.

Silo Engineering ohne Änderungsbewusstsein

Obwohl auch in diesem Fall das Vorgehen bei einer „Lehrbuch“- Betrachtung durchaus durchgehen kann, ist das Verfahren in der Praxis nicht Kosten-Nutzen optimal. Fatalerweise kann es in der Praxis sogar passieren, dass inkonsistent nebeneinanderher gearbeitet wurde, wenn die System-Anforderungsebenen nicht einem ständigen Konsistenzabgleich unterliegen. Überprüft man sehr spät die Konsistenz, stellen sich u.a. folgende Probleme ein:

  • Anforderungen im Subsystem LH sind akzeptiert – In der System Requirement Specification ist die Anforderung modifiziert
  • Anforderungen im Subsystem LH sind akzeptiert – In der System Requirement Specification ist die Anforderung in einem nicht konsistenten Review Status
  • Anforderungen im Subsystem LH sind nicht akzeptiert – In der System Requirement Specification ist die Anforderung akzeptiert
  • Anforderungen im Subsystem LH sind nicht akzeptiert – In der System Requirement Specification ist die Anforderung in einem nicht konsistenten Review Status
  • Anforderungen im Subsystem LH werden bearbeitet – In der System Requirement Specification ist die Anforderung für das Subsystem als ungültig erklärt worden

Smart Engineering als Ausweg

Die elegante Lösung um das obige Dilemma zu vermeiden, sei hier nur kurz skizziert. Im Wesentlichen wird es helfen, auf der Systemebene keine Zweiteilung durchzuführen und nur über ein Allokationsschema die Subsystemanforderungen zu einem Austauschpaket zu filtern. Dazu ist ein kleines Set an Metainformationen bzgl. des Subsystemanforderungsaustauschs notwendig. Requirements Engineers, die meinen, es wäre hilfreich, qualitätsorientierte Textmodifikationen an, von Umsetzern und Testern gut verstehbaren, original Systemanforderungstexten aus dem Lastenheft durchzuführen, sollten sich unbedingt von allen Stakeholdern aller Ebenen zu der Anforderungsänderung eine Freigabe geben lassen. Leichtfertige Änderungen behindern iteratives Arbeiten, wenn möglich die Änderung auf der obersten Ebene (LH Transport System Hersteller) einsteuern.

Wegen zu viel RE gescheitert

Die beiden genannten Beispiele zeigen, dass der ERAEOS-Pfad alles andere als offensichtlich sein kann. Lange denkt man noch, man mache das Richtige, dabei haben sich die Palmen, die uns zerreißen können, schon zu biegen begonnen.

Abschließend müssen wir zur Kenntnis nehmen: Projekte scheitern heute nicht nur wegen zu wenig RE, sie können auch wegen zu viel falschem RE scheitern!