Process Requirements#

Requirements Structure
status: valid
tags: done_automation, structure, requirements_engineering
complies: std_req__iso26262__support_6431, std_req__iso26262__support_6432
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

Requirements shall be hierarchically grouped into three levels.

Following levels are defined:

  • Stakeholder requirement

  • Feature requirement

  • Component requirement

Additionally there shall be the following logical groups of requirements:

  • Assumption of use requirement

  • Process requirement

  • Tool requirement
gd_req__req_structure
Process Requirements

Process Requirement Attributes#

Requirement attribute: UID
status: valid
tags: manual_prio_1, attribute, mandatory, requirements_engineering
complies: std_req__iso26262__support_6425, std_req__iso26262__support_6432
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

Each requirement shall have a unique ID. It shall consist of three parts:

  • type of requirement

  • structural element (e.g. some part of the feature tree, component acronym)

  • keyword describing the content of the requirement.

Consider the project’s naming convention.
gd_req__req_attr_uid
Process Requirements
Requirement attribute: title
status: valid
tags: manual_prio_1 attribute, mandatory, requirements_engineering
complies: std_req__iso26262__support_6424
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

The title of the requirement shall provide a short summary of the description, but is not an “additional” requirement.

This means for example that the word “shall” is not allowed in the title for all requirements.
gd_req__req_attr_title
Process Requirements
Requirement attribute: description
status: valid
tags: manual_prio_1, attribute, mandatory, requirements_engineering
complies: std_req__iso26262__support_6424
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

Each requirement shall have a description.

Note

ISO/IEC/IEEE/29148 - Systems and software engineering — Life cycle processes — Requirements engineering defines general concepts including terms and examples for functional requirements syntax.

The concepts shall apply.
gd_req__req_attr_description
Process Requirements
Requirement attribute: type
status: valid
tags: manual_prio_2, attribute, mandatory, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_feat_aou, wf__req_comp_aou

Each requirement, apart from process and tool requirements, shall have a type of one of following options:

  • Functional

  • Interface

  • Process

  • Non-Functional
gd_req__req_attr_type
Process Requirements
Requirements attribute: security
status: valid
tags: manual_prio_2, attribute, mandatory, requirements_engineering
satisfies: wf__req_feat_req, wf__req_comp_req, wf__req_feat_aou, wf__req_comp_aou

Each requirement, apart from process and tool requirements, shall have a security relevance identifier:

  • Yes

  • No
gd_req__req_attr_security
Process Requirements
Requirement attribute: safety
status: valid
tags: manual_prio_1, attribute, mandatory, requirements_engineering
complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_feat_aou, wf__req_comp_aou

Each requirement, apart from process and tool requirements, shall have a automotive safety integrity level (ASIL) identifier:

  • QM

  • ASIL_B
gd_req__req_attr_safety
Process Requirements
Requirement attribute: status
status: valid
tags: manual_prio_1, attribute, mandatory, requirements_engineering
complies: std_req__iso26262__support_6425
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_feat_aou, wf__req_comp_aou

Each requirement, apart from process and tool requirements, shall have a status:

  • valid

  • invalid
gd_req__req_attr_status
Process Requirements
Requirement attribute: rationale
status: valid
tags: manual_prio_1, attribute, mandatory, requirements_engineering
satisfies: wf__req_stkh_req

Each stakeholder requirement shall provide an attribute called rationale. The rationale shall contain the reason why the requirement is needed.
gd_req__req_attr_rationale
Process Requirements
Requirement attribute: valid_from
status: valid
tags: manual_prio_2, attribute, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req

Stakeholder and feature requirements can have a validity attribute that tells from which milestone onwards the requirement is part of a feature.

This validity attribute is defined as including the defined milestone.

Milestone shall be valid release version tag, e.g. v1.0.2 as defined in Platform Release Note Template: Platform Release Note Template (gd_temp__rel_plat_rel_note). Thus the corresponding requirement is valid from the defined milestone, including it.
gd_req__req_attr_valid_from
Process Requirements
Requirement attribute: valid_until
status: valid
tags: manual_prio_2, attribute, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req

Stakeholder and feature requirements can have a validity attribute that tells until which milestone the requirement is part of a feature.

This validity attribute is defined as excluding the defined milestone.

Milestone shall be valid release version tag, e.g. v1.0.2 as defined in Platform Release Note Template: Platform Release Note Template (gd_temp__rel_plat_rel_note). Thus the corresponding requirement is only valid until the defined milestone, excluding it.
gd_req__req_attr_valid_until
Process Requirements

Process Requirement Linkage#

Requirement Linkage
status: valid
tags: manual_prio_1, attribute, requirements_engineering
complies: std_req__iso26262__support_6432
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool

Requirements shall be linked to its adjacent level via the attribute satisfies.

  • stakeholder requirements <- feature requirements

  • feature requirements <- component requirements

  • workflow or stakeholder requirements <- process requirements

  • process requirements or stakeholder requirements <- tool requirements
gd_req__req_linkage
Process Requirements
Requirement Traceability
status: valid
tags: done_automation, attribute, requirements_engineering
complies: std_req__iso26262__support_6432
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool

Bi-directional traceability shall be provided by adding a “back-link” via attribute satisfied by (i.e. make a <-> out of the <- in Requirement Linkage (gd_req__req_linkage)).
gd_req__req_traceability
Process Requirements
Requirement attribute: requirement covered
status: valid
tags: manual_prio_1, attribute, requirements_engineering
complies: std_req__iso26262__support_6423
satisfies: wf__req_stkh_req, wf__req_feat_req

