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: 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 |
|||||
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 “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): |
|||||