Use Case: как описывать эффективные сценарии использования. Part 2

Всем привет! Меня зовут Анастасия Солдатова, я техлид системной аналитики в одном из крупнейших банков и один из авторов тг-канала Sprint аналитика.

В предыдущей статье мы разобрали, что такое сценарии использования (Use Cases), зачем они нужны и в чем их основные преимущества и ограничения. Самое время перейти от теории к практике.

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

• Определить, как пользователи взаимодействуют с системой.

• Выявить скрытые требования и потенциальные проблемы.

• Упростить коммуникацию между заказчиками, разработчиками и тестировщиками.

В этой статье пошагово разберем два примера, чтобы показать, как одна методология применяется в совершенно разных контекстах: проработка бизнес-процессов в современных IT-сервисах и покупка новых брюк на рынке 90-х. Пройдем тропою аналитика от формирования Use Case диаграммы с помощью промта до детализации сценария использования.

Давайте начнем!

(Если вы еще не успели прочитать первую часть — рекомендую ознакомиться с Use Case: как описывать эффективные сценарии использования. Part 1, чтобы лучше понимать основы).

---

В предыдущей статье мы разобрали теорию сценариев использования и рассмотрели простой кейс с переводом денег между счетами. Теперь применим эти знания к более сложному и комплексному примеру — «Бронирование тура в отпуск».

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

Для наглядного представления взаимодействия между пользователями (акторами) и системой, начинаем с формирования диаграммы прецедентов.

Диаграмма прецедентов

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

Use Case диаграмма помогает:

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

• Показывает, что может делать система, а что остается за её пределами.

• Пример:

  • Входит в систему: бронирование тура, оплата.

  • Не входит: доставка визы (это внешний сервис).

2. Выявить всех участников (акторов)

• Кто взаимодействует с системой:

  • Основные пользователи (например, семья, менеджер отеля).

  • Внешние системы (платежный шлюз, CRM).

• Пример:

3. Упростить коммуникацию между командами

• Для заказчиков: Понятная схема без технических деталей.

• Для разработчиков: Четкие требования к функционалу.

• Для тестировщиков: Список сценариев для проверки.

4. Выделить ключевые сценарии использования

• Группирует основные цели пользователей:

  • «Забронировать тур»,

  • «Отменить бронь»,

  • «Изменить даты».

• Показывает зависимости (например, оплата — часть бронирования).

5. Обнаружить пробелы в требованиях

• Если актор не связан ни с одним прецедентом — значит, его потребности не учтены.

• Пример упущения:

  • Нет прецедента «Восстановить доступ к брони» → нужна доработка.

6. Снизить риски недопонимания

• Визуализация исключает разночтения в требованиях.

• Пример конфликта:

  • Заказчик думает, что «Выбор отеля» — отдельный прецедент, а разработчик включает его в «Бронирование».

  • Диаграмма сразу расставляет приоритеты.

7. Подготовить базу для детальных сценариев

Диаграмма — это «каркас», на основе которого прописывают:

• Основные и альтернативные потоки.

• Предусловия/постусловия.

Из чего состоит диаграмма прецедентов?

Диаграмма прецедентов состоит из следующих основных блоков:

• Граничные рамки системы — блок, который устанавливает область действия системы для вариантов использования.

• Актор (actor) — пользователь, который взаимодействует с системой. В зависимости от процесса, это может человек, организация или даже система.

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

• Отношения (связи) — существуют четыре типа связей, описывающих отношения между элементами:

  • Ассоциация (Association): Это основная связь между актором и Use Case. Она показывает, что актор взаимодействует с Use Case. Ассоциация обозначается линией, соединяющей актора и прецедент.

  • Расширение (Extend): Отмечает, что один из вариантов использования присоединяет к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования. Обозначается пунктирной линией со стрелкой, указывающей на Use Case, который расширяется.

  • Включение (Include): Показывает, что один Use Case включает функциональность другого. Обозначается пунктирной линией со стрелкой, указывающей на Use Case, который включается.

  • Обобщение (Generalization): Обобщение служит для обозначения, что прецедент/актер А может быть обобщен до прецедента/актера B. Обозначается сплошной линией с незакрашенным треугольником, указывающим на более общий Use Case.

В некоторых источниках можно встретить также тип связи Специализация (Specialization), но на практике такой вид связи встречается крайне редко.

Формирование Use Case диаграммы

Итак, в границах нашего кейса по «Бронированию тура в отпуск», давайте выделим шаг «Бронирование отеля» и посмотрим, как будет выглядеть диаграмма прецедентов.

Для формирования диаграммы, призовем все силы искусственного интеллекта и составим промт:

Ты — опытный бизнес/системный аналитик и эксперт по UML/PlantUML. Твоя задача:  Сгенерировать PlantUML‑код диаграммы прецедентов для всех перечисленных Use Case. 

