Die Gefahren von veralteten Anforderungen – und was man dagegen tun kann

Nichts ist frustrierender, als nach stundenlanger Arbeit festzustellen, dass die Basis einer Arbeit veraltet war. Wenn dies in einem Review passiert, dann ist das ärgerlich. Wenn es sich jedoch um die teuer bezahlte Arbeit eines Zulieferers handelt, der eine Komponente auf der Basis von veralteten Anforderungen erstellt hat, dann kann dies eine kleine Firma in den Ruin treiben.

Veranstaltungshinweise: systems.camp Nord am 20.10. in Hamburg, Agile Systems Konferenz (ASK) am 24./25.10 in München,  Modeling Craftsmanship „Süd“ am 3.11. in Friedrichshafen.

Dies sind nur zwei der Gefahren, die von veralteten Anforderungen ausgehen. Doch was können wir tun, um solche Gefahren von Anfang an zu vermeiden?

Ursachenforschung

Für veraltete Anforderungen gibt es vielfältige Grunde, und dementsprechend auch vielfältige Maßnahmen. Außerdem trifft das hier gesagte nicht nur auf Anforderungen zu, sondern auch auch viele andere Artefakte der System- und Produktentwicklung.

Einer der häufigsten Ursachen ist: Copy & Paste. Auch wenn es den legitimen Einsatz davon gibt, so ist Kopieren eine Maßnahme, mit der Probleme schnell gelöst werden können – und die uns später teuer zu stehen kommen.

Mit Copy und Paste sind viele Probleme schnell gelöst – und kommen uns später teuer zu stehen. Twittern

Dabei geht es hier nicht nicht nur darum, Fragmente, oder Sätze von Anforderungen wiederzuverwenden. Im Prinzip ist auch das Herumschicken eines Anforderungsdokuments per E-Mail für ein Review eine Copy & Paste-Operation. Dies ist nur dann akzeptabel, wenn dafür gesorgt wird, dass die Reviewergebnisse zeitnah und diszipliniert wieder zusammengeführt werden. Doch das ist selten der Fall. Und da es heute genug Alternativen gibt, ist das Verschicken von Dokumenten für Reviews inzwischen als sträflich anzusehen.

Günstige Alternativen sind Wikis, oder online-Dokumentensysteme wie Google Docs. Wer mehr Komfort möchte, kann auf Systeme wie das Jama Review Center zurückgreifen

Single Source of Truth

Idealerweise gibt es in der Entwicklung eine zentrale Datenhaltung, auf der ohne Kopieren gearbeitet werden kann. In der Softwareentwicklung wird das in der Form von Code-Repositories schon lange praktiziert. Auch bei Anforderungen gibt es diese Möglichkeit schon seit Jahrzehnten, allerdings sind die entsprechenden Systeme in der Regel recht teuer. Doch gerade bei der Entwicklung komplexer Produkte im Team hat sich inzwischen herumgesprochen, dass eine entsprechende Datenhaltung unverzichtbar ist.

Doch gerade die älteren Werkzeuge für die professionelle Verwaltung von Anforderungen sind oft Insellösungen. Solange im System gearbeitet wird, ist die Welt in Ordnung. Doch in dem Moment, wo die Daten woanders weiterverarbeitet werden müssen, muss wieder kopiert werden. Dies kann mit Prozessen gelöst werden, das ist jedoch zeitaufwendig und fehleranfällig.Wenn so vorgegangen wird, dann ist es wichtig, zumindest eine Datenquelle als „Original“ zu deklarieren. Änderungen dürfen nur dort durchgeführt werden.

Auch hier gibt es wieder Komfortlösungen. Mit Integrations-Hubs können Daten automatisch und zuverlässig zwischen verschiedenen Werkzeugen synchronisiert werden. In dem Fall ist die Tatsache, dass kopiert wurde, kein Problem.

Schulden begleichen

In der Softwareentwicklung gibt es den Begriff „technische Schulden.“ Damit sind die Kosten gemeint, die durch eine schlechte, oder kurzfristige Umsetzung entstehen. Diese müssen in der Zukunft ausgeglichen werden. Wird das nicht getan, dann akkumulieren sich die Probleme. Wenn wir also ein Reviewdokument per E-Mail verschicken, entstehen Schulden. Diese müssen durch das disziplinierte Zurückführen der Reviewergebnisse beglichen werden.

Technische Schulden gibt es nicht nur in der Softwareentwicklung, sondern in jeder Entwicklung Twittern

Beim Arbeiten mit Anforderungen entstehen vielerlei Schulden. Diese zu begleichen macht keinen Spaß, ist aber wichtig. Zum Beispiel müssen verwaiste Elemente entweder neu zugeordnet oder gelöscht werden. Um dies jedoch auch erledigen zu können, brauchen wir eine gepflegte Traceability. Das Pflegen ist ebenfalls ein Teil davon, die Schulden zurückzuzahlen.

Probleme beschreiben

Auch wenn es eigentlich inzwischen eine Selbstverständlichkeit sein sollte: Gute Anforderungen beschreiben Probleme, keine Lösungen. Insbesondere technische Lösungen haben die Angewohnheit, mit der Zeit zu veralten. Wer also vor zehn Jahren einen VGA-Anschluss spezifiziert hat, und nicht eine „Schnittstelle zu einem Ausgabegerät,“ hat es heute mit einer veralteten Anforderung zu tun – ohne dass sich irgendetwas geändert haben muss.