Use Case: что это такое, структура и как написать сценарий использования

Сценарий фиксирует последовательность шагов: что делает пользователь и как система реагирует в каждом случае — включая ошибки.

Use Case используют системные аналитики, разработчики и тестировщики, особенно при работе над новыми функциями продукта.

Что такое Use Case простыми словами

Use Case (сценарий использования) — это инструкция-история о том, как человек пользуется системой, чтобы добиться своей цели. Ивар Якобсон — шведский учёный, предложил метод Use Case в 1990-х как инструмент описания функциональных требований. Простыми словами: это сценарий или инструкция, которая отвечает на вопрос: «Что должно произойти, когда пользователь делает то или иное действие?».

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

В Use Case прописывают не только «идеальный» путь, но и варианты, когда что-то идёт не так — например, карта не прошла или товара нет в наличии. Так команда заранее понимает, какие ситуации нужно предусмотреть в программе.

Зачем нужны сценарии использования: роли и задачи

Use Case — это универсальный язык, который связывает бизнес и IT. Сценарии использования решают конкретные задачи для каждой роли в проекте, обеспечивая единое понимание того, что система должна делать.

Для каких задач нужен Use Case:

• Сбор и согласование требований. Вместо абстрактных технических заданий, Use Case дает конкретные шаги. Заказчик видит, как именно будет работать система, и может сказать «да» или «нет» до начала разработки.
• Определение границ системы. Аналитик четко видит, что делает система, а что остается за её пределами (выполняется пользователем или другой системой).
• Оценка трудоемкости. По количеству шагов, альтернативных потоков и исключений разработчики понимают объем работы.
• Создание основы для тестирования. Каждый сценарий и альтернативный поток превращается в тест-кейс для QA-инженеров.

Роли и их задачи при работе с Use Case

Кто	Зачем им Use Case	Какие задачи они решают с его помощью
Бизнес-аналитик (БА)	Мост между бизнесом и IT	Собирает и структурирует требования от заказчика Переводит бизнес-процессы на язык системных требований Согласовывает с заказчиком, что именно и как будет работать
Системный аналитик	Проектирование архитектуры и логики	Декомпозирует сложную систему на отдельные сценарии Определяет, какие данные и запросы нужны для каждого шага Прописывает интеграции со смежными системами (например, с платёжным шлюзом)
UX/UI-дизайнер	Проектирование пользовательского интерфейса	Понимает, какие экраны и кнопки нужны пользователю Знает порядок действий пользователя, чтобы спроектировать удобный интерфейс Видит альтернативные пути и может предупредить пользователя о возможных ошибках
Разработчик (Dev)	Кодирование и реализация	Получает четкую спецификацию: что писать в коде Знает ожидаемые ответы системы и ошибки Может оценить сложность и сроки разработки каждого сценария
Тестировщик (QA)	Создание чек-листов и тест-кейсов	Превращает каждый сценарий в тестовый набор Проверяет не только «счастливый путь», но и все альтернативы и исключения Сравнивает реальное поведение системы с описанным сценарием
Заказчик / Владелец продукта	Контроль соответствия	Проверяет, соответствует ли разработанная система его ожиданиям Понимает функциональность без изучения технической документации Может принять решение о приоритетах, глядя на описанные сценарии

Структура Use Case: обязательные элементы шаблона

Классическое описание Use Case (варианта использования) в аналитике обычно оформляется в виде структурированного текстового шаблона. Это позволяет единообразно документировать описание функциональных требований, чтобы и заказчик, и разработчик понимали сценарий одинаково.

Обязательные элементы Use Case:

1. Название (Name) — краткое глагольное название, отражающее цель пользователя (например, «Оформить заказ», «Войти в систему»).
2. Описание (Brief Description) — 2–3 предложения, объясняющие суть сценария и конечный результат.
3. Актор (Primary Actor) — кто инициирует взаимодействие: пользователь, внешняя система или таймер.
4. Предусловия (Preconditions) — условия, которые должны быть истинны до старта сценария. Пример: «Пользователь авторизован».
5. Постусловия (Postconditions) — что гарантированно произойдёт после завершения. Пример: «Заказ сохранён со статусом Новый».
6. Основной поток (Basic Flow) — пошаговый нумерованный список успешного сценария (действия пользователя + ответы системы).
7. Альтернативные потоки (Alternative Flows) — допустимые вариации основного потока (например, другой способ оплаты).
8. Исключительные потоки (Exception Flows) — сценарии с ошибками, при которых цель не достигается (неверный пароль, недостаток средств).

Основной и альтернативные потоки событий

В описании Use Case потоки событий — это сердце документа. Они описывают, как именно пользователь и система взаимодействуют шаг за шагом. Разделение на основной и альтернативные сценарии помогает структурировать логику, не смешивая идеальный сценарий с исключениями.

