Requirements-Engineering mit Word und Excel – Teil VI

Nachdem ich im letzten Teil schon einige Unterschiede zwischen Word und Requirements-Engineering-Tools angesprochen habe, möchte ich das jetzt weiter vertiefen. Was können wir eigentlich gewinnen, wenn wir auf ein Requirements-Tool umstellen?

Klare Organisation 

Wie ich beim letzten Mal schon angedeutet habe, gibt es durchaus einige Vorteile. Traceability haben wir bereits besprochen. Der zweite Vorteil sind die Reports: Ihr könnt relativ einfach Statistiken erzeugen, die in Review-Kontexten sehr hilfreich sind:

Wie viel Anforderungen haben wir? Wie viel Prozent der Anforderungen sind überhaupt verlinkt? Habe ich Anforderungen drin, die schwierig oder zu lang sind? Bei den Tools habt ihr eine vollautomatische Versions- und auch Freigabenkontrolle.

Im Hilti-Projekt, das ich ein Jahr lang als Mentor begleitet habe, wurde außerdem ein sogenanntes „Document of Truth“, also das „Dokument der Wahrheit“ geschaffen. Dort wurden die relevanten Inhalte gesammelt und nur diese haben dann auch gegolten. So haben wir das Lastenheft für das Produktmanagement erstellt und die Spezifikationen im Entwicklungsprojekt aufgebaut.

Einfache Wiederverwendung

Diese klare Organisation ist ebenso sinnvoll wie die viel einfachere Wiederverwendung: Modularisierung, Standardisierung und Vergleichbarkeit hin oder her, aber in der aktuellen Automobil-Industrie sind wir an einem Punkt, wo wir sozusagen aus dem Regal arbeiten:

Wenn wir ein neues System entwerfen, nehmen wir Requirements-Module aus einem „Regal“ und packen das alles in ein Dokument. Und das Thema „Change-Management“ ist mit Requirements-Engineering-Tools viel einfacher.

Wenn der Kunde mit einer Anforderungsänderung kommt, „Oh nein, das System muss bei 75 Grad schon abschalten“, könnt ihr das Werkzeug nutzen und die Konsequenzen im Change-Management viel, viel einfacher organisieren.

Das geht auch mit Word, aber es ist doch deutlich aufwändiger. Ihr gewinnt also durchaus eine Menge, wenn ihr ein Requirements-Engineering-Tool einsetzt. Aber ich möchte hier auch die großen Herausforderungen der Tools nicht verschweigen.

Aufwand und Kosten bei Tools

Zunächst muss klar sein, dass kein Tool eine Plug-and-Play-Lösung darstellt. Wenn ein Vertriebler euch das erzählt, werdet skeptisch. Requirements-Engineering-Tools sind sehr komplexe Werkzeuge, die bestimmte Anforderungen einhalten, funktional sein und Features bereitstellen müssen.

Wenn ihr diese Werkzeuge einsetzt, müsst ihr eine Infrastruktur dafür haben, eine Konfiguration dieser Werkzeuge etc. – es gibt kein Plug and Play, egal welches Werkzeug ihr nutzt! Fragt mal Konstrukteure, ob es ein Plug and Play für ihr CAD-Tool gibt? Die werden euch wahrscheinlich auslachen.

Ihr müsst immer davon ausgehen, dass ihr das Tool individuell auf eure Bedürfnisse anpassen und zudem alle Anforderungen und Bedürfnisse des Tools berücksichtigen müsst.

Ein weiterer wichtiger Punkt ist der Kostenpunkt Lizenzen. Es gibt unglaublich viele Lizenzmodelle bis hin zu teuren Premium-Modellen, je nachdem, wie groß eure Firma ist und ob dieser Tool-Hersteller überhaupt mit euch redet – manche tun dies erst ab einer Unternehmensgröße von zwei- bis fünftausend Mann. Es gibt andere, die da wesentlich flexibler sind und mir persönlich auch viel mehr liegen.

Mit einem Tool nicht zum Fool werden!

Generell solltet ihr euch an folgendes Sprichwort halten: „A Fool with a Tool is just a Fool, but the Tool makes the Disaster faster.“ Mit anderen Worten, ihr müsst euch bei drei elementaren Dingen Gedanken machen: Werkzeug, Methode, Inhalt.

Am Ende des Tages kommt es auf den Inhalt an. Die Methode ist wichtig, um diesen Inhalt zu schaffen. Und das Tool ist wichtig, um den Inhalt zu verwalten – aber ohne gescheiten Inhalt ist der Rest egal. Und man kann auch ein furchtbar teures Requirements-Engineering-Tool mit den pfiffigsten Features mit Blödsinn befüllen – und somit nichts gewinnen: Ich habe zwar ein teures Tool verwendet, aber trotzdem nur Müll drin.

Also, geht wirklich in euch und überlegt, ob ein Requirements-Engineering-Tool euch in eurem konkreten Fall wirklich hilft. Und wenn ihr euch dafür entscheidet, lasst euch Zeit bei der Wahl und dann bei der Umsetzung in eurem Projekt.

Meine Empfehlung als erfahrener Mentor diverser Firmen ist: Nehmt ein echtes Projekt, kein Ad-on-Projekt, an dem ihr das ausprobiert. Nehmt lieber ein echtes Projekt, das gerade in der Entwicklung ist, das wirklich den Bedarf hat – und gebt euch mindestens zwölf Monate Zeit, damit klar zu kommen. Alles andere ist Quatsch.

Zwölf Monate ist ein ganz typischer Zeitraum, um sich diesem Thema anständig zu nähern. Wir reden hier schließlich von Requirements-Engineering, egal auf welchem Level, in welcher Komplexität, in welchem Branchen-Kontext – das ist ein so großes Thema, das lässt sich nicht im Hau-Ruck-Verfahren handhaben.

Vergleicht es doch mit einem Marathon. Da würdet ihr auch nicht auf die Idee kommen, erst zwei Monate vorher mit dem Lauftraining zu beginnen. Das scheint jedem klar zu sein – im Requirements-Engineering glauben aber komischerweise viele, dass das in zwei Monaten funktionieren kann, einfach weil sie Profis sind.

Also, übernehmt euch nicht, geht vorsichtig, bewusst und mit genug Raum und Zeit vor. Denn ob mit Word oder mit einem Requirements-Engineering-Tool – ihr habt Großes vor und das will geplant sein.