Входные данные:
- CASE_TITLE — бронирование отеля через сервис "Отдыхай с комфортом"
- SYSTEM_NAME — приложение "Отдыхай с комфортом"
- ACTORS — Клиент, приложение Карты, Госуслуги, Банк X, Почта, Менеджер отеля
- USE_CASES — открыть каталог отелей, выбрать отель, отобразить локацию, ввести данные бронирования, подтвердить учетную запись, оплатить отель 
- INCLUDES — выбрать отель - отобразить локацию, оплатить отель- подтвердить учетную запись

Сгенерируй код PlantUML:
plantuml
@startuml
left to right direction
actor «...»
rectangle «{SYSTEM_NAME}» {
usecase «...» as UC1
...
}
' include/extend отношения
UCx --> UCy : <<include>>
...
@enduml

Получаем вот такой результат в виде кода PlantUML:

@startuml

' направление слева‑направо, чтобы было удобнее читать

left to right direction

' Определяем акторов
actor Клиент as Client
actor "Приложение Карты" as CardsApp
actor "Госуслуги" as Gosuslugi
actor "Банк X" as BankX
actor Почта as Mail
actor "Менеджер отеля" as Manager

' Основная система
rectangle "Приложение «Отдыхай с комфортом»" {
usecase "Открыть каталог отелей"      as UC1
usecase "Выбрать отель"               as UC2
usecase "Отобразить локацию"          as UC3
usecase "Ввести данные бронирования"  as UC4
usecase "Подтвердить учётную запись"  as UC5
usecase "Оплатить отель"              as UC6
}

' Связи акторов с прецедентами
Client         --> UC1
Client         --> UC2
Client         --> UC4
Client         --> UC6
CardsApp       --> UC3
Gosuslugi      --> UC5
BankX          --> UC6
Mail          --> UC6
Manager   --> UC2

' Include‑связи (обязательные подпрецеденты)
UC2  --> UC3 : <<include>>
UC6  --> UC5 : <<include>>

@enduml

Добавляем код в любой редактор PlantUML и любуемся результатом.

На диаграмме мы видим:

• граничные рамки системы — это наше приложение «Отдыхай с комфортом»;

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

• прецеденты — простые, например, «Ввести данные бронирования» (1 актор — 1 действие), и составные, например, «Оплатить отель», который включает в себя еще один прецедент («Подтвердить учётную запись»).

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

Сценарии использования

После формирования диаграммы прецедентов, следующим этапом проработки задачи является составление сценариев использования. Как правило, каждый из прецедентов ложится в основу определенного сценария. Мы, для примера, выберем шаг «Оплатить отель» и сформируем для него Use Case.

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

1. Формируйте Use Case с точки зрения пользователя, который будет использовать систему. Описание от лица конечного потребителя поможет глубже проанализировать, где есть проблемы на текущий момент и где они потенциально могут возникнуть.

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

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

4. Не забывайте про описание альтернативных сценариев, которые могут возникнуть во время выполнения Use Case.

5. Указывайте условия, которые должны быть выполнены, прежде чем пользователь сможет выполнить Use Case, и условия, которые будут выполнены после того, как пользователь выполнит Use Case.

Формирование сценария использования

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

Ты — опытный бизнес/системный аналитик. Твоя задача: Сформировать подробную таблицу для одного выбранного Use Case с полями "ID и Название", "Основной актор", "Второстепенные акторы", "Описание", "Предусловия", "Основной поток", "Альтернативные потоки", "Предусловия", "Постусловия".

Входные данные:
- ACTORS — Клиент, Госуслуги, Банк Х, Почта
- USE_CASE —  оплатить отель 
- INCLUDES — оплатить отель- подтвердить учетную запись

И получим вот такой Use Case для сценария оплаты отеля:

Детализация Use Case: «Оплатить отель»

Атрибут	Значение
ID и Название	UC-001 – Оплатить отель
Основной актор	Клиент (пользователь, осуществляющий бронирование и оплату отеля)
Второстепенные акторы	• Госуслуги (верификация учетной записи) • Банк Х (обработка платежа) • Почта (отправка подтверждения бронирования)
Описание	Клиент подтверждает личность через Госуслуги, вводит платежные данные, проводит транзакцию через Банк Х и получает подтверждение бронирования на электронную почту.
Основной поток	1. Клиент выбирает отель и переходит к оплате 2. Система запрашивает подтверждение учетной записи через Госуслуги 3. Клиент успешно проходит верификацию 4. Система запрашивает платежные данные 5. Клиент вводит реквизиты карты (Банк Х) 6. Банк Х проверяет и подтверждает платеж 7. Система отправляет подтверждение бронирования на Почту клиента 8. Use Case завершен
Альтернативные потоки	А1. Верификация не пройдена (Госуслуги) • Система предлагает альтернативные способы подтверждения личности • При повторной неудаче - отмена бронирования А2. Отказ в проведении платежа (Банк Х) • Система уведомляет о недостатке средств/проблеме с картой • Предлагает ввести другие платежные данные или выбрать иной способ оплаты А3. Подтверждение не доставлено (Почта) • Система повторяет отправку • Предлагает альтернативные способы получения подтверждения (SMS, личный кабинет)
Предусловия	1. Клиент авторизован в системе 2. Отель выбран и добавлен в корзину 3. У клиента есть активная банковская карта
Постусловия	1. Платеж успешно проведен 2. Бронирование подтверждено 3. Клиент получил подтверждение на указанный email

