Друзья, привет! Меня зовут Ларионов Александр. Я работаю системным аналитиком. Совместно с Лабораторией инноваций Московской биржи мы изучали вопрос применения AI в системном анализе.

Когда я впервые столкнулся с задачей внедрения AI-ассистентов в процессы работы системного аналитика, то отреагировал скептически. Поводов было немало: большинство материалов на эту тему представляли собой восторженные отзывы вроде «AI автоматизирует рутину» или «machine learning улучшает принятие решений». Однако, при ближайшем рассмотрении, эти фразы распадались на абстрактные утверждения. Попытки уточнить у авторов конкретные кейсы или сценарии применения их инструментов для системного анализа сводились к общим фразам: «Обучите модель на ваших данных — и она всё поймёт».

Скептицизма добавляло и то, что сама роль системного аналитика строится на работе в условиях высокой неопределенности. В этой специальности регулярно сталкиваются с неоднозначными требованиями, непонятной бизнес-логикой, конфликтующими приоритетами, быстро меняющимися требованиями. Это противоречит глубинному принципу современных AI-моделей — обучению на конкретных, четко структурированных данных. Машине сложно оперировать «чувством здравого смысла» или «интуитивным пониманием бизнес-процессов», которые так важны для аналитика.

Как же убедиться, что AI полезен для нашей профессии, когда в поиске реальных кейсов находишь информационный вакуум? Я решил переосмыслить подход и начать экспериментировать самостоятельно. За основу я взял самые распространённые задачи, с которыми сталкиваются системные аналитики, в том числе и мы в Лаборатории инноваций Московской биржи.

Для начала важно избавиться от иллюзии, что AI-ассистент сможет заменить человека или автоматически сможет принести ожидаемый бизнес-результат и констатируем следующее:

• AI — это инструмент для работы в рамках уже сформированных аналитиком подходов. Его ценность проявляется там, где системное мышление (разработка гипотез и решений, анализ требований, управление неопределенностью) встречается с потребностью в поддержке.

• AI не заменяет критическое мышление, но может упростить процесс формализации и выполнение рутинных задач, а также помочь выявить «пробелы» в условиях неопределенности.

• AI не освобождает от ответственности. Любой ответ AI следует воспринимать как предположение, требующее обязательной проверки.

Получается, что наша задача не заставить AI работать вместо системного аналитика, а понять, где его усилия могут «заполнить пробелы» между хаосом и порядком.

От абстракции к практическим сценариям

Системный анализ — это не всегда линейный процесс, а, скорее, переплетение фаз, итераций и рутинных моментов. Исходя из этого, рассмотрим кейсы применения AI в двух частях:

• Полноценный сценарий — смоделируем ситуацию создания нового сервиса и рассмотрим, как инструмент встраивается в линейный аналитический цикл (от постановки задачи до разработки решения).

• Точечные сценарии — краткие примеры, где AI решает конкретную задачу.

В этой статье разберем первую часть, а второй будет посвящен отдельный материал. Рассмотрим, как ИИ-ассистент (в Лаборатории инноваций Московской биржи мы используем Qwen) может стать эффективным помощником системного аналитика на каждом этапе разработки системы. В качестве примера разберем процесс создания сервиса, который должен отправлять письма с электронной подписью (ЭЦП), взаимодействуя с внутренними сервисами компании.

Важно отметить, что все перечисленные ниже кейсы не являются строгим руководством к действию или единственно возможными сценариями для использования AI в системной аналитике. Основная идея — демонстрация возможностей AI и формирование понимания, что инструмент действительно может быть полезен. Пробуйте применительно к своим задачам, подбирайте различные варианты запросов, загружайте документы для уточнения своих запросов и получайте тот результат, который вас удовлетворит.

Шаг 1: Формирование требований к системе

Контекст задачи

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

• Клиенты системы — внутренние сервисы компании (API-интеграция).

• Бизнес-цель: упростить процесс отправки документов с гарантией юридической достоверности.

На данном этапе речь не идет о системном анализе, но, чтобы сценарий не выглядел фрагментарным, попросим модель выполнить этап бизнес-анализа и подготовить требования для системного аналитика. Этот шаг позволит не отвлекать бизнес-аналитика (подмигиваю коллегам из бизнес-анализа ? – кейс формализации требований с помощью AI).

Идея использования AI — автоматизация создания структурированных требований на основе бизнес-постановки.

Взаимодействие пользователя с AI-моделью

Запрос аналитика

«Требуется разработать сервис, который будет отправлять письма и подписывать вложенные файлы ЭЦП. Клиенты — различные сервисы в существующей архитектуре компании. Сервисам необходимо отправлять сообщение и получать статусы сообщений по API.

Сгенерируй требования к системе. Разложи их на бизнес-требования и пользовательские требования (с группировкой по пользователям). Выдели функциональные и нефункциональные требования. К наименованиям требований добавь коды. Для разных типов требований используй единый формат описания».

Пример ответа AI

Бизнес-требования

1. BR-001: Повысить уровень безопасности и юридической значимости отправляемых писем за счет использования электронной цифровой подписи (ЭЦП) на вложенные файлы.

   • Детали: Сервис должен обеспечивать возможность подписания файлов, вложенных в письма, с соблюдением требований законодательства РФ (например, ФЗ-63).

2. BR-002: Автоматизировать процесс отправки писем и подписания файлов для снижения ручной работы и ошибок.

   • Детали: Клиенты (внутренние сервисы) должны взаимодействовать с сервисом через API, минуя вмешательство человека.

