Änderungsanforderung

Ä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.

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 Ä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:

• Änderungsantrag, Abk. ÄA
• engl. Change Request, Abk. CR^[1][2][3][4]
• engl. Request For Change^[5], Abk. RFC^[6][7]; RFC wird auch in ITIL^[8] und PRINCE2 verwendet
• Change Notice^[9]
• Action Request (AR)^[1]

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).

• Change Management (ITIL)