EARS patterns are the six shapes every system requirement takes. Each pattern is identified by the keyword it uses — or by the absence of a keyword. Together they cover the full spectrum of requirement types: always-active invariants, mode-dependent behavior, reactive operations, error handling, variant features, and guarded triggers. This page enumerates them with canonical forms and examples drawn from the Order Processing context (REQ-ORD-001…REQ-ORD-008).

Ubiquitous

Canonical form:

The <system name> shall <system response>.

Example: “The system shall reject order lines with a quantity less than one.” (REQ-ORD-001, pattern ubiquitous.) No keyword. No precondition. No trigger. The obligation holds at all times and in all states.

Use for: fundamental system properties, structural constraints, and invariants that must hold regardless of state or event. Availability SLAs, encryption baselines, and regulatory minimums are typically ubiquitous.

State-Driven (While)

Canonical form:

While <system state>, the <system name> shall <system response>.

Example: "While the customer is suspended, the system shall reject new orders." (REQ-ORD-003, pattern state-driven.) The obligation is scoped to a lifecycle phase — it is inert outside the suspended state and binding inside it.

Use for: mode-dependent behavior, state-scoped invariants, and preconditions that apply only in specific lifecycle phases. Draft/confirmed/cancelled modes, maintenance windows, and feature flags with state are natural state-driven requirements.

Event-Driven (When)

Canonical form:

When <trigger event>, the <system name> shall <system response>.

Example: "When a customer submits an order, the system shall create the order in draft status and emit an OrderPlaced event." (REQ-ORD-002, pattern event-driven.) The trigger is a domain event; the response is a command outcome plus an emitted event.

Use for: commands, operations, event-driven state transitions, and reactive behavior. Every state-changing use case is typically one or more event-driven requirements. This pattern is the primary handle for Specy’s Observe loop: runtime event traces are matched against When statements to detect drift.

Unwanted (If-Then)

Canonical form:

If <unwanted condition or trigger>, then the <system name> shall <system response>.

Example: "If the ordered product is out of stock, then the system shall reject the order and notify the customer." (REQ-ORD-004, pattern unwanted.) The condition is undesired — stockouts — and the requirement pins down what the system must do when the condition occurs.

Use for: error handling, fault tolerance, compensating actions, and violation detection. This pattern deserves special attention: the omission of error handling is the most common and costly category of missing requirements. If you cannot find an If-Then requirement next to every When, you likely have a gap.

Optional (Where)

Canonical form:

Where <capability is enabled>, the <system name> shall <system response>.

The capability in a Where clause is a deployment-time variant flag — a configuration option, a product-line tier, a regional capability, a feature flag. It is not a PRD Feature (which is a user-facing capability at the product level). A PRD Feature typically decomposes into multiple EARS requirements, some of which may be unconditional (not under a Where) and some variant-conditional (under a Where). Using “capability” in the pattern keeps the two senses distinct.

Example: "Where express shipping is available, the system shall offer same-day delivery for orders placed before noon." (REQ-ORD-006, pattern optional.) The obligation exists only for variants that include the express-shipping capability. A deployment without the capability enabled is not in breach.

Use for: product-line tiers, configurable capabilities, regional variants, plug-in behaviors, and feature flags.

Complex

Canonical form:

While <precondition(s)>, When <trigger>, the <system name> shall <system response>.
While <precondition(s)>, If <unwanted trigger>, then the <system name> shall <system response>.
Where <capability>, When <trigger>, the <system name> shall <system response>.

Keywords appear in strict temporal order: While → When/If/Where → system → response. The complex pattern is not a separate syntax — it is the deliberate combination of the keywords introduced above.

Example: "While the customer has an active credit account, when an order is placed, if the order total exceeds the remaining credit limit, then the system shall hold the order for manual approval." (REQ-ORD-005, pattern complex.) A state precondition scopes the obligation, an event triggers it, and an unwanted condition routes it to manual handling — one sentence.

Use for: guarded triggers, conditional error handling, and feature-scoped events. Complex requirements are legitimate when decomposition would hide the temporal structure that domain experts actually use to reason about the behavior. If you find yourself nesting four or more clauses, stop — the requirement is hiding two.