Критерии приёмки (Acceptance Criteria)

Критерии приёмки (Acceptance Criteria, AC) — набор чётких, измеримых и проверяемых условий, которым должно удовлетворять решение или его часть, чтобы быть принятым заинтересованными сторонами. AC переводят требование в наблюдаемое поведение и результат, по которому можно однозначно ответить «принято / не принято». На проекте это основной инструмент валидации — проверки, что сделано то, что нужно (см. 02.04.01 Верификация и валидация (V&V)). Верификация же отвечает на вопрос, правильно ли описаны сами критерии: полны ли они, непротиворечивы ли, пригодны ли для трассировки (см. 08.03 Тестирование требований (статическое тестирование), 02.04.03 Управление качеством требований).

AC не описывают, как система реализована внутри — это зона проектирования и архитектуры. Они фиксируют наблюдаемое поведение с точки зрения пользователя, заказчика или смежной системы.

1. Суть темы

Критерии приёмки находятся на стыке 02.03.03 Спецификация требований (SRS, Use Case, User Story) и 02.04.01 Верификация и валидация (V&V). Они связывают требование с приёмочным тестированием и демонстрацией:

1. Формулируются вместе с требованием — историей, сценарием использования или пунктом SRS.
2. Фиксируются в инструменте управления требованиями или в карточке элемента бэклога.
3. Используются командой как чеклист при проектировании и реализации.
4. Валидируются на демонстрациях и при приёмо-сдаточных испытаниях.
5. Могут автоматизироваться в виде приёмочных тестов: ATDD (Acceptance Test-Driven Development) использует AC как основу тестов до разработки; Gherkin — распространённый формат в BDD (Behaviour-Driven Development), но не единственный.

AC — не только User Story

В Agile AC чаще всего привязаны к 04.02 Пользовательские истории (User Stories) и Job Stories, но в ветке BA Body of Knowledge они применимы к любому носителю требования:

Выбор носителя — в 04.03 Use Case vs User Story — выбор подхода и 05.01 Waterfall и V-model; в контрактных и регулируемых проектах AC часто фиксируются в 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD) и подписываются на этапе приёмки.

Acceptance Criteria vs Evaluation Criteria

В BABOK v3 техника «Acceptance and Evaluation Criteria» объединяет два разных уровня (см. 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)):

• Evaluation criteria — критерии оценки альтернатив на стратегическом уровне: какой вариант решения выбрать, какой KPI достаточен. Это ближе к 02.01.02 Цели, KPI и критерии успеха (SMART, GQM).
• Acceptance criteria — условия приёмки конкретного инкремента или требования: что должно быть выполнено, чтобы элемент считался готовым для стейкхолдера.

В этой статье речь только о втором типе.

2. Ключевые понятия

AC, Definition of Ready и Definition of Done

Три понятия часто смешивают; их разведение критично на практике (подробнее о DoD — в 05.02 Scrum и Kanban (аналитик в Agile)):

AC и DoD взаимодополняют друг друга: AC — что нужно пользователю; DoD — как команда гарантирует качество поставки. DoR проверяет, что AC достаточно полны до начала разработки.

НФТ в AC и в DoD

Нефункциональные требования могут попадать и в AC, и в DoD — различие в уровне и видимости (классификация НФТ — в 08.02 Нефункциональные требования (НФТ) — классификация и стандарты):

• В AC — когда поведение видимо заказчику на приёмке: «95% запросов к API /search выполняются менее чем за 200 мс при нагрузке до 100 RPS» — это критерий приёмки конкретной фичи поиска.
• В DoD — когда это инженерный стандарт команды для любой задачи: «код покрыт unit-тестами на 80%», «нет критических уязвимостей по SAST».

Если производительность — явное бизнес-обязательство конкретного релиза, фиксируйте её в AC; если это общий порог качества — в DoD или в 10.01.12 Шаблон нефункциональных требований (NFR).

AC, Acceptance Tests и Test Cases

flowchart LR
  REQ[Требование] --> AC[AC]
  AC --> AT[Acceptance Test]
  AC --> TC[Test Case]
  AT --> VAL[Приёмка / Demo]
  TC --> VAL
  AC -.-> RTM[RTM]

На этапе анализа достаточно AC; детальные test cases — зона QA, если процесс это предписывает. Прослеживаемость «требование → AC → тест» — в 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки.

Форматы записи

Пример bullet-list (история «Регистрация по email»):

