Use Case (Вариант использования)

Use Case (Вариант использования) – это описание последовательности действий, которые система выполняет в ответ на действие актора, приводящее к наблюдаемому результату.

Use Case – это описание того, как внешний участник (актор) достигает конкретной цели, взаимодействуя с системой. Важно: UC – не “описание экрана” и не “бизнес-процесс компании целиком”. Это сценарий в пределах границы системы, где видно: кто инициирует действие, какие шаги выполняются, что система обязана сделать, какие проверки и ошибки возможны, и чем все заканчивается.

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

Для чего нужен Use Case

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

2. превратить “хотелку” в контролируемую реализацию (шаги →  требования → тесты → API/интеграции)

3. не потерять альтернативы и исключения

Если говорить грубо: User Story отвечает “что нужно”, Use Case отвечает “как это происходит”. US удобна для бэклога и планирования, UC для точной спецификации поведения.

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

Use Case Diagram: Визуализация вариантов использования

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

В UML для этого есть Use Case Diagram. На ней изображаются:

• Акторы – человечки.
• Варианты использования – овалы с названиями действий.
• Границы системы – прямоугольник, внутри которого варианты использования, снаружи – актеры.
• Связи между элементами – линии, показывающие, кто с какими вариантами взаимодействует.

Связи между элементами:

• Связь включения (include) – обозначается пунктирной стрелкой с подписью include, которая показывает, что вариант использования включает в себя другие варианты. Стрелка направлена от одного варианта использования на те, которые включаются в него. Например, “Оформить заказ” всегда включает “Проверить наличие товара”.
• Связь расширения (extend) – обозначается пунктирной стрелкой с подписью extend, которая показывает, что один вариант использования опционально может расширять другой. В связи включения один вариант использования обязательно включается в другой, в связи расширения это необязательно. Например, “Оформить заказ” может расширяться “Применить промокод”, если пользователь ввел промокод.
• Связь обобщения (generalization) – обозначается стрелкой с пустым наконечником и направляется от частного к общему. Стрелка может объединить как акторов, так и варианты использования по какому либо признаку. Важно понимать, что дочерний вариант использования содержит все атрибуты и шаги из родительского варианта использования. Например, “Администратор” - частный случай “Пользователя”.
• Связь ассоциации – обозначается обычной линией без стрелки, которая показывает, с каким вариантом использования связан конкретный актор. Важно помнить, что связь ассоциации не используется для соединения между двух и более акторов, а также двух и более вариантов использования.

Диаграммы Use Case хороши для быстрого ознакомления с функциональностью системы. Но детали все равно хранятся в текстовом описании.

Пример Use Case Diagram: 

Use Case Scenario: Текстовое и табличное описание

Use Case сценарии – представляют собой текстовое описание последовательности действий, которые пользователи выполняют для достижения конкретной цели в системе. Каждый Use case сценарий описывает взаимодействие пользователя и системы (системы с системой) от начала до конца.

Классический Use Case включает несколько обязательных элементов.

Название (Name)

Краткое название, обычно глагол + существительное. Отражает цель актора.

• “Оформить заказ”
• “Зарегистрироваться в системе”
• “Создать отчет по продажам”
• “Вернуть товар”

Актор (Actor)

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

• “Покупатель”
• “Менеджер”
• “Администратор”
• “Платежная система”
• “Платежный шлюз”

Обычно выделяют: - Основное действующие лицо – кто инициирует UC и получает основную пользу. - Участники – кто помогает (внешние сервисы, подсистемы и тд.).

Цель (Goal)

Что актер хочет достичь. По сути, это расшифровка названия.

• “Получить возможность делать покупки в магазине”
• “Получить документ для отправки руководству”

Предусловие и триггер (Precondition)

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

• “Пользователь не авторизован”
• “Пользователь авторизован”
• “Товар есть в наличии”
• “Корзина не пуста”

Предусловия – что должно произойти до старта. Триггер – событие старта.

Постусловие (Postcondition)

Что изменится в системе после успешного выполнения сценария.

• “Заказ создан и сохранен в базе”
• “Пользователь авторизован в системе”
• “Средства списаны с карты покупателя”

Основной успешный сценарий (Basic Flow / Happy Path)

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

Пример (для сценария “Оформить заказ”):

1. Покупатель переходит в корзину.
2. Система отображает список товаров и итоговую сумму.
3. Покупатель нажимает кнопку “Оформить заказ”.
4. Система запрашивает адрес доставки и контактные данные.
5. Покупатель вводит данные и нажимает “Подтвердить заказ”.
6. Система проверяет наличие товаров на складе.
7. Система создает заказ и присваивает ему номер.
8. Система отправляет подтверждение на email покупателя.
9. Система перенаправляет покупателя на страницу успешного оформления.

Хорошим тоном считается писать шаги так, чтобы их можно было превращать в тест-кейсы (для помощи QA) и требования, например:
“Система валидирует…”, “Система сохраняет…”, “Система возвращает…”.

Альтернативные сценарии (Alternative Flows)

Что может пойти не так? Какие есть варианты развития событий, отличающиеся от идеального пути?

Примеры альтернатив:

• 3а. Если корзина пуста, показывается сообщение “Добавьте товары в корзину”.
• 4а. Если пользователь уже авторизован, шаг с запросом данных пропускается (данные берутся из профиля).
• 6а. Если товара нет в наличии, система уведомляет пользователя и предлагает удалить товар.
• 8а. Если email не указан, подтверждение не отправляется, но заказ создается.

Исключения (Exception Flows)

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

• “При проверке платежа выяснилось, что на карте недостаточно средств”
• “При создании заказа произошел сбой базы данных”

Пример Use Case Scenario: Снятие денег в банкомате:

Use Case vs User Story

• User Story – это краткое описание того, что хочет достичь пользователь, используя систему. Они обычно начинаются со слов “как пользователь, я хочу…”, и далее следует описание того, что пользователь хочет сделать. User Story сосредоточены на том, что пользователь хочет, а не на том, как это реализовать.

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

Как писать хорошие Use Case:

Начинайте с основного сценария

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

Не смешивайте с интерфейсом

Use Case описывает взаимодействие на уровне действий и целей, а не конкретные кнопки и поля. “Система запрашивает адрес” – этого достаточно. Не нужно писать “в поле слева от кнопки пользователь вводит…”.

Используйте активный залог

Правильно: “Пользователь нажимает кнопку”. Неправильно: “Кнопка нажимается пользователем”.

Будьте последовательны в уровне детализации

Не пишите для одного шага “пользователь вводит имя”, а для другого “пользователь вводит имя, фамилию, отчество, дату рождения, паспортные данные, ИНН и СНИЛС”. Детализация должна быть равномерной.

Не забывайте про предусловия и постусловия

Они помогают понять контекст и границы сценария.

Используйте нумерацию

Шаги в основном сценарии нумеруются 1, 2, 3. Альтернативы привязываются к шагам: 3а, 5b и т.д. Это упрощает навигацию.