User Story и Use Case: отличия, примеры и критерии приёмки

коротко

User Story описывает потребность и пользу для пользователя; её уточняют в обсуждении и подтверждают согласованными условиями приёмки. Use Case описывает поведение системы при достижении цели актора: основной сценарий и значимые альтернативы. Это не выбор между «коротко» и «подробно»: форматы решают разные задачи и могут использоваться вместе. Карточка истории, сценарии, бизнес-правила и критерии должны говорить об одном и том же поведении.

Я однажды видел стори «Как пользователь, я хочу восстанавливать пароль, чтобы вернуть доступ к аккаунту». Идеально по форме. Разработчик сделал восстановление по email. На приёмке выяснилось, что половина пользователей регистрировалась по телефону, без почты, — и для них фича не работала вообще. Стори была права, но под ней не было ни одного критерия приёмки. Все кивнули на красивую формулировку и разошлись, поняв каждый своё.

Что такое user story

User story — это короткое описание потребности с точки зрения того, кому она нужна. Распространённый шаблон карточки — три части; следовать ему дословно необязательно:

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

Как покупатель, я хочу сохранить карту,
чтобы не вводить её номер при каждой покупке.

Каждая часть помогает задать вопрос. Роль — кому нужна возможность; цель — чего этот человек хочет добиться; ценность — зачем ему результат. «Чтобы было удобно» почти ничего не уточняет. «Чтобы не вводить реквизиты при каждой покупке» уже объясняет проблему, для которой можно обсуждать разные решения.

Короткая карточка — только часть работы с историей. Модель Card, Conversation, Confirmation связывает запись потребности, обсуждение и подтверждение результата. Обсуждение не отменяет документацию: согласованные правила, примеры, ограничения и критерии нужно сохранить в доступном команде виде. История может ссылаться на спецификацию API или Use Case; всё это не обязано помещаться в одну фразу.

Что такое use case

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

Граница системы и основной актор — чьё поведение описываем и кто достигает цели.
Предусловие — что должно быть верно до старта (пользователь авторизован).
Основной сценарий — успешный ход событий по шагам.
Альтернативные сценарии — ветки и ошибки (карта отклонена, нет связи с банком).
Постусловие — что стало верно после (заказ оплачен, статус обновлён).

На примере отмены брони ниже видно, зачем разделять проверки. Это блок-схема части поведения, а не UML-диаграмма вариантов использования и не полное описание Use Case.

flowchart TD
  A["Запрос отмены брони"] --> B{"Есть право отмены?"}
  B -- "нет" --> X["Отказать без изменения брони"]
  B -- "да" --> C{"Уже отменена?"}
  C -- "да" --> D["Подтвердить текущий статус"]
  C -- "нет" --> E{"Время сервера меньше начала?"}
  E -- "нет" --> X
  E -- "да" --> F["Отменить бронь"]

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

Разница и когда что брать

Что сравниваем	User Story	Use Case
Основной вопрос	Какая возможность нужна пользователю и зачем?	Как система ведёт себя при достижении цели актора?
Способ уточнения	Обсуждение, правила, примеры и критерии приёмки	Предусловия, шаги, альтернативы и постусловия
Применение	Обсуждение и планирование пользовательской ценности	Согласование взаимодействий и исходов сценария
Что не определяет формат	Число строк и обязательный шаблон «Как…»	Объём документа и обязательная подробность каждого шага

На практике форматы можно связать. История объясняет, зачем нужна отмена брони, Use Case раскрывает поведение, а критерии позволяют проверить согласованные исходы. Не стоит выбирать только по сложности функции: важнее, кому нужен артефакт и какие вопросы пока не решены. У одной истории может быть несколько сценариев; один Use Case может реализовываться несколькими историями. Соответствие один к одному необязательно.

Критерии приёмки: то, что делает story проверяемой

Критерии приёмки (acceptance criteria) — согласованные проверяемые условия принятия конкретного изменения. Они описывают ожидаемое поведение и ограничения. Это не полный тест-план и не замена Definition of Done: общие требования к качеству и готовности поставки действуют отдельно.

Писать их можно просто списком, а можно как примеры given-when-then, знакомые по Gherkin («дано — когда — тогда»):

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

Дано: у пользователя подтверждён телефон; email не указан
Когда: он выбирает восстановление доступа по телефону
Тогда: система отправляет код на этот телефон
       и не требует указать email

Given-when-then разделяет начальные условия, действие и наблюдаемый результат. В этой записи нет автоматического теста: для него понадобятся шаги и реализация проверок. Лимиты попыток, срок действия кода и защиту от раскрытия существования аккаунтов надо согласовать отдельно, а не выдумывать числа при написании примера.

Когда согласовывать критерии

Критерии полезно обсуждать до реализации, чтобы команда одинаково понимала результат. Они могут уточняться по мере появления новых сведений. Если команда использует Definition of Ready, требования к такой проработке можно включить в него. Само наличие документа ещё не означает, что все существенные вопросы решены.

Карточка не заменяет договорённость

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

Формат не определяет метод разработки

User Story и Use Case можно применять и при итеративной работе, и при подготовке формальной документации. Наличие сценария не делает процесс «тяжёлым», а короткая карточка не делает его Agile. Выбирайте глубину описания по риску разного понимания, а не по ярлыку методологии.

Одна функция в двух форматах: отмена бронирования

