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

Документ создаётся до начала разработки. Системный аналитик фиксирует требования однозначно и проверяемо. Разработчик получает чёткое описание пути пользователя и проектирует бэкенд без дополнительных уточнений. Тестировщик берёт готовый тест-кейс: каждый пронумерованный шаг use case — отдельная проверка на этапе приёмочного тестирования.

В статье разбираем шаблон Карла Вигерса из книги «Разработка требований к программному обеспечению» — ориентира для системного аналитика. Три формата документа, заполненный пример «Положить товар в корзину» и пять типичных ошибок, из-за которых тестировщик теряет возможность сослаться в баг-репорте на конкретный шаг.

Что такое use case и кому он нужен

Use case — это не просто описание функции. Это пошаговый путь: пользователь делает действие — система отвечает реакцией. Именно такой формат делает документ одновременно требованием для разработчика и основой для проверки качества.

Use case входит в состав технического задания или спецификации требований. Системный аналитик создаёт его на этапе сбора требований — до того, как разработчик напишет первую строку кода. Документ обновляется при изменении функциональности или смене дизайн-системы.

Польза по ролям:

• Системный аналитик — проектирует поведение системы от общего к частному, применяя нотацию UML (унифицированный язык моделирования) и текстовый шаблон.
• Разработчик — работает по чётким сценариям без необходимости додумывать детали реализации.
• Тестировщик — получает готовый тест-кейс с нумерованными шагами и ожидаемым результатом для каждого из них.

Use case против user story: в чём разница

Пользовательская история (User Story) фиксирует цель в одном предложении: «Я, как [роль], хочу [действие], чтобы [результат]». Это контекст без деталей реализации — бизнес-аналитик собирает такие истории на встречах с заказчиком.

Use case — следующий уровень детализации. Системный аналитик берёт User Story и разворачивает её в документ с нумерованными шагами, предусловиями и расширениями. Схема такая: User Story предшествует use case, use case порождает тест-кейс.

Пример трансформации: User Story «Хочу оставить комментарий к товару» превращается в use case с пятью шагами — авторизация, переход к товару, ввод текста, отправка, получение подтверждения — и альтернативным сценарием на случай, если пользователь не авторизован. Именно этот альтернативный путь тестировщик проверит в первую очередь.

Освоить практику написания use case — от первой User Story до проектирования систем — можно по программе «Системный аналитик: с нуля до проектирования систем» в рамках нацпроекта «Кадры». 72 часа практики, бесплатно за счёт государства.

Структура шаблона use case: поля и их назначение

Карл Вигерс описал классический шаблон use case в «Разработке требований к программному обеспечению»: 11 полей, 7 из которых обязательны. Ключевое правило — пустое поле не удалять. Оно остаётся как явный сигнал команде: расширений нет, исключений нет, аналитик это осознанно зафиксировал.

Поля делятся на три группы. Разберём каждую пошагово.

Шаг 1 — Заголовок, акторы и точка входа

Заголовок формулируется по шаблону «глагол + объект»: «Выбор файлов для загрузки», «Оформление заказа», «Восстановление пароля». Не «Корзина» и не «Функция добавления» — глагол обязателен, он описывает действие, а не сущность.

Акторы — роль пользователя, запускающего сценарий: контент-менеджер, администратор, незарегистрированный покупатель. Если акторов несколько — добавляем столбец с ролью, чтобы разработчик понимал, у кого какие права доступа.

Точка входа — путь в интерфейсе до начала сценария: «Главная → Каталог → Страница товара → кнопка «В корзину»». Это помогает тестировщику воспроизвести сценарий в точной последовательности.

Шаг 2 — Предусловие, триггер и гарантии успеха

Предусловие описывает состояние системы до старта сценария. Пользователь авторизован. Товар есть в наличии. Страница товара загружена. Если предусловие не выполнено — сценарий не запускается.

Триггер — конкретное событие, которое запускает сценарий: нажатие кнопки «Купить», переход по баннеру, автоматическое перенаправление после входа.

Гарантии успеха — проверяемое состояние системы после выполнения сценария. Товар добавлен в корзину. Счётчик в иконке корзины увеличился на 1. Пользователю показано уведомление. Это не описание кнопки — это результат, который тестировщик фиксирует после прохождения основного сценария.

