EARS
EARS (Easy Approach to Requirements Syntax) es una notación que estructura los criterios de aceptación en lenguaje natural lo justo para eliminar la ambigüedad sin perder legibilidad. La desarrolló Alistair Mavin en Rolls-Royce y la presentó en 2009; varias herramientas de SDD la usan porque su forma fija reduce el margen de interpretación de un agente.
EARS no es compleja: es un conjunto de patrones basados en palabras clave, adoptado en el sector aeroespacial y en la ingeniería de sistemas, que ha vuelto al primer plano al integrarse en herramientas que generan criterios de requisitos.
La plantilla y los cinco patrones
La plantilla básica encaja tres piezas: «Mientras [precondición], cuando [evento], el sistema debe [respuesta]». Sobre ella, EARS define cinco patrones que cubren la mayoría de los requisitos:
| Patrón | Palabra clave | Uso y ejemplo |
|---|---|---|
| Ubicuo | (sin disparador) | Una propiedad permanente. «El sistema debe cifrar todas las contraseñas con un algoritmo de coste configurable». |
| Dirigido por evento | cuando… | Se activa al ocurrir algo. «Cuando se publica una versión de un documento, el sistema debe encolar una notificación en menos de cinco segundos». |
| Dirigido por estado | mientras… | Activo mientras se cumple una condición. «Mientras el usuario tiene activado el modo no molestar, el sistema debe retener las notificaciones». |
| Comportamiento no deseado | si… | Gestiona errores y situaciones anómalas. «Si la contraseña se introduce mal tres veces, el sistema debe bloquear la cuenta quince minutos». |
| Opcional | donde… | Funcionalidad condicionada a la configuración. «Donde la organización ha habilitado el segundo factor, el sistema debe pedir un código tras la contraseña». |
Los patrones se combinan: un requisito puede ser dirigido por estado y por evento a la vez, y la plantilla lo admite sin perder claridad.
Cuándo usarla
Los agentes responden bien a requisitos estructurados con patrones consistentes, porque la forma fija elimina las ambigüedades más comunes del lenguaje natural: el sujeto implícito, la condición que no se sabe si es previa o simultánea, o la respuesta sin plazo. EARS es especialmente útil para que los criterios sean verificables: «la notificación es rápida» no lo es; «la notificación llega al canal en menos de treinta segundos en el 99 % de los casos» sí.
La notación no es obligatoria. Se aplica donde el criterio es lo bastante importante para merecer la forma fija; forzarla en cada línea de la spec convierte una ayuda en una obligación. Es una herramienta que se usa con criterio, no un formato universal.
Error frecuente
Criterios de aceptación vagos. «Rápido», «intuitivo» o «seguro» sin umbral no son verificables ni para una persona ni para un agente. EARS empuja hacia la forma medible. El reverso también existe: forzar EARS donde no aporta, o confundir el patrón —usar «cuando» para una propiedad permanente o «mientras» para un evento puntual—, desvirtúa el criterio.
Recursos
📊 Guía didáctica SDDRecursos · Scrum Manager
🏦 SDD en equipos ágilesSkill Arena · Scrum Manager
Referencias
- Mavin, Alistair; Wilkinson, Philip; Harwood, Adrian; Novak, Mark. (2009). «Easy Approach to Requirements Syntax (EARS)». 17th IEEE International Requirements Engineering Conference (RE'09).
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.