Process Requirements#

Requirements Structure
status: valid
security:
safety:
status: valid
tags: structure, requirements_engineering

Requirements shall be hierarchically grouped into different levels.

Following levels are defined:

  • Stakeholder requirement

  • Feature requirement

  • Component requirement

  • Assumption of use requirement

  • Process requirement

Process Requirement Attributes#

Requirement attribute: UID
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

Each requirement shall have a unique ID. It shall be in a format which is also human readable and consists of

  • type of requirement

  • last part of the feature tree

  • keyword describing the content of the requirement.

The naming convention is defined here: Naming Convention for UIDs

Requirement attribute: title
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

The title of the requirement shall provide a short summary of the description. This means that e.g. the word “shall” must not be used here.

Requirement attribute: description
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

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.

Requirement attribute: type
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

Each requirement shall have a type of one of following options:

  • Functional

  • Interface

  • Process

  • Legal

  • Non-Functional

Requirements attribute: security
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

Each requirement shall have a security relevance identifier:

  • Yes

  • No

Requirement attribute: safety
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

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

  • QM

  • ASIL_B

  • ASIL_D

Requirement attribute: status
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

Each requirement shall have a status:

  • valid

  • invalid

Requirement attribute: rationale
status: valid
security:
safety:
status: valid
tags: attribute, mandatory, requirements_engineering

Each stakeholder requirement shall provide a in the attribute rationale the reason why that the requirement is needed.

Process Requirement Linkage#

Requirement Linkage
status: valid
security:
safety:
status: valid
tags: attribute, automated, requirements_engineering

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

  • stakeholder requirements <-> feature requirements

  • feature requirements <-> component requirements

  • workflow <-> process requirements

Requirement attribute: requirement covered
status: valid
security:
safety:
status: valid
tags: attribute, automated, requirements_engineering

It shall be possible to specify the requirement coverage.

  • Yes

  • No

Requirement attribute: link to implementation
status: valid
security:
safety:
status: valid
tags: attribute, automated, requirements_engineering

It shall be possible to link requirements to code and include a link to github to the respective line of code in an attribute of the requirement.

Requirement attribute: test covered
status: valid
security:
safety:
status: valid
tags: attribute, automated, requirements_engineering

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

  • Yes

  • No

Requirement attribute: versioning
status: valid
security:
safety:
status: valid
tags: attribute, automated, requirements_engineering

It shall be possible to provide a versioning for requirements. It shall be possible to detect if any of the mandatory attributes differ from the versioning: Requirements mandatory attr... (gd_req__req__attr_mandatory)

A more detailed description of the concept can be found here: Requirement attribute: vers... (gd_req__req__attr_hash)

Process Requirements Checks#

Requirements mandatory attributes provided
status: valid
security:
safety:
status: valid
tags: attribute, check, requirements_engineering

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: rationale

Requirement attribute: safety

Requirement attribute: status

Requirement attribute: type

Requirement attribute: UID

Requirement attribute: description

Requirements attribute: security

Requirement attribute: title

Requirements no weak words
status: valid
security:
safety:
status: valid
tags: attribute, check, requirements_engineering

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

Requirements linkage level
status: valid
security:
safety:
status: valid
tags: attribute, check, requirements_engineering

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

Traceability Concept for Requirements

Requirements linkage architecture
status: valid
security:
safety:
status: valid
tags: attribute, check, requirements_engineering

It shall be checked if every feature- and component requirement is linked at least to one architectural element.

Requirements linkage safety
status: valid
security:
safety:
status: valid
tags: attribute, check, requirements_engineering

It shall be checked that safety requirements (Safety != QM) can only be linked against safety requirements.