Use Case пример: как писать сценарии использования по Алистеру Коберну с шаблонами

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

Формула: [Актор] инициирует [действие], Система отвечает [поведением], чтобы [достичь цели при успехе] и [сохранить целостность при провале].

Три трактовки метода

1. Use Case как контракт (Алистер Коберн)

Трактовка: Use Case — это соглашение между заинтересованными лицами о поведении системы. Он фиксирует не только успешный путь, но и обязательства системы в случае сбоев (Failed End Condition). Главное — не интерфейс, а цель актора и гарантии, которые дает система при любом исходе.

Формула: [Предусловия] → [Триггер] → [Основной сценарий] → [Success End Condition] + [Failed End Condition].

2. Use Case как иерархия целей

Трактовка: Коберн вводит три уровня целей: Summary (обобщенная цель высокого уровня, объединяющая несколько сценариев), Primary Task (цель уровня моря — то, что актор делает за один присест) и Subfunction (подводный камень — шаг, который не имеет самостоятельной ценности). Правильный Use Case всегда находится на уровне Primary Task.

Формула: [Summary] → включает → [Primary Task] → включает → [Subfunction].

3. Use Case как инструмент выявления исключений

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

Формула: [Шаг основного сценария] + [Условие] → [Альтернативное действие или подчиненный Use Case].

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

Базовая формула: [Триггер запускает сценарий] → [Актор и Система обмениваются действиями] → [Достигается Success или Failed End Condition].

Уровни вариантов использования по Коберну

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

Правило Коберна: правильный Use Case пишется на уровне Primary Task — это то, что актор делает за один присест (2–20 минут). Summary объединяет несколько Primary Task в обобщенный сценарий высокого уровня. Subfunction не имеет самостоятельной ценности для актора и выносится в подчиненные сценарии, которые подключаются через расширения (в UML эти отношения называются include и extend).

Когда и как использовать Use Cases

Сценарии применения:

• Фиксация функциональных требований к сложной системе (Enterprise, B2B, госсектор).
• Выявление и обработка исключений до начала разработки.
• Основа для приемочного тестирования (каждый сценарий — готовый тест-кейс).
• Коммуникация между аналитиками, разработчиками и заказчиком на формальном, но читаемом языке.

Источники данных для Use Cases (в порядке приоритета):

1. Интервью с предметными экспертами (SME).
2. Бизнес-процессы и регламенты организации.
3. Анализ существующей системы (as-is).
4. Пользовательские истории и бэклог (для пересборки в системный вид).
5. Требования регуляторов и compliance.

Этапы написания Use Case:

• Определение границ системы (Scope) и акторов.
• Выявление целей акторов уровня Primary Task (уровень моря).
• Фиксация предусловий, триггера, условий успеха и провала.
• Описание основного успешного сценария на 3–9 шагов.
• Выявление расширений (Extensions) к каждому шагу.
• Выявление субвариантов (Sub-variations) — вариантов, не ломающих сценарий, но меняющих его течение.
• Фиксация связанных сценариев (Superordinate / Subordinate).

Поиск и декомпозиция Use Cases

Ищите цели, а не действия. Не «Нажать кнопку», а «Оформить заказ». Не «Ввести пароль», а «Аутентифицироваться». Цель Primary Task — то, что актор хочет достичь за один присест (2–20 минут). Subfunction — шаг, не имеющий самостоятельной ценности для актора вне контекста основного сценария.

10 примеров Use Cases

1. Оформление заказа Goal: Покупатель получает подтвержденный заказ. Success: заказ сохранен, присвоен номер. Failed: заказ не создан, покупатель уведомлен. Trigger: покупатель инициирует оформление.

2. Возврат товара Goal: Клиент регистрирует возврат. Success: возврат зарегистрирован, инструкция по отправке выдана. Failed: возврат не зарегистрирован, причина сообщена. Trigger: клиент выбирает опцию возврата в заказе.

