AI в системном анализе: как собирать и формализовать требования с помощью LLM

AI не напишет за вас требования. Но он может сделать то, на что уходит 80% времени аналитика: прочитать 40 страниц переписки, выцепить из интервью реальные потребности, найти противоречия и разложить всё по шаблонам. Если вы до сих пор делаете это вручную — вы тратите свой самый дорогой ресурс на механическую работу.

В этой статье — не теория «AI изменит профессию», а конкретный pipeline: промпты, которые я использую в работе, и схема, по которой это собирается в рабочий процесс. Базовые понятия ФТ/НФТ и шаблоны User Story/Use Case предполагаем известными; если нужно освежить — вот разбор функциональных и нефункциональных требований с шаблонами и статья про User Story и Use Case. А теперь — к делу.

Почему LLM, а не «просто шаблон в Jira»

Проблема не в том, что аналитики ленятся писать требования. Проблема в объёме сырого материала, через который надо продраться. Часовая запись интервью со стейкхолдером — это 10–15 тысяч слов. Переписка в чате по фиче за две недели — ещё столько же. Плюс комментарии к задаче, плюс письма, плюс «а давайте ещё учтём вот это».

Прочитать всё это и вычленить именно требования, а не эмоции и не «было бы неплохо когда-нибудь» — работа на несколько часов. LLM делает её за минуты. И главное — не пропускает ничего. Человек после третьего абзаца переписки начинает читать по диагонали (я проверял на себе, да). Модель — нет.

Важно: LLM не заменяет аналитика. Она работает как стажёр-трудоголик, который идеально структурирует информацию, но не принимает решений. Решение — всегда за вами.

Pipeline: от сырого ввода до структурированных требований

Весь процесс укладывается в 6 шагов. Давайте посмотрим на схему целиком, а потом разберём каждый этап с промптами.

graph LR
  RAW["Сырой ввод<br/>Запись интервью,<br/>переписка, чат поддержки"]
  PREP["Предобработка<br/>Транскрибация аудио,<br/>очистка от шума"]
  EXTRACT_FT["Извлечение ФТ<br/>LLM находит<br/>функциональные требования"]
  EXTRACT_NFT["Извлечение НФТ<br/>LLM находит<br/>нефункциональные требования"]
  STORIES["Генерация User Story<br/>и Use Case<br/>LLM по шаблонам"]
  REVIEW["Проверка требований<br/>Поиск противоречий,<br/>дубликатов, пробелов"]
  RESULT["Структурированные<br/>требования<br/>JSON / Confluence / Jira"]
  HUMAN["Аналитик<br/><i>контроль на всех этапах</i>"]

  RAW --> PREP
  PREP --> EXTRACT_FT
  PREP --> EXTRACT_NFT
  EXTRACT_FT --> STORIES
  EXTRACT_NFT --> STORIES
  STORIES --> REVIEW
  REVIEW --> RESULT
  HUMAN -.->|"направляет,<br/>корректирует"| PREP
  HUMAN -.->|"уточняет<br/>промпты"| EXTRACT_FT
  HUMAN -.->|"финальная<br/>приёмка"| RESULT

  style RAW fill:#e0e0e0,stroke:#999,color:#333
  style PREP fill:#f0a500,stroke:#c88400,color:#fff
  style EXTRACT_FT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style EXTRACT_NFT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style STORIES fill:#7b68ee,stroke:#5a4db2,color:#fff
  style REVIEW fill:#f0a500,stroke:#c88400,color:#fff
  style RESULT fill:#50c878,stroke:#3a9a5c,color:#fff
  style HUMAN fill:#7b68ee,stroke:#5a4db2,color:#fff

Диаграмма показывает сквозной конвейер: сырой материал (серый) попадает в предобработку (жёлтый), оттуда параллельно уходит на извлечение функциональных и нефункциональных требований (синие блоки). Оба потока сходятся в генерации User Story и Use Case (фиолетовый), затем проходят проверку на противоречия (жёлтый) и выходят готовым структурированным результатом (зелёный). Аналитик (фиолетовый, пунктирные связи) контролирует ключевые точки: направляет предобработку, уточняет промпты и принимает финальный результат.

