Вариант использования (Use Case) — артефакт, описывающий цель актора и наблюдаемое поведение системы в виде сценария «актор — система»: с границами, пред- и постусловиями, основным потоком и ветвлениями. Этот шаблон — рабочий документ для спецификации; теория нотации и выбор подхода — в 02.03.03 Спецификация требований (SRS, Use Case, User Story) и 04.03 Use Case vs User Story — выбор подхода.

1. Назначение

Use Case фиксирует что система делает для роли или внешней системы и при каких условиях, без подмены технической спецификацией. Его читают заказчик, бизнес-аналитик, системный аналитик, разработка, QA и архитектор.

Шаблон закрывает три задачи:

• Контракт поведения — сквозной сценарий с happy path, альтернативами и исключениями; один UC = одна измеримая цель primary actor. Include / extend — отдельные UC-ID, не вторая цель в том же документе.
• Мост между бизнесом и реализацией — между BRD/Vision (зачем) и детализацией (User Story, API, БД, экраны, интеграции).
• Точка трассировки — UC-ID → FR-ID в SRS → stories → test cases; шаги с UI/API — по ссылке на соседние артефакты, не копированием контрактов.

Порядок с SRS: upstream UC — только BRD (обязательно) и опционально epic-level ссылка в SRS, если FR уже заведены до детализации. FR-ID в SRS создаются или уточняются после Approved UC — из шагов, extensions и postconditions. Не дублируйте формулировки «сверху» и «снизу»: UC — источник поведения, SRS-FR — атомарные проверяемые требования. Полная модель цепочки — 02.03.04 Трассировка требований (концепция) и 10.01.15 Шаблон матрицы трассировки.

Use Case в разделе 10.01 — уровень сценария, а не единица бэклога: один UC часто декомпозируется в несколько 10.01.01 Шаблон User Story.

2. Когда использовать

Матрица «UC vs User Story», agile vs contract, CRUD vs сквозной процесс — 04.03 Use Case vs User Story — выбор подхода.

Уникально для этого шаблона:

• нужен fully dressed с extensions checklist (§3.7) — регламент, compliance, MVP с ветвлениями;
• каталог UC на диаграмме — форма Brief (таблица форм в §3); углубление в fully dressed по триггеру (релиз, compliance, инцидент).

Входные условия: роли согласованы (10.01.11 Шаблон ролевой модели), границы системы зафиксированы (03.01.02 Моделирование контекста системы (Context Diagram)), business goal привязан к BRD.

Уровни Cockburn (Summary / User goal / Subfunction): в одном документе не смешивайте. Шаблон ниже — для User goal; subfunction — отдельный UC с include-ссылкой. Подробнее об уровнях, include и subfunction — 02.03.03 Спецификация требований (SRS, Use Case, User Story).

3. Структура документа

Ниже — пояснение полей (§3.1–3.11). Готовый скелет для копирования — в §3.12. Скопируйте блок в Confluence, EA, draw.io или RM-инструмент (07.04 Инструменты моделирования (Sparx EA, Lucidchart, draw.io), 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)). Поля с пометкой обяз. нужны для согласования; остальные — по контексту.

Допустимы три формы одного шаблона:

3.1. Метаданные

3.2. Краткое описание и ценность

3.3. Scope и границы

3.4. Акторы и триггер

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

3.6. Основной сценарий (Main success scenario)

Правила качества шагов:

