EARS Reference

EARS - Easy Approach to Requirements Syntax - is the key to creating a specification without ambiguity, with full clarity. Every embedded system uses combinations of these patterns.

The core principle: requirements specify what software does (behaviour), not how it's built (implementation).

• "When temperature exceeds 80°C, activate cooling within 100ms" - this is a requirement
• "Use a state machine with 7 states" - this is an implementation decision

The 5 Universal Patterns

Pattern 1: Ubiquitous (always true)

Syntax: 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 watchdog timer shall reset the system if not serviced within 100ms."
• "The firmware shall execute from Flash memory."

Pattern 2: Event-Driven (triggered by event)

Syntax: 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 sequence within 2 seconds."
• "When battery voltage drops below 3.0V, the system shall display low battery warning."
• "When temperature sensor reading exceeds 85°C, the system shall activate cooling fan within 50ms."

Pattern 3: State-Driven (condition persists)

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

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

• "While in sleep mode, the system shall consume less than 50uA."
• "While Wi-Fi connection is active, the system shall send keep-alive packets every 30 seconds."
• "While calibration routine is executing, the system shall sample sensors at 1kHz."

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.

Pattern 4: Optional Feature (feature-dependent)

Syntax: Where [feature] is included, the system shall [do this] every [time period].

Use when behaviour depends on whether an optional component exists.

• "Where GPS module is installed, the system shall timestamp readings with latitude/longitude."
• "Where external EEPROM is populated, the system shall store logs in external memory."
• "Where hardware crypto accelerator is available, the system shall use hardware AES-256."

Pattern 5: Unwanted Behaviour (error handling)

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

Use when the system must handle failures, errors, or exceptional conditions.

• "If sensor reading is out of valid range, 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."
• "If firmware update is interrupted, the system shall boot from backup partition on next power-up."

Embedded System Extensions

These five additional patterns address concerns specific to embedded systems.

Pattern 6: Scheduled Periodic (timing constraints)

Syntax: The system shall [do this] at [frequency] +/- [tolerance].

• "Sample sensors at 100 Hz +/- 1%."
• "When emergency stop interrupt occurs, the ISR shall de-energize motor outputs within 10ms with less than 1ms jitter."

Pattern 7: Data Processing (data transformations)

Syntax: Transform [input data] through [steps] to [output data].

• "Raw ADC value -> voltage -> calibration -> temperature in degrees C."

Pattern 8: Control Algorithms (process control)

Syntax: Maintain [process] within +/- [tolerance] of target.

• "Maintain motor speed within +/- 5rpm of target."

Pattern 9: Resource Constraints (resource management)

Syntax: The [process] shall function within [resource limit].

• "The image processing algorithm shall function within 128KB RAM."

Pattern 10: Power Constraints (power management)

Syntax: While in [power mode], the system shall consume less than [power limit].

• "While in active mode, the system shall draw less than 100mA at 3.3V average current."

Best Practices

Split complex requirements

A requirement that describes multiple actions should be split into separate requirements - one per action.

Avoid: "When button pressed, the system shall record timestamp, update display, and send notification."

Better (3 separate requirements):

1. "When save button is pressed, the system shall record current timestamp with microsecond precision."
2. "When save button is pressed, the system shall update status display to show 'Saved' for 2 seconds."
3. "When save button is pressed, the system shall send save-complete notification to server via MQTT."

Don't mix patterns

Each requirement should use one pattern. Mixing patterns creates ambiguity about when the requirement applies.

Avoid: "While charging, when battery is full, the system shall..."

Better - choose one:

• State: "While battery is at 100% charge, the system shall stop charging current."
• Event: "When battery reaches 100% charge, the system shall transition to trickle charge mode."

Be specific

Every adjective needs a number. Every response needs a time bound.

Avoid: "When button pressed, the system shall respond quickly."

Better: "When power button is pressed, the system shall power on and display home screen within 2 seconds."

Use platform-agnostic language

Requirements should work regardless of implementation platform. If your requirement names a specific RTOS, hardware timer, or framework pattern, it's probably an implementation decision, not a requirement.

Platform-specific (avoid): "Create FreeRTOS task with 10ms period", "Use hardware timer 3", "Register callback", "Use state machine"

Platform-agnostic (use): "Execute at 100 Hz", "Respond within 10ms", "Periodic execution", "System operates in modes: [list]"

The test: can this requirement work on bare metal, RTOS, Linux, and custom frameworks? If not, it's over-specified.

Common Pitfalls

Vague language

Using imprecise adjectives instead of quantified specifications. "Process data quickly" and "real-time response" tell the implementer nothing useful.

Terms to avoid: "fast", "slow", "quick", "real-time", "reliable", "robust", "secure", "user-friendly", "efficient". Replace every one of them with a number.

