Process Requirements#

Change Request Attributes#

Change Request attribute: UID
status: valid

Each Change Request shall have a unique ID. It shall be in an integer number.

Change Request attribute: status
status: valid

Each Change Request shall have a status:

  • open

  • in review

  • in implementation

  • closed

  • rejected

Change Request attribute: title
status: valid

Reason for the Change Request

Change Request attribute: description
status: valid

Exact description of the Change Request, including impact analysis on functional safety, security, implementation (schedule, risks, resources) verification (measures defined).

Change Request attribute: safety
status: valid

Each Change Request shall have a automotive safety integrity level (ASIL) identifier:

  • QM

  • ASIL_B

Change Request attribute: security
status: valid

Each Change Request shall have a security relevance identifier:

  • Yes

  • No

Change Request attribute: Types
status: valid
tags: prio_1_automation, attribute, mandatory, change_management
  • Feature

  • Feature Modification

  • Component

  • Component Modification

Feature This Change Request describes a potential new feature for the platform. The Change Request uses the Feature request template: Feature Template.

Feature Modification This Change Request describes a scope modification of an existing feature (requirement or work product). The Change Request modifies the already existing Feature Request template: Feature Template.

Component This Change Request describes a potential new component for the platform. The Change Request uses the Component request template: Component Template.

Component Modification This Change Request describes a scope modification of an existing component (requirement or work product). The Change Request modifies the already existing Component Request template: Component Template.

Change Request attribute: Affected Work Products
status: draft

Links to the work products affected by the Change Request

Change Request attribute: Milestone
status: valid

Milestone until the Change Request must be implemented (used for prioritization)

Change Request Checks#

Change Requests mandatory attributes provided
status: valid
tags: prio_2_automation, attribute, check, change_management

It shall be checked if all mandatory attributes for each Change Request is provided by the user. For all requirements following attributes shall be mandatory:

Overview 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

Change Request attribute: status

Change Request attribute: title

Change Request attribute: Types

Change Request attribute: UID

Change Request Traceability Impact Analysis Tool#

Change Requests Impact Analysis Tool
status: valid
tags: prio_3_automation, check, tool, change_management

It shall be reported, which work products and elements are affected by adding a new feature or component or by a modification of an existing feature or component.

Below picture illustrates the relations:

Which changes to follow for impact analysis.

The picture is derived from the building blocks metamodel containing all the work products (Building blocks concept). Its arrows show how every work product is linked (manually) to other work products (e.g. feature requirements are linked to stakeholder requirements via “satisfies”). The color code describes which of these Links need to be followed for the impact analysis (so for the example this means: if a stakeholder requirement is changed, the feature requirements linked are affected, but not the other way round). “Black” links do not need to be followed, these are the “verifies” links. And these are expected to fail after implementation change, so the impact on testing will be detected by the test automation without the need for an additional tooling. Note that for some links it is expected to have both directions followed (red arrows) - these are the artefacts which reside in different repositories.

Note also: The impact analysis needs to follow the links iteratively, so first to the directly connected work products, then to the next, … (see the next illustration):

How to follow changes for impact analysis iteratively.