• В названии UC — без кнопок и UI-жаргона; в шагах допустимы пользовательские действия («нажимает „Отправить“») со ссылкой на FE-* при необходимости.
• Система описывает наблюдаемое поведение («отклоняет с кодом 403», «показывает список»), не внутреннюю реализацию.
• Include (subfunction): «На шаге N система выполняет UC-XXX (include)» — ID из §3.1 «Связанные UC»; postcondition include фиксируется в subfunction UC, не дублируется здесь. Связь с диаграммой — 03.02.01 Диаграмма прецедентов (Use Case Diagram).
• Шаг с синхронной интеграцией — «система отправляет запрос …» + ссылка на 10.01.04 Шаблон спецификации REST API / 10.01.05 Шаблон спецификации SOAP API.
• Шаг с публикацией события — ссылка на 10.01.06 Шаблон спецификации Producer (Kafka, RabbitMQ); если сценарий ждёт ответ или нужна компенсация — также 10.01.07 Шаблон спецификации Consumer (Kafka, RabbitMQ) и при необходимости 03.02.03 Диаграмма последовательности (Sequence Diagram).
• Шаг с UI — «система отображает экран …» + ссылка на 10.01.09 Шаблон описания экранной формы и логики на FE.
• UC как шаг сквозного процесса — ссылка на задачу/lane в 10.01.08 Шаблон сквозной фичи (BPMN-процесс).

3.7. Расширения и альтернативы (Extensions / alternate flows)

Нумерация: основные ветки — 4a, 4b; вложенные ответвления внутри extension — 4a1, 4a2 (например, цикл исправления полей в UI).

Когда допустимо «нет extensions — обосновано»: сценарий тривиален (нет ошибок, прав, интеграций, денег) и риск низкий; в обосновании укажите, какие пункты checklist проверены. Для compliance, платежей и публичных API extensions обязательны.

Checklist для extensions: авторизация, валидация полей, дубликат заявки/записи, повторная отправка (double submit), timeout, недоступность внешней системы, отмена актором, права доступа.

Если веток больше ~5–7 или они параллельны — добавьте 03.02.02 Диаграмма деятельности (Activity Diagram) и сослитесь из UC, не раздувая таблицу extensions.

3.8. Бизнес-правила и данные

3.9. NFR, допущения, трассировка

3.10. История изменений

3.11. Чеклист качества перед Review

• Primary actor и goal однозначны; название без привязки к кнопке.
• Trigger описан отдельно от шага 1; preconditions — факты до trigger.
• Postconditions (success) — после happy path; failure-postconditions — где требуются (§3.5).
• Основной поток соответствует level: ≥ 3 шага (User goal / Casual), абзац (Summary) или пропущен (Brief).
• Есть extensions для ошибок/прав или обоснован их отсутствие (§3.7).
• Scope и Out of scope явно разделены; include — отдельные UC-ID с формулировкой «на шаге N выполняется UC-XXX (include)».
• API/UI/БД/Producer/Consumer — ссылки, не дублирование контрактов.
• Upstream BRD заполнен; downstream FR/SRS — после Approved, без дублирования UC.
• Sign-off stakeholder указан для рискованных UC.

Review UC — инспекция артефакта: 08.04 Рецензирование и инспекции (техники Фейгана).

3.12. Блок для копирования

Скопируйте целиком в Confluence, EA или markdown-репозиторий. Заполните поля; удалите неиспользуемые секции (Summary — §3.6 абзацом; Brief — без §3.6 и §3.7).

# Use Case: [Название]
 
## Метаданные
 
| Поле | Значение |
|------|----------|
| **ID** | UC- |
| **Версия, статус, дата** | Draft · v0.1 · |
| **Продукт / подсистема** | |
| **Level (Cockburn)** | User goal / Summary / Subfunction |
| **Epic / релиз** | |
| **Upstream: BRD** | BRD-GOAL- |
| **Upstream: SRS (опц.)** | |
| **Согласующий (sign-off)** | |
| **Связанные UC** | include / extend: UC- |
 
## Краткое описание и ценность
 
**Краткое описание:**
 
**Goal / результат для актора:**
 
## Scope и границы
 
**Scope (внутри):**
 
**Out of scope:**
-
 
## Акторы и триггер
 
**Primary actor:**
 
**Secondary actors:**
-
 
**Trigger:** *(не входит в нумерованные шаги)*
 