Возьмём учебную систему MeetRoom и отдельный вариант правил отмены. Отменять активную бронь вправе её организатор строго до времени начала. Повторный запрос к уже отменённой своей брони подтверждает её статус. Эти правила заданы для упражнения; их надо согласовать заново для реального продукта.

Story отвечает «кому и зачем». Use case раскрывает шаги и альтернативы. Критерии приёмки позволяют проверить результат. Сравнивайте их на одной функции — иначе легко принять разницу предметных областей за разницу форматов.

User Story — отмена бронирования MeetRoom
Как организатор встречи, я хочу отменить ненужное бронирование,
чтобы переговорку могли использовать другие сотрудники.

Правила учебного примера
R1. Отменить активную бронь может только её организатор.
R2. Отмена разрешена, пока время сервера строго меньше времени начала.
    При равенстве или после начала — отказ. Время проверяется при отмене,
    а не только при открытии страницы.
R3. Отменённая бронь сохраняется в истории и больше не блокирует интервал.
R4. Повторная отмена своей отменённой брони подтверждает её статус,
    независимо от времени встречи. Другие брони не изменяются.
Организатор и время начала в этом упражнении не редактируются.

Критерии приёмки
AC1. Дано: своя активная бронь; других ограничений занятости нет.
     Когда: система принимает отмену до времени начала.
     Тогда: статус — cancelled; этот интервал можно забронировать снова.
AC2. Дано: бронь принадлежит другому сотруднику.
     Когда: пользователь запрашивает её отмену напрямую в API.
     Тогда: отказ; операция не изменяет бронь и не раскрывает её детали.
AC3. Дано: своя активная бронь.
     Когда: отмена обрабатывается ровно в момент начала или позже.
     Тогда: отказ; операция не изменяет статус брони.
AC4. Дано: своя бронь отменена; на её место уже создана другая бронь.
     Когда: пользователь повторяет отмену своей брони, даже после начала.
     Тогда: система подтверждает cancelled; новая бронь не изменяется.
AC5. Дано: ответ на отмену не получен.
     Когда: пользователь возвращается к карточке брони.
     Тогда: интерфейс запрашивает актуальный статус; при недоступности
     системы сообщает, что результат пока неизвестен, а не об успехе.

Use Case UC-CANCEL — отменить бронирование
Граница системы: MeetRoom, включая интерфейс и сервер.
Основной актор: сотрудник — организатор встречи.
Предусловия: сотрудник авторизован, выбрана существующая своя бронь;
            доступ к её деталям уже проверен.
Триггер: сотрудник выбирает действие «Отменить бронирование».
Основной сценарий:
1. Система запрашивает подтверждение отмены.
2. Сотрудник подтверждает отмену.
3. Система повторно проверяет права и актуальный статус брони.
4. Для активной брони система проверяет время и меняет статус на cancelled
   как единое согласованное действие. Бронь перестаёт блокировать интервал.
5. Система показывает отменённый статус.
Альтернативы:
2a. Сотрудник передумал — завершить без изменения брони.
3a. Доступ утрачен — отказ; эта операция ничего не изменяет.
3b. Своя бронь уже отменена — перейти к шагу 5 без изменения других броней.
4a. Время сервера не меньше времени начала — отказ без изменения статуса.
5a. Клиент не получил ответ — результат неизвестен; запросить статус.
    Если связи нет, сохранить сообщение о неизвестном результате.
Постусловие успеха: выбранная бронь имеет статус cancelled
                  и не блокирует интервал.
Гарантия при отказе проверки: эта операция не изменяет бронь.
Другие сотрудники могут независимо создавать брони на свободное время.

AC2 проверяет защиту API за пределами штатного UI-сценария UC-CANCEL.
Сбой связи не доказывает ни отмену, ни сохранение активного статуса.

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

Шаблоны User Story и Use Case

USER STORY
Как [конкретная роль], я хочу [цель], чтобы [ценность].
Правила и ограничения: [...]
Критерии: Дано [...] / Когда [...] / Тогда [проверяемый результат].
Отдельно проверьте: права, границы времени, повтор, неизвестный результат.

USE CASE
Граница системы: [...]
ID и цель: [...]
Актор: [...]
Предусловия: [...]
Триггер: [...]
Основной сценарий (действия актора и ответы системы): [...]
Альтернативы с привязкой к номеру шага: [...]
Постусловие успеха: [...]
Что сохраняется при отказе: [...]
Открытые вопросы и допущения: [...]

Открыть заполненный пример (.txt) · Открыть пустые шаблоны (.txt). Их можно сохранить и отредактировать в любом текстовом редакторе.

Проверьте себя на изменении правила

Заказчик разрешил офис-менеджеру отменять чужую бронь. Какие акторы, проверки прав и критерии теперь меняются? Затем попробуйте тренажёр критериев приёмки: он поможет отличать проверяемое условие от пожелания.

Частые вопросы

User Story или Use Case — что выбрать?

Для обсуждения пользовательской ценности и планирования полезна история. Для согласования поведения системы, веток и исходов — Use Case. При необходимости используйте оба, связывая их с одними бизнес-правилами. Размер функции и методология команды сами по себе выбор не определяют.

Как писать критерии приёмки?

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

Чем Use Case отличается от диаграммы Use Case?

Вариант использования описывает поведение системы ради цели актора. UML-диаграмма вариантов использования показывает акторов, варианты использования и связи. Овалы и связи не раскрывают автоматически порядок шагов, проверки и ошибки; их описывают отдельно.

Определение вариантов использования и акторов: OMG UML 2.5.1, раздел UseCases.