EARS: Easy Approach to Requirements Syntax

Tutorial basado en la guía oficial de Alistair Mavin, creador de la notación EARS en Rolls-Royce.

Qué es EARS

EARS es una notación ligera para escribir requisitos en lenguaje natural estructurado. Define 5 plantillas que cubren todos los tipos de comportamiento de un sistema. El resultado: requisitos claros, verificables y libres de las patologías clásicas (ambigüedad, vaguedad, requisitos compuestos, supuestos ocultos).

No es una herramienta, ni un metamodelo, ni un DSL. Son plantillas que cualquiera puede aprender en una hora y aplicar el mismo día.

Por qué importa

Los requisitos escritos en prosa libre son la raíz de la mayoría de los defectos de producto. EARS no te obliga a usar formalismos complejos: te da un molde tan simple que es difícil escribir un requisito ambiguo dentro de él.

Para agentes de IA, equipos distribuidos, certificación de software y dominios regulados (aeronáutico, médico, automotriz), EARS funciona como lenguaje pivote entre stakeholders no técnicos y la implementación.

Capítulos

1. Introducción a EARS — Origen en Rolls-Royce, por qué falla el lenguaje natural libre
2. Los 5 patrones EARS — Ubiquitous, Event-driven, State-driven, Optional feature, Unwanted behaviour
3. Sintaxis y palabras clave — When, While, Where, If/Then, shall, plantilla genérica
4. Requisitos complejos — Combinaciones y anidamientos de patrones
5. Antipatrones y errores comunes — Ambigüedad, compuestos, pasiva, “etc”
6. Taller: de prosa a EARS — Reescribir requisitos reales paso a paso
7. EARS + Agile y User Stories — Cómo conviven con Scrum, Kanban y XP
8. EARS + IA y LLMs — Requisitos que un agente puede implementar sin alucinar
9. EARS + Gherkin — Puente hacia escenarios ejecutables
10. Plantillas y checklist de calidad — Recursos listos para usar
11. Casos de estudio y dominios regulados — Aeronáutico, médico, automotriz, fintech

Audiencia

• Product Owners, Business Analysts y Requirements Engineers
• Equipos de QA que escriben criterios de aceptación
• Ingenieros que prompten agentes de IA y se cansan de iterar por requisitos vagos
• Stakeholders no técnicos que escriben épicas e historias

Prerrequisitos

Ninguno. EARS es deliberadamente accesible: no requiere conocimiento de UML, BPMN, modelado formal ni programación.

Referencia rápida

Patrón	Palabra clave	Cuándo aplica
Ubiquitous	(ninguna — “The X shall…”)	Comportamiento siempre activo
Event-driven	When	Reacción a un disparador discreto
State-driven	While	Mientras el sistema está en un estado
Optional feature	Where	Solo si una feature/opción está presente
Unwanted behaviour	If ... then	Comportamiento ante condiciones no deseadas

Empezá por el capítulo 1.