Process Requirements#
Change management planning
|
status: valid
|
||||
The Change Management Plan shall identify the work products and elements subject to change management, including those identified according to support_743, and define when change management applies to them. |
|||||
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:
|
|||||
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). Record the request date (issue creation date) and the starting release version on which the change is based. The impact analysis shall cover the affected elements, its interfaces and connected elements, the parties and responsibilities in distributed development, and the schedule for implementation and verification. |
|||||
Change Request attribute: safety
|
status: valid
|
||||
Each Change Request shall have a automotive safety integrity level (ASIL) identifier:
|
|||||
Change Request attribute: security
|
status: valid
|
||||
Each Change Request shall have a security relevance identifier:
|
|||||
Change Request attribute: Types
|
status: valid
|
||||
|
|||||
Change Request attribute: Tracking
|
status: valid
|
||||
Links to the issues implementing Change Request |
|||||
Change Request attribute: Affected Work Products
|
status: valid
|
||||
Links to the work products affected by the Change Request. Distinguish those affected from those requiring modification. |
|||||
Change Request attribute: Milestone
|
status: valid
|
||||
Milestone until the Change Request must be implemented (used for prioritization) For each accepted Change Request, record who will carry out the change and when it is due, considering the interfaces involved. The request or linked implementation issues may provide this information. |
|||||
Change Request Checks#
Change Requests mandatory attributes provided
|
status: valid
|
|||||||||||||||
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:
|
||||||||||||||||
Change Request Traceability Impact Analysis Tool#
Change Requests Impact Analysis Tool
|
status: valid
|
||||
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: 
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 “derived_from”). The impact analysis is supported by versioned linking, i.e. some of the workproducts have versions (as depicted in the picture) and the links pointing to these will also hold a version attribute. The tooling will detect and report a mismatch (blocking document generation). 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 for an example where a feature requirement change impacts the derived component requirements but not the feature level architecture artefacts): 
|
|||||