3. Онбординг нового сотрудника Goal: HR-менеджер создает учетные записи и выдает доступы. Success: сотрудник добавлен во все системы, уведомления разосланы. Failed: процесс прерван, ранее созданные записи откатываются. Trigger: HR вносит данные нового сотрудника.

4. Согласование договора Goal: Менеджер получает подписанный обеими сторонами договор. Success: документ прошел визирование, сохранен в архиве. Failed: договор отклонен на любом этапе, инициатор уведомлен с причиной. Trigger: менеджер отправляет договор на согласование.

5. Бронирование переговорной Goal: Сотрудник получает комнату на нужное время. Success: комната забронирована, конфликты исключены. Failed: слот не найден, предложены альтернативы. Trigger: сотрудник задает параметры поиска.

6. Выгрузка отчета для налоговой Goal: Бухгалтер получает файл установленного формата. Success: файл сформирован и выгружен. Failed: данные неполны, ошибка валидации подсвечена. Trigger: бухгалтер запускает формирование отчета за период.

7. Сброс пароля Goal: Пользователь восстанавливает доступ. Success: временная ссылка отправлена, старый пароль деактивирован. Failed: пользователь не найден, уведомление об ошибке отображено. Trigger: пользователь нажимает «Забыли пароль?».

8. Регистрация пациента в клинике Goal: Администратор создает карту пациента и назначает прием. Success: карта создана, слот у врача занят. Failed: дубликат пациента обнаружен, предложено объединение карт. Trigger: администратор вносит первичные данные.

9. Проведение платежа Goal: Плательщик переводит средства контрагенту. Success: платеж проведен, баланс обновлен, квитанция сформирована. Failed: платеж отклонен, причина зафиксирована, средства не списаны. Trigger: плательщик подтверждает операцию.

10. Модерирование отзыва Goal: Модератор публикует или отклоняет отзыв. Success: решение зафиксировано, автор уведомлен. Failed: отзыв отправлен на доработку, автор уведомлен с комментарием. Trigger: новый отзыв поступает в очередь модерации.

Алгоритм применения Use Cases

1. Определите границы системы (Scope).
   Что внутри системы, что снаружи. Кто акторы (люди, внешние сервисы, время). Система — черный ящик.

2. Соберите цели акторов уровня Primary Task.

   • Интервью с экспертами.
   • Анализ бизнес-процессов.
   • Регламенты и нормативные документы.

3. Зафиксируйте контракт:

   • Preconditions: что должно быть истинным до старта.
   • Trigger: событие, запускающее сценарий.
   • Success End Condition: состояние мира при успехе.
   • Failed End Condition: состояние мира при провале (минимальные гарантии).

4. Опишите Main Success Scenario.
   Идеальный путь без ветвлений. Шаги вида: «Актор делает X. Система делает Y». От 3 до 9 шагов.

5. Выявите Extensions.
   К каждому шагу — что может пойти не так. Каждое расширение: условие + альтернативное действие или ссылка на подчиненный Use Case.

6. Выявите Sub-variations.
   Варианты, которые не ломают сценарий, но меняют его течение (например: способ оплаты — карта или наличные). Не путать с расширениями.

7. Зафиксируйте Related Information:

   • Priority, Performance Target, Frequency.
   • Superordinate Use Case (родительский).
   • Subordinate Use Cases (подчиненные).
   • Channels to actors (interactive, file, database, timeout).

8. Проверьте тестом «сидим с экспертом».
   Читатель должен видеть, что произойдет в любой ситуации, не задавая дополнительных вопросов.

Примеры Use Case

Три полных примера Use Case с таблицами основного и альтернативного сценариев: логин в систему, интернет-магазин и банковский перевод. Структура соответствует шаблону Коберна: характеристики → основной успешный сценарий → расширения.

Пример 1: Логин в систему

Основной успешный сценарий

Расширения (альтернативные сценарии)

Пример 2: Оформление заказа в интернет-магазине

Основной успешный сценарий

Расширения (альтернативные сценарии)

Пример 3: Банковский перевод

Основной успешный сценарий

Расширения (альтернативные сценарии)

Шаблоны для этих примеров — в разделе «Шаблон Use Case» ниже.

