Casos de estudio y dominios regulados

EARS nació en aeronáutica, donde un requisito mal escrito puede costar vidas. Hoy se aplica en cualquier dominio donde la precisión paga. Esta sección resume cómo se aplica en distintos sectores.

Aeronáutico — el origen

Rolls-Royce, motores Trent (2009-actual)

Mavin y su equipo en Rolls-Royce evaluaron requisitos de FADEC (Full Authority Digital Engine Control) usando EARS. Resultados publicados:

• Reducción de defectos de requisitos en revisiones formales > 50%
• Eliminación total de voz pasiva
• Reducción de “requisitos compuestos” de ~25% a < 3%
• Reducción de tiempo de revisión por documento

Lección: en dominios safety-critical, la disciplina sintáctica de EARS no es opcional. Se complementa con estándares como DO-178C (software aeronáutico) y ARP 4754A (development of civil aircraft systems).

Médico — dispositivos clase II/III

Marcapasos, bombas de infusión, sistemas de imagen

Los requisitos regulados por IEC 62304 (software médico) y FDA 21 CFR 820 exigen trazabilidad requisito → diseño → código → test. EARS encaja:

REQ-PUMP-014: While the pump is delivering medication, when the patient presses the "Stop" button, the pump controller shall halt delivery within 50 ms and shall log the stop event with timestamp, dose delivered, and user ID.

REQ-PUMP-015: If the pump controller detects an over-infusion condition (rate > maximum_safe_rate), then the pump controller shall halt delivery, shall sound the audible alarm at >= 65 dB at 1 m, and shall not allow restart until a clinician acknowledges the alarm.

Lección: las respuestas con métricas absolutas (50 ms, 65 dB) son verificables y auditables. Sin EARS, los auditores reportan “ambiguo / no verificable” como observación crítica.

Automotriz — ISO 26262 y ASIL

Sistemas ADAS, frenos, dirección asistida

ISO 26262 define ASIL (Automotive Safety Integrity Level). Requisitos para componentes ASIL D (el nivel más alto) deben ser verificables formalmente. EARS reduce la brecha entre prosa y modelos formales:

REQ-AEB-008: While the vehicle is moving forward at speed > 5 km/h, when the forward radar detects an obstacle at TTC < 1.5 s, the AEB controller shall apply maximum braking force without driver input.

REQ-AEB-009: If the AEB controller detects a radar fault (RadarStatus != HEALTHY), then the AEB controller shall transition to degraded mode, shall display a warning on the dashboard, and shall not engage automatic braking.

Lección: combinar While + When modela bien las condiciones de activación de funciones autónomas. If + then modela los modos degradados exigidos por ISO 26262.

Fintech — pagos, KYC, compliance

Procesamiento de pagos, KYC, AML

PCI-DSS, PSD2, SOC2 requieren controles auditables. EARS define controles como requisitos verificables:

REQ-PCI-003: The payment service shall not log full PAN (Primary Account Number). The service shall log only the last 4 digits of the PAN, in the format "**** **** **** XXXX".

REQ-AML-021: When a transaction exceeds $10000, the transaction service shall create an AML alert with the customer ID, transaction ID, amount, currency, and timestamp.

REQ-PSD2-007: Where the user has enabled Strong Customer Authentication, when a payment exceeds €30 or the cumulative payments since last SCA exceed €100, the auth service shall require a second factor before authorizing the payment.

Lección: cada control de compliance se expresa como un REQ. Los auditores valoran la trazabilidad: control de norma → REQ → test.

Software comercial — SaaS y producto

SaaS B2B, marketplaces, herramientas internas

Sin obligaciones regulatorias, los equipos a veces resisten EARS por “burocrático”. Pero los beneficios siguen aplicando:

• Onboarding más rápido: nuevos developers entienden el sistema leyendo specs en lugar de descifrar código
• Discusiones más cortas: el refinamiento se enfoca en si el AC es correcto, no en qué significa
• Estimaciones más estables: hay menos varianza sobre “qué estamos por construir”
• Soporte de IA: los agentes implementan con más precisión

