Understanding the Easy Approach to Requirements Syntax (EARS) and How to Better Specify Requirements for AI

Author: MakerNeo
LAST UPDATED: 2025-10-11 02:48:08
TAG:

Index

Understanding the Easy Approach to Requirements Syntax (EARS) and How to Better Specify Requirements for AI

In software development and systems engineering, the quality of requirements directly impacts project success. Ambiguous or unclear requirements can lead to errors, increased costs, and project delays. The Easy Approach to Requirements Syntax (EARS) is a lightweight, structured method designed to improve requirement writing through standardized natural language expressions. Developed by Alistair Mavin and the Rolls-Royce PLC team in 2009, EARS was initially created to analyze airworthiness regulations for aircraft engine control systems and was first presented at the IEEE RE09 conference. Since then, it has been widely adopted, particularly in large organizations and academic institutions.

Definition and Core Principles of EARS

EARS leverages the familiarity of natural language while using specific sentence structures and keywords (e.g., "when," "if," "then") to constrain requirement expressions, reducing ambiguity and inconsistency. It requires no specialized tools, has a low training cost (typically half a day or less), and is suitable for both beginners and experienced engineers. This makes EARS a practical tool in requirements engineering, particularly for complex system requirements. Studies show that EARS effectively reduces errors in natural language requirements, such as ambiguity, verbosity, and logical incompleteness. By providing a standardized structure, it ensures consistency across requirements written by different authors while remaining easy for stakeholders to understand and review.

Development Background

EARS was developed in response to Rolls-Royce PLC’s need to analyze airworthiness regulations for aircraft engine control systems. Alistair Mavin and his team identified that these regulations often followed similar patterns but contained potential ambiguities and complexities. By extracting and simplifying these requirements, they created the EARS framework, which was published at the IEEE RE09 International Requirements Engineering Conference in 2009. Since then, EARS has been adopted by numerous global organizations, including Bosch, Daimler, Dyson, Honeywell, Intel, NASA, Rolls-Royce, and Siemens. Additionally, many universities in countries such as China, France, Germany, Sweden, the UK, and the US have incorporated EARS into their curricula, reflecting its widespread acceptance in both academia and industry.

Advantages of EARS

EARS offers the following 10 key benefits, validated through practical application, particularly in large organizations:

  1. Reduces or eliminates errors in natural language requirements.
  2. Makes requirements simpler, consistent, and easier to understand, free from stylistic bias.
  3. Requires short training time (half a day or less), aligns with test cases, and is easy to review.
  4. Helps both novices and experts write better initial drafts, reducing iterations.
  5. Complements models like activity diagrams and state diagrams, enhancing requirement visualization.
  6. Improves individual and team communication, reduces project risks, and enhances team mobility.
  7. Suitable for experienced engineers, providing a clear framework.
  8. Handles complex requirements systematically, making them clearer and implementable.
  9. Has a low learning curve, allowing new users to improve quickly.
  10. Validated by large organizations like Bosch, Daimler, Dyson, Honeywell, Intel, NASA, Rolls-Royce, and Siemens.

Compared to unconstrained natural language requirements, EARS significantly reduces variability and risks during development, minimizing rework and cost increases due to unclear requirements. For example, unconstrained natural language requirements may lead to misinterpretation and implementation errors, whereas EARS ensures testability and clarity through structured sentence patterns (e.g., "When..., the system shall...").

EARS Syntax and Patterns

EARS provides a universal syntactic structure as follows:

  • General Structure: "While , when , shall ."
  • Rules:
    • 0 or more preconditions
    • 0 or 1 trigger
    • 1 system name
    • 1 or more system responses

Based on this, EARS defines six main patterns, as shown in the table below:

