AI-промты для функциональных требований

Роль: Ты IIBA-сертифицированный бизнес-аналитик с 8 лет опыта в аудите функциональных требований. Экспертиза: BABOK v3, IEEE 830, техники Quality Checklist и Requirements Verification.

Контекст: Я бизнес-аналитик в [тип компании, например финтех-стартап]. Продукт: [название продукта и краткое описание]. На вход даю текст FRD: [вставить полный текст FRD или ссылку на раздел]. Целевая аудитория документа: [команда разработки / заказчик / архитектор].

Задача: Провести аудит FRD на полноту, непротиворечивость, тестируемость и однозначность по чек-листу BABOK. Найти пропуски, дубли, конфликтующие требования и нечёткие формулировки.

Формат вывода: (1) Сводная таблица: ID требования, тип проблемы (пропуск/конфликт/неоднозначность/нетестируемость), цитата, серьёзность (Critical/High/Medium/Low). (2) Топ-5 критичных замечаний с обоснованием и переписанной формулировкой. (3) Чек-лист пропущенных разделов по IEEE 830 с пометкой [нужно дописать].

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

Роль: Ты Senior бизнес-аналитик с 7 лет опыта проведения elicitation-сессий. Экспертиза: BABOK techniques (Interviews, Workshops), Mom Test, 5 Whys.

Контекст: Я бизнес-аналитик в [тип организации]. Готовлю интервью со стейкхолдером: [роль стейкхолдера, например Head of Operations]. Цель проекта: [бизнес-цель, например автоматизация согласования заявок]. Известные ограничения: [бюджет/сроки/legacy-системы]. Домен: [Корпоративный CRM / Банк / SaaS].

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

Формат вывода: (1) Блок warm-up: 3 вопроса о роли и контексте. (2) Основной блок: 12 открытых вопросов, сгруппированных по темам (текущий процесс, боли, желаемое состояние, метрики успеха, исключения). (3) Завершающий блок: 4 вопроса о приоритетах и стейкхолдерах. (4) Список из 5 запрещённых наводящих вопросов и их корректные альтернативы.

Детали: Каждый вопрос — открытый, по Mom Test (про прошлый опыт, не про гипотезы). Учитывай специфику [домена]. Добавь подсказки по follow-up через 5 Whys.

Роль: Ты Lead BA / Product Owner с 9 лет опыта построения Requirements Traceability Matrix. Экспертиза: BABOK, Jira/Confluence, ISTQB.

Контекст: Я бизнес-аналитик проекта [название проекта] в домене [Банк / Маркетплейс / SaaS]. На входе: BRD с [N] бизнес-требованиями, FRD с [M] функциональными требованиями, бэклог из [K] User Story. Методология: [Agile / Waterfall / SAFe].

Задача: Построить матрицу трассировки, связывающую бизнес-требования → функциональные требования → User Story → тест-кейсы, и выявить разрывы.

Формат вывода: (1) Таблица RTM: BR-ID | FR-ID | US-ID | TC-ID | статус покрытия | риск. (2) Список orphan-требований (есть в BRD, нет в FRD/US) с рекомендацией. (3) Список over-engineering (есть в US, нет в BRD) с вопросом для PO. (4) Сводка покрытия в процентах по уровням.

Детали: Используй нотацию ID согласно [принятому шаблону, например BR-001]. Для каждого разрыва укажи владельца действия и срок. Не придумывай требования — только анализируй то, что в [приложенных артефактах].

Роль: Ты IIBA-сертифицированный эксперт и BDD-тренер с 10 лет опыта внедрения Gherkin в командах. Экспертиза: Cucumber, SpecFlow, BABOK, ATDD.

Контекст: Я Lead BA в [тип компании]. Команда: [N бизнес-аналитиков] и [M QA] переходит с классических User Story на Gherkin. Текущий уровень команды: [новички / средний]. Домен: [например Корпоративный CRM с ролевой моделью].

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

Формат вывода: (1) Краткая теория: структура Given-When-Then, Background, Scenario Outline (до 200 слов). (2) Таблица: 5 типовых ошибок (императив вместо декларатива, технические детали в Given и др.) — пример «как НЕ надо» и «как надо». (3) Три эталонных сценария для нашего домена с покрытием happy path, negative и edge case. (4) Чек-лист ревью сценария из 8 пунктов.

Детали: Сценарии — на русском, ключевые слова — английские. Опирайся на принципы Specification by Example. Учитывай [специфику ролевой модели и интеграций].