AI-промты для системной документации

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

Контекст: Я системный аналитик в [тип организации — банк, телеком, ритейл]. Мне передали черновик ТЗ на [название системы или модуля] объёмом [кол-во страниц]. Целевой стандарт: [ГОСТ 34 или SRS IEEE 830]. Срок приёмки заказчиком: [дата].

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

Формат вывода: (1) Таблица 'Раздел — Требование стандарта — Статус (OK/частично/отсутствует) — Комментарий'. (2) Топ-10 критичных дефектов с цитатой и предложенной переформулировкой. (3) Чек-лист готовности на 15 пунктов со статусом. (4) Итоговая оценка зрелости документа по шкале 1–5 с обоснованием.

Детали: Опирайся на структуру разделов ГОСТ 34.602 и атрибуты качества IEEE 830 (полнота, непротиворечивость, верифицируемость). Не придумывай фактов, отсутствующих в документе, — помечай как 'требует уточнения у [роль стейкхолдера]'. Избегай общих советов в стиле 'улучшить формулировку'.

Роль: Ты Senior системный аналитик с 8 лет опыта сопровождения требований в связке с QA. Экспертиза: RTM (Requirements Traceability Matrix), Jira/Confluence, Zephyr, SRS IEEE 830.

Контекст: Я аналитик в команде [тип продукта — микросервисная платформа, мобильное приложение]. Есть утверждённый [SRS или User Stories] с [кол-во требований] требованиями и набор тест-кейсов в [инструмент — Zephyr, TestRail]. Нужно перед релизом [номер релиза] закрыть пробелы в покрытии.

Задача: Построить матрицу трассировки требование → тест-кейс → дефект и выявить непокрытые требования.

Формат вывода: (1) Таблица RTM с колонками 'ID требования | Формулировка | Приоритет | ID тест-кейса | Тип теста | Статус покрытия | Связанные дефекты'. (2) Список требований без тестов с предложенными сценариями (позитив/негатив/граничные). (3) Отчёт в 5 буллетов: процент покрытия, риски, рекомендации SA команде QA.

Детали: Используй нотацию MoSCoW для приоритетов. Для NFR добавляй тип теста (нагрузочный, security, usability). Не дублируй тест-кейсы — если один кейс покрывает несколько требований, указывай все связи. Избегай формулировок 'проверить работу системы' — конкретизируй ожидаемый результат.

Роль: Ты Solution Architect с 12 лет опыта в крупных интеграционных проектах. Экспертиза: DDD (ubiquitous language), ArchiMate, ведение корпоративного глоссария, терминологический контроль.

Контекст: Я аналитик на проекте [название — внедрение CRM, замена legacy-биллинга] в [отрасль]. Собрано [кол-во терминов] терминов из [источники — интервью, legacy-документация, ТЗ]. Домен: [описание предметной области]. Проблема: разные команды используют синонимы и конфликтующие определения.

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

Формат вывода: (1) Таблица 'Термин | Текущее определение | Источник | Проблема (дубль/конфликт/неполнота) | Каноническое определение | Связанные термины'. (2) Граф связей ключевых 10 терминов в формате Mermaid. (3) Список из 5 правил ведения глоссария для команды. (4) Риски для интеграций, если неоднозначность не устранить.

Детали: Применяй принципы DDD и bounded context — один термин может иметь разные значения в разных контекстах, фиксируй это явно. Не объединяй термины из разных bounded context без пометки. Избегай определений через сам термин ('клиент — это клиент системы').

Роль: Ты Lead системный аналитик с 10 лет опыта и 3 года управления командой из 6–8 SA. Экспертиза: менторинг, разработка внутренних стандартов, шаблоны ТЗ и SRS, BPMN 2.0, C4-модель.

Контекст: Я тимлид аналитиков в [тип компании — продуктовая, аутсорс, интегратор]. В команду выходит [кол-во] junior/middle аналитиков. Стек артефактов: [ТЗ по ГОСТ 34, User Stories, C4-диаграммы]. Используемые инструменты: [Confluence, draw.io, PlantUML]. Срок онбординга: [кол-во недель].

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

Формат вывода: (1) Таблица плана по неделям: 'Неделя | Тема | Материалы для изучения | Практическое задание | Критерий готовности | Ментор'. (2) Чек-лист самопроверки нового аналитика из 12 пунктов. (3) Список типовых ошибок новичков в документации и как их предотвратить. (4) Шаблон финального ассесмента с разбором учебного кейса.

Детали: Опирайся на BABOK и внутренние стандарты. Каждое задание привязывай к реальному артефакту команды (User Story, C4-контекст, Sequence-диаграмма). Избегай лекционного формата — минимум 70% времени практика с ревью ментора.