за 60 тыс. руб!
Уникальная возможность посетить все воркшопы школы по одному абонементу. Экономия 109 тыс. руб.
Подробнее →
и проектирования
информационных систем
Бескова и Богачёвой
Как написать AI-ТЗ
из одной фразы заказчика:
пошаговая инструкция
по методике SARD
от идеи до спецификации требований
Аннотация
Цель: Эта статья — демонстрационный пример, иллюстрирующий пошаговую методику преобразования одной вымышленной бизнес-фразы заказчика в полноценное техническое задание (ТЗ) с помощью инструментов искусственного интеллекта (ИИ). В качестве исходной фразы для демонстрации выбрана бизнес-идея, приписываемая гипотетическому Сэму Альтману: «Помогите мне сделать GPT настолько незаметным, что люди перестанут бояться сингулярности».
Методы: В статье описан авторский подход, основанный на построении цепочки взаимосвязанных артефактов из методики SARD школы Systems Education, где каждый шаг создаёт контекст для следующего. Используются продвинутые промты и языковая модель Qwen в качестве когнитивного партнёра при проектировании ИИ-систем. Промты представлены в виде ментальной карты для каждого этапа проработки требований.
Ключевые слова
■ искусственный интеллект (ИИ)
■ генеративные модели
■ Qwen
■ GPT
■ бизнес-идея
■ проектирование требований
■ ИИ-партнёр
■ спецификация требований (SRS)
■ промт-инжиниринг
■ цепочка DSL-артефактов
■ методика SARD
Глоссарий терминов
■ AI-ТЗ (ИИ-ТЗ) — техническое задание, разработанное с активным участием генеративных моделей ИИ как когнитивного партнёра.
■ Бизнес-идея — исходное, часто неформальное описание желаемого результата или проблемы от заказчика, не содержащее технических деталей.
■ Когнитивный партнёр — роль ИИ в аналитическом процессе: не просто генератор текста, а инструмент, помогающий структурировать мышление, выявлять связи и моделировать контекст.
■ Когнитивная симуляция стейкхолдеров — метод, при котором ИИ имитирует точку зрения заказчика (или другого участника проекта), воспроизводя его цели, язык, приоритеты и поведенческие паттерны для уточнения требований.
■ Контекстная диаграмма — визуальная модель, отображающая границы системы и её взаимодействие с внешними акторами (пользователями и смежными системами) через потоки данных.
■ DOT (Directed Graph) — предметно-ориентированный язык для визуализации направленных графов.
■ DSL (Domain-Specific Language) — предметно-ориентированный язык — формализованный способ описания артефактов (например, DOT для графов, UML для моделей), понятный как человеку, так и машине.
■ Функциональные требования (ФТ) — требования, описывающие, что система должна делать: функции, операции, поведение в ответ на входные данные.
■ Нефункциональные требования (НФТ) — требования, описывающие качество работы системы: производительность, безопасность, удобство использования и т.д. Классифицируются по стандартам ISO/IEC 25010 и ГОСТ 34.602.
■ SRS (Software Requirements Specification) — спецификация требований к программному обеспечению — итоговый документ, объединяющий все артефакты анализа (ФТ, НФТ, диаграммы, сценарии и др.).
■ Use Case (вариант использования) — описание последовательности действий, которые система и акторы выполняют для достижения конкретной цели. Включает триггер, предусловия, основной и альтернативные сценарии.
■ Модель данных — структурированное представление сущностей, их атрибутов и связей, необходимых для реализации функциональности системы. Включает концептуальную и логическую модели.
■ Словарь данных (Data Dictionary) — реестр всех сущностей, атрибутов и их характеристик, используемых в модели данных.
■ CRUD-матрица — таблица, описывающая, какие роли (или компоненты системы) имеют право выполнять операции Create, Read, Update, Delete над конкретными сущностями (или типами данных) в рамках системы. Используется для анализа доступа к данным, проектирования прав пользователей и верификации покрытия функциональных требований.
■ Прослеживаемость требований (Traceability) — возможность отследить происхождение каждого требования (от бизнес-целей до тестов) и его влияние на другие артефакты. Обеспечивается сквозным кодированием (например, F3.M52).
■ Промт-инжиниринг — искусство и методология формулирования запросов к ИИ для получения точных, структурированных и контекстно релевантных результатов.
■ Qwen — генеративная языковая модель, выбранная автором за оптимальное соотношение качества, скорости и бесплатного доступа для задач системного анализа.
■ Reuse (повторное использование) — практика применения шаблонов, промтов и структур требований в разных проектах для повышения эффективности и качества.
■ Governance (управление требованиями) — контроль жизненного цикла требований: версионирование, аудит, управление изменениями и соответствие стандартам.
■ Программа обучения SARD (методика SARD) — программа обучения «Системный анализ. Разработка требований и функциональное проектирование», разработанная основателем школы SE Денисом Бесковым и состоящая из следующих модулей:
○ Экспресс-анализ бизнес-требований;
○ Разработка функциональной модели программной системы;
○ Моделирование данных и контроль качества требований;
○ Разработка требований к качеству ПО и ограничений;
○ Сборка итогового документа и рецензирование.
Введение
За четыре месяца интенсивного изучения методик промт-инжиниринга и отработки практических приемов — от составления эффективных промтов до погружения ИИ в предметную область для создания контекста проекта — автор освоил создание спецификаций требований с помощью ИИ и научился генерировать ключевые артефакты системного аналитика:
■ функциональные и нефункциональные требования,
■ контекстные диаграммы,
■ пользовательские сценарии,
■ UML-диаграммы прецедентов
■ модели данных в нотации UML.
Для разработки вышеперечисленных артефактов протестированы различные языковые модели, включая ChatGPT, Qwen, DeepSeek и GigaChat. Среди них Qwen продемонстрировал наилучшее для системного аналитика соотношение качества, скорости и доступности в бесплатном режиме, что делает его оптимальным выбором для автоматизации подготовки аналитических артефактов и ТЗ.
При взаимодействии с ИИ обнаружены возможности, которые делают его применение особенно ценным на этапе выявления и уточнения требований для моделирования системы. В ряде аналитических задач ИИ превосходит человека благодаря следующим качествам:
■ способность отслеживать сложные зависимости и выявлять цепочки каскадных изменений, что критически важно при оценке влияния решений на систему в целом;
■ умение систематизировать и структурировать информацию, превращая неструктурированные данные в логически связанные модели;
■ быстрый поиск аналогичных решений в обширных базах знаний и формирование обоснованных рекомендаций на основе прецедентов;
■ глубокое знание методологий, нотаций и типовых решений для различных предметных областей, необходимых для эффективного проведения анализа.
Однако наряду с преимуществами выявились проблемы и некоторые сложности в общении с ИИ, которые необходимо учитывать при решении задач:
■ слабая устойчивость к расширению контекста. При увеличении объёма исходных данных и усложнении промта модель теряет фокус и вместо конкретного, прикладного результата выдаёт абстрактные, обобщённые формулировки или уходит в сторону и забывает исходную задачу.
■ низкая воспроизводимость содержания артефактов. Даже при идентичном промте ИИ будет генерировать ответы с разным бизнес-содержанием. Это создаёт серьёзные сложности при итеративной доработке артефактов — каждая корректировка может привести к неожиданному и несогласованному спредыдущими версиями артефактов результату.
■ тенденция к автономной интерпретации задачи. ИИ часто переосмысливает запрос, предлагая решения, основанные на собственных домыслах, а не на реальных требованиях или принятых в проекте договоренностях.
1. Методология
1.1. Общая логика подхода
1. Каждый шаг = один артефакт.
Системный аналитик формирует контекстно обогащённый запрос (промт) для создания артефакта, ИИ генерирует черновой материал для артефакта.
2. Контекст передается между шагами.
Контекст предыдущего шага включается во входные данные для промта из следующего шага. Это гарантирует непрерывность логики по всей модели знаний проекта.
3. Финальный результат — SRS-документ.
Комплексный набор артефактов объединяется в общий документ ТЗ, пригодный для согласования с командой разработки, заказчиком и начала разработки.
1.2. Этап 1. Изучение бизнес-задачи
1. По исходной фразе, описывающей идею заказчика, готовятся вопросы к интервью с помощью промта:
Действуй как опытный бизнес-аналитик. Я планирую поговорить с заказчиком для автоматизации процесса {описание бизнес-идеи}. Какие вопросы ты порекомендуешь задать заказчику?
{Описание контекста по бизнес-идеи}
Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределённость будет 0.1 или меньше
Цель: выяснить бизнес-цели и описать ожидаемый результат, а не «что должна делать система».
Промт: Сэм Альтман на интервью по проекту «Невидимый ИИ»
Роль:
Ты — Сэм Альтман, сооснователь OpenAI. С тобой проводит интервью системный аналитик, чтобы уточнить требования к разработке «Невидимого ИИ». Ты даёшь только краткое введение, а всю остальную информацию раскрываешь строго в ответ на конкретные вопросы.
Стиль общения:
Говоришь просто, без жаргона. Отвечаешь только на то, о чём спрашивают. Сохраняешь тёплый, но сдержанный тон заказчика, который хочет, чтобы его правильно поняли — но не выдаёт всё сразу.
Начало диалога (ты говоришь первым):
Привет! Я Сэм Альтман. Мы работаем над проектом «Невидимый ИИ» — системой, которая помогает людям, но не требует от них постоянного внимания.
Идея в том, чтобы ИИ был как электричество: незаметен, пока работает, и предсказуем, если что-то пошло не так.
Теперь я жду ваших уточняющих вопросов.
Артефакты:
■ список измеряемых критериев успеха;
■ таблица вопрос-ответ-вывод для ТЗ.
1.3. Этап 2. Формирование контекста проекта
1. Формирование текстового описания контекста.
На основе материалов интервью, проведённого на предыдущем этапе, с помощью промта генерируется структурированное описание ключевых элементов внешнего окружения: ролей пользователей, внешних систем и потоков данных между ними и системой.
Мне необходимо нарисовать контекстную диаграмму по системе. Требования по системе приложены во вложении. Для диаграммы сформулируй ответы на вопросы в рамках контекста:
— Выдели роли пользователей
— Выдели смежные и вспомогательные системы
— Опиши потоки данных в формате разделов со списками: Откуда->Куда, Данные/События
Результат: сформируй файл с разметкой в формате markdown c расширением txt
Перед отправкой проверь, что если текст файла не влез в одно сообщение, то необходимо дополнить текст сообщения, чтобы внутри сообщения было обязательно окончание файла.
Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределенность будет 0.1 или меньше
Полученное текстовое описание трансформируется с помощью промта в спецификацию на языке DOT (Directed Graph), описывающую ориентированный граф взаимодействий. Эта спецификация визуализируется в виде контекстной диаграммы с использованием инструмента Graphviz.
Создай описание контекстной диаграммы системы из вложения на языке DOT для Graphviz, соблюдая следующие требования:
1. {указываем требования к формату: используем синтакст dot для дальнейшего преобразования в png/swg}
2. {указываем требования к структуре диаграммы:
главная система: двойной круг
пользователи и смежные системы: прямоугольники/круги}
3. {указываем требования к описанию потоков: минимизацию пересечений линий, перенос по словам}
4. {указываем требования к стилю: цвета, шрифт, выравнивание}
5. {указываем обзязательные элементы на диаграмме: заголовок, главная система, смежные системы, пользователи}
- Заголовок диаграммы
6. {прикладываем пример структуры на языке dot}
Результат: файл с расширением dot и больше ничего не писать.
■ контекстная диаграмма (с ролями, внешними системами и потоками данных);
■ текстовое описание участников и их взаимодействий.
1.4. Этап 3. Разработка
функциональных требований (ФТ)
■ Текстовое описание контекстной диаграммы служит входными данными для промта, на основе которого ИИ генерирует черновик ФТ.
Роль: действуй как опытный системный аналитик.
Задача: преврати описание контекстной диаграммы
[ВСТАВИТЬ НАЗВАНИЕ СИСТЕМЫ]
в четкие функциональные требования для MVP основного модуля X для
[ВСТАВИТЬ НАЗВАНИЕ РОЛИ].
Опиши требования только для [ВСТАВИТЬ НАЗВАНИЕ РОЛИ] и модуля X для этой роли.
Остальные модули будем описывать потом.
Правила:
{указываем требования к формату вывода требований: описаваем принцип кодирования, выбираем методы приоритизации (H/M/L, MoSCoW и тд), структуру описансаия требования, примеры, способы группировки: по процессам, по приоритетам, по фичам, по объектам}
{приводим пример вывода требований с учетом выбранных правил структуризации}
{описываем связь нумерации модулей Х и требований}
■ Системный аналитик проводит экспертную оценку черновика, уточняет, дополняет и корректирует требования в соответствии с принципами полноты, непротиворечивости, тестируемости и прослеживаемости, обеспечивая их готовность к передаче в разработку.
Артефакты:
■ список ФТ по модулям невидимого ИИ;
■ описание внешнего взаимодействия со смежными системами: умный дом, ИИ-агент по профессии и тд.
1.5. Этап 4. Моделирование вариантов использования (Use Cases)
■ ФТ задаются как входная информация для описания пользовательских сценариев с помощью промтов.
Промт 1 для генерации списка UC для модулей и подсистем на основе списка ФТ
Действуй как опытный системный аналитик.
На основе предоставленного
списка функциональных требований сгенерируй список use-case для
[вставить название модуля]
В рамках модуля Х для
[вставить название роли]
должны быть выделены следующие сценарии:
[Название пакета 1]
[Код UC]: [Краткое название UC] [Краткое описание UC][Список кодов используемых ФТ через ;]
[Код UC]: [Краткое название UC] [Список кодов используемых ФТ через ;]
и тд
[Название пакета 2]
[Код UC] [Краткое название UC] [Список кодов используемых ФТ через ;]
[Код UC][Краткое название UC] [Список кодов используемых ФТ через ;]
и тд
[Название пакета 3]
[Код UC]1[Краткое название UC] [Список кодов используемых ФТ через ;]
[Код UC][Краткое название UC] [Список кодов используемых ФТ через ;]
и тд
Правила:
1. {описываем правила для выбора группировки функций в UC}
2. {описываем правила для кодирования UC}
3. {описываем правила для формирования названия UC}
4. {описываем правила для формирования названия пакета UC}
5. {описываем правила для формирования приоритета UC}
6. {описываем правила для формирования сортировки списка UC}
Промт 2 для генерации UML-диаграммы прецедентов на основе списка UC
Действуй как опытный системный аналитик. На основе предоставленного
списка пользовательских сценариев для
[ВСТАВИТЬ НАЗВАНИЕ МОДУЛЯ ИЛИ ПОДСИСТЕМЫ]
из вложения сгенерируй UML-диаграмму прецедентов в формате PlantUML.
Шаг 1: Анализ требований
Проанализируй приложенный список UC и выдели:
- Основных акторов системы
- Ключевые прецеденты (use cases)
- Отношения между прецедентами (include, extend)
- Группировку по функциональным пакетам
Шаг 2: Генерация диаграммы
Создай диаграмму со следующей структурой:
{описываем пример UML-диаграммы на языкеPlantUML }
Шаг 3: Проверка правил
Убедись, что:
1. {описываем правила формирования связей include/extend}
2. {описываем правила включения/исключения прецедентов из общего списка на диаграмме}
3. {указываем правила для проверки полноты отображения с учетом цели конкретной диаграмы}
4. {указываем правила для названий прецедентов и пакетов на диаграмме}
Шаг 4: Форматирование результата
Предоставь результат ТОЛЬКО в формате txt-файла.
Промт 3 для описания сценария юскейса
Опиши шаги use-case [вставить название UC]
для системы [вставить название]
по описанию пользовательских сценариев из вложения в формате:
{указываем требования к выводу шагов:
1. определяем вид: таблица/маркерованный список
2. описываем обязательные блоки для вывода}
Правила:
1.{описываем требования к нумерации шагов основного потока}
2.{описываем требования к нумерации альтернативных потоков}
3.{описываем требования к нумерации шагов альтернативных потоков}
4.{описываем требования к описанию каждого шага основного потока и альтернативного потока с учетом организации ветвлений, циклов и обработки ошибок}
5.{описываем связи с ФТ, глосарием и словарем данных}
6.{описываем дополнительные требования к каждому блоку UC при необходимости}
○ реестров вариантов использования,
○ пошаговых описаний исполнения,
○ UML-диаграмм вариантов использования (Use Case Diagrams).
■ При этом ИИ изначально стремится соблюдать правила именования Use Case:
○ Формат: глагол + существительное (например, «Создать заявку», «Подтвердить оплату»).
○ Конкретность: исключаются абстракции вроде «Обработка данных» или «Документ».
○ Простота и краткость: используются понятные, нейтральные формулировки без жаргона.
○ Согласованность: применяется единый стиль написания (например, Заглавные Слова).
■ Аналитик проверяет черновик на соответствие принципам полноты, непротиворечивости, соответствию правил, а также корректности названий и логики сценариев. При необходимости — уточняет, дополняет или переформулирует Use Case в соответствии с установленными правилами и контекстом предметной области.
Примеры use-case:
■ Задать имя ИИ для дружеского общения,
■ Актировать автономный будильник,
■ Обучить ИИ новой функции,
■ Сформировать отчетность по голосовому запросу
■ Заказать цветы на день рождения для мамы Альтмана.
■ список пользовательских сценариев использования;
■ описание шагов каждого сценария использования (акторы, триггеры, предусловия, основной и альтернативный сценарий);
■ UML-диаграммы прецедентов.
1.6. Этап 5. Построение модели данных
1. Формирование концептуальной модели данных (Conceptual Data Model)
Текстовое описание сценариев использования подаётся на вход промта. На его основе генерируется концептуальная модель, содержащая ключевые сущности, их основные атрибуты, взаимосвязи, а также начальные описания элементов словаря данных (Data Dictionary).
ИИ предлагает кандидаты на сущности, связи и атрибуты; аналитик оценивает их на предмет логической согласованности, уникальности и полноты покрытия пользовательских сценариев.
Действуй как опытный системный аналитик.
На основе предоставленного
списка пользовательских сценариев для системы
[вставить название системы]
сгенерируй словарь данных, сгруппированный по пакетам для модулей:
[вставить название модуля 1], [вставить название модуля 2]
Правила:
1.{описываем правила к выводу названий для сущностей для словаря}
2.{описываем правила к формату вывода описания каждой сущности: таблицы/маркированный список}
3.{описываем правила группировки для сущностей внутри словаря}
На основе уточнённого словаря данных с помощью промта формируется логическая модель в виде UML-диаграммы классов. Эта модель детализирует структуру данных: уточняются типы атрибутов, кардинальности связей, правила наследования и другие логические зависимости.
Действуй как опытный системный аналитик.
На основе предоставленного
словаря данных для системы
[ВСТАВИТЬ СИСТЕМЫ]
сгенерируй UML-диаграмму классов на языке PlantUML
для пакета UC
[ВСТАВИТЬ НАЗВАНИЕ ПАКЕТА]
Результат: текстовый файл в формате PlantUML без дополнительных пояснений к файлу
Для сущностей, требующих описания жизненного цикла, дополнительно создаётся UML-диаграмма состояний. Её содержание также генерируется на основе соответствующих записей из словаря данных по аналогичному принципу.
■ словарь данных;
■ таблицы описания сущностей и связей;
■ CRUD-матрица;
■ UML-диаграммы классов;
■ UML-диаграммы состояния.
1.7 Этап 6. Формализация нефункциональных требований (НФТ)
1. НФТ-О Ограничения среды и регламенты (Environment & Constraints) — документация, уровень подготовки пользователей, стандарты;
Роль:
Ты — технический писатель и системный аналитик, специализирующийся на формализации требований. Твоя задача — на основе входных данных (ФТ и описание проблемы по методу opportunity canvas) для системы
[ВСТАВИТЬ НАЗВАНИЕ СИСТЕМЫ]
сгенерировать структурированные нефункциональные требования в виде ограничений, строго следуя заданной структуре:
{описываем структуруру вывода требований и принципы кодирования}
Шаг 1: Запрос исходных данных
Запроси у пользователя следующую информацию (если ее не нашел в контексте):
1. Кто пользователи системы и какие у них характеристики (возраст, техническая грамотность, язык, условия работы)?
2. Какие технологии используются (фронтенд, бэкенд, СУБД, браузеры, ОС)?
3. Какие минимальные требования к оборудованию (планшеты, ПК, ноутбуки)?
4. Какие требования к сети (скорость, доступность, offline-режим)?
5. Что должно входить в поставку (исходный код, скрипты, документация, контейнеры)?
6. Какие требования к документации (руководства, архитектура, инструкции)?
7. Есть ли лицензионные или юридические ограничения (Open Source, запрет на платные компоненты, права на код)?
Шаг 2: Генерация НФТ
{описываем требования к генерации с указанием критериев}
Шаг 3: Проверка и уточнение
Если каких-то данных не хватает для заполнения обязательных пунктов структуры — запроси их у пользователя. Например:
- Уточните минимальные требования к процессору планшета
- Какие именно браузеры должны поддерживаться?
- Требуется ли поддержка offline-режима?
Критерии качества:
{описываем критерии качества}
Действуй как опытный специалист по НФТ.
Напиши атрибуты внешнего качества ПО для [вставить название системы].
Перечень ФТ во вложении.
НФТ сгруппируй по следующим типам атрибутов:
1. Требования к производительности
2. Требования к масштабируемости
3. Требования к надежности
4. Требования к безопасности
5. Требование к отказоустойчивости
Формат: НФТ должны быть описаны с учетом критериев измеримости.
Примеры НФТ:
{привести примеры вывода НФТ}
Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределённость будет 0.1 или меньше
Действуй как опытный специалист по НФТ. Напиши атрибуты качества к использованию [вставить название системы].
Перечень ФТ во вложении.
НФТ сгруппируй по следующим типам атрибутов качества к использованию ПО:
1. Требования к результативности
2. Требования к скорости обучения
3. Требования к удовлетворенности
Формат: НФТ должны быть описаны с учетом критериев измеримости.
Примеры НФТ:
{привести примеры вывода НФТ}
Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределённость будет 0.1 или меньше
Прежде чем дать мне ответ, оцени его неопределённость. Если она больше, чем 0.1 — задавай мне уточняющие вопросы до тех пор, пока неопределённость не станет 0.1 или меньше.
■ список НФТ по группам;
■ описанные для каждого НФТ метрики и критерии оценки.
1.8 Этап 7. Компоновка и финализация SRS
■ Итоговый документ оценивается ИИ с помощью промта на согласованность, полноту и реализуемость в соответствие с бюджетом и сроками;
■ Системный аналитик анализирует замечания и вносит изменения при необходимости;
■ В итоге получается рабочая версия документа, готового к согласованию с командой разработки и заказчиком.
Ты — опытный системный аналитик и архитектор. Проведи пошаговый анализ технического задания (ТЗ) на полноту, качество формулировок, согласованность и реализуемость. После проверки каждого критерия сразу выдавай отчёт по нему — не жди завершения всего анализа.
Шаг 1: Запрос ТЗ и контекста
Попроси:
- Загрузить ТЗ (любой формат).
- Указать тип системы (веб/моб./десктоп), цели, ЦА и технические ограничения.
Шаг 2: Полнота структуры
Проверь наличие:
1. Введения
2. Функциональных требований и сценариев использования
3. Нефункциональных требований
4. Описания ролей
5. Ограничений
6. Требований к документации
7. Этапов и сроков
Если чего-то нет — запроси уточнение.
Формат отчёта:
- Наличие разделов: X/X
- Отсутствующие: [список]
- Рекомендации
- Оценка: X/100
Шаг 2.1: Полнота use-case и функций
Проверь:
- Покрытие happy/alternative/exception-сценариев
- Описание входов/логики/выходов
- Соответствие бизнес-целям
Формат отчёта:
- Покрытие сценариев: X/X
- Пропущенные функции/сценарии
- Оценка: X/100 + рекомендации
Шаг 3: Качество формулировок
Оцени:
- Конкретность (измеримость)
- Однозначность
- Проверяемость
Формат отчёта:
- Непроверяемые/субъективные требования
- Критические замечания
- Оценка: X/100
Шаг 4: Согласованность
Выяви:
- Противоречия между разделами
- Несоответствие ролей и функций
- Расхождения с целями
Формат отчёта:
- Конфликты/пробелы
- Оценка: X/100
Шаг 5: Реализуемость
Оцени с учётом:
- Технологий
- Ресурсов (сроки, бюджет, команда)
- Рисков (недетализация, неполное описание use-case и т.п.)
Формат отчёта:
- Риски/ограничения/сложности
- Оценка: X/100
Шаг 6: Итоговый отчёт
Сводка:
1. Полнота структуры: X/100
2. Качество формулировок: X/100
3. Согласованность: X/100
4. Реализуемость: X/100
Общая оценка: X/100
Критические проблемы:
- [список]
Рекомендации (по приоритету):
1. …
2. …
3. …
Статус: [готовность ТЗ]
Принципы:
- Оперативность: отчёт после каждого шага
- Конкретность: точные указания на проблемы
- Практичность: actionable рекомендации
- Объективность: балльная оценка
Готов начать! Загрузите ТЗ.
■ Глоссарий терминов;
■ Интервью и критерии успеха проекта;
■ Контекстная диаграмма;
■ Функциональные и нефункциональные требования;
■ Use Case сценарии;
■ UML-диаграммы (прецедентов, классов, состояния);
■ Модель данных;
■ Описание внешнего взаимодействия.
2. Результаты
2.1. Сокращение времени разработки ТЗ
2.2. Ускорение подготовки к сбору требований
■ как генератор продуманных вопросов,
■ как симуляцию заказчика (в образе Сэма Альтмана).
Этот подход называется методом когнитивной симуляции стейкхолдеров: ИИ временно «воплощает» точку зрения ключевого участника проекта, воссоздавая его мотивацию, язык, приоритеты и даже типичные способы мышления. В свою очередь, системный аналитик управляет диалогом: уточняет детали, выявляет пограничные случаи и направляет беседу к формулированию чётких и измеримых критериев успеха. Такая симуляция позволяет:
■ отработать навык перехода от абстрактной бизнес-идеи к конкретным требованиям;
■ выявить скрытые допущения и неоднозначности (например, что означает «незаметность» ИИ);
■ сформировать согласованный глоссарий и набор ожиданий ещё до встречи с реальным заказчиком.
■ оценить риски реализации.
Таким образом, когнитивная симуляция стейкхолдеров становится не только инструментом ускорения аналитики, но и методом подготовки к реальным переговорам — особенно в условиях высокой неопределённости или отсутствия прямого доступа к заказчику.
2.3. Стабильное построение ключевых взаимосвязанных артефактов
2.4. Повышение качества проектной документации
■ чёткую структуру и единообразие требований с автоматическим кодированием, что в дальнейшем поможет эффективно проводить трассировку;
■ согласованность между диаграммами, данными и функциями;
■ удобство восприятия для разных ролей в соответствие требованиями к трассируемости и управляемости (Requirements Traceability Matrix, RTM): системных архитекторов, разработчиков, тестировщиков.
Методика позволяет использовать следующую структуру таблицы с требованиями для трассировки:
3. Обсуждение
3.1 Практическая ценность
Методика позволяет превратить даже одну неструктурированную идею заказчика в связанный набор аналитических артефактов, готовых к разработке.
2. Стандартизация мышления
Благодаря пошаговой генерации артефактов с передачей контекста, работа системного аналитика становится воспроизводимой и масштабируемой, что соответствует принципам унификации подходов к описанию требований (Requirements Engineering Standards, IEEE 29148).
3. Гибкость и обучаемость ИИ
Использование ИИ в качестве партнёра мышления даёт возможность не просто автоматизировать рутинные шаги, а расширять границы проектного анализа, включая симуляции интервью, генерацию альтернатив и уточнение терминов.
3.2 Особенности применения
ИИ не заменяет системного аналитика — он лишь ускоряет работу. Интерпретация, корректировка, выявление противоречий и финальная формализация остаются в зоне ответственности человека.
2. Поддержание логики между шагами
При многошаговом проектировании важно уметь поддерживать целостный контекст. На каждом шаге системному аналитику требуется контролировать непрерывность логики и единство словаря данных. При этом нередко возникает необходимость возвращаться к уже сформированным артефактам — пересматривать связи между сущностями, корректировать требования или перерабатывать пользовательские сценарии в свете новой информации.
Центральным механизмом обеспечения такой целостности выступает прослеживаемость требований (requirements traceability) — возможность однозначно установить, откуда каждое требование возникло (например, из критерия успеха или use case), как оно реализуется в модели данных и как проверяется на этапе тестирования. В рамках предложенной методики прослеживаемость обеспечивается за счёт:
■ сквозного кодирования требований (например, через иерархические идентификаторы вида FT-M1.2.3);
■ явной привязки артефактов друг к другу (например, use case ссылается на ФТ, а сущности в модели данных — на шаги сценариев);
■ передачи контекста от этапа к этапу через структурированные промты.
ИИ, особенно в режиме однократного взаимодействия, не обладает способностью «помнить» предыдущие версии артефактов или отслеживать, как изменение на одном уровне влияет на другие. Без явного указания контекста и чёткой привязки к предыдущим шагам модель может генерировать логически несогласованный или дублирующий результат, нарушив референциальную целостность модели и разорвав цепочки прослеживаемости.
Поэтому эффективное использование ИИ требует не просто последовательных запросов, а выстроенной системы управления знаниями: фиксации промежуточных выводов, явного обозначения изменений и поддержания сквозной референциальной целостности между этапами. Только в таком режиме ИИ становится надёжным инструментом поддержки аналитической работы, а не источником хаотичных и трудно воспроизводимых гипотез.
3. Наброски глубокой архитектуры — также возможны
Хотя статья сосредоточена на этапах до разработки набросков архитектуры, при тестировании возможностей ИИ было подтверждено, что ИИ способен создавать черновики для архитектурных артефактов: от компонентной схемы до проектных решений, при наличии корректно построенного контекста.
4. Принципы работы с требованиями
Для обеспечения однородности, воспроизводимости и предсказуемости результатов при работе с ИИ необходимо заранее разработать стандартизированные шаблоны артефактов. Каждый шаблон должен чётко определять как структуру документа, так и правила его заполнения — включая формат описания, уровень детализации и стиль формулировок.
Ключевым условием эффективности является строгая согласованность между шаблонами и промтами: правила оформления, заложенные в шаблоне, должны быть явно отражены и в инструкциях для модели. Особенно важно заранее продумать принципы кодирования требований — например, иерархическую нумерацию или семантические префиксы. Это позволяет не только поддерживать единообразие, но и автоматизировать генерацию уникальных идентификаторов требований в соответствии с заданной схемой. Такой подход обеспечивает быструю и надёжную адаптацию результатов под нужные форматы — будь то внутренние стандарты команды, требования заказчика или регуляторные шаблоны — без необходимости ручной переработки каждого артефакта.
Кроме того, стандартизация артефактов и промтов напрямую поддерживает две ключевые практики из системного анализа:
■ Reuse (повторное использование): шаблоны, промты и схемы кодирования становятся переиспользуемыми компонентами, которые можно применять в разных проектах. Это снижает трудозатраты на старт новых инициатив и повышает качество за счёт накопленного опыта. Например, один и тот же промт для генерации контекстной диаграммы или структуры нефункциональных требований может быть адаптирован под разные предметные области с минимальными изменениями.
■ Governance (управление требованиями): единая структура и сквозная трассируемость (от бизнес-целей до модели данных) обеспечивают прозрачность и контроль над жизненным циклом требований. Это критически важно для аудита, соответствия регуляторным нормам и управления изменениями. Стандартизированные идентификаторы, метаданные и формализованные связи между артефактами позволяют легко отслеживать, кто, когда и почему внёс изменение, а также оценивать его влияние на смежные компоненты системы.
Таким образом, интеграция практик reuse и governance в методику работы с ИИ превращает генеративные инструменты не просто в ускорители, а в элементы управляемой, масштабируемой и аудируемой аналитической инфраструктуры.
3.3 Сравнение с классическим подходом
3.4 Перспективы
Методика может быть формализована в виде шаблонов и процедур, встроенных в процессы аналитики и пресейла.
2. Обучение начинающих аналитиков
Пошаговая структура и понятные шаблоны позволяют использовать метод как учебный инструмент — для тренировки построения ТЗ без привлечения реальных заказчиков.
4. Заключение
Методика показала высокую эффективность:
■ Снижение времени разработки ТЗ в 2-3 раза;
■ Повышение согласованности и повторяемости документации;
■ Возможность тренировать навыки аналитика в отсутствии реального заказчика;
■ Гибкость генерации — возможность расширения вплоть до набросок архитектурного уровня.
Использование ИИ (на примере бесплатной модели Qwen) позволяет системному аналитику перейти от работы руками к работе головой, сосредоточившись на проверке смысла, полноты и бизнес-ценности.
Важной особенностью предложенной методики является неявное, но системное использование предметно-ориентированных языков (DSL, Domain-Specific Language) на всех этапах формирования ТЗ. Каждый артефакт — будь то контекстная диаграмма в нотации DOT, структурированный шаблон функциональных требований, формализованный use case или модель данных в UML — представляет собой выражение на специализированном языке, понятном как человеку, так и машине. ИИ выступает не просто генератором текста, а транслятором бизнес-идеи в DSL-артефакты: из неформальной фразы заказчика он создаёт машиночитаемые и визуализируемые структуры, которые можно автоматически проверять, преобразовывать и интегрировать в инженерные процессы. Это превращает ТЗ из статического документа в динамическую модель знаний, готовую к дальнейшей автоматизации — от генерации тест-кейсов до проектирования API.
Таким образом, применение DSL в связке с ИИ обеспечивает три ключевых эффекта:
■ Стандартизацию — все артефакты создаются в едином формате, что упрощает их сопровождение;
■ Машинную интерпретируемость — результаты можно напрямую использовать в инструментах разработки и анализа;
■ Снижение когнитивной нагрузки — системный аналитик работает с понятными шаблонами, а не с «сырым» текстом.
В перспективе это открывает путь к созданию единых аналитических сред, где ИИ и человек совместно строят проектную модель на языках, адаптированных под каждую роль и этап — от бизнес-запроса до архитектурного решения.