Use Case и пользовательские сценарии
Use case описывает один путь пользователя к цели вместе с тем, что происходит, когда что-то идёт не так. Он нужен там, где короткой истории уже мало.
User Story из статьи 02-08 говорит, кто чего хочет и зачем. Критерии приёмки из статьи 02-09 говорят, когда работа считается готовой. Но если у функции много шагов и веток, обоим форматам тесно: порядок действий и отклонения от него приходится держать в голове. Для таких случаев используют use case, или сценарий использования.
Use case (сценарий использования) - описание того, как пользователь достигает одной цели при работе с системой, включая успешный путь и сбои. Иначе говоря, use case - это все способы использования системы для достижения конкретной цели конкретным пользователем.
Кейс: отмена заказа с несколькими ветками
Владелец магазина «Узелок» хочет, чтобы покупатели сами отменяли заказы и не писали в поддержку. История готова, критерии приёмки к ней записаны. Команда начинает обсуждать детали и быстро выясняет, что вопросов больше, чем строк в истории: что видит покупатель после нажатия кнопки, нужно ли подтверждение, что делать, если заказ уже у курьера, куда возвращается человек, если он передумал.
Ответы на эти вопросы разбросаны по обсуждению, и каждый участник помнит их по-своему. Нужен один документ, где путь покупателя записан по шагам, а отклонения лежат рядом с шагами, к которым относятся. Это и есть use case.
Правила в примере условные: мы берём их для иллюстрации, а не из реального магазина.
Из чего состоит use case
У use case есть несколько обязательных частей. Актор (участник) - тот, кто взаимодействует с системой. Главный актор - тот, кто начинает сценарий. В нашем случае это покупатель. Цель - то, ради чего актор использует систему и какую пользу получает, когда всё прошло успешно.
Основной сценарий (его же называют базовым потоком или счастливым путём) - обычный путь к цели, когда всё идёт по плану. Расширения (альтернативные потоки) - особые случаи, необязательные шаги и ошибки, которые нужно обработать.
Часто к этому добавляют предусловие: что должно быть верно до начала сценария. В нашем примере заказ должен быть оплачен и ещё не передан курьеру. Набор полей зависит от команды, и в классическом описании предусловие отдельно не выделено, но на практике оно помогает не пропустить условия входа.
Как писать основной сценарий
Основной сценарий записывают нумерованными шагами. В каждом шаге один актор делает одно действие или система отвечает на него. Так легко увидеть, кто и что делает на каждом этапе.
Для кейса основной сценарий выглядит так:
- Покупатель открывает заказ в списке.
- Покупатель нажимает «Отменить». Система проверяет статус заказа.
- Система просит подтвердить отмену, покупатель подтверждает.
- Система меняет статус на «Отменён» и возвращает деньги.
Шаги описывают поведение, а не устройство экрана: «покупатель нажимает «Отменить»», а не «кнопка в правом верхнем углу». Такой текст не устареет при изменении дизайна. Как согласовывать сами экраны, рассказано в статье 02-15.
Расширения: что идёт не по плану
Каждое расширение привязано к номеру шага, на котором возникает отклонение. Запись начинают с условия и продолжают тем, что делает система. Расширение либо возвращает в основной сценарий, либо завершает его отказом.
В кейсе их два:
- 2а. Заказ уже передан курьеру. Система отказывает и объясняет причину, сценарий завершается без изменений.
- 3а. Покупатель передумал и отказался от подтверждения. Система возвращает его на страницу заказа, статус не меняется.
Именно здесь команда находит то, что в короткой истории не видно. Если расширение 2а не записать, о нём вспомнят уже после релиза.
Use case или User Story
Форматы не конкурируют. История коротка и удобна для планирования: она отвечает на вопросы «кто, что, зачем». Use case длиннее и показывает диалог пользователя с системой по шагам. Его берут там, где в процессе много веток или нужно договориться о порядке действий.
На практике часто начинают с истории и раскладывают в use case только сложную часть. Простые функции в полном сценарии не нуждаются: для кнопки «Выйти» хватит одной строки в трекере.
Отдельно скажем о пользовательских сценариях. В обиходе так называют описание того, что человек делает, чтобы достичь цели, и обычно оно менее формальное, чем use case: без полей и номеров шагов. Это хороший первый шаг, если нужно быстро понять путь пользователя, а потом при необходимости превратить его в use case. Точные определения у команд различаются, поэтому в рабочем документе стоит договориться, какое слово что означает.
Диаграмма вариантов использования, которая показывает набор use case и акторов на одной схеме, разобрана в статье 07-02.
Где это встречается в работе
- В требованиях к функциям с несколькими шагами: оформление заказа, регистрация, возврат.
- В обсуждении с разработчиками и тестировщиками, когда нужно договориться о порядке действий.
- В основе тест-кейсов: основной сценарий и расширения дают готовый набор проверок.
- В описании взаимодействия с внешними системами, где у каждой стороны своя роль.
Итог
- Use case описывает один путь пользователя к одной цели.
- Основные части: главный актор, цель, основной сценарий, расширения.
- Основной сценарий записывают нумерованными шагами, расширения привязывают к номеру шага.
- Шаги описывают поведение, а не внешний вид экрана.
- Use case дополняет User Story там, где много веток, и не заменяет её для простых функций.
Что дальше
- 02-18 Неполные и противоречивые требования: как находить пропущенные расширения и конфликты в описании.
- 02-25 От требований к тестированию: как из сценариев получаются тест-кейсы.
- 07-02 Диаграмма вариантов использования: как показать набор use case на схеме.
5 вопросов