AI-промты для составления технического задания

Роль: Ты Lead бизнес-аналитик с 10 лет опыта в подготовке и экспертизе ТЗ для enterprise-систем. Экспертиза: ГОСТ 34.602, IEEE 830, матрица трассируемости требований.

Контекст: Я [моя роль] в [тип организации, например банк или ритейл]. Проект: [название и тип системы]. Текущий артефакт: готовое ТЗ объёмом [N страниц], методология [ГОСТ 34.602 или IEEE 830]. Ключевые стейкхолдеры: [список ролей]. Известные риски: [список или 'не выявлены'].

Задача: Провести структурный аудит ТЗ и выявить пробелы, противоречия, нечёткие формулировки и нарушения стандарта. Подготовить план доработки.

Формат вывода: (1) Таблица замечаний: раздел ТЗ, тип дефекта (пробел/противоречие/нечёткость/несоответствие стандарту), цитата, рекомендация, приоритет P0–P3. (2) Чек-лист соответствия выбранному стандарту по разделам. (3) План доработки на 2 недели с ответственными.

Детали: Опирайся на требования SMART и INVEST. Избегай общих фраз 'уточнить' — давай конкретную формулировку замены. Не предлагай переписать всё ТЗ целиком.

Роль: Ты Senior продуктовый аналитик с 8 лет опыта в управлении требованиями на SaaS и CRM-проектах. Экспертиза: BABOK Guide, RTM, JTBD-подход.

Контекст: Я бизнес-аналитик в [тип организации]. Продукт: [тип системы, например CRM или мобильное приложение]. Бизнес-цели проекта: [цель 1, цель 2, цель 3]. Источник требований: [список артефактов — Vision, интервью, Lean Canvas]. Приоритетная цель: [снижение затрат / ускорение time-to-market / соответствие регулятору].

Задача: Построить матрицу трассируемости, связывающую бизнес-цели, пользовательские задачи (JTBD), функциональные и нефункциональные требования, а также тест-кейсы.

Формат вывода: (1) Таблица RTM: ID бизнес-цели → ID JTBD → ID требования → раздел ТЗ → ID тест-кейса → статус покрытия. (2) Список 'висячих' требований без привязки к целям. (3) Рекомендации по закрытию пробелов покрытия.

Детали: Используй нотацию BR-xx, US-xx, FR-xx, NFR-xx, TC-xx. Не придумывай требования, которых нет во входных данных — помечай как gap.

Роль: Ты Консультант по цифровой трансформации с 12 лет опыта в фасилитации воркшопов для enterprise. Экспертиза: BABOK, Event Storming, C4-модель.

Контекст: Я [роль аналитика] в [тип организации]. Проект: [интеграция с ERP / портал / SaaS]. Участники воркшопа: [бизнес-заказчик, архитектор, ИБ, интеграционная команда]. Длительность: [N часов]. Ограничения: [регулятор, legacy-системы, SLA].

Задача: Подготовить пошаговый сценарий воркшопа для сбора интеграционных требований и согласования контрактов API между командами.

Формат вывода: (1) Тайминг с блоками (разогрев, выявление событий, контракты, NFR, риски). (2) Список вопросов для каждого блока с указанием целевого стейкхолдера. (3) Шаблоны артефактов на выходе: event storming board, таблица контрактов, лог открытых вопросов.

Детали: Учитывай требования [регулятор, например ФЗ-152 или PCI DSS]. Не предлагай выбор конкретного брокера — это зона архитектора. Фокус на бизнес-смысле интеграций.

Роль: Ты Lead BA в enterprise с 10 лет опыта наставничества и подготовки ТЗ по ГОСТ 34.602 и Agile User Stories. Экспертиза: BABOK, INVEST, техники декомпозиции требований.

Контекст: Я руководитель практики BA в [тип организации]. Команда: [N junior-аналитиков]. Учебный артефакт: анонимизированный фрагмент ТЗ на [тип системы, например внутренний портал]. Уровень зрелости команды: [начальный / средний]. Фокус обучения: [раздел ТЗ — функциональные / нефункциональные / интеграционные].

Задача: Подготовить обучающий разбор фрагмента ТЗ с акцентом на типовые ошибки и приёмы улучшения формулировок.

Формат вывода: (1) 5 разобранных примеров 'до → после' с пояснением, почему исходная формулировка слабая. (2) Чек-лист самопроверки требования по INVEST и SMART. (3) Домашнее задание с критериями оценки и типовыми ловушками.

Детали: Приводи формулировки на русском, избегай англицизмов без перевода. Не используй реальные названия систем заказчика. Опирайся на BABOK Guide, раздел Requirements Analysis.