## Пред- и постусловия
 
**Preconditions:**
-
 
**Postconditions (success):**
 
**Minimal guarantees:**
 
**Postconditions (failure):**
 
## Основной сценарий
 
1.
2.
3.
 
## Extensions
 
- **a.** [шаг] Условие → действия → возврат к шагу N / завершение UC
 
**Порядок проверки extensions:** *(если условия конфликтуют)*
 
**Обоснование отсутствия extensions:** *(если «нет отклонений — обосновано»)*
 
## Бизнес-правила и данные
 
**Business rules:**
 
**Ключевые сущности:**
 
## NFR, допущения, трассировка
 
**Ссылки на NFR:**
 
**Ссылки на ADR:**
 
**Assumptions / открытые вопросы:**
 
**Трассировка downstream:**
BRD-GOAL- → UC- → SRS-REQ- → US- → TC-
 
## История изменений
 
| Версия | Дата | Автор | Изменение |
|--------|------|-------|-----------|
| 0.1 | | | Черновик |

4. Пример заполнения

Заполненный экземпляр скелета (§3.12). Сокращённый fully dressed для HR Portal (данные условны).

Use Case: Оформить заявку на отпуск

Метаданные

Краткое описание и ценность

Краткое описание: Сотрудник подаёт заявку на отпуск в портале; система проверяет доступный баланс и переводит заявку на согласование руководителю.

Goal / результат для актора: Заявка создана в статусе «На согласовании», сотрудник видит подтверждение и номер заявки.

Scope и границы

Scope (внутри): HR Portal — модуль Leave Management.

Out of scope:

• Согласование руководителем (UC-LEAVE-013)
• Интеграция с 1С:ЗУП
• Отмена заявки (UC-LEAVE-014)

Акторы и триггер

Primary actor: Сотрудник (ROLE-EMP-01)

Secondary actors: Сервис уведомлений (email)

Trigger: Сотрудник выбирает «Подать заявку на отпуск» в личном кабинете (не входит в нумерованные шаги)

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

Preconditions: Сотрудник авторизован; справочник типов отпуска актуален; у сотрудника есть доступный баланс > 0 для выбранного типа.

Postconditions (success): Создана заявка REQ-* в статусе «На согласовании»; руководителю отправлено уведомление; сотрудник видит экран подтверждения.

Minimal guarantees: При ошибке сохранения черновик не теряется; попытка фиксируется в audit log.

Postconditions (failure): При завершении по extension 5a: заявка не создана в БД; локальный черновик сохранён; audit log содержит запись о неуспешной попытке.

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

1. Сотрудник открывает форму подачи заявки (экран FE-LEAVE-FORM-01).
2. Система отображает доступный баланс по типам отпуска.
3. Сотрудник указывает тип, даты начала и окончания, комментарий (опционально).
4. На шаге 4 система выполняет UC-LEAVE-VALID-001 (include): проверка дат, баланса, пересечений с существующими заявками, длительности непрерывного периода ≤ 28 дней (BR-047).
5. Система сохраняет заявку, присваивает номер, устанавливает статус «На согласовании».
6. Система публикует событие leave.request.submitted (см. PROD-LEAVE-001); downstream-обработка уведомления — CONS-NOTIF-LEAVE-001.
7. Система отображает подтверждение с номером заявки.

Extensions

• 4a. Недостаточный баланс → система показывает «Недостаточно дней отпуска», подсвечивает поле дат; сценарий возвращается к шагу 3.
• 4b. Пересечение с заявкой REQ-7720 → система показывает «Период пересекается с заявкой REQ-7720»; возврат к шагу 3.
• 4c. Непрерывный период > 28 дней (BR-047) → система показывает «Непрерывный отпуск не более 28 дней»; возврат к шагу 3.
• 5a. Ошибка сохранения (5xx) → система сохраняет черновик локально, показывает «Не удалось отправить. Повторите позже»; UC завершается неуспешно (см. postconditions failure).
• 6a. (Продуктовое решение, согласовано с бизнесом и ADR-042.) Очередь недоступна → заявка сохранена; система ставит событие в outbox для повторной отправки; сотрудник видит подтверждение без задержки уведомления руководителю.

