Use case: что это, как его составить и какие инструменты пригодятся
2026-02-21 01:39 Diff

#статьи

  • 27 ноя 2025
  • 0

Учимся на практических примерах.

Иллюстрация: Оля Ежак для Skillbox Media

Программист, консультант, специалист по документированию. Легко и доступно рассказывает о сложных вещах в программировании и дизайне.

Когда компания решает создать новое ПО, ей необходимо заранее понять, какие именно задачи бизнеса и пользователей оно будет решать и каким именно образом. Чтобы разобраться в этом, готовят use case (сценарий использования).

В этой статье мы разберёмся, что это за документ, какие задачи он решает и как правильно его составить.

Содержание

Use case (сценарий использования) — это описание того, как пользователь взаимодействует с ПО, чтобы достичь конкретной цели. Он показывает, какие шаги выполняет человек, как на них реагирует программа и к какому результату это приводит.

Например, компания решает создать приложение для заказа такси. Use case будет описывать процесс его работы для пользователей — с главного экрана и до завершения поездки с указанием обратной связи. Подробное описание позволяет разработчикам и дизайнерам понять, как должна работать система и какие функции требуется реализовать.

В начале разработки use case задаёт общее представление о ПО: что важно для пользователя, какие ограничения стоит учитывать, как именно должно работать приложение или веб-сайт, какие ошибки могут возникнуть и что с ними делать, и многое другое. Позже эти сценарии используются для тестирования — по ним проверяют, выполняет ли система действия так, как нужно пользователям.

Посмотрим на несколько ситуаций, в которых используется use case:

  • Создание интернет-магазина. Сценарии будут описывать, как покупатель выбирает товар и оплачивает заказ, что делать, если товар закончился или оплата не прошла. То есть укажет на все возможные варианты развития событий, которые следует предусмотреть в разработке и тестировании.
  • Создание мобильного приложения, например для изучения иностранных языков. Use case будет описывать регистрацию пользователя, вход в систему, восстановление пароля, настройки профиля: текущий уровень владения языком, цель обучения, напоминания о занятиях и тому подобное. Сценарии использования должны включать в себя работу с настройками профиля, отображение ошибок, например когда сервис недоступен, и так далее.

Чтобы написать качественный сценарий использования, полезный на этапах разработки и тестирования, надо пройти четыре последовательных этапа: собрать информацию о ПО, описать задачи в виде общей диаграммы, детализировать сценарии, запланировать их проверку и уточнение при необходимости. Разберём каждый из них подробно.

Ключевая задача на старте работы над use case — понять цели бизнеса, то есть то, что важно заказчику разработки. Эту часть обычно формулирует бизнес-аналитик или продакт-менеджер. Например, в ходе сбора информации может выясниться, что сейчас требуется увеличить количество заказов, сократить время обслуживания или повысить удовлетворённость клиентов.

Следом переходят к требованиям пользователей — что нужно им самим от нашего ПО: возможность выбора тарифа, быстрой оплаты покупки или что-то другое. Здесь в процесс включается системный аналитик или продакт-менеджер: они проводят интервью с пользователями, изучают, как те будут работать с системой, и превращают эти наблюдения в чёткие формулировки.

После анализа собранных данных системный аналитик описывает задачу целиком, указывая возможные сценарии, но без их детализации. Для этого он использует язык UML — набор правил по созданию визуальных схем. Основное преимущество его выбора — графические материалы будут понятны всем, кто знаком с языком. То есть у UML есть определённые правила, по которым применяются все элементы: стрелочки, кружки, квадраты и другие.

Диаграмма сценария использования показывает всех участников процесса и то, как они взаимодействуют с ПО: акторы изображаются в виде человечков, сами действия — овальными фигурами, а связи между ними оформляются стрелками и короткими пояснениями.

Диаграмма сценариев использования приложения такси — как со стороны клиента, так и со стороны водителя. Мы видим все возможные действия, для которых необходимо продумать конкретные шаги и возможные ошибки
Иллюстрация: Майя Мальгина для Skillbox Media

