Use cases, user stories и BDD для AI-агента

7 августа 2026 · 15 минут чтения

Рабочая модель, которая связывает пользовательскую цель, поставляемую часть и проверяемые примеры в задаче для coding-агента.

Use case удерживает целостную цель. User story ограничивает порцию поставки. BDD-сценарий делает ожидаемое поведение проверяемым.

Если в ТЗ не сказано, что делать с дублем, повтором операции или частичным результатом, исполнитель должен либо задать вопрос, либо выбрать поведение самостоятельно. При работе с coding-агентом — AI-инструментом, который читает репозиторий, меняет файлы и запускает проверки, — легко пропустить разговор и получить правдоподобное, но не согласованное решение.

Use cases, user stories и BDD появились задолго до LLM. Каждый подход решал свою проблему разработки:

• use case не даёт потерять пользовательскую цель и альтернативные пути к ней;
• user story превращает потребность в небольшую обсуждаемую единицу поставки;
• BDD переводит правила в конкретные примеры, по которым можно проверить выбранные случаи поведения.

Это не общепринятая иерархия и не обязательный процесс. Фаулер отмечает, что единого взгляда на соотношение use cases и user stories нет: команды могут использовать оба подхода или только один. Ниже — моя рабочая модель, в которой эти техники отвечают на вопросы разного масштаба. Martin Fowler, Use Cases and Stories

один из возможных маршрутов

зачем и для кого
      ↓
use case: целая цель и все существенные пути
      ↓
user stories: кандидаты на независимо поставляемые срезы
      ↓
BDD examples: точные наблюдаемые примеры
      ↓
автотесты и реализованный код

В задаче для coding agent такая раскладка уменьшает число продуктовых решений, которые остаётся выводить из контекста. Это обоснование способа работы, а не доказательство, что сами названия артефактов улучшают качество кода.

Короткий ответ: в чём разница

Самая полезная формула:

use case ≠ большая user story
user story ≠ короткий use case
BDD ≠ синтаксис Given / When / Then

Use case организует требования вокруг цели пользователя. User story организует работу вокруг поставляемого изменения. BDD организует совместное понимание вокруг конкретных примеров поведения.

1. Use case: цель и все пути к ней

Откуда взялась идея

Use cases ввёл в программную инженерию Ивар Якобсон. Позже Алистер Кокберн развил практику goal-oriented use cases в книге Writing Effective Use Cases.

Современная совместная формулировка Якобсона и Кокберна проста:

Use case — это все способы использования системы для достижения цели конкретного пользователя.

В этой фразе важны слова все способы. Один линейный happy path — это не весь use case, а только один его сценарий. Полноценный use case объединяет нормальный путь, допустимые варианты, отказы и восстановление. Ivar Jacobson & Alistair Cockburn, Use-Case Foundation

Четыре опоры use case

У хорошего use case есть:

1. System of Interest — система, поведение которой мы описываем как чёрный ящик.
2. Primary actor — роль, инициирующая взаимодействие ради цели.
3. Goal — наблюдаемый полезный результат для актора.
4. Flows — основной и альтернативные пути от триггера к успеху или осмысленному отказу.

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

Цель тоже не равна действию в интерфейсе. «Нажать кнопку “Импортировать”» — не цель. «Добавить операции из банковской выписки в учёт» — цель. Интерфейс можно заменить, а цель останется.

Use case — текст, а не овал на диаграмме

UML-диаграмма с человечками и овалами может показать границу системы и каталог целей. Она почти ничего не говорит о поведении внутри цели.

Ценность use case находится в тексте: кто чего хочет, что происходит на основном пути, где он разветвляется и что гарантирует система. Мартин Фаулер прямо отмечает, что UML стандартизировал диаграмму, но не самый ценный текст use case. Martin Fowler, Use Case

Поэтому для ТЗ агенту список овалов — только индекс. Рабочий материал начинается с потоков.

Goal levels: не провалиться в кнопки

Кокберн различает уровни целей. Практически достаточно трёх:

• summary — большая бизнес-активность из нескольких пользовательских целей: «Вести бухгалтерский учёт»;
• user goal — результат, который актор хочет получить за один осмысленный сеанс: «Импортировать банковскую выписку»;
• subfunction — шаг, нужный системе или верхнему use case: «Определить кодировку CSV».

