Определить границы системы и целевой контекст

• • Зафиксировать, какую подсистему или приложение вы моделируете (например, «Интернет-банк» или «Модуль оформ­­ления заказа»).

  • Описать, какие внешние системы, устройства или организации взаимодействуют с вашей системой (см. раздел «акторы»).

  • Неплохо сразу набросать контекст-диаграмму (UML «System Context»), чтобы все чётко понимали, где грань «своё»/«чужое».

• **Идентифицировать и описать акторов (пользователей и внешние системы)
  **

  • Актор – это любая роль, которая инициирует или участвует в варианте использования.

  • Разделить акторов на «человеческих» (Покупатель, Администратор) и «системных» (Платёжный шлюз, СМС-сервис).

  • Для каждого акт­ ора коротко указать, какие права и обязанности у него есть (например, «Покупатель: может выбирать товары, добавлять их в корзину, оплачивать»).

• **Сформулировать цели (Use Case Goals)
  **

  • Для каждого актора подумать: «Что он хочет достичь?»

  • Записать главную цель в виде фразы «Актор делает X, чтобы получить Y» (например, «Покупатель оформляет заказ, чтобы получить товар»).

  • При необходимости определить второстепенные цели («подцели»: «Пользователь восстанавливает пароль, чтобы вновь войти в систему»).

• **Построить список вариантов использования (Use Case Catalog)
  **

  • На основе набора целей акторов составить список именованных Use Case:

    • UC1: «Регистрация нового пользователя»

    • UC2: «Авторизация»

    • UC3: «Оформление заказа»

    • …

  • Сгруппировать похожие или вложенные кейсы (например, UC3a «Выбор товаров», UC3b «Оплата заказа»).

• **Определить предусловия (Preconditions)
  **

  • Для каждого Use Case описать, какие условия уже должны быть выполнены до его запуска.

  • Пример: для UC3 («Оформление заказа») предусловия: «Пользователь авторизован, в корзине есть ≥ 1 товар».

• **Указать постусловия (Postconditions) или гарантии
  **

  • Что обязательно должно быть в конце варианта использования.

  • Должны отличаться от «последствий» (этим обычно занимается бизнес-правилами), но задают границы:

    • «Заказ создан в статусе «Ожидает оплаты»»

    • «Пользователь перенаправлен на страницу «Спасибо»».

• **Описать основной (базовый) сценарий (Main Success Scenario)
  **

  • Нумерованный пошаговый текст:

    • Пользователь нажимает «Оформить заказ».

    • Система показывает форму доставки.

    • Пользователь вводит адрес и нажимает «Далее».

    • Система рассчитывает итоговую стоимость и отображает способ оплаты.

    • …

  • Каждый шаг коротко, глаголами в настоящем времени, без лишних технических деталей.

• **Прописать альтернативные и расширяющие потоки (Alternate & Exception Flows)
  **

  • Для каждого шага базового сценария предусмотреть, что может пойти «не по плану»:

    • 3a. Если доставка по введённому адресу невозможна → Показать сообщение об ошибке и предложить скорректировать адрес.

    • 5b. Если платёж не прошёл → Предложить другой способ оплаты или повторить попытку.

  • Альтернативный (бизнес-ориентированный) поток: «Пользователь выбирает оплату при получении».

  • Исключительный поток: «Сервис оплаты недоступен».

• **Описать специальные требования и бизнес-правила
  **

  • Например, правила валидации полей («Телефон: 10 цифр, первый не 0»), ограничения («Максимальное кол-во товаров в заказе = 99»), SLA-интеграций («ожидание ответа от платежного шлюза не более 5 секунд»).

  • Эти требования можно вынести отдельной секцией «Non-functional Requirements» или «Business Rules».

• **Составить диаграмму Use Case (UML)
  **

• Нарисовать Use Case Diagram: акторы → ассоциации → Use Case.

• При большом количестве кейсов сгруппировать их в пакеты (subsystems).

• Диаграмма нужна для быстрой навигации и обсуждения на уровне команд.

• **Провести валидацию и уточнения с ключевыми стейкхолдерами
  **

• Собрать заинтересованных лиц (бизнес-представителей, UX/UI-дизайнеров, архитекторов, разработчиков).

• Пройтись вместе по основному сценарию и альтернативам, отметить пропуски, неточности.

• Записать все уточнения и внести правки в текстовое описание и диаграмму.

• **Рефакторить и версионировать Use Case
  **

• После каждого крупного обсуждения или итерации обновлять артефакт.

• Нумеровать версии (v1.0, v1.1, v2.0) и фиксировать изменения.

• Не допускать «зависания» документации — она должна развиваться вместе с продуктом.

• **Связать Use Case с другими артефактами
  **

• Карты пользовательских историй (User Stories), Acceptance Criteria.

• Тест-кейсы (Test Cases) и чек-листы QA.

• Бэклог задач в Jira/Trello с привязкой к UC-ID.

• Архитектурные документы (Sequence Diagrams, Class Diagrams).

• **Использовать Use Case в процессе разработки и тестирования
  **

• На основании сценариев UC разработчики пишут код и юнит-тесты.

• QA-инженеры формируют тест-планы и проверяют все альтернативные и исключительные потоки.

• На демо показывают именно те шаги, которые описаны в Use Case, убеждаются, что «всё как в документе».

• **Периодически пересматривать и править
  **

• По мере роста продукта требования меняются.

• За счёт версионирования легко отслеживать эволюцию UC.

• Use Case остаётся живым документом, а не статичной спецификацией.

Итого, последовательность разработки Use Case — это:

1. Границы системы

2. Акторы

3. Цели акторов

4. Каталог UC

5. Предусловия и постусловия

6. Основной сценарий

7. Альтернативные потоки

8. Бизнес-правила и NFR

9. Диаграмма UML

10. Валидация со стейкхолдерами

11. Версионирование и связь с бэклогом

12. Использование в dev/test

13. Регулярный рефакторинг

Такой детальный, структурированный подход гарантирует, что никто не потеряет детали, а команда сможет эффективно разрабатывать, тестировать и поддерживать систему.