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:
|
|||||
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:
|
|||||
Change Request attribute: security
|
status: valid
|
||||
Each Change Request shall have a security relevance identifier:
|
|||||
Change Request attribute: Types
|
status: valid
|
||||
|
|||||
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
|
||||||||||||||
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 “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): |
|||||