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.