EARS (Easy Approach to Requirements Syntax) — это нотация требований: небольшой набор английских шаблонов предложения, его же называют синтаксисом EARS. Шаблон держит условие, триггер и ответ системы в фиксированном порядке. Требование — одно проверяемое обязательство, которое система должна выполнить. Разработка по спецификациям (SDD, spec-driven development) — практика записать это обязательство в спецификацию до кода и считать спецификацию источником правды. Документ требований к продукту (PRD, product requirements document) — проза, которая называет проблему и рамки до того, как работу режут на задачи. В SpecScore требование (REQ) — именованное правило внутри функции, а критерий приёмки (AC, acceptance criterion) — необязательное абстрактное условие, которое указывает на одно или несколько таких правил. Непрерывная интеграция (CI, continuous integration) — автоматическая проверка каждого предлагаемого изменения. Проверка — команда интерфейса командной строки (CLI, command-line interface): specscore spec lint. Kiro, агентная интегрированная среда разработки (IDE, integrated development environment) от Amazon Web Services (AWS), пишет один из этих шаблонов. Нотацию впервые опубликовали Алистер Мэвин и коллеги из Rolls-Royce на конференции по инженерии требований Institute of Electrical and Electronics Engineers (IEEE) в 2009 году.
Обновлено: 2 ноября 2026
Алистер Мэвин, Филип Уилкинсон, Эдриан Харвуд и Марк Новак, тогда в Rolls-Royce PLC, опубликовали «Easy Approach to Requirements Syntax (EARS)» на 17th IEEE International Requirements Engineering Conference в 2009 году. Идентификатор документа — 10.1109/RE.2009.9. Правила сложились, когда они извлекали требования к управлению двигателем из Certification Specification for Engines (CS-E), раздел CS-E 50, нормы лётной годности. Исходный текст смешивал требования, проектные указания и заметки.
Статья называет восемь проблем неограниченного естественного языка: неоднозначность, расплывчатость, сложность, пропуск, дублирование, многословие, неуместную реализацию и непроверяемость. Небольшой набор правил должен был уложить каждое такое требование в один из пяти шаблонов. Авторы пишут, что нотация подходит для высокоуровневых требований заинтересованных сторон, и не утверждают, что она покрывает каждый уровень декомпозиции системы.
Собственное руководство Мэвина описывает EARS как способ мягко ограничить текстовые требования. Части остаются в одном порядке, который он называет темпоральной логикой: любое предусловие, затем триггер, затем имя системы и ответ. Его набор правил: ноль или много предусловий, ноль или один триггер, одно имя системы и один или много ответов. Статья 2009 года специализирует эту форму в пять шаблонов. То же руководство называет и сложные требования, которые сочетают ключевые слова.
В разборе случая из статьи сырой фрагмент содержал 36 требований, а переписанный набор — 47. Средняя длина упала с 36,9 до 25,6 слова. Авторы сообщают, что в этом разборе сложность, пропуск, дублирование, неуместная реализация и непроверяемость отсутствовали в переписанном наборе, а неоднозначность, расплывчатость и многословие уменьшились, но не исчезли. Они также перечисляют пределы: маленькая выборка, только высокоуровневые требования безопасности и суждение при классификации расплывчатости. Эти числа — из статьи, для одного документа.
Ключевые слова — из статьи 2009 года и из руководства Мэвина. Статья также допускает During вместо While для состояния, с тем же смыслом, когда так читается яснее. Примеры иллюстрируют шаблоны. Это не цитаты из статьи. Kiro пишет событийный шаблон заглавными буквами; исходная нотация начинает ключевое слово с заглавной. Примеры остаются на английском, потому что синтаксис EARS английский.
The <system name> shall <system response>
Всегда активно. Ключевого слова EARS нет, потому что нет ни предусловия, ни триггера. Собственный пример статьи 2009 года — система управления, которая должна не допускать превышения оборотов двигателя.
Пример The checkout system shall keep the order total equal to the sum of its line items.
When <trigger>, the <system name> shall <system response>
Ответ требуется, когда триггер обнаружен на границе системы, и только тогда. Ключевое слово — 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 <precondition>, the <system name> shall <system response>
Ответ требуется, пока система остаётся в названном состоянии. Ключевое слово — While.
Пример While the cart is empty, the checkout system shall keep the pay button disabled.
If <trigger>, then the <system name> shall <system response>
Ответ обрабатывает отказ, возмущение, отклонение или другое нежелательное поведение. Ключевые слова — If и then. Статья дала этому шаблону собственные слова, чтобы такие требования оставались видны. Авторы замечают, что желательное и нежелательное иногда зависит от точки зрения.
Пример If the submitted email is not a valid address, then the checkout system shall reject the form.
Where <feature is included>, the <system name> shall <system response>
Ответ действует, только если продукт включает названную функцию. Ключевое слово — Where.
Пример Where the shop includes gift wrapping, the checkout system shall offer gift wrapping on the order review step.
While <precondition>, when <trigger>, the <system name> shall <system response>
Больше одного ключевого слова. Руководство Мэвина сохраняет тот же порядок: 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 говорит то же своими словами: каждый REQ должен выражать ровно одно проверяемое обязательство.
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 публикует один шаблон, WHEN … THE SYSTEM SHALL …. Повсеместное, While, If / then, Where и сложные сочетания входят в нотацию статьи и руководства Мэвина. На этой странице Kiro их нет.
Страница спецификаций функций Kiro, помеченная как обновлённая 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.
Страница «сначала требования» говорит, что сгенерированный requirements.md включает пользовательские истории с критериями приёмки и поведение системы в той же форме WHEN … THE SYSTEM SHALL …. Пример регистрации — три предложения: верные данные регистрации создают учётную запись, уже существующая почта показывает «Email already registered», а неверный формат почты показывает ошибку проверки.
До проекта Analyze Requirements ищет логические несогласованности, неоднозначность, конфликтующие ограничения и пробелы. Страница говорит, что это выбирают в параметрах чата или в меню Continue редактора после генерации требований. design.md и tasks.md стоят рядом с требованиями. Quick Spec проводит требования, проект и задачи без остановки на утверждение между ними.
Этот разбор — шаг внутри Kiro. Страница не описывает его как линтер формата, который добавляют в собственный CI. Как другие инструменты проверяют спецификацию, написано в обзоре инструментов. Сравнение двух продуктов — SpecScore vs Kiro.
SpecScore не проверяет, что предложение совпадает с шаблоном EARS. specscore spec lint из репозитория specscore-cli проверяет структуру. Текст справки называет файлы README, разделы Open Questions, уровни заголовков, ссылки на функции, внутренние ссылки и строки индекса. Предложение EARS может быть прозой под заголовком REQ. Линтер не оценивает английский.
Спецификация требования помещает каждое требование под тематический заголовок внутри ## Behavior, на один уровень ниже, обычно #### REQ: slug. Slug — строчные буквы, цифры и дефисы. Идентификатор — {feature-path}#req:{slug}. Спецификация говорит, что требование следует писать ключевыми словами RFC 2119 (Request for Comments 2119): MUST, MUST NOT, SHOULD, SHOULD NOT и MAY. В соответствии ниже EARS-овое shall записано как MUST.
Критерий приёмки необязателен. Когда он есть, это ### AC: slug внутри ## Acceptance Criteria, а следующая строка — **Requirements:** с этими идентификаторами. Спецификация критериев приёмки говорит, что AC формулирует абстрактное условие и не должен содержать шаги Given/When/Then, конкретные входы или деталь реализации. Конкретный ход — сценарий в каталоге _tests/ функции. Спецификация функции также требует статус, краткое описание, проблему, поведение, критерии приёмки, открытые вопросы и нижний колонтитул соответствия.
Файлы ниже — функция оформления заказа. show-field-error — событийный пример. reject-invalid-email — пример нежелательного поведения. 2 ноября 2026 года specscore spec lint сообщил 0 нарушений для этого дерева на specscore 0.55.1, последнем выпуске, опубликованном 30 октября 2026 года, и на specscore 0.39.1, версии, закреплённой в dogfood.yml. Репозиторий формата — место этого потока.
---
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*
---
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*
# Checkout specification
## Open Questions
None at this time.
# 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.
Easy Approach to Requirements Syntax. Это набор шаблонов предложения для требований, опубликованный Алистером Мэвином, Филипом Уилкинсоном, Эдрианом Харвудом и Марком Новаком из Rolls-Royce на 17th IEEE International Requirements Engineering Conference в 2009 году и описанный на сайте Мэвина.
Страница спецификаций функций Kiro задаёт один шаблон: WHEN … THE SYSTEM SHALL …. Статья 2009 года и руководство Мэвина также определяют повсеместные требования, состояние While, If/then для нежелательного поведения, Where для необязательной функции и сложные сочетания этих ключевых слов.
Нет. specscore spec lint проверяет структуру файлов SpecScore. Предложение EARS может быть прозой REQ. Линтер не оценивает английский.
В сценарий в каталоге _tests/ функции. Критерий приёмки остаётся абстрактным условием и по спецификации критериев приёмки не должен содержать шаги Given/When/Then.
Прочитано 2 ноября 2026 года, кроме страниц, которые печатают собственную дату обновления. Страница спецификаций функций Kiro указывает обновление 4 августа 2026 года.
Нашли ошибку в переводе или знаете как улучшить эту страницу?