Use Case и User Story: в чём отличие сценариев использования и пользовательских историй

Use Case и User Story — два самых распространённых формата описания требований, которые постоянно путают. Одни команды считают user story «облегчённой версией» сценария использования, другие — наоборот, устаревшим артефактом из мира водопада. На самом деле это инструменты разной природы: сценарий использования фиксирует контракт о поведении системы, а пользовательская история — потребность роли в бэклоге. В этой статье разбираем, в чём отличие user story vs use case, как они связаны (эпик → use case → story), когда какой формат выбирать, и даём практический чеклист выбора.

О чём эта статья

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

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

Что вы узнаете:

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

Что такое Use Case

Сценарий использования — это история о том, как актор достигает значимой цели при взаимодействии с системой. Система рассматривается как чёрный ящик: описывается наблюдаемое поведение, а не внутренняя логика. Формат пришёл из работ Ивара Якобсона и Алистера Коберна и стал частью стандарта Unified Modeling Language (UML), где варианты использования представлены овалами на диаграмме, а их содержание раскрывается в текстовой спецификации.

Ключевые свойства сценария использования:

• Ориентация на цель, а не на действие. Не «нажать кнопку», а «оформить заказ»; не «ввести пароль», а «аутентифицироваться».
• Контракт, а не пожелание. Сценарий фиксирует не только успешный путь, но и обязательства системы при сбое (Failed End Condition, то есть состояние мира при неудаче).
• Проработка исключений. Каждый шаг основного сценария проверяется вопросом «что может пойти не так», и отклонения оформляются расширениями.
• Уровень цели. Коберн выделяет три уровня: Summary (обобщённая цель), User Goal (цель уровня моря — то, что актор делает за один присест) и Subfunction (подфункция). Правильный сценарий пишется на уровне User Goal.

Типичная структура сценария: характеристики (Scope, Preconditions, Trigger, Success и Failed End Condition, Primary Actor), основной успешный сценарий из 3–9 шагов и расширения, привязанные к конкретным шагам. Детальный разбор формата, уровней и шаблона Алистера Коберна — в статье Use Case пример: как писать сценарии использования.

Что такое User Story

Пользовательская история — это короткое описание функции с точки зрения пользователя, которое напоминает команде о потребности и запускает обсуждение деталей. Канонический формат из трёх частей записывается одной фразой:

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

История умышленно неполна. Она работает как обещание разговора: детали уточняются в диалоге с владельцем продукта и оформляются критериями приёмки. Именно поэтому Майк Кон в книге «User Stories Applied» называет историю приглашением к обсуждению, а не спецификацией. Признаки хорошей истории принято описывать акронимом INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable (независимая, договорная, ценная, оцениваемая, маленькая, проверяемая).

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

User Story vs Use Case: восемь отличий

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

1. Уровень. Сценарий использования — артефакт архитектурного уровня: он описывает поведение системы целиком. Пользовательская история — тактический элемент бэклога, из которого собирается инкремент.

2. Форма. Use case — структурированный документ с предусловиями, шагами и расширениями. User story — одно-два предложения по шаблону «Как X, я хочу Y, чтобы Z».

3. Аудитория. Сценарий читают аналитики, архитекторы, тестировщики и заказчик; он служит основой приёмочного тестирования. История адресована в первую очередь команде и владельцу продукта и живёт в инструменте управления бэклогом.

4. Срок жизни. Spec-сценарий обновляется вместе с контрактом системы и может жить годами. История закрывается в конце спринта и заменяется новой — она не претендует на долговечность.

5. Масштаб. Один сценарий покрывает целую цель актора со всеми ветвлениями. Одна история — атомарный кусок ценности, который команда завершает за итерацию.

6. Фокус. Use case концентрируется на цели актора и гарантиях системы. User story — на потребности конкретной роли и пользе, которую она получает.

7. Исключения. В сценарии они прорабатываются явно и обязательно. В истории до уточнения не рассматриваются вовсе — это ответственность критериев приёмки и диалога.

8. Готовность к разработке. Хорошо написанный use case почти готовое техническое задание. История всегда требует детализации: без критериев приёмки она не готова к реализации.

Таблица сравнения

Правило выбора простое: нужно быстро проверить гипотезу и получить обратную связь — берите user story. Нужно зафиксировать обязательства системы перед актором на годы вперёд и не потерять исключения — пишите use case. В реальных проектах форматы почти всегда сосуществуют, и вопрос не «или-или», а «что во что раскрывается».

Как связаны: эпик → use case → user story

