ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story / forpes.ru

Главная
ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story

ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story -1

20.10.2025 08:49

EgorMaryushko 11 575 Источник

Привет, Хабр! На связи Егор Марюшко, в ИТ с 2014 года в роли: бизнес‑эксперта, бизнес и системного аналитика, руководителя отделов бизнес и системного анализа, архитектора решений.

Я не верю в то, что ИИ отберёт у бизнес и системных аналитиков работу.
Как сказал Крейг Винг в одном из своих выступлений:

«ИИ — это невероятно дорогостоящий галлюцинирующий попугай, комбинирующий лишь то, что увидел».

ИИ — это современный и перспективный инструмент, и им надо уметь пользоваться.
Большинство статей и докладов о применении ИИ системными аналитиками рассказывают о том, как исследовать новую для себя предметную область, составить опросник для общения с заказчиком, нарисовать бизнес‑процесс, UML sequence diagram, сгенерировать User Story и так далее. Но часто эти операции требуют:

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

Безусловно, есть варианты эффективного применения, подтверждённые метриками, но чаще это выливается в использование ИИ ради использования ИИ.

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

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

В данной статье разберём промт для создания критериев приемки (Acceptance Criteria — AC) для User Story (US).
Да, кто‑то скажет, что писать AC к US должны тестировщики, но если вы как аналитик хотите получить прогнозируемый результат реализации US, то ключевые AC вы напишете сами =)

В процессе подготовки промта я проверил его применимость на 5 наиболее распространённых и доступных сейчас ИИ‑моделях:

ChatGPT
DeepSeek
Qwen
Алиса (Яндекс GPT)
GigaChat

Если вас НЕ интересуют примеры работы разных ИИ, их сравнение, наблюдения и промежуточные выводы, то пролистывайте статью до конца — там вы найдёте шаблон промта и инструкцию по его применении =) ⬇️

Если любопытство взяло верх, то давайте продолжим.
Исследование проводилось на нескольких User Story. В качестве примера рассмотрим типовую User Story для интернет‑магазина:

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

Каждому ИИ отправляли основной промт, получив в ответ от 5 до 10 критериев приемки, после первого дополнительного запроса были получены от 10 до 18 AC и после второго дополнительного запроса были получены от 15 до 25 AC в зависимости от ИИ.

Под спойлерами приведены ответы ИИ без каких либо изменений в критериях приемки, в колонке Комментарий мной оставлены пометки к некоторым критериям приемки.

Ответы ChatGPT

Основной промт

№	Критерий приемки	Комментарий
1	При условии, что пользователь авторизован в личном кабинете, когда он переходит в раздел «История заказов», то система отображает список всех заказов пользователя.
2	При условии, что у пользователя есть оформленные заказы, когда он задает период дат (начало и конец), то система отображает только заказы, дата которых попадает в указанный период.
3	При условии, что пользователь задает период, в котором отсутствуют заказы, когда выполняется поиск, то система отображает сообщение «Заказы за выбранный период отсутствуют».
4	При условии, что у пользователя нет оформленных заказов, когда он открывает раздел «История заказов», то система отображает сообщение «У вас нет заказов».
5	При условии, что пользователь просматривает список заказов, когда он выбирает конкретный заказ, то система отображает детальную информацию по выбранному заказу (номер, дата, статус, сумма, список товаров).	Додумывание деталей и Другая User Story о просмотре деталей заказа
6	При условии, что пользователь изменяет даты периода, когда он подтверждает поиск, то система обновляет список заказов в соответствии с новым периодом без перезагрузки страницы.
7	При условии, что запрос выполняется успешно, когда система отображает список заказов, то каждая запись содержит корректные данные: номер, дата, сумма, статус заказа.	Додумывание деталей

1й дополнительный промт

№	Критерий приемки	Комментарий
8	При условии, что пользователь задает некорректный диапазон дат (например, дата начала позже даты окончания), когда он запускает поиск, то система отображает сообщение об ошибке и не выполняет поиск.
9	При условии, что количество заказов превышает установленный лимит отображения на одной странице, когда пользователь открывает «Историю заказов», то система отображает заказы постранично с возможностью перехода между страницами.
10	При условии, что пользователь находится в разделе «История заказов», когда он обновляет страницу, то система сохраняет выбранный период и отображает результаты поиска без необходимости повторного ввода.
11	При условии, что пользователь вводит даты периода и покидает поле ввода, когда он возвращается к странице позже, то система сохраняет введённые значения до обновления страницы или выхода из аккаунта.
12	При условии, что пользователь изменил временной период поиска, когда он возвращается к списку заказов без сохранения изменений, то система отображает список заказов по последнему подтверждённому периоду.
13	При условии, что в результате поиска отображается список заказов, когда пользователь наводит курсор на элемент заказа, то система визуально подсвечивает выбранный заказ.
14	При условии, что пользователь просматривает историю заказов, когда у одного из заказов изменён статус (например, «Доставлен» → «Возврат»), то система отображает актуальный статус при следующем обновлении данных.	Избыточный AC
15	При условии, что пользователь выполняет поиск заказов за большой период, когда время отклика превышает допустимое значение, то система отображает индикатор загрузки до завершения поиска.	НФТ

2й дополнительный промт

