Zum Inhalt springen

Änderungsanforderung

aus Wikipedia, der freien Enzyklopädie

Eine Änderungsanforderung (auch Change Request abgekürzt CR oder Request for Change abgekürzt RfC) bezeichnet im Änderungswesen bzw. Änderungsmanagement von Projekten oder Programmen einen formalisierten Wunsch nach Veränderung der Eigenschaften eines bestimmten Objekts oder Gegenstandes.

Änderungsanfragen sind in der Regel für viele verschiedene Artefakte gültig, betreffen jedoch immer nur ein spezifisches. Ein Beispiel hierfür ist die Änderung des Planungsstands (Baseline) eines Dokuments, wie etwa des festgelegten Projektplans. Die eigentliche Kontrolle des Dokuments findet jedoch innerhalb einer Versionsverwaltung statt und als Teil eines Dokumentenmanagements.

Eine Änderungsanforderung kann in bestehenden Vertragsverhältnissen zwischen Auftraggeber und Auftragnehmer nur gemeinsam freigegeben werden. In diesem Fall wird sie zum Vertragsbestandteil. Man spricht auch von einem Änderungsvertrag.

Änderungsanträge werden zunächst innerhalb einer Organisation oder eines Unternehmens gestellt. Sie können aber auch durch einen Kunden gestellt werden, sofern dies fachlich und vertraglich geregelt ist. Wenn ein Kunde direkt mit einem Entwickler innerhalb einer Firma eine Änderung kommuniziert, sollte diese Art der Kommunikation abgestimmt werden, da jegliche Absprache durch den Änderungsprozess kontrolliert erfolgen sollte. Einmal akzeptierte Anforderungen dürfen ohne Änderungsantrag nicht verändert werden. Im Zweifelsfall ist der Projektmanager für das Ergebnis bzw. die Effekte der Änderungen auf die laufende Entwicklung verantwortlich.

Ausgangssituation

[Bearbeiten | Quelltext bearbeiten]

Grundsätzlich erfolgen Änderungen auf fixierte Objekte und/oder Daten, beispielsweise akzeptierten Anforderungen oder Merkmale (Features), die ein Produkt oder eine Dienstleistung erfüllen soll und die in ihrer ursprünglichen Fassung schon definiert wurden. Der ursprüngliche Wunsch, ein Feature einzufordern, wird in der Softwaretechnik als „Feature-Request“ bezeichnet. Diese vorgelagerten Aktivitäten finden im Projektmanagement als Teil des Inhalts- und Umfangsmanagement statt. Hier sind die schleichenden Anforderungen, auch „Scope-Creep“ genannt, zu beachten. Dabei handelt es sich um unbekannte Veränderungen der Anforderungen in Bezug auf Inhalt und Umfang. Die Zuständigkeit dafür liegt beim Anforderungsmanagement. Das Änderungsmanagement kommt daher tendenziell erst im späteren Verlauf einer Produkt- oder generell einer Entwicklungsphase zum Tragen. Wurde ein Endprodukt bereits hergestellt, z. B. ein Haus, können Änderungen rückwirkend nur begrenzt berücksichtigt und/oder unter entsprechenden Aufwänden und Kosten realisiert werden.

Jede Änderungsanforderung sollte in einem kontrollierten Veränderungsprozess bewertet, entschieden und kommuniziert werden. Zur Bewertung zählen z. B. eine Aufwandsabschätzung und Risikobewertung, siehe die Merkmale und Inhalte dazu. Dies geschieht in der Regel in einem ausgewählten Gremium von Personen, die mit dem Thema vertraut sind. Dieses Change Control Board (CCB) muss auf Basis der Informationen zum Änderungsantrag eine Entscheidung treffen können (Annahme oder Ablehnung des Änderungsantrags). Diese Managementaufgabe wird häufig von einem Changemanager oder einer repräsentativen Person übernommen, die ausschließlich den Änderungsprozess betreut. Die leitende Person sollte koordinative Fähigkeiten aufweisen, da Änderungen mit Kompromissen einhergehen können. Grundwissen in der Theorie und Praxis der Entscheidungsfindung sind notwendige Voraussetzungen. Zur Verwaltung von Änderungsanträgen kommen häufig Softwarelösungen zum Einsatz.

Beispiele:

  • Änderungsanforderungen interner Art: Die von der Softwareentwicklungsabteilung geschriebene Applikation für Windows soll auch unter Linux lauffähig sein. Nach einem erfolgreichen Änderungsantrag müssen die Entwickler die entsprechenden Anpassungen vornehmen, damit die Anwendung unter Linux läuft.
  • Gegenbeispiel: Beim Test eines Mautsystems wird festgestellt, dass der Kilometerzähler rückwärts läuft, wenn das Fahrzeug aufgrund einer Baustelle auf der Gegenfahrbahn fährt. Der Tester erstellt daher einen Fehlerbericht, weil der Anwendungsfall unzureichend oder gar nicht spezifiziert wurde oder weil das System diesen Fehler funktional begeht. Befindet sich das System noch in der Entwicklung, kann mittels eines Änderungsantrags überprüft werden, ob Korrekturen erforderlich sind. Eventuell fehlt eine Anforderung für diesen Spezialfall. Sie kann über einen Änderungswunsch angefordert werden, da gewisse Aufwände mit der Änderung einhergehen. Wurde eine zuvor gewünschte Funktion jedoch nicht korrekt erfüllt, dann ist das ein Fehler, aber keine Änderung.

Eine Sondervariante des Änderungsgremiums ist die Task Force, eine ausgewählte und aufgestellte Arbeitsgruppe, die sich genau einem oder nur wenigen Themen widmet und versucht, von Problemen zu Lösungen zu gelangen. Im Hinblick auf die mögliche Nutzung agiler Arbeitsverfahren werden Änderungen zunehmend kontinuierlich während des Arbeitsprozesses behandelt. Dies hat Vor-, aber auch Nachteile.

