Агент в задачах
системного аналитика

Модуль 3 — Требования, API, моделирование, верификация Практический модуль 70% практика

Программа обучения системных аналитиков работе с ИИ-агентами
Практика на DigitalWallet + Banking-App

Карта модуля

3.1

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

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

3.2

API и интеграции

OpenAPI/Swagger, тестовые сценарии для контрактов, таблицы соответствий между системами

3.3

Моделирование

Генерация Mermaid/PlantUML диаграмм, восстановление из кода

3.4

Когда агент ошибается

Типы ошибок, способы обнаружения, стратегии проверки результатов

Четыре подмодуля, каждый — с теорией, сценарием и практикой. 3.1 — Анализ требований. Агент читает код и восстанавливает бизнес-требования. Мечта аналитика на проекте без документации. 3.2 — API и интеграции. Анализ Swagger-спецификаций, генерация тестовых сценариев, таблицы соответствий данных между системами. 3.3 — Моделирование. Генерация sequence-диаграмм, activity-диаграмм прямо из кода. 3.4 — Самый важный. Когда и как агент ошибается. Без этого знания все предыдущие навыки опасны. Обратите внимание: 3.4 выделен красным — это не случайно. Верификация — ключевой навык.

3.1 Анализ требований из кода

Нет документации? Агент восстановит требования из исходного кода

DigitalWallet: генерация требований из кода

У проекта нет формального документа требований — только README и код

Инструкция агенту: «Проанализируй проект DigitalWallet. На основе контроллеров, доменных моделей и README восстанови полный список функциональных требований. Для каждого: ID, описание, статус реализации, критичность. Отдельно выдели пробелы — что должно быть в wallet-сервисе, но отсутствует. Сохрани в requirements-matrix.md»

✓ Матрица из 15+ требований. Агент анализирует контроллеры, модели, миграции — формирует структурированную матрицу. Готовая основа для уточнения бэклога.

Классическая ситуация: вы приходите на проект, а документации нет. Есть только код и README. Раньше аналитик бы неделю читал код, разговаривал с разработчиками, составлял требования вручную. С агентом — один промпт. Обратите внимание на формулировку: это идеальный промпт по структуре из Модуля 2 — контекст, задача, ограничения, критерии. Контекст: DigitalWallet. Задача: восстановить требования. Ограничения: формат матрицы с полями. Критерии: ID, статус, критичность, отдельно пробелы. Файл результата. Результат — 15+ требований за 5 минут. Давайте посмотрим, как выглядит результат.

Результат: матрица требований

ID	Требование	Статус	Критичность
FR-01	Создание кошелька с указанием валюты	Реализовано	Высокая
FR-02	Пополнение кошелька (WalletFunds)	Реализовано	Высокая
FR-03	Перевод между кошельками	Частично	Высокая
FR-04	Мультивалютная конвертация	Частично	Средняя
FR-05	Лимиты на транзакции	Не реализовано	Высокая

Пробелы, выявленные агентом:

Нет лимитов на транзакции (суммы, количество в день)
Отсутствует механизм отмены/возврата
Нет аудит-лога операций
Не описаны NFR (производительность, доступность)

Вот как выглядит результат. Матрица с ID, описанием, статусом реализации и критичностью. Зелёное — реализовано. Оранжевое — частично. Красное — не реализовано. Но самое ценное — блок пробелов внизу. Агент не просто описал то, что есть, а подумал, чего НЕ хватает для полноценного wallet-сервиса. Нет лимитов — это risk для финтеха. Нет возвратов — а как быть с ошибочными переводами? Нет аудит-лога — регуляторные требования. Это готовый материал для уточнения бэклога. Аналитик проверяет, дополняет своей экспертизой и несёт в команду. Ключевой момент: агент может пропустить что-то важное. Поэтому модуль 3.4 — про верификацию.

3.2 API и интеграции

Анализ контрактов, тестовые сценарии, таблицы соответствий между системами

Агент умеет:

→ Анализировать OpenAPI/Swagger-спецификации, находить проблемы
→ Генерировать тестовые сценарии для API-контрактов (позитивные + негативные)
→ Строить таблицы соответствий данных между системами

DigitalWallet
наш API

↔

Таблица
соответствий

↔

Banking-App
приложение партнёра

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

