A Practical Guide to Writing Better Requirements

Poor requirements are one of the leading causes of project delays, cost overruns, verification failures, and customer dissatisfaction. Yet many engineering teams still rely on informal statements that are ambiguous, incomplete, or difficult to verify.

This is where EARS comes in.

The Easy Approach to Requirements Syntax (EARS) is a structured method for writing clear, concise, and testable requirements. Originally developed by Rolls-Royce and later popularized through industry adoption, EARS provides a simple framework that helps engineers write better requirements without requiring extensive training in formal methods.

Whether you're developing aerospace systems, medical devices, automotive software, industrial controls, or AI-enabled products, EARS can dramatically improve the quality of your requirements.

The Problem with Traditional Requirements

Consider the following requirement:

The system should quickly notify the operator when a fault occurs.

At first glance, it appears reasonable. However, several questions immediately arise:

• What does "quickly" mean?
• What types of faults are included?
• How is the notification presented?
• Can the requirement be objectively verified?

Different engineers may interpret this requirement differently, leading to inconsistent implementations and difficult verification activities.

Requirements like these create ambiguity, increase development risk, and often result in costly rework later in the project lifecycle.

What Makes a Good Requirement?

Before discussing EARS, it is important to understand what constitutes a good requirement.

A well-written requirement should possess several key characteristics:

• Atomic – expresses a single behavior, capability, or constraint.
• Unambiguous – can only be interpreted one way by all stakeholders.
• Complete – contains all information necessary to understand the required behavior.
• Consistent – does not conflict with other requirements.
• Verifiable (Testable) – can be objectively verified through inspection, analysis, demonstration, or test.
• Feasible – can realistically be implemented within technical, cost, and schedule constraints.
• Necessary – provides value and supports a stakeholder, system, or regulatory need.
• Traceable – can be linked to its source, design elements, verification activities, and higher-level requirements.
• Solution Independent – specifies what is required rather than how it must be implemented whenever possible.

Many organizations struggle with requirements because engineers naturally write in free-form language, which often leads to ambiguity, multiple interpretations, and requirements that are difficult to verify. EARS helps address many of these challenges by providing a simple and consistent structure for writing requirements.

What Is EARS?

EARS is a lightweight requirements-writing methodology that uses predefined sentence structures to eliminate ambiguity and improve consistency.

Rather than allowing every requirement to be written differently, EARS provides patterns that guide engineers toward clear, testable statements.

A Brief History of EARS

The Easy Approach to Requirements Syntax (EARS) was originally developed by Alistair Mavin and colleagues at Rolls-Royce plc while analyzing airworthiness regulations and requirements for complex aerospace systems. Their objective was to create a simple, scalable method for writing requirements that reduced ambiguity while remaining accessible to engineers without extensive training in formal methods.

The approach was first published in 2009 at the IEEE International Requirements Engineering Conference and has since been adopted across aerospace, defense, automotive, rail, medical device, and industrial engineering sectors. Today, EARS is widely regarded as one of the most practical and effective techniques for improving requirements quality while maintaining readability and ease of use.

The most commonly used patterns include:

Ubiquitous Requirements

Requirements that are always true.

Format:

The system shall response.

Example:

The online banking application shall encrypt all customer passwords before storing them in the database.

Event-Driven Requirements

Requirements triggered by a specific event.

Format:

When trigger, the system shall response.

Example:

When a customer submits an order, the e-commerce platform shall generate an order confirmation email.

State-Driven Requirements

Requirements that apply only in a specific system state.

Format:

While state, the system shall response.

Example:

While the medical device is in calibration mode, the system shall disable patient monitoring functions.

Optional Feature Requirements

Requirements associated with optional capabilities.

Format:

Where feature is present, the system shall response.

Example:

Where multi-factor authentication is enabled, the system shall require a second authentication factor before granting user access. 

Complex Requirements

Requirements involving multiple conditions.

Format:

While state, when trigger, the system shall response.

Example:

While a patient record is open, when the clinician selects "Save", the electronic health record system shall store all modified patient information.

Why EARS Works

1. Reduces Ambiguity

The structured syntax forces engineers to clearly identify:

• Conditions
• Triggers
• System responses
• Operational states

This significantly reduces interpretation differences between stakeholders.