№	Критерий приемки	Комментарий
16	При условии, что пользователь просматривает историю заказов, когда он применяет фильтр по статусу заказа (например, «Доставлен», «Отменён»), то система отображает только заказы, соответствующие выбранному статусу.
17	При условии, что пользователь просматривает историю заказов, когда он сортирует заказы по дате, то система упорядочивает список заказов в соответствии с выбранным направлением сортировки (по возрастанию или убыванию).
18	При условии, что пользователь открывает раздел «История заказов» впервые, когда страница загружается, то система по умолчанию отображает заказы за последние 3 месяца.
19	При условии, что пользователь открывает детальную карточку заказа, когда она содержит несколько товаров, то система отображает полную информацию по каждому товару без усечения данных.	Другая User Story о просмотре деталей заказа
20	При условии, что пользователь просматривает историю заказов, когда соединение с сервером прерывается, то система отображает сообщение об ошибке и предлагает повторить запрос.
21	При условии, что пользователь изменяет период поиска, когда он очищает поля ввода дат, то система автоматически отображает все заказы без фильтрации по дате.
22	При условии, что пользователь задает будущую дату в поле окончания периода, когда он запускает поиск, то система корректно исключает заказы с датой позже текущей.	Избыточный AC
23	При условии, что пользователь просматривает историю заказов, когда он нажимает кнопку «Обновить», то система выполняет повторный запрос и отображает актуальные данные без изменения текущего периода.
24	При условии, что пользователь авторизован под другим аккаунтом, когда он открывает раздел «История заказов», то система отображает только заказы, принадлежащие текущему пользователю.	Избыточный AC
25	При условии, что пользователь просматривает историю заказов, когда он кликает по номеру заказа, то система копирует номер заказа в буфер обмена.	Додумывание деталей

Ответы DeepSeek

Основной промт

№	Критерий приемки	Комментарий
1	При условии, что покупатель аутентифицирован в системе, когда он переходит в раздел "История заказов", то система отображает список заказов за последние 30 дней по умолчанию.
2	При условии, что покупатель аутентифицирован и в его истории заказов есть заказы за выбранный период, когда он задает произвольный период дат с помощью элементов выбора даты и нажимает кнопку "Показать", то система отображает список заказов, сделанных в указанном временном диапазоне.
3	При условии, что покупатель аутентифицирован и в его истории заказов нет заказов за выбранный период, когда он задает произвольный период дат и нажимает кнопку "Показать", то система отображает сообщение "За выбранный период заказы не найдены".
4	При условии, что покупатель аутентифицирован и система отображает список заказов, когда покупатель нажимает на номер конкретного заказа, то система отображает детальную информацию по данному заказу (состав, статус, сумма, адрес доставки).	Другая User Story о просмотре деталей заказа
5	При условии, что покупатель аутентифицирован и задает период, где конечная дата раньше начальной, когда он нажимает кнопку "Показать", то система отображает сообщение об ошибке "Некорректный период. Конечная дата не может быть раньше начальной."

1й дополнительный промт

№	Критерий приемки	Комментарий
1	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он применяет сортировку по дате заказа (по убыванию), то система отображает заказы от самых новых к самым старым.
2	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он применяет сортировку по общей сумме заказа (по возрастанию), то система отображает заказы от самых дешевых к самым дорогим.
3	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он вводит текст в поле поиска по названию товара и нажимает "Найти", то система отображает только те заказы, в составе которых есть товары, соответствующие поисковому запросу.
4	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он выбирает фильтр по статусу заказа "Доставлен", то система отображает только заказы с выбранным статусом.
5	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он нажимает кнопку "Экспорт в CSV", то система формирует и скачивает файл с историей заказов за текущий отображаемый период.	Другая User Story об экспорте данных
6	При условии, что покупатель аутентифицирован и в системе имеется более 10 заказов за период, когда он переходит в раздел "История заказов", то система отображает заказы постранично, по 10 элементов на страницу.
7	При условии, что покупатель аутентифицирован и система отображает детали заказа, когда он нажимает кнопку "Повторить заказ", то система добавляет все товары из этого заказа в текущую корзину покупателя.	Другая User Story о повторении заказа

2й дополнительный промт

№	Критерий приемки	Комментарий
1	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он нажимает на кнопку "Показать все заказы", то система отображает полную историю заказов без ограничения по периоду.
2	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он применяет фильтр по способу оплаты "Картой онлайн", то система отображает только заказы с указанным способом оплаты.	Додумывание деталей
3	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он выбирает опцию "Только отмененные заказы", то система отображает только заказы со статусом "Отменен".	Додумывание деталей
4	При условии, что покупатель аутентифицирован и система отображает детали заказа, когда он нажимает кнопку "Скачать чек", то система формирует и предоставляет для скачивания PDF-файл с фискальным чеком.	Другая User Story о получении чека
5	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он использует комбинацию фильтров "период + статус + способ оплаты", то система отображает заказы, соответствующие всем выбранным критериям одновременно.
6	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он наводит курсор на иконку "i" рядом с номером заказа, то система показывает всплывающую подсказку с основной информацией о заказе (дата, сумма, статус).	Додумывание деталей
7	При условии, что покупатель аутентифицирован и система отображает список заказов, когда он нажимает кнопку "Сбросить фильтры", то система возвращает отображение к состоянию по умолчанию (заказы за последние 30 дней).

Ответы Qwen

Основной промт

№	Критерий приемки	Комментарий
1	При условии, что покупатель авторизован в личном кабинете, когда открывает раздел «История заказов», то система отображает список всех его заказов по умолчанию за последние 30 дней.
2	При условии, что покупатель авторизован и находится в разделе «История заказов», когда задаёт произвольный период времени (начальная и конечная дата включительно), то система отображает только те заказы, дата оформления которых попадает в указанный период.
3	При условии, что покупатель задал период, выходящий за пределы доступной истории (например, более 3 лет назад), когда нажимает «Применить», то система отображает сообщение: «История заказов доступна только за последние 3 года» и не показывает заказы вне этого диапазона.
4	При условии, что в заданном периоде отсутствуют заказы, когда покупатель применяет фильтр по дате, то система отображает сообщение: «В выбранный период заказы отсутствуют».
5	При условии, что покупатель авторизован и у него есть хотя бы один заказ в заданном периоде, когда открывает историю заказов, то система отображает для каждого заказа: номер заказа, дату оформления, статус, общую сумму и список товаров (наименование, артикул, количество).	Додумывание деталей

1й дополнительный промт

