Cargolifter setzt auf Requirements Management

Die Lust oder Last mit dem Pflichtenheft

09.03.2001
Die Cargolifter AG vertraut bei der Entwicklung ihres Leichter-als-Luft-Transportgeräts auf eine alte Tugend, die viele Unternehmen sträflich missachten: das konsequente Management von Anforderungen. Ein DV-gestütztes Werkzeug hilft den Luftschiffbauern dabei, die rund 30 000 "Requirements-Objekte" zu verwalten. CW-Bericht, Bernd Seidel

Ein Fluggerät mit einer Länge von 260 und einem Durchmesser von 65 Metern transportiert Lasten von 160 Tonnen mit einem Volumen von 50 Metern Länge sowie acht mal acht Metern Breite. Währenddessen sind Geschwindigkeiten von 80 bis 110 Kilometern pro Stunde möglich. Die Reichweite beträgt bis zu 10000 Kilometern. Dies ist weder ein Auszug aus Daniel Düsentriebs Erfinderbuch noch der Beginn eines Fantasy-Romans. Die Kennzahlen beschreiben ein Projekt, das immer wieder für Schlagzeilen sorgt: den Bau des Cargolifter 160 (CL 160).

Die genannten Werte sind einige der Haupt-Requirements des Luftschiffs; dazu gehören neben den technischen auch monetäre und terminliche Kenngrößen: Im Jahr 2003 wird, so steht es in den Requirements, der erste Prototyp seine Tests absolvieren, und im Geschäftsjahr 2004/05 soll die Serienproduktion beginnen. Insgesamt beschreiben zurzeit 28 500 Requirements-Objekte Anforderungen, die an das Luftschiff gestellt werden.

Bei der Festlegung von Requirements geht es nicht nur darum, Ausgangssituation und Anforderungen zu dokumentieren, sondern insbesondere darum, die Abweichungen vom ursprünglichen Entwurf festzuhalten. Diese entstehen häufig während des Designs oder sogar erst beim Bau. Ein Pflichtenheft, das zu diesem Zeitpunkt nicht den aktuellen Stand des Projekts wiedergibt, ist wertlos. Viele Vorhaben fangen dann wieder bei null an, weil sie keine iterativen Entwicklungsprozesse unterstützen. Die vorhandene Dokumentation muss unter erheblichem Aufwand auf einen aktuellen Stand gebracht werden. Gregory Opas, bei Cargolifter für das Projekt Produktdaten-Management (PDM) zuständig, bringt es auf den Punkt: "Ohne ein IT-basiertes Requirement-Tool lassen sich Anforderungen für ein Projekt solchen Ausmaßes nicht mehr verwalten."

Entscheidung kurz und schmerzlos

Diese Gefahr hat man bei Cargolifter frühzeitig erkannt. Die Engineering-Spezialisten wurden beauftragt, ein System aufzubauen, mit dem sich diese Hürde nehmen ließe. Sie entschieden sich für das Tool "Doors" (Dynamic Object Oriented Requirements System) des englischen Herstellers QSS, das später auch bei der Dokumentation von Anforderungen an IT-Systeme und deren Entwicklung eingesetzt werden soll.

Der Entscheidungsprozess für das QSS-Werkzeug war kurz und schmerzlos. Gerade, als Cargolifter ein Tool suchte, hatte das International Council on Systems Engineering (Incose) einen Produktvergleich veröffentlicht. Doors erfüllte die für Cargolifter ausschlaggebenden Kriterien. Dazu gehörten die Anzahl zu verwaltender Objekte sowie die Möglichkeit, aus dem Web heraus mit dem Werkzeug zu arbeiten. Außerdem passte das Tool in Bezug auf die Unternehmensgröße sowie die Zahl der Requirements und der Benutzer, die bei derzeit 80 liegt.

"Die Incose-Studie war für die Auswahl sehr hilfreich, da wir keine Zeit hatten, selbst einen detaillierten Auswahlprozess zu führen", erinnert sich Opas. "Requisit Pro" von Rational käme grundsätzlich zwar auch in Frage, sei aber eher für die Entwicklung von Software konzipiert; Doors erschien hier flexibler. Zudem habe das Branchen-Know-how der QSS-Consultants überzeugen können.

Abweichungen transparent nachvollziehen