Оптимизация сценариев: избавляемся от исключений

Коберн учит выявлять исключения, но не рассказывает, как их минимизировать. Практический подход:

1. Выявите исключение. Например: «Товар нельзя доставить в город клиента».
2. Определите первопричину. Почему это исключение возникает на данном шаге?
3. Перестройте сценарий, чтобы исключение не возникало. Например: запрашивайте город до выбора товара и показывайте только доступные к доставке позиции.
4. Если исключение нельзя устранить — минимизируйте путь возврата. Не сбрасывайте все введенные данные пользователя, сохраняйте контекст.

Результат: меньше ветвлений, чище основной сценарий, выше удовлетворенность актора.

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

Use Case и User Story: в чём отличие

Use Case чаще всего путают с User Story. Оба описывают поведение системы, но решают разные задачи: Use Case фиксирует контракт системы, User Story — потребность роли в бэклоге.

Правило выбора: нужно быстро проверить гипотезу — берите User Story. Нужно зафиксировать обязательства системы перед актором на годы вперед — пишите Use Case. Сравнение со всеми остальными методологиями — в разделе ниже.

Use Cases vs другие методологии требований

User Stories (Пользовательские истории)

Формула: [Как X, я хочу Y, чтобы Z].
Фокус — персона (роль).
Уровень — тактический (фичи, бэклог).
Форма — предложение на карточке.
Конкуренты — прямые аналоги.

Use Cases (Сценарии использования)

Формула: [Триггер] → [Сценарий] → [Success / Failed End Condition].
Фокус — цель и контракт.
Уровень — архитектурный (Primary Task).
Форма — структурированный документ с расширениями и субвариантами.
Конкуренты — любое решение, способное выполнить ту же работу (включая ручные процессы).

JTBD (Jobs To Be Done)

Формула: [Когда X, я хочу Y, чтобы Z].
Фокус — контекст и ситуация.
Уровень — стратегический (ниша, рынок, ценность).
Форма — описание работы и метрик успеха.
Конкуренты — любые способы решения (включая отказ от действия).

Job Stories

Формула: [Когда X, я хочу Y, чтобы Z].
Фокус — ситуация + задача.
Уровень — тактический (small job внутри основной потребности).
Форма — промежуточный формат между User Story и JTBD.
Применение — наполнение бэклога на основе полного контекста задачи.

ODI (Outcome-Driven Innovation)

Формула: [Функциональная работа] + [Метрика успеха] + [Текущая неудовлетворённость].
Фокус — измеримые результаты (outcomes).
Уровень — стратегический (data-driven приоритизация фич).
Форма — количественная надстройка над JTBD от Тони Ульвика.

BPMN (Business Process Model and Notation)

Формула: [Событие] → [Действия] → [Шлюзы] → [Конечное событие].
Фокус — последовательность работ и ролей.
Уровень — бизнес-процесс.
Форма — визуальная диаграмма.

CJM (Customer Journey Map)

Формула: [Этапы] → [Точки контакта] → [Эмоции].
Фокус — опыт пользователя во времени.
Уровень — тактический/стратегический.
Форма — карта пути пользователя.

User Scenarios (UX)

Формула: [Пользователь] → [Экран] → [Действие] → [Реакция].
Фокус — интерфейс и взаимодействие.
Уровень — UX-дизайн.
Форма — раскадровки, прототипы.

Сводная таблица

Когда Use Cases не стоит использовать

1. Задача — быстрое прототипирование. Use Cases требуют времени на проработку расширений и субвариантов. Для MVP достаточно User Stories.
2. Продукт простой и линейный. Если система состоит из CRUD-операций без сложной логики, Use Cases избыточны.
3. Нет доступа к предметным экспертам. Без понимания предметной области сценарии будут оторваны от реальности.
4. Команда не готова читать формальную документацию. Use Cases требуют культуры работы с текстовыми требованиями.
5. Продукт — игра или интерактивный опыт. Здесь важнее эмоциональный путь, а не формальный контракт о результате.

Продвинутый уровень: связка Use Cases + BPMN

