Wer je mit Softwareentwicklung zu tun hatte, weiß, dass klare Anforderungen einer der kritischen Erfolgsfaktoren für das Gelingen eines Projekts sind. Leider kommt es immer wieder vor, dass nach einer vermeintlich erfolgreich abgeschlossenen Spezifikation noch Änderungen am System notwendig werden. Denn Systems verändern sich mit dem Markt und den geschäftlichen Anforderungen.

Das Problem: Ein Umbau droht schnell, aufwändiger zu werden als ein Neubau. Nachträgliche Änderungen hinsichtlich der Anforderungen oder Spezifikationen führen zu erheblichen Schwierigkeiten und Risiken in Projekten. Trotzdem werden sie oft stiefmütterlich behandelt oder sogar völlig ignoriert. Das Resultat sind entweder Lösungen, die Kundenbelange unzureichend widerspiegeln, oder aber zusätzliche Kosten, die am Ende möglicherweise sogar die anvisierten Vorteile der Software übersteigen. Wie lässt sich das vermeiden? Und wodurch entsteht der Änderungsbedarf eigentlich?

Ursachenforschung

In Softwareprojekten hat wohl jeder schon einmal die Frage vernommen: "Wieso ändert sich unsere Spezifikation immer noch? Ich dachte die Analyse sei abgeschlossen, und die Anforderungen seien abgenommen." Die Projektbeteiligten reagieren darauf meist mit einem Schulterzucken. Scheinbar entstehend Änderungen aus dem Nichts - ohne eine konkrete Kundenanfrage.

In einem klassischen Softwareprojekt erheben am Anfang die Business-Analysten im Rahmen einer Spezifikationsphase die Anforderungen, die sie dann dokumentieren, mit den Fachbereichen abstimmen und freigegeben. Diese Spezifikationen bilden die Basis, auf der Architekten, Softwareentwickler und Tester ihre Konzepte, ausführbaren Code oder Testfälle erstellen. Mit dieser Weiterverarbeitung werden die Anforderungen aber aus einem anderen Blickwinkel beleuchtet. Das führt unweigerlich dazu, dass Lücken, Widersprüche oder andere Mängel in den Anforderungen auftauchen.

Vier Tipps für die Softwareentwicklung
Nachträgliche Änderungen sind immer ein Ärgernis, doch in der Softwareentwicklung sind sie nie komplett auszuschließen. Dies ist kein Grund zu Verzweifeln, wenn man effizient und schnell darauf reagieren kann. Anstatt sich den Änderungen zu verweigern, sollten die Unternehmen besser nach Mitteln und Wegen suchen, wie sie schnell darauf reagieren zu können. Dazu im Folgenden vier Tipps:

Wehret den Anfängen
Die effektivste und wirtschaftlichste Möglichkeit, mit Änderungen umzugehen besteht darin, sie bereits im Vorfeld zu vermeiden. Das kann beispielsweise durch das Einholen von Feedback geschehen. Derart stabilisierte Anforderungen lassen sich frühzeitig nutzen, um in anderen Projekt-Teilteams, etwa Entwicklung oder Test, weiterführende Ergebnisse zu erzeugen. Feedback nur aufgrund von Reviews hilft vergleichsweise wenig.

Visualisierung und kurze Zyklen
Empfehlenswert ist es auch, Visualisierungen und Beispiele aus der Praxis zu nutzen. Modelle und Grafiken erhöhen die Verständlichkeit und lassen sich zudem relativ einfach konsistent halten. Fallbeispiele dienen der Veranschaulichung, vor allem auf Kundenseite, und beugen Missverständnissen vor. Durch kurze Zyklen zwischen der Spezifikation der Anforderung und deren Umsetzung sinkt zudem die Gefahr, dass Anforderungen "veralten".

Mitsprache der künftigen User
Die an der Anforderungsdefinition beteiligten Personen sollten möglichst áuch die sein, die später mit der Software arbeiten. Der direkte Bezug schafft Verantwortlichkeit und trägt enorm zur Qualität der Anforderungen bei. Lösungsorientierte Anforderungen sind meist besonders anfällig für Änderungen. Deshalb sollten von Lösung und Anforderung voneinander getrennt werden: Das dokumentierte "Was" ist deutlich stabiler als das festgehaltene "Wie". Auf keinen Fall darf die Dokumentation ausufern.

Formaler Änderungsprozess
Die meisten Projekte verfügen durchaus über einen definierten Prozess, wie sie mit neuen Anforderungen umgehen. Es hapert nur an der Integration der kontinuierlichen Weiterentwicklung von bereits dokumentierten Anforderungen. Grundvoraussetzung für ein Anfoderungs-Management ist es, den Überblick zu behalten, denn die ständige Verbesserungen führen zu einer hohen Dynamik in den dokumentierten Anforderungen.

Änderungen oder Qualitätsverlust