3. BR-003: Обеспечить интеграцию с существующими сервисами компании.

   • Детали: API должен быть совместим с текущими стандартами аутентификации и форматами данных (например, OAuth2, JSON/XML).

4. ....

Группа пользователей: Клиент-сервисы

1. UR-001: Отправлять письма с подписанными вложенными файлами.

   • Детали: Клиенты должны передавать текст письма, список вложений и данные для подписи (ключ, сертификат) через API.

2. UR-002: Получать статусы отправленных писем.

   • Детали: API должен возвращать статусы: "ожидает обработки", "подписано", "отправлено", "ошибка".

3. ....

Группа пользователей: Администраторы
4. UR-004: Управлять ключами ЭЦП и сертификатами.

• Детали: Администраторы должны иметь интерфейс для загрузки, обновления и отзыва ключей/сертификатов.

5. UR-005: Отслеживать метрики работы сервиса.

   • Детали: Доступ к данным о количестве обработанных писем, времени выполнения задач, количестве ошибок.

Группа пользователей: Юридические специалисты
6. UR-006: Обеспечить юридическую подтверждаемость подписанных файлов.

• Детали: Подписи должны соответствовать требованиям ГОСТ Р 34.10-2012 и сохраняться в архиве с возможностью проверки.

Функциональные требования (FR)

1. FR-001: Прием и обработка запросов на отправку писем.

   • Детали: Сервис должен принимать POST-запросы с данными письма (тема, текст, список вложений) и параметрами подписания.

2. FR-002: Подписание вложенных файлов ЭЦП.

   • Детали: Подпись должна выполняться с использованием закрытого ключа, хранящегося в защищенном хранилище.

3. FR-003: ...

Нефункциональные требования (NFR)

1. NFR-001: Производительность.

   • Детали: Сервис должен обрабатывать не менее 1000 писем в час с минимальной задержкой (≤2 секунд на задачу).

2. NFR-002: Надежность.

   • Детали: Гарантия доставки писем с механизмом ретраев (до 3 попыток) при сбоях.

3. NFR-003: Безопасность.

   • Детали: Хранение закрытых ключей ЭЦП в зашифрованном виде, использование HTTPS для API, аудит доступа к ключам.

4. NFR-004: Совместимость.

   • Детали: API должен поддерживать версионирование (например, /v1/) и быть совместимым с JSON/XML.

5. NFR-005: ...

---

Роль AI на данном этапе

AI выполнил два ключевых действия:

• Анализ бизнес-постановки: преобразовал идею в конкретные требования, учитывая интеграции с PKI (публичной службой ключей), безопасность и законодательные аспекты.

• Структурирование данных: распределил требования на категории (бизнес/пользовательские, функциональные/нефункциональные) и автоматически пронумеровал их для удобства отслеживания.

Ключевые шаги работы AI

• Парсинг запроса: извлек ключевые элементы (ЭЦП, API, клиенты-сервисы)

• Обогащение знаниями: добавил требования, связанные с ФЗ-63 и стандартами ЭЦП

• Аналогии: использовал шаблоны описаний для аналогичных систем (например, облачных сервисов с API)

• Форматирование: применил единообразную структуру (код + тип + требование) для читаемости

Чем полезен AI на данном этапе

• Сокращение времени: ускорение создания первой версии документа требований.

• Снижение рисков ошибок: AI проанализировал необходимость требований к логам, которые могли ускользнуть от человека.

• Расширение экспертных знаний: например, использование ФЗ-63, что требует специального исследования, а AI воспользовался встроенной информацией.

• Единообразная структура: избежание использования произвольных форматов.

Выводы

Использование AI на этапе формирования требований экономит время на рутинную структуризацию и учет смежных аспектов.  Ответ модели демонстрирует, как AI может раскрыть детали, о которых пользователь мог забыть (например, требования аудиторов безопасности). Этот пример показывает, как AI готовит основу для аналитического процесса, но реальная ценность возникает в отношении между инструментом и критическим мышлением аналитика.

Шаг 2: Проверка входящих требований с помощью AI

Контекст задачи

Системный аналитик получил от бизнес-аналитика (заказчика) сформулированные требования для сервиса отправки писем с ЭЦП (сформированные на шаге 1). Теперь необходимо провести их проверку.

Для поиска несоответствий в требованиях необходим детальный анализ множества параметров, что может занять значительное время. AI-модель выполняет функцию аудитора, автоматически оценивая требования по стандартным критериям и выявляя недостатки, которые аналитик мог бы упустить.

Идея использования AI — автоматизировать анализ требований на основе стандартов (например, критерии качества требований).

Обратите внимание, что для проверки требований используются критерии качества как наиболее простой для понимания пример. В реальной работе системного аналитика всегда формируются собственные паттерны и правила проверки, которые требуется указывать в запросе к модели.

Взаимодействие пользователя с AI-моделью

Запрос системного аналитика

«Твоя роль — системный аналитик. Ты получил данные требования на вход. Выполни проверку требований на соответствие критериям качества. При проверке используй критерии качества требований. Сформулируй вопросы, которые необходимо выяснить перед тем, как начать разработку документации системного аналитика».

Пример ответа AI

1. Бизнес-требования (BR)

