Use Case (прецедент) и User Story (пользовательская история) — не конкурирующие «школы», а форматы с разным уровнем детализации и разной ролью в процессе. На проекте вопрос не «что правильнее», а какой артефакт закроет риск: пробел в сценариях, неуправляемые изменения или контрактную прослеживаемость. Эта заметка даёт критерии выбора, схему решения и гибридные схемы — без повторения полной структуры прецедента или правил INVEST (они в соседних материалах).

1. Суть темы

Use Case — текстовое описание взаимодействия актора (пользователя или внешней системы) с системой для достижения цели: основной поток, альтернативы, исключения, пред- и постусловия. Отвечает на вопрос «как система ведёт себя во всём множестве допустимых сценариев».

User Story — компактная запись намерения в формате «Как…, я хочу…, чтобы…»; приглашение к диалогу, а не исчерпывающая спецификация. Детали уточняются в обсуждении и 02.04.02 Критерии приёмки (Acceptance Criteria).

Выбор между форматами зависит от сложности логики, требований к формализации (00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)), методологии поставки и зрелости коммуникаций. Job Story — отдельный формат с фокусом на ситуацию и мотивацию; когда он уместнее User Story, см. 04.02 Пользовательские истории (User Stories) и Job Stories.

Ни Use Case, ни User Story не заменяют нефункциональные требования (NFR): производительность, безопасность, доступность фиксируются отдельно — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR).

Выбор не всегда бинарный: процессный scope с оркестрацией между ролями чаще описывают в BPMN (03.04.01 BPMN 2.0 - введение и основы); интеграционные сценарии с внешней системой как актором могут стыковаться с контрактами API (03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)). Use Case и User Story — про функциональное поведение в рамках первичной документации (04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)), а не про единственный способ описать любую потребность.

2. Ключевые понятия

2.1. Контраст форматов (что влияет на выбор)

Полная семантика полей прецедента, место UC/US в SRS и FRD — в 02.03.03 Спецификация требований (SRS, Use Case, User Story). Связь текстового Use Case с 03.02.01 Диаграмма прецедентов (Use Case Diagram) и 06.01.02 Поведенческие диаграммы (State, Activity, Use Case) — там же.

Ниже — не полное сравнение форматов, а оси решения «что брать на проекте»:

Критерий выбораСклонность к Use CaseСклонность к User Story
Риск ошибки и контрактРегуляторика, аудит, Fixed Price, матрица «требование → тест» — 02.03.04 Трассировка требований (концепция).Внутренний продукт, допустимы уточнения в ходе поставки.
Изменения scopeРедкие релизы, baseline до разработки — 05.01 Waterfall и V-model.Живой backlog, частые переприоритизации — 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.
Сложность сценарияМного веток, акторов, жёсткий порядок шагов; AC «раздуваются».Простой вертикальный срез, мало альтернатив.
ТестированиеПотоки → тест-кейсы и регрессия по сценарию.AC на уровне истории; сквозные e2e по цепочкам историй и интеграций — отдельно, см. 08.03 Тестирование требований (статическое тестирование).

2.2. Масштаб артефактов в backlog

На практике форматы наслаиваются по масштабу, а не заменяют друг друга один к одному:

УровеньТипичный артефактСвязь
Epic / FeatureКрупная ценность или модульЧасто соответствует одному Use Case или группе прецедентов; на масштабируемых фреймворках — см. 05.03 SAFe и LeSS — аналитик в масштабируемых фреймворках
Use CaseПолный сценарий с ветвлениямиИсточник декомпозиции; карта для трассировки
Story / SliceЭлемент backlog или срез Use Case 2.0Реализуется за итерацию; приоритизация — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)

Use Case 2.0 (Ивар Якобсон) трактует прецедент как контейнер срезов (slices) для инкрементальной поставки. Срез — не обязательно карточка в формате INVEST: это минимальный проходимый фрагмент сценария; в backlog он может быть оформлен как story, task или feature — главное, чтобы срез был реализуем и проверяем отдельно.

2.3. Потоки прецедента

Терминология альтернативных, исключительных потоков и extension point — в 02.03.03 Спецификация требований (SRS, Use Case, User Story); типичная ошибка путаницы extension point с отдельным потоком — в §4.

3. Как применяется в работе аналитика