Instead of	Specify
Fast boot time	Power-on to operational mode within 2 seconds
Long battery life	48 hours continuous operation on 2000mAh battery
High accuracy	+/-0.5°C over -40°C to +125°C range
Reliable communication	Packet loss rate less than 0.1% over 100m range
Real-time response	Interrupt latency less than 5us, task response within 10ms

Review every requirement. If you see an adjective without a number, ask: how fast? How accurate? How reliable?

Solution statements instead of problem statements

Stakeholders propose solutions instead of describing the underlying need. "We need Bluetooth connectivity" is a solution. The actual requirement might be: "Operators must configure device settings from their phone within 3 metres."

When someone proposes a solution, ask "Why? What problem does that solve?" Keep asking until you reach the actual requirement.

Verbal requirements

If it's not written down, it doesn't exist. Requirements described in meetings but never documented lead to "I never said that" conversations weeks later, different interpretations by different people, and no baseline for change management.

Capture requirements in real-time during discussions. Get stakeholder confirmation: "Is this what you meant?"

Missing stakeholders

Commonly forgotten: manufacturing teams (can this be built at scale?), field service teams (can this be diagnosed and repaired?), domain experts and end users (does this match actual usage?), regulatory and compliance (does this need certification?), and hardware engineers (are the software requirements physically possible?).

No environmental constraints

Requirements that don't mention temperature range, humidity, vibration, IP rating, or EMI/EMC environment. The hardware team assumes commercial grade. Reality: the device works outdoors at -40°C. Result: costly redesign.

For every embedded system, document: operating temperature range, storage temperature range, humidity range, vibration, shock/drop, IP rating, and EMI/EMC environment. These aren't optional - hardware decisions depend entirely on this information.

Ignoring safety

"We'll think about safety during testing" fails because safety requirements derive from hazard analysis before design, safety drives architecture (redundancy, monitoring, fail-safe), and certification takes months. Ask early: "Could this cause injury or death if it malfunctions?" If yes, identify the applicable safety standard (ISO 26262, IEC 62304, IEC 61508, DO-178C) and engage a safety specialist.

Everything is Must Have

When 90% of requirements are marked Must Have, engineering can't make trade-off decisions. Guideline: Must Haves should be 60% or less. The test: "Would you accept delivery without this feature?" If no, it's a Must Have. If yes, it isn't.

No hardware team involvement

Gathering software requirements without hardware engineers present leads to requirements that assume unlimited resources. Hardware reality: 128KB Flash, 32KB RAM, 50mA budget. Include the hardware lead in requirements workshops and validate technical feasibility continuously.

Scope creep

"Just one more thing", "Can we also...", "While we're at it..." - these are red flags. Acknowledge the idea, defer it to a future release, and document it as Won't Have. Protect scope boundaries.

Ambiguous language

Vague pronouns and passive voice create ambiguity. "The system shall send it there" - what is "it"? Where is "there"? Use EARS patterns to eliminate ambiguity: "When sensor reading exceeds 100°C, the system shall send an alarm message to the monitoring server via MQTT."

Missing operating modes

Only specifying normal operation. A complete specification addresses startup, normal, calibration, fault, sleep, and shutdown modes at minimum.

Implementation instead of behaviour

"Use PID controller with Kp=1.5" dictates implementation. "Maintain temperature at setpoint +/-1°C" describes behaviour. Specify the what, not the how.

Forgetting 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?

Framework-specific terms

"FreeRTOS task", "create semaphore", "post to queue" are implementation terms. Use "periodic task", "ensure mutual exclusion", "transfer data" instead.

No tolerances

"Sample at exactly 100 Hz" - nothing is exact. "Sample at 100 Hz +/-1%" gives the implementer a real target. Always include a tolerance.

Quantification Guide

Replace vague words with specific numbers:

Vague	Quantified
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 ≤50uA
Reliable communication	Packet loss < 0.1%
Long battery life	48 hours continuous operation

Timing units: Fast tasks in Hz (1 kHz = every 1ms). Slow tasks as period (every 15 minutes). Always include +/- tolerance.

Typical tolerances: Hard real-time +/- 0.1-1%. Soft real-time +/- 1-10%. Best effort +/- 10-100%.

Every non-functional requirement needs an actual number.

Requirement Quality

Every requirement should be:

• Complete - all necessary information included
• Consistent - no contradictions with other requirements
• Unambiguous - only one interpretation possible (EARS patterns help here)
• Verifiable - can be objectively tested or proven
• Traceable - origin clear, relationships documented
• Feasible - engineering reviewed and confirmed achievable
• Necessary - addresses actual need, not gold-plating

Related

• Write Requirements - the practical how-to for writing requirements in Specify
• Requirements Hierarchy - FR vs UCR and why both levels exist