• BR-001:

  • Корректность: Требование соответствует цели повышения безопасности.

  • Полнота: Не указаны конкретные требования к типу ЭЦП (например, ГОСТ Р 34.10-2012 или иной стандарт).

  • Ясность: Формулировка общая. Нужно уточнить, какие именно аспекты безопасности обеспечиваются.

  • Согласованность: Не противоречит другим BR.

  • Измеримость: Не указано, как измерить "уровень безопасности".

  • Достижимость: Требует интеграции с сертификационными службами.

  • Значимость: Высокая — связана с юридической значимостью.

  • Ограниченность: Не указаны ограничения на объем файлов, скорость подписания.

  • Стабильность: Вероятно, стабильное (законодательные требования меняются редко).

  • Проверяемость: Требует проверки соответствия сертификатам и стандартам......

Вопросы для уточнения перед разработкой документации

1. Какие конкретные законодательные требования (ФЗ-63, ГОСТ) должны соблюдаться при подписании файлов?

2. Какие типы файлов будут обрабатываться (PDF, DOCX, XML и т.д.)?

3. Какие существующие системы компании уже используют для отправки писем, и какие протоколы они поддерживают (SMTP, REST API и т.д.)?

4. Какие параметры аутентификации используются в компании (OAuth2, API-ключи, SAML)?

5. Какие метрики наиболее важны для администраторов (время подписания, количество ошибок, загрузка ключей)?

6. Какие требования к хранению ключей ЭЦП (HSM, локальное хранилище, облачное)?

7. ....

---

Роль AI на данном этапе

• AI выполнил комплексный аудит требований, оценил их соответствие стандартным критериям качества (полнота, четкость, согласованность, реализуемость и т.д.)

• Определил пробелы в документации требований (например, отсутствие описания аутентификации)

• Выявил противоречия и нечеткость формулировок (например, двусмысленность в определении временных метрик)

• Подготовил список уточняющих вопросов, которые аналитик должен задать заинтересованным сторонам (конечным пользователям, разработчикам)

Ключевые шаги работы AI

• Анализ требований по запросу аналитика: проверка каждого требования на соответствие критериям качества (полнота, четкость, согласованность, реализуемость, тестируемость)

• Формулировка контрольных вопросов: для каждого выявленного пробела или несоответствия сгенерировала конкретный вопрос

• Структурирование выводов: организация найденных нарушений в табличном виде для удобного анализа

Чем полезен AI на данном этапе

• Сокращение времени анализа: чем больше требований обрабатывает человек, тем больше шанс что-то упустить, тогда как AI проверяет все условия.

• Нейтральный взгляд: модель не имеет предвзятостей и анализирует требования «в лоб», без учета накопленного проектного опыта.

• Стандартизация аудита: использует заложенные методики проверки, о которых аналитик может забыть.

• Формулировка вопросов: готовые вопросы экономят время на подготовку к интервью с заинтересованными сторонами.

Выводы

Корректное использование модели на данном этапе, как и на любом другом, — это залог успеха. Модель не заменит аналитика, у которого есть опыт работы на проекте, но модель может проводить ревью неограниченного количества документов по критериям, которые укажет автор запроса. Сможет ли модель корректно отработать запрос «Проведи ревью ФЗ»? Нет. Сможет ли модель эффективно отработать запрос «Проверь, используются ли термины из раздела «глоссарий» в документе»? Да.

Шаг 3: Отработка вопросов системного аналитика

Контекст задачи

Для первоначального документа требований сервиса отправки писем с ЭЦП выявились несоответствия критериям качества (шаг 2). Задача системного аналитика на данном этапе — получить ответы на сформулированные вопросы и добиться устранения всех несоответствий. Из-за того, что для данных работ нам снова потребуется бизнес-аналитик, будем использовать AI для имитации работы БА, а именно для:

• Формулирования точных вопросов для устранения недочетов

• Предположения возможных ответов клиентов

• Корректирования требований с учетом новых данных

Взаимодействие пользователя с AI-моделью

Запрос системного аналитика

«Предложи наиболее вероятные ответы на свои вопросы выше. Скорректируй требования с учетом ответов. Преобразуй скорректированные требования в требования к системе. Преобразованные требования приведи в отдельной таблице. В ней должен использоваться уникальный код требований».

Пример ответа AI

Предполагаемые ответы на вопросы

Скорректированные требования

Бизнес-требования (BR)

---

Роль AI на данном этапе

AI выполнил важные функции:

• Анализ запросов и стратегия ответов: предложил логичные варианты ответов на вопросы, основанные на стандартных подходах (например, использование API-ключей для безопасности, форматы вложений).

• Автоматизированная корректировка требований: обновил требования с учетом полученных ответов, добавив необходимые детали и уточнения.

• Генерация структурированной таблицы: оформил требования в таблицу с четкими кодами, типами, описаниями и категориями (ФТ/НФТ), что ускоряет понимание и дальнейшую документацию.

Ключевые шаги работы AI

• Обработка идей: проанализировал список вопросов аналитика, идентифицировал ключевые области (безопасность, форматы, временные ограничения)

• Генерация предположений: использовал стандартные решения из области IT-архитектуры (например, AES-256 для шифрования, ограничение размера вложений) для предсказания ответов

• Интеграция с существующими требованиями: убедился, что новые требования не противоречат предыдущим и дополняют их

Выводы

