# Синтаксис вимог EARS з поясненням і прикладами Canonical: https://specscore.md/uk/articles/ears-requirements/ Оновлено: 2 листопада 2026 [EARS](https://alistairmavin.com/ears/) (Easy Approach to Requirements Syntax) — це нотація вимог: невеликий набір англійських шаблонів речення, його ж називають синтаксисом EARS. Шаблон тримає умову, тригер і відповідь системи у фіксованому порядку. Вимога — одне перевірюване зобов’язання, яке система мусить виконати. [Розробка за специфікаціями](https://specscore.md/uk/spec-driven-development/) (SDD, spec-driven development) — практика записати це зобов’язання в специфікацію до коду і вважати специфікацію джерелом правди. Документ вимог до продукту (PRD, product requirements document) — проза, яка називає проблему і межі до того, як роботу ріжуть на завдання. У [SpecScore](https://specscore.md/) вимога (REQ) — іменоване правило всередині функції, а критерій приймання (AC, acceptance criterion) — необов’язкова абстрактна умова, яка вказує на одне або кілька таких правил. [Безперервна інтеграція](https://specscore.md/uk/validators/) (CI, continuous integration) — автоматична перевірка кожної запропонованої зміни. Перевірка — команда [інтерфейсу командного рядка](https://specscore.md/uk/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/uk/spec-driven-development/tools/). Порівняння двох продуктів — [SpecScore vs Kiro](https://specscore.md/uk/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/uk/articles/feature-spec-template/) - [Лінтувати специфікації в CI лінтером специфікацій](https://specscore.md/uk/articles/lint-specs-in-ci/) - [Як писати критерії приймання, які перевірить ШІ-агент](https://specscore.md/uk/articles/acceptance-criteria/) - [SpecScore vs Kiro](https://specscore.md/uk/vs/kiro/) - [Інструменти розробки за специфікаціями](https://specscore.md/uk/spec-driven-development/tools/) - [Розробка за специфікаціями](https://specscore.md/uk/spec-driven-development/) - [Специфікація вимоги](https://specscore.md/requirement-specification) - [Специфікація критеріїв приймання](https://specscore.md/acceptance-criteria-specification) - [Специфікація функції](https://specscore.md/feature-specification) - [Валідатори і CI](https://specscore.md/uk/validators/)