Шаг 3 — Основной сценарий, расширения и исключения

Основной сценарий — нумерованный список шагов успешного пути. Пользователь нажимает кнопку → система проверяет наличие → добавляет товар → обновляет счётчик. Нумерация обязательна: без номеров тестировщик не может сослаться в баг-репорте на конкретное место.

К каждому шагу задаём вопрос: «А что если?» Если на шаге 3 товар закончился — расширение 3.1. Пользователь нажал «Отмена» — расширение 3.2. Так выявляются корнер-кейсы — граничные ситуации, которые без явного описания тестировщик пропустит на этапе проверки качества.

Общие ошибки сервиса — нет соединения, таймаут — выносятся в отдельный документ со ссылкой из use case. Это исключает дублирование одних и тех же сценариев в десятках документов.

Три формата шаблона: полный, компактный и кастомный

Формат выбирается под команду и методологию. Ниже — сравнение по четырём критериям.

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

Готовый пример use case с описанием

Разберём заполненный шаблон — мобильный интернет-магазин, сценарий «Добавить товар в корзину».

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

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

Типичные ошибки при написании use case

Документ без чёткой структуры превращается в источник вопросов, а не ответов. Пять ошибок, которые встречаются чаще всего.

Длинные деепричастные конструкции. «Пользователь, убедившись в наличии товара, нажимает кнопку» → «Пользователь нажимает «В корзину»». Один шаг — одно короткое действие.

Нет нумерации шагов. Без номеров тестировщик пишет в баг-репорте «где-то в середине сценария». Разработчик тратит время на поиск контекста. Нумерация — способ ссылаться точно, а не формальность.

Пустые поля удалены. Если расширений нет, аналитик убирает строку — разработчик не понимает: расширений нет или их забыли добавить? Пустое поле — намеренный сигнал об отсутствии альтернатив.

Макеты без ресурса на актуализацию. Скриншоты из Figma устаревают при первом обновлении дизайн-системы. Решение — общая ссылка на файл в Figma вместо вставленных изображений.

Дублирующиеся фичи. Одна и та же функция описана в нескольких use case. Выносите общие сценарии в отдельный документ и ссылайтесь на него — это упрощает поддержку при смене требований.

Часто задаваемые вопросы

Кто пишет use case — системный или бизнес-аналитик?

Основной автор — системный аналитик: он детализирует требования до уровня шагов системы. Бизнес-аналитик собирает пользовательские требования и передаёт их системному аналитику. Если аналитика нет — use case пишет менеджер проекта или тимлид в сокращённом формате.

Когда создаётся use case — до или после разработки?

Use case создаётся на этапе требований, до начала разработки. Он даёт разработчику понимание пути пользователя, а тестировщику — готовый тест-кейс. Обновляется при изменении функциональности или смене дизайн-системы.

Как нумеровать альтернативные сценарии в use case?

Нумерация строится от номера базового шага: если это шаг №3, альтернативы нумеруются 3.1, 3.2 и т. д. Это позволяет тестировщику точно сослаться в баг-репорте, а разработчику — понять конкретный контекст сценария.

Нужно ли вставлять макеты из Figma в use case?

Макеты улучшают восприятие, но при смене дизайн-системы их придётся обновлять. Правило: вставляйте макеты только при наличии ресурса на актуализацию. Альтернатива — общая ссылка на Figma-файл.

Чем use case отличается от тест-кейса?

Use case описывает путь пользователя с точки зрения требований. Тест-кейс — производный артефакт: тестировщик берёт use case и проверяет, работает ли система по описанию. Без нумерованных шагов в use case тест-кейс построить невозможно.

Когда строить диаграмму use case, а когда текстовый шаблон?

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

Что такое корнер-кейс и зачем он в use case?

Корнер-кейс — граничный сценарий, нестандартное поведение пользователя или системы. Выявляется вопросом «А что если?» к каждому шагу основного сценария. Фиксируется в расширениях. Без корнер-кейсов тестировщик пропускает граничные ситуации на этапе проверки качества.

Как адаптировать шаблон use case под Agile-команду?

В Agile use case пишется в сокращённом формате: берутся ключевые поля — триггер, основной сценарий, гарантии успеха. Полная спецификация нужна в Waterfall. Кастомный командный шаблон — финальный шаг после освоения стандартного.