Requirements-Engineering mit Word und Excel – Teil IV

Nachdem wir in den letzten Beiträgen die Spezifikationen und ihre Organisation besprochen haben, komme ich nun zum Thema Word und die Arbeit mit Spalten.

Tabellen in Word

Wenn ihr mit Word arbeitet, legt eine simple, pragmatische Tabelle an. Ich empfehle hierbei sehr, mit vier Spalten zu arbeiten (und nicht im Excel-View):

Die erste Spalte ist der Requirements-Text, das heißt das Statement. Die zweite Spalte ist der Requirements-Typ, handelt es sich also um eine Bemerkung zu einer Dokumentenanforderung, eine Überschrift, die Dokumentenanforderung per se etc. Die dritte Spalte ist der aktuelle Status, beispielsweise: „Noch nicht angefasst“, „In Arbeit“, „In Review“ oder „Freigegeben“.

Die vierte Spalte beinhaltet den Test-Level. Ich empfehle diese Spalte ausdrücklich, auch wenn ich sie selten sehe. Aber es gehört sich für einen System-Ingenieur, dass er für Kollegen auf der Testseite auch Vorschläge macht, auf welcher Ebene sie eine Anforderung testen können.

Diese vierte Spalte hat aber noch einen anderen Hintergrund, den ich in anderen Episoden bereits erklärt habe. Ganz kurz zusammengefasst: Wenn ich Schwierigkeiten habe, dem Systemtester hier zu sagen, auf welcher Ebene er das bitte testen soll, dann weiß ich, dass ich meine Anforderung schlecht geschrieben und z.B. zwei Anforderungen in einen Satz gepackt habe. Für System-Ingenieure ist diese Spalte also extrem vorteilhaft.

Legt einfach diese vier Spalten in einem Kapitel an und arbeitet damit – aber ohne Prosa zu verwenden! Wenn ihr mit Word arbeitet, verleitet dies oftmals und ganz schnell zu Prosa. Ihr solltet aber unbedingt die Requirements-Engineering-Grammatik benutzen, um die Sätze entsprechend zu strukturieren.

Die Requirements-Engineering-Grammatik

In dieser Grammatik findet ihr drei bzw. vier Level: Am Anfang steht meist die sogenannte „Condition“, also eine Kondition, die in einem When-Statement formuliert wird, z.B. „wenn die Temperatur über 80 Grad steigt, muss das System das Ventil öffnen“. Das kommt bei einem Anforderungssatz nicht immer vor, wichtig ist aber, dass ihr das reinschreiben könnt, wenn es vorliegt.

Das zweite Level ist das „Objekt“, also das, was ich in diesem Satz bezeichne, an wen ich diese Anforderung richte. In dem Beispielsatz war es “das System”.

Dann könnt ihr einen sogenannten „Schweregrad“ der Anforderung definieren. Typischerweise haben wir drei verschiedene Ebenen: Ein „muss“ bedeutet eine absolut klare und hundertprozentige Vorgabe. Trotz aller unterschiedlichen Definitionen anderer Level gibt es immer dieses „muss“, das heißt, die Anforderung ist zu 100 Prozent zu erfüllen.

„Sollte“ und „kann“ sind weitere Möglichkeiten, die Firmen nutzen – manche haben auch vier Level. „Sollte“ bedeutet, etwas zu einem hohen Grad zu erfüllen, wobei diese Anforderung aber auch eine ähnlich gelagerte Lösung sein kann. Und „Kann“ ist eine Empfehlung, die erfolgen kann, aber nicht muss.

In der Requirements-Grammatik folgt dann noch die Aktion, z.B. „das Ventil öffnen“. Insgesamt haben wir also die Kondition, das Objekt, die Einstufung und die Aktion.

Chris Rupp hat ein sehr gutes Buch dazu geschrieben, das kann ich euch nur wärmstens empfehlen. Alternativ könnt ihr auch im Netz nach „Requirements-Struktur“ googeln.

Es hat mehrere Gründe, warum mir das hier wichtig ist. Zum einen sind Anforderungen interpretierbar – gerade, wenn wir sie verschriftlichen. Durch den Satzbau der Requirements-Engineering-Grammatik haben wir die Möglichkeit, Anforderungen viel, viel klarer zu formulieren und auch immer nur eine Anforderung anzubringen.

Ich weiß, dass sich das Dokument später durchaus blöd liest, weil jeder Satz genau die gleiche Form hat – aber wir schreiben ja keinen unterhaltenden Roman, sondern versuchen, ein technisches Problem zu spezifizieren. Und dafür macht diese Grammatik sehr viel Sinn.

Zum anderen hat sie den großen Vorteil, dass wir unsere Testbarkeit erhöhen können, wenn wir sie einsetzen. So kann auch ein System- oder Softwaretester relativ klar einen Testfall definieren:

Er erhöht z.B. die Temperatur auf 79 Grad, wobei das Ventil noch zu sein soll. Er erhöht die Temperatur auf 80 Grad – und das Ventil soll sich öffnen. Er höht die Temperatur auf 81 Grad, das Ventil soll auch hierbei geöffnet sein. Er kann also richtig simpel Grenztests machen etc. Ihr seht, diese Art der Grammatik macht sehr viel Sinn, also versucht, sie zu nutzen.

Keine Requirements-IDs in Word!

Und eines noch: Vergebt keine Requirements-IDs. Das ist zwar sehr verlockend, aber ihr werdet dadurch früher oder später in Teufels Küche kommen. Der Grund ist relativ einfach: Ihr setzt den ersten Schwung an Requirements auf, nummeriert sie durch und gebt das Dokument eurem Kollegen zum Review, der ein paar Änderungen und Ergänzungen macht.

Damit ist relativ klar, dass ihr jetzt noch ein paar Requirements irgendwo dazwischen setzen werdet – und diese dann aber die höchste Nummer haben, die aktuell letzte ID, die ihr vergebt.

Das geht dann noch ein paarmal so weiter und nach ein paar Monaten ist es unglaublich schwierig, herauszufinden, welche denn die letzte ID war, die vergeben worden ist. Die korrekte Nummerierung ist kaum noch herzustellen.

Tools setzen IDs automatisch, Word nun mal nicht. Dementsprechend kommt ihr da eigentlich nur total durcheinander. Das heißt, lasst es lieber weg.

Weitere wertvolle Tipps und Tricks u.a. zur Traceability beschreibe ich im nächsten Teil der Reihe.