Merkmale und Inhalte

[Bearbeiten | Quelltext bearbeiten]

Eine Änderungsanforderung sollte folgende Informationen beinhalten:

  • die Beschreibung des Status quo der zu ändernden Eigenschaft
  • die Begründung für die Änderung (Motivation)
  • die betroffene Version oder Stand des zu ändernden Gegenstands
  • den Namen des Erstellers der Änderungsanforderung
  • den Namen des Verantwortlichen für die Umsetzung der Änderung
  • das Datum der Erstellung der Änderungsanforderung
  • das Zieldatum der gewünschten Umsetzung der Änderung
  • eine Kostenschätzung der Änderung (ggf. getrennt nach internen und externen Kosten, Lizenzkosten, Personalkosten usw.)
  • einen geschätzten Zeitaufwand für die geforderte Änderung (ggf. getrennt nach Konzeption, Entwicklung, Test usw.)
  • eine Risikobewertung der Änderung
  • bei Bedarf: sicherheitstechnische Bewertung der Änderung
  • bei Bedarf: strategische Bewertung der Änderung, von daher
  • bei Bedarf: Konsultation mit dem Management (Mittel- oder Topmanagement, also Vorgesetzten und/oder Geschäftsleitung)

Folgende Bezeichnungen werden in der Praxis gleichbedeutend verwendet:

Je nach Art der Änderung können verschiedene Anforderungen unterschieden werden, die im Wesentlichen das gleiche Konzept beschreiben:

  • Engineering Change (EC)[10]
  • engl. Engineering Change Request (ECR), technische Änderungsaufforderung[9]
  • Programm- oder Prozess- oder Product Change Request (PCR)

Engineering Change Order (ECO) ist ein separater Schritt nach dem ECR. Ist ein ECR genehmigt, wird ein ECO für die Umsetzung der Änderung erstellt.[11][12]

  • Siehe die Einzelnachweise und einführende Bücher aus dem Projekt- oder Changemanagement
  • Ivica Crnkovic, Ulf Asklund, Annita Persson Dahlqvist: Implementing and Integrating Product Data Management and Software Configuration Management (= Artech House computing library). Artech House, Boston London 2003, ISBN 978-1-58053-498-7 (englisch, lth.se).

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. 1 2 M. Kajko-Mattsson: Maintenance at ABB. II. Change execution processes (the state of practice). In: Proceedings IEEE International Conference on Software Maintenance - 1999 (ICSM'99). 'Software Maintenance for Business Change' (Cat. No.99CB36360). IEEE, 1999, S. 307–315, doi:10.1109/icsm.1999.792628.
  2. ↑ Minna Mäkäräinen: Software change management processes in the development of embedded software: Dissertation (= VTT Publications). VTT Technical Research Centre of Finland, Espoo 2000, ISBN 978-951-38-5573-4 (englisch, vtt.fi [abgerufen am 6. August 2026]).
  3. ↑ Alan Dennis, Barbara Haley Wixom, David Tegarden: System Analysis & Design: An Object-Oriented Approach with UML. John Wiley & Sons, Hoboken, 2002. ISBN 9780471413875
  4. ↑ Wing Lam: Change analysis and management in a reuse-oriented software development setting. In: Advanced Information Systems Engineering. Springer, Berlin, Heidelberg 1998, ISBN 978-3-540-69434-2, S. 219–236, doi:10.1007/BFb0054227 (englisch, springer.com [abgerufen am 6. August 2026]).
  5. ↑ Nicht zu verwechseln mit dem Request for Comments (RfC)
  6. ↑ Václav Rajlich: Software evolution and maintenance. In: Future of Software Engineering Proceedings. ACM, New York, NY, USA 31. Mai 2014, S. 133–144, doi:10.1145/2593882.2593893 (englisch).
  7. ↑ Václav Rajlich: Software change and evolution (SCE '99). In: Proceedings of the 21st international conference on Software engineering. ACM, New York, NY, USA 16. Mai 1999, S. 695–695, doi:10.1145/302405.302962 (englisch).
  8. ↑ A. Keller: Automating the Change Management Process with Electronic Contracts. In: Seventh IEEE International Conference on E-Commerce Technology Workshops. IEEE, S. 99–108, doi:10.1109/cecw.2005.7 (englisch).
  9. 1 2 Remko Helms: Product Data Management as enabler for Concurrent Engineering. Eindhoven University of Technology, Eindhoven 2002, ISBN 978-90-386-1787-9 (englisch, tue.nl [PDF; abgerufen am 6. August 2026]).
  10. ↑ G.Q. Huang, K.L. Mak: Current practices of engineering change management in UK manufacturing industries. In: International Journal of Operations & Production Management. Band 19, Nr. 1, 1. Januar 1999, ISSN 0144-3577, S. 21–37, doi:10.1108/01443579910244205 (englisch).
  11. ↑ Peter Pikosz, Johan Malmqvist: A Comparative Study of Engineering Change Management in Three Swedish Engineering Companies. In: Volume 7: 12th Engineering Information Management Symposium. American Society of Mechanical Engineers, 13. September 1998, doi:10.1115/detc98/eim-5684 (englisch).
  12. ↑ Christoph H. Loch, Christian Terwiesch: Accelerating the Process of Engineering Change Orders: Capacity and Congestion Effects. In: Journal of Product Innovation Management. Band 16, Nr. 2, März 1999, ISSN 0737-6782, S. 145–159, doi:10.1111/1540-5885.1620145 (englisch).