Практический разбор на примерах: сбор требований, диаграммы, Use Cases и ТЗ. Плюсы, минусы,подводные камни и промт-чеклист для системного аналитика.

Введение
ИИ-инструменты, вроде GPT, Claude или Qwen, активно внедряются в ежедневную работу системного аналитика. Но насколько они действительно полезны? Могут ли они заменить аналитика?
В этой статье я разберу 3 сценария использования ИИ в работе системного аналитика:
Сбор требований и уточнение деталей.
Моделирование процессов и генерация диаграмм.
Написание пользовательских историй и Use Cases.
Для каждого сценария покажу:
Промты разного уровня детализации.
Результаты от разных моделей (ChatGPT, Qwen, DeepSeek).
Что получилось хорошо, а что — нет.
Сколько времени удалось сэкономить.
Спойлер
ИИ не заменит аналитика, но может сэкономить ему до 70% времени на рутине. Если, конечно, уметь с ним работать.
1. Сбор требований: как задавать правильные вопросы, даже если вы их ещё не знаете

Задача: Стейкхолдер говорит: «Нужен личный кабинет с возможностью просмотра заказов и изменения контактных данных». Надо подготовить список уточняющих вопросов.
Промт (базовый):
Ты — опытный системный аналитик. Сформируй список уточняющих вопросов для стейкхолдера по описанию: «Нужен личный кабинет с возможностью просмотра заказов и изменения контактных данных».
Результат: ИИ выдал общие вопросы, но много «шума» — вопросы про интеграции, безопасность, мобильную версию, хотя контекст не ясен.
Промт (структурированный):
Ты выступаешь в роли опытного системного аналитика. На вход ты получаешь краткое описание функционала. Твоя задача - сформировать список уточняющих вопросов для стейкхолдера, которые помогут подготовить детальные функциональные требования. Требования к вопросам: Они должны быть конкретными, а не общими. Сфокусируйся на бизнес‑логике. Определи роли пользователей (кто и как взаимодействует с системой). Выяви ограничения (регуляторные, технические, временные, доступность данных). Обрати внимание на альтернативные сценарии (исключения, нештатные ситуации). Укажи зависимости и интеграции с другим функционалом или внешними системами. Старайся формулировать вопросы так, чтобы стейкхолдеру было легко дать чёткий и недвусмысленный ответ. В конце сгруппируй вопросы по блокам: Бизнес-логика, Роли пользователей, Ограничения, Альтернативные сценарии, Зависимости. Будь краток и задавай вопросы только по существу. Описание функционала:"Нужен личный кабинет с возможностью просмотра заказов и изменения контактных данных."
Сравнительная таблица «Результаты промтов: Базовый vs. Структурированный»
Критерий | Промт 1 (Базовый) | Промт 2 (Структурированный) |
Конкретность | ❌ Вопросы общие, много абстракций: «Какие данные обязательны?», «Нужны ли уведомления?» | ✅ Вопросы сфокусированы на деталях: «Какие именно контактные данные можно изменять?», «Какие статусы заказа должны отображаться?» |
Структура | ❌ Список вопросов без группировки, хаотичный порядок | ✅ Вопросы сгруппированы по блокам: «Бизнес-логика», «Роли», «Ограничения», «Альтернативные сценарии», «Зависимости» |
Пригодность для стейкхолдера | ❌ Сложно отвечать — вопросы размытые, требуют дополнительных уточнений | ✅ Удобно для ответа — вопросы конкретные, сфокусированы на бизнес-логике, стейкхолдер может дать чёткие ответы |
Эффективность | Требует последующей переработки аналитиком | ✅ Готов к использованию после минимальной правки |
Пример вопроса | «Планируется ли интеграция с другими системами?» (без уточнений) | «Нужно ли показывать историю заказов полностью или только актуальные/последние?» |
🏆 Результат: Гораздо лучше. ChatGPT, Qwen и DeepSeek выдали структурированные списки.
Что сработало:
✅ Группировка по блокам помогает систематизировать вопросы.
✅ Уточнение «без общих фраз» снизило уровень «воды».
✅ Разные модели дополняют друг друга — Qwen, например, спросил про скрытие заказов со статусом «Отменён».
Что не сработало:
❌ Часть вопросов всё ещё слишком абстрактна.
❌ ИИ не знает контекста компании — например, про внутренние интеграции.
Вывод: ИИ может сгенерировать 80% вопросов за 5 минут вместо 40 минут ручной работы. Но финальный отбор, переформулировка и контекстуализация — за аналитиком.
2. Моделирование процессов: как заставить ИИ нарисовать диаграмму, которую не стыдно показать архитектору
Задача: Описать процесс регистрации пользователя в интернет-магазине в виде диаграммы последовательности (PlantUML).
Промт (базовый):
Сгенерируй код для диаграммы последовательности в PlantUML для процесса регистрации пользователя.
Результат: Схема с низким уровнем детализации.

