Чек-лист для написания 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 — это история диалога между Актором и Системой. Твоя задача — рассказать эту историю полно, четко и без лишних деталей. Удачи
...
