Change Request im Softwareprojekt einfach erklärt

Ein Change Request ist eine nachträgliche Änderung an einer Software, die nach der ursprünglichen Beauftragung oder nach der Fertigstellung zusätzlich umgesetzt werden soll. Viele Auftraggeber suchen genau an diesem Punkt nach Orientierung: Welche Aufgaben entstehen nach dem Go-live oder nach der Abnahme noch, und warum fällt dafür weiterer Aufwand an?

Dabei geht es nicht nur um Fehlerbehebung. Häufig kommen neue Anforderungen, geänderte Prozesse, zusätzliche Schnittstellen, Anpassungen an Rollen und Rechte oder Erweiterungen der Benutzeroberfläche hinzu.

Dieser Artikel zeigt Ihnen praxisnah, wie Change Requests entstehen, wie sie bewertet werden und wie Sie Aufwand und Folgekosten besser einordnen.

Was ein Change Request genau bedeutet

Ein Change Request ist ein formaler Änderungswunsch für eine Software, die bereits geplant, entwickelt oder schon produktiv im Einsatz ist. Gemeint ist also keine vage Idee, sondern eine konkrete Anpassung, die geprüft, bewertet und bei Bedarf umgesetzt werden soll.

Wichtig ist die Abgrenzung: Wenn eine bereits vereinbarte Funktion nicht so arbeitet, wie sie beschrieben oder abgestimmt wurde, ist das in der Regel kein Change Request. Dann geht es meist um die vereinbarte Leistung oder um Qualitätssicherung, nicht um einen neuen zusätzlichen Wunsch. Mehr dazu, wie Prüfungen im Projekt eingeordnet werden, lesen Sie im Beitrag zu Softwaretests im Projekt.

Änderungswünsche können in jeder Projektphase entstehen. Für Auftraggeber werden sie oft besonders nach der Fertigstellung sichtbar, weil erst im Alltag auffällt, was noch fehlt, vereinfacht oder ergänzt werden sollte.

Typische Beispiele sind:

• ein neues Formular
• eine zusätzliche Auswertung
• die Erweiterung einer Datenbank
• eine neue Schnittstelle
• eine Anpassung an Microsoft 365 oder Entra ID
• geänderte Rollen und Rechte
• ein zusätzlicher Freigabeprozess

Eine Schnittstelle ist eine Verbindung, über die zwei Systeme Daten austauschen. Eine Datenbank ist der strukturierte Speicher der Anwendungsdaten.

Ein Change Request ist deshalb meist kein Störfall, sondern ein Hinweis darauf, dass sich Abläufe, Ziele oder Rahmenbedingungen weiterentwickeln. Wie solche Änderungen grundsätzlich in den Projektablauf eingeordnet werden, zeigt auch der Beitrag Software entwickeln lassen: So gehen Sie vor.

Warum nach der Fertigstellung weitere Aufgaben entstehen

Nach dem Livegang trifft Software erstmals vollständig auf echte Prozesse, echte Daten und echte Nutzer. Genau dann werden Anforderungen sichtbar, die sich in Workshops, Konzepten oder Tests vorher nur begrenzt erkennen ließen. Im Alltag zeigt sich oft erst, wo Informationen anders aufbereitet werden müssen, welche Schritte fehlen oder welche Bedienwege vereinfacht werden sollten.

Häufige Auslöser sind zum Beispiel:

• neue interne Abläufe
• geänderte Zuständigkeiten
• zusätzliche Standorte
• neue Berichtspflichten
• weitere Nutzergruppen
• die Anbindung eines weiteren Systems

Hinzu kommt: Auch neue Geschäftsideen oder organisatorische Veränderungen können den Funktionsumfang nachträglich erweitern. Was bei der Beauftragung passend war, muss einige Monate später bereits ergänzt werden, damit die Software weiter zum Unternehmen passt.

Auch das technische Umfeld bleibt nicht unverändert. Wenn Cloud-Dienste, Identitätsverwaltung oder bestehende Fachsysteme angepasst werden, kann daraus ein neuer Änderungsbedarf entstehen. Ein Cloud-Dienst ist bereitgestellte IT-Infrastruktur oder Software aus Rechenzentren, die über das Internet genutzt wird. Eine verständliche Einordnung dazu finden Sie im Beitrag zur Cloud-Computing-Infrastruktur.

Zusätzliche Wünsche entstehen inzwischen auch rund um KI-Funktionen, etwa für die Suche im Firmenwissen, einen Assistenten oder das Auslesen von Dokumenten. Gemeint sind damit Softwarefunktionen, die Inhalte analysieren oder formulieren.

Aus Projekterfahrung lässt sich das gut an einer Webplattform zur Verwaltung eines Kanalnetzes zeigen: Nach dem Start entstehen oft zusätzliche Auswertungen, weitere Kartenansichten oder neue Freigabeschritte, sobald Fachabteilungen im täglichen Einsatz damit arbeiten.

Ein Projektabschluss bedeutet deshalb meist nicht, dass keinerlei Arbeit mehr anfällt. Danach rücken eher Betrieb, Support und gezielte Weiterentwicklung in den Vordergrund. Wer Änderungswünsche später besser einplanen möchte, sollte außerdem technische Schulden verstehen.

Wie ein Change Request geprüft und umgesetzt wird

