Feature Request: EARS (Easy Approach to Requirements Syntax) Integration

[s-celles]

Summary

Would the spec-kit team consider integrating EARS (Easy Approach to Requirements Syntax) as a structured format for writing requirements in the specification phase? EARS provides a set of sentence templates that could help users write clearer, more unambiguous specifications that AI agents can parse more reliably.

What is EARS?

EARS was developed by Alistair Mavin at Rolls-Royce and is widely used in safety-critical industries (aerospace, automotive, medical devices). It provides five simple sentence patterns for requirements:

Pattern	Template	Example
Ubiquitous	The [system] shall [action]	The system shall display the user's name
Event-Driven	When [trigger], the [system] shall [action]	When the user clicks "Save", the system shall persist data to the database
State-Driven	While [state], the [system] shall [action]	While offline, the system shall queue pending operations
Unwanted Behavior	If [condition], then the [system] shall [action]	If the connection times out, then the system shall retry 3 times
Optional	Where [feature is enabled], the [system] shall [action]	Where dark mode is enabled, the system shall use the dark color scheme

Why EARS Could Benefit Spec-Kit

1. Reduced Ambiguity

Natural language specifications can be interpreted in multiple ways. EARS templates force writers to be explicit about triggers, conditions, and states, reducing the clarification cycles needed in /speckit.clarify.

2. Better AI Parsing

The structured patterns are easier for AI agents to decompose into:

• Preconditions (When/While/If/Where clauses)
• Actors (the system/component)
• Actions (the behavior to implement)

3. Improved Test Generation

EARS requirements map naturally to test cases:

• Event-driven → integration tests with specific triggers
• State-driven → state machine tests
• Unwanted behavior → error handling / edge case tests

4. Industry Adoption

EARS is already a standard in industries requiring rigorous requirements engineering. Supporting it could make spec-kit attractive for enterprise and regulated environments.

Proposed Integration Points

Option A: EARS-Aware Spec Template

Add an optional EARS section to spec-template.md:

## Functional Requirements (EARS Format)

### Ubiquitous Requirements
- REQ-001: The system shall [action]

### Event-Driven Requirements  
- REQ-002: When [trigger], the system shall [action]

### State-Driven Requirements
- REQ-003: While [state], the system shall [action]

### Unwanted Behavior Requirements
- REQ-004: If [condition], then the system shall [action]

Option B: EARS Linting in /speckit.clarify

During the clarification phase, the AI agent could:

1. Identify vague requirements
2. Suggest EARS reformulations
3. Flag requirements missing explicit triggers/conditions

Option C: EARS Slash Command

A new /speckit.ears command that:

• Converts free-form requirements to EARS format
• Validates EARS syntax
• Generates a requirements traceability matrix

Example Transformation

Before (free-form):

Users should be able to drag tasks between columns. The app needs to work offline too. Handle errors gracefully.

After (EARS):

• REQ-001 (Event): When the user drags a task card to a different column, the system shall update the task status to match the destination column.
• REQ-002 (State): While the application is offline, the system shall store task updates in local storage.
• REQ-003 (Event): When the application reconnects, the system shall synchronize locally stored updates with the server.
• REQ-004 (Unwanted): If synchronization conflicts occur, then the system shall display a resolution dialog to the user.

Questions for the Maintainers

1. Does EARS align with the Spec-Driven Development philosophy?
2. Would you prefer EARS as an optional "strict mode" or as the default recommendation?
3. Are there concerns about EARS being too formal for rapid prototyping / vibe-coding use cases?
4. Would this fit better as a core feature or as a community-contributed template variant?

References

• EARS: The Easy Approach to Requirements Syntax - Original methodology
• IEEE Paper on EARS - Academic publication
• INCOSE EARS Tutorial - Systems engineering perspective

Additional Context

I work in industrial automation where structured requirements are essential for safety and compliance. I see spec-kit as a powerful tool that could bridge the gap between informal AI-assisted development and rigorous engineering practices. EARS integration could make spec-kit viable for teams that need traceability and auditability in their specifications.

---

Happy to contribute a PR with template modifications if there's interest!