Основной рабочий уровень — user goal, который Кокберн метафорически называет sea level. Если описание заполняется кликами, HTTP-запросами и внутренними функциями, надо несколько раз спросить «зачем?», пока не проявится пользовательская цель. Если use case занимает недели непрерывного бизнеса и включает десятки самостоятельных целей, надо спросить «как?», чтобы спуститься на уровень ниже.

Рабочий шаблон

Не каждый use case нужно оформлять полностью. Кокберн советует двигаться вширь: сначала акторы и цели, затем краткие описания, потом основные сценарии и лишь затем расширения. Читаемый черновик полезнее идеального шаблона, который никто не закончил. Alistair Cockburn, Writing Effective Use Cases: Reminders

Для сложной или рискованной функции подходит такой шаблон:

## UC-07. Импортировать банковскую выписку

Scope: Accounting System
Level: user goal
Primary actor: Бухгалтер
Supporting actors: Файловое хранилище
Trigger: Бухгалтер выбирает подготовленную банковскую выписку

Stakeholders and interests:
- Бухгалтер хочет быстро получить корректные операции без дублей.
- Владелец бизнеса хочет, чтобы итоговые суммы можно было проверить.

Preconditions:
- Бухгалтер авторизован и имеет доступ к организации.
- Организация и банковский счёт уже существуют.

Minimal guarantees:
- Некорректный импорт не изменяет существующие операции.
- Исходный файл и причина отказа доступны для аудита.

Success guarantees:
- Новые операции сохранены ровно один раз.
- Бухгалтер видит число добавленных, пропущенных и ошибочных строк.

Main success scenario:
1. Бухгалтер передаёт системе выписку для выбранного счёта.
2. Система распознаёт формат и показывает период, валюту и число операций.
3. Бухгалтер подтверждает импорт.
4. Система добавляет новые операции.
5. Система показывает итог импорта.

Extensions:
2a. Формат не поддерживается:
    1. Система отклоняет файл и объясняет допустимые форматы.
    2. Use case завершается без изменения операций.
2b. Валюта выписки не совпадает с валютой счёта:
    1. Система предупреждает о несовпадении и не разрешает подтверждение.
3a. Бухгалтер отменяет импорт:
    1. Система удаляет временные данные и ничего не записывает.
4a. Часть операций уже импортирована:
    1. Система пропускает дубли.
    2. Система продолжает импорт новых операций.
4b. Запись новых операций завершается ошибкой:
    1. Система откатывает весь импорт.
    2. Система сохраняет диагностический идентификатор ошибки.

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

Как писать шаги

Классические эвристики Кокберна хорошо работают и для AI-агентов:

• один шаг выражает намерение или наблюдаемый результат, а не жест мышью;
• в каждом шаге ясно, кто действует: актор или система;
• система описывается как чёрный ящик;
• основной сценарий содержит только успешный путь;
• ответвления привязаны к конкретному шагу: 2a, 4b;
• расширение либо возвращается в основной путь, либо заканчивается успехом или отказом;
• данные называются доменными именами, а схема полей живёт в отдельном контракте.

Полезная проверка каждого шага: сохранится ли его смысл, если заменить web-интерфейс на CLI или API? Если нет, в use case, вероятно, просочилась реализация.

Сильная и слабая стороны

Use case силён там, где важна связность:

• длинный пользовательский путь;
• несколько внешних участников;
• транзакции и откаты;
• права доступа;
• ошибки, повторы и частичный успех;
• интеграции и асинхронные события.

Но use case обычно не предназначен быть единицей планирования спринта. Целая цель может быть слишком большой, а полезный релиз — содержать лишь несколько её потоков. Для нарезки поставки удобнее использовать user story.

2. User story: договорённость о следующей порции ценности

Story — не мини-спецификация

User stories пришли из Extreme Programming. Их классический смысл лучше всего передаёт формула Рона Джеффриса 3C:

• Card — короткая карточка-напоминание;
• Conversation — разговор, в котором команда выясняет детали;
• Confirmation — примеры или критерии, подтверждающие выполнение.