Примечательно, что промпты не пишутся один раз и навсегда. Вы начинаете с базовой версии, прогоняете пару интервью, смотрите на выдачу, правите промпт — и к пятому-шестому разу он превращается в инструмент. Ниже — те промпты, которые у меня прижились.

Шаг 1. Предобработка: транскрибация и очистка

С аудио — проще простого. Whisper от OpenAI (или локальный faster-whisper) даёт транскрибацию за минуты. С текстовыми переписками сложнее: они полны «привет, как дела», эмодзи, обсуждения погоды и параллельных веток про баги двухлетней давности.

Промпт для очистки переписки:

1
Ты — системный аналитик. Ниже — фрагмент рабочей переписки команды
2
по продукту. Удали из него:
3
1. Приветствия, прощания, small talk.
4
2. Обсуждения, не относящиеся к требованиям (баги, DevOps, отпуска).
5
3. Повторяющиеся сообщения (кто-то переспросил — оставь один,
6
   наиболее полный вариант).
7
4. Эмодзи и реакции.
8

9
Оставь только содержательные высказывания о том, ЧТО система должна
10
делать, ДЛЯ КОГО и ПРИ КАКИХ УСЛОВИЯХ. Сохрани контекст: к каждому
11
оставленному сообщению добавь, от кого оно (роль: разработчик,
12
продакт, заказчик, аналитик) и в какой ветке обсуждения прозвучало.
13

14
Выведи результат в виде структурированного текста с заголовками
15
по темам обсуждения. Не добавляй ничего от себя.
16

17
[текст переписки]

Шаг 2. Извлечение функциональных требований

После очистки у вас есть документ на 2–5 тысяч слов — уже без шума, но всё ещё не требования. Промпт, который превращает это в ФТ:

1
На основе текста ниже выдели все функциональные требования.
2
Для каждого укажи:
3

4
1. Идентификатор (FR-001, FR-002, ...).
5
2. Краткое название (до 10 слов).
6
3. Полное описание: что система должна делать.
7
4. Действующее лицо (Actor): кто инициирует это действие.
8
5. Предусловие: что должно быть выполнено до начала.
9
6. Основной поток: шаги по порядку.
10
7. Альтернативные потоки: что если что-то пошло не так.
11
8. Связанные требования: укажи ID других ФТ, на которые
12
   ссылается это требование.
13

14
Если в тексте недостаточно информации для какого-либо пункта —
15
напиши «[ТРЕБУЕТ УТОЧНЕНИЯ]». Не выдумывай.
16

17
Текст для анализа:
18
[очищенная переписка или транскрибация интервью]

Модель выдаёт таблицу. Её можно сразу в Confluence или в виде JSON для дальнейшей обработки. Скажу по опыту: в 60% случаев часть полей будет с пометкой «требует уточнения». Это не баг — это фича. Теперь вы знаете, какие вопросы задать стейкхолдерам на следующей встрече. Раньше эти пробелы всплывали бы на этапе разработки, когда переделывать в 10 раз дороже.

Шаг 3. Извлечение нефункциональных требований

НФТ сложнее — они часто не формулируются явно. В переписке редко пишут «время отклика должно быть не более 200 мс». Зато пишут «клиенты жалуются, что форма тормозит» или «нам нужно, чтобы выдерживало пиковые нагрузки перед праздниками». LLM нужно явно попросить искать такие сигналы.

1
На основе текста ниже выдели все нефункциональные требования.
2
Ищи не только явные формулировки (типа «должно работать быстро»),
3
но и косвенные сигналы: жалобы на производительность, упоминания
4
объёмов данных, требований к безопасности, интеграций, сроков
5
хранения, доступности.
6

7
Для каждого НФТ укажи:
8

9
1. Идентификатор (NFR-001, NFR-002, ...).
10
2. Категория: Производительность / Безопасность / Надёжность /
11
   Масштабируемость / Удобство использования / Совместимость /