Основной поток событий

Что это: основной, или «happy path», поток описывает успешный сценарий, при котором все шаги выполняются без ошибок, сбоев и отклонений. Пользователь достигает своей цели, а система работает штатно.

Особенности:

• Составляется в виде нумерованного списка.
• Каждый шаг — это либо действие пользователя, либо ответ системы.
• Важно: шаги должны быть атомарными (неделимыми) и идти в хронологическом порядке.

Альтернативный поток событий

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

Когда возникают:

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

Как обозначаются: обычно нумеруются буквами или цифрами с указанием шага основного потока, с которого они начинают ветвиться. Например: «Альтернативный поток А-1 (на шаге 3 основного потока)».

Разница между альтернативными и исключительными потоками

Характеристика	Альтернативный поток	Исключительный поток
Цель пользователя	Достигается	Не достигается (сценарий прерывается)
Причина	Пользователь выбрал другой допустимый путь	Ошибка, сбой, нарушение условий
Результат	Use Case завершается успехом	Use Case завершается неудачей или требует ручного вмешательства
Пример	«Оплата сертификатом вместо карты»	«Банк отклонил транзакцию, оплата не прошла»

Диаграмма Use Case: элементы UML и как её строить

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

Основные элементы диаграммы

Элемент	Обозначение	Что означает
Актор	Фигурка человека или прямоугольник	Внешняя сущность: пользователь, система, устройство
Use Case	Эллипс с названием	Конкретная задача, выполняемая системой (глагол + существительное)
Граница системы	Прямоугольник	Отделяет внутренние Use Case от внешних акторов
Ассоциация	Сплошная линия	Актор участвует в Use Case

Как строить диаграмму Use Case:

1. Определите систему. Чётко обозначьте, где проходят границы вашей системы (системный контекст).
2. Найдите акторов. Кто будет взаимодействовать с системой? Кто является пользователем? Какие внешние системы подключаются?
3. Найдите варианты использования. Какие цели преследует каждый актор, взаимодействуя с системой? Каждую цель оформите как отдельный Use Case. Названия должны начинаться с глагола: «Зарегистрироваться», «Оплатить заказ», «Поставить оценку».
4. Нарисуйте диаграмму. Расположите акторов снаружи, Use Case внутри, проведите ассоциации между ними.
5. Добавьте структуру (Include и Extend). Отношение extend отличается от отношения include: include означает обязательное включение одного сценария в другой, extend — необязательное расширение при выполнении условия.

Как написать Use Case: пошаговая инструкция

Написание Use Case — это процесс перевода потребностей пользователя в структурированный документ. Вы можете воспользоваться сервисом Draw.io (Diagrams.net) — бесплатный инструмент для построения Use Case Diagram. Ниже алгоритм, который поможет вам ничего не упустить.

Шаг 1. Определите систему и её границы

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

Вопросы для ответа:

• Как называется система?
• Где проходит граница между системой и внешним миром?
• Какие внешние системы взаимодействуют с ней?

Шаг 2. Найдите акторов

Определите все внешние сущности, которые будут взаимодействовать с системой. Актор — это не обязательно человек (им может быть другая система, устройство или даже время/таймер).

Вопросы для ответа:

• Кто использует систему?
• Кто получает информацию от системы?
• Кто поставляет информацию в систему?
• Какие внешние системы подключаются?

Пример: для интернет-магазина акторы: «Покупатель», «Менеджер», «Платёжная система», «Служба доставки».

Шаг 3. Выявите цели акторов (Use Case)

Для каждого актора определите, какие цели он хочет достичь с помощью системы. Каждая цель становится отдельным Use Case.

Правило: название Use Case должно отвечать на вопрос «Что хочет сделать актор?» и начинаться с глагола.

Вопросы для ответа:

• Что актор хочет получить в итоге?
• Какие задачи он решает с помощью системы?

Пример (для актора «Покупатель»):

• «Оформить заказ».
• «Отменить заказ».
• «Отследить статус доставки».

Шаг 4. Опишите основной поток событий

Напишите пошаговый сценарий успешного выполнения Use Case. Это «счастливый путь», где всё идёт идеально.

Правила:

• Используйте нумерованный список.
• Каждый шаг — это либо действие пользователя, либо ответ системы.
• Шаги должны быть атомарными и идти в хронологическом порядке.

Пример (Оформление заказа):

1. Покупатель добавляет товары в корзину.
2. Покупатель переходит к оформлению заказа.
3. Система отображает итоговую сумму и форму для ввода данных.
4. Покупатель вводит адрес доставки и выбирает способ оплаты.
5. Покупатель нажимает «Подтвердить заказ».
6. Система сохраняет заказ и отправляет подтверждение на почту.

Шаг 5. Опишите альтернативные потоки