Карточка не заменяет требование. Она хранит достаточно информации, чтобы нужный разговор состоялся вовремя. Билл Уэйк подчёркивал эту конструкцию, когда предложил критерий INVEST для хороших stories. Bill Wake, INVEST in Good Stories, and SMART Tasks

Acceptance criteria — это договорённость о том, что считается готовым. BDD examples — конкретные примеры, которые помогают эту договорённость обнаружить, сформулировать и проверить.

Популярный шаблон:

As a <role>
I want <capability>
so that <benefit>

помогает назвать роль, желаемую возможность и ценность. Но шаблон — не определение user story и не гарантия качества. Плохое требование легко уложить в три строки:

Как пользователь,
я хочу микросервис импорта на Kafka,
чтобы импортировать выписки.

Здесь роль ничего не уточняет, ценность тавтологична, а решение заранее вшито в потребность.

Лучше:

US-07.1
Как бухгалтер,
я хочу предварительно проверить распознанную выписку,
чтобы не добавить операции не на тот счёт.

INVEST: эвристика качества

Хорошая story стремится быть:

• Independent — поставляемой с минимальной зависимостью от соседних stories;
• Negotiable — оставляющей пространство для обсуждения решения;
• Valuable — дающей заметную ценность пользователю или бизнесу;
• Estimable — достаточно понятной для оценки;
• Small — помещающейся в короткую итерацию;
• Testable — допускающей ясное подтверждение результата.

INVEST — не приёмочный чек-лист. Это диагностическая эвристика. Например, если story невозможно оценить, проблема часто не в оценке, а в неизвестном правиле или скрытой зависимости.

User story режет use case не обязательно по шагам

Между use case и stories нет отношения один-к-одному. Фаулер формулирует различие так: use cases организуют требования в повествование о достижении цели, а stories — в части для планирования. Он называет связь между ними сложной: story может соответствовать целому небольшому use case, одному или нескольким сценариям, нескольким шагам или возможности, которой вообще нет в повествовании use case. Martin Fowler, Use Cases and Stories

В моей рабочей раскладке story может охватывать:

• весь маленький use case;
• один или несколько его сценариев;
• несколько шагов;
• одно правило, проходящее через разные use cases;
• технически необходимую возможность, не видимую отдельным шагом в пользовательском повествовании.

Для примера с выпиской возможны такие срезы:

US-07.1 — распознать поддерживаемый CSV и показать preview
US-07.2 — подтвердить и атомарно импортировать новые операции
US-07.3 — обнаружить и пропустить ранее импортированные операции
US-07.4 — выдать понятный отчёт по ошибочным строкам

Это вертикальные срезы поведения. Story «сделать таблицу transactions» может быть задачей реализации, но сама по себе не поставляет пользовательскую ценность и не заменяет story.

Что меняется при работе с агентом

В классическом XP большая часть смысла находится в Conversation. Если задачу продолжит новая сессия coding agent, результат этого разговора нельзя оставлять только в чате. Его стоит материализовать, не превращая карточку в исчерпывающий документ:

• решения — в правилах и контрактах;
• конкретные примеры — в сценариях приёмки;
• неизвестное — в явных открытых вопросах;
• границы — в списках того, что входит и не входит в задачу;
• связь с целой целью — идентификатором use case.

Иначе в письменной постановке остаётся Card без результатов Conversation и Confirmation.

3. BDD: от спорного правила к проверяемому примеру

BDD вырос из TDD, но не сводится к тестам

Дэн Норт описал BDD как попытку убрать путаницу вокруг TDD и говорить о поведении, а не о тестовых методах. Затем этот язык распространился с кода на анализ требований: разработчики, тестировщики и бизнес могли обсуждать систему одними доменными терминами. Dan North, Introducing BDD

Современная формулировка Cucumber разделяет ежедневную практику BDD на три стадии:

1. Discovery — вместе исследовать изменение через правила, примеры и вопросы.
2. Formulation — записать согласованные примеры точно и понятно человеку.
3. Automation — связать примеры с исполняемыми проверками и реализовать поведение.

Cucumber, Behaviour-Driven Development