Шаг 3 является результатом обработки шагов 1 и 2. Если вы проведете эксперимент самостоятельно и сравните две версии документа (шаг 1 и шаг 3), то заметите, что документ на шаге 3 содержит более качественное описание требований. В данном случае использованы гипотезы модели и критерии качества требований для достижения результата. Если обогатить данные требования доменными знаниями, собственными паттернами проверки и экспертизой реального бизнес-аналитика, то ответ AI будет еще лучше.

Шаг 4: Разработка матрицы трассировки требований

Контекст задачи

Этот шаг редко используется аналитиками, потому что создание и поддержание матрицы требований в актуальном состоянии требует значительных трудозатрат. Применение AI на этом этапе позволяет ускорить процесс и обеспечить прозрачность связи между требованиями и модулями системы.

 Идея использования AI — автоматизация создания матрицы трассировки требований на основе имеющихся данных. Она позволит визуализировать связи и обеспечит контроль за полнотой покрытия требований.

Взаимодействие пользователя с AI-моделью

Запрос системного аналитика

«Выполни трассировку требований. Результат выведи в формате матрицы требований. В матрицу добавь тест-кейсы».

Требование по добавлению тест-кейсов является «бонусным» и демонстрирует возможности применения модели в интересах тестирования.

Пример ответа AI

Матрица трассировки требований

---

Роль AI на данном этапе

AI выполнил следующие функции:

• Связывание требований с компонентами системы: распознавание модулей (например, «Модуль вложений») через ключевые слова в требованиях

• Создание тест-кейсов на основе логики требований: для каждого сгенерировал конкретные проверки

• Установление взаимосвязи между требованиями: например

• Упорядочивание результатов в табличном виде, что упрощает визуализацию процесса

Чем полезен AI на данном этапе

• Ускорение процесса

• Покрытие тестами

• Автоматизация связи требований на основе логики

• Стандартизация формата описания

Выводы

Делегирование задачи создания матрицы требований AI и предоставление модели необходимой документацией на входе, аналитик может получить дополнительный артефакт, который позволит:

• Убедиться, что все потребности связаны с требованиями к разработке решений, которые эти потребности удовлетворяют

• Убедиться, что все требования имеют связи с тест кейсами

• Точно понимать, какие масштабы изменений повлечет за собой изменение конкретного требования через его связи с другими требованиями

Шаг 5: Создание Use Case диаграммы

Контекст задачи

Допустим, мне как системному аналитику нужно убедиться, что при переходе от высокоуровневого описания требований к детальному ничего не упущено. Для этого я хочу добавить промежуточный уровень. Это позволит мне уменьшить шаг абстракции на уровне детализации требований. Здесь я хочу использовать Use Case диаграмму.

Использование AI позволяет автоматически сгенерировать сложную диаграмму с соблюдением стандартов UML, включая конструкции include и extend.

Взаимодействие пользователя с AI-моделью

Запрос системного аналитика

 «Сгенерируй Use Case диаграмму в формате plantUML по данным требованиям. Учти варианты extend и include сценариев».

Пример ответа AI

Роль AI в данном этапе

AI автоматически сгенерировал полный код диаграммы и включил акторов, сценарии и связи.

Ключевые шаги работы AI

• Анализ требований.

• Определение акторов.

• Создание основных Use Cases.

• Реализация include/extend.

• Формирование кода.

Чем полезен AI на данном этапе

• Сокращение времени

• Стандартизация: Гарантированное соблюдение UML-синтаксиса

• Полнота: Учет всех требований (от клиента до администраторов) и корректное отображение связей между акторами

• Гибкость: Возможность легко внести изменения в код, расширяя или исправляя сценарии без потери структуры

• Выявление зависимостей

Выводы

Возможно AI не предложил абсолютно корректную диаграмму, но создал эффективную точку входа, предложив логическую гипотезу по предполагаемым сценариям с соблюдением правил синтаксиса. Это позволяет аналитику экономить время и сразу приступать к уточнению гипотезы. Код PlantUml, предложенный моделью, должен быть уточнен аналитиком и использоваться в дальнейших запросах к модели, что, в свою очередь, сделает дальнейшие ответы модели более точными.

Шаг 6: Подготовка перечня предполагаемых сервисов

Контекст задачи

На текущем этапе системный аналитик уже собрал требования, выполнил декомпозицию и связал их между собой. Теперь можно переходить к проектированию решения.

 Допустим, в нашем примере используется микросервисная архитектура, и цель — определить список потенциальных сервисов. Обычно этим занимаются архитекторы (привет коллегам-архитекторам! ?). Однако AI может помочь:

• автоматически сформировать список сервисов,

• подготовить компонентные диаграммы,

• разработать схемы потоков данных и т. д.

Главная задача AI здесь — ускорить проектирование архитектуры. 

Взаимодействие пользователя с AI-моделью

Запрос системного аналитика

 «Составь перечень предполагаемых сервисов».

Пример ответа AI

Перечень предполагаемых сервисов

1. Email Gateway (Почтовый шлюз)

• Описание: Сервис, принимающий API-запросы от клиентов, формирующий письма и отправляющий их через SMTP/IMAP.

• Функции:

  • Прием и валидация данных письма (тема, текст, вложения).

  • Отправка писем через SMTP-сервер (с поддержкой TLS и OAuth2).

  • Интеграция с Digital Signature Service для подписания вложений.

  • Обновление статусов задач в Status Tracking Service.

• Ключевые требования:

  • FR-001, FR-003, FR-004, NFR-001, NFR-002, NFR-006.

2. Digital Signature Service (Сервис подписи ЭЦП)

