Write Requirements

Requirements specify what the software does (behaviour), not how it's built (implementation). Getting this right is the difference between a specification that guides development and one that gets ignored.

The five core EARS patterns

EARS - Easy Approach to Requirements Syntax - gives you patterns for writing unambiguous requirements. Most requirements fit one of these five patterns:

1. Ubiquitous (always true)

Pattern: The system shall always [do this].

Use when the requirement applies all the time, with no conditions.

"The system shall log all user activities." "The tick interval timer shall run at a frequency of 1KHz ±200ppm."

2. Event-driven (triggered by event)

Pattern: When [event], the system shall [do this] within [time period].

Use when a specific event triggers a one-time response.

"When the power button is pressed, the system shall perform power-on startup within 2 seconds." "When battery voltage drops below 3.0V, the system shall display low battery warning."

3. State-driven (condition persists)

Pattern: While in [state], the system shall [do this] every [time period].

Use when a continuous condition results in continuous or repeated behaviour.

"While in sleep mode, the system shall consume less than 50μA." "While Wi-Fi connection is active, the system shall send keep-alive packets every 30 seconds."

The key difference between event and state: an event is a single trigger producing a single response. A state is a continuous condition producing continuous behaviour.

4. Optional feature

Pattern: Where [feature] is included, the system shall [do this].

Use when behaviour depends on whether an optional component exists.

"Where GPS module is installed, the system shall timestamp readings with latitude/longitude." "Where hardware crypto accelerator is available, the system shall use hardware AES-256."

5. Unwanted behaviour (error handling)

Pattern: If [undesired condition], the system shall [do recovery].

Use when the system must handle failures or exceptional conditions.

"If sensor reading is out of valid range (1-100), the system shall flag data as invalid and use last known good value." "If I2C communication fails for 3 consecutive attempts, the system shall switch to backup sensor."

Common mistakes

Vague language. "Process data quickly" and "reliable communication" mean nothing without numbers. Replace "fast" with "within 50ms". Replace "reliable" with "packet loss less than 0.1%". If you see an adjective without a number, ask: how fast? How accurate? How reliable?

Implementation instead of behaviour. "Use a PID controller with Kp=1.5" dictates how. "Maintain temperature at setpoint ±1°C" describes what. The test: could this requirement work on bare metal, RTOS, Linux, and custom frameworks? If not, it's probably over-specified.

Mixing patterns. "While charging, when battery is full, the system shall..." combines state and event. Pick one or create 2 separate ones. "While battery is at 100%, the system shall stop charging current" (state-driven) and/or "When battery reaches 100%, the system shall transition to trickle charge" (event-driven).

Missing error handling. Only describing the happy path. For every requirement, ask: what can go wrong? How do we detect it? What should the software do?

Quantification

Every non-functional requirement needs a number:

Instead of	Specify
Fast response	Within 50ms
Process frequently	Execute at 100 Hz (every 10ms)
Store many readings	Store most recent 1000 readings
Small code size	Application code ≤256KB Flash
Low power	Active ≤50mA @ 3.3V, sleep ≤50μA

Always include a tolerance. Not "sample at 100 Hz" but "sample at 100 Hz ±1%".

The full reference

This page covers the essentials. For the complete set of EARS patterns (including embedded system extensions for timing, data processing, control algorithms, resource constraints, and power management), plus the full pitfalls guide, see the EARS Reference.

EARS Reference - all 10 patterns, extensions, and best practices
Define Specifications - where requirements are added
Requirements Hierarchy - FR vs UCR and why both exist