Прошло несколько итераций перед тем как я получила устраивающий меня вариант
Промт (детальный):
Сгенерируй код для диаграммы последовательности в PlantUML, описывающий процесс регистрации пользователя в интернет-магазине. Участники системы: Пользователь (Actor), Front-end (Интерфейс), Сервис регистрации, БД "Пользователи". Обязательные поля: Фамилия, Имя, Номер телефона. Важно учесть альтернативные сценарии: Данный пользователь уже существует в системе, Невалидные данные (фамилия, имя, телефон), Таймаут соединения. Добавь требования к указанию HTTP-статусов и сообщений об ошибках. Технические требования: Используй разделители для логических блоков. Добавь автонумерацию сообщений. Примени разные типы стрелок для синхронных и асинхронных операций. Добавь примечания (note) для сложных операций. Верни только код plantuml
Итоговый результат

🏆 Результат: Диаграмма стала детальной, с alt-блоками, сообщениями об ошибках.
Что сработало:
✅ Чем более детализированный промт — тем лучше результат.
✅ Возможность быстрой отладки благодаря поддержке plantuml-кода.
Что не сработало:
❌ ИИ не понимает нюансов бизнес-логики (например, «подтверждение телефона через SMS»).
❌ Требуется ручная доработка названий и порядка шагов.
Вывод: ИИ генерирует каркас диаграммы за 10–15 минут вместо 30 минут. Но логику исключений и бизнес-правила добавляет только человек.
3. Use Cases: от шаблонных текстов до тех. спецификаций
Задача: Описать Use Case «Сортировка отзывов в карточке товара».
Промт (базовый):
Ты - опытный системный-аналитик. Твоя задача --- подготовить максимально подробный use case на основе моего описания. Контекст:
Система: "Сайт интернет-магазина". Use Case: "Сортировка отзывов в карточке товара". Основной актор: "Покупатель" и "Веб-сайт"
Результат — размытые формулировки, нет технических деталей.
Промт (детализированный, с требованиями к структуре):
Роль: Ты — опытный системный аналитик, эксперт по описанию требований через use case. Задача: На основе контекста ниже подготовь максимально подробный, структурированный и технически корректный use case, ориентированный на реализацию в веб-приложении. Контекст: Система: сайт интернет-магазина. Use Case: сортировка отзывов в карточке товара. Акторы: Пользователь, Веб-сайт (фронтенд + бэкенд). Требования к формату use case: 1) Название — краткое и содержательное. 2) Краткое описание — 1–2 предложения, отражающие цель и суть сценария. 3) Акторы — все участники с указанием основного и второстепенных. 4) Предусловия — что должно быть истинно до начала сценария. 5) Постусловия — состояние системы и данных после успешного завершения. 6) Основной сценарий — нумерованный «счастливый путь» (1..N), пошагово, атомарные действия с указанием взаимодействия акторов и системы. 7) Альтернативные сценарии — все значимые ошибки, исключения, граничные случаи и ветвления с отсылкой к шагам основного сценария (например: отсутствие отзывов, ошибка сервера, некорректный параметр сортировки и т.п.). Дополнительно: Используй профессиональную терминологию, но без излишней абстракции. Учитывай как клиентскую (фронтенд), так и серверную (бэкенд) логику.
🏆 Результат — конкретные шаги, API-эндпоинты, HTTP-статусы, альтернативные сценарии с привязкой к шагам.
Пример фрагмента (результат работы ChatGPT):
Шаги основного сценария, предложенные ChatGPT:
Основной сценарий | 1 | Покупатель открывает страницу карточки товара (например, перейдя по ссылке из каталога). |
2 | Веб-сайт загружает данные о товаре и список опубликованных отзывов через API (например, GET /api/products/{id}/reviews?page=1&sort=date_desc). | |
3 | Фронтенд отображает отзывы в порядке по умолчанию (date_desc — от новых к старым). | |
4 | Покупатель замечает элемент управления сортировкой (выпадающий список с опциями). | |
5 | Покупатель выбирает критерий сортировки, например «По рейтингу: от высокого к низкому» (rating_desc). | |
6 | Фронтенд формирует новый запрос к бэкенду: GET /api/products/{id}/reviews?page=1&sort=rating_desc | |
7 | Бэкенд валидирует параметр sort, проверяет его на соответствие списку допустимых значений. | |
8 | Бэкенд извлекает из базы данных отзывы по product_id, применяет сортиров и возвращает результат в теле ответа на запрос. | |
9 | Фронтенд получает ответ, очищает текущий блок отзывов и рендерит обновлённый список. | |
10 | Покупатель видит отсортированные отзывы и может продолжить взаимодействие с сайтом. |
Шаги альтернативного сценария, предложенные ChatGPT:
Альтернативный сценарий 1 – У товара нет отзывов (отклонение от 2 шага основного сценария)
| 1 | Бэкенд возвращает пустой массив отзывов. |
2 | Фронтенд отображает сообщение: «Отзывов пока нет. Будьте первым!» | |
3 | Элемент сортировки скрыт или неактивен. | |
4 | Use Case завершается — сортировка недоступна. | |
Альтернативный сценарий 2 - Ошибка при выполнении API-запроса (отклонение от шага 8) | 1 | Бэкенд возвращает HTTP-статус 5xx или 4xx |
2 | Фронтенд отображает уведомление: «Не удалось загрузить отсортированные отзывы. Повторите попытку позже.» | |
3 | Блок отзывов остаётся в предыдущем состоянии. | |
4 | URL не изменяется. | |
5 | Элемент сортировки возвращается к предыдущему значению. | |
Альтернативный сценарий 3 - Недопустимый параметр сортировки (отклонение от шага 7) | 1 | Покупатель вручную подменил URL: ?review_sort=unknown_value. |
2 | Бэкенд отклоняет параметр как недопустимый и применяет сортировку по умолчанию (date_desc). | |
3 | Фронтенд корректирует URL заменяя параметр на корректный. | |
4 | Покупатель видит отзывы в порядке по умолчанию без ошибок. |
Что сработало:
✅ Чёткая структура (Предусловия, Постусловия, Основной сценарий, Альтернативы).
✅ Технические детали — эндпоинты, статусы, параметры.
Что не сработало:
❌ ИИ может «галлюцинировать» — например, добавить несуществующие поля.
❌ Бизнес-контекст (например, «показывать только отзывы с рейтингом > 3») нужно добавлять вручную.
Вывод: ИИ помогает быстро набросать каркас Use Case, но детализацию и валидацию должен делать аналитик.
Темная сторона ИИ: о чём молчат в маркетинговых статьях

