Use case 2.0 — это облегчённая, более «прикладная» версия описания сценариев, где можно за 2–5 дней упаковать требования так, чтобы команда перестала угадывать, а заказчик — “вроде это не то” на демо; выйти на стабильную поставку за 1–2 спринта реально, но ключевой риск — спутать use case с UX-макетами и потерять тестируемость.

Почему старые «толстые» use case не работают (и почему вы их всё равно пишете)

Боль знакомая: аналитик пишет 20 страниц «Основной поток / альтернативные потоки / исключения», разработчик читает первые две, тестировщик ищет хоть что-то проверяемое, а PO в конце говорит: «Я это не имел в виду». И вот вы снова открываете Confluence и начинаете “уточнять”.

Use case 2.0 появился как реакция на эту бюрократию: меньше художественной прозы, больше структуры, которая бьётся о реальную разработку (user story, acceptance criteria, тест-кейсы). В результате требования становятся не “документом”, а интерфейсом между людьми.

Use case 2.0 — что именно обновляем

Определение: что такое Use case 2.0 в проекте

Use case 2.0 — это набор компактных артефактов: краткое описание цели, перечень срезов (slices) по ценности, критерии готовности и (в идеале) связка с тестами. Он не отменяет user story и не заменяет BPMN, он закрывает дырку между «что нужно бизнесу» и «как это будет работать для пользователя».

• Use case — граница системы и цель пользователя.
• Slices — маленькие поставляемые куски ценности (по сути, нарезка use case на MVP-инкременты).
• Acceptance criteria — проверяемые условия, которые можно автоматизировать или хотя бы однозначно протестировать.

Главное изменение: от “одного гигантского сценария” к поставке кусками

Классическая ошибка — пытаться описать весь сценарий целиком, включая все ветки, и только потом отдавать в разработку. Use case 2.0 предлагает другую логику: берёте одну цель и режете на slices так, чтобы первый кусок был поставляемым и проверяемым. Этот подход не «про Agile», он про снижение цены ошибки: если вы ошиблись, вы ошиблись в одном срезе, а не в 3 месяцах разработки.

Как обновить требования под Use case 2.0: пошаговый алгоритм

Шаг 1. Зафиксируйте границу системы (иначе диаграмма будет врать)

Тезис: если не договориться “где система начинается и заканчивается”, дальше всё поедет — актёры перепутаются с ролями, а use case начнёт описывать организационный процесс вместо поведения системы.

• Назовите систему (например: «Портал заявок на обслуживание»).
• Определите внешних актёров: пользователь, платёжный провайдер, CRM, служба поддержки.
• Внутренние роли компании не всегда актёры. “Менеджер” может быть частью системы, если он работает в интерфейсе системы. Если он «просто принимает решения» — это уже спорно, уточните.

Подводный камень: смешать “актер” и “персона”. Персона — про UX и сегменты. Актёр — технически внешняя сущность, взаимодействующая с системой.

Шаг 2. Опишите цель в одном предложении

Каждый use case должен отвечать на вопрос: «Зачем актёр приходит в систему?». Одно предложение, без “и ещё”.

• Плохо: «Пользователь оформляет заказ и оплачивает и отслеживает доставку» — это три цели.
• Нормально: «Пользователь оформляет заказ с оплатой онлайн».

Практический вывод: одна цель — одна диаграммная “овалка”. Всё остальное — include/extend или отдельные use case.

Шаг 3. Нарежьте slices: 3–7 поставляемых кусков вместо “всего сразу”

Срезы — это не просто альтернативные потоки. Это “минимально полезные инкременты”, которые можно поставить, показать и протестировать.

1. Slice 1 (happy path MVP): самый простой основной поток без экзотики.
2. Slice 2: важный бизнес-исключение (например, отказ оплаты).
3. Slice 3: критичный нефункциональный аспект, если он блокирует поставку (например, аудит/логирование для регулятора).

Подводный камень: нарезать “по слоям” (сначала API, потом UI, потом интеграции). Это удобно команде, но плохо бизнесу. Нарезайте “по ценности”: чтобы кусок можно было потрогать.

Шаг 4. Для каждого slice сделайте проверяемые acceptance criteria

Если критерии нельзя проверить — вы написали пожелание, а не требование. Критерии должны быть такими, чтобы тестировщик мог сказать “pass/fail” без телепатии.

• Формат Given/When/Then — ок, но не молитесь на него.
• Добавьте правила валидации, статусы, сообщения об ошибках (минимально).
• Зафиксируйте, что является “успехом” операции (создана сущность, отправлено письмо, записано событие).

Шаг 5. Привяжите к диаграмме: use case diagram как карта, не как ТЗ

Диаграмма Use Case полезна, когда она отвечает на два вопроса: кто с системой взаимодействует и какие цели закрывает система. Всё. Она не должна описывать “в каком порядке жмем кнопки”. Для порядка есть flow, activity, sequence, прототип.

Диаграмма Use Case для Use case 2.0: как правильно рисовать

Минимальный состав диаграммы

• Система (рамка с названием).
• Актёры (2–6, иначе вы рисуете организацию, а не систему).
• Use case (цели, 5–15, иначе это каталог функций без приоритетов).
• Связи include/extend — только если они реально помогают читать.

Правила include/extend на человеческом

• <<include>> — обязательный подпроцесс, общий для нескольких use case (например, «Аутентификация»).
• <<extend>> — опциональное поведение при условии (например, «Запросить повторную оплату» при отказе).

Подводный камень: использовать include, чтобы “показать порядок шагов”. Это не про порядок, это про переиспользование.

Пример (текстовая спецификация диаграммы)

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

• Актёры: Клиент, Платёжный провайдер, Складская система
• Use case: Оформить заказ, Оплатить заказ, Отменить заказ, Отслеживать статус
• include: «Оформить заказ» include «Рассчитать стоимость доставки»
• extend: «Оплатить заказ» extend «Повторить оплату» (условие: отказ провайдера)

Скрытая цена обновления требований (куда утекает время и деньги)

Use case 2.0 экономит время не потому, что “короче”, а потому что снижает переспецификацию и количество итераций “переделайте”. Но бесплатным это не будет.

• Время PO/бизнеса: нужно принимать решения по slices и приоритетам, а не “потом разберемся”.
• Время команды: на синхронизацию терминов (глоссарий) и статусов.
• Тестирование: придётся делать критерии проверяемыми, а это иногда неприятная правда про продукт.

Типичная ошибка: “нарисуем диаграмму — и всё станет понятно”. Нет. Диаграмма — оглавление, не книга.

Таблица: было / стало — требования до и после Use case 2.0

Экспертный вердикт и инструмент: чек-лист обновления требований

• 1) Я могу назвать актёров как внешние сущности, а не должности?
• 2) Каждый use case — это одна цель в одном предложении?
• 3) У меня есть 3–7 slices, и первый реально поставляем за спринт?
• 4) Acceptance criteria проверяемые (pass/fail), без “удобно”, “быстро”, “понятно”?
• 5) Диаграмма отвечает на “кто/что”, а не пытается заменить flow?
• 6) Я знаю, какие исключения критичны бизнесу, а какие можно отложить?

Частые вопросы