VerReq_1_0 |
Is this requirement clearly comprehensible and unambiguous? |
To make sure the requirement can be analysed it must be easy to understand and leave no room for (functional) interpretation. |
Avoid vague statements such as some, sufficient, typical, many, several, few, ….
Statements like The Zephyr Kernel should provide functionality xyz where possible are not accurate enough and leave room for interpretation.
Also should must be replaced with the unambigous shall. The where possible must be replaced with a definition where the author of the requirement wants the functionality to be provided.
This can be a list of cases, system states or other conditions. As long as they are clearly defined. |
VerReq_1_1 |
Is this requirement atomic? |
The requirement really must only describe one thing that needs to be fulfilled. Otherwise things like safety analysis,
unique linking to architectural components and implementation and verifiability can be impaired. |
Statements like The signal a shall switch on and off the yellow LED and the error state shall be indicated by switching on the red LED
are not atomic. This needs to go into two requirements - REQ1: The signal a shall switch on and off the yellow LED. and REQ2: The error state shall be indicated by switching on the red LED.
This also can be supplemented by a REQ3(variant a): Yellow LED and the red Error LED must be separate or
REQ3(variant b): Yellow LED and red Error LED can be combined in case of TBD. |
VerReq_1_2 |
Is the requirement internally consistent? |
The requirement itself must be fully consistent within itself. |
Statements like The system shall use a preemtpive RTOS to guarantee deterministic task scheduling.
The system also need to ensure that all tasks, including low-priority background logging tasks, complete without preemption to preserve data integrity. are contradicting.
Stuff like this must be avoided. If both options shall be available, you must define the conditions for these options and how to configure the options. |
VerReq_1_3 |
Is the requirement feasible, achievable and verifiable? |
Requirements are not a fantasy wish-list, they need to be able to reach with reasonable matter (although what is reasonable can differ
between projects for sure). So generally this means something that sounds good on paper but is technically impossible,
internally contradictory, or violates fundamental constraints of the system. Verifiable here means that you need to be able to verify, either by test, (code-) review, analysis or other means that this requirement has been met. |
A bad example is e.g. The RTOS shall guarantee zero‑latency interrupt handling for all devices under all conditions.,
which is physically impossible, as no hardware can respond in literally zero time.
Better would be something more concrete like
The RTOS shall guarantee an interrupt latency of ≤ 5 µs on the target HW architecture at 80 MHz under maximum system load. |
VerReq_1_4 |
Is the requirement complete? |
Is all information that needs to be defined to clearly state the intention of the requirement available? |
The statement must either clearly state all needed data and information or give a reliable reference to where to find that data.
This means that referenced data sources have to be under control of the requirement author or stakeholder,
references that might change over time, like internet URLs to external sources are not suitable. |
VerReq_1_5 |
Is the requirement’s definition free from any implementation? |
Requirements must describe the “what” not the “how” something is done. There are corner cases where the requirement intentionally restricts the implementation variants,
usually for some design reasons, these reasons then must be stated in the requirement rational or comment (whatever is used) |
Avoid statements like The RTOS shall use a priority-based preemptive scheduler implemented with a round-robin algorithm for tasks of equal priority,
consider instead to focus on the functional needs
The RTOS shall support task scheduling that ensures higher-priority tasks can preempt lower-priority tasks, and tasks of equal priority are scheduled in a manner that prevents starvation. |
VerReq_1_6 |
Is the (safety/security) criticality of the requirements defined? |
All requirements that affect a function that can compromise Zephyr’s safety (or security) integrity needs to be marked as safety (security) critical so it can be handled accordingly. |
Currently there is no specific way defined to mark a function as safety or security relevant, a requirement’s or function’s relevance is based on the scope that it is defined. |
VerReq_1_7 |
Are there verification and/or acceptance criteria for each requirement defined? |
Each requirement must be verifiable. If you cannot define acceptance criteria for your requirement, the requirement needs to be reconsidered and maybe defined differently.
Acceptance criteria must at least be derivable from how the requirement is written. |
Make sure there is either a test available or that creating a test is planned. Evaluate if the test coverage is sufficient for this requirement.
If it is not sufficient, contact the Safety Working Group or Testing Working group to get this addressed. |
VerReq_1_8 |
Are all terms used in this requirement clear to the intended audience? |
This targets both accuracy and comprehensibility of the requirement. It needs to be clear, what is meant by the terms used in this requirement. Terms that have
a special meaning for the project need to be clearly defined in a glossary or along with the requirement. |
The statement The RTOS shall support IPC mechanisms such as mailboxes and semaphores for task synchronization could be problematic,
as the audience (testers, managers, POs etc.) might not be familiar with IPC or even what is meant by mailbox or semaphores in the context of an RTOS.
If there is no glossary that explains these terms to all stakeholders, consider phrasing this requirement more like
The RTOS shall provide mechanisms that allow tasks to exchange data and coordinate their execution, such as message-passing and signaling features. |