• Описание: Сервис, обеспечивающий подписание файлов по ГОСТ Р 34.10-2012.

• Функции:

  • Подписание вложенных файлов с использованием HSM.

  • Генерация хэшей и проверка целостности подписей.

  • Интеграция с Key Management Service для получения действительных ключей.

• Ключевые требования:

  • FR-002, FR-006, NFR-003, NFR-007...

---

Роль AI на данном этапе

После анализа собранных требований модель производит следующие действия:

• Генерирует список сервисов, соответствующих функциональности системы.

• Связывает их с конкретными требованиями.

• Предлагает технические решения (PKI, интеграция мониторинга и др.).

• Определяет зависимости между сервисами (например, Email Service требует Auth Service).

 

Преимущества использования AI на данном этапе

• Экономия времени на планирование

• Минимизация рисков упущенных функций — AI учитывает все входящие данные

• Структурированный подход — автоматическая привязка сервисов к требованиям 

Выводы

Применение AI для формирования перечня сервисов упрощает переход от требований к архитектуре. Модель автоматически группирует функции, связывает их с требованиями, предлагает варианты реализации. Это позволяет аналитику и команде начать работу не с нуля, а с готовой гипотезы, которую останется лишь уточнить.

Оптимальный процесс: AI формирует первоначальный вариант, затем архитектор вносит правки, после модель дорабатывает решение с учетом замечаний. В этом примере AI не заменяет аналитика, а становится его эффективным помощником, ускоряющим процесс проектирования.

 

Шаг 7: Построение ER-модели базы данных

1. Контекст задачи

На предыдущем этапе модель помогла сформировать архитектуру сервисов и их взаимосвязи. Теперь на основе этого решения необходимо спроектировать логическую ER-модель БД, корректно отразив сущности и их отношения.

Использование AI позволяет автоматизировать генерацию кода диаграммы (например, в PlantUML), сократить время проектирования и снизить риск логических ошибок.

2. Взаимодействие пользователя с AI-моделью

Запрос аналитика

«Построй ER-модель базы данных сервисов в формате PlantUML на логическом уровне. Исключи описание, предоставь только код».

Почему такой запрос? На предыдущих этапах (например, в шаге 5) модель генерировала не только код, но и пояснения, что замедляло процесс. Адаптируясь к работе с AI, мы уточняем запрос, чтобы получать только готовый код без лишних описаний.

Пример ответа AI

Роль AI на данном этапе

Модель автоматически сгенерировала код ER-диаграммы в PlantUML, используя ранее собранные требования и связи между сущностями . Это избавило аналитика от рутинной работы по прописыванию сущностей, атрибутов и отношений вручную.

Чем полезен AI на данном этапе

• Экономия времени

• Согласованности с требованиями: AI сохранил логику из предыдущих этапов общения с моделью

• Визуализация отношений: диаграмма помогает аналитику и разработчикам быстро понять схему БД, подчеркивая ключевые зависимости

• Избежание ошибок логики и синтаксиса: AI избежал пропуска полей или связей, которые легко упустить при ручной работе.

Выводы

Как и в предыдущих шагах, AI не заменяет аналитика, а выступает инструментом для ускорения работы: модель генерирует первичный вариант диаграммы, аналитик проверяет и корректирует его, затем, при необходимости, уточнения возвращаются в модель для доработки. Такой подход сокращает рутинную работу, позволяя сосредоточиться на содержательной части проектирования.

Шаг 8: Генерация SQL-скриптов для создания таблиц базы данных

1. Контекст задачи

Этот шаг — «бонус» для разработчиков ?. Он показывает, что имея логическую схему БД, можно использовать AI с целью генерации SQL-скрипта для создания таблиц БД.

2. Взаимодействие с AI

Запрос аналитика

«Сгенерируй SQL-скрипты для создания таблиц базы данных».

Пример ответа AI

-- Таблица для хранения писем
CREATE TABLE Email (
    id CHAR(36) PRIMARY KEY,
    subject VARCHAR(255) NOT NULL,
    body TEXT NOT NULL,
    created_at DATETIME NOT NULL,
    status VARCHAR(50) NOT NULL,
    recipient VARCHAR(255) NOT NULL
);

-- Таблица для хранения вложений
CREATE TABLE Attachment (
    id CHAR(36) PRIMARY KEY,
    file_name VARCHAR(255) NOT NULL,
    file_path VARCHAR(512) NOT NULL,
    email_id CHAR(36) NOT NULL,
    FOREIGN KEY (email_id) REFERENCES Email(id)
);

-- Таблица для хранения подписей
CREATE TABLE DigitalSignature (
    id CHAR(36) PRIMARY KEY,
    hash VARCHAR(64) NOT NULL,
    signed_at DATETIME NOT NULL,
    attachment_id CHAR(36) NOT NULL,
    key_id CHAR(36) NOT NULL,
    FOREIGN KEY (attachment_id) REFERENCES Attachment(id),
    FOREIGN KEY (key_id) REFERENCES Key(id)
);
................................................................................
-- Добавление индексов для оптимизации запросов
CREATE INDEX idx_attachment_email_id ON Attachment(email_id);
CREATE INDEX idx_signature_attachment_id ON DigitalSignature(attachment_id);
CREATE INDEX idx_signature_key_id ON DigitalSignature(key_id);
CREATE INDEX idx_status_email_id ON StatusTracking(email_id);
CREATE INDEX idx_audit_email_id ON AuditReport(email_id);
CREATE INDEX idx_audit_signature_id ON AuditReport(signature_id);
CREATE INDEX idx_audit_user_id ON AuditReport(user_id);
CREATE INDEX idx_error_email_id ON ErrorLog(email_id);
CREATE INDEX idx_error_signature_id ON ErrorLog(signature_id);
CREATE INDEX idx_token_user_id ON Token(user_id);
CREATE INDEX idx_metric_email_id ON Metric(email_id);
CREATE INDEX idx_metric_signature_id ON Metric(signature_id);

