Чтобы писать истории пользователей и критерии приёмки с ИИ, начните с проверенных свидетельств, укажите действующее лицо и его цель, разделите работу на обозримые результаты и задайте условия, которые уполномоченный человек сможет наблюдать и оценить. ИИ должен выявлять пропущенные предположения и крайние случаи, а не выдумывать потребности, выбирать реализацию или утверждать требование.

Ключевые выводы

Связывайте каждую историю с подтверждённой потребностью, проблемой, политикой или операционным ограничением.

Описывайте цель пользователя, а не запрошенную функцию или интерфейс.

Рассматривайте нормальные, граничные, ошибочные, разрешительные, доступные, конфиденциальные и безопасные исходы.

Не смешивайте критерии приёмки, задачи реализации, тестовые случаи и Definition of Done.

Общий процесс работы с ИИ задаёт контроль источников, проверки и утверждения. Более широкую последовательность и ответственность рассматривает планирование проекта с ИИ; история пользователя — не миниатюрный проектный план.

Какие доказательства нужны до истории пользователя?

Соберите материалы, объясняющие пользователя, проблему, желаемый результат, ограничения и открытые вопросы. Это могут быть утверждённые исследования, закономерности обращений в поддержку, аналитика, политика, результаты проверки доступности, отчёты об инцидентах или явно закреплённое бизнес-правило.

Создайте пакет доказательств:

ID	Источник	Наблюдаемая потребность или ограничение	Аудитория/контекст	Уверенность	Владелец
E-014	модерируемое исследование	пользователи не понимают, прошла ли отправка	новые заявители	средняя	руководитель исследования

Отделяйте свидетельство от решения. «Пользователю нужно подтверждение получения заявки» описывает результат. «Показывать зелёное уведомление пять секунд» — лишь вариант реализации и не должен автоматически становиться потребностью.

Не передавайте сервису ИИ конфиденциальные записи, персональные данные, подробности безопасности или неограниченные внутренние документы. Используйте минимальные одобренные выдержки и стабильные ID.

Как написать историю, ориентированную на цель?

GOV.UK указывает, что история должна называть действующее лицо, его потребность и цель. Часто применяется формат «Как… мне нужно/я хочу… чтобы…», причём цель считается самой важной частью.［1］

Сначала заполните канву:

Поле	Вопрос
действующее лицо	кто действительно испытывает потребность, без выдуманной персоны?
контекст	когда и где она возникает?
потребность	какого результата должен достичь пользователь?
цель	почему этот результат важен?
доказательства	какие ID поддерживают историю?
ограничения	какие действуют правила доступности, конфиденциальности, безопасности и эксплуатации?
предположения	что ещё не проверено?
утверждающий	кто отвечает за продуктовое решение?

Пример запроса:

Подготовь три варианта истории из этого пакета доказательств. В каждом назови действующее лицо, потребность и цель; укажи подтверждающие ID; избегай выбора интерфейса и реализации; перечисли неподтверждённые предположения и объясни, когда историю следует разделить или отклонить. Не выдумывай исследование и не выдавай предпочтение заинтересованного лица за пользовательское доказательство.

Проверьте, реально ли действующее лицо, описывает ли цель результат и можно ли обсуждать историю без заранее выбранного решения.

Как разделить epic или слишком большую историю?

GOV.UK называет epics крупные истории длительностью более нескольких недель и рекомендует по возможности делить их на элементы, завершаемые за итерацию.［1］ Не ограничивайтесь техническими слоями — база данных, API и интерфейс сами по себе могут не давать самостоятельной пользовательской ценности.

Полезные измерения для разделения: разные цели или этапы пути; успешный сценарий и восстанавливаемая ошибка; чтение, создание и изменение; роли и разрешения; простой случай до сложного; каналы и юрисдикции политики; ручная проверка до безопасной автоматизации.

