Guideline

Requirements Guideline		status: valid security: safety:
status: valid tags: requirements_engineering
gd_guidl__req__engineering		Process Guideline

This document describes the general guidances for requirements based on the concept which is defined Concept Description.

General Hints

Templates

Need templates displaying the correct syntax and attribute definition are provided for each requirement type. For VScode code snippets are included in the workspace settings which will provide in-place the definition of requirements including all mandatory attributes:

Table 6 Overview

Requirement Level	Template	VS Code Snippet
Stakeholder Requirements	Stakeholder Requirements Te...	stkh_req_t
Feature Requirements	Feature Requirements Templates	feat_req_t
Component Requirements	Component Requirements Temp...	comp_req_t
AoU Requirements	AoU Requirement Templates	aou_req_t
Process Requirements	Process Requirements Templates	gd_req_t

Additionally for the formulation of requirements following template is available: Requirement Formulation Tem...

Attributes

For all requirements following mandatory attributes need to be defined:

Overview of 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

• Title and description: For the formulation of requirements following template shall be used Requirement Formulation Tem...

• ID: The naming convention for the ID is defined here <TBD>.

• Furthermore the requirements need to be versioned. Therefore a hash value of the requirement will to be calculated. The concept is described: Traceability Concept for Requirements

• For the remaining attributes only predefined values can be used. A more detailed description can be found here: Attributes of the Requirements

Checks

During the sphinx build checks will be performed on the requirements. Those are specified via following process requirements:

Overview checks for requirement

Title	ID
Requirements no weak words	gd_req__req__attr_desc_weak
Requirements mandatory attributes provided	gd_req__req__attr_mandatory
Requirements linkage architecture	gd_req__req__linkage_architecture
Requirements linkage level	gd_req__req__linkage_fulfill
Requirements linkage safety	gd_req__req__linkage_safety

Workflow for Creating a Requirement

This section describes in detail which steps need to be performed to create a requirement based on Fig. 2

Table 7 Workflow for creating a requirement

Step	Description	Responsible
1.	Create parent requirement	Contributor
2.	Review parent requirement	Committer
	Merge valid parent requirement to main branch	Committer
4.	Derive child requirement and establish traceability	Contributor
5.	Review child requirement	Committer
	Merge valid child requirement to main branch	Committer
7.	Generate linkage document	Contributor
8.	Perform formal review of requirements	Committer

Create parent requirement

In this step the parent requirements shall be created. Stakeholder- and feature requirements should be generated in the score repository.

Therefore following guidelines are available:

• Branch Naming Conventions

• Git Guidelines

• Requirement Templates

Review parent requirement

As soon as the parent requirements are in a mature state it can be reviewed according to <TBD> and merged into the main branch of the score repository. However this is not the formal inspection of the requirements, this will follow in an upcoming step.

Following roles should be included in the review:

• Safety Manager

• Security Manager

• [[title]]

Derive child requirement and establish traceability

In an upcoming step the child requirements shall be derived from the parent requirements. Feature requirements shall be placed in the score repository again, while component requirements shall be placed in the module repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.

Following guidelines are available:

• Branch Naming Conventions

• Git Guidelines

• Requirement Templates

Review child requirement

As soon as also the child requirements are in a mature state they can be reviewed according to <TBD> and merged into the main branch of the respective repository. Again this is not a formal inspection as it will be performed in a later step.

Generate linkage document

As parent and child requirements are now available the linkage of the requirements can be established. This should be performed as described in Coverage of requirements

Perform formal review of requirements

In a last step the requirements shall be formally inspected. Therefore a checklist exists: Requirements Inspection Che...

Following roles should be included in the review:

• Safety Manager

• Security Manager

• [[title]]

Workflow for Creating and Linking Assumption of Use (AoU)

An AoU is a category of requirement which is originates from a safety concept of an architectural element (and thus it is confirmed by a safety analysis). As it can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the module. In Safety Elements out of Context (SEooC) the AoUs will normally be part of the safety manual. In this project (as it develops SEooCs) these AoUs are created both internally and externally - if existing SEooCs are integrated into the platform (e.g. a qualified Operating System). For AoU which arise from Score specific modules the template is almost identical to the one for feature/component requirements. The only difference is that it defined such that the attribute “satisfies” is replaced with the attribute “mitigates” (see picture below). For externally provided AoUs of course the sentence template cannot be taken into account, as these are only imported from an external safety manual. It is also not possible to link it to other development artifacts via the attribute “mitigates”.

AoUs can be of different class and shall be handled by tracing those

• to Feature/Component Architecture (via satisfies), if those are on Component Level and can be fulfilled there

• to Stakeholder Requirements (via satisfies), if AoU are of general nature and can be fulfilled by platform

• or by containing those in Platform Safety Manual, if AoU cannot be fulfilled by platform but need to be satisfied by the user of the platform

Fig. 4 AoU Traceability

Fig. 4 is an extension of the workproduct traceability to show the handling of (external) AoU. Note that the component level displayed in green shows two components - on the right the one exporting AoU to be fulfilled by others, left the component which fulfills and exports AoU (but without the traceability shown on the right to reduce complexity).