Los 5 patrones EARS

EARS define cinco plantillas. Cada requisito que escribas encaja exactamente en una. Si un requisito no encaja en ninguna, probablemente sea compuesto y haya que partirlo.

1. Ubiquitous — comportamiento siempre activo

Cuándo usarlo: el comportamiento siempre aplica, sin condiciones, mientras el sistema exista.

Plantilla:

The <system> shall <response>.

Ejemplos:

The system shall encrypt all data at rest using AES-256.

The API shall return responses in JSON format with UTF-8 encoding.

The mobile application shall display all monetary values in the user’s locale currency.

Antipatrón frecuente: usar ubiquitous para algo que en realidad es event-driven. Si el comportamiento solo ocurre cuando pasa algo, no es ubiquitous.

- The system shall validate the user's email.
+ When the user submits the registration form, the system shall validate the email address against RFC 5322.

2. Event-driven — reacción a un disparador

Cuándo usarlo: el sistema responde a un evento puntual, discreto, identificable.

Plantilla:

When <trigger>, the <system> shall <response>.

Ejemplos:

When the user clicks the “Export PDF” button, the system shall generate a PDF document of the current view and offer it for download within 3 seconds.

When a payment fails three consecutive times, the billing service shall send an email notification to the account owner.

When the device connects to a known Wi-Fi network, the synchronization service shall upload pending changes within 30 seconds.

Característica clave: el disparador es observable y verificable. “Cuando el usuario quiera” no es un disparador EARS. “Cuando el usuario hace clic en X” sí.

3. State-driven — mientras un estado dure

Cuándo usarlo: el comportamiento aplica de forma continua mientras el sistema esté en cierto estado.

Plantilla:

While <state>, the <system> shall <response>.

Ejemplos:

While the user is authenticated, the dashboard shall display the user’s name and avatar in the header.

While the export job is running, the UI shall display a progress indicator with the current percentage.

While the device is in airplane mode, the application shall queue outgoing requests and shall not attempt network calls.

Diferencia con Event-driven: When es puntual (“ocurrió”), While es continuo (“durante”). Si decís “Cuando el usuario esté autenticado” estás cometiendo el error clásico — debería ser “Mientras el usuario esté autenticado”.

4. Optional feature — solo si la feature está disponible

Cuándo usarlo: el requisito solo aplica si una característica, módulo, plan o configuración está activa.

Plantilla:

Where <feature is present>, the <system> shall <response>.

Ejemplos:

Where the user has a Premium subscription, the export service shall allow exporting files larger than 100 MB.

Where multi-factor authentication is enabled for the account, the login flow shall require a one-time code after password verification.

Where the device has a biometric sensor, the application shall offer fingerprint login as an alternative to password.

Diferencia con If/Then: Where describe una configuración estática o capacidad del sistema (planes, hardware, features). If/Then describe condiciones dinámicas o no deseadas.

5. Unwanted behaviour — respuesta ante condiciones no deseadas

Cuándo usarlo: definís cómo reacciona el sistema cuando algo va mal: errores, fallos, condiciones excepcionales, abuso.

Plantilla:

If <unwanted condition>, then the <system> shall <response>.

Ejemplos:

If the payment gateway returns a timeout, then the checkout service shall display an error message and shall preserve the cart contents.

If the user enters an invalid OTP three times within five minutes, then the authentication service shall lock the account for 15 minutes and shall send an alert email.

If the disk usage exceeds 90%, then the logging subsystem shall rotate logs and shall emit a warning event to the monitoring channel.

Característica clave: define explícitamente comportamientos de error. Sin esto, los developers improvisan y los testers no saben qué validar.

Tabla resumen

Patrón	Palabra clave	Ejemplo en una línea
Ubiquitous	—	The API shall return JSON.
Event-driven	When	When X happens, the system shall Y.
State-driven	While	While X is true, the system shall Y.
Optional feature	Where	Where feature X is present, the system shall Y.
Unwanted behaviour	If ... then	If X goes wrong, then the system shall Y.

Decidir qué patrón aplica

flowchart TD
    Start[Quiero escribir un requisito] --> Q1{¿Aplica siempre?}
    Q1 -->|Sí| Ubi[Ubiquitous]
    Q1 -->|No| Q2{¿Reacciona a un evento puntual?}
    Q2 -->|Sí| Event[Event-driven con When]
    Q2 -->|No| Q3{¿Aplica mientras un estado dura?}
    Q3 -->|Sí| State[State-driven con While]
    Q3 -->|No| Q4{¿Depende de una feature/capacidad?}
    Q4 -->|Sí| Optional[Optional feature con Where]
    Q4 -->|No| Q5{¿Es respuesta a condición no deseada?}
    Q5 -->|Sí| Unwanted[Unwanted behaviour con If/Then]
    Q5 -->|No| Recheck[Re-analizar: probablemente sea compuesto]

Si la respuesta es “no” a las cinco preguntas, el requisito probablemente combine varios. Partilo.

En el siguiente capítulo profundizamos en la sintaxis: palabras clave, voz activa, sujeto explícito y verbos verificables.