3.1. Когда выбирать Use Case

  • Высокая сложность бизнес-логики — страхование, налоги, банковские операции: много ветвлений, ошибок, бизнес-правил.
  • Формальная прослеживаемость и V&V — регулируемые отрасли, аудит, матрица «требование → тест» — 02.03.04 Трассировка требований (концепция), 10.01.15 Шаблон матрицы трассировки, 02.04.01 Верификация и валидация (V&V), 02.04.03 Управление качеством требований.
  • Waterfall или гибрид с фазой анализа — 05.01 Waterfall и V-model: baseline до разработки.
  • Контракт с подрядчиком (Fixed Price) — UC или приложение с прецедентами как юридически значимый scope; на практике часто гибрид с Agile backlog — см. §3.3.
  • Распределённая команда — когда асинхронная переписка заменяет ежедневный диалог; детальный UC снижает риск разночтений.
  • Обучение — прецеденты как читаемая документация системы для новых участников.
  • Непользовательский актор — внешняя система, batch, scheduler, шина событий: классическая User Story часто degenerate («Как cron…»); уместны Use Case с системным актором, 03.02.02 Диаграмма деятельности (Activity Diagram) или контракт API + оркестрация на нашей стороне — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).
  • Интеграционный контур — когда граница scope проходит по контракту с внешней системой, UC описывает поведение нашей стороны (шаги, ошибки, компенсации), а OpenAPI/AsyncAPI фиксирует обмен; выбор «US vs UC» здесь про orchestration, а не про замену спецификации контракта.

3.2. Когда выбирать User Story

  • Итерационная поставка — Scrum, Kanban, XP (05.02 Scrum и Kanban (аналитик в Agile), 05.05 Методология быстрой разработки (RAD, XP)): короткие циклы, ценность важнее многотомной спецификации.
  • Частые изменения требований — истории легко переписать или выбросить без каскада правок в потоках.
  • Живой диалог с заказчиком — классический Product Owner не обязателен: PO-функцию часто выполняет аналитик, продуктовый менеджер или представитель бизнеса; Kanban и внутренние продукты тоже работают на историях.
  • Независимые вертикальные срезы — функцию можно показать за итерацию.
  • Технический долг и enabler-истории — формулировка через пользовательскую ценность («быстрее загрузка»), а не через «обновить библиотеку» без «чтобы». Enabler не заменяет Use Case, если под «техническим» пунктом скрыта сложная доменная ветка с множеством альтернатив — см. §3.4.

3.3. Гибридные схемы

Жёсткое «или–или» на зрелых проектах редко оправдано:

  • UC как карта → US в backlog. Обзорная 03.02.01 Диаграмма прецедентов (Use Case Diagram) и границы системы — 02.01.04 Определение границ решения (Scope Modelling); каждый прецедент декомпозируется в истории. UC не даёт забыть поток; US — поставлять инкрементально.
  • Use Case 2.0. Прецедент = контейнер срезов; каждый срез — единица планирования (не обязательно классическая User Story).
  • Mini-Use Case внутри истории. Если у одной истории много веток — краткий UC или таблица веток в AC или комментарии к задаче.
  • Fixed Price + Agile backlog. См. гибрид в §3.1: контур scope в UC/SRS, реализация и приёмка спринтов — по историям с трассировкой к прецеденту.

3.4. Чеклист: достаточно ли критериев приёмки

Переходите от User Story к Use Case (или гибриду), если выполняется хотя бы один пункт:

  • Много значимых альтернатив или исключений — ориентир ~4–5 веток, не метрика; эквивалентный сигнал — раздувание AC до многостраничного документа или постоянное «открытие» новых веток на refinement.
  • Регуляторика или контракт требуют явного покрытия ошибок и трассировки к тестам.
  • Несколько акторов и систем в одном сценарии с жёстким порядком шагов — при детализации шагов полезны 03.02.03 Диаграмма последовательности (Sequence Diagram) или 03.02.02 Диаграмма деятельности (Activity Diagram) рядом с текстовым UC.
  • Распределённая команда без регулярных сессий уточнения.

Если веток мало, домен прост и диалог стабилен — достаточно истории с AC (02.04.02 Критерии приёмки (Acceptance Criteria)). Промежуточный слой — BDD / Gherkin (Given–When–Then): сценарии в AC без полной структуры прецедента; когда Gherkin тоже раздувается — сигнал к UC. Шаблоны: 10.01.01 Шаблон User Story, 10.01.02 Шаблон Use Case.

