ИИ-генерация User Story и Use Case из сырых требований: промпты и шаблоны

Час созвона со стейкхолдерами превращается в 25 User Story ещё до того, как вы допили остывший кофе. Звучит как фантазия, но ровно это LLM и делает — если дать ей правильный промпт и стенограмму вместо абстрактного «сгенерируй истории». Вся магия в том, что модель умеет вычленять роли, действия и ценности из потока сознания, который принято называть «сбором требований». Просто так она этого не сделает — нужна структура, о которой дальше и пойдёт речь.

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

Почему LLM справляется с этим лучше, чем кажется

На старте кажется, что User Story — это про эмпатию и понимание пользователя. Машина про эмпатию ничего не знает. Но если разобрать задачу, она состоит из трёх операций:

Извлечь из текста упоминания ролей (кто действует).
Найти глаголы, описывающие действия (что нужно сделать).
Связать действие с бизнес-результатом (зачем).

Всё это — лингвистический анализ. А с лингвистикой LLM справляется на уровне, который делает честь любому выпускнику филфака. Плюс модель обучена на огромном количестве шаблонов формата «Как … я хочу …, чтобы …» — она знает их до автоматизма.

Подвох в том, что модель не отличает полезную историю от бессмысленной. Ей всё равно, генерировать «Как пользователь, я хочу видеть баланс» или «Как администратор, я хочу экспортировать отчёт в PDF с сортировкой по дате и фильтрацией по категориям за последние 30 дней». Обе будут соответствовать формату. Качество зависит от входа: что скормили, то и получили.