Zweifellos ist es illusorisch, zu glauben, ab einer bestimmten Projektgröße und -komplexität könne man die Anforderungen im Vorfeld noch lückenlos und interpretationsfrei dokumentieren. Vorbeugende Maßnahmen erhöhen zwar die Qualität der Anforderungen und minimieren damit das Risiko von Mängeln, doch völlig ausschließen können sie diese nicht. Trotzdem gibt es in vielen Projekten einfach keinen Prozess, um einmal abgenommene Anforderungen kontinuierlich zu verbessern. Wenn überhaupt, so beschränkt sich der Änderungsprozess auf gänzlich neue Anforderungen.

Die im Projektverlauf gewonnenen Erkenntnisse aller Beteiligten müssen aber zyklisch in die Anforderungen zurückfließen, um die festgestellten Qualitätsmängel zu beheben. Geschieht das nicht, entsteht eine Software, die zu einem guten Teil auf Annahmen des Entwicklungsteams basiert. Überspitzt ausgedrückt, heißt das: Es wird dem Zufall überlassen, welche Lösung der Kunde am Ende erhält. Im Extremfall bekommt er also keine brauchbare Lösung für seine eigentlichen Probleme.

Anstatt sich den Änderungen zu verweigern, sollten die Unternehmen besser nach Mitteln und Wegen suchen, wie sie schnell darauf reagieren zu können. Dazu im Folgenden vier Tipps:

Tipp: Wehret den Anfängen

Die effektivste und wirtschaftlichste Möglichkeit, mit Änderungen umzugehen besteht darin, sie bereits im Vorfeld zu vermeiden. Das kann beispielsweise durch das Einholen von Feedback geschehen. Derart stabilisierte Anforderungen lassen sich frühzeitig nutzen, um in anderen Projekt-Teilteams, etwa Entwicklung oder Test, weiterführende Ergebnisse zu erzeugen. Feedback nur aufgrund von Reviews hilft vergleichsweise wenig.

Tipp: Visualisierung und kurze Zyklen

Empfehlenswert ist es auch, Visualisierungen und Beispiele aus der Praxis zu nutzen. Modelle und Grafiken erhöhen die Verständlichkeit und lassen sich zudem relativ einfach konsistent halten. Fallbeispiele dienen der Veranschaulichung, vor allem auf Kundenseite, und beugen Missverständnissen vor. Durch kurze Zyklen zwischen der Spezifikation der Anforderung und deren Umsetzung sinkt zudem die Gefahr, dass Anforderungen "veralten".

Tipp: Mitsprache der künftigen User

Die an der Anforderungsdefinition beteiligten Personen sollten möglichst áuch die sein, die später mit der Software arbeiten. Der direkte Bezug schafft Verantwortlichkeit und trägt enorm zur Qualität der Anforderungen bei.

Lösungsorientierte Anforderungen sind meist besonders anfällig für Änderungen. Deshalb sollten von Lösung und Anforderung voneinander getrennt werden: Das dokumentierte "Was" ist deutlich stabiler als das festgehaltene "Wie". Auf keinen Fall darf die Dokumentation ausufern; die Verhältnismäßigkeit muss gewahrt bleiben. Sind Anforderungen eindeutig und verständlich zu Papier gebracht, lassen sich "formale Schwächen" durchaus verkraften. Es ist wichtige, echten Mehrwert zu schaffen, statt einen Schönheitspreis zu gewinnen.

Tipp: Formaler Änderungsprozess

Die meisten Projekte verfügen durchaus über einen definierten Prozess, wie sie mit neuen Anforderungen umgehen. Es hapert nur an der Integration der kontinuierlichen Weiterentwicklung von bereits dokumentierten Anforderungen. Grundvoraussetzung für ein Anfoderungs-Management ist es, den Überblick zu behalten, denn die ständige Verbesserungen führen zu einer hohen Dynamik in den dokumentierten Anforderungen.

Um dieser Dynamik Herr zu werden, müssen die Grundlagen zur Verwaltung der Anforderungen implementiert sein. Dazu zählen Konzepte

• für die Versionierung von Anforderungen,

• zum Erstellen von Baselines und

• um erfolgte Änderung nachzuverfolgen.

Außerdem müssen die nötigen Ressourcen bereitstehen. Die kontinuierliche Weiterentwicklung der Anforderungen bedingt, dass Business-Analysten und Fachbereichsverantwortliche nicht nur am Anfang eines Projekes zur Verfügung stehen, sondern es bis zum Ende der Entwicklungsphase begleiten.

Der Prozess der Anforderungsentwicklung darf niemanden ausgrenzen. Jeder Projektbeteiligte darf Verbesserungsvorschläge anbringen. Das scheint auf den ersten Blick unkontrollierten Änderungen Tür und Tor zu öffnen. Doch in der Praxis hat sich gezeigt, dass die unterschiedlichen Sichtweisen die Qualität der Anforderungen maßgeblich erhöhen. Zudem bedarf es der Implementierung eines formalen Freigabeprozesses: Erst wenn der Kunde die verbesserten Anforderungen geprüft und fachlich für einwandfrei bewertet hat, können die Änderungen in den Entwicklungsprozess einfließen. Tauchen Mängel an bereits implementierten Anforderungen auf, ist zu prüfen, inwieweit sich eine Anpassung auf den aktuell implementieren Softwarestand auswirken würde. Wenn das der Fall ist, wird entweder eine Korrektur in der Software notwendig, oder aber eine Diskussion mit dem Kunden ist fällig, in der es um alternative Lösungsszenarien geht.