Подмодуль 3.2 — работа с API и интеграциями. Три ключевые задачи. Первая — анализ Swagger. Агент читает OpenAPI-спецификацию и находит: отсутствующие описания, несогласованные коды ошибок, проблемы с типами данных. Вторая — генерация тестовых сценариев. По API-контракту агент генерирует позитивные и негативные кейсы: «что если сумма = 0? отрицательная? слишком большая?» Третья — таблица соответствий данных. Типичная ситуация: к вам приходит партнёр или вендор со своим приложением и хочет интегрироваться с вашим API. Нужно понять: какие их модели соответствуют нашим, где нужна конвертация, а чего у нас вообще нет. В нашем учебном сценарии: DigitalWallet — это «наш» серверный API, а Banking-App — «приложение партнёра», которое хочет с нами работать. Агент анализирует модели обоих проектов и строит таблицу соответствий. Давайте посмотрим результат.

Результат: таблица соответствий данных

Наш API (DigitalWallet)	Партнёр (Banking-App)	Трансформация	Комментарий
`Wallet.Balance` decimal	`Account.balance` MoneyAmount	decimal → MoneyAmount	Прямое соответствие
`Currency.Code` enum	`currency` String	enum → String	Конвертация типа
`Transaction.Type` enum	`TransactionType` sealed class	enum → sealed class	Разные подходы
—	`QrPayment`	—	Нет аналога в API!

Пробелы видны сразу → готовый материал для задачи на интеграцию

Таблица соответствий — один из самых полезных артефактов для аналитика при интеграции. Первая строка — прямое соответствие: Balance → MoneyAmount, просто конвертация типа. Вторая — Currency. В бэкенде это enum, в мобилке — строка. Нужна конвертация. Третья — Transaction Type. Разные подходы: enum в .NET, sealed class в Kotlin. Нужна функция преобразования. Четвёртая — самое интересное. QR-платежи есть в приложении партнёра, но нет в нашем API! Это пробел — партнёр ожидает эту функцию, а у нас её нет. Значит, нужна доработка — новый эндпоинт. Агент это нашёл автоматически, просто сопоставив модели двух проектов. Такая таблица — первое, что делает аналитик при любой интеграции с внешней системой. Готовый артефакт для задачи на доработку.

3.3 Моделирование из кода

Агент читает код → строит sequence/activity диаграммы в Mermaid

 Ответ агента
sequenceDiagramparticipantCasClientparticipantCtrlasControllerparticipantTHasTransferHandlerparticipantWRasWalletRepoparticipantDBasDatabaseC->>Ctrl: POST /api/transferCtrl->>TH: TransferCommandTH->>WR: GetWallet(fromId)
    WR-->>TH: Wallet entityaltbalance < amountTH-->>Ctrl: 400 Insufficient fundselsesuccessTH->>DB: SaveChanges()
        Ctrl-->>C: 200 OKend

%%{init: {'theme': 'neutral', 'themeVariables': {'actorBkg': '#4361ee', 'actorTextColor': '#fff', 'actorBorder': '#4361ee', 'signalColor': '#1a1a2e', 'signalTextColor': '#1a1a2e', 'altSectionBkgColor': '#eef0ff', 'noteBkgColor': '#fff4e5'}}}%%
sequenceDiagram
    participant C as Client
    participant Ctrl as Controller
    participant TH as TransferHandler
    participant WR as WalletRepo
    participant DB as Database

    C->>Ctrl: POST /api/transfer
    Ctrl->>TH: TransferCommand
    TH->>WR: GetWallet(fromId)
    WR-->>TH: Wallet entity

    alt balance < amount
        TH-->>Ctrl: 400 Insufficient funds
    else success
        TH->>DB: SaveChanges()
        Ctrl-->>C: 200 OK
    end

Итеративно: «Добавь ветку мультивалютной конвертации с CurrencyService» → агент дополняет

Подмодуль 3.3 — генерация диаграмм из кода. Аналитику нужно задокументировать процесс перевода средств. Документации нет — только код. Вы даёте агенту задачу — и он выдаёт вот такой Mermaid-код. Текст, который можно прочитать. [КЛИК] — и этот код превращается в визуальную диаграмму. Вставляется в Confluence, markdown, документацию. Агент прослеживает цепочку вызовов: Controller → TransferHandler → WalletRepo → Database. Обратите внимание: агент добавил альтернативную ветку — «если баланс недостаточен». Это он нашёл в коде валидацию и отразил в диаграмме. [КЛИК] — и ключевой момент: итеративность. Вы говорите «добавь мультивалютную конвертацию» — агент дополняет диаграмму. Не нужно рисовать с нуля. Mermaid, PlantUML — агент работает с обоими форматами. Выбирайте тот, который у вас в команде принят.

3.4 Когда агент ошибается

Четыре типа ошибок, которые нужно уметь распознавать

👻 Галлюцинация фактов

Агент «видит» несуществующие эндпоинты, классы или поля в коде

