1. Klären Sie die Ebenen von Anforderungen!
In vielen Projekten entdecke ich während Reviews und Audits vielfach redundante Beschreibungen in fachlichen Konzepten, groben Anforderungen, detaillierten Anforderungen, technischen Konzepten, u.v.m. Diese mehrfach dokumentierten und teils auch mehrfach ermittelten Informationen können teilweise durch eine von Beginn an durchdachte Dokumentenlandschaft vermieden werden. Beginnen Sie sehr früh, bevor die erste Person anfängt erste Anforderungen zu formulieren, mit der Festlegung von deutlich voneinander abgestuften Anforderungsebenen. Dazu führe ich sehr gerne einen kleinen Workshop zur Klärung der Dokumentenlandschaft durch. Während des Workshops zeigen Sie ebenso die mit Anforderungen verbundenen (u.U. nachvollziehbar verfolgten) Informationen auf. Klären Sie die Ebenen von Anforderungen (z.B. Grobkonzept und Feinspezifikation) in Ihrem Projekt immer inklusive exemplarischer Verdeutlichungen mit einem Beispiel. Vermitteln Sie die definierte Dokumentenlandschaft dann an das Projektteam.
2. Reden hilft beim Kommunizieren! ;-)
Ich erlebe es häufig, dass Anforderungen ausschließlich mittels schriftlicher Dokumentation kommuniziert werden. Jemand erfasst sein Anforderungsdokument und sendet es an die beteiligten Reviewer. Diese senden die Anmerkungen zum Dokument per Email. Der Autor arbeitet die Anpassungswünsche ein und versendet es an die Entwicklungsabteilung. Die Wahrscheinlichkeit, dass die Reviewer und Entwickler ein sehr realistisches Bild der Anforderungen – zumindest für etwas komplexere Vorhaben – erhalten ist bestenfalls mittel bis gering. Kommunizieren Sie Ihre Anforderungen daher immer zusätzlich in einem Anforderungs-Workshop, um Diskussionen gezielt zu entfachen. Die Anforderungen werden typischerweise dadurch nur besser.
3. Einschränkung der Sprache!
Mit eines der größten Probleme in der Kommunikation – nicht nur bezogen auf Anforderungen – sind uneindeutige Formulierungen. Sie sind nicht nur irreführend für die Abnehmer (z.B. Architekten, Entwickler, Tester) und führend zu falschen Realisierungen. Uneindeutige Formulierungen erschweren während des Requirements Engineerings zudem den Fortschritt und sind Aufwandsfresser in der täglichen Projektarbeit. Das zu verfolgende Ziel für die Anforderungsformulierung sowie für die Kommunikation in Workshops sollte sein, von Beginn an einen reduzierten Sprachschatz zu verwenden (und diesen in einem Glossar festzulegen). Das bedeutet, auch wenn es eloquent erscheinen mag, Synonyme und Parabeln zu nutzen – für eine zielgerichtete Kommunikation sind sie nicht förderlich. Versuchen Sie, wenn auch nicht schriftlich in einem Glossar dokumentiert, immer identische Formulierungen, Prozesswörter und Fachbegriffe zu verwenden, um so schneller ein gemeinsames Verständnis zu erlangen. Mein Leitsatz heißt dabei: Nicht den Literatur-Nobelpreis gewinnen, sondern eine gescheite Anforderungsbasis erstellen!
4. Beschreiben Sie bis zu dem Punkt, ab dem es unwichtig wird!
Ich habe schon sehr häufig versucht zu vermitteln, wann denn Grobanforderungen nun inhaltlich tief genug spezifiziert sind oder bis zu welcher Informationstiefe eine technische Anforderungsspezifikation genau detailliert werden muss. Aus meiner Sicht ist eine weitreichend zutreffende Definition kaum möglich, weil Einflussfaktoren die eine klare Vorgabe unterbinden wie beispielsweise interne/externe Realisierung, Wissensstand der beteiligten, Neuentwicklung/Weiterentwicklung, Kritikalitätsstufe des Systems, usw. berücksichtigt werden müssen.,. Beschreiben Sie daher die Anforderungen genau so weit, bis Ihnen egal ist, was Sie in der Software realisiert bekommen (dies jedoch vor dem Hintergrund der obigen Ebenendefinition – siehe Punkt 1.). Das bedeutet, in einem Anforderungsdokument kommen unterschiedlich detaillierte Anforderungen vor, weil unterschiedliche Kapitel (z.B. unterschiedliche Use Cases) unterschiedlich „wichtig“ sind. Teils wird im Requirements Engineering empfohlen, in einem Anforderungsdokument die gleiche Detailtiefe an Informationen einzuhalten. Ich halte dies für aufwandszehrend und praxisfremd. Das aus meiner Sicht pragmatische Vorgehen ist, den Aufwand lieber an den wichtigen Stellen zu investieren.
5. Weniger ist mehr!
In vielen Projekten wird von Beginn an zu viel eingeplant. Das Ergebnis ist, dass viele Anforderungen auf der Strecke bleiben, obwohl viel Zeit in deren Ermittlung und Dokumentation geflossen ist. Diesem typischen Vorgehen möchte ich insofern gerade nicht folgen, als der 5. Erfolgsfaktor leer bleibt und wir uns den vier obigen Punkten intensiver widmen. :-)