Type Template Example
Ubiquitous The shall The phone’s weight shall be less than XX grams.
State-driven While , the shall While the aircraft is in flight and the engine is running, the control system shall maintain fuel flow above XX pounds/second.
Event-driven When , the shall When the aircraft issues a continuous ignition command, the control system shall initiate continuous ignition.
Optional Feature Where , the shall Where the control system has an overspeed protection feature, before takeoff, the control system shall test the feature’s validity.
Unwanted Behavior If , then the shall If computed airspeed is unavailable, the control system shall use model airspeed.
Complex (Expected behavior) While..., when..., the shall...
(Exceptional behavior) While..., when..., if... the shall...		 While the aircraft is on the ground, when a thrust reverser command is received, the control system shall activate the thrust reverser.

These patterns cover various scenarios in requirements engineering, from simple functional descriptions to complex conditional logic, all effectively expressed through EARS. For example, "When the aircraft issues a continuous ignition command, the control system shall initiate continuous ignition" is a typical event-driven requirement, while "Where the control system has an overspeed protection feature, before takeoff, the control system shall test the feature’s validity" demonstrates the utility of the optional feature pattern.

Practical Applications and Examples

EARS is widely applied, particularly in aviation, automotive, and software development. For instance, Rolls-Royce uses EARS to analyze aircraft engine control system requirements, ensuring clarity and implementability of airworthiness regulations. Organizations like Bosch and Siemens also adopt EARS to improve requirements engineering processes and reduce project risks.

A specific example is requirement clarification: a vague requirement like "The system shall disconnect the network" can be improved with EARS to "When the disconnect button is pressed, the software shall disconnect the network," clearly specifying the trigger and system response. This improvement enhances testability and reduces misunderstandings during development.

Moreover, EARS aligns closely with test cases. For example, "When the aircraft issues a continuous ignition command, the control system shall initiate continuous ignition" can be directly translated into a test scenario, ensuring the system responds correctly under specific conditions.

Example 1: User Login Function

  • Traditional Description:

    "The system should make user login convenient and provide error prompts."

  • EARS Improvement:

    When the user enters a username and password and clicks the "Login" button, the system shall verify the credentials against the database. If verification fails, the system shall display a "Username or password incorrect" prompt.

EARS Type: Event-driven (trigger action) + Conditional (error handling).

Example 2: Data Saving Function

  • Traditional Description:

    "The system should preferably auto-save after user edits."

  • EARS Improvement:

    When the user stops typing in the edit box for more than 5 seconds, the system shall automatically save the current content to the draft folder.

EARS Type: Event-driven (time-triggered).

Example 3: Permission Management

  • Traditional Description:

    "Admins can delete user posts, but regular users cannot."

  • EARS Improvement:

    When a user attempts to delete a post, the system shall check if their role is "admin." If the role is not admin, the system shall display an "Insufficient permissions" prompt and prevent the deletion.

EARS Type: Conditional (permission check) + Event-driven (user action).

Example 4: System Performance Constraint

  • Traditional Description:

    "Page loading shouldn’t be too slow."

  • EARS Improvement:

    The system shall return page content within 2 seconds of a user request (excluding network latency).

EARS Type: Constraint (quantified metric).

Summary of EARS Key Improvements

  1. Eliminate Ambiguity:
    • Traditional: "preferably," "convenient" → EARS: "shall," "must."
  2. Specify Triggers:
    • Traditional: Omits trigger timing → EARS: "when...," "if..."
  3. Decompose Complex Requirements:
    • Traditional: Multiple requirements in one sentence → EARS: Separate descriptions (validation + prompts).
  4. Quantify Non-Functional Requirements:
    • Traditional: "not too slow" → EARS: "within 2 seconds."

This makes requirements much clearer. In the AI era, using EARS when communicating requirements to AI ensures clarity and precision. With advanced models, this approach can give you a significant edge over others.

Other Requirement Description Methods

In addition to EARS (Easy Approach to Requirements Syntax), several other structured requirement-writing methods aim to enhance clarity, testability, and traceability. Below are some common methods and their characteristics:

1. User Stories

Applicable Scenarios: Agile development, product requirement descriptions
Format:

As a [role], I want [function], so that [value/purpose].

Example:

Traditional Description: "The system should allow password resets."
User Story Improvement:
As a user who forgot their password, I want to reset my password via email, so that I can regain access to my account.

Advantages:

  • Emphasizes user perspective and value, avoiding technical detail overload.
  • Suitable for requirement breakdown and prioritization in agile development.

Disadvantages:

  • Lacks strict syntactic constraints, potentially leading to ambiguity.
  • Often requires supplementary acceptance criteria to clarify details.

2. Use Cases

Applicable Scenarios: System interaction process descriptions
Format:

  • Actor: Who performs the action?
  • Main Flow: Steps under normal conditions.
  • Alternative Flow: Exceptions or alternative scenarios.

Example:

Traditional Description: "Users log into the system."
Use Case Improvement:
Use Case Name: User Login
Actor: Registered User
Main Flow:

  1. The user enters a username and password.
  2. The system validates the credentials.
  3. The system displays the homepage.
    Alternative Flow:
    • A1: Validation fails → The system displays a "Username or password incorrect" prompt.

Advantages:

  • Suitable for describing complex interaction flows.
  • Highly structured, aiding developers in understanding business logic.

Disadvantages:

  • Time-consuming to write, not ideal for simple requirements.
  • Can result in overly detailed documentation.

3. Gherkin Syntax (Behavior-Driven Development, BDD)

Applicable Scenarios: Automated testing, Acceptance Test-Driven Development (ATDD)
Format:

Given [initial condition],
When [trigger event],
Then [expected outcome].

Example:

Traditional Description: "The shopping cart should calculate the total price."
Gherkin Improvement: 

Scenario: Calculate shopping cart total  
  Given the user has added 3 items to the cart  
  When the user clicks the "Checkout" button  
  Then the system shall display the correct total price (including tax)

Advantages:

  • Directly maps to automated test code (e.g., Cucumber).
  • Enables collaboration between business and technical teams, reducing communication errors.

Disadvantages:

  • Only suitable for testable requirements, not for constraints or architectural requirements.

4. Requirement Patterns

Applicable Scenarios: Complex system requirements (e.g., security, performance)
Format: Standardized templates based on industry best practices.

Example (Security Requirement Pattern):

Traditional Description: "The system should prevent unauthorized access."
Pattern Improvement:
The system shall implement JWT-based authentication for all sensitive API endpoints, returning HTTP 403 for requests without a valid token.

Advantages:

  • Provides standardized expressions, reducing ambiguity.
  • Suitable for compliance requirements (e.g., GDPR, ISO 27001).

Disadvantages:

  • Requires team familiarity with patterns, leading to a higher learning curve.

5. Decision Tables

Applicable Scenarios: Complex business rules (e.g., pricing, risk control logic)
Format: Tables describing system behavior under different conditions.

Example (E-commerce Discount Rules): User Type Order Amount Promotion Discount Rate
New User ≥100 CNY None 5%
Regular User ≥200 CNY Double 11 15%

Advantages:

  • Visually represents complex condition combinations.
  • Facilitates test case design.

Disadvantages:

  • Only suitable for scenarios with clear rules and limited conditions.

How to Choose the Right Method?

Method Applicable Scenarios Key Advantages
EARS Functional requirements (software/hardware) Simple syntax, strong testability
User Stories Agile development, product requirements Emphasizes user value
Use Cases Complex interaction flows (e.g., banking systems) Highly structured, clear
Gherkin Automated testing requirements Directly generates test code
Requirement Patterns Compliance, security requirements Standardized, reduces ambiguity
Decision Tables Multi-condition business rules Visually represents logic combinations

If your requirement is "The system should do Y under condition X," EARS is the best choice; if it’s "What does the user want?" user stories are more suitable; if it’s "How to test this feature?" Gherkin is ideal.

Recommended Combinations:

  • Use user stories for high-level requirements, then refine with EARS or Gherkin for detailed rules.
  • Use decision tables for complex business logic, complemented by use cases for interaction flows.

Hopefully, these methods will help you write clearer, actionable requirements more efficiently! 🚀