← Volver al listado de tecnologías ← Índice de EARS

Antipatrones y errores comunes

15 de mayo de 2026 Por: Artiko

earsantipatroneserrores-comunescalidad-requisitos

Antipatrones y errores comunes

Escribir requisitos malos es fácil, escribir buenos requisitos requiere disciplina. Esta sección lista los errores más frecuentes — todos resolubles con EARS.

1. Voz pasiva

Síntoma: el actor desaparece.

- Los datos serán encriptados antes de almacenarse.
+ Before persisting user data, the storage service shall encrypt the data using AES-256-GCM.

Por qué falla: nadie sabe quién encripta. Si hay un bug, no se sabe a quién atribuirlo. Si hay un cambio, no se sabe qué módulo modificar.

2. Requisito compuesto

Síntoma: una sola frase contiene varios requisitos disfrazados con and, or, also, además.

- Cuando el usuario inicia sesión, el sistema validará las credenciales, mostrará el dashboard, enviará una notificación push y registrará el evento en analytics.
+ When the user submits valid credentials, the auth service shall issue a session token.
+ When a session token is issued, the application shall navigate to the dashboard.
+ When a session token is issued, the notification service shall send a "Welcome back" push notification.
+ When a session token is issued, the analytics service shall record a "login_success" event.

Test: si podés escribir 3+ tests independientes para verificar un requisito, son 3+ requisitos.

3. Palabras tóxicas

Lista de palabras que generan ambigüedad y deben evitarse:

Palabra	Por qué falla	Reemplazo
`apropiado`	Subjetivo	Especificar el criterio exacto
`fácil de usar`	No verificable	Métricas concretas o user testing
`etc`	No enumera	Listar todo o referenciar una norma
`y/o`	Ambiguo	Elegir `y`, o partir el requisito
`aproximadamente`	Sin precisión	Rango o número exacto
`rápidamente`	Sin métrica	”within 200 ms”
`usable`	Subjetivo	Criterios específicos
`intuitivo`	Subjetivo	Tests de usabilidad con métricas
`varios`	Cardinalidad indefinida	”at least 3”, “between 5 and 10”
`algunos`	Cardinalidad indefinida	Cardinalidad explícita
`escalable`	Demasiado amplio	”soporta N concurrentes con latencia X”
`seguro`	Demasiado amplio	Lista de controles específicos
`eventualmente`	Sin garantía temporal	”within X seconds” o “at next sync”

4. Ubiquitous donde corresponde Event-driven

- The system shall validate user inputs.
+ When the user submits the registration form, the validation service shall validate each field against its schema and shall return a list of errors if any field is invalid.

Casi nada en software es “siempre”. Si el comportamiento solo aplica al ocurrir algo, usá When.

5. When usado como While (o viceversa)

- When the user is authenticated, the dashboard shall display the user's avatar.
+ While the user is authenticated, the dashboard shall display the user's avatar.

When = puntual. While = continuo.

- While the user clicks the button, the system shall submit the form.
+ When the user clicks the button, the system shall submit the form.

6. Falta de cuantificación

Síntoma: respuestas sin métricas, plazos ni cardinalidades.

- When the user requests an export, the system shall generate the report quickly.
+ When the user requests an export, the report service shall generate the PDF and shall offer it for download within 10 seconds for reports of up to 10000 rows.

7. Especificar la implementación

EARS describe qué, no cómo.

- When the user logs in, the system shall query the users table in PostgreSQL with a SELECT statement and validate the bcrypt hash.
+ When the user submits the login form with credentials, the auth service shall validate the credentials against the identity store and shall return a session token within 500 ms.

El cómo es decisión del equipo de implementación. Filtrarlo en requisitos lock-in tecnología y limita refactorizaciones.

8. Requisitos negativos sin contraparte

- The system shall not allow unauthorized access.

¿Qué significa? ¿Cuál es la respuesta del sistema ante un acceso no autorizado? Mejor:

+ If a request is made to a protected endpoint without a valid session token, then the API shall return HTTP 401 with the body { "error": "unauthorized" } and shall not invoke any downstream service.

9. Mezclar requisitos funcionales y no funcionales

Mantenelos separados:

- When the user submits the form, the system shall validate it and the validation shall complete in under 100 ms.
+ REQ-FUNC-001: When the user submits the form, the validation service shall validate each field against the schema.
+ REQ-PERF-001: When the form validation runs, the validation service shall complete within 100 ms for the 95th percentile.

10. Requisitos sin sujeto claro

- Deberá poder buscarse por nombre.
+ When the user types a query in the search bar, the search service shall return matching records ordered by relevance within 300 ms.

11. Referencia circular o externa sin trazabilidad

- The system shall comply with the security policy.
+ The system shall enforce the access controls defined in REQ-SEC-001 through REQ-SEC-014 (see Section 4.2).

Mejor todavía: enumerá los requisitos en línea.

12. Tono especulativo o sugestivo

- The system should ideally support dark mode.
+ Where the user's OS preference is "dark", the application shall render the UI using the dark color palette.
+ Where the user explicitly selects "dark" in the application settings, the application shall render the UI using the dark color palette regardless of OS preference.

should ideally no es un requisito, es un deseo.

Checklist anti-antipatrones

Antes de aprobar un requisito EARS, validá:

Tiene sujeto explícito (no voz pasiva)
Usa una de las 4 palabras clave o es ubiquitous
Contiene una sola respuesta (o múltiples atómicas)
No tiene palabras tóxicas (etc, varios, apropiado…)
La respuesta es verificable (medible o observable)
No describe implementación
Tiene ID único y trazable
Está en voz activa
Si es de error, está como If/Then separado

Diagrama de revisión

flowchart TD
    Start[Requisito candidato] --> Q1{¿Voz activa con sujeto?}
    Q1 -->|No| Fix1[Reescribir en voz activa]
    Q1 -->|Sí| Q2{¿Una sola respuesta?}
    Q2 -->|No| Fix2[Partir en varios REQ]
    Q2 -->|Sí| Q3{¿Sin palabras tóxicas?}
    Q3 -->|No| Fix3[Cuantificar o eliminar]
    Q3 -->|Sí| Q4{¿Patrón EARS aplicado correctamente?}
    Q4 -->|No| Fix4[Corregir When/While/Where/If]
    Q4 -->|Sí| Q5{¿Respuesta verificable?}
    Q5 -->|No| Fix5[Agregar métrica u observable]
    Q5 -->|Sí| Done[Aprobado]

En el siguiente capítulo hacemos un taller práctico: tomamos requisitos reales mal escritos y los reescribimos en EARS.