12
   Регуляторные требования / Логирование и мониторинг.
13
3. Описание: что именно требуется.
14
4. Метрика (если применимо): конкретное измеримое значение.
15
   Например: «время ответа API ≤ 200 мс для 95-го перцентиля».
16
5. Источник в тексте: процитируй фрагмент, из которого сделан вывод.
17
6. Статус: Явное (прямо указано) / Косвенное (выведено из
18
   контекста) — [ТРЕБУЕТ ПОДТВЕРЖДЕНИЯ].
19

20
Не добавляй требования, не упомянутые в тексте. Там, где нет
21
метрики — укажи «[ТРЕБУЕТ КОЛИЧЕСТВЕННОЙ ОЦЕНКИ]».
22

23
Текст для анализа:
24
[очищенная переписка или транскрибация]

Шаг 4. Генерация User Story и Use Case

Теперь у вас есть два списка — ФТ и НФТ. Самое время превратить функциональные требования в истории и сценарии. Это тот этап, где LLM особенно полезна: шаблонизация — её родная стихия.

1
У тебя есть список функциональных требований (ниже). Для каждого
2
сгенерируй:
3

4
A) User Story по шаблону:
5
   Как <роль>,
6
   я хочу <действие>,
7
   чтобы <ценность>.
8

9
   Роль бери из поля Actor. Ценность формулируй так, чтобы она
10
   отвечала на вопрос «зачем это пользователю», а не «что делает
11
   система».
12

13
B) Критерии приёмки (Acceptance Criteria) — 3–5 пунктов
14
   в формате Gherkin (Given/When/Then). Каждый критерий должен
15
   быть проверяемым: если тестировщик не может однозначно сказать
16
   «пройдено / не пройдено» — критерий плохой.
17

18
C) Для требований с пометкой «[ТРЕБУЕТ УТОЧНЕНИЯ]» — сформулируй
19
   конкретные вопросы стейкхолдеру. Не «уточнить детали», а
20
   «какой максимальный размер загружаемого файла?» или «должен ли
21
   повторный платёж для того же заказа блокироваться на уровне
22
   интерфейса или на уровне API?».
23

24
Список ФТ:
25
[результат шага 2]

Пара итераций — и у промпта появляется «характер»: он начинает формулировать ценность в стиле вашей команды, а не абстрактным канцеляритом. Это не silver bullet, но экономия часов five-six в неделю для аналитика — это реальные цифры, а не маркетинг.

Проверка требований на полноту и противоречия

Самый недооценённый этап. Когда у вас 40 требований, человеческий глаз перестаёт замечать, что FR-012 говорит «пользователь может редактировать заказ до оплаты», а FR-034 — «после нажатия “Оформить” изменения запрещены». Это не одно и то же. И такие конфликты живут в документах неделями, пока разработчик не споткнётся и не спросит на дейлике: «так можно редактировать или нельзя?»

Промпт для кросс-проверки:

1
Проверь список требований ниже на противоречия, дубликаты
2
и пробелы. Для каждого найденного конфликта укажи:
3

4
1. Тип: Противоречие / Дубликат / Пропущенное требование.
5
2. Идентификаторы затронутых требований.
6
3. Суть проблемы (одно предложение).
7
4. Варианты разрешения: минимум два варианта с аргументами
8
   за и против.
9

10
Дополнительно проверь:
11
- Все ли роли (actors), упомянутые в переписке, фигурируют
12
  хотя бы в одном требовании?
13
- Все ли интеграции упомянуты?
14
- Нет ли требований без предусловий, где они объективно нужны?
15
- Совпадают ли НФТ по безопасности с функциональными
16
  требованиями (например, если заявлена аутентификация —
17
  есть ли соответствующие ФТ)?
18

19
Список требований:
20
[результаты шагов 2, 3 и 4]

Здесь LLM выступает как ревьюер. Практика показывает: на 40–50 требований модель находит 2–4 конфликта, которые реально упустили. Это не магия — это просто алгоритмическая проверка, которую человеку делать скучно, и он её саботирует.