3.5. Диаграмма принятия решения

flowchart TD
    START["Нужно описать функциональность"] --> Q1{"Формальная спецификация<br>и полное покрытие ошибок?"}
    Q1 -->|Да| Q1A{"Нужна итерационная<br>поставка (Agile/Kanban)?"}
    Q1A -->|Да| HYBRID["Гибрид: UC как карта/контракт,<br>US или срезы для поставки"]
    Q1A -->|Нет| UC["Use Case<br>(+ трассировка, V&V)"]
    Q1 -->|Нет| Q2{"Живой backlog<br>и частые изменения?"}
    Q2 -->|Да| Q3{"Много ветвлений<br>и исключений?"}
    Q2 -->|Нет| Q3
    Q3 -->|Да| Q3A{"Есть итерационная<br>поставка?"}
    Q3A -->|Да| HYBRID
    Q3A -->|Нет| UC
    Q3 -->|Нет| Q4{"Контрактная<br>прослеживаемость?"}
    Q4 -->|Да| UC
    Q4 -->|Нет| Q5{"Есть PO-функция<br>или тесный диалог?"}
    Q5 -->|Да| US["User Story<br>+ критерии приёмки"]
    Q5 -->|Нет| UC

Схема — эвристика, не закон: при формальности и Agile одновременно сначала смотрите на гибрид, а не на «чистый» UC. Чем выше цена ошибки и слабее синхронная коммуникация, тем сильнее крен к прецеденту.

Если схема вывела в Use Case из‑за отсутствия PO-диалога (Q5 → Нет), обязательна трассировка к элементам плана — иначе UC превращается в «мёртвую спецификацию» (§4): каждый поток или срез должен быть связан с задачей backlog, релизом или тестом — 02.03.04 Трассировка требований (концепция).

3.6. Практические рекомендации

  • Начинайте с цели пользователя, не с формата: «какую работу выполняет актор?» — название прецедента или набор историй.
  • Не превращайте истории в мини-Use Case — намерение в story, ветки — в AC, Gherkin, прототипах или отдельном UC.
  • Если из обсуждения ускользают альтернативы («а если карта просрочена?») — формализуйте ветки через Use Case.
  • Несколько акторов и жёсткая последовательность — текстовый UC дополняйте sequence или activity diagram, а не раздуваете AC.
  • Документация в Agile — живой backlog и исполняемые тесты; для регулируемых доменов и пост-поставки добавьте UC и диаграммы — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD).

4. Типовые ошибки и ограничения

  • Считать выбор «религией методологии» — Kanban без PO и Waterfall с итерациями ломают бинарные правила «Agile = только US».
  • User Story как единственный слой тестирования — без e2e по цепочкам историй и интеграций регрессия даёт ложное спокойствие.
  • Use Case без связи с backlog — «мертвая» спецификация, которую команда не читает при планировании спринта; особенно типично, если UC выбран из‑за асинхронной коммуникации, но трассировка к backlog не заведена.
  • Игнорирование NFR — ни UC, ни US не покрывают производительность, безопасность, SLA.
  • Путаница extension point и отдельного потока — extension point это шаг основного потока, с которого возможен переход в альтернативу; трактовать его как «ещё один тип потока» — дублирование шагов и раздувание документа. Подробнее — 02.03.03 Спецификация требований (SRS, Use Case, User Story).
  • Enabler вместо UC для сложной доменной ветки — «рефакторинг правил расчёта» не снимает необходимость описать альтернативы и ошибки.
  • Ожидание, что slice Use Case 2.0 = User Story в формате «Как…» — срез может быть task/feature с другим шаблоном.
  • Тезис «документация = только тесты + backlog» — недостаточен для аудита, контракта и онбординга; нужен осознанный минимум артефактов под контекст.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги

  • Алистер Кокбёрн. Writing Effective Use Cases («Эффективное написание Use Case») — уровни целей, потоки, extension points.
  • Ивар Якобсон и др. Use Case 2.0: The Guide to Succeeding with Use Cases — срезы и адаптация прецедентов к Agile: https://www.ivarjacobson.com/publications/white-papers/use-case-2-0-the-guide-to-succeeding-with-use-cases/
  • Майк Кон. User Stories Applied («Пользовательские истории») — классика Agile-стороны.
  • Курт Биттнер, Алистер Кокбёрн. Use Case Modeling — моделирование прецедентов.

Стандарты

Статьи