1. Смоделируйте бизнес-процесс в BPMN. Это выявит контекст использования системы и стыковки с ручными операциями.
2. Каждая задача на дорожке системы (Pool/Lane «Система») — кандидат в Use Case уровня Primary Task.
3. Для каждого Use Case опишите основной поток как текстовую детализацию BPMN-шага.
4. Ветвления из диаграммы BPMN (шлюзы) становятся расширениями (Extensions) в Use Case.
5. Субварианты (Sub-variations) соответствуют различным способам выполнения одной и той же задачи (например: оплата картой или наличными).
6. Используйте трассировку: ID процесса → ID Use Case → ID требований → ID тест-кейса.

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

Для User Stories — обратный подход:
Из BPMN выделяются роли и их задачи. Каждая задача, требующая реализации в системе, формулируется как User Story. BPMN дает контекст, User Story — атомарную ценность для разработки.

Усиление метода: от Use Case к ТЗ для разработчика

Сам по себе Use Case — не полное ТЗ. Для передачи в разработку дополните его:

1. Отображаемые данные. Какая информация нужна актору на каждом шаге для принятия решения.
2. Вводимые данные. Разделите поля ввода, если их обработка порождает разные исключения (логин и пароль — отдельно, как у Google).
3. Требуемые преобразования. Алгоритмы, которые должны отработать на стороне системы (расчет стоимости доставки, поисковые подсказки).
4. Требования к отчетности. Какие метрики собирать по каждому сценарию и его расширениям.

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

Use Case требования: как описать

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

Как писать требования из Use Case:

1. Каждый шаг основного сценария сформулируйте как «Система должна ...».
2. Каждое расширение превратите в требование поведения при условии.
3. Обеспечьте трассировку: каждый тест-кейс приемочного тестирования ссылается на конкретный шаг или расширение.
4. Подчиненные сценарии (include) и расширения (extend) опишите как отдельные требования со своей нумерацией.

В отличие от use case диаграммы UML (акторы и эллипсы на картинке), текстовая спецификация дает тестировщику готовую пошаговую инструкцию, а заказчику — формальный контракт.

Шаблон Use Case: готовый шаблон по Коберну (TR.96.03a)

Ниже — оригинальный шаблон Алистера Коберна в двух форматах: простой текст и табличный вид. Выбирайте тот, что лучше ложится на ваш инструментарий.

Мини-шаблон (копируйте и заполняйте):

USE CASE # <номер> <название — цель в виде короткой глагольной фразы>
Goal in Context: <цель актора в контексте>
Scope: <система как черный ящик>
Level: Primary Task
Preconditions: <что должно быть истинным до старта>
Success End Condition: <состояние мира при успехе>
Failed End Condition: <состояние мира при провале>
Primary Actor: <роль>
Trigger: <событие, запускающее сценарий>

Основной успешный сценарий:
1. <Актор> ...
2. <Система> ...
3. ...

Расширения:
1a. <условие>: <альтернативное действие>
2a. <условие>: <альтернативное действие>

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

Текстовый формат

