# Синтаксис требований EARS с объяснением и примерами Canonical: https://specscore.md/ru/articles/ears-requirements/ Обновлено: 2 ноября 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) — это нотация требований: небольшой набор английских шаблонов предложения, его же называют синтаксисом EARS. Шаблон держит условие, триггер и ответ системы в фиксированном порядке. Требование — одно проверяемое обязательство, которое система должна выполнить. [Разработка по спецификациям](https://specscore.md/ru/spec-driven-development/) (SDD, spec-driven development) — практика записать это обязательство в спецификацию до кода и считать спецификацию источником правды. Документ требований к продукту (PRD, product requirements document) — проза, которая называет проблему и рамки до того, как работу режут на задачи. В [SpecScore](https://specscore.md/) требование (REQ) — именованное правило внутри функции, а критерий приёмки (AC, acceptance criterion) — необязательное абстрактное условие, которое указывает на одно или несколько таких правил. [Непрерывная интеграция](https://specscore.md/ru/validators/) (CI, continuous integration) — автоматическая проверка каждого предлагаемого изменения. Проверка — команда [интерфейса командной строки](https://specscore.md/ru/cli/) (CLI, command-line interface): `specscore spec lint`. [Kiro](https://kiro.dev/), агентная интегрированная среда разработки (IDE, integrated development environment) от Amazon Web Services (AWS), пишет один из этих шаблонов. Нотацию впервые опубликовали Алистер Мэвин и коллеги из Rolls-Royce на конференции по инженерии требований Institute of Electrical and Electronics Engineers (IEEE) в 2009 году. ## Откуда взялся EARS Алистер Мэвин, Филип Уилкинсон, Эдриан Харвуд и Марк Новак, тогда в Rolls-Royce PLC, опубликовали «Easy Approach to Requirements Syntax (EARS)» на 17th IEEE International Requirements Engineering Conference в 2009 году. Идентификатор документа — [10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9). Правила сложились, когда они извлекали требования к управлению двигателем из Certification Specification for Engines (CS-E), раздел CS-E 50, нормы лётной годности. Исходный текст смешивал требования, проектные указания и заметки. Статья называет восемь проблем неограниченного естественного языка: неоднозначность, расплывчатость, сложность, пропуск, дублирование, многословие, неуместную реализацию и непроверяемость. Небольшой набор правил должен был уложить каждое такое требование в один из пяти шаблонов. Авторы пишут, что нотация подходит для высокоуровневых требований заинтересованных сторон, и не утверждают, что она покрывает каждый уровень декомпозиции системы. [Собственное руководство Мэвина](https://alistairmavin.com/ears/) описывает EARS как способ мягко ограничить текстовые требования. Части остаются в одном порядке, который он называет темпоральной логикой: любое предусловие, затем триггер, затем имя системы и ответ. Его набор правил: ноль или много предусловий, ноль или один триггер, одно имя системы и один или много ответов. Статья 2009 года специализирует эту форму в пять шаблонов. То же руководство называет и сложные требования, которые сочетают ключевые слова. В разборе случая из статьи сырой фрагмент содержал 36 требований, а переписанный набор — 47. Средняя длина упала с 36,9 до 25,6 слова. Авторы сообщают, что в этом разборе сложность, пропуск, дублирование, неуместная реализация и непроверяемость отсутствовали в переписанном наборе, а неоднозначность, расплывчатость и многословие уменьшились, но не исчезли. Они также перечисляют пределы: маленькая выборка, только высокоуровневые требования безопасности и суждение при классификации расплывчатости. Эти числа — из статьи, для одного документа. ## Шаблоны предложений EARS Ключевые слова — из статьи 2009 года и из руководства Мэвина. Статья также допускает *During* вместо *While* для состояния, с тем же смыслом, когда так читается яснее. Примеры иллюстрируют шаблоны. Это не цитаты из статьи. Kiro пишет событийный шаблон заглавными буквами; исходная нотация начинает ключевое слово с заглавной. Примеры остаются на английском, потому что синтаксис EARS английский. ### Повсеместное `The shall ` Всегда активно. Ключевого слова EARS нет, потому что нет ни предусловия, ни триггера. Собственный пример статьи 2009 года — система управления, которая должна не допускать превышения оборотов двигателя. **Пример:** The checkout system shall keep the order total equal to the sum of its line items. ### Событийное `When , the shall ` Ответ требуется, когда триггер обнаружен на границе системы, и только тогда. Ключевое слово — *When*. **Пример:** When a shopper submits the checkout form with invalid data, the checkout system shall show a validation error next to the invalid field. ### Состояние `While , the shall ` Ответ требуется, пока система остаётся в названном состоянии. Ключевое слово — *While*. **Пример:** While the cart is empty, the checkout system shall keep the pay button disabled. ### Нежелательное поведение `If , then the shall ` Ответ обрабатывает отказ, возмущение, отклонение или другое нежелательное поведение. Ключевые слова — *If* и *then*. Статья дала этому шаблону собственные слова, чтобы такие требования оставались видны. Авторы замечают, что желательное и нежелательное иногда зависит от точки зрения. **Пример:** If the submitted email is not a valid address, then the checkout system shall reject the form. ### Необязательная функция `Where , the shall ` Ответ действует, только если продукт включает названную функцию. Ключевое слово — *Where*. **Пример:** Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step. ### Сложное `While , when , the shall ` Больше одного ключевого слова. Руководство Мэвина сохраняет тот же порядок: *While* для предусловия, затем *When* для триггера, затем ответ системы. Статья 2009 года также сочетает *While* с *If / then* для нежелательного поведения в состоянии. Иллюстрация такого сочетания: While the shopper is signed out, if the shopper submits the checkout form, then the checkout system shall refuse the order. **Пример:** While the shopper is signed in, when the shopper submits a valid checkout form, the checkout system shall place the order. ## Типичные ошибки ### Несколько обязательств в одном предложении Статья считает составное предложение проблемой сложности и делит его. [Спецификация требования SpecScore](https://specscore.md/requirement-specification) говорит то же своими словами: каждый `REQ` должен выражать ровно одно проверяемое обязательство. ### Прятать нежелательное поведение в When *When* — для ожидаемого триггера. *If / then* — для поведения, которого лучше бы не встретить. Одно слово на оба случая делает нежелательный случай похожим на обычный. Это проблема пропуска, которую называет статья. ### Писать реализацию «The checkout system shall store the flag in Redis» называет проектное решение. Статья называет это неуместной реализацией. Ответ должен говорить, чего система должна достичь, а не какой компонент это делает. ### Нет имени системы «When the form is submitted, shall show an error» не имеет подлежащего. Набор правил Мэвина требует одно имя системы. ### Триггер после ответа «The checkout system shall show an error when the form is submitted» ставит триггер в конец. Опубликованный порядок: предусловие, затем триггер, затем ответ. ### Принимать одну строку Kiro за весь EARS Страница спецификаций функций Kiro публикует один шаблон, `WHEN … THE SYSTEM SHALL …`. Повсеместное, *While*, *If / then*, *Where* и сложные сочетания входят в нотацию статьи и руководства Мэвина. На этой странице Kiro их нет. ## Как Kiro использует EARS [Страница спецификаций функций Kiro](https://kiro.dev/docs/specs/feature-specs/), помеченная как обновлённая 4 августа 2026 года и прочитанная 2 ноября 2026 года, говорит, что файл `requirements.md` использует EARS. Напечатанный шаблон — `WHEN [condition/event]`, затем `THE SYSTEM SHALL [expected behavior]`. Пример страницы: WHEN a user submits a form with invalid data, THE SYSTEM SHALL display validation errors next to the relevant fields. [Страница «сначала требования»](https://kiro.dev/docs/specs/feature-specs/requirements-first/) говорит, что сгенерированный `requirements.md` включает пользовательские истории с критериями приёмки и поведение системы в той же форме WHEN … THE SYSTEM SHALL …. Пример регистрации — три предложения: верные данные регистрации создают учётную запись, уже существующая почта показывает «Email already registered», а неверный формат почты показывает ошибку проверки. До проекта Analyze Requirements ищет логические несогласованности, неоднозначность, конфликтующие ограничения и пробелы. Страница говорит, что это выбирают в параметрах чата или в меню Continue редактора после генерации требований. `design.md` и `tasks.md` стоят рядом с требованиями. Quick Spec проводит требования, проект и задачи без остановки на утверждение между ними. Этот разбор — шаг внутри Kiro. Страница не описывает его как линтер формата, который добавляют в собственный CI. Как другие инструменты проверяют спецификацию, написано в [обзоре инструментов](https://specscore.md/ru/spec-driven-development/tools/). Сравнение двух продуктов — [SpecScore vs Kiro](https://specscore.md/ru/vs/kiro/). ## То же требование в SpecScore SpecScore не проверяет, что предложение совпадает с шаблоном EARS. `specscore spec lint` из репозитория [specscore-cli](https://github.com/specscore/specscore-cli) проверяет структуру. Текст справки называет файлы README, разделы Open Questions, уровни заголовков, ссылки на функции, внутренние ссылки и строки индекса. Предложение EARS может быть прозой под заголовком `REQ`. Линтер не оценивает английский. [Спецификация требования](https://specscore.md/requirement-specification) помещает каждое требование под тематический заголовок внутри `## Behavior`, на один уровень ниже, обычно `#### REQ: slug`. Slug — строчные буквы, цифры и дефисы. Идентификатор — `{feature-path}#req:{slug}`. Спецификация говорит, что требование следует писать ключевыми словами RFC 2119 (Request for Comments 2119): MUST, MUST NOT, SHOULD, SHOULD NOT и MAY. В соответствии ниже EARS-овое *shall* записано как MUST. [Критерий приёмки](https://specscore.md/acceptance-criteria-specification) необязателен. Когда он есть, это `### AC: slug` внутри `## Acceptance Criteria`, а следующая строка — `**Requirements:**` с этими идентификаторами. Спецификация критериев приёмки говорит, что AC формулирует абстрактное условие и не должен содержать шаги Given/When/Then, конкретные входы или деталь реализации. Конкретный ход — [сценарий](https://specscore.md/scenario-specification) в каталоге `_tests/` функции. [Спецификация функции](https://specscore.md/feature-specification) также требует статус, краткое описание, проблему, поведение, критерии приёмки, открытые вопросы и нижний колонтитул соответствия. Файлы ниже — функция оформления заказа. `show-field-error` — событийный пример. `reject-invalid-email` — пример нежелательного поведения. 2 ноября 2026 года `specscore spec lint` сообщил 0 нарушений для этого дерева на specscore 0.55.1, последнем выпуске, опубликованном 30 октября 2026 года, и на specscore 0.39.1, версии, закреплённой в [dogfood.yml](https://github.com/specscore/specscore/blob/main/.github/workflows/dogfood.yml). [Репозиторий формата](https://github.com/specscore/specscore) — место этого потока. ### 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 — ячейка описания совпадает с предложением краткого описания функции. Правило линтера feature-index-row-sync отвергло более короткое описание. ```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 — удаление раздела Open Questions дало oq-section: Open Questions section not found. ```markdown # Checkout specification ## Open Questions None at this time. ``` ### specscore.yaml — project.host, project.org и project.repo — значения, с которыми сверяется строка studio-toolbar. Без них линтер сообщил 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 ``` Ещё две ошибки всплыли, пока этот пример доводили до прохождения, и обе исправлены в файлах выше. Функция без `**Source Ideas:**` не прошла `feature-source-ideas-required`; `—` — пустое значение. Индексу функций также нужно поле frontmatter `format: https://specscore.md/features-index-specification`. Успех линтера значит, что файлы соответствуют этим структурным правилам. Он не значит, что предложения — хороший EARS, и не значит, что продукт оформления заказа существует. Given/When/Then для этого поведения был бы файлом сценария в `spec/features/checkout/_tests/`, а не ещё одним абзацем внутри AC. ## Вопросы ### Что означает EARS? Easy Approach to Requirements Syntax. Это набор шаблонов предложения для требований, опубликованный Алистером Мэвином, Филипом Уилкинсоном, Эдрианом Харвудом и Марком Новаком из Rolls-Royce на 17th IEEE International Requirements Engineering Conference в 2009 году и описанный на сайте Мэвина. ### Нотация Kiro — это весь EARS? Страница спецификаций функций Kiro задаёт один шаблон: WHEN … THE SYSTEM SHALL …. Статья 2009 года и руководство Мэвина также определяют повсеместные требования, состояние While, If/then для нежелательного поведения, Where для необязательной функции и сложные сочетания этих ключевых слов. ### Проверяет ли SpecScore синтаксис EARS? Нет. `specscore spec lint` проверяет структуру файлов SpecScore. Предложение EARS может быть прозой `REQ`. Линтер не оценивает английский. ### Куда класть примеры Given/When/Then? В сценарий в каталоге `_tests/` функции. Критерий приёмки остаётся абстрактным условием и по спецификации критериев приёмки не должен содержать шаги Given/When/Then. ## Источники Прочитано 2 ноября 2026 года, кроме страниц, которые печатают собственную дату обновления. Страница спецификаций функций Kiro указывает обновление 4 августа 2026 года. - [Mavin, Wilkinson, Harwood и Novak — Easy Approach to Requirements Syntax (EARS), 17th IEEE International Requirements Engineering Conference, 2009, DOI 10.1109/RE.2009.9](https://doi.org/10.1109/RE.2009.9) - [Алистер Мэвин — руководство EARS](https://alistairmavin.com/ears/) - [Документация Kiro — спецификации функций и EARS (страница обновлена 4 августа 2026)](https://kiro.dev/docs/specs/feature-specs/) - [Документация Kiro — поток «сначала требования»](https://kiro.dev/docs/specs/feature-specs/requirements-first/) - [specscore/specscore — спецификация требования](https://github.com/specscore/specscore/blob/main/spec/features/requirement/README.md) - [specscore/specscore — спецификация критериев приёмки](https://github.com/specscore/specscore/blob/main/spec/features/acceptance-criteria/README.md) - [specscore/specscore — спецификация сценария](https://github.com/specscore/specscore/blob/main/spec/features/scenario/README.md) - [specscore/specscore — спецификация функции](https://github.com/specscore/specscore/blob/main/spec/features/feature/README.md) - [specscore/specscore — поток 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) ## Связанное - [Шаблон PRD в Markdown для программирования с ИИ](https://specscore.md/ru/articles/feature-spec-template/) - [Линтовать спецификации в CI линтером спецификаций](https://specscore.md/ru/articles/lint-specs-in-ci/) - [Как писать критерии приёмки, которые проверит ИИ-агент](https://specscore.md/ru/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/ru/vs/kiro/) - [Инструменты разработки по спецификациям](https://specscore.md/ru/spec-driven-development/tools/) - [Разработка по спецификациям](https://specscore.md/ru/spec-driven-development/) - [Спецификация требования](https://specscore.md/requirement-specification) - [Спецификация критериев приёмки](https://specscore.md/acceptance-criteria-specification) - [Спецификация функции](https://specscore.md/feature-specification) - [Валидаторы и CI](https://specscore.md/ru/validators/)