Requirements Engineering Methoden

Vor einiger Zeit habe ich zusammen mit Chris Rupp und Frank Rachinger erforscht, ob sich ein Benutzerhandbuch als Spezifikation eignet (Vortragsfolien und Vortragsankündigung).
Die grundlegende Idee war, dass im Benutzerhandbuch eine funktionale Beschreibung aus Benutzersicht beschrieben ist - dieselbe Information, die schließlich auch in der Spezifikation landet. In unserem Artikel haben wir einen (theoretisch) gut funktionierenden Ansatz beschrieben, Aufwand zu sparen und dieselbe Information nur 1x zu dokumentieren - im Benutzerhandbuch.

In einem Projekt bei Spirit Link hatte ich jetzt die Gelegenheit, diesen Ansatz praktisch zu prüfen.
Vorweg: Wir haben uns zu Beginn dagegen entschieden, mit dem Benutzerhandbuch zu spezifizieren und zwei Dokumente geschrieben. Dennoch habe ich immer wieder an meine alten Forschungen gedacht und sie während des Projekts auf eine mögliche Umsetzung geprüft - immerhin hätte sie uns min. 30% des gesamten Aufwands gespart!

Wir haben uns aus folgenden Gründen dagegen entschieden:

• Benutzerhandbuch und Spezifikation haben unterschiedliche Leser.
  Das Benutzerhandbuch muss extrem gut verständlich sein, da es eine komplexe Applikation beschreibt und die Anwender teilweise wenig IT-Verständnis besitzen.
  Die Spezifikation ist für Projektbeteiligte (Auftraggeber und uns) und soll u. a. als formale Grundlage für die Weiterentwicklung dienen.
• Die Spezifikation ist eine formale Grundlage für Tests. Sie muss daher auf derselben detaillierten Abstraktionsebene komplett das gesamte System beschreiben.
• Die Sprache ist unterschiedlich - Prosa vs. Eindeutigkeit; Lesespaß vs. Exaktheit
• Die Detailtiefe ist unterschiedlich (z. B. keine Fehlerbeschreibung im Benutzerhandbuch, siehe Pyramide)

Gibt es andere Erfahrungen? Welche Voraussetzungen gibt es und wann sind diese tatsächlich einmal erfüllt?

Weiterer (in realen Projekten vielleicht nicht zu unterschätzender) Vorteil für das Handbuch als Spezifikation: Handbücher wären frühzeitig fertig und benötigten weniger nachgeschobene Last-Minute-Information. Bislang ist Dokumentation ja meist Stiefkind in den Projektprioritäten.

Nachteile: Ich arbeite in einer Umgebung, in der nicht-funktionale Anforderungen (Performance, Durchsatz, Uptime, Erweiterbarkeit, Hardware) stets signifikanten Anteil haben. Und auch je mehr echte Backend- oder Service-Funktionalität das Produkt beinhaltet, desto weniger würde ein Benutzerhandbuch als Anforderungsquelle abdecken.

Zweitens ist das Design der Benutzeroberfläche und der Interaktionsstruktur oft ein eigenständiger Vorgang, bei dem in mehreren Zyklen z. B. Prototypen erstellt, mit Anwendern evaluiert und entsprechend verändert werden, währenddessen andere Entwickler längst die darunter liegende Business-Logik implementieren, auf die das UI erst später aufgesetzt wird. Diesen zeitlichen Vorteil würde ich verlieren, würde ich erst auf die Fertigstellung des (doch sehr UI-abhängigen) Handbuchs warten, bevor ich mit dem Backend beginne.

Insgesamt halte ich daher die Idee für sehr reizvoll, aber in der Umsetzung höchstens für kleinere Projekte geeignet.