Requirements Management

Bummelzug zum Anforderungsmanagement

Es ist ein eisernes Gesetz aller modernen Gesellschaften, dass ihre politischen und bürokratischen Eliten immer mehr Gesetze produzieren. Mit wachsender Zahl nimmt der Grenznutzen der Gesetze zwangsläufig ab, wenn sie nicht gleich mehr Schaden als Nutzen anrichten, weil mit heißer Nadel gestrickt. Dessen ungeachtet ist die Regulierungswut dort am größten, wo sie am wenigsten bewirkt. Nirgendwo gibt es mehr Auflagen zum Umwelt- und Verbraucherschutz als in Europa, wo die Menschen nicht erst seit gestern unter relativ sauberen und sicheren Bedingungen leben. Oder anders ausgedrückt: In Bangladesch würde die Verschärfung des Baurechts sicher Menschenleben retten, hier sichert sie allenfalls den Lebensstandard von ein paar Beamten in den Baubehörden. Nicht selten ist die Regelungswut Ausdruck eigenen Unvermögens: Weil die Regierenden nicht in der Lage sind, den Waffenhandel der Rebellen in Afrika oder anderswo zu unterbinden, müssen jetzt die (amerikanischen) Unternehmen Bauteil für Bauteil nachweisen, dass sie keine Edelmetalle aus Krisenregionen verbauen.

Das Problem ist, dass der regulatorische Overkill der Politiker allmählich unsere Wettbewerbsfähigkeit und damit letztlich auch unserer aller Lebensstandard gefährdet. Egal wo man hinschaut – das Volumen an zu beachtenden Gesetzen und Normen ist in den letzten Jahren explodiert und damit auch der Aufwand, den die Unternehmen treiben müssen, um sie einzuhalten und gegenüber den Behörden den Nachweis ihrer Compliance zu erbringen.

Infolge der Regulierungswut werden die Lastenhefte immer dicker. Die Zahl der Anforderungen, die bei der Bearbeitung einer Spezifikation kommentiert werden müssen, habe sich in den letzten zehn Jahren mindestens verzehnfacht, sagte mir neulich der Manager eines Herstellers von Bremssystemen für Schienenfahrzeuge. Früher passte die Spezifikation auf eine CD, heute braucht man eine DVD, um alle Dokumente zu speichern. Aufgrund der vielen Köche unterschiedlicher Nationalitäten, die im Normierungsbrei herumrühren, sind vielen Normen interpretationsbedürftig, so dass unterschiedliche Auftraggeber daraus individuelle Anforderungen ableiten. Das führt dazu, dass die Spezifikationen für ein Bremssystem bei Multitender-Projekten, bei denen mehrer Konsortien auf dasselbe Projekt bieten, von Hersteller zu Hersteller unterschiedlich sein können.

Obwohl ein globales Geschäft, müssen die Schienenfahrzeughersteller außerdem einen Haufen unterschiedlicher nationaler Normen berücksichtigen. Das führt zu der absurden Situation, dass der neue ICE in Deutschland mangels Zulassung noch nicht ausgeliefert werden kann, während er in Spanien schon fährt – und das mit einer höheren Geschwindigkeit als er sie hierzulande je erreichen darf. Nirgendwo sei es schwieriger, ein neues Schienenfahrzeug zuzulassen als in Deutschland, meinte mein Gesprächspartner. Der aufwendige papier- bzw. dokumentenbasierte Zulassungsprozess lähme das Unternehmen und bedeute einen Wettbewerbsnachteil gegenüber Anbietern in aufstrebenden Ländern mit weniger Auflagen und geringeren bürokratischen Hürden.

Bimmelbahn — Mit freundlicher Genehmigung von Victor Habbick / FreeDigitalPhotos.net

Aufgrund der Vielzahl an zu beachtenden Anforderungen und Normen wird der Abstimmungsprozess mit den Schienenfahrzeugherstellern immer zeitaufwendiger. In diesem Prozess müssen die Lieferanten zu jeder Anforderung Stellung nehmen und definieren, ob und unter welchen Bedingungen sie sie erfüllen werden. Das geht dann ein paar Mal hin und her, bis die Bestellung unterschriftsreif ist. Um die Abstimmung zu beschleunigen, hat der Hersteller von Bremssystemen vor anderthalb Jahren ein datenbankgestütztes Anforderungsmanagement eingeführt, das künftig in die PLM-Lösung integriert werden soll.

Dank des Requirements Interchange Formats (RIF) bzw. des neuen ReqIF-Formats ist es eigentlich kein Problem mehr, Anforderungen mit den Auftraggebern in elektronischer Form auszutauschen, selbst wenn diese eine andere IT-Lösung für das Anforderungsmanagement einsetzen. Leider können die meisten Hersteller ihre Spezifikationen noch nicht im richtigen Format zur Verfügung stellen und die Anforderungsdaten der Zulieferer auch noch nicht elektronisch weiter verarbeiten. Die Schienenfahrzeugindustrie fährt hier im Vergleich zu anderen Branchen mit dem Bummelzug. Selbst die Deutsche Bahn hat selbst erst vor kurzem ein datenbankgestütztes Anforderungsmanagement eingeführt.