Роль AI на данном этапе

AI автоматически сгенерировал SQL-скрипты на основе предыдущей ER-модели, сохранив логические связи между сущностями.

Ключевые шаги работы AI

• Анализ ER-модели: AI проанализировал структуру таблиц и связи, казанные в plantUML-коде

• Преобразование в SQL: для каждой сущности создалась таблица с полями, типами данных и внешними ключами

• Добавление ограничений: включил параметры PRIMARY KEY, FOREIGN KEY, NOT NULL в соответствии с моделью

• Синтаксический контроль: убедился в корректном SQL-синтаксисе для выбранных типов БД

• Логические связи: реализовал связи через внешние ключи

Чем полезен AI на данном этапе

• Сокращение времени: генерация SQL‑кода занимает секунды

• Согласованность с моделью: AI точно передал связи из ER‑модели в БД, устраняя риски ошибок, например, неправильного указания ключей

• Согласованность типов данных: автоматическое применение корректных типов минимизировало конфликты

• Нейтральность к SQL‑диалекту: Скрипты написаны в стандартной синтаксической форме, что упрощает их адаптацию под разные СУБД (PostgreSQL, MySQL).

Выводы

Делайте сами ?. Как и в предыдущих шагах — применение AI требует от аналитика проверки, уточнений и доработки результата. 

Шаг 9: Создание API-спецификации

1. Контекст задачи

После определения сервисов на предыдущих шагах необходимо сформировать «схему» их взаимодействия. AI помогает автоматизировать составление API-документации, значительно ускоряя этот процесс.

2. Взаимодействие с AI

Запрос аналитика

«Предложи API-спецификацию сервисов».

Пример ответа AI

openapi: 3.0.0
info:
  title: Email Signing and Sending Service
  description: Сервис для подписания и отправки писем с ЭЦП
  version: 1.0.0
servers:
  - url: https://api.email-signing.com/v1
    description: Production server
paths:
  /emails:
    post:
      summary: Отправка письма с подписанными вложениями
      description: Клиент отправляет письмо с вложениями, которые подписываются ЭЦП
      operationId: sendEmail
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              properties:
                subject:
                  type: string
                  description: Тема письма
                body:
                  type: string
                  description: Текст письма
                recipient:
                  type: string
                  description: Адресат письма
                attachments:
                  type: array
                  items:
                    type: string
                    format: binary
                    description: Вложения (PDF, DOCX, XML)
                key_id:
                  type: string
                  description: ID ключа ЭЦП
      responses:
        '202':
          description: Задача принята на обработку
          content:
            application/json:
              schema:
                type: object
                properties:
                  task_id:
                    type: string
                    example: "550e8400-e29b-41d4-a716-446655440000"
                  status:
                    type: string
                    example: "accepted"
        '400':
          description: Ошибка в данных запроса
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Missing required field: subject"
        '500':
          description: Внутренняя ошибка сервера
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Failed to sign attachment"
  /emails/{task_id}:
    get:
      summary: Получение статуса письма
      description: Клиент запрашивает статус задачи по ID
      operationId: getEmailStatus
      parameters:
        - name: task_id
          in: path
          required: true
          description: ID задачи
          schema:
            type: string
            example: "550e8400-e29b-41d4-a716-446655440000"
      responses:
        '200':
          description: Успешный ответ со статусом
          content:
            application/json:
              schema:
                type: object
                properties:
                  task_id:
                    type: string
                    example: "550e8400-e29b-41d4-a716-446655440000"
                  status:
                    type: string
                    example: "signed"
        '404':
          description: Задача не найдена
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Task not found"
 ..............................................................
 ..............................................................
  /auth/token:
    post:
      summary: Получение токена аутентификации
      description: Клиенты получают OAuth2-токен для доступа к API
      operationId: getAuthToken
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                client_id:
                  type: string
                client_secret:
                  type: string
      responses:
        '200':
          description: Токен успешно выдан
          content:
            application/json:
              schema:
                type: object
                properties:
                  access_token:
                    type: string
                  token_type:
                    type: string
                    example: "Bearer"
                  expires_in:
                    type: integer
                    example: 3600
        '401':
          description: Неверные учетные данные
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: string
                    example: "Invalid credentials"

Роль AI на данном этапе

AI автоматически сгенерировал RESTful API-спецификацию на основе предыдущих данных: структуры БД (ER-модель), бизнес-требований и технических требований (безопасность, механизмы аутентификации). Это избавило аналитика от необходимости создания документации с нуля.

Чем полезен AI на данном этапе

• Сокращение времени разработки

• Согласованность с требованиями: документация соответствует ранее сгенерированным требованиям в том же диалоге

• Детализация: включены технические детали (типы данных в SQL, коды ответов). Уровень детализации можно регулировать по мере общения с моделью

• Безопасность: реализованы стандарты безопасности (все запросы через HTTPS, проверка API‑ключей)

Выводы

