Scribd
Upload
2K views1 page

Ears

The document provides an overview of the Easy Approach to Requirements Syntax (EARS) which outlines different types of requirement sentences, including: shall statements to define system responses; event-driven requirements that trigger from preconditions; state-driven requirements for different system states; and requirements to define unwanted behaviors or optional features. It also provides steps for applying EARS such as identifying the requirement type and necessary syntax, reviewing for clarity, and characteristics of good requirements like being unambiguous, traceable, consistent, verifiable and complete.

Uploaded by

el_gallifante
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2K views1 page

Ears

The document provides an overview of the Easy Approach to Requirements Syntax (EARS) which outlines different types of requirement sentences, including: shall statements to define system responses; event-driven requirements that trigger from preconditions; state-driven requirements for different system states; and requirements to define unwanted behaviors or optional features. It also provides steps for applying EARS such as identifying the requirement type and necessary syntax, reviewing for clarity, and characteristics of good requirements like being unambiguous, traceable, consistent, verifiable and complete.

Uploaded by

el_gallifante
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 1

EARS quick reference sheet

Easy Approach to Requirements Syntax

Sentence types

•The <system name> shall <system response>


Ubiquitous •The kitchen system shall have an input hatch.

•When <optional preconditions> <trigger>, the <system> shall <system response>


Event-driven •When the chef inserts a potato to the input hatch, the kitchen system shall peel the potato.

•While <in a state>, the <system> shall <system response>


State-driven •While the kitchen system is in maintenance mode, the kitchen system shall reject all input.

Unwanted •If <optional preconditions> <trigger>, then the <system> shall <system response>
behavior •If a spoon is inserted to the input hatch, then the kitchen system shall eject the spoon.

•Where <feature>, the <system> shall <system response>


Optional •Where the kitchen system has a food freshness sensor, the kitchen system shall detect rotten foodstuffs.

Steps to take in applying EARS


Identify whether you Identify compound
are working with a requirements, i.e. Identify the acting
Analyse the needed
requirement, or whether the system, person or sentence type(s)
something else (e.g. note requirement needs to process
or example) be split

Identify possible
Analyse the translated missing requirements
Review requirements if requirements for
Iterate as required • E.g. 2 states and 2 events
possible ambiguity, conflict usually produce 4
and repetition requirements

Some characteristics of a good requirement

Unambiguous Traceable Consistent Verifiable Complete


•One •Has unique •Doesn't conflict •Possible to check •Not lacking
interpretation identifier other system meets relevant
requirements requirement information

You might also like