Word considered harmful

Anforderungsmanagement (AM) mit Word und anderen Vertretern der Office Tools Liga zu bewerkstelligen liegt nahe. Es sind bekannte Werkzeuge, sie sind praktisch überall verfügbar. Früher oder später kann es aber dazu kommen, dass Office Tools nicht als ausreichend erachtet werden. Oft ist das der Fall, wenn eine effiziente Entwicklungs-Methodik und eine höhere Automatisierung im AM nachgefragt werden. In dieser Situation kommen Lösungen ins Spiel, die spezialisiert für das Anforderungsmanagement entworfen wurden.

Der GOTO Streit

Eine legendäre Veröffentlichung in der Geschichte der Informatik ist der von Edsger W. Dijkstra 1968 veröffentlichte Beitrag „ Goto considered harmful“ [Dijkstra68]. Der Niederländer Dijkstra warnte in diesem Aufsatz vor der Verwendung von GOTO bei der Erstellung von Programmen. Er legte darin dar, dass die Nutzung sehr schnell zu komplexen, schwer nachvollziehbaren Programmstrukturen führt. Programme also, die unter Entwicklern als Spagetti-Code bezeichnet werden. In der Informatik wird die GOTO Diskussion als die Geburtsstunde des strukturierten Programmierens gesehen.

Dass es um das Thema seit Jahrzehnten nicht ruhig geworden ist, zeigt der Wikipedia Artikel:

https://de.wikipedia.org/wiki/Sprunganweisung#Umstrittene_Verwendung_von_GOTO

Was hat das GOTO Thema, bei dem es um Programmiersprachen geht, mit Anforderungsmanagement (AM) Tools zu tun?

Der AM Tool Streit ?

Ich meine, es gibt Parallelen zur Diskussion über AM Tools. Ein beliebtes Thema für Entwickler, die sich vertieft mit Anforderungsmanagement, Business-Analyse oder Ähnlichem beschäftigen, ist die Verwendung von Office Tools für das Anforderungsmanagement. In dieser Diskussion wird nicht selten die Frage gestellt, ob Office Applikationen wie Word und Excel ein ausreichendes Handwerkszeug für den Anforderungsentwicklungsprozess darstellen.

Word Nutzung als Qualitätsindikator für die AM Reife ?

Ähnlich wie sich Edgar Dijstra gegen die Verwendung von GOTO stellt, so stelle auch ich mich gegen eine Verwendung von „Word“ als zentrales AM Tool. Jedoch bin ich, aufgrund meiner Erfahrungen in zahlreichen Anwendungsfällen dieser Werkzeuge, weit entfernt von einem Verbot dieser Tools in Entwicklungsprojekten. Die Verwendung als primäres Erfassungs- und Verwaltungswerkzeug sollte aber gut überlegt sein. Anders als bei Programmcode wird die „Spagettihaftigkeit“ der Anforderungsdokumentation eher selten als Problem erkannt. Einmal gewählte Strukturen unter Zuhilfenahme von Überschriften, Aufzählungen etc. zementieren die Anforderungsdaten jedoch ein. Der Bezug zu späteren Bearbeitungsartefakten in Form von z.B. Stories oder Tasks bleibt verschwommen oder wird inkonsistent. Wer meint, das ist normal und muss in Kauf genommen werden, disqualifiziert sich für anspruchsvolle Entwicklungstätigkeiten, die robuste Software zum Ziel haben. Mag es bei Webseiten, PC Programmen und Smartphone Apps, dank einer Gewöhnung beim Benutzer, immer wieder mal zu verzeihlichen Abbrüchen und kleineren Fehlfunktionen kommen, so zeigt das Beispiel des Ariane 5 Jungfernflugs [Ariane5], bei dem es zu einem katastrophalen Programmabbruch kam, dass eine veraltete Anforderungsspezifikation und fälschlicherweise eingesparter Entwicklungsaufwand einen nicht unerheblichen Beitrag dazu leisten.

Trotzdem der Schwarmintelligenz folgen ?

Ein Blick auf die Statistik spricht zunächst gegen meine  “Anti-Word” Position. Betrachtet man die Auswertungen aus der Frauenhofer IESE Befragung RE-Kompass von 2015 [IESERE15], so spricht die Befragung nach den verwendeten Werkzeugtypen eine deutliche Sprache. Die Mehrheit der Befragten verwendet Office Software Lösungen. Sollte man einfach dieser „Schwarmintelligenz“ folgen?

