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 року.
Знайшли помилку в перекладі або маєте ідею як покращити цю сторінку?