Tools à la Doors helfen dabei, Abweichungen vom ursprünglichen Konzept transparent nachzuvollziehen, erläutert Volker Stammnitz, Head of Systems Engineering bei der Cargolifter Development GmbH in Briesen-Brand. Die geänderten Parameter könnten per Workflow an die Verantwortlichen weitergeleitet und mittels Schnittstellen automatisch an PDM- oder Controlling-Systeme übergeben werden.

Die Arbeit mit solch einem Werkzeug ähnelt auf den ersten Blick der Erfassung von Texten in einem Textverarbeitungssystem. In ein Maskenfeld wird die Bezeichnung für ein Requirement als Überschrift eingegeben - gepaart mit Anweisungen für den Workflow, beispielsweise darüber, wer die Requirements abzeichnen soll. Doors stellt vordefinierte Schablonen bereit, um die Anforderungen zu erfassen. Die Templates wurden entsprechend den firmeneigenen Qualitätsrichtlinien, dem Workflow und den Vorgaben der Luftfahrtbehörden sowie der QSS-Consultants strukturiert. Die Requirements lassen sich über mehrere Ebenen - ähnlich einer Baumstruktur oder Stückliste - hierarchisch verfeinern.

Aus dem Doors-Dokument kann dann über Links in ausführlichere Beschreibungen verzweigt werden, die sich etwa in über- oder auch untergeordneten Requirements-Dokumenten befinden. Zusätzlich ist es möglich, via Hyperlinks auf Dateien zu springen, die in einem "Word"-Dokument oder in einer "Excel"-Tabelle liegen. Doors ermöglicht das Management von Änderungen sowohl im Strukturdokument als auch in der zugehörigen "Support Documentation": Ergänzungen in dem einen werden in der anderen sichtbar; dadurch entsteht eine Versionsverwaltung.

Änderungen von Anforderungen schlagen sich allerdings nicht nur im Requirements-Werkzeug nieder, sondern haben Seiteneffekte auf angrenzende Systeme - auch bei den Geschäftspartnern, die an dem Produkt mitarbeiten. Dadurch entstehen Schnittstellen zum Marketing, zur Produktion und zum Engineering.

Cargolifter hat Doors mit dem PDM-System "Windchill" von PTC integriert. Diese Software basiert auf einer offenen Java-Architektur und bietet eine eigene Middleware namens "Info-Engine". Mittels eines C-Service in der Middleware lässt sich die Doors-Datenbank ansprechen, Modelle und Beschreibungen können geladen werden.

"Mit der Kopplung von Doors und Windchill bilden wir unsere iterative Entwicklung ab", erklärt Stammnitz. So lasse sich aus den Anforderungen in Doors auf Produktteile verzweigen, die im PDM gespeichert sind. Umgekehrt sei es möglich, Produktteile im PDM aufzurufen und von dort zu den Requirements in Doors zu springen, um darin zu navigieren.

Kein System von der Stange

Ein solches System gibt es natürlich nicht von der Stange: Angepasst werden mussten Templates für Dokumentation, Reporting, Suchroutinen und Checklisten. Zu den Kosten lässt Stammnitz nur so viel heraus: Die Aufwände für Beratung und Lizenzen sind etwa gleich.

Mit Tools allein ist es aber nicht getan, denn mit der Erfassung und dem Management von Requirements, ganz gleich ob für IT-Systeme oder für industriell gefertigte Produkte, verhält es sich wie mit den "allseits geliebten" Tests, berichten Stammnitz und Opas; beide seien bei Ingenieuren, Entwicklern und Topmanagement gleichermaßen wenig geschätzt.

"Detaillierte Pflichtenhefte, die ständig gepflegt werden, sowie Tests kosten Geld und bremsen möglicherweise den Fortschritt eines Vorhabens", monieren die beiden Ingenieure. Die Produktivität bei der "Ersterfassung" mit Hilfe von Doors sinke zunächst um durchschnittlich 20 Prozent: Grund dafür seien der Aufwand für Schulung, Einarbeitung sowie Installation und "Customization". Doch diese Mehrausgaben zahlen sich bei jedem Change Request und bei künftigen Projekten aus. Laut Stammnitz lassen sich pro Änderung 20 bis 25 Prozent Zeit einsparen, wenn das Tool vernünftig eingesetzt wird.