№	Критерий приемки	Комментарий
6	При условии, что покупатель авторизован и применяет фильтр по дате с некорректными значениями (например, конечная дата раньше начальной), когда нажимает «Применить», то система отображает сообщение: «Некорректный период: дата окончания не может быть раньше даты начала» и не выполняет фильтрацию.
7	При условии, что покупатель авторизован и открывает историю заказов, когда прокручивает список до конца, то система подгружает следующую порцию заказов (пагинация или бесконечная прокрутка), если общее количество превышает лимит отображения на одной странице.
8	При условии, что покупатель авторизован и задал корректный период, когда нажимает «Сбросить фильтр», то система возвращает отображение списка заказов за последние 30 дней по умолчанию.
9	При условии, что покупатель авторизован и у него есть заказы с одинаковой датой оформления, когда применяет фильтр по этой дате, то система отображает все заказы, оформленные в указанную дату, независимо от времени.	Избыточный AC
10	При условии, что покупатель авторизован и открывает историю заказов впервые, когда раздел загружается, то система автоматически устанавливает фильтр по дате на последние 30 дней и отображает соответствующие заказы (если есть).	Дубль

2й дополнительный промт

№	Критерий приемки	Комментарий
11	При условии, что покупатель авторизован и задал период, включающий будущие даты, когда нажимает «Применить», то система игнорирует будущие даты и отображает заказы только до текущей даты включительно.	Избыточный AC
12	При условии, что покупатель авторизован и открывает историю заказов с мобильного устройства, когда применяет фильтр по дате, то интерфейс корректно отображает календарь выбора дат и результаты фильтрации без горизонтального скролла или обрезки контента.	Избыточный AC
13	При условии, что покупатель авторизован и у него есть заказы в статусе «Отменён» или «Возвращён», когда применяет фильтр по любому периоду, то система включает такие заказы в список, если их дата оформления попадает в заданный период.	Додумывание деталей и Избыточный АС
14	При условии, что покупатель авторизован и копирует URL страницы с применённым фильтром по дате, когда открывает эту ссылку в новой сессии (после повторной авторизации), то система восстанавливает тот же период и отображает соответствующие заказы.
15	При условии, что покупатель авторизован и в заданном периоде есть заказы с разными валютами, когда отображается список заказов, то система корректно указывает валюту для каждого заказа рядом с его общей суммой.	Додумывание деталей

Ответы Алиса (Яндекс GPT)

Основной промт

Номер	Критерий приемки	Комментарий
1	При условии авторизации пользователя в системе, когда пользователь переходит в раздел «История заказов», то система отображает список всех заказов пользователя с указанием даты, статуса и общей суммы
2	При условии наличия у пользователя хотя бы одного заказа, когда пользователь выбирает период в фильтре дат, то система отображает только заказы, попадающие в указанный временной промежуток
3	При условии наличия нескольких заказов у пользователя, когда пользователь кликает на конкретный заказ в списке, то система открывает детальный просмотр этого заказа с информацией о товарах, их количестве и стоимости	Другая User Story о просмотре деталей заказа
4	При условии ввода некорректных дат в фильтре (конечная дата раньше начальной), когда пользователь пытается применить фильтр, то система отображает сообщение об ошибке с пояснением
5	При условии отсутствия заказов в выбранном периоде, когда пользователь применяет фильтр дат, то система отображает сообщение «За выбранный период заказов не найдено»
6	При условии наличия заказов с разными статусами, когда пользователь выбирает фильтр по статусу заказа, то система отображает только заказы с выбранным статусом
7	При условии наличия в заказе нескольких товаров, когда пользователь открывает детали заказа, то система показывает полный список товаров с их характеристиками и итоговой стоимостью	Другая User Story о просмотре деталей заказа
8	При условии наличия у заказа номера отслеживания, когда пользователь открывает детали заказа, то система предоставляет ссылку для отслеживания посылки	Другая User Story о просмотре деталей заказа
9	При условии наличия у пользователя прав администратора, когда администратор просматривает историю заказов другого пользователя, то система отображает те же данные, что и для обычного пользователя	Другая User Story о просмотре деталей заказа
10	При условии изменения статуса заказа в системе, когда пользователь просматривает историю заказов, то система отображает актуальное состояние заказа

1й дополнительный промт

Номер	Критерий приемки	Комментарий
11	При условии сортировки списка заказов по дате, когда пользователь выбирает направление сортировки (по возрастанию/убыванию), то система корректно отображает заказы в выбранном порядке
12	При условии наличия большого количества заказов, когда пользователь использует пагинацию, то система корректно отображает нужное количество заказов на каждой странице
13	При условии экспорта истории заказов, когда пользователь нажимает кнопку «Экспорт», то система формирует файл в формате CSV/PDF с данными всех отображаемых заказов	Другая User Story об экспорте данных
14	При условии поиска по номеру заказа, когда пользователь вводит номер в поисковую строку, то система мгновенно отображает соответствующий заказ
15	При условии наличия комментариев к заказу, когда пользователь открывает детали заказа, то система отображает все комментарии, оставленные при оформлении	Другая User Story о просмотре деталей заказа
16	При условии изменения способа оплаты заказа, когда пользователь просматривает историю, то система отображает актуальную информацию о способе оплаты
17	При условии наличия промокода в заказе, когда пользователь открывает детали заказа, то система отображает информацию о примененном промокоде и размере скидки	Другая User Story о просмотре деталей заказа
18	При условии наличия нескольких адресов доставки, когда пользователь просматривает историю заказов, то система корректно отображает адрес доставки для каждого заказа

2й дополнительный промт