В зависимости от требований проекта и необходимости детализации, можно дополнять разделы сценариев использования. Например, указать исключения (Банк X отклонил платеж → система предлагает выбрать другую карту), бизнес-правила (Полный возврат - за 48 часов до заезда), технические нюансы (Интеграция с API Банка X (REST)).

Критерии «хороших» и «плохих» сценариев использования

Проверить, насколько «хорошим» получился сценарий помогут следующие критерии:

• Четкость и однозначность. Название должно отражать суть, а шаги должны быть сформулированы без двусмысленности.

Плохой пример: «Обработать заказ» — неясно, что значит «обработать».

• Полнота покрытия сценариев. В UC описан как основной поток, так и альтернативные сценарии и исключения, учитывается взаимодействие всех акторов.

Плохой пример: «Оплата прошла успешно» — не описана обработка ошибок.

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

Плохой пример: «Клиент взаимодействует с системой» — слишком абстрактная формулировка, неясно, зачем нужен бизнесу, невозможно понять, что необходимо реализовать.

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

Плохой пример: «Стена текста» без логического разделения.

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

Плохой пример: «Клиент вводит номер карты из 16 цифр» — жестко завязан на текущую реализацию. «Забронировать отель и заказать такси» — объединяет несколько несвязанных функций.

Плохой Use Case создает иллюзию работы, но на практике приводит к пробелам в разработке и неожиданным багам.

Не только IT: Use Case работает даже на российском рынке

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

Цель:

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

• Особенности рынка (торг, наличные расчеты, погодные условия)

• Взаимодействие с продавцом

• Проверку качества товара

Контекст:

Время: Конец августа, подготовка к 1 сентября.

Место: Рынок («Лужники», «Горбушка» или аналогичный).

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

• Мама хочет купить «что‑то приличное, но недорого».

• Школьник хочет «нормальные штаны, а не колхозные».

Диаграмма прецедентов включает основного актора — Школьника, второстепенных акторов — Маму, обеспечивающую процесс покупки, и Продавца с характерными фразами.

Детализация Use Case:

Атрибут	Значение
ID и Название	UC-001 – Купить школьные брюки на рынке
Основной актор	Школьник
Второстепенные акторы	Мама (финансист и контролер), Продавец
Предусловия	1. До 1 сентября осталось 3 дня. 2. В семье выделены деньги на "что-то приличное". 3. Школьник согласился идти на рынок (после уговоров).
Основной поток	1. Поиск палатки: Мама ищет "что-то классическое, но не дороже 500 руб." 2. Выбор модели: Школьник тыкает в "клеш" или "дудочки", мама настаивает на "обычных". 3. Торг: Мама: "Сколько за эти? 700? Да это же синтетика!" 4. Примерка: Натягивание брюк поверх джинсов (если нет картонки для примерки). 5. Проверка качества: Мама щупает ткань, проверяет швы. 6. Оплата: Наличными. 7. Итог: Брюки куплены, школьник недоволен, мама считает, что "сойдет".
Альтернативные потоки	A1. Если нет размера: - Продавец предлагает "такие же, но с наплывом" (на вырост). A2. Если подросток бунтует: - "Мааам, да это же мешок!" → мама покупает "как есть".
Ошибочные сценарии	E1. Обнаружен брак после покупки: - Одна штанина короче → возврата нет, чинить у бабушки. E2. Кончились деньги: - Покупка переносится, донашиваем брюки за старшим братом.
Постусловия	1. Брюки повешены в шкаф до 1 сентября. 2. Подросток клянется, что "никогда их не наденет". 3. Мама говорит: "На линейку потерпишь!"

Заключение

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

Берите за основу рекомендации из статьи, приходите на наши воркшопы (следите за анонсами в канале) и формируйте действительно эффективные Use Cases.

P.S. Если после прочтения статьи вы вспомнили, как сами примеряли брюки на рынке под мамины причитания — значит, сценарий описан верно! 😊