Ein Change Request wird sinnvoll in mehreren Schritten bearbeitet: Änderungswunsch aufnehmen, Ziel und Auswirkungen klären, Aufwand einschätzen, Entscheidung treffen, umsetzen, testen und dokumentieren.

Wichtig ist dabei eine möglichst präzise Beschreibung. Ohne klar formuliertes Ziel lässt sich schwer beurteilen, welche Bereiche der Software betroffen sind und was tatsächlich geändert werden muss. Hilfreich sind zum Beispiel diese Fragen:

• Was soll sich für die Nutzer konkret ändern?
• Welche Daten sind betroffen?
• Welche Rollen dürfen künftig was sehen oder bearbeiten?
• Müssen Schnittstellen angepasst werden?
• Welche Tests sind notwendig?

Mit Auswirkungen ist gemeint, welche Funktionen, Datenflüsse oder Arbeitsabläufe durch die Änderung mitberührt werden, auch wenn sie zunächst nicht direkt dazugehören. Genau deshalb kann eine kleine fachliche Anpassung technisch größer werden, wenn mehrere Komponenten zusammenwirken.

In der Umsetzung hilft ein strukturiertes Vorgehen mit regelmäßigen Abstimmungen. So lassen sich Änderungswünsche früh erkennen, sauber einordnen und in eine sinnvolle Reihenfolge bringen. CI/CD ist ein automatisierter Weg, Softwareänderungen kontrolliert zu prüfen und bereitzustellen.

Zur Qualitätssicherung gehört mehr als ein kurzer Sichttest. Sinnvoll sind funktionale Prüfungen und automatisierte Tests. Automatisierte Tests sind vorab definierte Prüfungen, die wiederholt kontrollieren, ob wichtige Funktionen weiterhin korrekt arbeiten.

Ebenso wichtig ist nachvollziehbare Dokumentation. Warum sie spätere Anpassungen erleichtert, zeigt der Beitrag zur technischen Dokumentation für Softwareprojekte.

Wovon Aufwand und Kosten eines Change Requests abhängen

Der Aufwand eines Change Requests hängt selten nur von der sichtbaren Änderung in der Oberfläche ab. Entscheidend ist, welche Bereiche im Hintergrund mitbetroffen sind und wie stark die bestehende Lösung dafür angepasst werden muss.

Typische Einflussfaktoren sind zum Beispiel:

• die Komplexität der bestehenden Software
• die Qualität der Ausgangsbasis
• die Zahl der betroffenen Module
• Änderungen an Datenbank und Schnittstellen
• zusätzlicher Testaufwand
• notwendige Dokumentation
• Abstimmungen zwischen Fachbereich, IT und Dienstleister

Eine kleine fachliche Ergänzung kann deshalb deutlich mehr Arbeit auslösen, wenn mehrere Teile der Anwendung zusammenspielen. Nachhaltig gebaute Software unterstützt spätere Änderungen oft besser als schnell zusammengebaute Lösungen. Clean Code Development steht hier für eine Arbeitsweise, die auf Verständlichkeit, klare Struktur und langfristige Wartbarkeit zielt.

Umgekehrt können technische Schulden den Aufwand erhöhen. Gemeint sind kurzfristig entstandene Vereinfachungen in der Software, die spätere Anpassungen erschweren. Gerade dann werden Änderungen oft teurer oder aufwendiger als zunächst erwartet.

Auch Betrieb und Infrastruktur spielen mit hinein, etwa wenn Anpassungen in Azure, bei Zugriffsrechten oder im Zusammenspiel mehrerer Umgebungen berücksichtigt werden müssen. Einen Überblick über die Leistungen von ballmüller solutions finden Sie hier.

Wenn die Art der Erweiterung bereits klar ist, hilft der Kostenrechner für eine grobe Kostenspanne. Bei unklaren oder größeren Vorhaben eignet sich der Projekt-Check mit Projektsteckbrief.

Wie Sie Change Requests für Auftraggeber gut steuern

Sinnvoll ist, Änderungswünsche nicht nebenbei im Termin oder per Zuruf zu sammeln. Besser ist ein fester Ablauf: Wünsche erfassen, fachlich einordnen, priorisieren und dann bewusst entscheiden, was wirklich umgesetzt werden soll.

Hilfreich ist eine einfache Einteilung in:

• Muss: notwendig für den Betrieb oder den Prozess
• Soll: wichtig, aber nicht sofort zwingend
• Kann: nützlich, jedoch nachrangig

So bleibt der Überblick erhalten, und wichtige Anpassungen gehen nicht zwischen kleineren Ideen unter.

Viele spätere Missverständnisse lassen sich schon vor Projektbeginn verringern. Klare Ziele, bekannte Nutzergruppen, definierte Prozesse und eine nachvollziehbare Anforderungsbasis schaffen von Anfang an ein gemeinsames Verständnis. Lastenhefte, Beschreibungen und frühe Entwürfe verhindern zwar nicht jede Änderung, verbessern aber die Erwartungshaltung auf beiden Seiten.

Ein Prototyp ist ein früher Entwurf, mit dem Abläufe und Bedienung greifbar geprüft werden, bevor die vollständige Lösung entsteht. Wenn Sie noch in der Vorbereitung sind, helfen die Beiträge zu Anfrage und Vorarbeit und zum sinnvollen Einsatz eines Prototyps.

Ebenso wichtig sind Tests, damit Änderungen in produktiver Software kontrolliert eingespielt werden.