На данном этапе использование AI принесло ряд выгодных решений: модель автоматически сгенерировала сложный документ, интегрировала все предыдущие требования, обеспечила техническую корректность и сохранила качество интерфейсов за счет современных стандартов (REST, OpenAPI). Это снижает риск ошибок на этапе проектирования, ускоряет реализацию и позволяет аналитику сосредоточиться на уточнении критических требований вместо рутинной документации.

Шаг 10: Создание sequence-диаграммы

1. Контекст задачи

Еще один этап работы системного аналитика в вопросе интеграционного взаимодействия — визуализация последовательности взаимодействия компонентов системы. Использование AI позволяет автоматически сгенерировать сложную UML-диаграмму, отражающую взаимодействие сервисов и обработку бизнес-операций (например, подписи вложений, логирования, отправку писем). Модель анализирует предыдущие этапы (ER-модель и API-интерфейсы) и генерирует структурированный код.

2. Взаимодействие с AI

Запрос аналитика

«Сгенерируй sequence-диаграмму в формате plantUML».

Полный ответ AI

 

Роль AI на данном этапе

AI создал UML-диаграмму на основе диагностических данных из предыдущих этапов (API-требований, ER-модели). Это избавило аналитика от ручного рисования элементов, обеспечив логическую согласованность между бизнес-процессами и архитектурой системы.

Чем полезен AI на данном этапе

• Сокращение времени разработки

• Согласованность с документацией: код отражает бизнес‑логику, согласованную с ER‑моделью и API‑спецификацией

• Детализация технической логики

Выводы

Использование AI для генерации sequence-диаграммы выявило ряд преимуществ:  аналитик получил визуализацию сложной системы, отслеживающую взаимодействие более 6 сервисов. Это уменьшит риски возникновения недопонимания между командами и кратно сократит время документирования.

Шаг 11: Разработка контракта взаимодействия Frontend/Backend

1. Контекст задачи

В качестве последнего шага рассмотрим кейс установления аналитиком четких правил взаимодействия между frontend-интерфейсом и backend-сервисами. AI на данном этапе используется для генерации сложной таблицы, которая систематизирует связи между визуальными элементами веб-интерфейса, HTTP-запросами и хранилищем данных, используя предыдущие результаты дизайна API и схемы БД.

2. Взаимодействие с AI

Запрос аналитика

«Опиши контракт взаимодействия frontend/backend. Контракт должен учитывать API-спецификацию, схему данных, ожидаемое поведение, сроки изменений, обработку ошибок и т.д.».

Пример ответа AI

Контракт взаимодействия Frontend/Backend

1. Обзор

• Цель: Определение структуры и правил взаимодействия между клиентскими приложениями (Frontend) и сервисами (Backend) для отправки писем с подписью ЭЦП.

• Формат данных: JSON для текстовых полей, multipart/form-data для вложений.

• Аутентификация: OAuth2 (токен в заголовке Authorization: Bearer <token>).

• Версионирование API: /v1/ в URL.

2. Детали взаимодействия

2.1 Отправка письма с подписью

• Метод: POST /v1/emails

• Формат данных:

  • multipart/form-data:

    • subject (string, обязательный)

    • body (string, обязательный)

    • recipient (string, обязательный)

    • attachments (array of files, форматы: PDF, DOCX, XML)

    • key_id (string, обязательный)

• Ответ:

  • 202 Accepted:

    {
      "task_id": "550e8400-e29b-41d4-a716-446655440000",
      "status": "accepted"
    }
    

2.2 Получение статуса письма

• Метод: GET /v1/emails/{task_id}

• Ответ:

  • 200 OK:

    {
      "task_id": "550e8400-e29b-41d4-a716-446655440000",
      "status": "signed",
      "updated_at": "2024-03-25T10:00:00Z"
    }
    

  • 404 Not Found:

    {
      "error": "Task not found"
    }
    

2.3 Загрузка ключа ЭЦП

• Метод: POST /v1/keys

