Вам надоело, что бизнес приходит с абстрактными проблемами или того хуже с готовым решением? В итоге, ограничивая работу отдела разработки в принятии решений? Как сделать сложные требования понятными и структурированными, чтобы они работали быстрее и эффективнее для решения задач бизнеса?
Бизнес-требования — это основа для разработки IT-решений. Но часто их описывают слишком сложно или неоднозначно. В результате разработчики тратят время на уточнения деталей, а заказчики остаются недовольны.
Формат Use Case помогает избежать этих проблем. Он описывает сценарии взаимодействия пользователей и систем в четкой, последовательной форме. Это не просто техническая документация, а «инструкция» для всех участников проекта: аналитиков, разработчиков, тестировщиков и бизнес-пользователей.
Автор: Борис Абрамов, Lead system analyst.
В этом гайде разберём:
✔ Как правильно формулировать каждый элемент Use Case.
✔ Какие ошибки чаще всего допускают и как их избежать.
✔ Примеры хороших и плохих формулировок.
Кому пригодится:
Бизнес-аналитикам — для понятной фиксации требований.
Разработчикам — для точного понимания, что нужно сделать.
Тестировщикам — для проверки соответствия ожиданиям.
Продуктовым менеджерам — для согласования логики с заказчиком.
Готовы сделать требования максимально прозрачными? Поехали!
Title (Заголовок)
Заголовок кратко описывает действие или процесс, составляющий его суть. Он должен состоять из глагола и существительного, но, как правило, без указания актора или конкретной точки взаимодействия. Исключение составляют случаи, когда изменение функциональности напрямую влияет на основной сценарий взаимодействия актора – тогда актора можно упомянуть. Допустимо включить в заголовок условия, при которых возникает описываемый сценарий.
Хорошие примеры:
Получить доступ к премиум-контенту (после оплаты подписки).
(Здесь указано условие возникновения опыта – после оплаты подписки).
Плохие примеры:
Пользователь оформляет заказ. (Содержит актора, хотя изменение функционала не влияет на основной сценарий. Лучше: «Оформить заказ»)
Оформление заказа на сайте. (Содержит тачпоинт – «На сайте». Лучше: «Оформить заказ»)
Оформить заказ с помощью мобильного приложения. (Содержит тачпойнт. Лучше: «Оформить заказ»)
Посмотреть каталог и оформить заказ. (Слишком длинный и описывает несколько действий. Лучше разбить на два отдельных юзкейса: «Просмотреть каталог» и «Оформить заказ»)
Goal (Цель)
Цель описывает, чего хочет достичь актор, выполнив основной сценарий. Формулировка цели должна быть краткой (одно предложение) и содержать как самого актора, так и измеримый результат, ценный для него.
Хороший пример:
Пользователь записывается на прием к врачу
Плохой пример:
Выполнение требования постановления правительства
Context (Контекст)
Может использоваться для описания условий и обстоятельств, при которых происходит взаимодействие актора с системой, если они неочевидны или требуют уточнения. Описывается произвольной формой и не более чем в 3-х предложениях.
Пример:
Процесс инициируется потенциальным трейдером, заинтересованным в участии в биржевых торгах. Успешная регистрация предоставляет трейдеру доступ к торговой платформе и возможность совершать операции на бирже.
Scope
Должен определять границы UC, описывая задействованные системы и процессы.
Хороший пример:
Охватывает процесс регистрации нового трейдера на СПбМТСБ, начиная с заполнения регистрационной формы на сайте и заканчивая получением SPIMEXID и установкой торгового терминала. Включает взаимодействие с информационным сайтом СПбМТСБ, системой ЭДО, внутренними системами биржи и удостоверяющим центром.
Плохой пример:
Пользователя не устраивает качество покрытия текущего оператора в его зоне эксплуатации мобильного приложения (часто пропадает соединение телефона с интернетом).
Actors (Участники)
Акторы классифицируются на 2 категории:
Human actors (человеческие акторы)
System actors (системные акторы)
Если в сценарии использования участвует только один человек, то он обозначается своим именем для ясности. Если людей несколько, для краткости используется общее обозначение «Пользователь» (User). Аналогично, если взаимодействует только одна внешняя система, она обозначается как «Система» (System). При участии нескольких систем каждая из них должна быть названа по имени.
Пример:
User (Human actors):
Библиотекарь
Читатель
Systems (System actors):
Единая система биометрии Гондураса
ИС Абоба
Preconditions (Предусловие)
Описывает текущее состояние системы (включено/выключено, верно/неверно), а не то, что пользователь хочет сделать или делает в данный момент. Описывает необходимые условия в системах, участвующих в данном сценарии, для его успешного завершения. Все условия должны быть описаны на одном уровне детализации.
Правильные примеры:
Информационный сайт ЗАО «Бещёки» доступен и функционирует корректно.
Система ЭДО работает в штатном режиме.
Внутренние системы ЗАО «Бещёки», ответственные за обработку регистраций, доступны.
Удостоверяющий центр, выдающий ЭЦП, функционирует и доступен для взаимодействия.
Неправильные примеры:
Пользователь зашел домой и ест лапшу
Triggers
Это событие или условие, после которого сразу начинается выполнение сценария.
Пример:
Пользователь нажимает на большую красную кнопку
Плохой пример:
Пользователь хочет посмотреть скорость
Main Scenario
Количество шагов — от 3 до 12.
Шаги должны быть описаны в порядке их выполнения.
Результат main scenario должен соответствовать Goal.
Важно:
Не указывать типы виджетов.
Не указывать свойства интерфейса (чекбоксы, вкладки, радио-кнопки, виджеты, селекты).
Не указывать текст уведомлений и примеры диалогов.
Не указывать тексты ошибок.
Пример описания шагов:
Некорректно:
Система проверяет токен на сервере
Система обновляет параметры в памяти
Корректно:
Пользователь сохраняет выбранные настройки
Система информирует пользователя, что настройки сохранены
При описании взаимодействия пользователя с системой или наоборот должен быть указан тачпоинт (точка взаимодействия) в следующей форме:
via in/out_** тачпоинт name
Не допускается использование условий, пример:
If User rejects…
Упоминание актора необходимо либо в виде действующего лица, либо лица для которого совершаются действия
Пример:
1. Пользователь получает информацию о сервисе via Канал коммуникации A.
2. Пользователь предоставляет данные для регистрации via Канал коммуникации A.
3. Система отправляет пользователю необходимые документы via Канал коммуникации B.
4. Пользователь взаимодействует с документами via Канал коммуникации B.
5. Система проверяет предоставленную информацию.
6. Система регистрирует пользователя и запрашивает оплату via Канал коммуникации B.
7. Пользователь производит оплату via Канал коммуникации C.
8. Пользователь получает необходимые инструменты доступа via Канал коммуникации D.
9. Система предоставляет пользователю доступ к сервису.
10. Пользователь получает доступ к функционалу сервиса via Канал коммуникации E.
Post Conditions (Постусловие)
Описывает финальный результат основного сценария в контексте Goal кейса.
Пример:
Пользователь записался к врачу
Alter Scenario
Должен представлять собой ответвление от основного сценария, начинающееся в определенной точке и приводящее к тому же конечному результату.
Должен быть обоснован конкретной причиной (триггером) и соответствовать ожидаемому конечному состоянию системы (посткондишену).
Не должны появляться новые точки взаимодействия с системой, которых нет в основном сценарии.
Должен описывать отличную от основного сценария последовательность действий, с указанием точек, где он отходит от основного сценария и где к нему возвращается.
Пример:
Extension Point: на шаге 4 основного сценария отсутствует подключение к интернету:
Система информирует пользователя, что настройки временно сохранены локально in/out_** тачпоинт name.
С шага 5 продолжается выполнение основного сценария.
Exceptions(опционально)
Должен быть обоснован указанным триггером и соответствовать исходному состоянию системы (прекондишену).
Уровень детализации его описания должен быть таким же, как и у основного и альтернативных сценариев.
Представляет собой ответвление от основного сценария, начинающееся при выполнении определённого условия, и не приводящее к достижению целевого результата (посткондишена) основного сценария.
Пример:
Если на шаге 2 основного сценария отсутствуют подключение к интернету:
Система оповещает трейдера об отсутствии подключения.
Трейдер получает уведомление о необходимости скорректировать или сформировать новый отчет.
Requirements(опционально)
Уточняющая информация важная для выполнения юзкейса (NFR-требования определяющие свойства).
Должен быть актор или системы, которые «shall».
Пример:
The system shall create a new role with pre-installed default settings which can be changed.
Теперь у вас есть готовый шаблон для оформления бизнес-требований в формате Use Case. Но как сделать так, чтобы это работало не только в теории, но и в реальных проектах?
Вот несколько советов:
Проверяйте сценарии на «живых» пользователях — если непонятно им, значит, нужно дорабатывать.
Держите Use Case лаконичными — если сценарий разрастается, возможно, его стоит разбить на части.
Используйте их как основу для тест-кейсов — это сэкономит время на тестировании.
Обновляйте документ при изменениях — устаревшие требования приводят к ошибкам.
Главное преимущество Use Case – они превращают абстрактные пожелания в четкие инструкции. Попробуйте применить этот подход в своем проекте, и вы сразу заметите:
✔ Меньше недопонимания между командами.
✔ Быстрее разработка – потому что требования прозрачны.
✔ Проще вносить правки – структура помогает быстро находить нужные места.
Хотите глубже разобраться в аналитике? Пишите в комментариях, какие темы вам интересны – сделаем следующий гайд еще полезнее!