Номер	Критерий приемки	Комментарий
19	При условии наличия возвратов по заказу, когда пользователь открывает детали заказа, то система отображает информацию о возвращенных товарах и суммах	Другая User Story о просмотре деталей заказа
20	При условии наличия частичных оплат, когда пользователь просматривает историю заказа, то система отображает все транзакции по оплате	Другая User Story о просмотре деталей заказа
21	При условии изменения цены товара после покупки, когда пользователь просматривает историю, то система отображает исходную цену на момент заказа
22	При условии наличия бонусных баллов за заказ, когда пользователь открывает детали заказа, то система показывает количество начисленных/списанных баллов	Другая User Story о просмотре деталей заказа
23	При условии наличия прикрепленных файлов к заказу (чеки, инструкции), когда пользователь открывает заказ, то система предоставляет доступ к этим файлам	Другая User Story о просмотре деталей заказа
24	При условии смены email пользователя, когда пользователь просматривает старые заказы, то система отображает оригинальный email на момент оформления	Другая User Story о просмотре деталей заказа
25	При условии наличия нескольких платежных методов в одном заказе, когда пользователь открывает детали, то система отображает все использованные способы оплаты	Другая User Story о просмотре деталей заказа

Ответы GigaChat

Основной промт

№	Критерий приемки	Комментарий
1	При условии входа покупателя в личный кабинет, когда он выбирает пункт меню «История заказов», то система отображает список всех предыдущих заказов.
2	При условии выбора периода времени покупателем, когда он вводит начальную и конечную даты, то система фильтрует и показывает заказы только за указанный период.
3	При условии отсутствия заказов за выбранный период, когда покупатель устанавливает фильтр дат, то система уведомляет его соответствующим сообщением.
4	При условии наличия ошибок ввода дат, когда покупатель неправильно вводит диапазон дат, то система выводит сообщение об ошибке и подсказывает правильный формат.
5	При условии перехода покупателя по ссылке заказа, когда он кликает на элемент списка истории заказов, то система открывает подробную информацию о данном заказе.	Другая User Story о просмотре деталей заказа
6	При условии повторного посещения страницы истории заказов, когда покупатель обновляет страницу браузера, то система сохраняет примененный фильтр и возвращает последний видимый список заказов.

1й дополнительный промт

№	Критерий приемки	Комментарий
7	При условии сортировки заказов покупателем, когда он выбирает порядок сортировки («по дате», «по статусу»), то система сортирует список согласно выбору.
8	При условии изменения количества записей на странице, когда покупатель выбирает число элементов на странице, то система отображает указанное количество заказов.
9	При условии экспорта истории заказов, когда покупатель нажимает кнопку «Экспорт», то система генерирует файл формата CSV/XLSX с историей заказов.	Другая User Story об экспорте данных
10	При условии наличия статуса доставки, когда заказ имеет информацию о доставке, то система отображает трек-номер и ссылку на отслеживание.
11	При условии оформления нового заказа, когда покупатель совершает новый заказ, то система автоматически добавляет запись в историю заказов.

2й дополнительный промт

№	Критерий приемки	Комментарий
12	При условии использования фильтра по статусу заказа, когда покупатель выбирает определенный статус («Оплачен», «Отменён»), то система фильтрует и показывает соответствующие заказы.
13	При условии просмотра детализированной информации заказа, когда покупатель запрашивает полную информацию о товаре, то система отображает характеристики товаров, цену и итоговую сумму.	Другая User Story о просмотре деталей заказа
14	При условии копирования номера заказа, когда покупатель активирует соответствующую команду интерфейса, то система выделяет и позволяет скопировать уникальный номер заказа.	Додумывание деталей и Другая User Story о копировании номера заказа
15	При условии поиска конкретного заказа, когда покупатель вводит ключевые слова (например, название товара или дату), то система находит подходящие записи среди исторических заказов.
16	При условии возврата к предыдущему состоянию фильтра, когда покупатель отменяет введённые фильтры, то система восстанавливает первоначальный вид списка заказов.

Наблюдения:

Только DeepSeek и Qwen упоминают условие аутентификации/авторизации на регулярной основе.
ChatGPT и Алиса сделали это один или два раза, хотя для просмотра истории заказов авторизация является важным условием.
GigaChat порадовал использованием максимально русифицированной формулировки без иностранных заимствований: «При условии входа покупателя в личный кабинет», хотя есть ощущение, что он имел в виду именно вход, а не проверку доступов.
В защиту ChatGPT и Алисы скажу, что условие аутентификации/авторизации применительно к данной User Story и её критериям приемки можно вынести как базовое, чтобы не писать каждый раз — возможно, это и имелось в виду этими ИИ, так как у них обоих аутентификация/авторизация упомянуты в первом AC. Однако, как показывает практика, упрощение документации ведёт к увеличению количества ошибок и дыр в безопасности. Упомянешь проверку безопасности только при переходе на страницу — и не успеешь моргнуть, как все остальные операции с историей заказов пользователя можно выполнять из‑под любого другого пользователя или вообще без авторизации. Звучит абсурдно, но подобные уязвимости встречаются даже на сайтах крупных авиакомпаний, когда при наличии кода бронирования можно было напрямую зайти на список всех броней пассажира и дальше делать с ними всё, что угодно (реальный кейс, озвученный на недавней конференции по информационной безопасности).

AC с авторизацией / всего AC
- ChatGPT — 2/25
- DeepSeek — 19/19
- Qwen — 13/15
- Алиса (Яндекс GPT) — 1/25
- GigaChat — 0–1/16
Первый критерий приемки у всех связан со входом, переходом, открытием или выбором пункта меню «История заказов».

ChatGPT, Алиса и GigaChat с барского плеча предлагают сразу вывести пользователю список ВСЕХ его заказов, тем самым при наличии долгой истории покупок намертво повесив ЛК или отвалившись по timeout.
У DeepSeek и Qwen упомянуто ограничение выгрузки заказов за последние 30 дней, что улучшает ситуацию. В то же время у каждого ИИ во второй порции AC добавляется критерий приемки с упоминанием пагинации или бесконечной прокрутки.

ChatGPT, DeepSeek, Qwen полноценно указывают, что у страницы есть лимит на количество отображаемых заказов.

Qwen сразу предлагает варианты: пагинация или бесконечная прокрутка.

