Change Requests

A change request is part of the formalized change management process in configuration management and describes a single change to the design data in RePoSyD.

Change requests can be submitted at any time during the execution of a project and are used to change design data that is under configuration control, i.e., assigned to a formal configuration baseline. Or for the formalized documentation of changes to design artifacts such as requirements without these being under configuration control.

Overview of all Change Requests

Click on Configuration Management / Change Request in the main menu to display an overview of all change requests in a table, carousel or Kanban view.

Table and Kanban View

The change requests view provides different view for accessing and managing change requests. You can toggle between the views to clicking either on the kanban or table button

Figure 1: Change Requests: Table View

Figure 3: Change Requests: Carousel View

Table 1: caption

Action		Description
	Approve	Approves the submitted change request.
	Implement	Starts the implementation the change request
	Reject	Rejects the change request .
	Submit	Submits the change request
	Withdraw	Withdraws the change request .

Carousel View

n the carousel view, you can search and edit the change request at the same time. Click on the carousel view button to open the view starting with the respective change request.

Dashboard

Figure 4: Change Requests: Dashboard

Change Request

Table 2: caption

Property	Description
Classification	Defines the classification of the change. Design change The change is necessary as part of the development and implementation process of the system. Obsolescence The change is necessary due to the discontinuation of systems, components, or functions. Other The change is necessary for other reasons that are not specified in detail.
Implementation	Date and schedule for the implementation. Schedule no schedule The implementation is not planned. after The implementaion shall be started after the specified date. before The implementaion shall be completed before the specified date. on The implementation shall be completed on the given date. Date The date when the implementation shall be performed.
Number	Numbering of the change request. When a change request is created, it is automatically filled with the PUID of the design data object and the sequential number of the change requests for the respective design data object. (<puid>.CR.<seqnum>)
Priority	Determines the priority (processing speed) with which the change request is to be evaluated, decided upon, and, if approved, implemented. emergency To make a change to operational characteristics that, if not implemented immediately, could seriously compromise operational safety; or To remedy a hazardous situation that could result in fatal or serious injury to personnel or significant damage or destruction of equipment. (A hazardous situation usually requires the temporary decommissioning of the item or the suspension of the operation of the item or the cessation of further testing or development until the situation is remedied.); urgent To make a change that, if not made promptly, could seriously compromise the operational capability of the equipment used; or To remedy a potentially hazardous situation that, if not remedied, could result in injury to persons or damage to equipment. (A potentially hazardous situation compromises safety and poses risks, but allows, within reasonable limits, the continued use of the affected item, provided that the operator has been informed of the hazard and appropriate precautions have been taken and communicated to the user.) ; routine A routine priority is assigned to a proposed technical change if “emergency” or “urgent” does not apply.
Source	Defines the source of the change request. Customer The change request was initiated by the customer. External The change request was initiated externally (e.g. partner) Internal The change request was initiated internally (e.g. project, company). Other source The change request was initiated by an undefined source.
Owner	The team who has created the change request.
Responsible	The team who is responsible for the change request.
Reason for Change	A detailed description why this change is necessary.
Title	Summary of the reason for the change.
Type	Type of changes.

Life Cycle

Figure 5: Change Request: Life Cycle

Status

Table 3: Change Request: Status

Status	Description
Pending	The change request is currently being processed and is not valid with regard to the specified changes.
Submitted	All necessary changes to be made to the respective design data with this change request have been described, and the change request has been submitted for decision.
Rejected	The implementation of the change request has been rejected.
Approved	The implementation of the change request has been approved.
Implemented	The changes described in the change request have been implemented in the design data.
Verification failed	The implementation of the changes to the design data has been rejected.
Verified	The implementation of the changes to the design data has been checked and they correspond to the change request.

Transitions

Table 4: Change Request: Transitions

Transition	Description	Permissions
Pending → Deleted	This transaction can only be performed for change requests with the status ‘Pending’.	All users who are members of the team that owns the change request. All users who are members of the team responsible for the change request. All users with one of the following roles assigned to their account: Repository Manager, Change Manager or Configuration Manager.
Pending → Submitted	The change request is submitted for decision.	All users who are members of the team that owns the change request. All users who are members of the team responsible for the change request. All users with one of the following roles assigned to their account: Repository Manager, Change Manager or Configuration Manager.
Submitted → Withdrawn	The change request is withdrawn and will not be pursued in the current version. A new change request must be created if the changes described in the change request are to be resubmitted for decision at a later date.	All users who are members of the team that owns the change request. All users who are members of the team responsible for the change request. All users with one of the following roles assigned to their account: Repository Manager, Change Manager or Configuration Manager.
Submitted → Approved	A decision has been made on the change request and implementation is approved.	All users with one of the following roles assigned to their account: Repository Manager, Configuration Manager or Change Manager
Submitted → Rejected	A decision has been made on the change request and implementation is rejected. The reason must be described in the change log.	All users with one of the following roles assigned to their account: Repository Manager, Configuration Manager or Change Manager
Approved → Implemented	The changes described in the change request have been fully implemented and are submitted for verification.
Implemented → Verification failed	The changes described in the change request have been implemented incorrectly. The deviations must be described in the change log.	All users with one of the following roles assigned to their account: Repository Manager, Configuration Manager or Change Manager
Implemented → Verified	The review of the changes described in the change request has been completed and no deviations have been found.	All users with one of the following roles assigned to their account: Repository Manager, Configuration Manager or Change Manager

Table of Contents