инструмент, который помогает разработчикам, аналитикам и продакт-менеджерам формализовать взаимодействие пользователя с системой
Регистрируйтесь и прокачивайте навыки создания use case, которые помогут вам избежать ошибок в будущих проектах.

Use case

Зарегистрироваться
Однако на практике его нередко путают с user story или вовсе описывают настолько абстрактно, что теряется практическая ценность. Ошибки в составлении use case приводят к недопониманию между разработчиками и заказчиками, проблемам при реализации и росту технического долга.

В этой статье разберём ключевые ошибки при создании use case, которые мешают разработке, и разберёмся, как их избежать. Будем опираться на реальные примеры и практические рекомендации.
Пользовательский путь оказывается не продуманным, что увеличивает вероятность провала продукта.
Функциональные требования теряют чёткость, что замедляет согласование и реализацию.
Неполные или противоречивые сценарии приводят к неопределённости в задачах разработчиков.
Что пойдёт не так, если игнорировать проработку use case?
Чтобы этого избежать, разберём топ-5 ошибок,
начиная с базового — путаницы между use case и user story.
1. use case ≠ user story: ключевое различие
User story — это краткое описание потребности пользователя, выраженное в формате «Как [роль], я хочу [цель], чтобы [выгода]». Они используются для постановки задач в agile-командах и помогают задать направление работы.
Use case — это более формализованный сценарий, описывающий, как пользователь взаимодействует с системой, какие шаги выполняет, какие условия должны быть соблюдены, какие альтернативные варианты могут возникнуть.
Главные различия:
Пример ошибки:
Неправильно: «Как пользователь, я хочу оплатить заказ, чтобы получить товар».

Это user story, но если попытаться реализовать её без детальной проработки, могут возникнуть вопросы:

  • Какие методы оплаты доступны?
  • Что делать, если транзакция отклонена?
  • Какие данные вводит пользователь?
Правильный use case:
Пользователь выбирает метод оплаты.
Система проверяет данные и запрашивает подтверждение.
Если платёж проходит успешно, система создаёт заказ.
В случае ошибки пользователю предлагается повторная попытка или другой способ оплаты.
Вывод: user story и use case дополняют друг друга, но не заменяют.
Если ограничиться только user story, критически важные детали могут быть упущены.
2. ошибка №1: нет четкой границы между пользователем и системой
При создании use case важно чётко понимать, какие действия выполняет сам пользователь, а какие — система. Ошибки на этом этапе приводят к тому, что сценарий становится нерабочим или требует сложной доработки.

Типичные проблемы:
  • В сценарии смешаны пользовательские действия и поведение системы.
  • Система рассматривается как активный субъект, хотя она только реагирует на действия пользователя.
  • Не обозначены сторонние акторы (например, API платёжной системы или администратор).
Пример ошибки:
Неправильно:
  1. Система отправляет пользователю уведомление о скидке.
  2. Пользователь решает сделать заказ.
  3. Система проверяет его баланс и списывает деньги.

Здесь первая и третья строки — действия системы, а вторая — действия пользователя. Но в таком формате возникает вопрос: что является триггером? Должен ли пользователь каким-то образом подтвердить заказ?
Исправленный вариант:
  1. Пользователь открывает приложение и видит уведомление о скидке.
  2. Пользователь добавляет товар в корзину и нажимает «Оформить заказ».
  3. Система проверяет баланс пользователя.
  4. Если средств достаточно, система подтверждает покупку и списывает деньги.
Как избежать ошибки:
  1. Ясно разделяйте роли:
  • Пользователь — активный субъект, который инициирует действие.
  • Система — реагирует и выполняет предписанные функции.

2.Чётко обозначайте внешние системы и акторов: API, администраторов, бэкенд-сервисы.
3.Используйте глаголы, которые указывают на субъект:
  • «Пользователь выбирает…»
  • «Система обрабатывает…»
  • «API возвращает…»
Вывод: чтобы use case был полезным, он должен чётко разграничивать, кто выполняет какое действие.
3. ошибка №2: неопределенные цели и ожидаемые результаты
Use case должен отвечать на два ключевых вопроса:
  • Какую задачу решает пользователь?
  • Каков ожидаемый результат взаимодействия с системой?

