Варианты использования (use cases) — один из самых мощных инструментов в арсенале бизнес-аналитика. Но даже самая продуманная методика даст сбой, если не соблюдать базовые правила качества. Давайте разберёмся, как создавать по-настоящему полезные use cases, которые не вызовут вопросов у разработчиков и точно передадут суть требований.
Бизнес vs системные use cases: в чём разница?
Перед тем как проверять качество, важно понимать — варианты использования бывают разными. В зависимости от цели описания выделяют два основных типа:
Бизнес-варианты описывают процессы так, как если бы они выполнялись вручную, без участия автоматизированных систем. Например, процесс продажи товара в спа-центре, где администратор вручную записывает покупки в журнал. Здесь важно зафиксировать саму бизнес-логику: кто что делает, в какой последовательности, какие документы оформляет.
Системные варианты фокусируются именно на взаимодействии пользователя с программным обеспечением. В том же примере с продажей товара системный use case будет описывать, как администратор сканирует штрих-код в CRM, система отображает информацию, происходит оплата через терминал и т.д.
Главное правило: бизнес-варианты помогают понять суть процесса, системные — объясняют, как это будет работать в программе. Не всегда нужны оба типа, но важно чётко понимать, какой именно use case вы составляете.
Чек-лист качества: 8 ключевых критериев
1. Чёткое определение акторов
В каждом шаге должно быть ясно, кто совершает действие. Фразы типа "озвучивается способ оплаты" недопустимы — непонятно, кто именно озвучивает. Правильно: "клиент называет способ оплаты" или "система предлагает выбрать способ оплаты".
2. Единый временной формат
Все действия должны описываться в настоящем времени и действительном залоге. Не "пользователь передал товар", а "пользователь передаёт товар". Это создаёт эффект "киносценария", где читатель видит процесс в развитии.
3. Альтернативные сценарии
"Счастливый путь" — это лишь вершина айсберга. Качественный use case включает:
- Альтернативные способы выполнения (например, оплата наличными вместо карты)
- Обработку ошибок (отказ терминала, неверные данные)
- Исключительные ситуации (прерванная операция)
4. Атомарность описания
Один use case — одна законченная операция. Если процесс слишком сложный, разбейте его на несколько связанных use cases. Например, "Оформление заказа" и "Оплата заказа" могут быть разными use cases.
5. Полнота сценария
Use case должен описывать процесс от триггера (что запускает сценарий) до финального результата. Частая ошибка — обрывать описание на середине. Например, в сценарии покупки товара важно не только описать оплату, но и передачу товара клиенту, закрытие заказа в системе.
6. Разумная детализация
Золотая середина между избыточной и недостаточной детализацией. Не нужно описывать каждый клик мышкой, но и оставлять "белые пятна" нельзя. Например, вместо "система обрабатывает данные" лучше написать "система проверяет соответствие введённых данных формату email".
7. Простота языка
Избегайте:
- Технического жаргона (если термин необходим, дайте пояснение)
- Сложных синтаксических конструкций
- Двусмысленных формулировок
8. Единый формат
Все use cases в проекте должны следовать одному шаблону. Если начали описывать с указанием контекста, области действия и акторов — продолжайте в том же духе. Это упрощает чтение и анализ.
Пример Use Case
Вариант использования: Оплата товара в спа-центре
Контекст: Клиент спа-центра желает приобрести товар с возможностью выбора способа оплаты
Область действия: CRM-система спа-отеля и платежный терминал
Основной актор: Посетитель спа-центра
Участники:
- Администратор (сканирует товар, управляет процессом оплаты)
- Платежный терминал (обрабатывает транзакции)
- CRM-система (фиксирует продажу, формирует чеки)
Предусловия:
- Посетитель выбрал товар
- Администратор авторизован в CRM-системе
- Платежный терминал подключен и готов к работе
Основной сценарий (оплата картой):
- Посетитель передает товар администратору
- Администратор сканирует штрих-код товара
- CRM-система отображает название и цену товара
- Администратор нажимает кнопку "Оплатить"
- Посетитель выбирает оплату банковской картой
- Администратор выбирает в системе соответствующий способ оплаты
- Система активирует платежный терминал
- Посетитель прикладывает карту к терминалу
- Терминал обрабатывает платеж
- Терминал печатает подтверждение об успешной оплате (слип-чек)
- CRM-система формирует кассовый чек
- Администратор передает товар и оба чека посетителю
- Система фиксирует завершение продажи
Альтернативные сценарии:
Оплата наличными:
5.1 Посетитель выбирает оплату наличными
6.1 Администратор выбирает в системе "Наличный расчет"
6.2 Посетитель передает деньги администратору
6.3 Администратор вводит полученную сумму в систему
6.4 Система рассчитывает сдачу
6.5 Администратор выдает сдачу посетителю
→ Переход к шагу 11 основного сценария
Ошибка оплаты:
9.1 Терминал сообщает об ошибке платежа
9.2 Система уведомляет администратора об ошибке
9.3 Администратор предлагает посетителю повторить оплату или выбрать другой способ
→ Возврат к шагу 5
Постусловия:
- Товар передан покупателю
- Оплата зафиксирована в системе
- Сформированы финансовые документы
Бизнес-правила:
- При оплате наличными сумма округляется до целого числа
- Возврат товара возможен только при предъявлении чека
- Максимальная сумма наличного платежа — 100 000 руб.
Технические требования:
- Время обработки платежа — не более 15 секунд
- Интеграция с фискальным регистратором
- Поддержка бесконтактных платежей (NFC)
Пример улучшения use case
Рассмотрим пример с покупкой товара в спа-центре. Исходная версия содержала множество проблем:
- Пропущенные акторы в некоторых шагах
- Смешение времён
- Неполное описание финальных действий
- Отсутствие важных альтернативных сценариев
После доработки use case стал:
- Чётче — каждый шаг имеет явного исполнителя
- Полнее — добавлены финальные действия и альтернативные сценарии
- Понятнее — убран профессиональный жаргон или пояснён
- Логичнее — соблюдена последовательность от начала до конца
Почему это важно?
Качественные use cases экономят время и нервы всей команде:
- Заказчики точно понимают, как будет работать система
- Разработчики получают чёткие инструкции без двусмысленностей
- Тестировщики могут на их основе создавать тест-кейсы
- Аналитики уменьшают количество уточняющих вопросов
Потратив лишний час на проверку use case по этому чек-листу, вы сэкономите десятки часов на исправлении недоразумений в будущем. Помните: хороший use case — это не просто документ, а инструмент коммуникации между всеми участниками проекта.