Это важная последовательность. В строгом понимании Cucumber написать .feature после готового кода — нормальный способ автоматизации тестов, но не полный BDD-процесс. Запустить Cucumber — тоже не значит провести discovery.

Rule → Examples → Questions

BDD начинается не с ключевого слова Given, а с обнаружения правил и пограничных случаев.

Для story о дублях разговор может выглядеть так:

Story:
  Импортировать операции без повторного создания дублей.

Rule:
  Операция, ранее импортированная из этого счёта, повторно не создаётся.

Examples:
  - тот же файл загружен второй раз;
  - другая выписка содержит одну ранее импортированную операцию;
  - две операции имеют одинаковую сумму и дату, но разные банковские ID.

Questions:
  - что является стабильным идентификатором у каждого поддерживаемого банка?
  - считаем ли дублем операцию, исправленную банком задним числом?

В технике Example Mapping story, rules, examples и questions специально разделяют. Много правил сигнализирует, что story велика; много вопросов — что она не готова; несколько разных примеров уточняют смысл правила. Matt Wynne, Introducing Example Mapping

Given / When / Then — грамматика одного примера

Согласованный пример удобно сформулировать так. Ниже показан полноценный минимальный фрагмент .feature:

Feature: Импорт банковской выписки

  Scenario: Повторная загрузка того же файла
    Given выписка с банковскими ID "A-100" и "A-101" уже импортирована
    When бухгалтер повторно импортирует эту выписку
    Then новые операции не создаются
    And результат сообщает о 2 пропущенных дублях

Семантика частей:

• Given — существенное начальное состояние, контекст примера;
• When — одно событие или действие, поведение под проверкой;
• Then — наблюдаемый результат для пользователя или внешней системы.

And и But только делают текст естественнее. Они не создают новую фазу.

Официальная документация Gherkin советует проверять наблюдаемый выход, а не внутреннюю запись в базе. Она также рекомендует описывать поведение независимо от интерфейса: When Bob logs in, а не последовательность заполнения полей и кликов. Cucumber, Gherkin Reference и Writing better Gherkin

Конкретность важнее торжественности синтаксиса

Плохой сценарий (фрагмент, намеренно оставленный неточным):

Feature: Импорт банковской выписки

  Scenario: Импорт работает правильно
    Given у пользователя есть файл
    When пользователь импортирует файл
    Then файл должен успешно импортироваться

Он выглядит формально, но не задаёт критерия проверки: что именно означает «правильно» и «успешно»?

Хороший сценарий содержит значения, которые снимают неоднозначность:

Feature: Импорт банковской выписки

  Scenario: Из смешанной выписки импортируются только новые операции
    Given на счёте уже есть операция с банковским ID "A-100"
    And выписка содержит операции "A-100", "A-101" и "A-102"
    When бухгалтер подтверждает импорт
    Then система создаёт 2 операции
    And итог показывает "Добавлено: 2, дубли: 1, ошибки: 0"

Конкретные примеры не заменяют общее правило. Один пример не доказывает, что мы поняли все случаи. Поэтому хороший пакет хранит оба уровня:

Rule: обобщение, которое должно быть истинно
Examples: несколько точек, уточняющих границы правила

BDD не требует Gherkin везде

Given / When / Then можно использовать в обычном Markdown, тестах или таблицах. Gherkin нужен, когда ценны единый парсер, отчёты и связка со step definitions.

Не стоит автоматизировать каждый текстовый сценарий через UI. Я обычно проверяю правила на самом низком уровне, который сохраняет наблюдаемый смысл: в доменной модели, API или контрактном тесте; end-to-end оставляю для немногих критических путей. Иначе исполняемая спецификация превращается в медленную дублирующую тестовую обвязку.

4. Как три подхода складываются в одно ТЗ

Вернёмся к примеру.

Уровень 1. Use case удерживает целое

UC-07 Импортировать банковскую выписку показывает:

• границу Accounting System;
• цель бухгалтера;
• основной путь;
• отмену, неверный формат, валютный конфликт, дубли и откат;
• гарантии атомарности и аудита.

Агент видит не отдельный экран, а жизненный цикл операции.

Уровень 2. User story ограничивает изменение

US-07.3 Обнаружить и пропустить ранее импортированные операции выбирает один поставляемый срез. В ней явно указано:

