EARS stands for Easy Requirements Specification.  It is a simple template used to specify Systems requirements and is particularly well suited for the textual specification of systems requirements for cyberphysical systems.  We specify requirements using EARS in lieu of more traditional user stories.  EARS is well suited for specifying  requirements for a cyberphysical system — while allowing us to retain many aspects of an agile project.  EARS was  developed by Alistair Mavin whilst at Rolls Royce.   Details of EARS can be found here and references are provided at the bottom of this page.

EARS requirements are structured as follows:  <optional preconditions> <optional trigger> the <system name> shall <system response>

There are five specific EARS templates – which we show here with example requirements.

  • Ubiquitous:
    An ubiquitous requirement is always active. 
    Template: The <component name> shall  <response>
    – A sUAS shall not fly outside of the designated flight zone.
    – Distances computed between two sets of coordinates shall account for curvature of the earth.
  • Event Driven: (keyword: when)
    Describes the required response to a triggering event.
    Template: When<trigger> the <system name> shall <system response>
    – When a sUAS loses contact with central control for more than minContactLost seconds and less than maxContactLost seconds it shall halt progression to its targeted waypoint and hover in place. 
    – When a low battery is detected in a sUAS all registered UI clients shall be notified.
  • State Driven: (keyword: while)
    Describes the required response for a specified state.
    Template: While <in a specific state> the <system name> shall  <system response>
    – While in flight each managed sUAS shall report its current coordinates each healthReportingPeriod seconds.
    – While an active sUAS is registered to a ground control station (GCS), the GCS shall monitor the sUAS’ current coordinates and forward them to the Dronology Central Control (DCC).
  • Optional: (keyword: where)
    Describes required responses if a specific feature is included.  Therefore particularly useful for product lines.
    Template: Where <feature is included> the <system name> shall <system response>
    – Where a sUAS has collision avoidance capabilities the sUAS will adjust its own flight path to avoid obstacles in its immediate vicinity.
    – Where a sUAS is equipped with a camera and tasked with streaming video it shall register itself with a GCS capable of handling video streams.
  • Unwanted Behavior: (keyword: if)
    Describes the required response when unwanted behavior occurs.
    Template: If <optional preconditions>, then the <system name>  shall <system response>
     – If a sUAS battery drops below the safeBatteryFlyingLevel the sUAS shall land at the nearest safeLandingSite.
    If central control detects a sUAS flying erratically, other sUAS in the surrounding airspace will be directed to increase their minimumSeparationDistance* from the affected sUAS.  (Actual distances will be defined via formulas in design specifications).
  • Hybrid: (multiple keywords)
    – If wind gusts are recorded above the desiredWindVelocity when a sUAS is awaiting permission to takeoff then the flight shall be delayed until no further wind gusts over desiredWindVelocity have been observed for windWaitingPeriod minutes.


Alistair Mavin, Philip Wilkinson, Adrian Harwood, Mark Novak: Easy Approach to Requirements Syntax (EARS). RE 2009: 317-322
– Levi Lúcio, Salman Rahman, Chih-Hong Cheng, Alistair Mavin: Just Formal Enough? Automated Analysis of EARS Requirements. NFM 2017: 427-434
Alistair Mavin, Philip Wilkinson, Sarah Gregory, Eero Uusitalo: Listens Learned (8 Lessons Learned Applying EARS). RE 2016: 276-282

The design specification bridges the gap between requirements and the lower level design and implementation. It describes how a specific requirement will be achieved.  Here we illustrate the process through providing examples in which requirements are elaborated through the design specification.

(To do: Add a better example for a safety-related requirement and clean up these design defs).

Example 1:
Requirement: Where a potential collision is detected between two or more sUAS the collision avoidance manager shall send avoidance directives to each sUAS.

D1When a potential collision is detected between two or more sUAS, the collision avoidance controller shall compute a collision avoidance plan.
D2When a collision avoidance plan is activated, the controller shall transmit commands to all impacted sUAS using velocity vectors (instead of waypoints).

Example 2:
Requirement:  While in edit mode, a user may create and save a flight route composed from a series of waypoints.

D1When flightRoute edit mode is active, the user shall create a new waypoint by right clicking on the map.
D2When a new waypoint is created, it shall be added to the end of the flight route.
D3The user shall reorder waypoints using mouse drag actions within a window listing waypoints for the route.
D4The starting waypoint, ending waypoint, and intermediate waypoints shall be assigned colors according to a user defined (or default) color scheme.
D5When a new waypoint is created, it shall be added to the end of the flight route.
D6Each pair of waypoints shall be connected by a straight line.

Requirements Specification:
The requirements specification is a structured document that describes the services that a system is expected to provide.   These include functions, performance, qualities, and constraints.  Requirements specify what the system must do without describing how the system objectives will be achieved.  Requirements therefore provide the “what” that guides the design.  The requirements must be described precisely in order to serve as a contract between the customer (i.e., the system procurer) and the software development team.  In an agile environment, the requirements provide a clear overview of features to be delivered.

Design Specification:
The design specification describes how the requirements are to be achieved.  It includes descriptions of the architecture, specific constraints on the design, and therefore describes  “how” requirements are to be met.

System goals and constraints that are specified in the requirements must be traceable to the design specification, and from there to the source code.

Further Reading:
Ivy Hooks provides an excellent explanation about the role of requirements vs. design specifications here.

A Requirement Specification addresses the “what“, and a Design Specification addresses the “how“.