Алиса и GigaChat косвенно указывают на пагинацию, напрямую не упоминая про лимит записей на странице.

На мой взгляд, данный кейс хорошо показывает, как ИИ идёт от простых и общих формулировок к усложнению и детализации при дополнительных запросах. Однако «живой» аналитик чаще всего совместит два данных AC в одном первом, написав примерно следующее: «При условии: покупатель авторизован в системе, когда: покупатель инициирует отображение истории заказов, то: система отображает покупателю историю его последних NN записей».
Несмотря на явно указанное условие в промте «критерии приемки не повторяют друг друга», Qwen создал один дубль критерия приемки, немного его перефразировав:
- При условии, что покупатель авторизован в личном кабинете, когда открывает раздел «История заказов», то система отображает список всех его заказов по умолчанию за последние 30 дней.
- При условии, что покупатель авторизован и открывает историю заказов впервые, когда раздел загружается, то система автоматически устанавливает фильтр по дате на последние 30 дней и отображает соответствующие заказы (если есть).
Большинство корректных критериев приемки повторяются у всех ИИ, однако у Qwen, ChatGPT, DeepSeek и Алисы попадаются уникальные AC, не дублирующиеся у других ИИ.
Например:
- ChatGPT — При условии, что пользователь выполняет поиск заказов за большой период, когда время отклика превышает допустимое значение, то система отображает индикатор загрузки до завершения поиска.
- DeepSeek — При условии, что покупатель аутентифицирован и система отображает список заказов, когда он нажимает кнопку «Сбросить фильтры», то система возвращает отображение к состоянию по умолчанию (заказы за последние 30 дней).
- Qwen — При условии, что покупатель авторизован и копирует URL страницы с применённым фильтром по дате, когда открывает эту ссылку в новой сессии (после повторной авторизации), то система восстанавливает тот же период и отображает соответствующие заказы.
- Алиса — При условии изменения цены товара после покупки, когда пользователь просматривает историю, то система отображает исходную цену на момент заказа.
Все ИИ, кроме Qwen, предлагают то или иное количество AC, связанных с другими User Story, смежными с исходной

AC для других историй / всего AC:
- ChatGPT — 2/25
  - Пример User Story о просмотре деталей заказа: «При условии, что пользователь открывает детальную карточку заказа, когда она содержит несколько товаров, то система отображает полную информацию по каждому товару без усечения данных».
- DeepSeek — 4/19
  - Пример User Story об экспорте чеков: «При условии, что покупатель аутентифицирован и система отображает детали заказа, когда он нажимает кнопку „Скачать чек“, то система формирует и предоставляет для скачивания PDF‑файл с фискальным чеком».
- Qwen — 0/15
- Алиса (Яндекс GPT) — 13/25
  - Пример User Story об экспорте истории заказов: «При условии экспорта истории заказов, когда пользователь нажимает кнопку „Экспорт“, то система формирует файл в формате CSV/PDF с данными всех отображаемых заказов».
- GigaChat — 4/16
  - Пример User Story об экспорте истории заказов: «При условии экспорта истории заказов, когда покупатель нажимает кнопку „Экспорт“, то система генерирует файл формата CSV/XLSX с историей заказов».
Все ИИ, кроме Алисы, в некоторых AC фантазируют и додумывают детали, о которых не указано в исходных данных. Однако у Алисы больше всего AC, которые можно отнести к другим User Story.
- Додумывание деталей на примере DeepSeek: «При условии, что покупатель аутентифицирован и система отображает список заказов, когда он наводит курсор на иконку „i“ рядом с номером заказа, то система показывает всплывающую подсказку с основной информацией о заказе (дата, сумма, статус)».
DeepSeek создает AC после нового запроса как отдельный набор AC. ChatGPT, Qwen, Алиса, GigaChat добавляют новые критерии к ранее созданным и в каждом ответе формируют единый список со сквозной нумерацией.

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

Шаблон основного промта:

Вы являетесь — системным и бизнес‑аналитиком и экспертом в [ОТРАСЛЬ] в одной роли с 20-летним опытом работы, обладающим отличными навыками описания и структурирования информации. Вы также обладаете исключительными навыками бизнес‑анализа и системного анализа. Все ваши ответы всегда хорошо структурированы. Вы должны грамотно описывать информацию, используя минимальное количество слов, если пользователь не просил вас об этом. Вы всегда предоставляете хорошо структурированные ответы.
Контекст: идёт этап детальной проработки требований к программному обеспечению.

Задача: Составь критерии приемки для User Story «[ВАША USER STORY]» по сценарно‑ориентированному подходу (при условии, когда, то система), только текст.

Позитивный пример идеального критерия приемки:
«При условии..., когда..., то система...».
Избегай размытых формулировок.
Инспекция. Перед финальным ответом проверь:
— все критерии приемки связаны с исходной user story;
— критерии приемки не повторяют друг друга.
Если условие не выполнено — исправь ответ, затем выведи.
Тон: деловой, лаконичный, каждое действие с новой строки.
Окружение: читатели — продукт‑оунер и команда разработки.
Результат: выведи результат в таблицу с колонками: номер, критерий приемки.

Шаблон дополнительного промта:

добавь новые варианты, которые не упоминались раньше.

Инструкция по применению:

У вас уже сформирован список User Story, для которых вам необходимо написать критерии приемки. User Story должны максимально соответствовать критериям качества INVEST.
Выбираете любой удобный для вас ИИ.
Копируете основной промт в чат взаимодействия с ИИ:
1. заменяете в основном промте [ОТРАСЛЬ] на название вашей предметной области, для которой вы разрабатываете ПО, например:
  - в e‑commerce
  - в онлайн‑образовании
  - в банковских операциях
  - и так далее