После создания диаграммы переходят к подробному описанию каждого сценария в текстовом формате. Use case обычно состоит из нескольких обязательных частей:

  • Заголовок. Краткое описание действия.
  • Акторы. Те, кто взаимодействует с системой. Это может быть человек (например, покупатель в интернет-магазине), другая программа (платёжный сервис) или устройство. Нужно перечислить всех акторов, чтобы понимать, кто и какие действия выполняет, и не пропустить их проработку в дальнейшем.
  • Основной поток событий. Это главный сценарий — то, как система должна работать в обычной ситуации. Например, пользователь вводит логин и пароль → система проверяет данные → открывается личный кабинет.
  • Альтернативные потоки. Это варианты, которые могут отличаться от основного сценария. Например: пользователь вводит неверный пароль → система показывает сообщение об ошибке и предлагает попробовать ещё раз.
  • Предусловия. То, что должно быть выполнено перед началом сценария. Например: «Пользователь зарегистрирован в ПО, имеет логин и пароль».
  • Постусловия. Результат, который должен быть достигнут после выполнения сценария. Например: «Пользователь успешно вошёл в личный кабинет ПО».
  • Исключения и ошибки. Описывают, что происходит в нестандартных ситуациях. Например: сервер недоступен или платёж не прошёл.
  • Триггеры. Это события, которые запускают сценарий. Например: «Пользователь нажал кнопку „Войти“».

После написания сценариев нужно их проверить и убедиться, что учтены все требования к ПО или его части и ожидания от них. Для этого системный аналитик обсуждает use case с заказчиком.

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

Один и тот же use case можно описать как с точки зрения бизнеса, так и с позиции системы в целом.

Бизнес-сценарий показывает задачу глазами заказчика и пользователей. В нём описывается цель и результат без технических деталей, чтобы было понятно, что нужно бизнесу. Например: «Покупатель оформляет заказ в интернет-магазине: выбирает товар, оплачивает и получает подтверждение». Здесь не указывается, как технически работает платёжная система или какой код выполняется: важен только итог.

Системный сценарий предназначен для разработчиков и тестировщиков. Он показывает, что происходит внутри ПО: какие проверки реализованы и проводятся, куда отправляются запросы, как приложение или веб-сайт реагируют на ошибки. Вот как может выглядеть формулировка: «Система проверяет наличие товара на складе, рассчитывает доставку, передаёт данные в платёжный шлюз, обрабатывает ошибки и верстает письмо с подтверждением».

Коротко: бизнес-сценарий показывает то, какие задачи будет решать продукт, а системный — как будет реализовано их решение.

Кроме этого, сценарии можно разделить по глубине проработки на два варианта:

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

Как выбрать формат? В начале проекта пишут бизнес-сценарии: они помогают договориться с заказчиком о требованиях и ожиданиях и согласовать их с ним. Когда начинается разработка, переходят к системным и детализированным сценариям: по ним программисты и тестировщики понимают, что и как нужно делать.

Стандартных шаблонов для сценария использования нет — разные компании оформляют их по-своему, опираясь на специфику разрабатываемого ПО. Главное, чтобы в итоге получился структурированный документ, который позволяет команде разработки одинаково представлять конечный результат или по отдельным функциям приложения или веб-сайта, или в целом.

Рассмотрим основные элементы, которые обычно включают в описание use case.

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

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

Нужно чётко определить, кто участвует в сценарии использования. Есть первичные акторы (они начинают процесс, и конечный результат важен для них) и вторичные (те, кто подключается позже). Актором может быть не только человек, но и, например, платёжная система.

После того как акторы определены, нужно понять, чего они хотят. Цель должна быть конкретной и полезной для акторов. Часто её формулируют как «глагол + объект»: например, «оформить заказ», «авторизоваться в программе» или «запросить поддержку».

Цель помогает сосредоточиться на основной задаче сценария и не уходить в технические детали.

Это стандартный путь, когда всё идёт без ошибок. Шаг за шагом аналитик описывает действия акторов и реакцию ПО.

Несколько советов по проработке основного сценария:

  • Используйте нумерованный список.
  • Каждый шаг — простое действие: «Пользователь вводит адрес», «Система проверяет наличие машины поблизости» и тому подобное.
  • Ошибки пока не учитываются. Мы игнорируем то, что они могут появиться.
  • Сценарий должен логично завершаться — цель пользователя достигнута.

