Урок 3 из 8 · 20 мин · обновлено

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

Как описать работу системы глазами пользователя: сценарий использования (use case) с основным и альтернативными потоками, пользовательские истории и критерии приёмки в формате «дано — когда — тогда».

Сценарий использования

Сценарий использования (use case) — описание того, как пользователь достигает цели с помощью системы, шаг за шагом. Пример:

Сценарий: оплата заказа баллами

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

Основной поток:

  1. Гость открывает экран оплаты.
  2. Система показывает сумму заказа и доступные баллы.
  3. Гость нажимает «Списать баллы».
  4. Система рассчитывает, сколько баллов можно списать: не больше 50% суммы заказа.
  5. Система показывает новую сумму к оплате.
  6. Гость оплачивает остаток картой.
  7. Система списывает баллы и создаёт заказ.

Альтернативные потоки:

  • 4а. Баллов меньше 50% суммы — списываются все доступные баллы.
  • 6а. Оплата картой не прошла — баллы не списываются, гость видит ошибку и может повторить.
  • 7а. Система лояльности не отвечает — заказ создаётся без списания, гость видит сообщение «Баллы недоступны, попробуйте позже».

Альтернативные потоки — самое ценное. Основной сценарий понятен всем, а ошибки в работе обычно прячутся в исключениях.

Пользовательские истории

Пользовательская история — короткая формулировка в формате «Как [кто], я хочу [что], чтобы [зачем]»:

Как гость, я хочу оплатить часть заказа баллами, чтобы кофе обходился дешевле.

Истории удобны для гибкой разработки: их легко обсуждать, оценивать и брать в спринт. Подробно они разобраны в уроке «Бэклог и пользовательские истории» курса про Scrum.

История короткая, поэтому к ней добавляют критерии приёмки, а для сложной логики — ссылку на use case.

Критерии приёмки «Дано — Когда — Тогда»

Удобный формат критериев — Дано — Когда — Тогда (Given — When — Then):

  • Дано: у гостя 100 баллов, заказ на 300 ₽. Когда: гость нажимает «Списать баллы». Тогда: списывается 100 баллов, к оплате 200 ₽.

  • Дано: у гостя 500 баллов, заказ на 300 ₽. Когда: гость нажимает «Списать баллы». Тогда: списывается 150 баллов (50% суммы), к оплате 150 ₽.

  • Дано: оплата картой не прошла. Когда: гость возвращается на экран оплаты. Тогда: баланс баллов не изменился.

Такие критерии одинаково понимают все: разработчик знает, что делать, тестировщик — что проверять, заказчик — что получит.

Попробуйте сами. Напишите use case «Начисление баллов за заказ»: основной поток и 2–3 альтернативных. Добавьте два критерия приёмки в формате «Дано — Когда — Тогда».

Пример

Основной поток:

  1. Гость оплачивает заказ.
  2. Система отправляет данные заказа в систему лояльности.
  3. Система лояльности начисляет 5% от суммы, округляя вниз до целого балла.
  4. Гость видит уведомление «+15 баллов» и новый баланс.

Альтернативные потоки:

  • 2а. Система лояльности не отвечает — повторная отправка каждые 5 минут в течение часа, потом задача для поддержки.
  • 3а. Заказ оплачен баллами частично — баллы начисляются только на сумму, оплаченную картой.
  • После начисления заказ отменён — начисленные баллы списываются.

Критерии приёмки:

  • Дано: заказ на 310 ₽ оплачен картой. Когда: оплата прошла успешно. Тогда: начислено 15 баллов.
  • Дано: заказ на 300 ₽, 100 ₽ оплачено баллами. Когда: оплата прошла. Тогда: начислено 10 баллов — 5% от 200 ₽.

Мини-тест: проверьте себя

Закрепите урок: несколько вопросов, разбор ответов — в конце.

  1. Что такое альтернативный поток в use case?

  2. Как лучше записать критерий приёмки?

  3. Когда use case полезнее короткой пользовательской истории?