2. заменяете [ВАША USER STORY] на текст вашей User Story, например: «Я как покупатель интернет‑магазина хочу иметь возможность видеть историю своих заказов за заданный период времени, для того чтобы иметь возможность найти информацию о ранее заказанных товарах».
Запускаете выполнение промта и получаете первую порцию критериев приемки.
Копируете дополнительный промт в чат взаимодействия с ИИ.
Запускаете выполнение дополнительного промта первый раз, ждёте ответа и запускаете второй раз.
- Двойной запуск дополнительного промта вместе с запуском основного промта позволяет получить в среднем от 15 до 25 критериев приемки.
- Ответ на основной промт чаще всего даёт основные базовые критерии приемки для User Story.
- Ответ на первый дополнительный промт чаще всего даёт от 40 до 80% новых хороших критериев приемки.
- Ответ на второй дополнительный промт чаще всего даёт от 10 до 50% новых хороших критериев приемки.
- В третьем и последующих запросах ИИ начинает активно ~~галлюцинировать~~ фантазировать о том, что ещё может быть в вашей системе и как это может быть задействовано в вашей User Story, или уходить в критерии приемки смежных User Story, которые могут вытекать из вашей, которые он самостоятельно додумал, что существенно снижает полезность его ответов в диапазон 0–30%.
Копируете полученные результаты в свою документацию/базу знаний, удаляете избыточные и фантазийные критерии приемки и уточняете полезные.

Применимость:

Как показала практика, у опытного аналитика обдумывание и написание одного критерия приемки может занимать 4–6–10 минут, у начинающего — 5–10 и более минут. Создание критериев приемки через ИИ и последующая валидация в среднем занимает 1–3–5 минут на один критерий у опытного специалиста и 3–6 минут у начинающего. Таким образом, получаем примерно 30-50% сокращение трудозатрат на подготовку критериев приемки.

Выводы:

Данный промт можно применять как есть для сокращения своих трудозатрат.
Выбор того или иного ИИ незначительно влияет на качество исходного набора критериев приемки — в любом случае его необходимо валидировать.
Для улучшения качества исходного набора критериев приемки необходимо добавлять больше контекста в промт, как следствие — тратить на его подготовку больше времени, что усложняет и удорожает его использование.
Создание критериев приёмки через ИИ — это как дать задачу джуну и провести последующее ревью. Один из топ-10 российских банков ведёт активное внедрение ИИ во всех своих отделах и подразделениях, фактически заставляя сначала попробовать решить любую задачу через ИИ. Не везде это эффективно, но они пробуют — и очень быстро нарабатывают опыт, нащупывая верный путь.

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

Буду рад узнать примеры ваших промтов и обсудить особенности их применения в комментариях!

Надеюсь, материал будет вам полезен! До встречи в следующей статье!

Благодарность

Благодарю команды IISAD — АНО Международный институт системного анализа и проектирования и STENET school за участие в фокус‑группе при подготовке статьи.

ссылки

Комментарии (11)

ASenchenko
20.10.2025 11:44
#28986418
Вот здесь:

ChatGPT, Алиса и GigaChat с барского плеча предлагают сразу вывести пользователю список ВСЕХ его заказов, тем самым при наличии долгой истории покупок намертво повесив ЛК или отвалившись по timeout.

Вы не правы. Критерий отработан чётко, строго по UC. Большая история покупок - это уже другой UC и с другими ЗИ.

Однако «живой» аналитик чаще всего совместит два данных AC в одном первом, написав примерно следующее

Ну то есть Вы сознательно написали UC так, чтобы посмотреть разворачивание контекста машиной ? Не этично.

Следующее

Все ИИ, кроме Алисы, в некоторых AC фантазируют и додумывают детали, о которых не указано в исходных данных.

Вы не избавитесь от этого. Галлюцинации - базовое свойство векторного поиска, оснобенно с учетом следующего:

Важно.

Вы дико перегрузили входной промпт прилагательными. "отличными", "исключительными", не хватает разве что "божественными". Это реальный оверпромптинг.

Вы пытаетесь добиться от LLM каких-то космических компетенций, сдвигая вектора поиска в сторону экспертных комплексных решений, но ради чего ? Критериев приёмки по простенькому кейсу ? Ну не удивительно, что они начинают фантазировать и/или цеплять смежные кейсы. Вы их сами об этом попросили.
1. EgorMaryushko Автор
  20.10.2025 11:44
  #28986790
  Андрей, спасибо большое за комментарий!
  
  Согласен, что User Story может быть более детальной, включая, например, информацию о том, что у пользователя больше 1000 заказов, но сама идея User Story и Acceptance Criteria, как раз и заключается в том, что история формулируется как обсуждаемая (Negotiable) и отражающая выгоду для пользователя (Valuable), а через критерии приемки мы её детализируем.
  
  Как часто среднестатистический заказчик приходит к аналитику с запросом: «мне нужна форма отзыва, где текст может быть длиной 7000 символов и можно прикрепить 15 фотографий»?
  Чаще всего это выглядит как: «нам нужна форма отзывов с возможностью загрузки фотографий», на основе этого мы формулируем примерно следующую пользовательскую историю: «Я, как покупатель, хочу иметь возможность оставить отзыв о товаре и приложить к нему фото, чтобы оставить образную связь для продавца.», а уже через критерии приемки мы напишем, что длина до 7000 символов и не больше 15 фото.
  
  В статье мы обсуждаем все-таки формат документирования требований User Story, при использовании Use Case все эти моменты будут учтены в основном и альтернативных сценариях, но это другой формат документирования требований и там будут свои особенности, про промты для Use Case будет отдельная статья.
  
  User Story написана так, как она формулировалась среднестатистическим заказчиком, владельцем продукта, аналитиком в тех коммерческих и учебных проектах в которых я участвовал. Если у вас есть примеры других подходов, буду рад их изучить!
  
  Про галлюцинации – полностью с вами согласен! Цитата про попугая из эпиграфа статьи именно об этом и говорит =) Я бы даже сказал, это в некотором смысле преимущество ИИ, так как даже если ему давать максимально четкие инструкции, он все равно остается не зашоренным.
  
  Про оверпромптинг – да, эти прилагательные были призваны максимально повысить качество выдаваемого результата, и, возможно, с ними получился некоторый перебор. А как бы вы видоизменили данный промт, могли бы написать свой пример?
  1. ASenchenko
    20.10.2025 11:44
    #28987082
    Давайте начнём с конца.
    
    Для данной конкретно задачи достаточно старта "Ты - старший бизнес-аналитик на проекте "...". Твоя задача:
    Всё. Модель поняла кто она и её не носит по разным кластерам за "экспертизой". То есть на наоборот, группирую всё в один вектор. Меня устраивает результат
    
    Второе
    
    Сама по себе сторя написана может быть в общем как угодно. Но если в ней не хватает данных - я обычно просто "подкладываю" некие общие требования, релевантные для всех кейсов этого модуля.
    
    Так у меня получается стабильнее.
    
    Ну и к базе статьи.
    
    Я в общем довольно часто использую LLM, но обычно лишь в качестве самопроверки "не забыл ли что-то". Редко как первоисточник
    
    EgorMaryushko Автор
    20.10.2025 11:44
    #28987748
    Андрей, все верно! Это тоже отмечено в начале статьи, ваш опыт Бизнес-архитектора делает ИИ-для вас мало эффективным в рутинных задачах, как и для меня, но для рядовых junior и middle аналитиков, это хороший инструмент для ускорения работы =)

