Introducción a EARS
Introducción a EARS
El problema: el lenguaje natural sin estructura
Los requisitos son contratos. Si un requisito dice “el sistema debe ser rápido”, ¿qué significa? ¿Rápido respecto a qué? ¿Bajo qué carga? ¿Medido cómo? Esa frase no es un contrato: es un deseo.
La mayoría de los problemas graves en proyectos de software empiezan en la fase de requisitos:
- Ambigüedad: “El sistema mostrará un mensaje apropiado”. Apropiado para quién, definido por quién.
- Vaguedad: “El sistema será fácil de usar”. No es verificable.
- Requisitos compuestos: “Cuando el usuario inicie sesión y haga clic en guardar y la red esté disponible, el sistema mostrará un toast y enviará un correo”. Múltiples requisitos disfrazados de uno.
- Supuestos ocultos: “El sistema debe permitir múltiples usuarios concurrentes”. ¿Cuántos? ¿Con qué garantías de aislamiento?
- Voz pasiva: “Los datos serán encriptados”. ¿Por quién? ¿Cuándo?
En proyectos pequeños esto se compensa con conversaciones. En proyectos grandes, distribuidos, con auditorías o con agentes de IA implementando código, la ambigüedad se traduce en defectos.
El origen: Rolls-Royce y los motores aeronáuticos
EARS nació en Rolls-Royce alrededor de 2009, cuando Alistair Mavin y su equipo enfrentaban un problema concreto: escribir requisitos para sistemas de control de motores aeronáuticos donde un defecto puede costar vidas.
Probaron lenguajes formales (Z, VDM), modelado UML, especificaciones controladas. Todos requerían entrenamiento extenso y los stakeholders no técnicos no podían leerlos. La pregunta de Mavin fue: ¿podemos imponer estructura sin abandonar el lenguaje natural?
La respuesta fue EARS: cinco plantillas que cubren los cinco tipos de comportamiento posibles en un sistema. Cualquier persona puede aprenderlas en una tarde.
El estudio publicado mostró que en Rolls-Royce los requisitos escritos con EARS:
- Redujeron defectos de requisitos en más del 50%
- Eliminaron el 100% de la voz pasiva
- Redujeron requisitos compuestos a casi cero
- Acortaron el tiempo de revisión por documento
EARS hoy se usa en aeronáutica, defensa, automotriz, médico y fintech. Y crece en software comercial, especialmente en equipos que trabajan con agentes de IA.
Qué es y qué no es EARS
EARS es:
- Una notación de escritura
- 5 plantillas de oraciones
- Compatible con cualquier herramienta (Word, Confluence, Markdown, DOORS, Jira)
- Aprendible en horas
EARS no es:
- Una herramienta de software
- Un metamodelo formal
- Un DSL ejecutable
- Una metodología (Agile, V-Model, Waterfall — funciona con todas)
- Un reemplazo de Gherkin, BDD o tests (EARS describe qué; Gherkin describe cómo se verifica)
La forma genérica
Todo requisito EARS sigue esta estructura abstracta:
<precondiciones opcionales> <disparador opcional> the <sistema> shall <respuesta>Por ejemplo:
When the user submits the login form, the system shall validate the credentials against the identity provider within 500 ms.
Notá tres elementos clave:
- Disparador:
When the user submits the login form - Sujeto:
the system - Respuesta verificable:
validate the credentials against the identity provider within 500 ms
No hay ambigüedad: si pasan 600 ms, el requisito falló.
Los cinco patrones, en una línea
Cada patrón se aplica a una situación distinta:
- Ubiquitous — comportamiento siempre presente, sin precondiciones
- Event-driven — reacciona a un evento puntual (con
When) - State-driven — activo mientras un estado dura (con
While) - Optional feature — solo aplica si una feature está disponible (con
Where) - Unwanted behaviour — define cómo reacciona el sistema a condiciones indeseadas (con
If ... then)
Estos cinco patrones cubren — según la investigación de Mavin — la totalidad de los comportamientos que un sistema puede exhibir.
Lectura del capítulo
EARS no resuelve mágicamente los problemas de requisitos. Sigue requiriendo dominio del problema, claridad mental y revisión por pares. Pero al imponer una plantilla, fuerza al autor a:
- Pensar cuándo ocurre el comportamiento
- Especificar quién es el sujeto
- Definir una respuesta concreta y verificable
Esa disciplina, en sí misma, elimina la mayoría de los defectos de requisitos.
En el siguiente capítulo cubrimos en profundidad los cinco patrones con ejemplos completos.