Geschrieben am

Requirements Management in Word — geht das?

word

Requirements Management in der Textverarbeitung

In Requirements Management Trainings kommt es nicht selten vor, dass ein Teilnehmer in die Runde fragt

„Entschuldigung, wenn ich das einfach mal so ungeniert frage, aber: Welches Tool nehmt ihr denn eigentlich alle so zum Requirements Management?“

Dann kommen ein paar Antworten („Enterprise Architect“, „Etwas selbst gebautes“, „Doors“) und einige schauen ganz sparsam auf ihre Fingerspitzen und sagen erst auf Nachfrage ganz leise und verschämt:

„Wir nehmen Word…“

Ich finde, ein Textverarbeitungsprogramm (ob es nun Microsoft Word ist oder Open Office oder Google Docs) ist als Requirements Management Werkzeug unter einigen Voraussetzungen gar nicht so verkehrt. Die Voraussetzungen möchte ich hier einmal etwas genauer betrachten:

  1. Der Product Lifecycle-Prozess ist (noch) nicht sehr stabil: Dedizierte Requirements Management-Tools lassen sich integrieren mit anderen Werkzeugen, die den Product Lifecycle-Prozess unterstützen. Hat der gelebte Product Lifecycle-Prozess noch keinen besonders stabilen Reifegrad, scheut man verständlicherweise den Aufwand, die Toolchain verbindlich zu integrieren. Damit fällt ein großer Vorteil eines Requirements Management-Werkzeugs weg.
  2. Nur einer spezifiziert: Einer der Vorteile von Requirements Management-Werkzeugen ist ihre Fähigkeit, Kollaboration zu ermöglichen, sprich: mehrere Leute arbeiten gleichzeitig an einem Dokument. Bei gängigen Textverarbeitungen wie Word, OpenOffice etc. ist das nicht so einfach möglich (eine Ausnahme bildet hier Google Docs, man erkauft sich damit aber, dass wichtige Dokumente ausschließlich in der Cloud liegen).
  3. Die Spezifikation ist nicht hochkomplex und erfordert nicht, dass sich viele Requirements auf jeweils andere viele Requirements beziehen.

Unter diesen Bedingungen lässt sich auch ein Textverarbeitungsprogramm einigermaßen brauchbar als Requirements Management Tool verwenden.

Allerdings ist dabei sehr zu empfehlen, dass sich der Autor durch einige selbst auferlegte Regeln ein wenig diszipliniert. Auf diese möchte ich im folgenden eingehen:

  1. Ein Anforderungsdokument benötigt eine Struktur: Wie auch immer sie gewählt wird, sie sollte ganz klar die Anforderungen von der restlichen „Prosa“ trennen, so dass ein Leser jederzeit weiß, was er gerade liest.
  2. Für die Anforderungen empfehle ich einen tabellarischen Ansatz (nicht unbedingt im Layout, nur vom Denken her). Jede Anforderung kann bspw. die folgenden Bestandteile haben:
    • Eindeutige ID: Wenn ich über eine Anforderung am Telefon mit jemandem anderen spreche (bspw. aus Gründen eines Reviews), dann ist es immer sehr hilfreich, die Anforderung simpel benennen zu können und nicht „die siebzehnte Zeile auf Seite 34“ sagen oder alles vorlesen zu müssen. Darüber hinaus können sich Anforderungen auf andere Anforderungen beziehen. Auch dann muss dieser Bezug einfach herstellbar sein.
    • Der Anforderungstext selbst.
    • Erläuterungen zum Anforderungstext: Wieso ist diese Anforderung da? An welche Fälle wurde hier gedacht? Wie sind bestimmte verwendete Fachworte zu verstehen usw.
    • Akzeptanzkriterium: Was sind die Bedingungen, unter denen die Anforderung als erfüllt angesehen wird?

Wenn eine Historie der Änderungen am Anforderungsdokument nötig ist, dann lässt sich entweder im „Ändern“-Modus arbeiten oder das Anforderungsdokument wird in einem Versionsverwaltungstool gehalten. Oder das Dokument wird — versehen mit unterschiedlichen Namen in Abhängigkeit vom Änderungsdatum — in einem Ordner mehrmals gespeichert.

Zugegeben, alles nicht schön und Requirements Management Tools sind natürlich die coolere Wahl — aber manchmal rechtfertigt das Ziel es einfach nicht, eine so große Umstellung.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.