ИИ-анализ бизнес-требований: противоречия, пробелы и риски — чек-лист и промпты

Вы когда-нибудь читали спецификацию, где на странице 3 написано «система должна поддерживать все браузеры», а на странице 17 — «работа только в Chrome»? Я — да. Много раз. Каждый раз заканчивалось одинаково: разработчики злятся, аналитик оправдывается, стейкхолдер удивляется, почему «такая простая фича» делается неделями.

Противоречия в требованиях убивают проекты медленно. Как коррозия: сначала никто не замечает, потом что-то скрипит, а потом разваливается. Ручной кросс-ревью на 200 страницах ТЗ даёт 60–70% обнаружения проблем — и то если аналитик опытный и выспался. LLM в этой задаче — не замена аналитику. Усилитель. Модель не устаёт на 147-й странице.

Что конкретно ищет LLM в требованиях

Я выделяю три класса проблем, которые модель ловит стабильно. На практике первые два дают 80% находок, третий — страховку от откровенно глупых уязвимостей.

Противоречия

«Гость не может оформить заказ» — а через 40 страниц: «после оформления гостю высылается трек-номер». Одно исключает другое. Или классика: «платёжная система удерживает комиссию 2%» против «все транзакции проходят без комиссии».

Почему аналитик это пропускает? Первую часть писал во вторник утром, вторую — в пятницу вечером после трёхчасового созвона с бухгалтерией. LLM видит документ целиком. Ей без разницы, кто и когда писал конкретный абзац.

Проверял на реальном ТЗ из финтеха: 87 страниц, 312 функциональных требований. Модель нашла 14 противоречий. Из них 9 — настоящие проблемы, 3 — ложные срабатывания (разные контексты), 2 — опечатки. Ручное ревью трёх аналитиков того же документа нашло 7.

Пробелы

Модель сравнивает описанные сценарии с типовой картой процессов домена и флагом помечает то, чего нет. Пользователь загружает аватар — а что, если формат не PNG? Если файл 50 мегабайт? Если загрузка оборвалась на середине?

В ТЗ про это молчок.

У меня был случай: стейкхолдер полчаса рассказывал про восстановление пароля — три ветки сценария, безопасность, уведомления. В требования попало одно предложение: «пользователь может восстановить пароль». LLM выловила пробел за секунду.

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

Модель не предсказывает будущее, но сопоставляет требования с чек-листами OWASP, GDPR, PCI DSS. Видит «передача номера карты в лог» — флаг. Видит «хранение пароля в открытом виде» — флаг. Базовые вещи, о которых в спешке забывают чаще, чем хочется.

Отдельная категория — болото неоднозначностей. Слово «быстро» в требованиях к производительности не значит ничего. «Система должна быстро открывать отчёт» — для продакта это 0.5 секунды, для бэкенд-разработчика — 2, для индийского аутсорса — 10. LLM подсвечивает слова-триггеры: «быстро», «удобно», «качественно», «масштабируемо» — всё, что нельзя измерить в цифрах.

flowchart TB
  subgraph input["Входные данные"]
      TZ["Тексты требований"]
      CONTEXT["Контекст домена"]
      CONSTRAINTS["Ограничения / NFR"]
  end

  subgraph analysis["Этапы анализа LLM"]
      CONTRADICT["Поиск противоречий\nлогических и временных"]
      GAPS["Выявление пробелов\nв сценариях"]
      AMBIGUITY["Поиск неоднозначностей\nи двусмысленностей"]
      RISKS["Оценка рисков\nбезопасность, compliance"]
  end

  subgraph output["Результаты"]
      MATRIX["Матрица проблем\nкритичность x влияние"]
      CHECKLIST["Чек-лист\nисправлений"]
      REPORT["Отчёт\nдля стейкхолдеров"]
  end

  TZ --> CONTRADICT
  TZ --> GAPS
  TZ --> AMBIGUITY
  TZ --> RISKS
  CONTEXT --> CONTRADICT
  CONTEXT --> GAPS
  CONSTRAINTS --> RISKS
  CONSTRAINTS --> CONTRADICT

  CONTRADICT --> MATRIX
  GAPS --> MATRIX
  AMBIGUITY --> MATRIX
  RISKS --> MATRIX
  MATRIX --> CHECKLIST
  MATRIX --> REPORT

  style TZ fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CONTEXT fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CONSTRAINTS fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style CONTRADICT fill:#f0a500,stroke:#c88400,color:#fff
  style GAPS fill:#f0a500,stroke:#c88400,color:#fff
  style AMBIGUITY fill:#7b68ee,stroke:#5a4db2,color:#fff
  style RISKS fill:#f0a500,stroke:#c88400,color:#fff
  style MATRIX fill:#50c878,stroke:#3a9a5c,color:#fff
  style CHECKLIST fill:#50c878,stroke:#3a9a5c,color:#fff
  style REPORT fill:#50c878,stroke:#3a9a5c,color:#fff

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