Es gibt hier Parallelen zu der GOTO Diskussion, die in den 70er Jahren ihren Höhepunkt hatte. Erst durch Sprachen wie ALGOL, Pascal, Ada, die es zumindest schwer machten im „GOTO Style“ zu programmieren, wurde es möglich, strukturierte Ansätze zu verfolgen. Diese Ansätze wurden Stück für Stück von der Entwicklergemeinde angenommen. Sprachen wie Pascal und objektorientierte Sprachen wie Smalltalk verzichteten gar auf ein „GOTO“.

Ähnlich dieser Entwicklung wird das Anforderungsmanagement zunehmend strukturiert betrieben. So wie bei modernen Programmiersprachen und Entwicklungsumgebungen (Stichwort IDE), die syntaktischen Konzepte einen strukturierten und wartbaren Programmcode unterstützen, so unterstützen im Anforderungsmanagement auf den Anforderungsentwicklungsprozess hin spezialisierte AM Tools, strukturierte und wartbare Anforderungsdaten.

Das lässt sich u.a. an der Verwendung und Verbreitung von spezialisierten AM Werkzeugen ablesen. Betrachtet man die Verfügbarkeit verschiedener AM Lösungen im Markt für Software Werkzeuge, so gab es in den vergangenen Jahren eine immer größere Auswahl. Was auch zu sinkenden Lizenz- und Nutzungskosten führte. Diese Werkzeuge finden mehr und mehr Verwendung und verdrängen rein Office basiertes Anforderungsmanagement in vielen Projekten. Die IX Studien für Anforderungsmanagement aus den Jahren 2005 [IXRE05] und 2007 [IXRE07] belegen diesen langanhaltenden Trend. Der Trend hält bis heute an, wie dies der U.S. Analyst Gartner in seinem 2014 Report „Market Guide for Software Requirements Definition and Management Solutions“ [GartnerRM14] aufzeigt. Der Gartner Analyst Thomas E. Murphy spricht in seinem Report IT Manager an und listet viele Werkzeuge auf, die in der IT orientierten Softwareentwicklung weite Verbreitung finden.

Office als ökologische Nische

Bei kleinen Ein-Personen-Projekten ist für die Anforderungs- und Konzeptarbeit das Office Toolset sicherlich ausreichend. Analog einer kleinen Visual Basic Programmierung, die auch ohne streng durchdachtes Code Design und mit Unterstützung einiger GOTO‘s ihren Dienst leistet.

Es gibt jedoch auch Fälle, die unter falschen Annahmen auf Office Lösungen setzen, oft in der vergeblichen Hoffnung, dass diese dann auch skalieren, wenn das Projekt ein ungeahntes Wachstum erreicht. Andere werden einfach überrascht von Engpässen, hohen Arbeitsaufwänden oder nicht umsetzbaren Bedürfnissen mit einem bis dato gut funktionierenden Office Anforderungsmanagement.

Flucht vom Planet der Dokumente

Irgendwann ist der Zeitpunkt gekommen aus dieser unwirtlich gewordenen Umgebung aufzubrechen. Die Auswahl eines AM Tools und eine Migration der Anforderungsdaten wird immer unausweichlicher.

In einem der nächsten Blogs beschäftige ich mich daher eingehender mit Word Importen und der strukturierten Ablage von Anforderungen. Dabei werden die Tools Polarion RM und IBM Rational DNG unter die Lupe genommen.

[Ariane5]
https://de.wikipedia.org/wiki/Ariane_5#Fehlgeschlagener_Erstflug
[Dijkstra68]
Edsger W. Dijkstra: Go To Statement Considered Harmful. In: Communications of the ACM. Vol. 11, No. 3, März 1968, S. 147–148
[GartnerRM14]
Thomas E. Murphy: Market Guide for Software Requirements Definition and Management Solutions. 7. Oktober 2014 ID:00235237
[GOTOWik]
https://de.wikipedia.org/wiki/Sprunganweisung#Umstrittene_Verwendung_von_GOTO  14.August 2015 (18:36)
[IESERE15]
Adam,Seyff,Wünch: RE-KOMPASS 2014/15 2015 Fraunhofer IESE, HOOD GmbH & Universität Zürich
[IXRE05]
Kress, Stevenson, Wiebel, Hood, Versteegen: Requirements Engineering Methoden und Techniken, Einführungsszenarien und Werkzeuge im Vergleich, iX Studie Anforderungsmanagement. Heise, 2005, ISBN 978-3-936931-19-8
[IXRE07]
Hood, C.; Mühlbauer, S.; Rupp Ch.; Versteegen, G.: iX Studie 01/2007 Anforderungsmanagement. 2. erweiterte Auflage, Heise Zeitschriften Verlag
[MISRA12]
Guidelines for the Use of the C Language in Critical Systems, ISBN 978-1-906400-10-1 (paperback), ISBN 978-1-906400-11-8 (PDF), March 2013