Ich möchte deshalb an dieser Stelle ausdrücklich den Appell des Unternehmens an die Auftraggeber unterstützen, mit den Zulieferern beim Anforderungsmanagement an einem Schienenstrang zu ziehen. Sonst stehen bald noch mehr nagelneue Schienenfahrzeuge nutzlos auf dem Abstellgleis. Und an die Politiker sei bei der Gelegenheit der Appell gerichtet, bei der Normierung ab und zu mal die Notbremse zu ziehen und die eine oder andere nutzlose Norm auch wieder zu streichen.

Requirements Engineering besser integrieren

Das Anforderungsmanagement ist nach einhelliger Auffassung von Praktikern und von Fachleuten aus Forschung und Lehre das A und O des Systems Engineerings (SE). Dabei ist es nicht damit getan, die Anforderungen am Anfang der Systementwicklung einmalig zu erfassen und zu bewerten – sie können sich im Laufe der Entwicklung nämlich verändern und müssen deshalb über ihren gesamten Lebenszyklus einem konsequenten Änderungsmanagement unterworfen werden. Aus diesem Grunde plädieren viele PLM-Hersteller für die Einbettung des Anforderungsmanagements in das Product Lifecycle Management (PLM) bzw. die entsprechenden PLM-Lösungen, mit denen die mechanischen und mechatronischen Komponenten verwaltet werden, die diese Anforderungen letztlich in entsprechende Funktionen umsetzen.

Das Plädoyer klingt plausibel, lässt sich in der Praxis aber nicht so einfach befolgen. Zunächst einmal sind die Menschen, die sich in den Unternehmen mit der Erfassung, Bewertung und Dokumentation von Systemanforderungen beschäftigen, ein besonderer Schlag, der mit PLM (noch?) nicht viel anzufangen weiß. Wer sie näher kennen lernen möchte, dem sei der Besuch der REConf empfohlen – der europaweit bedeutendsten Tagung zum Thema Requirements Engineering (RE). Sie fand neulich zum 12. Mal in München statt, ohne dass die PLM-Welt davon groß Notiz nahm. Zu meinem Erstaunen waren unter den immerhin 40 Ausstellern nur zwei namhafte PLM-Hersteller zu finden, von denen sich einer noch dazu als ALM-Anbieter (Application Lifecycle Management) präsentierte.

Zugegebenermaßen spielt das Thema Prozessintegration und PLM für die RE-Gemeinde derzeit noch eine untergeordnete Rolle. Sie hat andere Prioritäten: Erst einmal geht es darum, RE überhaupt nachhaltig in der Unternehmen zu verankern. Obwohl fast alle Unternehmen heute zumindest in ausgewählten Projekten RE anwenden und die Methode auf eine wachsende Akzeptanz stößt, ist sie in den meisten Fällen noch nicht genügend etabliert, wie eine Anwenderbefragung von REConf-Veranstalter HOOD ergeben hat. Zum Teil hängt das damit zusammen, dass das Management RE zwar gerne nachhaltig in der Organisation verankern würde, aber dafür kein zusätzliches Budget locker macht.

Der Ruf nach mehr Integration wird jedoch auch in der RE-Gemeinde lauter. Die Anwender, die an der Befragung teilnahmen, sind mit ihren RE-Tools nicht immer zufrieden. Sie wünschen sich bessere Schnittstellen zu den Werkzeugen und Systemen anderer Disziplinen, insbesondere zum Testmanagement, aber auch zu klassischen PLM-Funktionsbereichen wie Änderungsmanagement, Projektmanagement oder Dokumentengenerierung. Viele dieser Schnittstellen würden sich erübrigen, wenn man die Anforderungen direkt im PLM-Kontext erfasste und dokumentierte, aber das würde die etablierte Tool-Landschaft ziemlich über den Haufen werfen.

Wie sieht diese Landschaft aus? Die meist genutzten Anwendungen für RE und Anforderungsmanagement sind immer noch Excel und andere MS Office-Anwendungen, dicht gefolgt von IBM DOORS. Sie leisten den Anwendern zwar gute Dienste, weisen aber gerade in punkto Datenbankintegration und Prozessunterstützung Schwächen auf. Das erschwert zugleich den Austausch von Anforderungen zwischen Entwicklungspartnern, noch dazu wenn sie andere RE-Tools einsetzen. Abhilfe soll jetzt der ReqIF-Standard schaffen, den einige Tool-Hersteller bereits implementiert haben und den auch die PLM-Anbieter nutzen können, um Anforderungen standardbasiert aus den RE-Werkzeugen zu importieren bzw. an sie zu exportieren.

