Agent Skills: EARS Authoring

EARS Authoring

EARS (Easy Approach to Requirements Syntax) pattern authoring for precise, unambiguous requirements.

When to Use This Skill

Keywords: EARS patterns, ubiquitous requirements, state-driven requirements, event-driven requirements, unwanted behavior, optional features, complex requirements, SHALL keyword, requirement syntax

Use this skill when:

• Writing new requirements using EARS syntax
• Converting informal requirements to EARS format
• Validating EARS pattern correctness
• Selecting the right EARS pattern for a requirement
• Understanding EARS anti-patterns

Quick Pattern Reference

| Pattern | Keyword | Template | | --- | --- | --- | | Ubiquitous | (none) | The <entity> SHALL <action> | | State-Driven | WHILE | WHILE <condition>, the <entity> SHALL <action> | | Event-Driven | WHEN | WHEN <trigger>, the <entity> SHALL <action> | | Unwanted | IF...THEN | IF <condition>, THEN the <entity> SHALL <action> | | Optional | WHERE | WHERE <feature>, the <entity> SHALL <action> | | Complex | Multiple | Combination of patterns |

Pattern Selection Decision Tree

Start here: When does this requirement apply?

1. Always applies (no conditions) → Use Ubiquitous: "The system SHALL..."

2. While in a specific state → Use State-Driven: "WHILE in maintenance mode, the system SHALL..."

3. When something happens (event/trigger) → Use Event-Driven: "WHEN user clicks submit, the system SHALL..."

4. To handle unwanted behavior (error/exception) → Use Unwanted: "IF authentication fails, THEN the system SHALL..."

5. Only when feature is enabled (optional/configurable) → Use Optional: "WHERE dark mode is enabled, the system SHALL..."

6. Multiple conditions apply → Use Complex: "WHILE active, WHEN timeout occurs, the system SHALL..."

Pattern Details

Ubiquitous Pattern

Use when: Requirement applies unconditionally, always active.

Template:

The <entity> SHALL <action>

Keywords: None required (no WHILE, WHEN, IF, WHERE)

Examples:

• "The system SHALL encrypt all data at rest"
• "The API SHALL respond in JSON format"
• "The application SHALL log all user actions"

Common Mistakes:

• Adding unnecessary conditions when behavior is universal
• Using "should" instead of "SHALL"

State-Driven Pattern

Use when: Behavior applies while system is in a particular state.

Template:

WHILE <condition>, the <entity> SHALL <action>

Keywords: WHILE (at start)

Examples:

• "WHILE in maintenance mode, the system SHALL display a banner"
• "WHILE the connection is active, the system SHALL send heartbeats"
• "WHILE the user is authenticated, the system SHALL show the dashboard"

Common Mistakes:

• Using WHEN instead of WHILE (WHEN = event, WHILE = state)
• Describing events, not states

Event-Driven Pattern

Use when: Action triggered by a specific event or user action.

Template:

WHEN <trigger>, the <entity> SHALL <action>

Keywords: WHEN (at start)

Examples:

• "WHEN a user submits the form, the system SHALL validate inputs"
• "WHEN an error occurs, the system SHALL log the details"
• "WHEN the session expires, the system SHALL redirect to login"

Common Mistakes:

• Using WHILE instead of WHEN (WHILE = state, WHEN = event)
• Describing states, not events

Unwanted Behavior Pattern

Use when: Handling exceptions, errors, or unwanted conditions.

Template:

IF <condition>, THEN the <entity> SHALL <action>

Keywords: IF...THEN (both required)

Examples:

• "IF authentication fails, THEN the system SHALL lock the account"
• "IF the database is unavailable, THEN the system SHALL queue requests"
• "IF input validation fails, THEN the system SHALL display error messages"

Common Mistakes:

• Using IF-THEN for normal behavior (use Event-Driven instead)
• Missing THEN keyword
• Using for positive conditions (reserve for negative/unwanted)

Optional Feature Pattern

Use when: Behavior depends on feature flag or configuration.

Template:

WHERE <feature/config>, the <entity> SHALL <action>

Keywords: WHERE (at start)

Examples:

• "WHERE dark mode is enabled, the system SHALL use dark theme"
• "WHERE audit logging is configured, the system SHALL log access"
• "WHERE two-factor authentication is enabled, the system SHALL require OTP"

Common Mistakes:

• Using IF instead of WHERE (IF = unwanted, WHERE = optional)
• Describing mandatory features as optional

Complex Pattern

Use when: Requirement combines multiple conditions from different patterns.

Template:

<Pattern1>, <Pattern2>, the <entity> SHALL <action>

Examples:

• "WHILE active, WHEN timeout occurs, the system SHALL reconnect"
• "WHILE in production mode, IF error occurs, THEN the system SHALL notify ops"
• "WHERE caching is enabled, WHEN data changes, the system SHALL invalidate cache"

Common Mistakes:

• Using Complex when a simpler pattern suffices
• Nesting conditions too deeply (max 2 recommended)

Writing Quality Requirements

The SHALL Keyword

Always use SHALL for requirements:

• ✅ "The system SHALL validate input"
• ❌ "The system should validate input"
• ❌ "The system must validate input"
• ❌ "The system will validate input"

Why: SHALL indicates mandatory behavior. Other words are ambiguous.

Active Voice

Always use active voice:

• ✅ "The system SHALL encrypt data"
• ❌ "Data shall be encrypted"
• ❌ "Encryption shall be performed"

Single Requirement Per Statement

One action per requirement:

• ✅ "The system SHALL validate input"
• ✅ "The system SHALL log validation errors"
• ❌ "The system SHALL validate input and log errors"

Testable Requirements

Requirements must be testable:

• ✅ "The system SHALL respond within 200ms"
• ❌ "The system SHALL respond quickly"
• ✅ "The system SHALL support 1000 concurrent users"
• ❌ "The system SHALL scale well"

Anti-Patterns to Avoid

| Anti-Pattern | Problem | Fix | | --- | --- | --- | | "should" instead of "SHALL" | Ambiguous obligation | Use "SHALL" | | Passive voice | Unclear actor | Use active voice | | Multiple requirements | Untestable compound | Split into separate | | Implementation details | Specifies "how" | Focus on "what" | | Vague terms | Not measurable | Add specific metrics | | Wrong pattern keyword | Semantic confusion | Match pattern to behavior |

Validation Checklist

Before finalizing an EARS requirement:

• [ ] Uses "SHALL" (not should/must/will)
• [ ] Uses active voice (entity does action)
• [ ] Single behavior per statement
• [ ] Testable with measurable criteria
• [ ] Pattern keyword matches behavior type
• [ ] No implementation details (what, not how)

Integration with Canonical Spec

EARS requirements map to canonical specification:

requirements:
  - id: "REQ-001"
    text: "WHEN a user submits the form, the system SHALL validate inputs"
    priority: must
    ears_type: event-driven  # Matches pattern used
    acceptance_criteria:
      - id: "AC-001"
        given: "a user on the form page"
        when: "the user clicks submit"
        then: "the system validates all inputs"

References

Detailed Documentation:

• Pattern Reference - Complete pattern syntax and rules
• Examples - Real-world examples per pattern

Related Skills:

• canonical-spec-format - Canonical specification structure
• spec-management - Specification workflow navigation
• requirements-quality - INVEST criteria and quality assessment

Last Updated: 2025-12-24

Version History

• v1.0.0 (2025-12-26): Initial release