Qualität von Pflichtenheften steigern
Gute Anforderungsdokumente schreiben ist eine nicht zu unterschätzende Herausforderung. Ausgehend vom aktuellen Stand werden Kriterien für ein gutes Anforderungsdokument aufgestellt, die als Ausgangspunkt für Prüfkriterien genutzt werden können.[/caption]Gute Anforderungsdokumente schreiben ist eine nicht zu unterschätzende Herausforderung. Ausgehend vom aktuellen Stand werden Kriterien für ein gutes Anforderungsdokument aufgestellt, die als Ausgangspunkt für Prüfkriterien genutzt werden können.

Begriff Anforderungsdokument

Wann ist ein Anforderungsdokument gut? Wie beurteile ich die Qualität eines Anforderungsdokumentes? Zuerst wäre es sicherlich hilfreich zu klären, was unter einem Anforderungsdokument zu verstehen ist.  Den Begriff gibt es schließlich so nicht: Pflichtenheft, Lastenheft, Grobkonzept, Feinkonzept sind bekannt, vielleicht auch das SRS (system requirements specification). Unter Anforderungsdokument sollen hier alle diese Ausprägungen zusammengefaßt werden, sofern sie das Ziel haben, entweder zu Beginn eines IT-Vorhabens als Vertragsbestandteil das zu bauende System (Zielsystem) zu beschreiben oder mit Abschluß des Vorhabens den aktuellen Stand des Zielsystems zu dokumentieren.

Anforderungsdokumente sind sehr verschieden

Analysiert man Anforderungsdokumente von verschiedenen Zulieferern, so stellt man schnell fest, daß diese sich sowohl strukturell als auch inhaltlich stark unterscheiden. Man könnte meinen, daß das in der Natur der Sache liegt, schließlich ist ja der Gegenstand verschieden – hier eine kaufmännische Software, dort eine Produktionsplanung. Doch selbst innerhalb einer Ausschreibung, also bei ein und demselben Vorhaben (Zielsystem), unterscheiden sich die Dokumente erheblich.  Innerhalb großer Unternehmen gibt es Versuche, die Dokumente zu vereinheitlichen, doch beschränken sich diese oft auf die Vorgabe einer Gliederung, die je nach Gegenstand mehr oder weniger paßt.

Liest man die Dokumente, dann stellt man fest:  Es gibt Dokumente, die sich flüssig herunterlesen. Andere Dokumente sind sperrig, also mühsam zu lesen. Und bei anderen Dokumenten wiederum denkt man an Erschwerniszuschlag für das Lesen desselben.

Wie auch immer sich das Dokument liest, oft hat man als Außenstehender nach dem Durcharbeiten den Eindruck, daß man nicht so recht weiß, worum es geht. Man muß das Dokument mehrfach lesen, ja regelrecht Forschungsarbeit betreiben, um zu verstehen, was geliefert werden soll. Meist geht das nicht ohne mehr oder weniger Rücksprache mit den Autoren. Je nach deren kommunikativer Kompetenz bleibt am Schluß oft ein mehr oder weniger gutes Gefühl.

Zielgruppe des Anforderungsdokumentes

Wann ist ein Anforderungsdokument nun gut? Man sollte das vom Ziel aus angehen, also sich klar machen, was die Empfänger des Dokumentes benötigen. Da gibt es hauptsächlich drei verschiedene Gruppen von Empfängern: Der Projektmanager des Projektlieferanten, die dort für die Entwicklung zuständigen Mitarbeiter (Softwarearchitekt, Entwickler, …) sowie die für den Test Verantwortlichen

Anforderungen an ein Anforderungsdokument

Prinzipiell sollte ein Anforderungsdokument nur fachlich beschreiben, was das Zielsystem leisten soll. Gern wird  statt dessen versucht, das Zielsystem in Form von technischen Lösungen zu beschreiben: In SAP-Sprech, TechSprech oder MyOwnSprech. Es ist jedoch unwahrscheinlich und zudem nicht nötig, daß Fachseiten die technischen Details der Umsetzung so gut kennen – sie haben eine andere Aufgabe. Dann aber Hände weg von TechSprech und Co! Auch der Projektmanager und die Tester kommen mit fachlich formulierten Anforderungsdokumenten wesentlich besser zurecht.

Betrachtet man die Struktur, dann muß ein Anforderungsdokument folgendes leisten: Zum einen muß es Orientierung geben. Ein umfangreiches Vorhaben erschließt sich nicht ohne weiteres! Es sollte also den Leser an die Hand nehmen und Schritt für Schritt so durch das Vorhaben führen, daß der Einarbeitungsaufwand für die Empfänger so gering wie möglich ist. Zum anderen sollte ein Anforderungsdokument aktiv die Arbeitsteilung unterstützen, d.h. es sollte so strukturiert sein, daß nicht alle Mitarbeiter alles gelesen haben müssen, um ihre Aufgabe erfolgreich erfüllen zu können.

Bezüglich der Inhalte sollte ein Anforderungsdokument nur das fachlich beschreiben, was benötigt wird – mehr nicht, aber auch nicht weniger! Das heißt, es muß beschrieben werden

• wer das Zielsystem benutzt (Nutzer)
• wie das Zielsystem mit anderen Systemen (Drittsysteme) wechselwirkt.
• wie das Zielsystem fachlich strukturiert ist.
• welche Funktionalität das System den unterschiedlichen Nutzern und Drittsystemen bereitstellt.
• wie den Nutzern bzw. Drittsystemen des Zielsystems die Funktionalität zugänglich gemacht werden soll.
• welche fachlichen Anforderungen das Zielsystem erfüllen muß.
• welche technischen Anforderungen das Zielsystem erfüllen muß, damit es zur Systemlandschaft paßt.

Wann ist ein Anforderungsdokument gut?

Ein gutes Anforderungsdokument stellt diese Information vollständig zur Verfügung, und zwar in einer Reihenfolge, die die Zielgruppe optimal in das Thema einführt. Es beschreibt die Funktionalität konsequent fachlich, also ohne auf technische Lösungen als „Beschreibungssprache“ (TechSprech) zurückzugreifen. Die Beschreibung ist angemessen, wenn ein Fachmann, welcher die Thematik nicht kennt, versteht, was geliefert werden soll. Das Dokument sollte so strukturiert sein, daß es die Spezialisierung fördert, also nicht alle Mitarbeiter alles gelesen haben müssen, um an der Umsetzung mitarbeiten zu können.

Gute Anforderungsdokumente schreiben – aber wie?

Wie kommt man zu so einem Anforderungsdokument? Das Ergebnisorientierte Verarbeiten von Anforderungen hat sich diesem Problem angenommen. Es zeigt, wie man effizient die Informationen des Kunden zu Anforderungen verarbeitet und ein Anforderungsdokument erarbeitet, welches beide Seiten, der Projektkunde und der Projektlieferant, abnehmen können.