Guidelines#

Change Request Guideline		status: valid
status: valid tags: change_management is contained by: wf__change__cr_an_change_request, wf__change__rv_ap_change_request complies: std_req__iso26262__support_19, std_req__iso26262__support_23, std_req__iso26262__support_25, std_req__iso26262__support_23, std_req__iso26262__support_26

gd_guidl__change__change_request		Process Guideline

This document describes the general guidances for Change Management based on the concept which is defined Concept Description.

General Hints#

The detailed implementation of the Change Management for S-CORE is described in the Change Management Plan.

Templates#

Need templates displaying the correct syntax and attribute definition are provided for each Change Request type.

Table 13 Overview#
Change Request Type	Template
Feature	Feature Request Template
Feature Modification	Feature Request Template
Component	Component Request Template
Component Modification	Component Request Template

Attributes#

For all Change Requests following mandatory attributes need to be defined:

Overview of mandatory change request attributes#
Title
Change Request attribute: Affected Work Products
Change Request attribute: description
Change Request attribute: safety
Change Request attribute: security
Change Request attribute: Milestone
Requirement attribute: status
Change Request attribute: title
Change Request attribute: UID

ID: Unique integer number
For the remaining attributes only predefined values can be used. A more detailed description can be found here: Attributes of Change Requests

Workflow for Change Requests#

This section describes in detail which steps need to be performed for a Change Request.

Table 14 Workflow for Change Request#
Step	Description	Responsible
1.	Create change request	Contributor
2.	Analyze Change Request	Contributor
3.	Approve Change Request	Committer
4.	Implement Change Request	Contributor
5.	Verify Change Request	Committer

Create Change Request#

Contributor creates the Change Request in the defined Issue Tracking System linked to the created Feature or Component Request work products based on the provided templates. It is expected, that the UID will be provided by the Issue Tracking System.

The title of the Change Request should reflect the type (new feature/component request or feature/component modification).

The description should reflect the detailed changes. In case of a new feature/component request, fill-out the template sections properly. For modifications touch only the concerned sections.

Set the status of the Change Request to “draft”, indicating that is not ready for review.

Analyze Change Request#

To enable the S-CORE Committer to take a decision for approval of the Change Request, Contributor analyses and documents the request concerning the following topics in the created Change Request:

List of all affected work products
Provide potential implementation schedule including targeted Milestone
Identify risks for implementation, required S-CORE resources
Identify impact on existing work products and on functional safety, security
Define verification measures used to confirm the implementation

Set the status of the Change Request to “draft”, indicating that is not ready for review. Otherwise, change the status to “in review”, so that Committer is informed to start approval.

Approve Change Request#

Committer checks the Change Request in status “in review” based on checklist questions and provided content. If the check is passed, the Change Request is approved, which is pre-requisite for the implementation of the Change Request. In this case the status of the Change Request is changed to “accepted”.

In case information are missing the status will be kept in “in review” and the creator is asked for resolving the review comments.

Finally the Change Request may also “rejected”, then the implementation is not wanted.

Implement Change Request#

Contributor implements the Change Request. This is indicated by the Change Request status “in implementation”. During implementation the responsible lead Technical Lead or Module Project Lead reports regularly the status to the involved S-CORE teams until is completed and verified.

The traceability from the Change Request to the affected work products must be established during implementation. Also the verification measures must be executed.

Verify Change Request#

Committer must finally check, that implementation is complete and the defined verification measures are properly executed and successfully pass, before the Change Request can be confirmed.

The Change Request is closed by setting the status to “confirmed”.