«В контроллере есть метод RefundTransaction» — а его нет

😤 Ложная уверенность

Утверждает наличие валидации или обработки ошибок, которой нет

«Все суммы проверяются на > 0» — а проверки нет в коде

🕳️ Пропуск информации

Находит 5 из 8 контроллеров, не сообщая о неполноте результата

«Я нашёл все контроллеры: ...» — а три пропустил

🎭 «Додумывание» логики

Достраивает бизнес-логику, которая выглядит правдоподобно, но не соответствует коду

«При переводе автоматически конвертируется валюта» — а нет

Самый важный слайд модуля. Четыре типа ошибок агента. Галлюцинация — агент уверенно говорит о том, чего нет. «Метод RefundTransaction» — а его нет в коде. Это классика LLM-ошибок: модель генерирует правдоподобный текст. Ложная уверенность — хуже галлюцинации. Агент утверждает, что валидация есть, вы верите, а потом на проде оказывается, что можно создать транзакцию на -1000 рублей. Пропуск — агент не говорит «я не уверен, что нашёл всё». Он говорит «вот все контроллеры», хотя нашёл только 5 из 8. Додумывание — самое коварное. Агент достраивает бизнес-логику так, как «должно быть», а не так, как реально написано в коде. Все четыре типа опасны. Но у нас есть стратегии защиты.

Стратегии верификации

📌 На основе фактов

Всегда просить агента указать конкретный файл и строку кода

«Покажи, где именно реализована валидация суммы — файл и строка»

🔄 Перекрёстный анализ

Задать тот же вопрос с другой стороны — инвертировать

«Найди всё, чего НЕ хватает в обработке ошибок»

🔬 Декомпозиция проверки

Разбить крупный вывод на мелкие утверждения и проверить каждое

«Утверждение: кошелёк проверяется на существование. Покажи код»

Не спрашивай «есть ли X?» → спрашивай «покажи, где именно X реализован»

Три стратегии, которые спасут вас от ошибок агента. На основе фактов — главная стратегия. Никогда не принимайте утвердительный ответ без доказательства. «Да, валидация есть» — не достаточно. «Файл TransferHandler.cs, строка 42, метод Validate» — вот это доказательство. Перекрёстный анализ — инвертируйте вопрос. Не «что хорошо?», а «что плохо?». Не «есть ли валидация?», а «найди, чего НЕ хватает». Агент на негативные вопросы отвечает честнее — нет давления «угодить». Декомпозиция — если агент дал большой вывод из 10 пунктов, не верьте сразу. Возьмите каждый пункт отдельно и попросите доказательство. Золотое правило на слайде. Запишите его: никогда не спрашивайте «есть ли?» — спрашивайте «покажи где».

Два проекта для практики

DigitalWallet

thisisnabi/DigitalWallet

E-Commerce Wallet Service — кошельки, мультивалютность, транзакции, пополнение/списание

Backend API → требования, API-анализ, диаграммы

ASP.NET Core EF Core Swagger ~3-8K LOC

Banking-App-Mock-Compose

alexandr7035/Banking-App-Mock-Compose

Android Banking App — карты, переводы, QR-платежи, профиль, Clean Architecture + Compose

Mobile → прослеживание цепочки вызовов, доменные модели, таблицы соответствий

Kotlin Jetpack Compose Room ~20K LOC

Кросс-проект: соответствие данных между серверным API и мобильными моделями

В этом модуле мы работаем с двумя проектами. DigitalWallet — знакомый вам по модулям 0-2. Backend API на .NET. Здесь мы будем анализировать требования, делать ревью API, строить диаграммы. Banking-App — новый проект. Android-приложение банка на Kotlin с Jetpack Compose. Clean Architecture, Room для локальной базы, красивый UI. Здесь мы будем прослеживать цепочку вызовов через слои (UI → ViewModel → UseCase → Repository), документировать доменные модели. И самое интересное — кросс-проектная работа: соответствие данных между сервером и мобильным приложением. Это реальная задача аналитика при интеграции систем.

Практика

5 заданий на двух проектах

1
Восстановить требования из кода DigitalWallet — матрица с ID, статусом, пробелами DigitalWallet
2
Прослеживание цепочки «Отправить деньги» через Clean Architecture: UI → ViewModel → UseCase → Repository → Room DB Banking-App
3
Таблица соответствий данных между DigitalWallet API и Banking-App моделями Кросс-проект
4
Верификация: задать агенту вопрос, получить ответ, проверить по коду. Зафиксировать: что додумал, что пропустил Верификация
5
Парная работа: один формулирует задачу, второй оценивает качество ответа агента и ищет ошибки Парная

