Проблема: почему подготовка SRS отнимает дни и как DocGen меняет правила
Системный аналитик тратит на Software Requirements Specification (SRS) от одного до двух дней. Процесс выглядит так: серия интервью с заказчиком, расшифровка записей, вычитка противоречий, оформление разделов по шаблону, отрисовка диаграмм, согласование. Большая часть этого времени - механическая работа. Сборка текста из разрозненных ответов, поиск конфликтующих требований, ручная валидация синтаксиса PlantUML. Собственно анализ занимает 20-30% общего времени.
DocGen переворачивает эту пропорцию. AI-ассистент забирает рутину и отдаёт аналитику готовый черновик SRS через 2-3 часа после начала работы. Семь LLM-агентов, разделённых на две независимые цепочки, проводят интервью, вылавливают противоречия и генерируют документацию. Аналитик оставляет за собой стратегические решения и финальное ревью. Система не заменяет специалиста - она снимает с него механическую нагрузку.
Архитектура DocGen: две цепочки агентов вместо одного монолита
Ключевое архитектурное решение DocGen - отказ от монолитного промпта. Вместо одного вызова LLM, который получает на вход контекст и должен выдать готовый SRS, система разбивает процесс на два независимых пайплайна. Первая цепочка генерирует вопросы для интервью, вторая превращает собранные ответы в структурированный документ. Такое разделение даёт три преимущества: специализацию агентов под конкретную задачу, возможность итераций без перезапуска всего процесса и контроль качества на каждом этапе.
Входная точка - контекст проекта: brief заказчика, черновики требований, записи с созвонов. Цепочка 1 анализирует эти данные и формирует список уточняющих вопросов. Аналитик проводит интервью, собирает ответы и передаёт их в цепочку 2. Результат - готовый черновик SRS с диаграммами, проверенный на внутренние противоречия. Подход напоминает принципы проектирования предсказуемых LLM-ассистентов, где оркестратор управляет сменяемыми подсистемами, а не пытается решить всё одним вызовом модели.
Цепочка 1: от контекста к умным вопросам
Первый пайплайн решает задачу, с которой сталкивается любой аналитик: «О чём спрашивать заказчика, чтобы ничего не упустить?». Три агента последовательно обрабатывают входной контекст.
Агент оценки контекста проверяет, достаточно ли данных для генерации осмысленных вопросов. Если brief состоит из двух предложений вида «Нужна CRM для отдела продаж», агент сигнализирует о недостаточности и предлагает пользователю дополнить контекст. Это предотвращает генерацию поверхностных вопросов на пустом основании. Порог достаточности настраивается: для типовых проектов хватает 300-500 слов описания, для сложных систем с интеграциями - от 1000.
Агент настройки температуры динамически выставляет параметр temperature для LLM. В цепочке вопросов используется значение 0.7-0.8 - это даёт модели свободу находить неочевидные аспекты требований. Например, при анализе brief'а интернет-магазина агент может сгенерировать вопрос о пиковых нагрузках в Чёрную пятницу, даже если заказчик не упоминал сезонность.
Генератор вопросов формирует структурированный список из 15-30 пунктов, сгруппированных по разделам будущего SRS: функциональные требования, нефункциональные, интеграции, ограничения. Каждый вопрос привязан к фрагменту исходного контекста - аналитик видит, откуда взялась формулировка, и может скорректировать направление интервью.
Цепочка 2: от ответов к готовому документу
Второй пайплайн получает расшифрованные ответы интервью и проходит путь от сырых данных до структурированного черновика. Здесь работают четыре агента.
Сборщик ответов нормализует входные данные: приводит терминологию к единому стандарту, устраняет дубли, распределяет информацию по разделам SRS. Если заказчик в одном ответе упомянул и ролевую модель, и требования к шифрованию, агент разнесёт это в разделы «Пользователи» и «Безопасность».
Валидатор противоречий ищет логические конфликты. Классический пример: в ответе про производительность указано «время отклика до 100 мс», а в ответе про архитектуру - «синхронная репликация на три дата-центра». Агент обнаруживает, что синхронная репликация вносит задержку, и генерирует уточняющий вопрос. Цикл повторяется до трёх итераций - если противоречие не снято, оно попадает в финальный документ с пометкой «требует решения аналитика».
Структуризатор SRS собирает проверенные данные в документ по шаблону. Поддерживаются стандарты IEEE 830, ISO/IEC 25010 и внутренние форматы компаний. Агент заполняет разделы, проставляет перекрёстные ссылки и формирует таблицу версий требований.
Генератор UML создаёт диаграммы в гибридном режиме - этот механизм заслуживает отдельного разбора.
Семь агентов DocGen: что делает каждый и зачем
Полный состав системы - семь специализированных агентов. Каждый получает на вход строго определённый тип данных и выдаёт структурированный результат. Разберём три самых нетривиальных компонента, которые отличают DocGen от наивной генерации документации через ChatGPT.
Агент оценки контекста: когда данных мало, а вопросы нужны
Агент работает как фильтр качества на входе. Он анализирует объём и связность предоставленного контекста по трём метрикам: количество сущностей предметной области, покрытие функциональных блоков и наличие явных ограничений. При значении ниже порогового система не запускает генерацию вопросов, а запрашивает у пользователя дополнительную информацию. Это решает проблему «мусор на входе - мусор на выходе», характерную для одноэтапных промптов. Практический пример: аналитик загружает brief на 150 слов о разработке мобильного приложения. Агент подсвечивает, что не хватает данных о целевых платформах, количестве ролей пользователей и требованиях к офлайн-режиму. После дополнения контекста запускается основная цепочка.
Динамическая температура: почему 0.7 для вопросов и 0.2 для документации
Параметр temperature управляет «креативностью» LLM: чем выше значение, тем более разнообразные и неожиданные токены выбирает модель. DocGen использует разные настройки для разных этапов. Генерация вопросов требует широты охвата - temperature 0.7 позволяет агенту предлагать нестандартные ракурсы. Генерация документации требует фактологической точности - temperature 0.2 минимизирует вероятность галлюцинаций. Разница принципиальна: на тестовой выборке из 50 проектов при temperature 0.8 в черновиках SRS появлялось в среднем 2.3 вымышленных требования на документ. При 0.2 этот показатель падает до 0.1. Агент настройки температуры выставляет значение автоматически, опираясь на тип задачи и сложность контекста.
Валидатор противоречий: циклы уточнений вместо ручной перепроверки
Агент решает одну из самых трудоёмких задач аналитика - поиск конфликтов в требованиях. Алгоритм работает в три прохода. Первый проход: поиск прямых противоречий вида «система должна поддерживать 1000 одновременных пользователей» и «серверная часть разворачивается на одном узле с 4 ГБ RAM». Второй проход: поиск косвенных конфликтов через цепочки зависимостей. Третий проход: проверка на полноту - все ли заявленные функции покрыты нефункциональными требованиями.
При обнаружении противоречия агент формулирует уточняющий вопрос и возвращает его аналитику. После получения ответа цикл повторяется. Максимальное количество итераций - три, после чего неразрешённый конфликт маркируется для ручного разбора. На практике 85% противоречий снимаются за первую итерацию, 12% за вторую, 3% уходят аналитику. Такой подход перекликается с техникой Loop Engineering для уточнения пользовательских запросов, где небольшой цикл диалога резко повышает точность результата.
Гибридная генерация UML: когда LLM и код работают в паре
LLM плохо справляются с синтаксисом PlantUML. Модель может перепутать стрелки наследования и агрегации, пропустить закрывающий тег или сгенерировать невалидный идентификатор. Проблема известна: при прямой генерации диаграмм через промпт доля синтаксических ошибок достигает 30-40%.
DocGen обходит ограничение через гибридный подход. LLM не пишет код PlantUML - она создаёт текстовое описание диаграммы в промежуточном формате: сущности, атрибуты, типы связей, кардинальность. Программный модуль-транслятор принимает это описание и генерирует синтаксически валидный PlantUML. Транслятор написан на Python и содержит полную грамматику языка - он гарантирует корректность выходного кода.
Пример работы: агент получает ответы интервью о ролевой модели интернет-магазина и формирует описание: «Actor: Покупатель, Actor: Администратор, UseCase: Оформить заказ (связь с Покупателем), UseCase: Управлять каталогом (связь с Администратором)». Транслятор преобразует это в валидную диаграмму вариантов использования. Аналитик видит готовую картинку и при необходимости правит логику - синтаксис уже гарантирован.
DocGen на практике: 2 часа вместо 2 дней - реальные цифры
Цифры получены на выборке из 40 проектов разной сложности: от небольших веб-сервисов до распределённых систем с микросервисной архитектурой. Среднее время подготовки SRS вручную - 12 рабочих часов (1.5 дня). Среднее время с DocGen - 2.5 часа, из которых 1 час занимает интервью по сгенерированным вопросам, 40 минут - ревью черновика, 20 минут - правки диаграмм.
Распределение по сложности: для простых проектов (до 20 функциональных требований) время сокращается с 6 до 1.5 часов. Для средних (20-50 требований) - с 12 до 2.5 часов. Для сложных (50+ требований, множественные интеграции) - с 20 до 4 часов. Количество итераций уточнений противоречий: в среднем 1.8 на проект. Доля разделов SRS, принятых аналитиком без правок - 70%. Оставшиеся 30% требуют корректировки формулировок, но не логики.
Ключевой показатель: аналитик перестаёт тратить время на механическую сборку текста и полностью сосредотачивается на содержательной валидации. Это тот же переход, который мы видели в кейсе с AI-агентом для разработки: инструмент закрыл рутинные исследовательские запросы аналитиков, хотя провалил боевые задачи кодирования. Правильное позиционирование системы как ассистента, а не замены - критично для результата.
Границы применимости: что DocGen не умеет и почему это не замена аналитику
DocGen не проводит интервью самостоятельно. Он генерирует вопросы, но задаёт их человек. Система не считывает невербальные сигналы заказчика, не улавливает интонацию сомнения и не может переформулировать вопрос на лету, видя замешательство собеседника.
DocGen не принимает стратегических решений. Выбор между монолитом и микросервисами, определение приоритетов требований, оценка компромиссов между скоростью разработки и масштабируемостью - это зона аналитика. Система может подсветить конфликт, но не выбрать сторону.
DocGen не работает с неявными требованиями. Если заказчик не сказал о регуляторных ограничениях, потому что считает их очевидными, система не догадается спросить про ФЗ-152 или PCI DSS. Аналитик с отраслевым опытом заметит пробел и добавит вопрос вручную.
Система ошибается в двух типах ситуаций: когда контекст принципиально противоречив (заказчик сам не знает, чего хочет) и когда предметная область слишком узкая (агенты не обладают специфическими знаниями о, скажем, протоколах промышленных контроллеров). В первом случае DocGen зациклит уточнения и отдаст конфликт аналитику. Во втором - сгенерирует поверхностные вопросы, которые потребуют существенной доработки. Именно поэтому DocGen - инструмент усиления. Он забирает 80% рутины и оставляет человеку 20% сложных решений, где нужна экспертиза и контекст, недоступный машине.
Как начать использовать DocGen: интеграция в процесс аналитика
Внедрение DocGen не требует перестройки процессов или специальных знаний в AI. Достаточно пяти шагов.
Шаг 1: подготовка контекста. Соберите все доступные материалы по проекту - brief, записи созвонов, email-переписку, черновики требований. Загрузите в систему одним файлом или набором. Минимальный объём - 300 слов структурированного текста.
Шаг 2: запуск цепочки вопросов. Система анализирует контекст, при необходимости запрашивает дополнения и генерирует структурированный список вопросов. Обычно это занимает 3-5 минут.
Шаг 3: проведение интервью. Используйте сгенерированные вопросы как план встречи с заказчиком. Фиксируйте ответы в любом удобном формате - диктофонная запись с последующей расшифровкой, конспект, заполненная форма.
Шаг 4: запуск цепочки документации. Загрузите ответы в систему. Агенты проведут нормализацию, найдут противоречия, запросят уточнения и сгенерируют черновик SRS с диаграммами. Время обработки - 10-15 минут.
Шаг 5: ревью. Проверьте черновик на содержательные ошибки, скорректируйте формулировки, разрешите оставшиеся конфликты. Документ готов к согласованию с заказчиком.
Система адаптируется под шаблоны SRS, принятые в компании. Достаточно один раз настроить структуру разделов и стилистику - все последующие документы будут формироваться в том же формате. Для команд, которые уже используют AI-инструменты в процессах, DocGen встраивается в существующий стек без конфликтов. Это не замена аналитику, а мультипликатор его продуктивности - как хорошо спроектированный AI-агент, который берёт на себя предсказуемую рутину и оставляет человеку содержательные решения.