Requirements-Engineering mit Word und Excel – Teil III

Klickt auf die Links, um den ersten und zweiten Teil dieser Reihe zum Requirements-Engineering mit Word und Excel zu lesen.

Kommen wir in diesem Teil der Reihe nun auf die Organisation der Spezifikationen zu sprechen. Bei diesem Thema kommen fast automatisch die entsprechenden Tools ins Spiel. Meine erste Empfehlung vorweg:

Besser Word anstelle von Excel verwenden!

Wenn ihr keine Requirements-Engineering-Werkzeuge habt, nutzt lieber Word als Excel. Mit jahrelanger Erfahrung möchte ich mich wirklich nachdrücklich dafür aussprechen.

Der Hintergrund ist relativ einfach. Man kann in Excel zwar recht schnell viele (Unter-)Tabellen produzieren und gleichzeitig über diverse Makros auch noch eine „Pseudo-Traceability“ einbauen. Doch meiner Meinung nach geht Excel an dieser Stelle auch ganz schnell nach hinten los.

Es gibt zunächst einen ganz pragmatischen Grund, warum Excel nicht gut funktioniert: Wir können keine Bilder in die Excel-Tabellen kopieren. Wenn ich aber ein gutes beschreibendes Bild für mein System habe, ist es natürlich mehr als blöd, wenn ich es in der Spezifikation nicht darstellen kann.

Hinzu kommt, dass der Ausdruck bzw. der PDF-Export einer Excel-Tabelle beispielsweise für Kunden oder einen Dritten bedeutend aufwändiger ist als bei Word. Daher also meine Empfehlung aus der Praxis: Nutzt lieber Word, dort könnt ihr schließlich auch mit Spalten arbeiten.

Modularisierung der Spezifikationen

Meine zweite große Empfehlung: Eine Modularisierung. Versucht, eure Spezifikationen zu modularisieren. Nehmt ein Word-Dokument und sammelt dort das Inhaltsverzeichnis und alle dokumentenspezifischen Informationen für die Spezifikation.

Legt zudem eigene Doc-Files für die ganzen relevanten einzelnen Kapitel an. Nehmt euch dafür ein wenig Zeit und schaut mit Sinn und Verstand, was zusammen in ein Word-Dokument gehört. Nicht jedes Unterkapitel gehört hier in ein Doc-File, doch clever aufbereitet ist dieser modulare Aufbau sehr wertvoll.

Das Ganze hat zwei große Vorteile: Zum einen können mehrere Kollegen gleichzeitig an unterschiedlichen Kapiteln arbeiten, ohne dass sie sich gegenseitig behindern, alles doppeln und hinterher alle Änderungen aufwändig in einem Dokument zusammenführen müssen.

Zweitens ist Word so deutlich schneller. Gerade wenn ihr diese Dateien auf einem Firmen-Netzlaufwerk liegen habt, kann es sehr mühselig sein, ein 20 oder 30 Megabyte großes Word-Dokument überhaupt zu öffnen. Mit den Kapitel-Dokumenten habt ihr wesentlich angenehmere Größen und könnt flexibler arbeiten.

“Versionierung”

Modularisierung macht also extrem viel Sinn. Ein weiterer Aspekt, der damit zusammenhängt, ist die „Versionierung“, also die Nachverfolgung der Text-Revisionen: Achtet darauf, dass ihr bei euren Files immer die Möglichkeit habt, alte Stände wieder zurückzuholen!

Das hat den großen Vorteil, dass ihr zu jedem Zeitpunkt schauen könnt, wann ihr ein Requirement entfernt oder warum ihr ein neues hinzugefügt habt. Gleichzeitig habt ihr natürlich auch Sicherungskopien, wenn diese Form des Versionen-Managements auf euren Servern bzw. in eurer Firmen-Infrastruktur liegt und Backups produziert werden.

Wie ihr dieses Management handhabt, kann variieren. Das Einfachste ist, alles über Subversion und entsprechende Free Tools abzubilden. Das integriert sich sehr schön in die klassische Explorer-Sicht von Windows oder in den Finder auf Macs.

Damit habt ihr die Möglichkeit, alles effizient zu versionieren und müsst zudem jedes Mal ein- und auschecken, sodass ihr auch Kommentare hinterlassen und erläutern könnt, warum es diese neue Version gibt, welche Änderungen vorliegen etc.

Vergleichbarkeit der Strukturen

Ein weiterer Vorteil dieser Organisation von Spezifikationen ist die Vergleichbarkeit der Strukturen – wenn diese gut abgesprochen sind. Ich kann nur empfehlen, eine einheitliche Dokumentenstruktur zu vereinbaren. So bleiben alle Files ähnlich und werden auch gleich verständlich sein.

Ihr könnt hierfür gerne die Templates für die System-Requirements und System-Architecture-Spezifikationen nehmen, die ich in den Podcast-Episode 29 und Episode 30 online gestellt habe. Passt diese einfach für eure Bedürfnisse an.

Wenn Vergleichbarkeit vorliegt, könnt ihr eure Erfahrungen auch mit anderen Teams austauschen. Wenn ihr beispielsweise immer das gleiche Kapitel zu einer Basistechnologie habt, die ihr über alle verschiedenen Produkte in eurem Unternehmen einsetzt, dann könnt ihr dieses als feste Grundlage verwenden: „Das ist unser Kapitel für die Anforderungen an die Basistechnologie XY. Alle verweisen immer auf dieses Kapitel und verändern es nur gemeinsam.“

Schließlich hat diese Vergleichbarkeit auch den Vorteil, dass Kollegen, die das reviewen, es viel schneller verstehen, weil sie die Struktur und den Sinn dahinter kennen.

Im nächsten Teil werden wir uns mit den Tabellenformen in Word beschäftigen.