Nik1947
20.10.2025 11:44
#28986816
https://chatgpt.com/share/68f62fc2-fb28-8003-af88-b9814c82e3ff gpt 5 pro
1. EgorMaryushko Автор
  20.10.2025 11:44
  #28987018
  Большое спасибо за тест!
  
  За основной и дополнительный промт gpt 5 pro сгенерировал 28 критериев приемки, после ознакомления могу сказать, что критерии от про версии, более детальные и качественные чем у бесплатной.

Nik1947
20.10.2025 11:44
#28986904
Ниже — краткий разбор и готовый улучшенный промпт, который можно копировать и использовать.

Недостатки исходного промпта
1. Не зафиксированы термины: какая дата фильтрации (создание/оплата/доставка), включительность границ, часовой пояс.
2. Не определён формат даты/времени и правила интерпретации дат без времени.
3. Не ограничена область: допускает добавление несвязанных функций (экспорт, доп. фильтры).
4. Нет явных дефолтов UI/UX (сортировка, пагинация, размеры страниц, состав полей строки заказа).
5. Нет конкретных бизнес‑ограничений (макс. длина периода, запрет будущих дат).
6. Слабая проработка ошибок: нет требований к точным текстам сообщений.
7. Не задана обязательная охватность по категориям (доступ/валидация/границы/результаты/ошибки/NFR).
8. Нет нефункциональных метрик (время ответа, таймауты, объём данных).
9. Не закреплены требования к безопасности (доступ только к своим заказам, поведение по прямым ссылкам).
10. Нет запрета на размытые слова («корректно», «должна»), что снижает проверяемость.
Более эффективный промпт (для этой задачи)
```
Роль: ты — системный и бизнес‑аналитик e‑commerce.

Цель: составь проверяемые критерии приемки для User Story:
«Я как покупатель интернет‑магазина хочу видеть историю своих заказов за заданный период, чтобы найти информацию о ранее заказанных товарах».

Определения и правила:
• Ключевая дата фильтрации: дата создания заказа.
• Границы периода: включительно.
• Часовой пояс: профиль пользователя; даты без времени интерпретировать как 00:00:00 для начала и 23:59:59 для конца.
• Формат дат: ДД.ММ.ГГГГ.
• Бизнес‑ограничения: макс. длина периода — 24 месяца; дата окончания не в будущем.

Область (scope):
• Только просмотр списка заказов за период и просмотр деталей заказа.
• Не добавляй функции вне области (нет экспорта/доп. фильтров/изменения заказов).

UI/UX дефолты:
• Сортировка по умолчанию: дата создания ↓.
• Пагинация: 20 записей на страницу.
• Поля строки заказа: номер, дата/время создания, статус, итоговая сумма, ссылка на детали.
• Поля деталей заказа: наименование, артикул (если есть), количество, цена за единицу, сумма по позиции.

Безопасность:
• Показывать только заказы текущего пользователя; чужие заказы по прямой ссылке — 403/404.

Ошибки (тексты обязательны):
• «Укажите период», «Неверный формат даты», «Дата начала не может быть позже даты окончания», «Дата окончания не может быть в будущем», «За период заказы не найдены», «Сервис истории недоступен, попробуйте позже».

Нефункциональные требования:
• ≤ 10 000 заказов в периоде — 95‑й перцентиль времени ответа ≤ 2 с; таймаут — 5 с.

Покрытие критериев (обязательно):
1) Доступ/безопасность
2) Форма и валидация дат
3) Границы и часовые пояса
4) Результаты/поля/сортировка/пагинация
5) Детали заказа
6) Пустые результаты
7) Отказоустойчивость/ошибки
8) НФ‑метрики

Формат каждого критерия:
• Строго «При условии..., когда..., то система...».
• Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.

Вывод:
• Таблица с колонками «номер» и «критерий приемки»; 22–30 уникальных критериев.
• Никаких разделов, примечаний и пояснений — только критерии.

Самопроверка перед выводом:
• Каждый критерий связан только с данной User Story.
• Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
```
1. ASenchenko
  20.10.2025 11:44
  #28987028
  Николай, добрый день.
  
  Вы подаёте ряд бизнес-правил и НФТ прямо в промпте. Неужто так делаете в реальности или это просто для примера ?
  
  Я обычно весь контекст держку сбоку и "подкладываю"
  1. Nik1947
    20.10.2025 11:44
    #28987220
    Добрый день!
    Это же не я, это результат запроса: "Найди недостатки промпта. Предложи более эффективный промпт для данной задачи."
    Да, пропустил контекст) Я в другом чате предложил Егору использовать еще один шаг: Просить ИИ проанализировать исходный промпт, найти в нем недостатки и предложить более совершенный. Здесь я привел результат, который выдал gpt 5 pro
    
    ASenchenko
    20.10.2025 11:44
    #28987228
    Ясно. Ссылку не смог открыть с телефона - не видел.
    
    Ну там понято, что GPT развернулся. На практике же такой шаблон даже не знаю поможет ли - чётко заточен под задачу.
    Но можно сохранить и творчески переписать :))))
