Management-Zusammenfassung zu diesem Beitrag:
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 1).
Abbildung 1: Einordnung des Change Requests im → Projektmanagement- und Requirements-Engineering-Kontext
1. Einleitung und Grundlagen
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 2 sind die beiden wesentlichen Aspekte eines Change Requests dargestellt.
Abbildung 2: Aspekte eines Change Requests
Generell wird unter Change Request nicht nur der (formale) Antrag, sonderen auch der Umgang damit (Change-Request-Prozess) verstanden.
1.1 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.
- 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 3 dargestellt.
Abbildung 3: Ä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 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
A. Präsentationen, Literatur und Weblinks
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) | 
|
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
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 (generell)
/*/ Verweis auf eine Website, die als Buch-Ergänzung dient
/#/ Verweis auf einzelnes Thema auf einer Website
/#V/ Verweis auf ein Video auf einer Website
Letzte Aktualisierung: 30.04.2022 © Peterjohann Consulting, 2005–2023