Parent use case: UC-07
Covers: extension 4a
Входит в задачу: дубли с тем же банковским ID в пределах одного счёта
Не входит в задачу: исправленные банком операции; поиск дублей без банковского ID

Агент не обязан реализовывать все найденные в use case расширения за один проход.

Уровень 3. BDD уточняет правила

Feature: Импорт банковской выписки

  Rule: Банковский ID уникален в пределах счёта, но не всей организации

    Scenario: Тот же банковский ID на том же счёте
      Given на счёте "KZ-01" есть операция с банковским ID "A-100"
      When на счёт "KZ-01" импортируется операция с ID "A-100"
      Then новая операция не создаётся
      And операция учитывается как дубль

    Scenario: Тот же банковский ID на другом счёте
      Given на счёте "KZ-01" есть операция с банковским ID "A-100"
      When на счёт "KZ-02" импортируется операция с ID "A-100"
      Then новая операция создаётся
      And операция не учитывается как дубль

Здесь проявилась деталь, которой не было в одной фразе «пропускать дубли»: область уникальности. Без явного правила исполнителю пришлось бы выбрать её самостоятельно.

Трассировка

Связь можно сделать машиночитаемой без тяжёлой бюрократии:

UC-07
 ├─ US-07.1 → AC-07.1.1, AC-07.1.2
 ├─ US-07.2 → AC-07.2.1, AC-07.2.2
 └─ US-07.3 → RULE-DEDUP-1
                ├─ EX-DEDUP-1
                └─ EX-DEDUP-2

Идентификаторы позволяют команде и инструментам:

• показать, какое требование реализует тест;
• не потерять расширение при рефакторинге;
• отличить уже поставленное от будущего;
• назвать противоречие точнее, чем «ТЗ неясно».

Но трассировка не должна становиться отдельной ручной базой. Лучше хранить связи рядом с кодом и спецификацией и проверять их простыми скриптами.

5. Минимальный пакет спецификации для coding agent

Для средней продуктовой функции я бы давал агенту не максимально подробное ТЗ, а небольшой связанный пакет:

Контекст:
- проблема и ожидаемый результат
- граница системы
- неоднозначные доменные термины

Use case:
- ID, цель, основной актор и триггер
- предусловия и гарантии
- основной сценарий и существенные расширения

Текущая story:
- связь с use case
- ценность и поставляемый срез
- что входит и не входит в задачу

Правила и примеры:
- общее правило
- успешный, граничный и неуспешный примеры
- вопросы, на которые пока нет ответа

Инженерные контракты:
- затрагиваемые API, события и данные
- требования качества и ограничения архитектуры
- команды проверки

Критерии завершения:
- выбранные примеры проверяются автоматически
- существующие проверки проходят
- изменения вне границы задачи перечислены отдельно

Use case, story и BDD описывают главным образом функциональное поведение. Они не заменяют модель данных, требования к безопасности, задержке и доступности, правила развёртывания, наблюдаемость и архитектурные ограничения. Несколько BDD-примеров проверяют выбранные случаи, но ничего сами по себе не говорят о гонках, лимитах памяти или правах доступа.

6. Типичные ошибки

Ошибка: use case равен happy path

Если записан только основной поток, самые дорогие решения остались за рамкой: отказ внешней системы, повтор, отмена, частичный результат и восстановление.

Исправление: после каждого шага спросить: что может пойти иначе, что система способна обнаружить и что обязана сделать?

Ошибка: use case описывает UI

Последовательность экранов быстро устаревает и преждевременно фиксирует решение.

Исправление: писать намерения акторов и обязанности системы. Сценарий интерфейса хранить отдельно как дизайн реализации.

Ошибка: story считается полным требованием

Три строки As a / I want / so that создают впечатление ясности, но скрывают правила.

Исправление: сохранить 3C. Для агента записать результаты разговора как правила, примеры, границы задачи и открытые вопросы.

Ошибка: технические слои выдают за stories

«Сначала база, потом бэкенд, потом фронтенд» создаёт незавершённые горизонтальные части и откладывает обратную связь.

Исправление: резать вертикально по поведению, правилу, сценарию или простому/сложному варианту.

