Taller: de prosa a EARS

La mejor forma de aprender EARS es reescribir requisitos reales. Acá hay 10 casos típicos extraídos de proyectos reales (sanitizados). Para cada uno: el original, el análisis y la versión en EARS.

Caso 1 — login

Original:

El usuario debe poder iniciar sesión con email y contraseña. Si las credenciales son incorrectas se mostrará un mensaje de error.

Problemas:

• “Debe poder” — voz oblicua
• “Se mostrará” — pasiva, actor implícito
• Dos requisitos en una frase
• Sin métricas

Reescrito:

REQ-AUTH-001: When the user submits the login form with email and password, the auth service shall validate the credentials against the identity store and shall issue a session token valid for 24 hours.

REQ-AUTH-002: If the auth service cannot validate the credentials, then the auth service shall return HTTP 401 and the application shall display the message "Email or password incorrect" without revealing which field failed.

Caso 2 — exportación

Original:

El sistema permitirá exportar reportes en PDF, Excel y CSV. Será rápido.

Problemas:

• “Permitirá” — pasivo, sin disparador
• “Será rápido” — no verificable
• Sin disparador

Reescrito:

REQ-EXP-001: When the user clicks "Export" and selects a format (PDF, XLSX, CSV), the export service shall generate the file in the selected format and shall offer it for download.

REQ-EXP-002 (no-funcional): When the export service generates a report of up to 10000 rows, it shall complete within 5 seconds at the 95th percentile.

REQ-EXP-003 (no-funcional): If the export contains more than 10000 rows, then the export service shall process it asynchronously and shall send an email with a download link when ready.

Caso 3 — notificaciones

Original:

El sistema enviará notificaciones cuando algo importante ocurra.

Problemas:

• “Algo importante” — completamente vago
• Sin definir canal, contenido, frecuencia

Reescrito:

REQ-NOTIF-001: When an order assigned to the user changes status, the notification service shall send a push notification to the user's registered devices within 30 seconds.

REQ-NOTIF-002: When an invoice assigned to the user becomes overdue, the notification service shall send an email to the user's primary email address with the invoice number and amount.

REQ-NOTIF-003: Where the user has enabled SMS alerts in their preferences, when a payment of more than $5000 is processed on the user's account, the notification service shall additionally send an SMS to the registered phone number.

Caso 4 — búsqueda

Original:

Habrá una barra de búsqueda que mostrará resultados relevantes mientras el usuario escribe.

Problemas:

• “Habrá” — descripción de UI, no comportamiento
• “Relevantes” — sin criterio
• “Mientras escribe” — confunde estado y evento

Reescrito:

REQ-SEARCH-001: When the user types in the search field, after a debounce of 300 ms, the search service shall return up to 20 matching records ordered by descending relevance score and shall display them in a dropdown below the search field.

REQ-SEARCH-002: The search service shall compute relevance using BM25 over the indexed fields (title, description, tags) with field weights 5, 2, 1 respectively.

Caso 5 — autoguardado

Original:

Los cambios se guardarán automáticamente.

Problemas:

• Pasiva
• Sin frecuencia
• Sin manejo de error

Reescrito:

REQ-AUTOSAVE-001: While the user is editing a document, every 5 seconds, if there are unsaved changes, the editor shall persist the document state to the backend.

REQ-AUTOSAVE-002: When the autosave succeeds, the editor shall display "Saved" in the status bar for 2 seconds.

REQ-AUTOSAVE-003: If the autosave fails due to network error, then the editor shall queue the changes locally and shall retry every 30 seconds while displaying "Offline — changes will sync when reconnected" in the status bar.

Caso 6 — auditoría

Original:

Deben registrarse todas las acciones de los administradores para auditoría.

Problemas:

• “Deben registrarse” — pasiva
• “Todas las acciones” — sin enumerar
• Sin formato ni retención

Reescrito:

REQ-AUDIT-001: When an administrator performs any of the following actions (create user, delete user, change role, change permission, export data, modify system settings), the audit service shall persist an audit entry to the audit log.

REQ-AUDIT-002: Each audit entry shall include: actor user ID, action type, target resource ID, timestamp in ISO 8601 UTC, source IP, and request ID.

REQ-AUDIT-003: The audit service shall retain audit entries for a minimum of 7 years and shall not allow deletion or modification of existing entries.

Caso 7 — concurrencia

Original:

Si dos usuarios editan al mismo tiempo, el sistema debe manejar el conflicto.

Problemas:

• “Manejar el conflicto” — sin definir
• Falta granularidad

Reescrito:

REQ-CONC-001: If two users submit edits to the same document within the same revision window, then the persistence service shall apply the first submission, shall reject the second with HTTP 409, and shall return the current revision identifier.

REQ-CONC-002: When a client receives a 409 response on a document save, the editor shall fetch the latest revision, shall display the user's local changes alongside the latest version, and shall offer a manual merge interface.

Caso 8 — performance

Original:

El sistema soportará muchos usuarios concurrentes.

Problemas:

• “Muchos” — sin número
• Sin condiciones (carga, datos)

Reescrito:

REQ-PERF-001: When 1000 concurrent users issue requests at a rate of 10 requests per second per user, the API shall maintain a 95th percentile latency below 200 ms for read endpoints and below 500 ms for write endpoints.

REQ-PERF-002: When the API receives more than 15000 requests per second sustained for 60 seconds, the rate limiter shall begin returning HTTP 429 with a Retry-After header to excess requests.

Caso 9 — accesibilidad

Original:

La app debe ser accesible.

Problemas:

• Sin estándar
• Sin criterios

Reescrito:

REQ-A11Y-001: The application shall conform to WCAG 2.2 Level AA for all interactive views.

REQ-A11Y-002: Every interactive element shall be reachable and operable using keyboard navigation alone.

REQ-A11Y-003: Every form input shall have an associated visible label and a programmatic accessible name.

REQ-A11Y-004: The application shall maintain a minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text and graphical elements.

Caso 10 — privacidad

Original:

Los datos personales del usuario serán manejados con confidencialidad.

Problemas:

• Pasiva
• “Confidencialidad” — sin operacionalizar

Reescrito:

REQ-PRIV-001: The persistence layer shall encrypt all fields classified as "personal data" using AES-256-GCM with keys managed by the KMS.

REQ-PRIV-002: When the user requests data export under GDPR Article 20, the privacy service shall provide a complete export within 30 calendar days in a machine-readable format (JSON).

REQ-PRIV-003: When the user requests deletion under GDPR Article 17, the privacy service shall delete all personal data within 30 calendar days, shall retain only the data required by legal obligations, and shall provide a deletion confirmation.

REQ-PRIV-004: Where the user has not granted marketing consent, the marketing service shall not include the user's contact information in any campaign.

Patrón común de reescritura

Para cualquier requisito vago, aplicá estas preguntas:

1. ¿Quién ejecuta la acción? → sujeto explícito
2. ¿Cuándo ocurre? → When / While / Where / If
3. ¿Qué hace exactamente el sistema? → respuesta concreta
4. ¿Cómo se mide que se cumple? → criterio observable

Si una de estas preguntas no tiene respuesta clara, el requisito no está listo.

Ejercicio para el lector

Tomá cinco requisitos de un proyecto real y reescribilos. Vas a notar que el ejercicio de reescritura revela ambigüedades que ni el autor original había percibido — ése es el verdadero valor de EARS.

En el siguiente capítulo vemos cómo EARS se integra con User Stories y metodologías ágiles.