Простой подход к синтаксису требований ⇐ Васина Википедия

[wiki_en]

«Простой подход к синтаксису требований» («EARS») — это структурированный метод написания инженерных требований на естественном языке с использованием небольшого набора ключевых слов и шаблонов предложений. Разработанный Алистером Мавином и его коллегами из Rolls-Royce Holdings|Rolls-Royce plc при анализе правил летной годности системы управления реактивными двигателями, EARS был впервые опубликован на Международной конференции по разработке требований IEEE (RE'09) в 2009 году.
EARS был принят такими организациями, как Airbus, Robert Bosch GmbH|Bosch, Dyson (компания)|Dyson, Honeywell, Intel, NASA, Rolls-Royce и Siemens, и преподается в университетах Китая, Франции, Германии, Швеции, Великобритании и США. С 2025 года нотация EARS была интегрирована в инструменты разработки на базе искусственного интеллекта, в первую очередь в Amazon Kiro. интегрированная среда разработки|IDE.
== Фон ==

Системные требования обычно пишутся на естественном языке, который по своей сути является неточным. Авторы требований часто являются экспертами в предметной области, а не обученными инженерами по требованиям, а плохо сформулированные требования приводят к распространению ошибок на последующие этапы проектирования, реализации и тестирования, что увеличивает затраты и риски планирования. Хотя языки формальных спецификаций могут повысить точность, они требуют значительных затрат на обучение и перевода исходных требований, что само по себе может привести к ошибкам.
EARS был разработан, чтобы занять золотую середину: он сохраняет естественный язык, чтобы все заинтересованные стороны могли читать и просматривать требования без специальной подготовки, в то же время обеспечивая достаточную синтаксическую структуру для устранения наиболее распространенных дефектов. Этот подход возник во время анализа Мавином правил летной годности, содержащихся в основе сертификации системы управления авиационными двигателями Rolls-Royce, где он заметил, что все хорошо написанные требования имеют схожую базовую структуру.

== Синтаксис ==

Общая структура требования EARS такова:

'''WHILE''' , '''WHEN''' , '''SHALL'''

В наборе правил EARS указано, что требование должно содержать:

* Ноль или множество предварительных условий
* Ноль или один триггер
* Ровно одно имя системы
* Один или несколько ответов системы

Предложения всегда появляются в одном и том же временном порядке, а небольшое количество ключевых слов обозначают разные типы предложений. Это создает требования, которые попадают в один из пяти основных «шаблонов», а также их комбинации.

=== Вездесущий ===

Повсеместные требования всегда активны. У них нет ключевого слова EARS, поскольку нет условия срабатывания.

THE '''SHALL'''

''Пример:'' «Мобильный телефон ДОЛЖЕН иметь массу менее 150 грамм».

=== Управляемый событиями ===

Требования, управляемые событиями, определяют, как система должна реагировать при возникновении инициирующего события. Они обозначаются ключевым словом «КОГДА».

'''WHEN''' , '''ДОЛЖЕН'''

''Пример:'' «КОГДА выбрано «отключение звука», ноутбук ДОЛЖЕН подавлять весь аудиовыход».

=== Управляемый государством ===

Требования, определяемые состоянием, активны до тех пор, пока указанное состояние остается истинным. Они обозначаются ключевым словом '''WHILE'''.

'''WHILE''' , '''SHALL'''

''Пример:'' "ПОКА в банкомате нет карты, банкомат ДОЛЖЕН отображать сообщение "вставьте карту, чтобы начать".

=== Дополнительная функция ===

Требования к дополнительным функциям применяются только к продуктам или вариантам системы, которые включают указанную функцию. Они обозначаются ключевым словом «ГДЕ».

'''WHERE''' , '''SHALL'''

''Пример:'' «ГДЕ автомобиль имеет люк на крыше, в автомобиле ДОЛЖНА быть панель управления люком на двери водителя».

=== Нежелательное поведение ===

Требования к нежелательному поведению определяют требуемую реакцию системы на нежелательные ситуации, такие как сбои, сбои или ошибки. Они обозначаются ключевыми словами «IF» и «THEN».

'''IF''' , '''THEN''' '''ДОЛЖЕН'''

''Пример:'' "ЕСЛИ введен неверный номер кредитной карты, ТОГДА на веб-сайте ДОЛЖНО появиться сообщение "пожалуйста, введите еще раз данные кредитной карты".

=== Сложные требования ===

Простые строительные блоки, описанные выше, можно комбинировать, чтобы задать более богатое поведение системы. В сложных требованиях используется более одного ключевого слова EARS:

'''WHILE''' , '''WHEN''' , '''SHALL'''

''Пример:'' «ПОКА самолет находится на земле, КОГДА подается команда на реверс тяги, система управления двигателем ДОЛЖНА включить реверс тяги».

== Преимущества и ограничения ==

=== Преимущества ===

EARS обеспечивает несколько документально подтвержденных преимуществ по сравнению с неограниченными требованиями к естественному языку:

* '''Уменьшенная двусмысленность'''. Фиксированный порядок предложений и словарь ключевых слов вынуждают авторов явно указывать условия запуска, предварительные условия и ожидаемые ответы.
* '''Низкий барьер внедрения'''. Ключевые слова точно соответствуют повседневному использованию английского языка, поэтому затраты на обучение минимальны, а специальные инструменты отсутствуют.
* '''Языковая доступность''' – EARS особенно эффективен для авторов, которые пишут требования на английском языке, но чей родной язык не является английским.
* '''Улучшенная тестируемость''' — структурированное разделение условий и реакций упрощает разработку тестовых примеров.
* '''Совместимость с существующими инструментами''' — требования могут быть написаны в любом текстовом редакторе, текстовом процессоре или инструменте управления требованиями.

=== Ограничения ===

EARS не подходит для всех типов требований. Требования с более чем тремя предварительными условиями могут создавать громоздкие отдельные предложения, а некоторые требования лучше выражать в виде математических формул, таблиц решений или диаграмм состояний|диаграмм переходов состояний.
== История публикаций ==

== Использование в разработке на основе спецификаций ==

=== Обзор ===

Разработка на основе спецификаций (SDD) — это методология программного обеспечения, в которой формальная или полуформальная спецификация — а не специальные подсказки или неформальные описания — управляет генерацией кода, тестированием и документированием. В рабочих процессах SDD требования сначала фиксируются в структурированном формате, затем используются для создания технического проекта и, наконец, разбиваются на задачи реализации. Нотация EARS стала предпочтительным синтаксисом на этапе разработки требований SDD, поскольку ее ограниченный естественный язык может анализироваться как людьми, так и большими языковыми моделями (LLM), что устраняет разрыв между замыслом продукта и машиночитаемыми спецификациями.
=== Амазон Киро ===

Kiro, агентская интегрированная среда разработки искусственного интеллекта, анонсированная Amazon (компанией)|Amazon в 2025 году и построенная на Visual Studio Code#версия с открытым исходным кодом|Code OSS, приняла EARS в качестве собственной нотации требований. Рабочий процесс Kiro, основанный на спецификациях, состоит из трех этапов:

# '''Требования''' (requirements.md): разработчик вводит подсказку на естественном языке (например, «Добавьте систему отзывов для продуктов»). Киро расширяет это до пользовательских историй|пользовательских историй, каждая из которых имеет критерии приемлемости, записанные в нотации EARS. Структурированный формат явно фиксирует предварительные условия, триггеры и ожидаемые реакции системы, охватывая крайние случаи, которые в противном случае разработчики обнаружили бы во время реализации. # '''Дизайн''' (design.md): на основе требований EARS и существующей кодовой базы Киро создает документ технического дизайна, включающий архитектуру, диаграммы последовательности и решения по стеку технологий.
# '''Задачи''' (tasks.md): проект разбивается на отдельные, последовательные задачи реализации с отслеживанием зависимостей.

Поскольку каждый критерий приемки соответствует шаблону EARS КОГДА СИСТЕМА ДОЛЖНА , требования поддаются непосредственному тестированию и обеспечивают однозначные критерии успеха для каждой сгенерированной задачи. Разработчики также могут вручную создавать требования в формате EARS и использовать функцию Kiro «Уточнить» для их проверки или реструктуризации.
=== Более широкое внедрение ИИ ===

Интеграция EARS в Kiro отражает более широкую тенденцию использования шаблонов структурированных требований для повышения предсказуемости и качества кода, генерируемого LLM. По сравнению с подсказками в свободной форме (иногда называемыми «вибрирующим кодированием»), спецификации в формате EARS уменьшают двусмысленность, из-за которой ИИ-агенты делают нежелательные предположения. Проекты сообщества расширили этот подход и на других помощников по ИИ-кодированию с помощью подключаемых модулей и серверов протокола контекста модели (MCP), которые предоставляют основанные на EARS рабочие процессы, основанные на спецификациях.
== Сравнение со схожими подходами ==

EARS и пользовательские истории на практике часто используются вместе: пользовательские истории отражают потребности заинтересованных сторон высокого уровня, а EARS используется для определения подробных критериев приемки в каждой истории — подход, формализованный рабочим процессом Киро, основанным на спецификациях.

== См. также ==

* Разработка требований
* Разработка на основе спецификаций
* Контролируемый естественный язык
* Анализ требований
* Развитие, основанное на поведении
* Системная инженерия
* Кодирование Vibe

* [https://aliairmavin.com/ears/ EARS – Официальная страница Алистера Мавина]
* [https://ieeexplore.ieee.org/document/5328509/ Оригинальная статья EARS по IEEE Xplore]
* [https://kiro.dev/docs/specs/concepts/ Документация Kiro – концепции спецификаций]
* [https://qracorp.com/guides_checklists/t ... ntax-ears/ QRA – Простой подход к синтаксису требований: полное руководство]
* [https://www.jamasoftware.com/requiremen ... gineering/ Jama Software – принятие нотации EARS для разработки требований]

Разработка требований
Разработка программного обеспечения
Системная инженерия
Языки спецификации

Подробнее: https://en.wikipedia.org/wiki/Easy_Appr ... nts_Syntax