Writing better requirements with EARS

EARS stands for "Easy Approach to Requirements Syntax" - a simple approach to formulating requirements. With EARS, employees should finally be able to write good requirements without a great deal of learning effort. In other words, requirements that are clear, precise, testable, comprehensible and correct. Many approaches before EARS had this promise and could not keep it.

There is comparatively little information on EARS in German. How does EARS work, and is it really better than text templates and checklists? And above all: How can we use EARS for German requirements? That's what we're looking at today.

The history of EARS

EARS was founded in 2009 by Alistair Maven and his colleagues at Rolls-Royce PLC. The team used EARS to analyze the regulations for the control system of a jet engine. The regulations contained high-level objectives, a mixture of implicit and explicit requirements at various levels, lists, guidelines and supporting information.

When extracting and simplifying the requirements, they found that the requirements all had a similar structure. Following this structure also increased readability. EARS is the refinement and further development of this pattern. EARS are therefore text templates.

I am actually not a big fan of text templates. However, I would recommend EARS the most, as it is a simple and at the same time very effective template set that does not restrict authors much.

EARS templates for requirements in German

I have found many sources for the English language stencils from EARS. The original source is the website of Alistair Mavenwho also organizes EARS training courses. I also found the Description of QRAwho came up with the idea for the cheat sheet (cover picture, thank you!). The following is my personal translation of the EARS templates into German.

EARS has proved particularly useful for writing English requirements for authors whose native language is not English.

Alistair Maven

But let's be honest, more and more requirements are being written in English, less and less in German. English has established itself as the Lingua Franca established in our world. But this means that more and more people have not learned English as their mother tongue. For these people in particular, EARS is a valuable tool for formulating requirements in English.

General EARS syntax

The clauses of a requirement written in EARS always appear in the same order. The basic structure of an EARS request is:

If , if , then   must be

The EARS rule set states that a request must contain the following: None or more preconditions; None or exactly one trigger; Exactly one system name; One or more system responses.

That is actually all there is to it. Everything else is a variation on this general structure.

Variations

The application of EARS notation produces a small number of typical variations, depending on which clauses we use. These are the following patterns:

Universal requirements

Universal requests are always active, so there is no EARS keyword:

The  must be .

Example: The cell phone must weigh less than 120 grams.

State-dependent requirements

State-dependent requests are active as long as the specified state is true and are identified by the keyword "As long as".

As long as , the   must be

Example: As long as there is no card in the ATM, the ATM must display the message "Insert card to start".

Event-driven requests

Event-driven requirements define how a system must react when a triggering event occurs and are identified by the keyword "As soon as".

As soon as , the   must be

Example: As soon as "Mute" is selected, the laptop must suppress all audio output.

Optional functional requirements

The requirements for optional features apply to products or systems that contain the specified feature and are identified by the keyword "If".

If ,   must be

Example: If the car has a sunroof, the car must have a sunroof control panel on the driver's door.

Undesirable behavioral requirements

Undesirable behavior requirements are used to specify the required system response to undesirable situations and are identified by the keywords "if" and "then".

If , then the   must be

Example: If an invalid credit card number is entered, the website should display the message "Please enter the credit card details again".

Complex requirements

The simple building blocks of the EARS patterns described above can be combined to specify requirements for a more extensive system behavior. Requirements that contain more than one EARS keyword are referred to as complex requirements.

As long as , As soon as , the  must

Example: As long as the aircraft is on the ground and as soon as reverse thrust is activated, the engine control system must activate reverse thrust.

Complex requirements for undesired behavior also include the if-then keywords.

Keywords

I'm sure I'll get a comment or two regarding the suggested keywords. "Must" the system or "shall" the system...? Which is better, "as long as" or "while"? Do we have a "system response" or "system reaction"?

My personal opinion: It doesn't matter as long as a team consistently applies the same conventions.

Conclusion

In the end, EARS are just text templates for requirements. Therefore, the templates from ISO/IEC/IEEE 29148:2018, IREB or Master templates the obvious alternatives. Interestingly, these sources all mention EARS, but without going into more detail.

But in my opinion, EARS has an important advantage: EARS is as simple as possible, but not simpler. EARS can be summarized on one page. The master template book is 50 pages long.

Cover picture inspired by QRA