• Пользователь может ввести email и пароль и нажать «Зарегистрироваться».
• Если email не соответствует формату, поле подсвечивается ошибкой.
• Если пароль короче 8 символов, отображается сообщение об ошибке.
• При корректном вводе пользователь перенаправляется на страницу приветствия и получает подтверждение на email.

Иллюстрация формата Gherkin для той же истории (полные сценарии и шаблоны — в 04.02 Пользовательские истории (User Stories) и Job Stories и 10.01.01 Шаблон User Story):

Scenario: Успешная регистрация с корректными данными
  Given пользователь находится на странице регистрации
  When он вводит "user@example.com" в поле email
  And вводит "SecurePass1" в поле пароль
  And нажимает кнопку «Зарегистрироваться»
  Then он видит сообщение «Подтвердите ваш email»
  And на указанный email отправлено письмо со ссылкой активации
 
Scenario Outline: Регистрация с некорректным email
  Given пользователь находится на странице регистрации
  When он вводит "<email>" в поле email
  And нажимает кнопку «Зарегистрироваться»
  Then поле email подсвечено красным
  And отображается сообщение «Введите корректный email»
 
  Examples:
    | email        |
    | user         |
    | user@        |
    | @example.com |

Use Case / SRS: постусловия успешного сценария и ключевые альтернативные потоки выполняют ту же роль, что AC у истории. Не дублируйте их отдельным списком, если уже зафиксированы в структуре use case.

3. Как применяется в работе аналитика

Владелец, процесс и «заморозка»

Правило «AC не меняются после старта спринта» — ориентир Scrum, а не абсолют: изменение допустимо при согласовании с PO/заказчиком и фиксации impact на объём и сроки. Односторонняя правка разработчиком недопустима. Согласованные AC до старта разработки — пункт 10.04 Чеклист аналитика перед стартом разработки.

Правила качества формулировок

Атрибуты качества AC совпадают с требованиями к формулировкам в ISO/IEC/IEEE 29148 и BABOK: верифицируемость, однозначность, полнота, атомарность, трассируемость (подробнее — в 02.04.03 Управление качеством требований и 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)). На практике это сводится к нескольким проверкам:

• Тестируемость — однозначный ответ «да/нет»; измеримые пороги вместо «работает быстро».
• Ориентация на ценность — наблюдаемое поведение для пользователя или контрагента, а не задача реализации («добавить индекс в таблицу users» — не AC).
• Полнота минимального набора — happy path + ключевые негативы + граничные условия.
• Технологическая нейтральность — для бизнес-историй не привязывайте AC к ID элементов UI, если это не требование.

Сигнал к декомпозиции: если на одну историю набралось более 7–10 AC или они покрывают несколько независимых пользовательских целей — разделите историю (см. 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)). Количество не фетишируйте; важно совместное понимание.

Локализация, доступность, юридические тексты

Связь с приёмочным тестированием

AC — прямой вход для ручных и автоматизированных acceptance tests. ATDD — отдельная практика: тесты пишут по AC до разработки. BDD — про совместное формулирование на общем языке; Gherkin — распространённый, но не обязательный формат. Сценарии Gherkin могут исполняться Cucumber, SpecFlow, Behave и попадать в CI как living documentation (см. 07.06 CICD и конвейеры — влияние на требования). Для низкоуровневых API-тестов и чисто технических проверок достаточно bullet-list или формального test case.

Черновики Gherkin можно ускорять с помощью ИИ (промпты для сценариев — в 11.03 Промпт-инжиниринг для аналитика), но финальную проверку выполняет команда: граничные случаи, комплаенс, формулировки с юридическим смыслом — зона обязательного human review (см. 11.07 Практические кейсы применения LLM в анализе). Единый org-wide DSL и масштабирование BDD на уровне программы — в 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках.

Сквозной пример

История: «Как покупатель, я хочу применять промокод при оформлении заказа, чтобы получить скидку».

AC (bullet-list):

• В корзине отображается поле для ввода промокода.
• При вводе действительного кода «SALE10» сумма заказа уменьшается на 10%, если сумма заказа не ниже минимального порога акции (500 руб.).
• При вводе недействительного кода отображается «Промокод не найден».
• Применённый промокод отображается в детализации заказа отдельной строкой.
• Если срок действия кода истёк — «Срок действия промокода истёк».
• Повторное применение одного кода к заказу невозможно.
• Промокод нельзя комбинировать с другой активной скидкой на тот же заказ.
• При пересчёте корзины (изменение количества, удаление товара) ранее применённый промокод пересчитывается или сбрасывается согласно правилам акции.