Если эти аспекты не проработаны, сценарий становится неполным, и команда разработки начинает гадать, как должна работать система. Это приводит к задержкам, переработкам и конфликтам между бизнесом и разработчиками.

Типичные ошибки:
  • Цель use case описана слишком расплывчато.
  • Не определено, что система должна делать в конце сценария.
  • Нет явного указания на успех или неуспех операции.
Пример ошибки:
Неправильно:
Use case: оформление заказа
  1. Пользователь выбирает товар.
  2. Пользователь вводит данные.
  3. Система оформляет заказ.

Вопросы, которые возникают у разработчиков:
  • Какие данные вводит пользователь?
  • Какой результат ожидается — заказ создаётся сразу или требуется подтверждение?
  • Что происходит, если платёж не проходит?
Исправленный вариант:
Use case: оформление заказа
  1. Пользователь выбирает товар и нажимает «Оформить заказ».
  2. Пользователь вводит адрес доставки и выбирает метод оплаты.
  3. Система проверяет корректность данных.
  4. Система инициирует платёж через внешнего провайдера.
  5. Если платёж успешен, система создаёт заказ и отправляет подтверждение.
  6. Если платёж неуспешен, система предлагает повторить попытку или выбрать другой метод.

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

  • Определите конкретную цель. Вместо «оформить заказ» — «создать заказ с подтверждённой оплатой».
  • Фиксируйте ожидаемый результат. Чем заканчивается сценарий? Как система должна себя вести?
  • Прописывайте альтернативные пути. Что делать, если процесс пошёл не так?
4. ошибка №3: линейный сценарий без альтернативных путей
Одна из самых распространённых ошибок — описание use case как единственного, безупречно работающего пути. В реальном мире пользователи ошибаются, платежи отклоняются, соединение с сервером обрывается. Если эти моменты не учесть, продукт окажется неудобным, а баги будут выявляться уже на продакшене.
Как выглядят хорошие и плохие сценарии?
Пример ошибки:
Неправильно:
Use case: восстановление пароля
  1. Пользователь вводит e-mail.
  2. Система отправляет письмо с инструкцией.

Что не так?
  • Не описано, что делать, если e-mail не зарегистрирован.
  • Не учтена задержка с отправкой письма.
  • Не рассматривается ситуация, если пользователь не получил письмо (оно ушло в спам или был введён неверный адрес).
Исправленный вариант:

Use case: восстановление пароля
1.Пользователь вводит e-mail.
2.Система проверяет, зарегистрирован ли e-mail.
  • Если e-mail не найден, система выводит сообщение: «Аккаунт с таким e-mail не зарегистрирован».
  • Если e-mail найден, система отправляет письмо с инструкцией.
3.Система сообщает пользователю, что письмо отправлено.
4.Если пользователь не получил письмо в течение 5 минут, он может запросить повторную отправку или обратиться в поддержку.
Как правильно прорабатывать альтернативные пути?

1.Определите, где может произойти сбой.
  • Ввод неверных данных.
  • Ошибки системы (например, недоступность сервера).
  • Ошибки взаимодействия с внешними сервисами (платёжные шлюзы, API).
  • Пропишите, что делать в каждом случае.

2.Должен ли пользователь попробовать снова?
  • Нужна ли дополнительная информация (например, ссылка на справку)?
  • Можно ли решить проблему без участия поддержки?

3.Добавьте логичные альтернативные сценарии.
  • Если пользователь не получил письмо, он должен иметь возможность его запросить повторно.
  • При неудачной оплате предложите другой способ, а не просто завершайте сценарий.
Вывод: игнорирование альтернативных путей ведёт к недоработкам и ухудшает UX. Use case должен покрывать все ключевые варианты поведения пользователя.
5. ошибка №4: отсутствие системы триггеров и предусловий
Часто в use case забывают про две ключевые вещи: когда запускается сценарий (триггер) и какие условия должны быть соблюдены перед его выполнением (предусловия). В результате система начинает работать непредсказуемо или требует сложных исправлений уже на стадии тестирования.

Что такое триггер и предусловия?
  • Триггер – это событие, запускающее выполнение сценария. Оно может быть вызвано пользователем или системой (например, истечение срока подписки).
  • Предусловия – это условия, которые должны быть выполнены перед запуском сценария (например, пользователь должен быть авторизован, товар – в наличии).