Здесь учитываются отклонения от основного пути: ошибки, отмены и другие возможные варианты событий. Для каждого шага аналитик продумывает, что может пойти не так и как система должна реагировать на это.

Важно всегда указывать условия перехода к альтернативному сценарию и то, как вернуться к основному или завершить работу пользователя с ошибкой.

Когда основной и альтернативные сценарии готовы, нужно убедиться, что описание получилось цельным и логичным: нет ли противоречий и пробелов, которые могут вызвать ошибки при реализации.

Сначала оценивают, насколько согласованы акторы и границы системы: нет ли действий, которые выполняют пользователи, не имеющие к этому доступа? Затем смотрят, все ли возможные ситуации учтены: предусмотрены ли ошибки или непредвиденные сбои?

После этого аналитик проверяет переходы между ветками сценария: если пользователь может вернуться из альтернативного пути в основной, это должно быть явно описано. Каждый сценарий обязан завершаться определённым состоянием системы — успешным или с ошибкой.

После этого use case показывают команде: разработчикам, тестировщикам и заказчику, чтобы заметить нестыковки, которые можно пропустить. Наконец, важно убедиться, что сценарий читается легко, иначе его лучше разделить на несколько связанных use case или подзадач — так описание останется понятным и управляемым.

Посмотрим на упрощённые примеры сценариев использования из разных сфер: корпоративной системы, интернет-магазина и мобильного приложения.

Название: Авторизация пользователя.

Акторы:

  • пользователь;
  • система аутентификации.

Предусловия:

  • пользователь зарегистрирован или ему разрешено войти как гостю;
  • нужные данные (логин/пароль или токен) доступны.

Основной сценарий:

  • Пользователь открывает экран входа на веб-сайте.
  • Вводит логин и пароль.
  • Система проверяет данные.
  • Если данные корректные — система переводит пользователя на главную страницу.
  • Сценарий успешно завершён.

Альтернативные сценарии:

  • Если пользователь вводит неверный пароль, то программа показывает сообщение об ошибке и предлагает повторить ввод.
  • Если пользователь забыл пароль, то может нажать на кнопку «Забыли пароль» и выполнить восстановление через электронную почту, которая уже зарегистрирована в системе.

Постусловия:

Пользователь либо авторизован и может использовать функции корпоративной системы, либо получил понятное сообщение об ошибке с вариантами её устранения.

Название: Оформление заказа.

Акторы:

  • клиент (покупатель);
  • система магазина;
  • служба доставки;
  • система оплаты.

Предусловия:

  • клиент вошёл в аккаунт или сделал заказ как гость;
  • товары, которые требуется заказать, добавлены в корзину;
  • способы оплаты и доставки доступны в регионе клиента.

Основной сценарий:

  • Клиент проверяет корзину и подтверждает состав товаров.
  • Выбирает адрес доставки.
  • Выбирает способ оплаты.
  • Система рассчитывает стоимость доставки и итоговую сумму.
  • Клиент подтверждает заказ.
  • Система отправляет запрос в платёжную систему.
  • После подтверждения платёжной системы заказ обозначается как оплаченный, происходит уведомление склада и службы доставки. Подтверждение оплаты обязательно направляется клиенту по email или в приложении.

Альтернативные сценарии:

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

Название: Отправка push-уведомления пользователю.

Акторы:

  • приложение (серверная часть);
  • пользователь (устройство).

Предусловия:

  • пользователь установил приложение;
  • разрешил получение push-уведомлений в настройках операционной системы;
  • имеется событие, которое должно вызвать вызов уведомления, например новое сообщение, акция или другое.

Основной сценарий:

  • Событие генерируется на сервере (например, новая акция или сообщение).
  • Сервер формирует содержимое уведомления: заголовок, текст, ссылку и так далее.
  • Сервер отправляет уведомление через push-сервер (FCM, APNS и другие).
  • Устройство пользователя получает уведомление.
  • На устройстве отображается уведомление.
  • Пользователь нажимает на уведомление.
  • Открывается приложение с соответствующим экраном, например с информацией про акцию.