Галлюцинации — ИИ может придумать несуществующие сущности, поля, API.
Качество входных данных — «
мусор на входеплохой промт → мусор на выходе». Промт надо уметь составлять.Безопасность — загрузка конфиденциальных данных в облачные ИИ-сервисы рискованна. Лучше использовать локальные решения (например, корпоративный GPT).
Ответственность — итоговое решение, валидация и подписание ТЗ остаются за аналитиком.
Заключение: ИИ как ассистент, а не замена аналитика

ИИ-инструменты не заменяют системного аналитика, но становятся его ассистентом, который:
Ускоряет рутину на 60–70%.
Помогает структурировать мысли.
Генерирует каркасы документов.
ИИ позволяет аналитику сосредоточиться на главном: глубоком понимании бизнеса, принятии решений, формировании четких требований для разработки. Важно использовать GPT с умом, не как замену аналитика, а как решение позволяющее ускорить его работу.
Грамотный промт — залог качественного результата. Поэтому, для работы с ИИ необходимо учиться промт-инжинирингу, ну а если времени для глубокого погружения в тему сейчас нет, то можно пользоваться чеклистом ниже
Промт-чеклист для системного аналитика:
Сформулируй конкретную цель и ожидаемый результат (что нужно и для кого).
Задай роль ИИ и уровень детализации («ты — опытный системный аналитик в области …»).
Опиши контекст: система, пользователи, ключевые ограничения.
Укажи формат и структуру ответа (список требований, Use Case, таблица и т.п.).
Задай критерии качества: без общих фраз, технически точно, помечать допущения.
Попроси ИИ при нехватке данных задавать уточняющие вопросы.
После ответа проверь применимость к проекту и при необходимости доработай вручную.