Добавьте сценарии, которые отклоняются от идеального пути, но не являются ошибками. Это допустимые вариации, при которых цель всё ещё достигается.

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

Пример (альтернатива к шагу 4). Альтернативный поток А-1: Оплата подарочным сертификатом:

• Вместо оплаты картой пользователь выбирает «Подарочный сертификат».
• Пользователь вводит код сертификата.
• Система проверяет код и списывает сумму.
• Переход к шагу 6 основного потока.

Шаг 6. Опишите исключительные потоки (ошибки)

Опишите сценарии, при которых выполнение Use Case прерывается из-за ошибок или невозможности выполнить условие. В этих случаях цель не достигается.

Пример: исключительный поток Е-1: Недостаточно средств на карте. Вместо шага 5 основного потока:

• Система получает отказ от платёжного шлюза.
• Система показывает сообщение: «Недостаточно средств на карте».
• Use Case завершается неудачей. Заказ не создан.

Шаг 7. Добавьте предусловия и постусловия

Предусловия — что должно быть истинно до начала сценария.

Постусловия — что гарантированно будет после завершения (успешного или неудачного).

Пример:

• Предусловие: Пользователь авторизован в системе; выбранные товары есть в наличии.
• Постусловие (успех): Заказ сохранён со статусом «Новый».
• Постусловие (неудача): Заказ не создан; изменения в системе отсутствуют.

Шаг 8. Проверьте и согласуйте

Покажите готовый Use Case заказчику, разработчикам и тестировщикам. Убедитесь, что все понимают сценарий одинаково.

Чек-лист проверки:

• Название отражает цель пользователя?
• Все шаги понятны и атомарны?
• Учтены все альтернативы и исключения?
• Предусловия и постусловия корректны?
• Use Case не описывает техническую реализацию (интерфейс, БД, алгоритмы)?

Когда Use Case не нужен или навредит

Use Case — мощный инструмент для сложных и формальных проектов, но он не универсален. В некоторых ситуациях его детализация становится тормозом, а не помощью. Ниже — сценарии, где от написания Use Case лучше отказаться:

• Маленькая команда с прямым доступом к заказчику. Написание полных Use Case занимает больше времени, чем устная договорённость и быстрый прототип. Если команда сидит в одном помещении (или в одном созвоне) и может мгновенно уточнить детали, достаточно лёгких user story на стикерах или в трекере.
• Зрелый продукт с устойчивой функциональностью. Команда давно знает продукт, сценарии поведения уже у всех в голове и не добавляют нового понимания. Формальное поддержание Use Case при каждом изменении превращается в бюрократическую нагрузку без реальной ценности.
• Высокочастотные итерации (спринты длиной 1 неделя). Детальный Use Case устаревает быстрее, чем его успевают прочитать разработчики. В быстро меняющихся проектах проще использовать user story с критериями приемки (DoD) и живое общение.
• Шаблон Use Case написан слишком абстрактно — «Клиент взаимодействует с системой». Без конкретных шагов, предусловий и постусловий такой документ нельзя использовать для реализации или тестирования. Это не Use Case, а бесполезное описание, которое только создаёт иллюзию документации.
• Use Case подменяет пользовательские истории (user story). Use Case отличается от User Story: User Story фиксирует ценность функции для пользователя, Use Case — пошаговую последовательность взаимодействия с системой. Смешение форматов запутывает команду: разработчики не понимают, что от них требуется, а тестировщики не могут построить тест-кейсы.

Какой формат описания выбрать в зависимости от задачи

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

Задача	Рекомендуемый формат	Причина
Зафиксировать ценность функции для бизнеса	User Story	Короткий формат, фокус на пользе и потребности пользователя, а не на последовательности шагов
Описать пошаговую логику взаимодействия с системой	Текстовый Use Case	Фиксирует основной и альтернативные потоки, предусловия и постусловия — всё, что нужно для разработки и тестирования
Показать высокоуровневую карту функций системы	Use Case Diagram (UML)	Язык визуального моделирования, в котором определены диаграммы Use Case Даёт общий обзор акторов и их целей без лишней детализации, полезен для согласования с заказчиком
Описать внутреннюю логику шагов и ветвления	Диаграмма активности (UML Activity Diagram)	Наглядно показывает развилки, параллельные ветки и циклы — незаменима для сложной внутренней логики
Показать последовательность вызовов между компонентами	Диаграмма последовательности (Sequence Diagram)	Детализирует обмен сообщениями между объектами внутри сценария во времени, полезна для разработчиков
Описать требования при частых итерациях (спринты 1–2 недели)	User Story + критерии приёмки	Быстро обновляется, не требует поддержки полного шаблона Use Case, адаптируется под изменения
Задокументировать бизнес-процесс с несколькими системами	BPMN-диаграмма	Нотация для описания бизнес-процессов, используется рядом с Use Case для описания сложных процессов Показывает роли, оркестрацию и потоки данных между участниками