Альтернативные сценарии:

  • Если пользователь отключил уведомления, то устройство не получает уведомление. Возможно, ПО будет логировать то, что уведомление отправлено, но не доставлено.
  • Если устройство находится вне зоны доступа или не подключено к Сети в момент отправки, то уведомление доставляется, когда устройство снова будет доступно.
  • Если уведомление имеет неправильный формат данных для отображения на устройстве, то оно не отображается. Сервер должен логировать это событие для последующего решения бага.
Упрощённая UML-диаграмма для use case с отправкой push-уведомления в мобильном приложении
Иллюстрация: Майя Мальгина для Skillbox Media

Составлять сценарий использования удобнее всего при помощи специализированных сервисов. Они позволяют быстро строить диаграммы, используя принципы UML, хранить их в проекте и совместно работать над ними с командой.

Draw.io — бесплатный онлайн-редактор диаграмм, у которого есть десктопная версия. Работает прямо в браузере и не требует регистрации, хотя с аккаунтом можно подключить синхронизацию через Google Drive или другие облачные сервисы.

В библиотеке Draw.io есть готовые элементы для UML: символы для акторов, овалы для конкретных действий, рамка системы и стрелки со связями. Можно нарисовать схему вручную или взять готовый шаблон, чтобы упростить работу. Ограничение одно: поддерживать актуальность сложной документации придётся вручную, без автоматического внесения изменений в созданные диаграммы.

Lucidchart — это облачный сервис для команд, где можно строить UML-диаграммы и сразу делиться ими с коллегами. В Lucidchart есть готовые шаблоны и возможность создавать диаграммы из текста. Например, аналитик пишет описание шагов, а система автоматически собирает из него последовательную диаграмму.

Инструмент интегрируется с Google Drive, Confluence и Jira. Благодаря этому его часто используют в больших командах, где важна интеграция с другими сервисами. Большая часть функций доступна только на платных тарифах.

PlantUML — это инструмент для тех, кто предпочитает текст графическим элементам. Здесь диаграммы описываются кодом — короткими строками вроде actor User, usecase «Login», User --> (Login). А сервис перестраивает это в UML-диаграмму. Подробная документация доступна на сайте ПО.

Схемы в PlantUML можно хранить в репозитории вместе с кодом, разделять на отдельные версии и обновлять автоматически. Минус в том, что графического интерфейса нет: придётся учить синтаксис, а визуально схемы в итоге выглядят проще, чем в специализированных редакторах.

Каждый инструмент решает свои задачи. Draw.io подойдёт, если нужно быстро и бесплатно построить диаграмму use case. Lucidchart — выбор для команд, когда важна интеграция и совместная работа. PlantUML — хороший вариант, если диаграммы должны храниться рядом с кодом и аналитик предпочитает описывать действия текстом, а не работать с визуальными инструментами.

Часто два этих понятия путают, но это разные инструменты, которые решают разные задачи.

User story (пользовательская история) — это короткое описание того, что нужно пользователю от продукта и зачем. Она помогает сформулировать задачу с точки зрения человека — чтобы команда понимала, какую пользу несёт отдельная функция или ПО в целом.

Структура у user story простая: «Как [роль] я хочу [цель], чтобы [результат]».Например: «Как покупатель я хочу сохранять товары в избранное, чтобы вернуться к ним позже». Для user story, в отличие от use case, не прорабатывают пошаговые сценарии и не строят для них диаграммы. Основной акцент делают на коротком описании желаемого для пользователя результате.

Пользовательские истории появляются на этапе планирования продукта. Продакт-менеджер или аналитик собирает их, оценивает приоритеты и формирует бэклог — список функций, которые предстоит реализовать. На следующем этапе каждая история превращается в более детальные сценарии, макеты и задачи для разработки.

На практике use case и user story хорошо сочетаются. User story задаёт направление: что нужно пользователю и зачем. А use case раскрывает детали: как именно система должна реагировать на действия пользователя и какие исключения нужно учесть.


Курс с трудоустройством: «Профессия Разработчик + ИИ» Узнать о курсе