Gherkin-сценарии для этой истории — в 10.01.01 Шаблон User Story и 04.02 Пользовательские истории (User Stories) и Job Stories.

4. Типовые ошибки и ограничения

• Смешение validation и verification — называть AC «инструментом верификации». AC — для приёмки стейкхолдером; проверка качества формулировок AC — верификация.
• Слишком обобщённые критерии — «система работает корректно» не проверяемо.
• Избыточная детализация UI — цвет кнопки и радиус скругления — в дизайн-системе; в AC — только если это функциональное требование (например, контрастность для a11y).
• Подмена AC задачами разработки — «Реализовать EmailService.SendAsync» — техническая задача.
• Пренебрежение негативными сценариями — только happy path.
• Несогласованность истории и AC — в истории массовая операция, в AC — единичный объект.
• Фетишизация количества — «минимум N критериев на историю» вместо содержательной проработки.
• Слишком много AC без декомпозиции — признак перегруженной истории; разбивайте, а не раздувайте чеклист.
• Жёсткая «заморозка» без процесса изменений — блокирует легитимные уточнения; нужен согласованный change control, а не запрет.
• Gherkin везде — навязывание BDD там, где достаточно bullet-list или формального test case, создаёт лишние накладные расходы.
• Инфраструктурный AC в форме бизнес-истории — enabler и API-контракт описывают по-разному (см. 02.03.01 Классификация требований (БТ, ФТ, НФТ)).
• Перенос Scrum-модели баг-трекера буквально — не в каждой команде у дефекта есть AC; иногда достаточно expected/actual и шагов воспроизведения.

Связи с другими разделами базы

• 02.04.01 Верификация и валидация (V&V) — место AC в процессах проверки; validation vs verification.
• 02.03.03 Спецификация требований (SRS, Use Case, User Story) — носители, для которых определяются AC.
• 04.02 Пользовательские истории (User Stories) и Job Stories — AC в user story и job story; форматы Gherkin.
• 02.04.03 Управление качеством требований — атрибуты качества формулировок AC (верифицируемость, полнота).
• 02.05.05 Жизненный цикл требования — версионирование и устаревание AC вместе с требованием.
• 08.04 Рецензирование и инспекции (техники Фейгина) — формальное ревью AC до baseline в regulated-проектах.
• 10.01.01 Шаблон User Story — оформление историй с AC и Gherkin-сценариями.

Источники и дополнительные материалы

Книги и стандарты

• BABOK Guide v3, IIBA — техника «Acceptance and Evaluation Criteria» (разделение evaluation vs acceptance). См. также 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148).
• ISO/IEC/IEEE 29148:2018 — требования к содержанию спецификаций; верифицируемость формулировок. Тестовая документация — ISO/IEC/IEEE 29119 (создание test cases из AC).
• Mike Cohn, «User Stories Applied: For Agile Software Development» — классика по историям и AC. ISBN: 978-0321205681.
• Gojko Adzic, «Fifty Quick Ideas to Improve Your User Stories» — практические советы по качеству AC.
• Gojko Adzic, «Specification by Example» — исполняемые спецификации и living documentation.
• Gáspár Nagy, «The BDD Books — Discovery» — формулирование AC в BDD с Gherkin.
• Lisa Crispin, Janet Gregory, «Agile Testing: A Practical Guide for Testers and Agile Teams» — ATDD и роли при формировании AC.
• Roman Pichler, «Agile Product Management with Scrum» — refinement бэклога и критерии приёмки.
• NASA Software Engineering Handbook, SWE-034 — Acceptance Criteria — формальные AC для mission-critical систем (не типовой e-commerce). https://swehb.nasa.gov/

Статьи и спецификации

• Scrum Guide (Schwaber, Sutherland, 2020) — Definition of Done; роль PO в приёмке. https://scrumguides.org/scrum-guide.html
• Scrum.org: Definition of Done vs. Acceptance Criteria Explained — разграничение DoD и AC. https://www.scrum.org/resources/definition-of-done-vs-acceptance-criteria
• Cucumber Documentation — BDD — контекст BDD vs просто Gherkin. https://cucumber.io/docs/bdd/
• Gherkin Reference — синтаксис Given-When-Then. https://cucumber.io/docs/gherkin/reference/
• Cucumber School — уроки по написанию Gherkin-сценариев. https://cucumber.io/docs/cucumber/