Denn eins ist klar: PLM wird die bestehenden RE-Werkzeuge auf absehbare Zeit nicht ersetzten, sondern allenfalls ergänzen. Einkauf, Entwicklung und anderen Abteilungen haben unterschiedliche Sichten auf die Anforderungen und nutzen unterschiedliche Anwendungen, um diese Sichten darzustellen. Wichtig ist jedoch aus Prozesssicht, dass zumindest die kritischen Anforderungen in der PLM-Umgebung wandern, um sie dort mit anderen Objekten verknüpfen und ihre Änderungsgeschichte nachvollziehen zu können. Dafür müssen die PLM-Anbieter neben eigenen Anforderungsmanagement-Funktionen entsprechende Integrationen bereit stellen.

Systems Engineering und der Innovationseffet

Elektronik und Software sind zum Motor der Innovation geworden – nicht nur im Automobil, sondern auch in vielen anderen Produkten. Und wie beim Billard stößt eine Innovation die andere an, auch wenn die Effets nicht immer vorhersehbar ist. Die softe Revolution erlaubt die schnelle Integration von zusätzlichen Funktionen, die den Produktlebenszyklus verlängern, und erleichtern gleichzeitig die funktionale Differenzierung der Produktpalette. Wie viel Pferdestärken ein Motor auf die Straße bringt, das hängt heute auch und vor allem von der eingebetteten Software ab.

In einem Fahrzeug der Oberklasse stecken inzwischen mehr Zeilen Programmcode als in manchem PLM-System. Die eigentliche Herausforderung ist jedoch nicht die Menge an Software, die sich wesentlich schneller entwickeln lässt als andere Produktbestandteile, sondern das perfekte Zusammenspiel von Software, Elektrik/Elektronik und Mechanik. Ihre Abstimmung erfordert neue Werkzeuge, Methoden und Prozesse für die interdisziplinäre Produktentwicklung. Systems Engineering (SE) heißt das Schlagwort, das in aller Munde ist, auch wenn jeder SE-Experte es etwas anders definiert.

Verwunderlich ist die Definitionsvielfalt nicht, denn letztlich geht es genau darum: Erst einmal eine gemeinsame Sprache zu finden. Eine gemeinsame Sprache, mit der man komplexe Produkte als Gesamtsystem beschreiben und überprüfen kann, unabhängig davon, wie und mit welchen Werkzeugen die beschriebenen Funktionen und Eigenschaften nachher umgesetzt werden. Eine Sprache, die es den unterschiedlichen Disziplinen erlaubt, ein gemeinsames Verständnis für die bestehenden Abhängigkeiten zwischen Anforderungen, Funktionen, Bauteilen etc. zu entwickeln und gerade bei Änderungen einfacher miteinander zu kommunizieren. Sozusagen ein Esperanto für die Produktentwicklung.

Ganz gleich welche Sprache(n) und Sprachwerkzeuge zum Einsatz kommen, müssen sie in die Product Lifecycle Management-Lösungen integriert werden, um die beschriebenen Anforderungen und die daraus abgeleiteten Funktionen und Eigenschaften des Produkts über den gesamten Entwicklungsprozess verfolgen und die Wechselwirkungen von Änderungen beurteilen zu können. In diesem Sinne ist das Systems Engineering zum Motor für die Innovation der PLM-Technologie geworden, die lange Zeit einseitig auf die Datenverwaltung und Prozessteuerung in der Mechanikentwicklung fokussiert war. Die meisten PLM-Lösungen unterstützen heute ein disziplinenübergreifendes Anforderungs-Management und ermöglichen die Abbildung einer funktionalen Sicht auf das Produkt.

Anforderungen abzubilden und in Beziehung zu anderen Anforderungen, Funktionen, Bauteilen etc. zu setzen, ist weniger eine technische Herausforderung. Die PLM-Datenmodelle sind dafür ausreichend flexibel. Die Kunst besteht darin, dies so zu tun, dass die Systeme für die Anwender noch bedienbar sind. Oder anders ausgedrückt: Zu vermeiden, dass man den Teufel mit dem Belzebub austreibt. Schließlich soll das Systems Engineering die Komplexität der Produktentwicklung besser beherrschbar zu machen. Wenn die IT-Werkzeuge zur Unterstützung der Systementwicklung dadurch so komplex werden, dass sie für die Anwender kaum noch zu beherrschen sind, ist nichts gewonnen.

Die PLM-Hersteller müssen sich darüber Gedanken machen, wie sie die Definition der Beziehungen zwischen Anforderungen und anderen PLM-Objekten und vor allem die Visualisierung der komplexen Zusammenhänge besser unterstützen. Die Anwender benötigen komfortable grafische Eingabehilfen und neue Peripheriegeräte mit taktilen Oberflächen, um die Beziehungsgeflechte großformatig darstellen und mit ihnen direkt interagieren zu können. Mit anderen Worten genau die Art von Produkten, deren Entwicklung ein interdisziplinäres Vorgehen im Sinne des Systems Engineering erfordert.