2. Improves Verification

Well-written EARS requirements naturally lend themselves to verification activities.

For example:

When battery voltage falls below 20V, the system shall generate a low-voltage warning within 1 second.

A test engineer can immediately determine how to verify this requirement.

3. Encourages Atomic Requirements

The EARS patterns naturally encourage engineers to write requirements that describe a single behavior or response. This makes requirements easier to review, verify, trace, and maintain throughout the system lifecycle.

4. Accelerates Reviews

Requirements reviews become more efficient because reviewers spend less time deciphering poorly written statements and more time validating technical correctness.

5. Helps New Engineers

Many engineers receive little formal training in requirements writing.

EARS provides a simple framework that allows junior engineers to produce high-quality requirements from day one.

6. Supports Regulatory and Safety-Critical Development

Industries such as aerospace, defense, medical devices, rail, and automotive frequently require rigorous requirements management.

EARS helps organizations demonstrate:

• Clarity
• Consistency
• Traceability
• Verifiability

all of which are essential for compliance and certification activities.

EARS and Model-Based Systems Engineering (MBSE)

One common misconception is that MBSE eliminates the need for textual requirements.

In reality, MBSE and EARS complement one another extremely well.

Models help describe:

• System structure
• Interfaces
• Behaviors
• Architectures

EARS helps define:

• Functional requirements
• Performance requirements
• Failure responses
• Operational constraints

The strongest engineering teams use both.

Models provide understanding.

Requirements provide contractual intent.

Together they create a more complete system specification.

Common Mistakes When Using EARS

Including Design Solutions

Poor:

When communication is lost, the system shall use a Kalman filter.

Better:

If communication is lost, then the system shall maintain target track continuity for at least 5 seconds.

The second statement focuses on the required behavior rather than prescribing implementation.

Using Vague Language

Avoid terms such as:

• Quickly
• Efficiently
• User-friendly
• Robust
• Adequate
• Minimize

Replace them with measurable criteria.

Combining Multiple Requirements

Poor:

When power is applied, the system shall initialize, perform self-test, display status information, and begin logging data.

Better:

Split into separate requirements.

Each requirement should express a single verifiable behavior.

Example: Before and After

Traditional Requirement:

The camera should continue tracking targets even when GPS is unavailable.

EARS Requirement:

If GPS position data becomes unavailable, then the camera system shall continue target tracking using onboard inertial measurements for at least 30 seconds.

The EARS version is:

• More precise
• More testable
• Less ambiguous
• Easier to review
• Easier to verify

Final Thoughts

Requirements are the foundation upon which systems are designed, implemented, verified, and validated.

When requirements are ambiguous, every downstream engineering activity suffers.

EARS provides a simple but powerful framework that helps engineers write requirements that are atomic, unambiguous, consistent, traceable, and verifiable. Its adoption requires minimal training, integrates well with modern MBSE practices, and can significantly improve engineering quality across projects.

If your team is still writing requirements as free-form sentences, adopting EARS may be one of the highest-return process improvements you can make.

Good requirements do not happen by accident.

They are engineered.

And EARS is one of the best tools available to help engineers do exactly that.

At Ngenaire, we believe engineering should focus less on administrative overhead and more on innovation. Structured approaches like EARS help teams reduce ambiguity, improve collaboration, and accelerate the development of complex systems.

References

[1] Mavin, A., Wilkinson, P., Harwood, A., & Novak, M. (2009). Easy Approach to Requirements Syntax (EARS). Proceedings of the 17th IEEE International Requirements Engineering Conference (RE'09), Atlanta, Georgia, USA, pp. 317–322.

[2] Mavin, A. EARS – Easy Approach to Requirements Syntax. Official EARS website. Available at: https://alistairmavin.com/ears/

[3] Mavin, A., Wilkinson, P., Gregory, S., & Uusitalo, E. (2019). Ten Years of EARS. IEEE Software, Vol. 36, No. 2, pp. 95–99.

Further Reading

• Requirements Engineering Fundamentals
• Writing Verifiable Requirements
• EARS and Model-Based Systems Engineering (MBSE)
• Common Requirement Anti-Patterns
• INCOSE Guide to Writing Requirements
• SysML and Requirements Traceability