Чек-лист для написания Use Case — именно то, что нужно джуну для формирования правильных привычек в работе с Use Case.

Вот подробная инструкция-чек-лист, которую можно использовать как карманную шпаргалку.

Инструкция-чек-лист для джуна: Как писать Use Case (UC)

Используй этот список на каждом этапе создания Use Case, чтобы ничего не упустить.

0 этап**: Подготовка (До того, как начать писать)**

  • Определи границы системы. Ответь на вопрос: «Что является системой, а что — внешней средой?» (Например, система «Интернет-магазин», а внешние акторы — «Покупатель», «Курьерская служба»).
  • Определи Акторов (Actors). Кто или что взаимодействует с системой для достижения цели? Актором может быть роль (Пользователь, Админ), другая система (Платежный шлюз) или устройство.
  • Определи Цель Актора. Какую конечную, значимую бизнес-цель преследует актор, запуская этот Use Case? (Например, цель «Оформить заказ»). Это поможет отсечь лишние шаги.
  • Проверь, не существует ли уже похожего UC. Не изобретай велосипед. Возможно, нужную функциональность можно описать расширением существующего UC.

1 этап: Структура и Основной поток

  • Заполни шапку документа.
  • Название UC: Глагол + существительное, отражающее цель (Например: «Оплатить заказ»).
  • Уникальный ID: (Например: UC-102). Полезно для трекинга.
  • Акторы: Основные и второстепенные.
  • Основной Предусловие (Pre-condition): Что должно быть истиной на момент старта UC? (Например: «Пользователь авторизован», «В корзине есть товары»).
  • Основной Постусловие (Post-condition): Какое состояние системы гарантировано после успешного выполнения Основного потока? (Например: «Создан новый заказ со статусом ‘Оплачен’», «Списаны бонусные баллы»).
  • Опиши Основной поток (Basic Flow).
  • Это «идеальный» сценарий, где все идет без ошибок.
  • Нумеруй шаги (1, 2, 3…).
  • Начинай с инициации UC актором.
  • Используй конструкцию: «Актор -> Система: Действие».
  • Фокус на ЧТО делает система, а не КАК.
  • Каждый шаг — это законченное действие, а не мелкое движение.
  • Пример:
    • Покупатель нажимает кнопку «Перейти к оплате».
    • Система отображает доступные способы оплаты.
    • Покупатель выбирает способ «Банковская карта» и нажимает «Оплатить».
    • Система перенаправляет Покупателя на страницу ввода данных карты платежного шлюза. … и т.д.

2 этап: Детализация и «Хорошие» практики

  • Проверь формулировки.
    • Избегай технического жаргона в шагах («система делает SELECT в БД»). Вместо этого: «Система проверяет наличие товара на складе».
    • Используй единый глоссарий терминов (например, всегда «Корзина», а не иногда «Cart»).
    • Убедись, что шаги однозначны и не допускают двоякого толкования.
  • Определи Альтернативные потоки (Alternative Flows).
    • Это отклонения от основного потока, которые ведут к успеху или другой логической точке.
    • Формат: А[Номер шага основного потока]: [Краткое описание условия]. (Например: А4: Покупатель выбрал оплату бонусными баллами).
    • Опиши, что происходит в этом случае, и где поток возвращается к основному (или куда уходит).
  • Определи Исключения (Exceptions).
    • Это потоки, которые приводят к ошибке и не достигают цели Use Case.
    • Формат: E[Номер шага]: [Описание ошибки]. (Например: E4: Введены неверные данные карты).
    • Обязательно укажи, как система обрабатывает ошибку (показывает сообщение, логирует, завершает сеанс и т.д.).
  • Укажи не функциональные требования (если применимо).
    • Производительность: «Оплата должна завершиться не более чем за 10 секунд».
    • Безопасность: «Данные карты не должны храниться в системе».
    • Usability: «Сообщения об ошибках должны быть понятными для пользователя».

3 этап: Проверка (Перед тем, как отдать на ревью)

  • Проверь целостность.
    • Все ли предусловия выполняются на момент старта?
    • Гарантированно ли выполнится постусловие после Основного потока?
    • Все ли шаги основного потока действительно ведут к цели?
  • «Прогони» Use Case мысленно.
    • Представь себя актором. Все ли шаги логичны? Нет ли «провалов» в логике (например, система запрашивает пароль, не спросив логин)?
    • Проверь, покрыты ли альтернативные потоки и исключения: «А что, если…?».
  • Проверь на избыточность.
    • Не описываешь ли ты в Use Case UI? (Например: «Пользователь нажимает на синюю кнопку в правом верхнем углу»). Это ошибка.
    • Не пытаешься ли объять необъятное? Один UC — одна цель. Если поток стал слишком большим, возможно, его нужно разбить на несколько UC (например, «Добавить товар в корзину», «Оформить заказ», «Оплатить заказ»).
  • Отдай на ревью коллеге (мидлу/синьору).
    • Свежий взгляд всегда находит недочеты. Попроси коллегу прочитать UC и задать любые вопросы, которые у него возникнут. Если вопросы есть — значит, описание не до конца ясное.

Краткая шпаргалка-напоминалка для каждого UC:

  • 🎯 Одна цель: Этот UC о чем?
  • 👤 Актор и система: Кто инициирует? Кто отвечает?
  • 1…2…3…: Основной поток — это история успеха.
  • А и E: Альтернативы и Исключения — это жизнь.
  • До и После: Пред- и постусловия задают рамки.
  • Проверь и спроси: Никогда не пренебрегай ревью.

Помни: Use Case — это история диалога между Актором и Системой. Твоя задача — рассказать эту историю полно, четко и без лишних деталей. Удачи

Полезные материалы: