Requirement adding

Requirement adding Guidelines

Scope

The scope of the requirements are the kernel functionality. The requirements shall reflect the actual state of the implementation in requirements because of the route 3s approach of the projects safety effort.

Consistency:

• Consistency across all requirements. The language and choice of words shall be consistent and remain so.

Levels of Requirements:

• System Requirements
• Software Requirements

UID Handling:

• UIDs are freely selectable for development of the Requirements.
• Final UIDs are distributed during the requirement finalization process.

Requirement Types:

• Functional
• Non-Functional

Requirement titles:

• Use short and terse requirement titles.

The short titles are easier to read and navigate when exploring the table of contents of a document which simplifies understanding of the overall document structure. Example: use "Reset Count" instead of "Counting Semaphores Exposes Ability to Reset Count to Zero".

Characteristics of a Good Requirement:

• Unambiguous
• Testable (verifiable)
• Clear (concise, terse, simple, precise)
• Correct
• Understandable
• Feasible (realistic, possible)
• Independent
• Atomic
• Necessary
• Implementation-free (abstract)

Characteristics of a set of Requirements:

• Consistent
• Non redundant
• Complete

Pull Request:

• Adhere to the contribution guidelines of the Zephyr Project: https://docs.zephyrproject.org/latest/contribute/guidelines.html
  • As long as they are applicable to the requirements repository.
• Avoid creating larger commits that contain both trivial and non-trivial changes.
• Avoid moving and changing requirements in the same commit.