Safety Requirements

Introduction

The safety committee leads the effort to gather requirements that reflect the actual state of the implementation, following the route 3s approach of the project’s safety effort. The goal is NOT to create new requirements to request additional features for the project.

The requirements are gathered in the separate repository: Requirement repository

Guidelines

Below are the guidelines for the requirements repository and the expectations of the safety committee when adding requirements to the repository.

Scope

The scope of the requirements covers the KERNEL functionalities.

Consistency

Maintain consistency across all requirements. The language and choice of words shall be consistent. (See: Syntax)

Levels of requirements in the repository

System Requirements

System requirements describe the behaviour of the Zephyr RTOS (= the system here). They describe the functionality of the Zephyr RTOS from a very high-level perspective, without going into details of the functionality itself. The purpose of the system requirements is to get an overview of the currently implemented features of the Zephyr RTOS. In other words a person writing these requirements usually has some knowledge of the Zephyr RTOS Project as the requirements are specific to an RTOS.

Software Requirements

Software requirements refine the system-level requirements at a more granular level so that each requirement can be tested. These requirements define the specific actions the feature shall be able to execute and the behavior of the feature.

Requirement UID (Unique identifier) Handling

The tool used to manage requirements, strictDoc, is responsible for handling the Unique Identifier (UID) associated with each requirement. To manage UIDs, follow these steps:

  1. Don’t add a requirement UID and UID field for new requirements

  2. After completing work on the new requirements execute: strictDoc manage auto-uid .

  3. Establish links between the requirements with the new attributed UIDs if needed

After doing this, the requirements are ready and a pull request can be created. The CI in the PR will check if the requirements UIDs are valid or if there are duplicates in it. If there are duplicates in the PR, these need to be resolved by rebasing and re-executing the steps above.

Requirement Types

  • Functional

  • Non-Functional

Requirement title convention

Use short and succinct requirement titles.

Pull Request requirement repository

  • Adhere to the Contribution Guidelines of the Zephyr Project.

    • As long as they are applicable to the requirements repository.

  • Avoid creating large commits that contain both trivial and non-trivial changes.

  • Avoid moving and changing requirements in the same commit.

Characteristics of a good requirement

  • Unambiguous

  • Verifiable (e.g. testable for functional requirements)

  • Clear (concise, succinct, simple, precise)

  • Correct

  • Understandable

  • Feasible (realistic, possible)

  • Independent

  • Atomic

  • Necessary

  • Implementation-free (abstract)

Characteristics of a set of requirements

  • Complete

  • Consistent

  • Non redundant

Syntax

  • Use of a recognized Requirements Syntax is recommended.

    • EARS is a good reference. Particularly if you are unfamiliar with requirements writing.

    • Other formats are accepted as long as the characteristics of a requirement from above are met.