Чек-лист: на что смотреть при анализе требований

Таблица собрана методом граблей, а не из учебника.

Класс проблемы	Что проверять	Пример флага
Логические противоречия	A требует B, но C запрещает B	«Гость оформляет заказ» vs «Заказ только для авторизованных»
Временные противоречия	Порядок шагов в сценариях	«Уведомление приходит до того, как платёж обработан»
Числовые расхождения	Лимиты, таймауты, квоты	«Не более 10 товаров» vs «Корзина до 100 позиций»
Отсутствующие ветки	Альтернативные и ошибочные сценарии	Описан только happy path, нет обработки ошибок
Пропущенные edge cases	Граничные значения	Нет поведения при пустой БД / нуле данных / переполнении
Неоднозначные формулировки	Слова без метрик	«Быстро», «удобно», «качественно», «надёжно»
Отсутствующие NFR	Производительность, безопасность	Нет требований к времени отклика, нагрузке, шифрованию
Compliance-риски	GDPR, PCI DSS, 152-ФЗ	Персональные данные без указания срока и способа хранения

Промпты для анализа

Три промпта, которые я использую в работе. Оттестированы на Claude 3.5+ и GPT-4o. Копируйте и подставляйте текст требований.

Промпт 1: Базовый анализ противоречий

1
Ты — системный аналитик с 10-летним опытом в финтехе.
2
Проанализируй текст требований на логические противоречия.
3

4
Для каждой находки укажи:
5
1. Цитаты или номера конфликтующих требований
6
2. Суть конфликта — почему эти пункты не могут быть истинными одновременно
7
3. Критичность: Critical / High / Medium
8

9
Если требования ссылаются на разные версии одного документа — отметь это отдельно.
10
Не выдумывай проблемы. Если противоречий нет — скажи прямо.
11

12
Текст требований:
13
---
14
[paste here]
15
---

Промпт 2: Поиск пробелов по доменным сценариям

1
Ты — системный аналитик. Твой домен — e-commerce.
2
Проверь текст требований на пробелы в покрытии сценариев.
3

4
Пройди по стандартному списку:
5
— Основной сценарий (happy path)
6
— Альтернативные сценарии
7
— Ошибочные сценарии (сетевые ошибки, таймауты, невалидные данные)
8
— Edge cases (пустые данные, экстремальные значения, параллельные запросы)
9

10
Для каждого пробела:
11
1. Опиши, чего не хватает
12
2. Объясни, почему это важно для бизнеса
13
3. Предложи формулировку требования
14

15
Текст требований:
16
---
17
[paste here]
18
---

Промпт 3: Риски безопасности и compliance

1
Ты — эксперт по безопасности корпоративных систем.
2
Проанализируй текст требований на риски безопасности
3
и несоответствие регуляторным нормам (GDPR, PCI DSS, 152-ФЗ).
4

5
Формат ответа — таблица:
6
| Требование | Проблема | Риск | Стандарт | Как исправить |
7

8
В колонке «Как исправить» давай конкретную формулировку требования,
9
а не общие рекомендации.
10

11
Если не указан способ хранения паролей, метод шифрования данных
12
при передаче, политика хранения (retention) — считай это пробелом.
13

14
Текст требований:
15
---
16
[paste here]
17
---

Замените домен в промпте 2 на свой: банкинг, страхование, логистика — что угодно. Модель адаптирует список типовых сценариев под контекст.

Как встроить в рабочий процесс

Я запускаю LLM-анализ на этапе ревью, до передачи спецификации в разработку. Последовательность простая: черновик ТЗ → прогон через три промпта → ручная фильтрация находок (20% — ложные срабатывания, это нормально) → правки → финальное ревью с командой.

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

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

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

Что делать с находками

Не кидайте отчёт LLM разработчикам как есть. Верный способ получить репутацию «того самого аналитика с нейросеткой».

Алгоритм действий:

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

У меня на проекте модель нашла 14 противоречий в ТЗ на расчётный модуль. Ручная фильтрация оставила 9 реальных проблем. Три из них заказчик признал фразой «ой, мы об этом не думали» и взял паузу на неделю. Неделя паузы в разы дешевле трёх спринтов переделок.