1. EgorMaryushko Автор
  20.10.2025 11:44
  #28987142
  Приведенный более эффективный промт очень хорошо, и точно даст более качественные критерии приемки, но он уже более глубоко заточен именно под данную User Story, то есть время на его подготовку больше и требует более глубокого предварительного обдумывания.
  
  Выделил жирным элементы в промте, которые специфичны для конкретной User Story:
  
  Роль: ты — системный и бизнес‑аналитик e‑commerce. Цель: составь проверяемые критерии приемки для User Story: «Я как покупатель интернет‑магазина хочу видеть историю своих заказов за заданный период, чтобы найти информацию о ранее заказанных товарах». Определения и правила:• Ключевая дата фильтрации: дата создания заказа. • Границы периода: включительно. • Часовой пояс: профиль пользователя; даты без времени интерпретировать как 00:00:00 для начала и 23:59:59 для конца. • Формат дат: ДД.ММ.ГГГГ. • Бизнес‑ограничения: макс. длина периода — 24 месяца; дата окончания не в будущем.Область (scope):• Только просмотр списка заказов за период и просмотр деталей заказа.• Не добавляй функции вне области (нет экспорта/доп. фильтров/изменения заказов).UI/UX дефолты:• Сортировка по умолчанию: дата создания ↓. • Пагинация: 20 записей на страницу. • Поля строки заказа: номер, дата/время создания, статус, итоговая сумма, ссылка на детали. • Поля деталей заказа: наименование, артикул (если есть), количество, цена за единицу, сумма по позиции.Безопасность:• Показывать только заказы текущего пользователя; чужие заказы по прямой ссылке — 403/404.Ошибки (тексты обязательны):• «Укажите период», «Неверный формат даты», «Дата начала не может быть позже даты окончания», «Дата окончания не может быть в будущем», «За период заказы не найдены», «Сервис истории недоступен, попробуйте позже».Нефункциональные требования:• ≤ 10 000 заказов в периоде — 95‑й перцентиль времени ответа ≤ 2 с; таймаут — 5 с.Покрытие критериев (обязательно): 1) Доступ/безопасность 2) Форма и валидация дат 3) Границы и часовые пояса 4) Результаты/поля/сортировка/пагинация 5)Детали заказа6) Пустые результаты 7) Отказоустойчивость/ошибки 8) НФ‑метрики Формат каждого критерия: • Строго «При условии..., когда..., то система...». • Без слов «должна/корректно»; только наблюдаемое поведение и точные значения. Вывод: • Таблица с колонками «номер» и «критерий приемки»; 22–30 уникальных критериев. • Никаких разделов, примечаний и пояснений — только критерии. Самопроверка перед выводом: • Каждый критерий связан только с данной User Story. • Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
  
  Если делать его более универсальным для массового применения, то изменил бы его следующим образом:
  
  Роль: ты — системный и бизнес‑аналитик [ОТРАСЛЬ].
  
  Цель: составь проверяемые критерии приемки для User Story:
  
  [ВАША USER STORY]
  
  Определения и правила:
  
  [ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
  
  Область (scope):
  
  Не добавляй функции вне области User Story
  
  UI/UX дефолты:
  
  [ОПЦИОНАЛЬНО ЕСЛИ НЕТ КОНКРЕТНЫХ ТРЕБОВАНИЙ УБРАТЬ]
  
  Покрытие критериев (обязательно):
  
  Доступ/безопасность
  
  Форма и валидация вводимых данных
  
  Результаты/поля/сортировка/пагинация
  
  Пустые результаты
  
  Отказоустойчивость/ошибки
  
  НФ‑метрики
  
  Формат каждого критерия:
  
  Строго «При условии..., когда..., то система...».
  
  Без слов «должна/корректно»; только наблюдаемое поведение и точные значения.
  
  Вывод:
  
  Таблица с колонками «номер» и «критерий приемки»; 20–30 уникальных критериев.
  
  Никаких разделов, примечаний и пояснений — только критерии.
  
  Самопроверка перед выводом:
  
  Каждый критерий связан только с данной User Story.
  
  Нет дубликатов и размытых формулировок; при выявлении — исправь и пересчитай нумерацию.
  
  Самый главный вопрос где провести границу между временем подготовки качественного и детального промта и временем на последующее ревью его результатов. Ведь даже в рамках этой конкретной задачи по подготовке критериев приемки в зависимости от опыта специалиста она будет сильно плавать.
  
  Я склоняюсь к тому что лучше быстрее получить результат и провести его ревью и корректировку, чем уделять существенное время детализации промта, при том что не зависимо от того детализируешь ты промт или проводишь ревью, если ты забыл или ни когда не сталкивался с проблемой формата ввода даты, то ты все равно пропустишь это требование не важно в промте или при ревью критериев =)

ИИ-инструменты бизнес и системного аналитика: промт для создания критериев приёмки User Story -1

Наблюдения:

Шаблон основного промта:

Шаблон дополнительного промта:

Инструкция по применению:

Применимость:

Выводы:

Комментарии (11)

ASenchenko

EgorMaryushko Автор

ASenchenko

EgorMaryushko Автор

Nik1947

EgorMaryushko Автор

Nik1947

ASenchenko

Nik1947

ASenchenko

EgorMaryushko Автор