Formulating requirements correctly (ISO 29148, EARS)

Good requirements are the basis for verifiable results. The standard ISO/IEC/IEEE 29148 describes what makes a good requirement and how requirements relate across several levels. ETRM reflects both: with the ISO 29148 project profile, typed links and the wording check.

Two levels: problem and solution

Level	Question	Example from the sample project
Stakeholder requirement (problem space)	What does the customer or user want to achieve?	“The battery shall be chargeable at a 350 kW charging station from 10 % to 80 % in at most 20 minutes.”
System requirement (solution space)	What must the system technically achieve for this to succeed?	“The BMS shall specify the permissible charging current depending on cell temperature and state of charge according to the 800 V charging profile.”
Test case (evidence)	How is it verified that the requirement is met?	“Fast charging 10–80 % at 25 °C on the test charger, measure charging time.”

System requirements are attached to the stakeholder requirement with is derived from, test cases with verifies to the requirement they prove. This way you can always see whether every customer requirement is implemented and every system requirement is verified (Traceability).

Characteristics of a good requirement

The standard names characteristics against which you can measure each individual requirement:

Characteristic	Check question
necessary	Would something important be missing if the requirement were deleted?
unambiguous	Can it be understood in only one way?
complete	Does it contain all information, including conditions and limits with units?
singular	Does it contain exactly one statement?
feasible	Can it be implemented with reasonable effort?
verifiable	Can it be objectively demonstrated whether it is met?
correct	Does it reflect the need correctly?
solution-neutral (at stakeholder level)	Does it describe the goal rather than a particular solution?

Obligation

• shall: binding requirement; deviations only via change request.
• should: recommendation or goal. It is not binding as an obligation, which is why the wording check points it out.
• may: option.
• could, might and as far as possible are not binding and therefore not verifiable.

Sentence templates with EARS

EARS (Easy Approach to Requirements Syntax) gives sentences a fixed form. This makes condition, trigger and response visible and avoids ambiguity. In the editor you insert the patterns via Template … and replace the placeholders in angle brackets.

Pattern	Template	Example
Ubiquitous	The <system> shall <response>.	The BMS shall measure every cell voltage with ±2 mV.
Event-driven	When <trigger>, the <system> shall <response>.	When a crash signal is received, the BMS shall open the main contactors within 50 ms.
State-driven	While <state>, the <system> shall <response>.	While the cell temperature is below 0 °C, the BMS shall limit the charging current to 0.2 C.
Unwanted behaviour	If <unwanted event>, then the <system> shall <response>.	If the insulation resistance falls below 500 Ω/V, then the BMS shall report an insulation fault.
Optional feature	Where <feature is included>, the <system> shall <response>.	Where the 800 V variant is installed, the BMS shall support charging at 350 kW.
Complex	While <state>, when <trigger>, the <system> shall <response>.	While the vehicle is charging, when the cell temperature exceeds 55 °C, the BMS shall halve the charging current.

Typical mistakes

Mistake	Why it is a problem	Help in ETRM
Vague terms (“fast”, “user-friendly”)	not verifiable	wording check, acceptance criterion as an attribute
Several statements in one requirement	partial fulfilment cannot be shown	hint “Several statements”, split
Open points (“TBD”)	approval of unclear content	hint “Open point”, filter in the table
System requirement without origin (gold plating)	effort without customer benefit	coverage “is derived from”, filter “Missing link”
Requirement without evidence	fulfilment not proven	coverage “is verified by” in the metrics
Circular references	origin can no longer be traced	hierarchical link types prevent cycles

More example wordings by topic can be found in the requirements catalog.