Business rules: BR-047: непрерывный отпуск не более 28 календарных дней — проверка в UC-LEAVE-VALID-001, extension 4c.

NFR: NFR-AUDIT-003 — запись audit на шаге 5; NFR-PERF-012 — шаги 2–4, p95 < 2 с.

Трассировка (после Approved): BRD-GOAL-011 → UC-LEAVE-012 → SRS-REQ-038, SRS-REQ-039 → US-0238, US-0239 → REST API-LEAVE-001, FE FE-LEAVE-FORM-01, Producer PROD-LEAVE-001, Consumer CONS-NOTIF-LEAVE-001 → TC-LEAVE-012 (happy path), TC-LEAVE-012-4a, TC-LEAVE-012-4b, TC-LEAVE-012-4c, TC-LEAVE-012-5a, TC-LEAVE-012-6a.

5. Связанные артефакты

На входе (upstream)

На выходе (downstream)

Типичный порядок работы аналитика

1. Контекст и список акторов → каталог UC (brief) → приоритизация (02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)).
2. Fully dressed для MVP и рискованных сценариев.
3. Review с бизнесом (основной поток и extensions) и с архитектурой (интеграции, NFR) — 08.04 Рецензирование и инспекции (техники Фейгена).
4. Approved UC → заведение/уточнение FR в SRS → stories → API/экраны/БД.
5. Тест-кейсы по happy path и значимым extensions — 08.03 Тестирование требований (статическое тестирование).
6. Изменения UC — версионирование и impact analysis (02.05.05 Жизненный цикл требования; 02.05.02 Управление изменениями (Change Control Board) при формальном процессе).

6. Связи с другими разделами базы

Куда идти за теорией — без дублирования полей шаблона:

• Поведенческие диаграммы UML и место UC в нотации — 06.01.02 Поведенческие диаграммы (State, Activity, Use Case)
• Критерии приёмки, выводимые из extensions — 02.04.02 Критерии приёмки (Acceptance Criteria)
• Верификация сценариев на review и приёмке — 02.04.01 Верификация и валидация (V&V)
• Качество формулировок требований — 02.04.03 Управление качеством требований
• Классификация ФТ и НФТ в цепочке UC → SRS — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
• Стандарты ISO 29148 и структура SRS — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)
• Аналитик в Agile: когда достаточно brief UC — 05.02 Scrum и Kanban (аналитик в Agile)

7. Источники и дополнительные материалы

Книги и стандарты

• Alistair Cockburn — Writing Effective Use Cases (уровни, fully dressed, postconditions, extensions) — https://www.pearson.com/en-us/subject-catalog/p/writing-effective-use-cases/P100000000000/9780321125194
• Alistair Cockburn — материалы автора — https://alistair.cockburn.us/
• OMG — UML Superstructure — Use Cases (актор, include/extend) — https://www.omg.org/spec/UML/
• IIBA — BABOK Guide — Requirements Analysis and Design Definition (формализация и трассировка требований) — https://www.iiba.org/standards-and-resources/babok/
• ISO/IEC/IEEE 29148:2018 — Systems and software engineering — Life cycle processes — Requirements engineering — https://standards.ieee.org/standard/29148-2018.html
• IEEE — IEEE 830-1998 (классическая структура SRS; withdrawn, см. 29148) — https://standards.ieee.org/standard/830-1998.html

Статьи

• Wikipedia — Use case (обзор терминов, fully dressed, связь с UML) — https://en.wikipedia.org/wiki/Use_case
• Agile Alliance — User Stories (glossary; граница с User Story) — https://www.agilealliance.org/glossary/user-stories/