Пять заданий — это примерно 3 часа практики. Задание 1 — восстановление требований из DigitalWallet. Применяем то, что видели в 3.1. Используйте промпт из сценария, адаптируйте под себя. Задание 2 — прослеживание цепочки вызовов в Banking-App. Это новый проект, Clean Architecture. Попросите агента пройти от UI до Room DB. Сравните со своим пониманием. Задание 3 — кросс-проект. Маппинг моделей. Клонируйте оба репозитория, дайте агенту задачу. Задание 4 — верификация. Самое важное! Задайте вопрос, получите уверенный ответ, проверьте по коду. Зафиксируйте, где агент ошибся. Задание 5 — парная работа. Один пишет промпт, второй проверяет результат. Это прекрасно тренирует навык критического мышления.

Итоги Модуля 3

3.1 Требования: агент восстанавливает бизнес-требования из кода — матрица + пробелы
3.2 API: анализ контрактов, тестовые сценарии, таблицы соответствий между системами
3.3 Модели: sequence/activity диаграммы из кода, Mermaid/PlantUML, итеративная доработка
3.4 Верификация: Не «есть ли X?» → «покажи, где X реализован»

Далее → Модуль 4: Работа с данными и кодом — SQL, миграции, code review, рефакторинг с агентом

Четыре ключевых вывода: 1. Агент — мощный инструмент для анализа требований. 15 минут вместо недели. Но всегда проверяйте. 2. API-анализ и таблицы соответствий — рутина, которую агент делает отлично. Кросс-проектная работа — реальная задача. 3. Диаграммы из кода — один промпт вместо часа в draw.io. И можно итеративно дополнять. 4. Верификация — САМЫЙ ВАЖНЫЙ навык. Золотое правило: не «есть ли?», а «покажи где». Агент — инструмент, ответственность — на вас. В следующем модуле — работа с данными и кодом. SQL-запросы, анализ миграций, code review. Подключим третий проект — Mifos mobile-wallet на Kotlin Multiplatform. А пока — домашнее задание на следующем слайде.

Домашнее задание

Применить навыки модуля 3 на своём рабочем проекте

Восстановить требования из своего проекта ⏱ 30 мин

Выбрать модуль или сервис, где документация отсутствует или устарела. Попросить агента восстановить функциональные требования из кода. Матрица: ID, описание, статус, критичность, пробелы.

Например: модуль оплаты, сервис уведомлений, процесс создания заявки

Построить диаграмму процесса ⏱ 25 мин

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

Например: оформление заказа, проведение платежа, регистрация клиента

Проверить 3 утверждения агента по коду ⏱ 20 мин

Взять результат задания 1 или 2. Выбрать 3 утверждения агента и применить правило «на основе фактов»: попросить показать конкретный файл и строку. Зафиксировать: что утверждал → что в коде → совпало или нет.

Главное правило: не «есть ли X?» → «покажи, где именно X реализован»

Если рабочий проект недоступен — используйте Banking-App из занятия

Домашнее задание — три задания, и все на вашем реальном рабочем проекте. Это самое ценное, что можно сделать: применить навыки модуля 3 к своей настоящей работе. Первое — восстановление требований. Выберите модуль или сервис, где документация устарела или её вообще нет. У каждого из вас такой точно есть. Модуль оплаты, сервис уведомлений, процесс создания заявки — что угодно. Попросите агента проанализировать код и восстановить требования. Результат — матрица, которую вы реально сможете использовать в работе. Второе — диаграмма процесса. Выберите один бизнес-сценарий. Оформление заказа, проведение платежа, регистрация клиента — любой. Попросите агента построить sequence-диаграмму в Mermaid. Потом попросите добавить обработку ошибок — это итеративная доработка из модуля 2. Эту диаграмму тоже можно сразу использовать — вставить в Confluence, показать команде. Третье — самое важное. Проверка. Возьмите результат первого или второго задания. Выберите три утверждения агента. Не верьте на слово — попросите показать файл и строку. Для каждого зафиксируйте: что агент сказал, что реально в коде, совпало или нет. Гарантирую — минимум одно из трёх не совпадёт. И это нормально. Именно поэтому навык проверки — ключевой. Если у кого-то нет доступа к рабочему проекту с локальной машины или есть ограничения по безопасности — используйте Banking-App, который мы разбирали на занятии. Но постарайтесь работать со своим проектом — польза несравнимо выше. На следующем занятии обсудим результаты: у кого что получилось, где агент ошибся, какие артефакты удалось создать для реальной работы.

Агент в задачахсистемного аналитика