• Формат данных:

  • multipart/form-data:

    • key_type (string, обязательный, значения: PEM, PKCS#12)

    • key_data (file, обязательный)

    • expiration_date (datetime, обязательный)

• Ответ:

  • 201 Created:

    {
      "key_id": "550e8400-e29b-41d4-a716-446655440001",
      "is_active": true
    }
    

  • 400 Bad Request:

    {
      "error": "Invalid key format"
    }
    

...

3. Схемы данных

3.1 Запрос на отправку письма

{
  "subject": "string",
  "body": "string",
  "recipient": "string",
  "attachments": ["file1.pdf", "file2.docx"],
  "key_id": "string"
}

3.2 Ответ на отправку письма

{
  "task_id": "uuid",
  "status": "accepted | signed | sent | error"
}

3.3 Ответ на статус письма

{
  "task_id": "uuid",
  "status": "accepted | signed | sent | error",
  "updated_at": "datetime"
}

3.4 Ответ на ошибку

{
  "error": "string",
  "error_type": "validation | signing | smtp | audit",
  "details": "string"
}

4. Ожидаемое поведение

5. Сроки изменений и версионирование

• Версионирование: /v1/ в URL.

• Срок поддержки версии: 6 месяцев.

• Изменения API:

  • Новые версии API объявляются за 30 дней до внедрения.

  • Изменения в существующих эндпоинтах требуют согласования с клиентами.

  • Пример: /v2/emails будет поддерживать новые форматы вложений (например, XLSX).

6. Обработка ошибок

• Коды ошибок:

  • 400 Bad Request: Ошибка валидации данных.

  • 401 Unauthorized: Неверный или истёкший токен.

  • 404 Not Found: Запрашиваемый ресурс не существует.

  • 500 Internal Server Error: Внутренняя ошибка системы.

• Формат ответа:

  {
    "error": "Ошибка подписания ключа",
    "error_type": "signing",
    "details": "Недействительный ключ"
  }
  

7. Политики безопасности

• Аутентификация:

  • Все запросы должны содержать заголовок Authorization: Bearer <token>.

  • Токены выдаются через /auth/token и действуют 1 час.

• Роли:

  • admin: Может управлять ключами.

  • client: Может отправлять письма и получать статусы.

• Шифрование:

  • Все данные передаются через HTTPS.

  • Ключи ЭЦП хранятся в HSM, шифрованные с AES-256.

• Ограничения:

  • Максимальный размер вложения: 10 МБ.

  • Максимальный размер письма: 20 МБ.

8. Тестирование и мониторинг

• Тестирование:

  • Frontend должен обрабатывать ошибки 400/500 и отображать пользователю.

  • Backend должен поддерживать retry-механизм при сбое SMTP (до 3 попыток).

• Мониторинг:

  • Метрики времени подписания и доставки доступны через /v1/metrics.

  • Логи ошибок сохраняются 6 месяцев и доступны через /v1/logs.

9. Приложения

• Примеры запросов:

  POST /v1/emails
  Content-Type: multipart/form-data
  Authorization: Bearer <token>
  
  --boundary
  Content-Disposition: form-data; name="subject"
  Заявка на подписание
  --boundary
  Content-Disposition: form-data; name="body"
  Пожалуйста, подтвердите подписание договора.
  --boundary
  Content-Disposition: form-data; name="recipient"
  user@example.com
  --boundary
  Content-Disposition: form-data; name="attachments"; filename="contract.pdf"
  [бинарные данные файла]
  --boundary
  Content-Disposition: form-data; name="key_id"
  550e8400-e29b-41d4-a716-446655440001
  --boundary--
  

• Пример ответа на статус:

  GET /v1/emails/550e8400-e29b-41d4-a716-446655440000
  Authorization: Bearer <token>
  
  200 OK
  {
    "task_id": "550e8400-e29b-41d4-a716-446655440000",
    "status": "signed",
    "updated_at": "2024-03-25T10:00:00Z"
  }
  

---

Ключевые моменты

• Frontend должен:

  • Поддерживать multipart/form-data для вложений.

  • Обрабатывать ретраи при сбоях в подписании или отправке.

  • Опрашивать статус задачи каждые 5 секунд.

  • Отображать ошибки в понятном пользователю формате.

• Backend должен:

  • Принимать данные письма и вложения.

  • Обновлять статус задачи в реальном времени.

  • Подписывать вложения по ГОСТ Р 34.10-2012.

  • Возвращать структурированные ошибки с детализацией.

---

Роль AI на данном этапе

AI сгенерировал таблицу взаимодействия между frontend, backend и БД, проанализировав предыдущие компоненты системы.

Чем полезен AI на данном этапе

• Сокращение количества рутинной работы и исключение ручных ошибок: AI генерирует полный вариант таблицы, состоящей из десятков соединений, за секунды

• Согласованность: модель применяет ранее заданные названия таблиц/колонок (из SQL) и пути API (из спецификации), минимизируя опечатки и противоречия

• Комплектность ответа: помимо таблицы, AI автоматически формулирует разделы с примерами, валидацией и комментариями, что экономит время на систематизацию

• Повышение качества: модель проверяет соответствия через интеграцию с предыдущими этапами

Выводы

Использование AI на этапе формирования контракта frontend/backend продемонстрировало его эффективность в рамках автоматизации сложной документации. Модель не только разработала структуру взаимодействия, но и применила консистентные данные из предыдущих этапов, что обеспечило уверенность в корректности интеграции. AI перенес семантику системы в собственное знание, визуализируя его в необходимом формате — это очередной кейс, когда искусственный интеллект становится партнером.

Заключение: AI — не замена, а инструмент

Интеграция искусственного интеллекта в работу системного аналитика открывает новые перспективы. Принципиально важно понимать, что AI не заменяет специалиста, а служит эффективным инструментом для повышения его продуктивности. Модель берет на себя рутину (генерацию документации, диаграмм, тест-кейсов), освобождая время для стратегических задач. Наша практика в Лаборатории инноваций Московской биржи показывает: чем точнее аналитик формулирует запросы, тем качественнее результат. ИИ обрабатывает гигабайты данных, предлагает варианты архитектуры и API, но финальные решения всегда требуют экспертной проверки и адаптации.

Ключевое преимущество — синергия человеческого опыта и машинной скорости. Новички получают готовые шаблоны, профессионалы — возможность быстрее масштабировать решения. Однако ИИ лишь предлагает гипотезы: ответственность за корректность требований, выбор архитектуры и итоговое качество системы остается за аналитиком.

Итог: AI не угроза профессии, а ее естественное развитие. Он не мыслит, а обрабатывает — но именно это позволяет специалисту сосредоточиться на том, где незаменим человеческий интеллект: креативности, сложных решениях и коммуникации. Главное — научиться ставить четкие задачи и сохранять критическое мышление, используя ИИ как мощный, но подконтрольный инструмент.