Как научиться писать Use Case

Навык описывать сценарии взаимодействия пользователя с системой входит в стандартную программу подготовки системных аналитиков и разработчиков требований в ИТ-проектах. Например, тестировщик использует Use Case как основу для тест-кейсов: сценарии основного и альтернативных потоков напрямую переносятся в тестовые сценарии.

Ресурсы, которые стоит посмотреть для лучшего понимания темы:

• Яндекс Практикум — источник по структуре и правилам написания Use Case.
• Habr — источник по руководству Use Case для аналитиков (статья askid, март 2025).
• GeekBrains — источник по ошибкам и правилам создания Use Case.

На какие онлайн-курсы стоит обратить внимание на Сравни:

Курс «Системный и бизнес-аналитик» от Нетология

Школа	Нетология
Стоимость	129 600 руб
Цена в рассрочку	4 000 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций, Онлайн занятия с преподавателем

Курс «Системный аналитик с нуля до PRO + ИИ» от Эдюсон

Школа	Эдюсон
Стоимость	80 900 руб
Цена в рассрочку	3 370 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций

Курс «Системный аналитик» от Яндекс Практикум

Школа	Яндекс Практикум
Стоимость	117 500 руб
Цена в рассрочку	15 000 руб/мес
Длительность курса
Программа трудоустройства	Есть
Формат	Запись лекций, Онлайн занятия с преподавателем

Сколько Use Case нужно на проект и как это оценить

Универсальной формулы «N Use Case на проект» не существует: количество зависит от масштаба, зрелости требований и подхода команды. Но можно дать практическую методику оценки, чтобы получить реалистичную цифру — и не уйти в бесконечное дробление сценариев.

Практический метод оценки (по шагам):

1. Выпишите роли и цели. Для каждой роли (покупатель, менеджер, админ) перечислите 3–8 ключевых целей. Итоговый список целей — это база для высокоуровневых Use Case.
2. Оцените сложность каждой цели. Присвойте вес:

• 1 — простая операция (просмотр списка, фильтрация).
• 2 — операция с несколькими шагами и 1–2 ветками ошибок.
• 3 — сложная операция с интеграциями, разными ролями, множеством исключений (оплата, возврат, сложные согласования).

1. Посчитайте «эквиваленты детальных сценариев»: Total_detailed_est = Σ(weight_i) по всем целям. Это и будет ваша оценка числа детальных Use Case.
2. Добавьте буфер 15–30% на уточнения, новые требования и edge‑cases, которые всплывают в ходе проработки.

Пример расчёта для интернет‑магазина:

Цель	Роль	Вес	Комментарий
Оформить заказ	Покупатель	3	Много шагов, оплата, валидации, ошибки
Отследить заказ	Покупатель	1	Просмотр статуса, без сложных действий
Вернуть товар	Покупатель	2	Заявка, фото, согласование, расчёт суммы
Добавить товар	Менеджер	2	Карточка, категории, валидация
Обработать возврат	Менеджер	2	Согласование, логистика, учёт
Сформировать отчёт	Админ	1	Выбор фильтров, выгрузка

Итог:

• Сумма весов = 11 → оценка детальных Use Case: ~11–14
• С буфером 20% → 13–17 детальных сценариев.

FAQ

Что такое Use Case простыми словами?

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

Кто создал метод Use Case?

Ивар Якобсон предложил метод Use Case в 1990-х как замену спискам отдельных функций при описании требований к ПО. Вместо перечисления возможностей системы Якобсон предложил описывать взаимодействие с точки зрения пользователя.

Из каких элементов состоит Use Case?

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

В чём разница между основным и альтернативным потоком?

Основной поток (happy path) отличается от альтернативного: happy path описывает идеальный сценарий без ошибок, альтернативный — все возможные отклонения.

Что такое диаграмма Use Case и как её читать?

Use Case Diagram — это графическое представление функциональности системы. Use Case Diagram строится на нотации UML: актор — человечек, вариант использования — овал, граница системы — прямоугольник, связи — стрелки с пометками include и extend. Акторы находятся снаружи прямоугольника (границы системы), варианты использования — внутри.

Как научиться создавать Use Case?

Научиться писать Use Case можно на онлайн-курсах для аналитиков, программистов и разработчиков на Сравни.

Итог

• Use Case — это инструмент для описания пошагового взаимодействия пользователя с системой, разработанный Иваром Якобсоном в 1990-х.
• Структура включает обязательные элементы: актор, предусловия, основной и альтернативные потоки, постусловия.
• Для графического отображения используется UML-диаграмма с акторами (человечки), вариантами использования (овалы) и границами системы.

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