Ошибка: любой Given / When / Then считается BDD

Gherkin после реализации может быть полезным тестом, но без discovery он лишь структурирует уже сделанные предположения.

Исправление: сначала обсуждать правила, примеры и вопросы; затем формулировать; затем автоматизировать.

Ошибка: сценарии повторяют клики

Такие тесты хрупки и не объясняют бизнес-поведение.

Исправление: When бухгалтер импортирует выписку, а детали UI проверять меньшим числом специализированных тестов.

Ошибка: примеры заменяют правила

Набор точек без обобщения оставляет неизвестным поведение между точками.

Исправление: каждому набору примеров дать одно правило; каждый сценарий должен иллюстрировать конкретное правило.

Ошибка: спецификация пытается предусмотреть всё

Если цена пропущенного поведения невелика, подробная спецификация может не окупиться.

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

7. Практический процесс подготовки задачи агенту

1. Назвать границу и результат. Не «сделать форму импорта», а «бухгалтер добавляет операции из банковской выписки в Accounting System».
2. Перечислить акторов и цели. Пока не углубляться во все поля и ошибки.
3. Написать основной сценарий и расширения. Отделить обязательные сейчас ветки, будущие задачи, неподдерживаемое поведение и открытые вопросы.
4. Выбрать поставляемый story-срез. Он должен давать демонстрируемый результат и завершаться проверкой.
5. Сопоставить правила, примеры и вопросы. В сценарии нужен один фокусный эпизод, наблюдаемый результат и конкретные значения на границах правила; Gherkin допускает несколько When, если без них пример нельзя выразить ясно. Cucumber, Gherkin Reference
6. Добавить инженерные ограничения и провести проверку противоречий. Назвать контракты, требования качества, команды тестирования и запреты, а затем выполнить отдельный проход:

Для каждого критичного примера должно быть ясно:

• какой тест его проверяет;
• на каком уровне;
• какой внешний результат наблюдается;
• что будет сигналом регрессии.

Итог

Use case, user story и BDD не образуют обязательную методологию. В предложенной рабочей модели use case сохраняет цель и ветвящееся поведение, story выбирает следующую поставляемую часть, а BDD-примеры делают конкретные случаи проверяемыми.

Use case говорит агенту:
  не потеряй целую пользовательскую цель и альтернативные пути.

User story говорит:
  реализуй сейчас только этот поставляемый срез.

BDD examples говорят:
  вот как отличить правильное поведение от правдоподобной ошибки.

Ценность здесь не в названиях артефактов и не в их количестве. Она в явных связях между целью, границей текущей задачи, правилами и проверками — и в том, что неизвестное остаётся вопросом, а не превращается в случайное решение исполнителя.

Классические и базовые источники

1. Ivar Jacobson, Alistair Cockburn — Use-Case Foundation — краткая современная фиксация общих основ use case: система, актор, цель и сеть потоков.
2. Alistair Cockburn — Writing Effective Use Cases: Reminders — памятка из классической книги: уровни целей, точность, основной сценарий и extensions.
3. Alistair Cockburn — Writing Effective Use Cases, Addison-Wesley, 2001 — основная книга по goal-oriented текстовым use cases.
4. Martin Fowler — Use Cases and Stories — точное объяснение, почему use cases и user stories организуют требования для разных целей.
5. Bill Wake — INVEST in Good Stories, and SMART Tasks — первоисточник эвристики INVEST и напоминание о Card, Conversation, Confirmation.
6. Mike Cohn — User Stories Applied: For Agile Software Development, Addison-Wesley, 2004 — классическое систематическое изложение user stories.
7. Ron Jeffries — Essential XP: Card, Conversation, Confirmation — классическая формула трёх составляющих user story.
8. Dan North — Introducing BDD — исходная мотивация BDD, story template и Given / When / Then для acceptance criteria.
9. Cucumber — Behaviour-Driven Development — BDD как Discovery, Formulation и Automation.
10. Cucumber — Gherkin Reference — точная семантика Feature, Rule, Scenario, Given, When и Then.
11. Matt Wynne — Introducing Example Mapping — практическая связь story, rules, examples и questions.

Автор: Данил Письменный · Дата: 7 августа 2026