Требования и ТЗ с ИИ: шесть промптов, которые работают
Это практикум, а не рассуждение: ниже шесть формулировок, которые я использую в работе с постановками. У каждой — что реально получается на выходе и что приходится перечитывать руками.
Почему требования — идеальная задача для ИИ
Требования — это работа с уже существующими смыслами: расшифровать пожелание, разложить сценарии, отловить двусмысленность, договориться о границах. Модель здесь не придумывает продукт, а перерабатывает то, что вы ей дали. Именно поэтому участок окупается быстрее остальных.
Условие одно: материалы должны быть на входе. Если дать пустой запрос «напиши требования к фиче», получите правдоподобный документ не о вашем продукте — и это худший из возможных результатов, потому что он выглядит прилично.
Правило, на котором держится всё остальное
В каждой формулировке ниже есть требование указывать источник. Это не формальность: ссылка на файл и абзац превращает ошибки модели из невидимых в очевидные. Вы сразу видите, где кончаются материалы и начинаются догадки.
1. Черновик требований
Задача: получить скелет документа, который можно критиковать, вместо пустого листа.
Ты — системный аналитик. Ниже материалы по фиче: переписка, заметки со встреч, старое ТЗ. Собери черновик требований: цель, пользователи и роли, сценарии, состояния (пустое, загрузка, ошибка, нет прав, лимит), ограничения, критерии приёмки. На каждое утверждение укажи источник — файл и абзац. Если данных для раздела не хватает — напиши «нет данных» и перечисли, что нужно выяснить. Не добавляй требований, которых нет в материалах.
Что получается: структура на 2–3 страницы и, что важнее, список пробелов. Разделы с пометкой «нет данных» — это готовый список вопросов к стейкхолдеру, с которым можно идти на встречу.
Что править руками: границы и приоритеты. Формулировки критериев приёмки почти всегда слишком общие — их надо переписать под то, как вы реально принимаете работу.
2. Поиск двусмысленностей
Самая недооценённая функция. Модель вытаскивает места, из-за которых потом появляется «мы думали, что имелось в виду другое».
Ты — разработчик этой системы. Найди в описании места, которые можно реализовать двумя разными способами. Для каждого: две трактовки, чем они отличаются для пользователя, какой вопрос задать до начала работы. Не предлагай решений — только вопросы.
Что получается: десяток вопросов, часть из которых вы бы задали на тестировании, а не до разработки. Формулировка «не предлагай решений» здесь принципиальна: без неё модель начнёт проектировать за вас и вы потеряете список вопросов.
Что править руками: отобрать действительно важные. Из пятнадцати вопросов значимых обычно пять, остальные — следствие неполных материалов.
3. Проверка полноты по состояниям
Задача: пройтись по веткам, которые обычно забывают.
Прогони описание по чек-листу: пустое состояние, загрузка, ошибка, нет прав, лимит, отмена, частичный успех, повторный вход. По каждому пункту скажи: описан, не описан, описан неоднозначно. Где не описан — сформулируй вопрос к заказчику.
Что получается: таблица состояний с тремя статусами и вопросами. Это самый быстрый способ найти дыры в логике, потому что чек-лист не зависит от того, насколько подробно описана фича.
Что править руками: добавить состояния конкретного домена — например, ожидание внешней системы или частичный возврат. Типовой список их не знает.
4. Поиск противоречий в материалах
Задача: поймать конфликт между старым ТЗ и новой перепиской. Аналитик при чтении пропускает такие места регулярно, потому что читает последовательно.
Сравни материалы между собой и найди противоречия: что описано по-разному в разных документах, что противоречит более новым сообщениям, какие решения отменяют друг друга. Для каждого противоречия покажи два источника и предложи вопрос, который закрывает расхождение.
Что получается: список расхождений с двумя ссылками на каждое. Отдельная польза — вы перестаёте спорить о том, «что было решено», опираясь на память.
Что править руками: решить, какая версия актуальна. Модель показывает расхождение, но не знает, какая договорённость победила.
5. Техническое задание из подтверждённой аналитики
Собирается только после того, как аналитика согласована. На неподтверждённом описании этот промпт даёт красивое ТЗ не той задачи.
На основе согласованной аналитики собери техническое задание: контекст, границы (что входит и что не входит), функциональные требования, нефункциональные, зависимости, критерии приёмки. Ничего не добавляй от себя: если требования нет в аналитике — не пиши его.
Что получается: документ, который можно отдавать в разработку, с явным разделом «что не входит» — он экономит больше всего споров.
Что править руками: зависимости и нефункциональные требования. Модель почти всегда занижает нагрузку, сроки хранения и требования к доступности.
6. User story и критерии приёмки
Задача: разложить согласованные сценарии на истории, с которыми удобно работать разработке.
Разложи сценарии на user story в формате «Как роль, я хочу действие, чтобы результат». К каждой — критерии приёмки в формате «дано — когда — тогда», включая негативные сценарии. Не объединяй несколько действий в одну историю.
Что получается: набор историй с проверяемыми критериями. Негативные сценарии — то, что обычно забывается: отмена, ошибка, недостаток прав.
Что править руками: разрезание историй. «Не объединяй несколько действий» модель понимает по-разному, крупные истории всё равно придётся делить.
Чего в этих промптах нет
- Просьбы «придумай требования». Без материалов это генерация выдуманного продукта.
- Доверия к формулировкам. Любая фраза, которая уйдёт в разработку, читается человеком — иначе ответственности нет ни у кого.
- Расчёта на то, что модель знает домен. Отраслевые ограничения, юридические требования и правила доступности описываются отдельно.
Критерии приёмки — они уходят в тестирование. Раздел «что не входит» — он уходит в споры с заказчиком. Всё, что помечено источником, к которому вы не заглядывали. И любое требование, которого не было в ваших материалах, — такие всегда находятся при внимательном чтении.
Вопросы про эти промпты
Можно ли поручить ИИ написать требования целиком?
Нет. Модель собирает черновик по вашим материалам и находит неоднозначности, но границы, приоритеты и формулировки, за которые вы отвечаете, остаются за аналитиком.
Что делать, если материалов по фиче почти нет?
Не генерировать требования, а попросить модель собрать список вопросов к стейкхолдеру. Требования без материалов модель просто придумает — и вы получите приличный документ не о том продукте.
Почему в промптах везде требуется источник?
Ссылка на файл и абзац делает ошибки видимыми: сразу понятно, где заканчиваются материалы и начинаются догадки. Без этого различить их почти невозможно.
Сколько времени это экономит?
Основная экономия — на старте: вместо пустого листа сразу есть черновик, который можно критиковать, и список вопросов. Дальше время уходит на содержательную работу, а не на набор текста.
Как эти промпты встраиваются в общий маршрут команды — в статье «ИИ в аналитике и UXUI: пайплайн от требований до прототипа». А из чего состоит агент, который их выполняет, — в «ИИ-агент за вечер».
Показываю командам, как встроить эти формулировки в рабочий процесс, а не в переписку с чатом. Телеграм: @darkclaus