Use Case: <номер> <название — цель в виде короткой глагольной фразы>
--------------------------------------------------
ХАРАКТЕРИСТИКИ
Goal in Context:     <развернутое описание цели в контексте, если нужно>
Scope:               <какая система рассматривается как черный ящик>
Level:               <один из: Summary, Primary Task, Subfunction>
Preconditions:       <что должно быть истинным до начала сценария>
Success End Condition: <состояние мира при успешном завершении>
Failed End Condition:  <состояние мира при провале цели>
Primary Actor:       <роль или описание основного действующего лица>
Trigger:             <действие, запускающее сценарий (может быть временнЫм событием)>
----------------------------------------
ОСНОВНОЙ УСПЕШНЫЙ СЦЕНАРИЙ
<шаги от триггера до достижения цели и финализации>
<шаг #> <описание действия>
----------------------
РАСШИРЕНИЯ
<расширения по одному, каждое ссылается на шаг основного сценария>
<измененный шаг> <условие>: <действие или ссылка на подчиненный Use Case>
<измененный шаг> <условие>: <действие или ссылка на подчиненный Use Case>
--------------------
СУБВАРИАНТЫ
<варианты, которые вызовут разветвление внутри сценария>
<шаг или вариант #> <список субвариантов>
<шаг или вариант #> <список субвариантов>
----------------------
СВЯЗАННАЯ ИНФОРМАЦИЯ (опционально)
Priority:             <насколько критичен для системы/организации>
Performance Target:   <ожидаемое время выполнения>
Frequency:            <как часто выполняется>
Superordinate Use Case: <опционально, родительский Use Case>
Subordinate Use Cases:  <опционально, подчиненные Use Cases>
Channel to primary actor: <например: interactive, static files, database>
Secondary Actors:     <другие системы, необходимые для выполнения>
Channel to Secondary Actors: <например: interactive, static, file, database, timeout>
----------------------------
ОТКРЫТЫЕ ВОПРОСЫ (опционально)
<список вопросов по сценарию, ожидающих решения>
---------------------------
РАСПИСАНИЕ
Due Date: <дата или релиз>
...прочая информация о сроках и ресурсах...

Табличный формат

Пример заполнения: Buy Goods (покупка товаров)

Use Case: 5 Buy Goods
--------------------------------------------------
ХАРАКТЕРИСТИКИ
Goal in Context:     Покупатель направляет запрос напрямую в компанию,
                     ожидает отгрузки товара и выставления счета.
Scope:               Компания
Level:               Summary
Preconditions:       Мы знаем покупателя, его адрес и т.д.
Success End Condition: Покупатель получил товар, мы получили деньги.
Failed End Condition:  Мы не отправили товар, покупатель не потратил деньги.
Primary Actor:       Покупатель, любой агент (или компьютер), действующий от имени клиента
Trigger:             Поступает запрос на покупку.
----------------------------------------
ОСНОВНОЙ УСПЕШНЫЙ СЦЕНАРИЙ
1. Покупатель обращается с запросом на покупку.
2. Компания фиксирует имя покупателя, адрес, запрошенные товары и т.д.
3. Компания предоставляет покупателю информацию о товарах, ценах, сроках доставки и т.д.
4. Покупатель подписывает заказ.
5. Компания создает заказ и отправляет товар покупателю.
6. Компания направляет счет покупателю.
7. Покупатель оплачивает счет.
----------------------
РАСШИРЕНИЯ
3a. Компании не хватает одной из заказанных позиций:
    3a1. Пересогласовать заказ.
4a. Покупатель платит напрямую кредитной картой:
    4a1. Принять оплату картой (use case 44)
7a. Покупатель возвращает товар:
    7a. Обработать возврат (use case 105)
--------------------
СУБВАРИАНТЫ
1. Покупатель может использовать:
    телефонный звонок,
    факс,
    веб-форму заказа,
    электронный обмен данными.
7. Покупатель может оплатить:
    наличными или денежным переводом,
    чеком,
    кредитной картой.
----------------------
СВЯЗАННАЯ ИНФОРМАЦИЯ
Priority:            высший
Performance Target:  5 минут на оформление заказа, 45 дней до получения оплаты
Frequency:           200/день
Superordinate Use Case: Управление отношениями с клиентом (use case 2)
Subordinate Use Cases:
    Создать заказ (use case 15)
    Принять оплату кредитной картой (use case 44)
    Обработать возврат (use case 105)
Channel to primary actor: может быть телефон, файл или интерактивный
Secondary Actors:    компания-эмитент кредитных карт, банк, служба доставки
----------------------------
ОТКРЫТЫЕ ВОПРОСЫ
Что происходит, если у нас есть только часть заказа?
Что происходит, если кредитная карта украдена?
---------------------------
РАСПИСАНИЕ
Due Date: релиз 1.0

Связанные статьи: Архитектурные роли в ИТ: где Solution Architect применяет Use Cases, Как написать ТЗ, Справочник аналитика: требования к ПО, Собеседование системного аналитика: полный гайд