Сохраняйте сквозные ограничения в каждой затронутой истории. После разделения требования конфиденциальности, доступности и авторизации не должны исчезнуть.

Что делает критерий приёмки наблюдаемым?

Критерии описывают условия и результаты, необходимые для приёмки работы уполномоченным пользователем, заказчиком или другой стороной. Руководство NASA подчёркивает необходимость определять и документировать критерии и условия, включая при необходимости диапазоны, производительность, надёжность, совместимость и данные.［2］

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

Начните с обычной таблицы:

ID критерия	Ситуация	Наблюдаемый результат	Источник	Владелец
AC-01	корректная отправка	пользователь получает уникальный номер и понятный следующий шаг	E-014	владелец продукта
AC-02	повторная отправка	пользователь предупреждён, введённые данные сохранены	E-021	владелец продукта
AC-03	обработка недоступна	пользователь получает восстанавливаемый путь ошибки	политика P-03	владелец сервиса

«Создать конечную точку», «использовать модальное окно» и «написать модульные тесты» — задачи реализации или поставки, а не наблюдаемые критерии приёмки.

Какие крайние случаи рассматривать?

Попросите ИИ проверить нормальный путь по явным категориям:

Граница: пустое, минимальное, максимальное, просроченное, повторное или необычное допустимое значение.
Ошибка: недоступная зависимость, тайм-аут, отклонённый запрос, частичное завершение и повтор.
Разрешение: выход из учётной записи, неверная роль, смена владельца или отозванный доступ.
Доступность: клавиатура, фокус, объявление состояния, исправление ошибки и невизуальное понимание.
Конфиденциальность: минимизация, видимость, хранение, экспорт и удаление данных.
Безопасность: неразрешённые действия, опасный ввод, повтор запроса, ограничения частоты и аудит.
Эксплуатация: мониторинг, передача в поддержку, откат и поведение при деградации.

Не каждой истории нужны все категории, но для каждой следует явно решить «покрыто» или «не применимо». Области вне полномочий команды должны рассматривать профильные владельцы.

Профиль NIST для генеративного ИИ предупреждает об уверенно созданной ложной информации и подчёркивает оценку, проверку источников, человеческий надзор и безопасную обработку ошибок.［5］ Сгенерированный критерий остаётся кандидатом до проверки доказательств и выполнимости ответственными людьми.

Когда использовать Given, When, Then?

Применяйте Given/When/Then, когда конкретный пример улучшает общее понимание. Cucumber определяет Given как исходный контекст, When как событие или действие, а Then как ожидаемый наблюдаемый результат. Результат должен быть виден пользователю или внешней системе, а не зависеть от скрытых деталей реализации.［3］

Пример:

Given вошедший заявитель заполнил обязательные поля When заявитель отправляет форму один раз Then сервис показывает уникальный номер и следующий шаг

Для повторной отправки, потери связи, смены разрешений и неверных данных создайте отдельные примеры. Один сценарий — пример критерия, а не обязательно полный набор.

Чем критерии отличаются от задач, тестов и Definition of Done?

Артефакт	Главный вопрос	Область	Владелец
история пользователя	какой результат нужен и зачем?	одна связная потребность	продуктовая команда
критерии приёмки	какие наблюдаемые условия делают историю приемлемой?	конкретная история	продукт и заинтересованные стороны
задачи реализации	как команда это создаст?	техническая работа	команда поставки
тестовые случаи	как выполнять и сравнивать поведение?	проверочное покрытие	QA и разработка
Definition of Done	какое общее состояние качества применяется к инкременту?	продукт или команда	Scrum Team/организация

Scrum Guide определяет Definition of Done как формальное состояние инкремента, соответствующего мерам качества продукта.［4］ Это более широкое и повторно используемое условие, чем критерии отдельной истории. Функциональные критерии могут быть выполнены, но работа ещё не Done из-за документации, проверки безопасности, интеграции или другого общего требования.