"Das mussten unser Management sowie die Entwickler und Designer erst lernen", wissen Stammnitz und Opas. Sie leisteten harte Überzeugungsarbeit bei den Entwicklungsingenieuren: "Die ersten Arbeiten zum Cargolifter kamen aus dem universitären Bereich", berichten sie, "es gab also ursprünglich keinen definierten Designprozess". Die Anforderungen seien anfangs auf Zuruf entstanden, das heißt: Sie waren nicht oder nur schlecht dokumentiert.

Mit Zuckerbrot und Peitsche

Um ein Produkt wie den CL 160 zu bauen, das kommerziell vermarktet werden soll, sind solche Methoden und Arbeitsweisen sicher ungeeignet. Trotzdem sei das Requirements-Engineering auch heute noch für viele Firmen Neuland, wundern sich Stammnitz und Opas. Aus diesem Grund fehlten manchmal die Erfahrungen mit Requirements und deren Nachvollziehbarkeit.

Mitarbeiter zu motivieren, ein Tool à la Doors auch zu benutzen, ist eine Kunst, die mit Zuckerbrot und Peitsche ausgeübt werden muss - "Management by Objectives" nennt Opas die Strategie: Auf der einen Seite sei der Nutzen für den Einzelnen, das Team und das Projekt aufzuzeigen, andererseits müsse die Verwendung des Werkzeugs als Qualitätsstandard vorgeschrieben werden.

Bei Cargolifter ist in einem Qualitätshandbuch festgelegt, wie projektrelevante Vorgänge zu dokumentieren sind. Aber das reicht nicht immer aus: "Entwickler sind Individualisten. Sanfter Druck wirkt manchmal Wunder", beschreibt Opas die Motivationsinstrumente. Dazu gehöre beispielsweise, Fehler aufzuzeigen, die passierten, weil das Tool nicht benutzt wurde. Schließlich wolle keiner derjenige sein, dessen Komponente nachher nicht passe, weil er geänderte Anforderungen nicht mitbekommen habe.

Ein spektakuläres Vorhaben

Auf dem ehemaligen Militärgelände Briesen-Brand, etwa 60 Kilometer südlich von Berlin, entsteht der "fliegende Kran", der ab 2003 Dienst tun soll. Interesse an diesem Transportmittel für schwere, sperrige Gegenständen haben beispielsweise der Maschinen- und Anlagenbau, der Bereich "Modular Bauen" (Container und größer), die Öl-, Offshore- und Automobilindustrie sowie humanitäre Hilfsorganisationen und die UN. Marktstudien zufolge besteht weltweit ein potenzielles Transportvolumen von mehr als drei Millionen Tonnen. Das entspricht einem Bedarf an etwa 200 Luftschiffen mit der Kapazität des CL 160. Neben der Cargolifter AG (www.cargolifter.de) mit ihren derzeit etwa 350 Mitarbeitern in Unternehmenstöchtern wie Cargolifter Development GmbH, Cargolifter Network GmbH und Cargolifter Communications GmbH, arbeiten auch Kooperationspartner, darunter Conti, EADS, MAN Technologie, Rolls Royce Turbomeca, Syntec und Vickers, am Cargolifter-Projekt.

Tipps zur Einführung

Folgende Hinweise können, das hat die Erfahrung der Cargolifter-Ingenieure gezeigt, bei der Einführung eines Requirements-Management-Systems hilfreich sein:

- Das System durch internes Projekt-Marketing bekannt machen.

- Erfahrungsberichte veröffentlichen, damit nicht jeder dieselben Fehler macht.

- "Management by walking around": Die Anwender aktiv befragen, wie die Arbeit mit dem System läuft.

- Den Aufwand nicht unterschätzen: Der Betrieb eines Requirement-Tools für 80 User bedarf einer oder besser zweier Vollzeitkräfte für den Support.

- Das System-Management sorgfältig planen.

- Kulturelle Veränderung vorantreiben mit dem Ziel, dass bereits während der Design-Phase ein Softwarewerkzeug eingesetzt wird.

- Poweruser identifizieren, die andere motivieren.

- Akzeptieren, dass man am Anfang vielleicht Zeit verliert, die aber spätestens bei der ersten Änderung wieder gewonnen werden kann.

- Die Möglichkeiten des Team-Designs vermitteln.