Kampf den goldenen Henkeln

Unabdingbar ist es daher, Transparenz zu schaffen: Alle Änderungen an der Spezifikation müssen zu jedem Zeitpunkt für alle Projektbeteiligten einsehbar und nachvollziehbar sein. Nur können die unterschiedlichen Projekt-Teilteams zeitnah auf Änderungen reagieren. Außerdem lässt sich so auch der Umfang der Änderungen besser kontrollieren; das ist unabdingbar, um Aufwand und Nutzen gegeneinander abwägen zu können.

Eine potentielle Gefahr bei der kontinuierlichen Verbesserungen der Anforderungen ist die, dass sich über diesen Weg neue Anforderungen - die berühmten "goldenen Henkel" in den Umfang der zu erstellenden Software einschleichen. Jeder Änderungsbedarf an bestehenden Anforderung ist deshalb kritisch darauf zu überprüfen. (qua)

So kommen Sie groß raus ... oder?
Sie möchten, dass Ihre Projekte zäh verlaufen, weil Sie sich damit in der Firma profilieren können? Dann folgen Sie den Ratschlägen von Jürgen Rohr.

Tipp 1
Setzen Sie die Verantwortlichen unter Termindruck. Mit engen Terminen stellen Sie sicher, dass möglichst wenige Betroffene ins Boot geholt werden. Damit vermeiden Sie die sowieso unnötigen Diskussionen um Meinungs- sowie Wahrnehmungsunterschiede.

Tipp 2
Starten Sie mit einer problem-orientierten Ist-Analyse. Fragen Sie immer zuerst danach, was nicht gut läuft. Damit fokussieren Sie die Aufmerksamkeit aller Beteiligten auf die Schwächen der Organisation. Sie stellen sicher, dass niemand auf die Idee kommt, sich auf den Erfolgen der Vergangenheit auszuruhen.

Tipp 3
Geben Sie möglichst kein zusammenfassendes Feedback. Halten Sie die Betroffenen im Unklaren. Das fördert zwar die Gerüchteküche, hält aber den Änderungsaufwand für die Konzeptionierer gering. Sie erhalten schon mit dem ersten Wurf ein Konzept aus einem Guss - ohne lästige und zeitaufwändige Anpassung an unterschiedliche Wahrnehmungen der Beteiligten.

Tipp 4
Lassen Sie das Konzept ohne Beteiligung der Betroffenen ausarbeiten. Hier können Sie Aufwand und Budget einsparen. Jeder Betroffene wird mit seinen individuellen Ansichten sowieso nur das Konzept verwässern. Außerdem: Wenn ein Außenstehender den Sollzustand konzipiert, kommt endlich frischer Wind in die Organisation.

Tipp 5
Vermitteln Sie das Konzept frontal mit mindestens 100 PowerPoint Slides. Hier gilt: Je mehr Input, desto weniger lästige Rückfragen. Halten Sie das Präsentationstempo hoch. Planen Sie ja keine Zeit für die Diskussion ein. Das Konzept steht. Basta!

Tipp 6
Planen Sie keine Zeit für die Überarbeitung des Konzepts ein. Das wäre ja noch schöner: Sie planen knapp bei Budget und Terminen und wollen sich den Erfolg nicht durch unplanbare Überarbeitungsaufwände vermiesen lassen. Denn jede Überarbeitungsschleife würde den schönen Entwurf zerstören.

Tipp 7
Schränken Sie die Zugriffsrechte auf neue Tools möglichst stark ein. Ganz wichtig: Wenn Sie im Rahmen der Organisationsentwicklung neue Werkzeuge (zum Beispiel ein IT-System) einführen, achten Sie darauf, dass niemand außer den Konzeptionierern in der Lage ist, die Werkzeuge anzupassen.

Tipp 8
Lassen Sie die Betroffenen beim Umsetzen des Konzepts alleine. In diesem Punkt gilt das Motto: Die Leute werden sich schon umgewöhnen. Durch die Unterstützung während der Umsetzungsphase könnte wiederum das sorgfältig ausgearbeitete Konzept verwässert werden. Das ist unbedingt zu vermeiden.

Tipp 9
Vermeiden Sie persönlichen Kontakt zwischen den Beteiligten. Stellen Sie sich vor, was Sie hier an Reisekosten einsparen können. Diskussionen können auch per E-Mail geführt werden. Das spart richtig Geld.

Tipp 10
Betrachten Sie jegliches Feedback als persönliche Kritik. Wenn jemand mit einem Feedback zu Ihnen kommt, will er damit eigentlich sagen, dass Sie Ihre Arbeit nicht richtig gemacht haben. Das wirkt sich schlecht auf Ihr Selbstwertgefühl aus.