Management-Zusammenfassung dieses Beitrags:
Ein Change Request (deutsch Änderungsanfrage oder Änderungsantrag) bezeichnet ein formales Vorgehen oder formales Dokument, um Änderungen am Produktumfang beantragen und vornehmen zu können. Change Requests sind Teil des Änderungsmanagements in Projekten oder bei der Produktentwicklung.
Es wird in diesem Beitrag der Change Request charakterisiert.
Das Konzept des Change Requests ist sowohl ein Teil des Projektmanagements als auch des Requirements Engineerings. In beiden Disziplinen kommt dem Change Request eine große Bedeutung zu (Abbildung 0.1).
Abbildung 0.1: Einordnung des Change Requests im → Projektmanagement- und Requirements-Engineering-Kontext
1. Einleitung und Grundlagen
1.1 Definitionen
Das → PMI /PBG17‑d/ definiert:
“Änderungsantrag / Change Request. Ein formaler Vorschlag zur Änderung eines Dokuments, eines Liefergegenstandes oder eines Basisplans.”
In der Wikipedia steht /#Wiki-Change-Request/:
“Eine Änderungsanforderung (auch Change Request abgekürzt CR oder Request for Change abgekürzt RfC) bezeichnet im Änderungswesen von Projekten einen formalisierten Wunsch nach Veränderung der Eigenschaften eines bestimmten Produktmerkmals.
Jede Änderungsanforderung sollte in einem kontrollierten Prozess bewertet, entschieden und kommuniziert werden.”
In Abbildung 1.1 sind die beiden wesentlichen Aspekte eines Change Requests dargestellt.
Abbildung 1.1: Aspekte eines Change Requests
Generell wird unter Change Request nicht nur der (formale) Antrag, sondern auch der Umgang damit (Change-Request-Prozess) verstanden.
Ohne formale Change Requests können sich Änderungen in den Produkt- oder Projektinhalt einschleichen — dies wird als Scope Creep (deutsch in etwa: Umfangsverschleppung) bezeichnet. Ein Scope Creep ist unerwünscht, da hierdurch Aufwände und Kosten entstehen können, ohne dass dadurch Mehrwerte geschaffen werden.
1.2 Kurzcharakterisierung von Change Requests
Change Requests können folgendermaßen charakterisiert werden — Change Requests (in Softwareentwicklungsprojekten) …
- heißen zu gut Deutsch Änderungsanträge.
- dienen dem formalen Abstimmungsprozess zwischen Fachabteilung und Entwicklungsteam.
- werden durch die Fachabteilungen in Zusammenarbeit mit dem Entwicklungsteam erstellt.
- basieren auf bestehenden Spezifikationen (und nicht auf realisierten Versionen der Software).
- sind häufig “normale” Textdokumente.
- haben im Idealfall nur eine beschränkte Lebens-/Gültigkeitsdauer und werden in die Dokumentation (Spezifikation u.a.) eingearbeitet.
- bedürfen der Diskussion und der Abstimmung zwischen den Beteiligten und haben immer einen definierten Status.
- führen im Normalfall zu einer Veränderung der entstehenden Software.
- führen zur keiner Änderung der Datenbestände (dies machen Data Change Requests).
- sind kein Instrumentarium zur Fehlerbehebung.
- gliedern sich in das Change- und → Konfigurationsmanagement ein.
- haben eine fortlaufende Nummer.
- beziehen sich auf eine abgenommene / freigegebene Version (→ Baseline) der Feinspezifikation (mit Version & Datum).
- haben immer den gleichen, formalen Aufbau.
- werden durch die Fachabteilung vorpriorisiert und mit einem Wunschdatum versehen.
- haben einen Status, der nicht “im Dokument” selber, sondern in der übergeordneten CR-→ Liste festgehalten wird. Achtung: Die CR-Liste darf nicht mit dem → Changelog verwechselt werden: Im Changelog werden durchgeführte Änderungen protokolliert, die auch unabhängig von Change Requests entstehen können.
- werden nach Erstellung nicht mehr verändert.
2. Das Change-Request-Formular
Um einen Änderungswunsch innerhalb eines Projekts bearbeiten zu können, sollte Änderungsantrag über ein Änderungsantragsformular (Change-Request-Formular) gestellt werden. Ein Beispiel für ein Änderungsantragsformular ist in Abbildung 2.1 dargestellt.
Die oberen beiden Zeilen bilden den Kopf des Änderungsantrags und sind für alle Änderungsanträge im Projekt gleich. Es werden dabei vier Einträge vorgenommen, die aus dem → Projektauftrag stammen:
- Projekttitel (und Beschreibung)
- Projekt-ID
- → Projektmanager
- → Projektsponsor
Nach dem Kopf gibt es folgende Felder zum Eintragen von Informationen zum Änderungswunsch:
- CR-Nr. (Änderungsnummer): Eindeutige Nummer für diesen Änderungsantrag, wird zentral für das Projekt vergeben und ist eindeutig
- Machbarkeit geprüft (durch, am): Hier wird der Status der Machbarkeit festgehalten. Ist die Änderung nicht machbar, so gilt der Änderungsantrag als abgelehnt
- Beschreibung der Änderung: Textuelle Beschreibung der Änderung, gegebenenfalls mit Verweisen / Verlinkungen auf ergänzende Grafiken oder Dokumente
- Grund der Änderung: Kurze Benennung des Auslösers / Grunds der Änderung
- Betroffene → Arbeitspakete (Arbeitspaketnummern): Hier werden die Arbeitspakete (aus dem → Projektstrukturplan) benannt, die von der gewünschten Änderung betroffen sind
- Kosten der Änderungsumsetzung: Benennung der Kosten zur Umsetzung der Änderung
- Kostenübernahme durch: Benennung desjenigen, der die Kosten zur Umsetzung der Änderung übernimmt. Dies kann nur eine “autorisierte Person” sein
- → Aufwand der Änderungsumsetzung: Benennung des Aufwands zur Umsetzung der Änderung (in der Regel in Stunden oder Personentagen)
- → Dauer der Änderungsumsetzung: Benennung der Dauer zur Umsetzung der Änderung (in der Regel in Tagen oder Werktagen)
- Auswirkungen auf die Projektleistung, die → Projektdauer, die → Projektkosten: Betrachtung der Veränderung auf die drei Elemente des magischen Dreiecks für das Gesamtprojekt (zumindest → qualitativ)
- → Zeitpunkt der Realisierung, Auswirkungen auf den Projektterminplan: Anvisierter Zeitpunkt, an dem mit der Realisierung begonnen werden soll und Betrachtung des Einflusses auf den → Terminplan, insbesondere des Projektabschlusstermins
- Zahlungsbedingungen: Beschreibt, wann und die entstehenden Kosten durch den Kostenübernehmer dem Projekt zur Verfügung gestellt werden
- Genehmigungsstatus: Benennt den Status des Genehmigungsverfahrens
- Bezug zum Konfigurationsstand (Baseline): Benennt die Baseline, für die dieses Änderungsverfahren gilt
- Unterschrift Projektmanager: selbsterklärend
- Unterschrift Projektsponsor: selbsterklärend
Abbildung 2.1: Änderungsantragsformular (Beispiel)
3. Die Verwendung von Change Requests
Change Requests werden im Projektmanagement und im → Requirements Engineering gleichermaßen verwendet.
3.1 Im Projektmanagement
Im Projektmanagement sind Änderungen / Change Requests wesentlich. Änderungen verursachen in der Regel Mehraufwände und damit Kosten. Da der Kostenrahmen und der Kostenplan aber zu Beginn des Projekts festgelegt werden, müssen Änderungen gezielt über einen formalen Prozess in das Projekt eingebracht werden.
Bei einer hohen Anzahl von Änderungen sollte eine neue Baseline gezogen werden, um so die Vergleichbarkeit zu gewährleisten, denn ansonsten würden die Mechanismen des Projektcontrollings nicht mehr greifen. Insbesondere bei der → Earned Value Analysis würden die ermittelten Zahlen an Aussagekraft verlieren.
3.2 Im Requirements Engineering
Werden Änderungswünsche an ein bereits spezifiziertes oder entwickeltes System geäußert, so müssen diese in einem ersten Schritt überprüft werden. Hierzu werden die → Traces von Anforderungen genutzt und mittels einer Einflussanalyse überprüft.
4. Generelle Regeln im Umgang mit den Changes Requests
Folgende Regeln sollten beim Umgang mit Change Requests beachtet werden:
- Alle Änderungen müssen erfasst werden
- Bereits das Bewerten der Änderungswünsche verursacht Kosten. Diese müssen vorab benannt (und eingeordnet) werden
- Gravierende Änderungen müssen durch einen Ausschuss (Board) — im Allgemeinen das Change Control Board (CCB) — genehmigt werden
- Bei vielen Änderungen muss nach der Genehmigung eine Baseline gezogen werden
In Abbildung 4.1 ist ein Zustandsmodell für Änderungen dargestellt, welches sich an einem Zustandsmodell für die Erfassung von Anforderungen orientiert.
Abbildung 4.1: Ein Zustandsmodell für Change Requests (Beispiel)
5. Häufig gestellte Fragen und Antworten (FAQ) zum Change Request
Einige Fragen zu den Change Requests werden häufig gestellt – diese werden hier wiedergegeben.
- F: Müssen Change Requests in Projekten berücksichtigt werden?
A: Ja. Change Requests sind für Projekte essenziell: Projekte ohne Änderungen im Projektverlauf gibt es kaum. - F: Reichen rein textuelle Beschreibungen in Change Requests aus?
A: Meiner Meinung nach ja. Soll “mehr” dargestellt werden, so sollten Verweise zum Einsatz kommen. - F: Welche Tools sollten für die Change Requests verwendet werden?
A: Bei kleinen → Vorhaben können einfache Tabellen-Tools ausreichend sein. Generell empfiehlt es sich aber, datenbankgestützte Tools zu verwenden.
Haben Sie noch weitere Fragen oder möchten Sie Ergänzungen an der FAQ vornehmen? Am besten schreiben Sie mir hierzu eine E‑Mail an: kontakt@peterjohann-consulting.de.
A. Präsentationen, Literatur und Weblinks
A.1 Meine öffentliche Präsentation zum Change Request
Der Change Request wird in meiner Präsentation zum Requirements Engineering beschrieben.
| Inhalt | Typ |
|---|---|
| Requirements Engineering (und Business Analysis) – Eine Einführung (RE-Basispräsentation) | 
|
A.2 Literatur
Diese Bücher beleuchten den Change Request (im Projekt- oder Requirements-Engineering-Kontext) etwas intensiver:
- /PBG17/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sixth Edition 2017, ISBN 978–1‑62825–184‑5
- /PBG17‑d/ Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK Guide), Project Management Institute, Philadelphia, Pennsylvania Sechste Ausgabe 2017, ISBN 978–1‑62825–188‑3
A.3 Weblinks
Folgende Weblinks liefern weitere Informationen zum Change Request und zum Änderungsmanagement:
- /#Wiki-Änderungswesen/ Änderungswesen in der deutschen Wikipedia
- /#Wiki-Change-Request/ Änderungsanforderung in der deutschen Wikipedia
Legende zu den Weblinks
/ / Verweis auf eine Website (allgemein)
/*/ Verweis auf eine Website, die als Ergänzung zu einem Buch dient
/#/ Verweis auf ein einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 30.04.2022 © Peterjohann Consulting, 2005–2025