It shall be possible to specify the requirement coverage, meaning the requirement is covered fully by its linked children.

  • Yes

  • No
gd_req__req_attr_req_cov
Process Requirements
Requirement attribute: link to implementation
status: valid
tags: prio_2_automation, attribute, requirements_engineering
satisfies: wf__req_feat_req, wf__req_comp_req

It shall be possible to link requirements to code (to the respective line of code in an attribute of the requirement).
gd_req__req_attr_impl
Process Requirements
Requirement attribute: link to test
status: valid
tags: prio_1_automation, attribute, requirements_engineering
complies: std_req__iso26262__support_6433, std_req__iso26262__software_944
satisfies: wf__req_feat_req, wf__req_comp_req

It shall be possible to link requirements to tests and automatically include a link to the test case in the attribute testlink.
gd_req__req_attr_testlink
Process Requirements
Requirement attribute: test covered
status: valid
tags: manual_prio_1, attribute, requirements_engineering
complies: std_req__iso26262__support_6433, std_req__iso26262__software_944
satisfies: wf__req_feat_req, wf__req_comp_req

It shall be possible to specify if requirements are completely covered by the linked test cases.

  • Yes

  • No
gd_req__req_attr_test_covered
Process Requirements
Requirement attribute: versioning
status: valid
tags: prio_1_automation, attribute, requirements_engineering
complies: std_req__iso26262__support_6425, std_req__iso26262__support_6434
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req

A versioning for requirements shall be provided. For this all mandatory attributes shall be taken into account: see Requirements mandatory attr... (gd_req__req_check_mandatory)
gd_req__req_attr_version
Process Requirements

Process Requirements Checks#

Requirement check: suspicious
status: valid
tags: prio_2_automation, check, requirements_engineering
complies: std_req__iso26262__support_6425, std_req__iso26262__support_6434
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req

Based on the requirement versioning it shall be checked if a parent requirement was updated but not the linked child requirements (or tests). In case an update was detected, the attribute requirement (or test) covered shall be set to “No”

Note: This refers to Requirement attribute: requ... (gd_req__req_attr_req_cov) and Requirement attribute: test... (gd_req__req_attr_test_covered)
gd_req__req_suspicious
Process Requirements
Requirements mandatory attributes provided
status: valid
tags: done_automation, check, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

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

Overview mandatory requirement attributes#

Title

Requirement attribute: description

Requirement attribute: rationale

Requirement attribute: safety

Requirements attribute: security

Requirement attribute: status

Requirement attribute: type

Requirement attribute: UID

There is one exception from the above: “rationale” attribute is mandatory only for stakeholder requirements.
gd_req__req_check_mandatory
Process Requirements
Requirements no weak words
status: valid
tags: done_automation, check, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req, wf__req_proc_tool, wf__req_feat_aou, wf__req_comp_aou

It shall be ensured that no weak words are contained in the requirement description for:

  • Stakeholder Requirements

  • Feature Requirements

  • Component Requirements

  • Tool Requirements

List of these weak words: just, about, really, some, thing, absolutely (to be extended)
gd_req__req_desc_weak
Process Requirements
Requirements linkage level
status: valid
tags: done_automation, check, requirements_engineering
complies: std_req__iso26262__support_6432
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req

Every feature- and component requirement shall be linked to at least one parent requirement according to the defined traceability scheme:

Traceability Concept for Requirements
gd_req__req_linkage_fulfill
Process Requirements
Requirements linkage architecture
status: valid
tags: prio_2_automation, check, requirements_engineering
complies: std_req__iso26262__support_6423
satisfies: wf__req_feat_req, wf__req_comp_req

It shall be checked if every feature- and component requirement is linked at least to one valid architectural element on the same level. This should also include requirement type checking:

  • If the requirement is of type “Functional” it shall be linked to architecture diagram elements.

  • If the requirement is of type “Interface” it shall be linked to architecture interface elements. Here the level matching is feature <> logical and component <> real.

  • If the requirement is of any other type there shall not be a link to architecture elements.

Note that the linking is done from the architecture element to the requirement as described for example in Allocate feature requirements to architectural elements.
gd_req__req_linkage_architecture
Process Requirements
Requirements linkage architecture switch
status: valid
tags: prio_2_automation, check, requirements_engineering
complies: std_req__iso26262__support_6423
satisfies: wf__req_feat_req, wf__req_comp_req

The check Requirements linkage archit... (gd_req__req_linkage_architecture) shall only be enabled for a release build, otherwise it would block creating requirements first without architecture.
gd_req__req_linkage_architecture_switch
Process Requirements
Requirements linkage safety
status: valid
tags: done_automation, check, requirements_engineering
complies: std_req__iso26262__support_6422
satisfies: wf__req_stkh_req, wf__req_feat_req, wf__req_comp_req

It shall be checked that (child) QM requirements (Safety == QM) can not be linked against a (parent) safety requirement (Safety != QM).

Note: This ensures that safety requirements are properly derived into their children. Also a mix of safe and QM aspects in a parent is avoided by this.
gd_req__req_linkage_safety
Process Requirements
Requirements validity
status: valid
tags: prio_3_automation, check, requirements_engineering
satisfies: wf__req_stkh_req, wf__req_feat_req

Validity attributes (Requirement attribute: vali... (gd_req__req_attr_valid_from) and Requirement attribute: vali... (gd_req__req_attr_valid_until)) shall be checked for correctness (i.e. they denote an existing milestone) and consistent (e.g. the until is not before from) Several of the above checks are not to be executed on requirements not valid in the next milestone, these are TBD
gd_req__req_validity
Process Requirements