Приёмочные тесты также не равны критериям: критерии говорят, что должно быть истинно, а тесты и проверки создают доказательство. NASA описывает приёмочные испытания как формальное тестирование того, удовлетворяет ли система критериям.［2］

После утверждения критериев используйте процесс генерации тестов с ИИ. Для повторяемых операционных инструкций подходит создание контрольных списков SOP с ИИ.

Как писать истории пользователей и критерии приёмки с ИИ с сохранением трассируемости?

Создайте таблицу трассируемости требований:

История/критерий	ID доказательств	ID ограничений	Доказательство теста или проверки	Владелец решения	Статус
US-07 / AC-01	E-014	P-03	AT-114	владелец продукта	утверждено

У каждого критерия должен быть источник или явное решение владельца. Каждое значимое ограничение должно вести к одному или нескольким критериям. Позже критерий связывается с тестовым доказательством, но нельзя выдумывать это доказательство во время подготовки.

Проведите совместную проверку с нужными владельцами продукта, дизайна, разработки, QA, исследований, доступности, безопасности, конфиденциальности, права и эксплуатации. Спросите: подтверждены ли пользователь и цель; не являются ли критерии инструкциями реализации; наблюдаемы ли нормальный, граничный и ошибочный исходы; явны ли решения о разрешениях, доступности, конфиденциальности и безопасности; измеримы ли допуски; у каждого ли пункта есть утверждающий.

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

Итоги

Начинайте с проверенных свидетельств, ограничений, предположений и ответственного владельца.
Стройте историю вокруг потребности и цели, а не интерфейса.
По возможности делите epic по самостоятельно ценным результатам.
Задавайте наблюдаемые нормальные, граничные, ошибочные, разрешительные, доступные, конфиденциальные и безопасные исходы.
Используйте Given/When/Then как необязательные примеры, а не замену анализу.
Связывайте критерии с доказательствами и отделяйте человеческое утверждение от генерации.

Часто задаваемые вопросы (FAQ)

Может ли ИИ написать истории по протоколу встречи?

Он может подготовить кандидатов, но высказывания на встрече не являются автоматически проверенными потребностями. Сначала разделите доказательства, запросы сторон, предположения и решения.

Сколько критериев должно быть у истории?

Столько, чтобы определить важные нормальные, граничные и ошибочные исходы без превращения истории в свалку спецификаций. Длинный список или несколько целей требуют разделения.

Обязателен формат «Как, я хочу, чтобы»?

Нет. Формат полезен, но важны действующее лицо, потребность и цель. Выберите последовательный формат проверки команды.

Обязательны ли Given/When/Then?

Нет. Для многих историй лучше ясный список. Используйте сценарий, если он поясняет контекст, событие и ожидаемый результат.

Критерии приёмки — это тестовые случаи?

Нет. Критерии определяют, что должно быть истинно; тестовый случай задаёт входы, действия, среду и сравнения для получения доказательств.

Definition of Done входит в каждую историю?

Общее Definition of Done применяется к качеству инкремента или продукта, а критерии — к истории. До завершения работы могут потребоваться оба условия.

Может ли ИИ утвердить измеримое требование?

Нет. Измеримость не доказывает ценность, полномочие политики, выполнимость, безопасность или организационное одобрение. Решение принимают ответственные люди.

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

Источники:

GOV.UK Service Manual — Writing user stories — https://www.gov.uk/service-manual/agile-delivery/writing-user-stories
NASA Software Engineering Handbook — SWE-034 Acceptance Criteria — https://swehb.nasa.gov/spaces/7150/pages/16450634/SWE-034%2B-%2BAcceptance%2BCriteria
Cucumber — Gherkin Reference — https://cucumber.io/docs/gherkin/reference/
Scrum Guides — The Scrum Guide — https://scrumguides.org/scrum-guide.html
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Sources checked 30 августа 2026 г.

Рекомендуемые статьи:

Как писать истории пользователей и критерии приёмки с ИИ