Use case — это структурированное описание взаимодействия актера (пользователя, другой системы, сервиса) с вашей системой для достижения конкретной цели. В отличие от user story, которая концентрируется на ценности («как [роль], хочу… чтобы…»), use case раскрывает пошаговый сценарий: что происходит до начала, как протекает основной поток, какие есть развилки, что считаем завершением и какие условия должны быть выполнены.
Хорошо написанный use case:
- помогает команде видеть целостный сценарий от триггера до результата;
- служит опорой для требований, тест-кейсов, UX-решений и интеграций;
- снижает риск «забыли про исключение», потому что альтернативные ветки и ошибки зафиксированы сразу.
Когда уместны use cases
- Сценарий длиннее одного экрана и включает несколько систем/ролей.
- Нужны согласованные пред и постусловия (логины, состояния корзины, статусы заявки).
- Важны альтернативные и исключительные потоки (ошибки, отмены, таймауты).
- Требуется единый источник правды для аналитиков, дизайнеров, тестировщиков и разработчиков.
User story отлично живет в бэклоге. Use case — «скелет» сценария, который помогает не потерять смысл при детализации и тестировании. Эти артефакты не конкурируют, а дополняют друг друга.
Структура хорошего Use Case
- Название и цель — что делает актер и к какому результату стремится.
- Актеры — кто взаимодействует с системой: основной и второстепенные (платежный шлюз, CRM, курьерская служба).
- Предусловия — что должно быть истинно перед стартом (пользователь авторизован, в корзине есть товары).
- Триггер — что запускает сценарий (клик «Оформить заказ», приход вебхука).
- Основной поток (Main flow) — «счастливый путь» пошагово.
- Альтернативные потоки — допустимые развилки (другая доставка, другой метод оплаты).
- Исключения/ошибки — что делаем при сбое (таймаут, отказ банка, недоступный склад).
- Постусловия/результат — что должно быть на выходе (заказ создан, клиент получил подтверждение).
- Бизнес-правила — частотные лимиты, округления, пороги, доступности.
- Нефункциональные требования (NFR) — время отклика, надежность, аудит, доступность.
- События и данные — какие события шлем в аналитику, какие поля обязательны.
Советы по форме:
- Пишите короткими шагами, один наблюдаемый результат на шаг.
- Нумерация шагов допустима, но текст внутри — простым языком, без «воды».
- Альтернативы связывайте со шагом, на котором они ответвляются («2a», «3b»).
Мини-шаблон (можно брать в работу)
Название: Оформление заказа зарегистрированным пользователем
Цель: Покупатель успешно оплачивает корзину и получает подтверждение
Актеры: Покупатель (основной), Платежный шлюз, Сервис доставки, Склад, Почта/Push
Предусловия: Пользователь авторизован; в корзине ≥1 товара; есть валидный адрес
Триггер: Нажатие на «Оформить заказ»
Основной поток (Happy path):
- Система валидирует корзину (наличие, цены, ограничения).
- Покупатель выбирает способ доставки и оплаты.
- Система рассчитывает итог (товары, доставка, скидки, налоги).
- Покупатель подтверждает заказ → система создает заказ в статусе «ожидает оплаты».
- Переадресация/встраивание платежной формы; оплата подтверждается.
- Система фиксирует транзакцию, меняет статус заказа на «оплачен», резервирует на складе.
- Отправляются подтверждение на email/push и событие аналитики checkout_success.
- Покупатель видит экран «Заказ оформлен».
Альтернативные потоки:
- 2a. Самовывоз: пользователь выбирает самовывоз → пункт выдачи → пересчет итогов.
- 3a. Купон: пользователь вводит купон → купон валиден → скидка применяется.
- 5a. 3-D Secure: требуется подтверждение банка → пользователь подтверждает → успех.
Исключения:
- 1e. Нет в наличии: при валидации корзины обнаружено отсутствие → показываем недоступный товар, предлагаем удалить/заменить.
- 5e. Отказ в оплате: платеж отклонен → заказ остается «ожидает оплаты», пользователь видит понятное сообщение и может выбрать другой способ.
- 6e. Таймаут внешнего сервиса: повтор запроса с экспоненциальной паузой; при исчерпании попыток — фиксируем инцидент, показываем «не получилось, попробуйте позже».
Постусловия: Заказ создан; статус корректен; остатки/резервы обновлены; отправлены подтверждения; аналитика записана.
Бизнес-правила: удержание резерва 30 мин; один активный купон на заказ; бесплатная доставка от N.
NFR: P95 ответа на шаги оплаты ≤ 2 c; доступность платежного сценария ≥ 99,9%/мес; все действия логируются.
Частые ошибки и как их избегать
- Подмена цели интерфейсом. «Сделать страницу оплаты» — это не цель; цель — «покупатель оплатил заказ». Держите формулировку про результат.
- Нет альтернатив и ошибок. Сразу фиксируйте хотя бы по одному альтернативному и исключительному потоку на ключевой шаг.
- Слишком много деталей реализации. Use case — про поведение и правила, а не про технологии и таблицы БД.
- Неопределенные предусловия. Если входные состояния не описаны, сценарий будет «прыгать».
- Отсутствие метрик. Добавляйте события и измеримые NFR — иначе сложно принять результат.
Короткий чек-лист качества Use Case
- Ясная цель и понятные актеры.
- Описаны предусловия и постусловия.
- Есть happy path, альтернативы и исключения.
- Зафиксированы бизнес-правила и NFR.
- Определены события/данные для аналитики и аудита.
- Из сценария легко получить stories и тесты.
Use case — это «скелет» пользовательского сценария, который удерживает общую картину, когда вокруг много ролей, интеграций и условий. Он не заменяет user stories, а помогает им быть согласованными и проверяемыми. Опишите цель, актеров, шаги, альтернативы и ошибки, добавьте правила и NFR — и у вас появится артефакт, по которому команда одинаково понимает, что именно нужно построить и как поймем, что получилось.
Полезные ссылки
- Курс «Бизнес-аналитик в IT» на Stepik — структурированный старт, шаблоны и практика с проверкой артефактов автором курса + спец предложение для присоединившихся по ссылке ниже, скидка 25%.
Реклама. Семенов А.Д. ИНН 645503942344
- Telegram-канал «Аналитика в IT» — полезные статьи, шаблоны, чек-листы и разборы из реальных задач. Канал будет полезен аналитикам, продактам и тем, кто только начинает свой путь в IT. [ссылка на канал]