Lección: en software comercial, EARS no es opcional para los AC. La historia de usuario (Como X, quiero Y, para Z) sin AC en EARS es solo intención.

Caso integrado: implementación de feature compleja

Contexto: empresa SaaS de gestión de turnos. Implementan “recordatorios por SMS para citas”.

Historia:

Como cliente con cita agendada, quiero recibir un SMS de recordatorio antes de mi turno, para no olvidarlo.

Requisitos EARS:

REQ-REM-001: When a customer has an appointment scheduled in the next 24 hours, the reminder service shall send an SMS reminder 24 hours before the appointment start time.

REQ-REM-002: When a customer has an appointment scheduled in the next 24 hours, if the appointment is less than 24 hours in the future at the time of scheduling, the reminder service shall send the SMS reminder immediately if more than 1 hour remains.

REQ-REM-003: The SMS reminder shall contain: customer first name, business name, appointment date in customer's locale, appointment time in customer's timezone, and a link to reschedule.

REQ-REM-004: Where the customer has opted out of SMS reminders, the reminder service shall not send any SMS regardless of the appointment status.

REQ-REM-005: If the SMS provider returns an error, then the reminder service shall retry up to 3 times over 10 minutes and shall log an error event if all retries fail.

REQ-REM-006: The reminder service shall not send the same reminder more than once per appointment.

REQ-REM-007 (no-funcional): The reminder service shall send 95% of reminders within 60 seconds of the scheduled send time.

REQ-REM-008 (no-funcional): The reminder service shall comply with TCPA — between 21:00 and 08:00 in the customer's timezone, the reminder service shall not send SMS reminders. Reminders scheduled in that window shall be sent at 08:01.

Resultado: 8 requisitos cubren todos los aspectos. Cada uno se traduce a tests. Los developers no inventan comportamientos. Los testers cubren todos los casos. El PM puede revisar y aprobar sin ambigüedad.

Errores comunes en la adopción

1. “EARS es para waterfall, nosotros somos Agile”

EARS es notación, no proceso. Funciona en cualquier metodología. Las historias siguen siendo INVEST; los AC se escriben en EARS.

2. “Es muy verboso”

Sí, los EARS son más largos que prosa. Pero son más cortos que el código de tests que te ahorran y los bug-fixes que evitás.

3. “Mi equipo no quiere aprender”

EARS se aprende en 2-3 horas. La curva es plana: una vez vista, las 5 plantillas son fáciles de aplicar.

4. “No tenemos tiempo para escribir requisitos formales”

El tiempo invertido escribiendo requisitos se recupera en revisión, implementación, tests y bug-fixing. La evidencia (Rolls-Royce, ESA, NASA, equipos comerciales) es consistente.

Recursos oficiales

• Guía oficial: alistairmavin.com/ears
• Paper original: “Easy Approach to Requirements Syntax (EARS)” — Mavin, Wilkinson, Harwood, Novak (RE’09)
• Recursos comunidad: GitHub discussions, presentaciones de Mavin en conferencias

Próximos pasos

Si te interesa profundizar:

1. Leé la guía oficial de Mavin (en inglés, 30 minutos de lectura)
2. Aplicá EARS a un proyecto real esta semana — reescribí 5 AC
3. Compartí con tu equipo y discutí los antipatrones que aparezcan
4. Combinalo con Gherkin para tests ejecutables (tutorial Gherkin)

Cierre

EARS no es una bala de plata. Sigue requiriendo pensamiento crítico, dominio del problema y revisión. 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 cualquier dominio, mejora la calidad. La adopción es barata, el ROI es alto y se compone con las herramientas que ya usás (Agile, BDD, agentes de IA, Spec-Driven Development).

Empezá hoy. Tomá una historia que estés por refinar, escribí los AC en EARS y observá cuántas ambigüedades aparecen.