"Man muss sich einfache Ziele setzen, dann kann man sich komplizierte Umwege erlauben."
(Charles de Gaulle)

Änderungsanforderungen

Änderungsanforderungen (engl.: Change Requests) sind die Tücke eines jeden Software-Projekts. Wenn Sie bisher alles richtig gemacht haben und optimal im Plan liegen und endlich die Fachlichkeit und die Technik im Griff haben, kommt der Kunde jetzt garantiert mit neuen Ideen, damit Sie als Anbieter auch garantiert ins Schleudern kommen. Hier danke ich einem Kunden für den ehrlichen Spruch: "Kunde sein verdirbt den Charakter"!

Das Problem ist ja nicht die neue Idee, der geänderte Geschäftsprozess oder der bisher so zurückhaltende Anwender, der nun anhand der Prototypen die neuen technischen Möglichkeiten entdeckt hat - das Problem ist der Umgang damit! Ist die neue Idee nun wirklich neu oder ist darüber nicht schon ganz häufig gesprochen worden und das war schon immer so gemeint? Hat sich der Geschäftsprozess wirklich geändert oder haben Sie als Anbieter den Kunden nur nicht richtig verstanden? Ist der bisher so zurückhaltende Anwender wirklich nie gefragt worden und hat jetzt erst vom neuen System erfahren? Wenn Sie als Anbieter die Anforderungen verbindlich fixiert, umfangreich analysiert und detailiert spezifiziert haben und wenn Sie all diese Prozesse in Stufen mit Zwischenabnahmen und Protokollen begleitet haben und wenn Sie wirklich nur einen einzigen Ansprechpartner haben, der seinerseits genau einen benannten Vertreter für jeden Akteur hat und wenn alle Dokumente und Prototypen all diesen Vertretern vorgeführt wurden, dann können Sie sehr genau feststellen, welche Anforderung wirklich neu oder geändert ist.

Sie können diese Änderungsanforderung "oben" in Ihren Prozess einstreuen und beobachten, welche Auswirkungen sie worauf hat: Passt die Änderungsanforderung überhaupt ins Hauptziel? Welcher Akteur stellt diese Änderungsanforderung? Welche Anforderungen kamen noch von diesem Akteur? Auf welchen Übersichts-AF und auf welche Funktions-AF wirkt sich diese Änderungsanforderung aus? Welche Detail-AF müssen mit welchen Testfällen wie geändert werden? Wie ändert sich die Qualität der Software? Welche Daten werden dabei neu entstehen oder können verworfen werden? Was bedeutet dies für das Datenmodell? Welche Geschäftslogik muss geändert oder ergänzt oder verworfen werden? Welche Teile des Datenmodells und der Geschäftslogik und welche Teile in anderen tiern sind bereits implementiert und müssen wie umcodiert werden? Welche Team-Mitglieder sind also betroffen, wofür sind diese in nächster Zeit eingeplant und welchen Stundensatz haben sie? Welche Dokumentation muss in welchem Umfang geändert werden und welche Teile des evtl. bereits begonnenen Handbuchs müssen wie geändert werden?

Wie viel Zeit wird also alles in allem für diese Änderung benötigt und was kostet diese letztendlich? Wird das Produkt vielleicht sogar billiger, weil die Änderung eine Reduzierung mit sich bringt, die eintritt, bevor mit den betroffenen Stellen überhaupt irgendjemand begonnen hat? Eine Änderungsanforderung kann durchaus auch zur Minderung statt zur Mehrung führen, auch wenn dies eher untypisch ist.

Wenn Sie als Anbieter Ihrem Kunden also nachweisen können, dass es sich um eine Änderung handelt und vorrechnen können, welchen Einfluss diese Änderung auf Zeit und Kosten hat, dann kann der Kunde für sich abwägen, ob er die Änderung dennoch möchte oder nicht. Vielleicht möchte der Kunde die Änderung dann ja auch in einer späteren Version, zusammen mit einigen anderen Änderungen. Es soll nämlich schon Projekte gegeben haben, die vor lauter Änderungsanforderungen nie fertig geworden sind! Eine Änderung in einer Folgeversion ist zwar in der Regel teurer als eine Änderung in der aktuellen Version, aber eine Version später auf den Markt zu bringen als ursprünglich geplant und versprochen kann noch viel teurer werden!

Hier sei nochmals erwähnt, dass eine Änderungsanforderung natürlich umso teurer ist, je später sie in das Projekt "einschlägt". In der Pre-Analyse ist eine Änderung gedankenschnell vollzogen, in der Analyse kostet die Änderung der bereits erstellten Dokumentteile vielleicht einen Tag, nach dem Design kann es schon eine Woche sein und wenn weite Teile bereits codiert und im Handbuch verewigt sind, wird es bestimmt schon ein Monat sein. Ist das Produkt erst im Markt und muss in der nächsten Version kompatibel geändert werden, bedeutet es vielleicht ein halbes Jahr!

Ich spreche hier die ganze Zeit von "Änderungsanforderungen", aber wenn man präzise sein möchte, muss man diese auch mal sprachlich von "Anforderungsänderungen" abgrenzen: Eine Änderungsanforderung ist die Anforderung zu einer Änderung (der Software), also eine neue Anforderung, die neu zur Anforderungsliste hinzukommt und meist spät direkt an die Software gestellt wird ("In diesem Fenster muss man aber auch die Menge eingeben können." - "Seit wann denn das?" - "Seit jetzt!").

Eine Anforderungsänderung ist die Änderung einer Anforderung, also bestand die Anforderung bereits ("Hier muss aber mehr als ein Dokument hinterlegt werden können." - "Bisher haben Sie aber immer nur von dem Dokument gesprochen." - "Das war aber falsch, denn wir haben meistens mehrere.").

Der Unterschied erscheint marginal, weil die Software ohnehin in beiden Fällen geändert werden muss, aber einmal kommmt eine Anforderung hinzu, was eine neue Anforderungsnummer bedeutet und einmal ändert sich eine Anforderung, die bereits in der Liste steht (hier von Dokument zu Dokumente), was eine historische Fortschreibung bedeutet. Das kann im kaufmännischen Geschehen einmal zu einem neuen Auftrag führen (weil die Anforderung neu ist) und einmal zu einem Nachtrag zu einem bestehenden Auftrag (weil die Anforderung ja schon bestand). Dann ist der Unterschied eventuell gar nicht mehr marginal, weil vielleicht Neuaufträge wegen Budget-Knappheit einen Vergabestopp haben, aber Nachträge zu bereits vergebenen Aufträgen noch möglich sind. Damit entscheidet dieser anfänglich belanglose und scheinbar rein sprachliche Unterschied auf einmal über "hop" oder "top".

Zum Glück sind es aber mit etwas Geschick oft doch nur zwei verschiedene Sichten auf dieselbe Sache: eine Änderungsanforderung soll die Software ändern, in der Regel indem was Neues hinzugefügt wird. Dieses Neue wird aber nun mal in die bestehende Software eingebaut, so dass es immer auch als Änderung eines bestehenden Moduls betrachtet werden kann. Eine Anforderungsänderung soll ja etwas Bestehendes ändern, und zwar meistens erweitern, also etwas Neues hinzufügen. Damit ist der Umstand meistens diskutabel und der Ausgang der Geschichte halt vom Verhandlungsgeschick der beteiligten Parteien abhängig.