Что LLM делает плохо (и зачем всё равно нужен аналитик)

Справедливости ради — вот где модель спотыкается:

Приоритизация. LLM не знает, что для бизнеса важнее: интеграция с CRM (чтобы продажники не бунтовали) или экспорт в Excel (чтобы бухгалтерия не парализовала запуск). Приоритеты — это всегда компромисс между людьми, а не между данными. Модель может предложить варианты, но решение принимаете вы.

Доменный контекст. Если вы делаете продукт для страхования, а промпт не содержит страховой терминологии — модель выдаст требования в стиле e-commerce. Потому что e-commerce-примеров в её обучении больше. Выход — зашить глоссарий домена прямо в системный промпт.

Неявные знания. Требование «нужно учитывать сезонность» — модель распишет буквально: фильтр по датам, группировка по кварталам. Но она не знает, что в вашем бизнесе «сезон» стартует не 1-го числа, а в первый вторник ноября. Эти детали — только от вас.

Тон переписки. В чате поддержки пользователь пишет «у вас всё тормозит, я полчаса жду!!!». LLM честно извлечёт НФТ: «время отклика должно быть приемлемым». А на самом деле там проблема с конкретным отчётом на 200 тысяч строк. LLM нужно явно просить искать не только формулировки, но и эмоциональные триггеры в тексте — жалобы, капслок, множественные восклицательные знаки.

Таблица: что LLM делает за аналитика, а что — нет

Это не серебряная пуля. LLM — инструмент, который снимает с аналитика механическую работу, но не снимает ответственность за результат.

Как это выглядит в реальном проекте: пример из e-commerce

Берём реальный кейс: интернет-магазин, задача — «добавить систему промокодов». Есть 15-минутное интервью с продакт-оунером, 3 страницы переписки в чате команды и письмо от маркетинга с пожеланиями.

Транскрибируем → очищаем → прогоняем через промпты. На выходе получаем:

• 12 функциональных требований — от базового «применить промокод к корзине» до специфического «запретить комбинацию промокода и товара со скидкой».
• 5 нефункциональных требований — включая «проверка промокода ≤ 50 мс» (маркетинг хочет применять код мгновенно, а то «пользователь уйдёт»).
• 14 User Story — включая роли «покупатель», «менеджер по маркетингу» и «администратор».
• 3 конфликта — например, требование «промокод не должен суммироваться со скидкой постоянного покупателя» противоречило письму маркетинга, где сказано «лояльным клиентам — двойная выгода».

Аналитик потратил 25 минут: 10 — на настройку промптов, 10 — на прогон, 5 — на финальную валидацию. Без LLM это заняло бы 3–4 часа. Разница не в том, что модель умнее. Разница в том, что она не отвлекается на уведомления в Slack.

Заключение

LLM не заменит системного аналитика. Но аналитик, использующий LLM, заменит того, кто не использует. Старая максима, но в случае с обработкой требований она бьёт точнее, чем хотелось бы.

Pipeline, который мы разобрали, закрывает главную боль: ручной разбор гигантских объёмов неструктурированной информации. Вы по-прежнему принимаете решения. Вы по-прежнему спорите со стейкхолдерами о приоритетах. Но три часа чтения переписок и выписывания требований в табличку заменяются тремя минутами промпта и пятью минутами проверки.

Попробуйте на одном ближайшем интервью: запишите, транскрибируйте, скормите модели. Если результат будет сырым — доработайте промпт. Ко второму-третьему разу вы получите инструмент, который останется с вами надолго. А механическая работа по вытаскиванию требований из текста пусть останется в прошлом — у неё там своё почётное место, рядом с факсами и модемами на 56 килобит.

P.S. Если вы дочитали до этого места и подумали «ну, можно попробовать на следующем проекте» — отлично. Если подумали «я и так всё руками делаю, зачем мне эти игрушки» — приходите через полгода. Когда ваш коллега будет закрывать спринт за два дня, а вы всё ещё читать сорокастраничную переписку. Нет, серьёзно.