Модуль 1.6. Acceptance & критерии готовности
DoR/DoD, критерии приёмки (AC), примеры/контрпримеры. Артефакт: шаблон критериев приёмки. Практика: написать AC для 3 требований.
Системный аналитик (SA) превращает «описанные требования» в проверяемые обязательства. Для этого нужны:
- DoR/DoD — чёткие условия «входа» и «выхода» работы;
- Acceptance Criteria (AC) — измеримые правила, по которым команда и бизнес понимают, что мы «сделали правильно»;
- примеры/контрпримеры — чтобы исключить двусмысленность и «серые зоны».
На выходе модуля у вас будет шаблон AC, чек-листы DoR/DoD под ваш проект и готовность написать качественные AC к любому требованию.
Роли и ответственности (кратко)
- SA — автор и владелец AC для функциональных и нефункциональных требований; обеспечивает проверяемость, трассируемость (RTM), данные для приёмки.
- QA — переводит AC в тесты (E2E/интеграционные/контрактные/нагрузочные), уточняет краевые случаи.
- Dev — реализует поведение и инструментирует систему (логи, метрики, трейсы) для проверки AC/NFR.
- PO/бизнес — утверждает AC как критерии ценности.
- Архитектор/Безопасность/DevOps — верифицируют AC по NFR, совместимости, безопасности, релизным режимам.
Практика: оформляйте «3 Amigos» (PO/BA ↔ SA ↔ QA/Dev) для финализации AC перед входом в спринт.
Definition of Ready (DoR) — «готово в разработку»
Минимально для карточек, где задействован SA:
- SRS-ссылка и актуальная версия артефактов (BPMN/ER/Sequence/DMN).
- Контракты: OpenAPI/AsyncAPI (с ошибками/лимитами/идемпотентностью/безопасностью).
- AC/BDD: 3–7 сценариев (позитив/негатив/ошибки/повторы).
- NFR: измеримые SLO + способ измерения (SLI/алерты/дашборды).
- Тестовые данные/фикстуры, оговорены маски PII.
- Зависимости и допущения (если есть) зафиксированы; риск-план (FF/rollback).
Правило: Story без AC/NFR — не попадает в спринт.
Definition of Done (DoD) — «готово к релизу»
- Реализованы все AC (прошли BDD/E2E/контрактные).
- Документация обновлена: SRS/OpenAPI/ER/DMN (bump SemVer, changelog).
- Observability соответствует NFR: метрики/алерты/логи/трейсы включены и видны.
- Совместимость: пройдены контрактные тесты N и N−1, определён срок EOL.
- Релизные заметки/миграции/FF/rollback — описаны и проверены.
- RTM обновлён: требование → тесты/метрики/релиз-тег.
Что такое AC и как их писать
Acceptance Criteria (AC) — минимальный набор однозначных и проверяемых условий, при выполнении которых требование считается реализованным.
Свойства качественного AC
- SMART: Specific, Measurable, Achievable, Relevant, Time-bound.
- Однозначность: без «быстро», «удобно», «как раньше».
- Проверяемость: автоматизируемо (BDD/контракты/нагрузка/мониторинг).
- Полнота: позитив, негатив, ошибки/таймауты/повторы, идемпотентность.
- Независимость от реализации: описывает поведение и результаты, а не «как устроено внутри».
Формы записи
- Gherkin (BDD) — Given/When/Then.
- Чек-лист — таблица с входами/выходами/метриками.
- NFR-AC — «Метрика — Порог — Окно — Способ измерения».
Примеры AC (и контрпримеры)
5.1. Функциональные (финтех: возврат платежа)
Хорошо (BDD):
Scenario: Create refund (idempotent)
Given payment status is "CAPTURED" and amount ≤ capturedAmount
And header "Idempotency-Key" = "abc-123"
When client POST /refunds { paymentId, amount }
Then response code is 201
And body.refund.status = "PENDING"
And header "X-Correlation-Id" is present
Scenario: Idempotent retry
Given previous request with Idempotency-Key "abc-123" was successful
When client repeats POST /refunds with same Idempotency-Key
Then response code is 200
And body.refundId equals original
Плохо (контрпримеры):
- «Система быстро создаёт возврат» — нет числа.
- «Возврат не должен дублироваться» — не сказано как проверять (где ключ идемпотентности?).
Интеграции/ошибки/таймауты
Scenario: PSP timeout Given PSP does not respond within 10s When POST /refunds Then response code is 202 And refund.status = "PENDING" And retry is scheduled with exponential backoff (max 3 attempts)
Контрпример: «При ошибке попробуем ещё» — сколько раз? какой шаг?.
NFR как AC
NFR-PERF-001: p95 latency for POST /refunds < 2000 ms over 7 days. Measurement: Prometheus metric refunds_latency_ms_p95; Alert: >2000 ms 5 min → page on-call. NFR-REL-002: Error rate for /refunds < 0.5% per rolling 7 days. Measurement: refunds_error_rate; Alert: >0.5% for 5 min → SEV-2. NFR-SEC-003: No PAN/PII in logs; masked pattern "****" for sensitive fields. Test: automated log-scan; Audit: 0 violations per release.
Контрпример: «Должно быть безопасно и быстро» — вода.
Данные/качество данных (DQ)
AC-DQ-001: For any refund, sum(refund.amount) ≤ capturedAmount per payment (enforced by DB constraint and validated by nightly DQ job). AC-DQ-002: idempotency_key is unique per merchantId; duplicates rejected with 409.
Совместимость/контракты
AC-API-Compat-001: Clients on API v2.3 continue to work unchanged during and after deployment of v2.4. Test: contract tests against v2.3 (N-1) passing; deprecation notice included in release notes.
События/асинхрон
AC-EVT-001: On refund capture, event "RefundCompleted" is published once (at-least-once semantics), schema "refund-completed.avsc" v1.1, within 60s. AC-EVT-002: Consumers can deduplicate using eventId and correlationId; schema contains both fields.
E-commerce (смена адреса)
Scenario: Change address before shipment
Given order.status in { "Created", "Paid", "Packed" }
When PATCH /orders/{id}/delivery-address
Then response code is 200 and address.version increments by 1
Scenario: Change address after shipment
Given order.status = "Shipped"
When PATCH /orders/{id}/delivery-address
Then response code is 409 and body.error = "ADDRESS_CHANGE_FORBIDDEN"
DWH/ETL (данные)
AC-ETL-001: Nightly load completes < 30 min; freshness lag ≤ 15 min at 08:00. AC-ETL-002: Column "gross_revenue" equals SUM(price*qty) - SUM(discounts) per day; zero NULLs in key columns (order_id, date).
Шаблон «Критерии приёмки» (артефакт)
Скопируйте и используйте как базовый:
# Acceptance Criteria — <REQ-ID> <Название> Owner: <ФИО SA> | Version: <SemVer> | Status: Draft/Review/Approved Linked: SRS §<…>, Jira <…>, OpenAPI <…>, ER <…>, RTM <…> ## 1. Функциональные сценарии (BDD) Scenario: <кратко> Given <предусловия/данные/роль> When <действие/запрос> Then <результат/статус/изменение состояния/событие> Scenario: <альтернатива/ошибка/повтор> … Notes: <особые случаи, локализация, валюты, TZ> ## 2. Интеграции/контракты — OpenAPI/AsyncAPI версия: <…> — Ошибки: <коды/типы/семантика> — Пагинация/идемпотентность/correlation-id: <…> — Совместимость: поддержка N/N-1 до <дата EOL> ## 3. Нефункциональные критерии (NFR) — Performance: <метрика/порог/окно/SLI/алерт> — Reliability/Availability: <SLO/RTO/RPO/деградации> — Security/Compliance: <маскирование, роли, аудит> — Observability: <логи/метрики/трейсы/дашборды/алерты> ## 4. Данные и DQ — ER/домены/ограничения: <…> — Валидаторы/уникальность/полнота: <…> — Миграции/обратимость: <…> ## 5. Тестовые данные — Наборы/фикстуры: <…> — Маскирование PII: <…> ## 6. Готовность к релизу — Release notes/депрекейт/FF/rollback: <…> ## 7. Подписи (утверждение) PO/Бизнес: <имя/дата> | QA: <…> | Dev Lead: <…> | SA: <…>
Как внедрить AC в процесс (рабочая дисциплина)
- В Jira добавьте поле AC link (ссылка на файл .feature/страницу).
- В PR-шаблон внесите чек «AC/BDD обновлены и прошли».
- В CI включите прогон Newman/BDD/контрактных тестов по AC.
- На Sprint Review демонстрируйте фичу по AC (а не «просто покажем»).
- Перед релизом убедитесь, что алерты заведены, а SLA/SLI видны в Grafana/Kibana.
Типовые риски и анти-паттерны
- AC описывают UI вместо поведения → привяжитесь к API/событиям/данным (UI — слой, меняется чаще).
- Нет негативных сценариев → обязательно добавляйте ошибки/таймауты/повторы.
- NFR без SLI/алертов → нельзя принять; добавьте метрики/порог/окно/алерт.
- Разрыв AC ↔ SRS/OpenAPI → docs-as-code и PR-проверка ссылок/версий.
- Слишком много AC (20+) → объединяйте, оставляйте сценарии с наибольшим риском; остальное — в тест-план QA.
- AC зависимы от окружения → фиксируйте требования к стенду (данные/сети/ключи), используйте FF и мок-сервисы.
Вопрос–Ответ
Q: Сколько AC должно быть на одно требование?
A: Обычно 3–7 ключевых (позитив/негатив/ошибка/повтор). Если больше — вероятность «вода/дубли».
Q: Кто финально утверждает AC?
A: PO/бизнес (ценность), QA (тестируемость), Dev Lead (реализуемость), SA (корректность и полнота).
Q: AC можно менять в спринте?
A: Только через Change Request и синхронное обновление SRS/RTM/тестов. Иначе — риск дефектов требований.
Q: Как принимать NFR?
A: По фактическим SLI на стенде/канареике с заданным окном измерения; наличие алертов — обязательное условие.
Q: Где хранить AC?
A: В Git (канон) — .feature/Markdown; в Confluence — витрина/ссылки; в Jira — поле AC link.
Практика: напишите AC для 3 требований (60–90 мин)
Вариант темы:
- FR-PAY-001 — создать платёж (идемпотентно).
- FR-ADR-003 — смена адреса до отгрузки.
- NFR-PERF-010 — p95 для POST /payments < 3000 мс за неделю.
Задание:
- Для каждого требования напишите минимум 3 BDD-сценария (позитив/негатив/ошибка/повтор).
- Добавьте 2–3 NFR-AC (перформанс/безопасность/наблюдаемость) там, где применимо.
- Укажите тестовые данные и требования к стенду.
- Сохраните файл ac/<feature>.feature и таблицу «NFR-AC» в /docs/nfr.
Эталон для самопроверки (кратко):
FR-PAY-001 — Create payment (idempotent)
- BDD: успех (201), повтор с тем же Idempotency-Key (200 + тот же paymentId), таймаут PSP (202 + ретрай ≤3).
- NFR-AC: p95 POST /payments < 3000 мс; error-rate < 0.5%; в логах нет PII; X-Correlation-Id обязателен.
FR-ADR-003 — Change address
- BDD: до Shipped (200 + version++), после Shipped (409), неправильный формат адреса (422).
- NFR-AC: ответ < 500 мс; аудит-лог адресных изменений; маскирование PII.
NFR-PERF-010 — p95 payments
- NFR-AC: p95 < 3000 мс (7 дней), алерт >3000 мс 5 мин — SEV-2; throughput ≥ 50 RPS в пик 1 час.
Шпаргалка (распечатайте)
- DoR: нет AC/NFR/контрактов — нет разработки.
- DoD: пройдены тесты по AC, обновлены спеки, включены метрики/алерты.
- AC: BDD + NFR-AC + данные + совместимость.
- Плохие AC: без чисел, без негативных сценариев, с привязкой к внутренней реализации.
- Главное: по AC принимаем фичу на ревью и релизе — никаких «на глаз».
