ИИ для системного аналитика: от требований к проверяемой схеме
ИИ помогает системному аналитику быстрее получить черновую структуру из текста: участников, сущности, сценарии и вопросы. Самая полезная часть работы часто начинается после первого ответа — когда нужно найти, что модель предположила без основания. Рассмотрим один учебный пример оформления заказа и три разных представления его логики.
Сначала зафиксируйте исходные факты
Условия примера: клиент создаёт заказ; заказ содержит одну или несколько позиций; позиция ссылается на продукт и хранит количество. Сервис заказов запрашивает оплату у провайдера. При подтверждении заказ становится оплаченным, при отказе остаётся в ожидании оплаты. После оплаты заказ может быть отправлен. Ожидающий оплаты заказ можно отменить.
Это учебный текст, а не описание реальной системы Эсборд. В нём намеренно нет правил возврата, таймаутов, налогов и складского учёта. Если модель добавит их как уже согласованные факты, это ошибка постановки или выполнения задачи. Полезные предположения допустимы только в отдельном списке вопросов.
Разбор входящих требований
Попросите модель составить четыре списка: акторы, сущности, действия и ограничения. Для каждого пункта нужна фраза-основание из источника. Затем отдельно — что не определено. Например: может ли один платёж покрывать несколько заказов, возможна ли частичная оплата, что происходит с повторным уведомлением провайдера?
На этом этапе не просите сразу построить «архитектуру». Сначала проверьте словарь. В письме «клиент» может означать человека, организацию или программное приложение; схема с красивой раскладкой не устраняет эту неоднозначность.
Sequence: проверить порядок взаимодействий
В проверенном примере участвуют клиент, сервис заказов и платёжный провайдер. Сначала создаётся заказ и возвращается его ID, затем запрашивается оплата. Блок альтернативы показывает подтверждение и отказ. Такая схема отвечает на вопрос «кто кому сообщает и в каком порядке», но не описывает структуру таблиц.
Проверьте, что отказ не превращается в отмену без основания. В исходнике сказано: заказ остаётся в ожидании оплаты. Это небольшая разница в формулировке, которая меняет поведение системы. Дополнительно спросите о синхронности ответа: если источник этого не определяет, модель должна задать вопрос, а не выбрать удобный вариант молча.
ER: проверить сущности и кратности
В учебной модели используются Customer, Order, OrderItem и Product. Один клиент может иметь несколько заказов, каждый заказ содержит хотя бы одну позицию, позиция относится к одному продукту. Количество находится в позиции заказа, а не в продукте: оно описывает конкретную покупку.
Идентификаторы и внешние ключи здесь — явно выбранный учебный вариант, не доказанная схема существующей базы. Не переносите его в миграцию без уточнения требований. Даже верно нарисованная связь не определяет индексы, ограничения удаления, историчность цены и требования к транзакциям. Подробнее о чтении таких схем — в разборе ER-диаграмм.
State: проверить жизненный цикл
Состояния примера: Draft, AwaitingPayment, Paid, Shipped, Cancelled. Создание переводит черновик в ожидание оплаты, подтверждение — в оплаченный, отправка — в отправленный. Отмена разрешена из ожидания оплаты. Другие переходы не добавлены, потому что их нет в исходных правилах.
Попросите модель найти несовместимости между state и sequence. Например, если sequence допускает повтор оплаты после отказа, state не должен сразу завершать объект отменой. Это хороший сценарий для ИИ: сравнивать два представления одного набора правил, а не придумывать третье.
Что действительно проверено
5 октября 2026 года sequence, ER и state из этого примера созданы на тестовой доске через MCP. Сервер принял исходники и вернул объекты с рассчитанными размерами. Проверены участники, связи, ветки и переходы в возвращённых данных, затем отрисовка в Chromium без входа в аккаунт. Скриншоты выше сняты с открытой доски. Это подтверждает создание диаграмм, но не является нагрузочным тестом или проверкой корректности платёжной интеграции.
Синтаксис сверяется с документацией sequence и ER. Содержание сверяется с исходным текстом и владельцем процесса. Эти две проверки нельзя подменять друг другом.
Попросите найти дыры, а не только нарисовать
Сопоставь исходные требования, sequence, ER и state. Для каждого расхождения приведи два фрагмента-основания. Отдельно перечисли пробелы и предположения. Не добавляй правила, не меняй диаграммы. Начни с ошибок, которые могут изменить бизнес-результат.
Полезный ответ содержит конкретную пару утверждений, а не общий совет «улучшить обработку ошибок». Если модель пишет, что поле обязательно, спросите, какой источник это подтверждает. Такая проверка помогает и человеку точнее сформулировать требования.
Доступ к доске и границы ответственности
Через MCP внешний агент работает с объектами в пределах выданных прав. Для sequence, state, class, ER и Ганта используется движок диаграмм; блок-схемы собираются нативными фигурами. Не обещаем автоматическую поддержку всего UML, BPMN или любой архитектурной нотации.
Создайте доску для ревью требований: исходный текст слева, три представления рядом, вопросы отдельно. Агент готовит и сопоставляет материалы; аналитик проверяет смысл, договаривается с участниками и отвечает за принятую спецификацию.
