# Scenario Rules

## Назначение

Этот файл описывает, как оформлять технический USE CASE в подраздел `### Сценарий` в документах.

## Обязательные части

- название
- предусловия
- триггер
- основной сценарий
- альтернативный сценарий
- обработка ошибок
- постусловие

## Правила
- Основной и альтернативные сценарии состоят из шагов. 

- Каждый шаг описывается одним предложением не более 15-20 слов, и состоит из двух частей. Первая часть описывает что мы делаем по смыслу, чтобы это было понятно человеку без низкоуровневых технических деталей. Например: авторизует запрос, получает данные клиента, запрашивает справочники. Вторая часть описывает как это реализовано технически - вызывает эндпоинт /path/to/resource в системе <название системы>.

- В описании шага не должно быть длинных технических деталей. Если техничсекую реализацию нельхзя описатьодним предложенеим (в лимите длины описания шага), то необхлодимо это вынести в отдельное функциональное требование  FR.<номер>. <Название>  и описать в нем технические детали. А в шаге сослаться на это требование через "Описание приведено в FR.<номер>. <Название>"

- Для шагов авторизации обязателен доп шаг с описанием обработки ошибки.
- Для шагов с интеграцией обязателен доп шаг с описанием обработки ошибки.
- Для шагов с проверкой условий обязательны доп шаги с описанием переходов по сценарию.

- Название "FR.<номер>. <Название>" формируется следующим образом: 
  - <номер> идет инкрементально внутри конкретного документа, начинается с 1.
  - <Название> - кратко описывает что делает требование, суть действий.

- Для каждого шага при необходимости нужно прописать логику действий в случае ошибки или если логика шага определяет несколько сценариев разивития при выполнении заданных условий. 

- Для шагов, которые описывают интеграцию с другой системой необходимо указать название точки интеграции (название эндпоинта, название топика и так далее) и сделать ссылку на FR.<номер>. <Название> с описанием шагов интеграции - как сформировать запрос/сообщение, как обработать ответ, политику ретраев.

 - Сценарий собирается из тезисов, приведенных системной аналимтике в свободной формулировке

 - Функциональные требования "FR.<номер>. <Название>" не должны дублировать шагов сценария в use case. Они содержат детали, которые вынесены из юзкейса чтобы не делать его тяжелым. Если шаг юзкейса описывается одним предложением в лимите длины, то FR делать не нужно.

 - FR обязательно описывается для шага с интеграцией
 - FR Не описывается для шага авторизации.






## Пример целевого описания сценария

### Примеры шагов сценария

Пример 1
- Авторизует запрос пользователя по наличию у него экшена ролевой модели CI02792632.ContactsDGR.Detail
  - В случае ошибки - завершить сценарий с кодом UNAUTHORIZED

Пример 2
- Запрашивает данные клиента - вызывает /api/v1/clients/{client-id}/info
  - В случае ошибки - завершить сценарий с кодом CLIENT_INFO_REQUEST_FAIL

Пример 3
- Возвращает ответ в формате <название DTO>

### Примеры названия FR
 - Получение данных клиента из АС ЕПК
 - Проверка уровня доступа
 - Сценарий построения списка связанных предложений