Пример ошибки:
Неправильно:

Use case: изменение пароля
  1. Пользователь вводит новый пароль.
  2. Система обновляет пароль.

Что здесь не так?
  • Не указано, когда начинается сценарий (может ли пользователь поменять пароль без авторизации?).
  • Не описаны предусловия (нужен ли старый пароль, какие требования к новому?).
  • Не учтены ошибки (например, ввод слишком простого пароля).
Исправленный вариант:

Use case: изменение пароля
Триггер: Пользователь выбирает опцию «Сменить пароль» в настройках аккаунта.

Предусловия:
  • Пользователь авторизован.
  • Старый пароль введён верно.
Основной поток:
  1. Пользователь вводит старый пароль и новый пароль.
  2. Система проверяет, соответствует ли новый пароль требованиям безопасности.
  3. Если проверка успешна, система обновляет пароль и уведомляет пользователя.
  4. Если новый пароль не соответствует требованиям, система выводит сообщение с рекомендациями.
6. ошибка №5: слишком технический или слишком поверхностный язык
Последняя распространённая ошибка – это несоответствие уровня детализации.
  • Если use case слишком технический, его сложно понять бизнес-аналитикам и заказчикам.
  • Если use case слишком поверхностный, разработчики не смогут использовать его для реализации.
Как найти баланс?

  1. Используйте чёткую структуру
  • Триггер
  • Предусловия
  • Основной поток
  • Альтернативные пути
  • Исключения
2.Пишите на языке, понятном
всем участникам команды
  • Избегайте излишне сложных технических терминов.
  • Не используйте расплывчатые фразы вроде «система как-то проверяет».
3.Добавляйте контекст и примеры
  • Вместо «система валидирует данные» – «система проверяет, соответствует ли e-mail формату example@domain.com».
Пример ошибки:
Неправильно:

Use case: восстановление пароля
  • Пользователь инициирует процесс.
  • Система проверяет данные.
  • Если всё в порядке, пользователь получает инструкцию.
Исправленный вариант:

Use case: восстановление пароля
1.Пользователь вводит e-mail и нажимает «Восстановить пароль».
2.Система проверяет, зарегистрирован ли e-mail.
  • Если e-mail не найден, система выводит сообщение: «Такой e-mail не зарегистрирован».
  • Если e-mail найден, система отправляет письмо с инструкцией.
3.Пользователь получает письмо и переходит по ссылке для смены пароля.
4.Система предлагает ввести новый пароль, проверяет его сложность и обновляет в базе.
Заключение
Создание корректных use case – это не просто формальность, а важный шаг, который напрямую влияет на успешность проекта. Ошибки в сценариях приводят к недоработкам в разработке, проблемам с UX и увеличению технического долга.
Как избежать этих ошибок?

  1. Разделяйте user story и use case. Истории пользователей нужны для постановки задач, а сценарии – для проработки логики.
  2. Формулируйте чёткие цели и ожидаемые результаты. Это помогает избежать разночтений.
  3. Прорабатывайте альтернативные пути. В реальном мире пользователи совершают ошибки, а системы могут давать сбои.
  4. Определяйте триггеры и предусловия. Это основа логически выверенного сценария.
  5. Находите баланс между техничностью и доступностью языка. Use case должен быть понятен и бизнесу, и разработчикам.
Если вы хотите глубже разобраться в теме и научиться писать корректные пользовательские сценарии, приглашаем на вебинар OTUS:
Пользовательские сценарии (Use Cases): как превратить бизнес-требования заказчика
в задачи на разработку

На вебинаре разберём:
✔ Разницу между use case, user story и требованиями.
✔ Как правильно формулировать сценарии для сложных проектов.
✔ Типовые ошибки и их влияние на процесс разработки.

Регистрируйтесь и прокачивайте навыки создания use case, которые помогут вам избежать ошибок в будущих проектах.
Зарегистрироваться
Поздравляем, вы записаны на мероприятие
Курс Системный аналитик. Advanced
Пользовательские сценарии (Use Cases): как превратить бизнес-требования заказчика в задачи на разработку
© 2025 OTUS
Информация
Об Otus
Контакты
По всем вопросам
help@otus.ru