Beiträge

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.

Requirements-Engineering mit Word und Excel – Teil V

Nachdem ich im letzten Teil die Tabellenstruktur in Word und die Requirements-Engineering-Grammatik detailliert beschrieben habe, kommen wir in diesem Teil zu Traceability, Verantwortlichkeiten & Co.

Mit Word ohne Traceability & Reports arbeiten

Mir ist durchaus bewusst, dass Traceability wichtig ist. Mit den Requirements-Engineering-Werkzeugen wenden wir sie auch an. Wenn ihr aber mit Word arbeitet, ist Traceability kaum einbaubar. Das ist einfach Fakt.

Dabei ist diese Möglichkeit der Nachverfolgung durchaus wertvoll. Wenn z.B. oben im Lastenheft eine Anforderung vom Kunden steht, beispielsweise „Das System muss bei 80 Grad abschalten“, so habt ihr sofort eine vernünftige Anforderungsbeschreibung: „Wenn die Temperatur über 80 Grad steigt oder wenn die Temperatur bei 80 Grad ist, muss das System das Ventil öffnen.“

Daraus entwickeln sich zudem verschiedene Anforderungen für die verschiedenen Domains. Also für die Software, für die Elektronik, die Mechanik, Satzanforderungen zu Öffnungsgeschwindigkeiten, Winkeln, Messungen und so weiter.

Aus diesem einen banalen Satz, den ich auf der Systemebene habe, können unten eine ganze Menge Requirements herausfallen. Genau das ist Traceability: Wir können nachvollziehen, wo das alles herkommt. Was ist aus dieser Lastenheftanforderung eigentlich ganz unten auf der Domain-Ebene in den jeweiligen mechatronischen Bereichen geworden?

Oder auch andersrum: Der Kollege aus der Konstruktion kann sagen: „Woher kommt die Anforderung über eine Öffnungsgeschwindigkeit in meinem konstruktiven Ventil? Und wieso ist das so, wie es da drinsteht?“ Diese Möglichkeit der Nachvollziehbarkeit ist mit Requirements-Engineering-Werkzeugen gegeben.

Sie mit Word herzustellen, ist wirklich furchtbar schwierig, ganz zu schweigen von Excel. Ich rate ja ohnehin von Excel ab, denn auch hier verleitet Excel einen geradezu dazu, Traceability zu versuchen – was im totalen Chaos enden wird. Tut euch den Gefallen und lasst es.

Ein weiterer Teil, der fehlt, wenn ihr nur Word nutzt, sind die Reports. Ihr könnt zwar auch in Word ein paar Skripte laufen lassen. Wenn wir aber Requirements-Management-Werkzeuge einsetzen, können wir zudem sehr ausführliche Reports machen.

Mit solchen Funktionen lassen sich Fehler sehr gut herausfischen, z.B. Requirements, die nicht verlinkt oder noch nicht zugeordnet sind und vieles mehr. Hier gibt es diverse Möglichkeiten, Reports zu machen.

In Word solltet ihr das aber bitte nicht machen: Keine IDs, keine Traceability und versucht auch gar nicht erst, Reports aufzubauen.

Word – nicht selbstgebaute Word-Tools!

Als letzten „Bitte tut es nicht“-Punkt möchte ich noch Folgendes anbringen: Baut bitte keine eigenen Tools. Ich habe jetzt mittlerweile einige Firmen gesehen, die mit Word und Excel gearbeitet haben und dann anfingen, in Office ein paar Makros zu nutzen, um z.B. mit Visual Basic zu programmieren.

Einer fängt dann, das Ganze umzumodellieren und auf die Bedürfnisse des Requirements-Managements anzupassen – und somit, Tools zu bauen. Ganz ehrlich: Der Kauf von Lizenzen ist viel, viel günstiger, als wenn ein Kollege über drei Jahre hinweg versucht, etwas zusammenzubauen.

Und noch schlimmer: Es folgt immer die Erkenntnis, dass die eigenen Möglichkeiten am Ende sind und man jetzt eigentlich Dinge implementieren müsste, die das Ganze zu einer richtigen Tool-Suite machen. Also, das macht alles keinen Sinn.

Sagt lieber von Anfang an ganz klar: „Wir nutzen Word. Und wir nutzen es mit viel Sinn und Verstand und folgen den Empfehlungen – aber es wird niemals ein Requirements-Engineering-Tool werden.“ Es ist einfach Word und damit hat es sich.

Von Reviews, Verantwortlichkeiten & Freigaben

Ein weiterer Punkt, der die Organisation der Spezifikationen angeht, betrifft die Verantwortlichkeiten: Wer ist eigentlich für die Spezifikationen verantwortlich? Das ist gerade in diesem Kontext ein wichtiger Punkt und hat folgenden Hintergrund:

Wenn wir Requirements-Management-Werkzeuge einsetzen, gibt es Logins und damit eindeutige Benutzer. So etwas habt ihr bei Word aber nicht, jeder mit Zugriffsrechten auf das Laufwerk kann die Dateien öffnen, bearbeiten, umspeichern.

Dementsprechend macht es sehr viel Sinn, klare Rollen zu vergeben: Wer ist verantwortlich für das Dokument? Wer ist verantwortlich für die Freigabe etc.? Legt diese Rollen fest und haltet euch daran. So gibt es stets eine Person, die genau diese oder mehrere Rollen auf dem Hut hat und damit verantwortlich ist für das, was da geschieht.

Hier fällt auch das Thema Review hinein: Eine eurer stärksten Waffen, gerade wenn ihr Word nutzt und eben nicht Requirements-Management-Werkzeuge, sind Reviews. Sie sind elementar wichtig, wie ich bereits in der Podcast-Episode 006, „Geheimwaffe Reviews“, betont habe.

Ich kann auch hier wieder nur empfehlen, Reviews zu nutzen. Denn mit den Verantwortlichkeiten kommen hier auch die Freigaben hinzu: Nichts ist schlimmer, als Dokumente zu haben, die in irgendeinem Vorab-Stand hängen – gebt diese Dokumente frei!

Dafür könnt ihr wunderbar die Reviews nutzen: Sobald ihr ein Review gemacht und die Feedbacks eingebaut habt, ist es freigegeben, automatisch. Das ist eine relativ einfache Vereinbarung, die ihr mit allen Beteiligten treffen könnt.

Im nächsten Teil werde ich auf diese Vorteile und auch auf die Herausforderungen der Requirements-Engineering-Tools weiter eingehen.