Самый практичный способ примирить форматы — выстроить иерархию артефактов. Сверху лежит эпик (Epic) — крупная бизнес-цель. Эпик раскрывается в один или несколько сценариев использования, потому что именно они описывают поведение системы целиком. Сценарий, в свою очередь, служит источником пользовательских историй: их можно нарезать по шагам основного сценария или по расширениям, но каждая история должна оставаться самостоятельной ценностью, то есть удовлетворять критерию Valuable из INVEST.

Такая связка даёт три эффекта:

• Полнота. Сценарий гарантирует, что ни одна ветка и ни одно исключение не потеряны, а истории просто реализуют уже описанное поведение.
• Трассируемость. Каждую историю можно связать с конкретным шагом или расширением use case, а затем — с тест-кейсом приёмочного тестирования.
• Планируемость. Истории достаточно малы, чтобы попадать в спринт, но их источник — стабильный контракт, а не случайный набор пожеланий.

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

Use Case требования: как превратить сценарий в постановку

Сценарий использования — не замена списку требований, а каркас, который делает их проверяемыми. Каждый элемент превращается в конкретное требование.

Порядок работы: каждый шаг формулируется как «Система должна…», каждое расширение — как требование поведения при условии, а подчинённые сценарии (include) и расширения (extend) получают собственную нумерацию. В итоге аналитик отдаёт разработке не список из сотни фраз «должен», а связную модель, из которой видно, что произойдёт в любой ситуации.

Когда что использовать

Use Case уместен, когда:

• система сложная и многоуровневая: B2B, enterprise, государственные сервисы;
• требования формальные и подлежат согласованию с заказчиком или регулятором;
• критичны исключения и ошибки, а цена сбоя высока;
• нужна база для приёмочного тестирования и трассируемости;
• есть доступ к предметным экспертам и время на проработку.

User Story уместен, когда:

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

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

Примеры: заполненная user story и сценарий использования

Заполненная пользовательская история

Сценарий использования «Оформление заказа»

Основной успешный сценарий

Расширения

Разбиение сценария на истории — один из вариантов, а не обязательное правило: можно взять по истории на шаг основного сценария или на расширение, но каждая такая история всё равно должна приносить самостоятельную пользовательскую ценность (критерий Valuable из INVEST). Если отдельный шаг ценности не несёт, шаги лучше объединить в одну историю. Именно так сценарий становится источником бэклога.

Чеклист выбора

• Требование описывает сложное поведение с ветвлениями и ошибками → выберите use case.
• Нужен артефакт для согласования с заказчиком или регулятором → выберите use case.
• Нужна основа для приёмочного тестирования → выберите use case.
• Требование атомарно и понятно команде → достаточно user story.
• Работа идёт короткими итерациями с частой сменой приоритетов → начните с user story.
• Есть эпик, который не декомпозируется → раскройте его в один-два use case.
• Истории накапливаются без общей картины → восстановите use case из группы историй.
• Не понятно, что делать при сбое → добавьте расширения в use case.
• Спор о формате вместо разговора о поведении → задайте вопрос «какой результат нужен актору».
• Команда не читает формальные документы → оставьте use case для критичных узлов, остальное — истории.

Частые ошибки

Ресурсы

• Алистер Коберн, «Writing Effective Use Cases» — каноническое руководство по написанию сценариев, уровням целей и шаблону.
• Дэрил Кулак и Имон Гинн, «Use Cases: Requirements in Context» — применение сценариев в процессе разработки требований.
• Айвар Якобсон, «Object-Oriented Software Engineering: A Use Case Driven Approach» — первоисточник метода вариантов использования.
• Майк Кон, «User Stories Applied» — практика работы с пользовательскими историями, INVEST и критериями приёмки.
• Джефф Паттон, «User Story Mapping» — как выстраивать истории в карту и видеть целостный путь пользователя.
• Карл Вигерс и Джой Битти, «Разработка требований к программному обеспечению» — классификация пользовательских и функциональных требований.
• Стандарт OMG UML 2.5 — формальное определение актора, варианта использования и отношений include, extend, generalization.
• Стандарт ISO/IEC/IEEE 29148 «Systems and software engineering — Life cycle processes — Requirements engineering» — требования к спецификации.

Что дальше

• Use Case пример: как писать сценарии использования по Коберну — шаблоны, уровни целей и полные примеры.
• Use Case диаграмма: элементы, правила и примеры — как визуализировать акторов и варианты использования.
• Справочник аналитика: требования к ПО — виды требований и работа с ними.
• Собеседование системного аналитика — как проверяют знание форматов требований.
• Руководство по системному дизайну — как требования превращаются в архитектурные решения.