# Sintaxis de requisitos EARS explicada, con ejemplos Canonical: https://specscore.md/es/articles/ears-requirements/ Última actualización: 2 de noviembre de 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) es una notación de requisitos: un conjunto pequeño de patrones de frase en inglés, también llamado sintaxis EARS, que mantiene una condición, un disparador y una respuesta del sistema en un orden fijo. Un requisito es una obligación comprobable que un sistema debe cumplir. El [desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/) (SDD, spec-driven development) es la práctica de escribir esa obligación en una especificación antes del código, y tratar la especificación como la fuente de verdad. Un documento de requisitos de producto (PRD, product requirements document) es la prosa que enuncia el problema y el alcance antes de partir el trabajo en tareas. En [SpecScore](https://specscore.md/), un requisito (REQ) es una regla con nombre dentro de una funcionalidad, y un criterio de aceptación (AC, acceptance criterion) es una condición abstracta y opcional que apunta a una o más de esas reglas. La [integración continua](https://specscore.md/es/validators/) (CI, continuous integration) es una comprobación automática en cada cambio propuesto. La comprobación es un comando de la [interfaz de línea de comandos](https://specscore.md/es/cli/) (CLI, command-line interface): `specscore spec lint`. [Kiro](https://kiro.dev/), un entorno de desarrollo integrado (IDE, integrated development environment) con agentes de Amazon Web Services (AWS), escribe uno de estos patrones. La notación la publicaron por primera vez Alistair Mavin y colegas de Rolls-Royce en una conferencia de ingeniería de requisitos del Institute of Electrical and Electronics Engineers (IEEE) en 2009. ## De dónde viene EARS Alistair Mavin, Philip Wilkinson, Adrian Harwood y Mark Novak, entonces en Rolls-Royce PLC, publicaron “Easy Approach to Requirements Syntax (EARS)” en la 17.ª IEEE International Requirements Engineering Conference en 2009. El identificador del documento es [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9). Construyeron las reglas al extraer requisitos de control de motor de la Certification Specification for Engines (CS-E), sección CS-E 50, una regulación de aeronavegabilidad. Esa fuente mezclaba requisitos, guía de diseño y notas. El artículo nombra ocho problemas del lenguaje natural sin restricciones: ambigüedad, vaguedad, complejidad, omisión, duplicación, palabrería, implementación inapropiada e imposibilidad de prueba. Un conjunto pequeño de reglas debía permitir que cada requisito usara una de cinco plantillas. Los autores dicen que la notación sirve para requisitos de alto nivel de las partes interesadas, y no afirman que cubra todos los niveles de descomposición del sistema. La [guía del propio Mavin](https://alistairmavin.com/ears/) describe EARS como una forma de constreñir con suavidad los requisitos textuales. Las cláusulas permanecen en un orden, lo que él llama lógica temporal: cualquier precondición, luego el disparador, luego el nombre del sistema y la respuesta. Su conjunto de reglas es cero o muchas precondiciones, cero o un disparador, un nombre de sistema y una o muchas respuestas. El artículo de 2009 especializa esa forma en cinco plantillas. La misma guía también nombra los requisitos complejos, que combinan las palabras clave. En el estudio de caso del artículo, el extracto original tenía 36 requisitos y el conjunto reescrito tenía 47. La longitud media bajó de 36,9 palabras a 25,6. Los autores informan que, en ese estudio, la complejidad, la omisión, la duplicación, la implementación inapropiada y la imposibilidad de prueba estaban ausentes del conjunto reescrito, mientras que la ambigüedad, la vaguedad y la palabrería se redujeron y no se eliminaron. También enumeran los límites: una muestra pequeña, solo requisitos de seguridad de alto nivel y juicio al clasificar la vaguedad. Esas cifras son las del artículo, para ese único documento. ## Los patrones de frase EARS Las palabras clave son las del artículo de 2009 y de la guía de Mavin. El artículo también permite *During* en lugar de *While* para un estado, con el mismo significado, cuando se lee con más claridad. Las frases de ejemplo ilustran las plantillas. No son citas del artículo. Kiro escribe el patrón dirigido por eventos en mayúsculas; la notación original usa mayúscula inicial. Los ejemplos se quedan en inglés porque la sintaxis EARS es inglesa. ### Ubicuo `The shall ` Siempre activo. No hay palabra clave EARS, porque no hay precondición ni disparador. La ilustración del propio artículo de 2009 es un sistema de control que debe impedir el exceso de velocidad del motor. **Ejemplo:** The checkout system shall keep the order total equal to the sum of its line items. ### Dirigido por eventos `When , the shall ` La respuesta se exige cuando se detecta un disparador en la frontera del sistema, y solo entonces. La palabra clave es *When*. **Ejemplo:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### Dirigido por estado `While , the shall ` La respuesta se exige mientras el sistema permanece en el estado nombrado. La palabra clave es *While*. **Ejemplo:** While the cart is empty, the checkout system shall keep the pay button disabled. ### Comportamiento no deseado `If , then the shall ` La respuesta trata un fallo, una perturbación, una desviación u otro comportamiento no deseado. Las palabras clave son *If* y *then*. El artículo dio a este patrón sus propias palabras clave para que esos requisitos sigan siendo visibles. Los autores señalan que deseado y no deseado a veces es una cuestión de punto de vista. **Ejemplo:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### Función opcional `Where , the shall ` La respuesta se aplica solo cuando el producto incluye la función nombrada. La palabra clave es *Where*. **Ejemplo:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### Complejo `While , when , the shall ` Más de una palabra clave. La guía de Mavin mantiene el mismo orden de cláusulas: *While* para la precondición, luego *When* para el disparador, luego la respuesta del sistema. El artículo de 2009 también combina *While* con *If / then* para un comportamiento no deseado en un estado. Una ilustración de esa combinación: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **Ejemplo:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## Errores habituales ### Varias obligaciones en una frase El artículo trata una frase compuesta como el problema de complejidad y la parte. La [especificación de requisitos de SpecScore](https://specscore.md/requirement-specification) dice lo mismo en sus términos: cada `REQ` debe expresar exactamente una obligación comprobable. ### Esconder el comportamiento no deseado en When *When* es para un disparador que se espera. *If / then* es para el comportamiento que preferirías no encontrar. Usar una sola palabra clave para ambos hace que el caso no deseado parezca el caso normal, que es el problema de omisión que el artículo señaló. ### Escribir la implementación “The checkout system shall store the flag in Redis” nombra un diseño. El artículo llama a eso implementación inapropiada. La respuesta debe decir qué debe lograr el sistema, no qué componente lo hace. ### Sin nombre de sistema “When the form is submitted, shall show an error” no tiene sujeto. El conjunto de reglas de Mavin exige un nombre de sistema. ### El disparador después de la respuesta “The checkout system shall show an error when the form is submitted” pone el disparador al final. El orden publicado es precondición, luego disparador, luego respuesta. ### Tomar la línea de Kiro por todo EARS La página de especificaciones de funcionalidad de Kiro publica un solo patrón, `WHEN … THE SYSTEM SHALL …`. Lo ubicuo, *While*, *If / then*, *Where* y las combinaciones complejas forman parte de la notación en el artículo y en la guía de Mavin. No están en esa página de Kiro. ## Cómo usa Kiro EARS La [página de especificaciones de funcionalidad de Kiro](https://kiro.dev/docs/specs/feature-specs/), marcada como actualizada el 4 de agosto de 2026 y leída el 2 de noviembre de 2026, dice que el archivo `requirements.md` usa EARS. El patrón impreso allí es `WHEN [condition/event]` seguido de `THE SYSTEM SHALL [expected behavior]`. El ejemplo de la página es: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. La [página de requisitos primero](https://kiro.dev/docs/specs/feature-specs/requirements-first/) dice que un `requirements.md` generado incluye historias de usuario con criterios de aceptación y comportamientos del sistema en esa misma forma WHEN … THE SYSTEM SHALL …. Su ejemplo de registro son tres frases: los datos de registro válidos crean una cuenta, un correo que ya existe muestra “Email already registered” y un formato de correo inválido muestra un error de validación. Antes del diseño, Analyze Requirements busca inconsistencias lógicas, ambigüedades, restricciones en conflicto y huecos. La página de especificaciones de funcionalidad dice que se elige desde las opciones del chat o el menú Continue del editor después de generar los requisitos. `design.md` y `tasks.md` van junto a los requisitos. Quick Spec ejecuta requisitos, diseño y tareas sin una parada de aprobación entre ellos. Ese análisis es un paso dentro de Kiro. La página de especificaciones de funcionalidad no lo describe como un linter de formato que añades a tu propia CI. Cómo comprueban la especificación otras herramientas está en la [guía de herramientas](https://specscore.md/es/spec-driven-development/tools/). La comparación de los dos productos es [SpecScore vs Kiro](https://specscore.md/es/vs/kiro/). ## El mismo requisito en SpecScore SpecScore no comprueba que una frase coincida con una plantilla EARS. `specscore spec lint`, del repositorio [specscore-cli](https://github.com/specscore/specscore-cli), comprueba la estructura. Su texto de ayuda nombra archivos README, secciones Open Questions, niveles de encabezado, referencias a funcionalidades, enlaces internos y entradas de índice. Una frase EARS puede ser la prosa bajo un encabezado `REQ`. El linter no califica el inglés. La [especificación de requisitos](https://specscore.md/requirement-specification) coloca cada requisito bajo un encabezado de tema dentro de `## Behavior`, un nivel más abajo, normalmente `#### REQ: slug`. El slug usa letras minúsculas, números y guiones. El identificador es `{feature-path}#req:{slug}`. La especificación dice que un requisito debería usar palabras clave de RFC 2119 (Request for Comments 2119): MUST, MUST NOT, SHOULD, SHOULD NOT y MAY. En el mapeo de abajo, el *shall* de EARS se escribe como MUST. Un [criterio de aceptación](https://specscore.md/acceptance-criteria-specification) es opcional. Cuando se usa, es `### AC: slug` dentro de `## Acceptance Criteria`, y la línea siguiente es `**Requirements:**` con esos identificadores. La especificación de criterios de aceptación dice que el AC enuncia una condición abstracta y no debe contener pasos Given/When/Then, entradas concretas ni detalle de implementación. Un flujo concreto es un [escenario](https://specscore.md/scenario-specification) en el directorio `_tests/` de la funcionalidad. La [especificación de funcionalidad](https://specscore.md/feature-specification) también exige un estado, un resumen, un problema, el comportamiento, criterios de aceptación, preguntas abiertas y un pie de adherencia. Los archivos de abajo son una funcionalidad de pago. `show-field-error` es el ejemplo dirigido por eventos. `reject-invalid-email` es el ejemplo de comportamiento no deseado. El 2 de noviembre de 2026, `specscore spec lint` informó 0 infracciones para este árbol con specscore 0.55.1, la última versión publicada el 30 de octubre de 2026, y con specscore 0.39.1, la versión fijada en [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). El [repositorio del formato](https://github.com/specscore/specscore) es donde vive ese flujo. ### spec/features/checkout/README.md ```markdown --- format: https://specscore.md/feature-specification status: Draft --- # Feature: Checkout validation > [SpecScore.**Studio**](https://specscore.studio): | [Explore](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=explore) | [Edit](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=edit) | [Ask question](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=ask) | [Request change](https://specscore.studio/app/github.com/example/checkout/spec/features/checkout?op=request-change) | **Status:** Draft **Source Ideas:** — ## Summary The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. ## Problem A vague sentence such as "the form should handle bad input" does not say which event causes which response. Checkout needs those obligations written so a reviewer and a linter can point at them. ## Behavior ### Field validation The checkout system checks the form when the shopper submits it. #### REQ: show-field-error When a shopper submits the checkout form with invalid data, the checkout system MUST show a validation error next to the invalid field. #### REQ: reject-invalid-email If the submitted email is not a valid address, then the checkout system MUST reject the form. ## Acceptance Criteria ### AC: invalid-submission **Requirements:** checkout#req:show-field-error, checkout#req:reject-invalid-email Submitting the checkout form with invalid data shows a validation error next to the invalid field, and an email that is not a valid address is rejected. ## Open Questions None at this time. --- *This document follows the https://specscore.md/feature-specification* ``` ### spec/features/README.md — la celda de descripción es la frase de resumen de la funcionalidad. La regla feature-index-row-sync del linter rechazó una descripción más corta. ```markdown --- format: https://specscore.md/features-index-specification --- # Features | Feature | Status | Description | |---|---|---| | [Checkout validation](checkout/README.md) | Draft | The checkout form shows a validation error next to a field when the shopper submits invalid data, and it rejects an email that is not a valid address. | ## Open Questions None at this time. --- *This document follows the https://specscore.md/features-index-specification* ``` ### spec/README.md — quitar la sección Open Questions produjo oq-section: Open Questions section not found. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org y project.repo son lo que se contrasta con la línea studio-toolbar. Sin ellos el linter informó studio-toolbar: studio toolbar requires project host/org/repo. ```yaml # SpecScore Repo Config Schema: https://specscore.md/repo-config project: title: Checkout sample host: github.com org: example repo: checkout ``` Aparecieron dos errores más al hacer que esta muestra pasara, y ambos están corregidos en los archivos de arriba. Una funcionalidad sin `**Source Ideas:**` falló `feature-source-ideas-required`; `—` es el valor vacío. El índice de funcionalidades también necesitaba el campo de frontmatter `format: https://specscore.md/features-index-specification`. Que el linter pase significa que los archivos cumplen esas reglas estructurales. No significa que las frases sean buen EARS, ni que el producto de pago exista. El Given/When/Then de este comportamiento sería un archivo de escenario bajo `spec/features/checkout/_tests/`, no otro párrafo dentro del AC. ## Preguntas ### ¿Qué significa EARS? Easy Approach to Requirements Syntax. Es un conjunto de patrones de frase para requisitos, publicado por Alistair Mavin, Philip Wilkinson, Adrian Harwood y Mark Novak, de Rolls-Royce, en la 17.ª IEEE International Requirements Engineering Conference en 2009, y descrito en el sitio de Mavin. ### ¿La notación de Kiro es todo EARS? La página de especificaciones de funcionalidad de Kiro especifica un patrón: WHEN … THE SYSTEM SHALL …. El artículo de 2009 y la guía de Mavin también definen requisitos ubicuos, While dirigido por estado, If/then para comportamiento no deseado, Where para función opcional y combinaciones complejas de esas palabras clave. ### ¿SpecScore valida la sintaxis EARS? No. `specscore spec lint` valida la estructura de archivos de SpecScore. Una frase EARS puede ser la prosa de un `REQ`. El linter no califica el inglés. ### ¿Dónde van los ejemplos Given/When/Then? En un escenario bajo el directorio `_tests/` de la funcionalidad. Un criterio de aceptación sigue siendo una condición abstracta y, en la especificación de criterios de aceptación, no debe contener pasos Given/When/Then. ## Fuentes Leído el 2 de noviembre de 2026, salvo donde una página imprime su propia fecha de actualización. La página de especificaciones de funcionalidad de Kiro dice que se actualizó el 4 de agosto de 2026. - [Mavin, Wilkinson, Harwood y Novak — Easy Approach to Requirements Syntax (EARS), 17.ª IEEE International Requirements Engineering Conference, 2009, DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Alistair Mavin — guía EARS](https://alistairmavin.com/ears/) - [Documentación de Kiro — especificaciones de funcionalidad y EARS (página actualizada el 4 de agosto de 2026)](https://kiro.dev/docs/specs/feature-specs/) - [Documentación de Kiro — flujo de requisitos primero](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — especificación de requisitos](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — especificación de criterios de aceptación](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — especificación de escenarios](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — especificación de funcionalidad](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — flujo de CI dogfood](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml) - [specscore/specscore-cli](https://github.com/specscore/specscore-cli) - [specscore/specscore](https://github.com/specscore/specscore) ## Relacionado - [Plantilla de PRD en Markdown para programar con IA](https://specscore.md/es/articles/feature-spec-template/) - [Lintear especificaciones en CI con un linter de especificaciones](https://specscore.md/es/articles/lint-specs-in-ci/) - [Cómo escribir criterios de aceptación que un agente de IA pueda verificar](https://specscore.md/es/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/es/vs/kiro/) - [Herramientas de desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/tools/) - [Desarrollo basado en especificaciones](https://specscore.md/es/spec-driven-development/) - [Especificación de requisitos](https://specscore.md/requirement-specification) - [Especificación de criterios de aceptación](https://specscore.md/acceptance-criteria-specification) - [Especificación de funcionalidad](https://specscore.md/feature-specification) - [Validadores y CI](https://specscore.md/es/validators/)