graph TD
  A["Сырые требования
стенограмма / чаты / письма"] --> B["LLM: извлечение
ролей и глаголов"]
  B --> C["Генерация User Story
Как роль я хочу чтобы"]
  B --> D["Генерация Use Case
основной поток"]
  B --> E["Альтернативные
потоки и исключения"]
  C --> F["Критерии приёмки
Given / When / Then"]
  D --> F
  E --> F
  F --> G["Валидация:
противоречия, дубли,
пропущенные роли"]
  G --> H["Структурированный бэклог
User Story + Use Case
+ Acceptance Criteria"]

  style A fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B fill:#f0a500,stroke:#c88400,color:#fff
  style C fill:#7b68ee,stroke:#5a4db2,color:#fff
  style D fill:#7b68ee,stroke:#5a4db2,color:#fff
  style E fill:#7b68ee,stroke:#5a4db2,color:#fff
  style F fill:#50c878,stroke:#3a9a5c,color:#fff
  style G fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style H fill:#50c878,stroke:#3a9a5c,color:#fff

Схема описывает пайплайн, который я использую на практике. Сырые данные проходят через извлечение акторов и действий, затем модель генерирует User Story, Use Case и альтернативные потоки — всё это стягивается в критерии приёмки и валидируется. Последний блок, валидация, возвращает истории на доработку, если модель нашла противоречие или забыла роль. Два-три цикла — и бэклог готов к ревью.

Промпты: шаблоны, которые дают результат, а не мусор

Промпт — это инструкция. Чем она точнее, тем меньше ерунды на выходе. Ниже три шаблона, которые реально работают на Claude 3.5 Sonnet и GPT-4o.

Базовый промпт: быстрая генерация User Story

Подходит, когда у вас уже есть сформулированные потребности — например, расшифровка интервью или письмо от заказчика. Задача: превратить это в structured stories.

1
Ты — системный аналитик. Прочитай приведенный ниже текст и сгенерируй User Story в формате:
2

3
Как <роль>,
4
я хочу <действие>,
5
чтобы <ценность>.
6

7
Правила:
8
1. Роль должна быть конкретной: не «пользователь», а «зарегистрированный покупатель», «оператор склада», «менеджер по возвратам».
9
2. Ценность — измеримый бизнес-результат, а не абстрактное «для удобства».
10
3. Одна Story — одна функциональность. Не объединяй несколько действий в одну.
11
4. Если в тексте роль упомянута, но действия не описаны — НЕ додумывай.
12
5. Если в тексте описано действие без явной роли — определи наиболее вероятную.
13

14
Текст требований:
15
---
16
{вставьте стенограмму или описание требований}
17
---

Продвинутый промпт: User Story + Use Case + критерии приёмки

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

1
Ты — ведущий системный аналитик. По приведённому ниже описанию построй полную модель требований.
2

3
Формат вывода — для каждой функциональности:
4

5
1. User Story:
6
   Как <конкретная роль>,
7
   я хочу <конкретное действие>,
8
   чтобы <измеримая ценность>.
9

10
2. Use Case (таблица):
11
   | Поле | Значение |
12
   | Название | ... |
13
   | Актор | ... |
14
   | Предусловие | ... |
15
   | Основной поток | 1. ... 2. ... |
16
   | Альтернативный поток | 1a. Если ..., то ... |
17
   | Постусловие | ... |
18

19
3. Критерии приёмки (Given/When/Then):
20
   - Given <начальное состояние>
21
   - When <действие>
22
   - Then <ожидаемый результат>
23

24
4. Граничные случаи (edge cases) — минимум 3 на каждую Story.
25

26
ВАЖНО: не выдумывай функциональность, которой нет в исходном тексте. Если данных недостаточно для поля — пиши «требует уточнения».
27

28
Исходный текст:
29
---
30
{вставьте требования}
31
---

Промпт: ревью и дошлифовка бэклога

Этот шаг — финальный. У вас уже есть сгенерированный набор историй. Модель смотрит на него свежим взглядом и находит то, что человек при вычитке пропускает.

1
Ты — ревьюер. Проверь приведённый ниже список User Story на типичные ошибки системного аналитика.
2

3
Найди и отметь:
4
1. Размытая роль («пользователь» вместо конкретного актора).
5
2. Абстрактная ценность («для удобства», «для улучшения UX»).
6
3. Несколько действий в одной Story — разбей.
7
4. Истории без критериев приёмки — предложи минимум 2 Given/When/Then.
8
5. Пропущенные негативные сценарии (что будет при ошибке, пустом вводе, отсутствии прав).
9
6. Дубли — две Story об одном и том же разными словами.
10

11
Формат ответа:
12
- Story ID: [номер или заголовок]
13
- Проблема: [тип ошибки]
14
- Предложение: [как исправить]
15

16
Список User Story:
17
---
18
{вставьте список}
19
---

Эти три промпта закрывают цикл: генерация → детализация → валидация. Пропустите третий шаг — получите бэклог, в котором половина историй не пройдёт refinement без правок.

Где оно спотыкается: типичные глюки AI-генерации

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

Выдуманные роли. Если в стенограмме сказано «пользователь», а модель видит слово «одобрение», она может родить роль «модератор заявок». Вакансии такой в компании нет. Лечится правилом в промпте: «не выдумывай роли, которых нет в тексте». Но полностью не уходит — перепроверяйте.

Пропуск негативных сценариев. Модель отлично генерирует позитивные сценарии. А вот что будет, если платёжный шлюз вернул таймаут, или пользователь ввёл номер карты, а потом передумал и нажал «назад» — это остаётся за скобками, пока явно не попросишь. Промпт «добавьте минимум 3 edge cases на каждую Story» решает проблему на 80%.

Сюжетная дыра в Use Case. Модель пишет основной поток как связный рассказ, но пропускает шаг 3 из 7 — потому что он «очевиден». Например: «1. Пользователь открывает корзину. 2. Нажимает оплатить. 3. Видит подтверждение». Где проверка адреса доставки? Где расчёт стоимости? Для LLM это подразумевается, для разработчика — нет.

Лучшая защита от этих глюков — второй проход с промптом-ревьюером из предыдущего раздела. 15 минут дополнительной работы против часа разбора на груминге.

Ручной vs AI-подход: сравнение на реальных цифрах

Я взял одно и то же интервью со стейкхолдером (45-минутная расшифровка требований к личному кабинету интернет-магазина) и прогнал двумя способами. Ручным — сел и методично выписывал истории. AI — скормил стенограмму Claude с продвинутым промптом.

graph LR
  subgraph "Ручной процесс"
      A1["Расшифровка
интервью 45 мин"] --> A2["Формулировка
User Story 2ч"] --> A3["Use Case
основные потоки 1ч"] --> A4["Критерии
приёмки 1.5ч"] --> A5["Результат:
18 историй за 4ч"]
  end
  subgraph "AI-процесс"
      B1["Расшифровка
интервью 45 мин"] --> B2["LLM:
30 секунд"] --> B3["Ревью и правки
аналитиком 1.5ч"] --> B4["Результат:
24 истории за 2ч"]
  end

  style A1 fill:#e0e0e0,stroke:#999,color:#333
  style A2 fill:#e0e0e0,stroke:#999,color:#333
  style A3 fill:#e0e0e0,stroke:#999,color:#333
  style A4 fill:#e0e0e0,stroke:#999,color:#333
  style A5 fill:#e0e0e0,stroke:#999,color:#333
  style B1 fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style B2 fill:#f0a500,stroke:#c88400,color:#fff
  style B3 fill:#50c878,stroke:#3a9a5c,color:#fff
  style B4 fill:#50c878,stroke:#3a9a5c,color:#fff

Разница в цифрах: 18 историй за 4 часа вручную против 24 историй за 2 часа с AI (45 минут расшифровки + 1 час 15 минут на ревью и дошлифовку). Не в два раза быстрее — в два раза быстрее и на треть больше покрытие. Дополнительные 6 историй, которые модель нашла, касались роли «менеджер по возвратам» — в стенограмме она упоминалась вскользь, без привязки к конкретным функциям. При ручном разборе я эту роль пропустил.

Важный нюанс: половина сэкономленного времени ушла не на кофе, а на проверку сгенерированного. Без ревью использовать вывод LLM нельзя — получите красиво оформленные истории про несуществующие фичи.

Куда это встраивать в рабочем процессе

Не надо перестраивать весь процесс ради AI. Достаточно добавить один шаг между сбором требований и оформлением бэклога.

Шаг 1: расшифровка. Если интервью аудио — сначала расшифровка через Whisper или встроенную транскрипцию в Zoom/Teams. Текст — обязательное условие, LLM аудио не переваривает (пока).

Шаг 2: базовый промпт. Берёте расшифровку, применяете базовый промпт из раздела выше. На выходе — список User Story.

Шаг 3: проверка человеком. Просматриваете список, вычёркиваете выдуманные роли и нерелевантные истории. Обычно уходит 10-15 минут.

Шаг 4: продвинутый промпт. Оставшиеся истории прогоняете через продвинутый промпт — получаете Use Case и критерии приёмки.

Шаг 5: финальное ревью. Промпт-ревьюер проверяет итоговый набор, вы помечаете то, что реально надо поправить.

Шаг 6: бэклог. Готовые истории уходят в Jira или Confluence.

Весь процесс занимает часа полтора вместо четырёх. Не магия — методичное применение инструмента под присмотром человека. Если на проекте уже настроен AI-ассистент аналитика через MCP, шаги 2 и 4 можно автоматизировать — модель сама подтянет расшифровку из Confluence и положит результат в задачи Jira.

Что модель не заменит никогда

Есть вещи, которые LLM не делает и не сделает.

Приоритизация. Модель не знает, что для бизнеса важнее прямо сейчас — экспорт отчётов или редизайн корзины. User Story про «экспорт в PDF» и «красивые иконки товаров» для неё равноценны. Решение о порядке реализации остаётся за человеком.

Понимание неявного контекста. Если стейкхолдер сказал «нужно ускорить загрузку страницы», модель сгенерирует User Story про скорость. Она не знает, что проблема не в коде, а в том, что 2 ГБ изображений товаров лежат без CDN. Промпт-инжиниринг помогает загрузить контекст, но не заменяет знание архитектуры.

Переговоры. Главная работа аналитика на интервью — не запись, а уточнение: «Правильно ли я понимаю, что вам нужно X, а не Y?» Модель не задаёт встречных вопросов. Она берёт то, что ей дали, и делает из этого конфетку. Если в стенограмме неверная предпосылка — на выходе будет красиво оформленная ошибка.

Мораль: AI ускоряет превращение сырых требований в структурированные артефакты. Но качество входа определяет качество выхода. Мусор на входе — мусор на выходе, только в красивом формате.

Главный вывод

LLM для генерации User Story и Use Case — это не замена аналитику, а инструмент, который срезает самую механическую часть работы. Вы не пишете 18 историй руками, вы проверяете 24 сгенерированных и тратите на это в два раза меньше времени. Оставшееся — на уточнение требований с заказчиком, где модель пока бесполезна.

Попробуйте на ближайшем интервью: запишите созвон, расшифруйте, скормите Claude базовый промпт и посмотрите, сколько историй модель найдёт даже в десятиминутном фрагменте. Скорее всего, вы удивитесь количеству требований, которые пролетели мимо ушей, пока вы вели конспект.

Что касается самой методики User Story и Use Case без привязки к AI — есть подробный разбор с шаблонами и типичными ошибками в посте про User Story и Use Case для системного аналитика. Там про format и структуру требований, здесь — про то, как заставить LLM делать эту рутину за вас.