operations Specification

Purpose

Расчёт сроков и эксплуатационные требования в системе «Обратная связь — регион».

Requirements

Requirement: REQ-TIM-001 — Срок публикации итогового ответа

{
  "id": "REQ-TIM-001",
  "level": "REQ",
  "status": "agreed",
  "owner": "product-owner",
  "parents": [
    "HLR-POS-008"
  ],
  "sources": [
    "DEC-POS-002"
  ],
  "questions": [],
  "required_aspects": [
    "calculated",
    "preserved"
  ],
  "verification": "test",
  "risk": "high"
}

Система «Обратная связь — регион» MUST устанавливать deadline_at = registered_at + 10 календарных суток в UTC. Уточнение, маршрутизация и переназначение не изменяют этот момент. Интерфейс отображает его в Europe/Moscow с указанием зоны. Профиль расчёта: DEMO_STANDARD.

Scenario: SCN-POS-001 — Полный путь жалобы в одно ведомство

• GIVEN Жалоба принята от автора; тестовый маршрут LIGHT-01 v7 действует
• WHEN Подтвердить категорию; назначить маршрут; подготовить и согласовать ответ; опубликовать итог; открыть его автором
• THEN Дедлайн вычислен и отображён с часовым поясом

Подробности и данные: acceptance/scenarios/scn-pos-001.json.

Scenario: SCN-POS-009 — Переназначение и запоздавший ответ

• GIVEN Старое поручение dept-light; оператор переназначает на dept-roads
• WHEN Применить переназначение; отправить ответ по старой версии
• THEN Дедлайн не изменился

Подробности и данные: acceptance/scenarios/scn-pos-009.json.

Scenario: SCN-POS-017 — Дедлайн при переходе даты

• GIVEN Регистрация в23:30UTC; профиль расчёта сроков DEMO_STANDARD
• WHEN Вычислить срок; уточнить сведения; переназначить маршрут
• THEN +10 календарных суток UTC; отображение в МСК; Уточнение и переназначение не сдвигают срок

Подробности и данные: acceptance/scenarios/scn-pos-017.json.

Requirement: REQ-OPS-001 — Диагностика внешних отказов

{
  "id": "REQ-OPS-001",
  "level": "REQ",
  "status": "agreed",
  "owner": "product-owner",
  "parents": [
    "HLR-POS-008"
  ],
  "sources": [
    "DEC-POS-004"
  ],
  "questions": [],
  "required_aspects": [
    "observable"
  ],
  "verification": "test",
  "risk": "high"
}

Система MUST показывать сопровождению failed-уведомления с complaint_id, числом попыток, последним кодом ошибки, временем следующего действия и correlation_id без текста обращения. Сигнал появляется не позднее 60 секунд после исчерпания попыток. Повтор вручную требует роли support и сохраняет историю.

Scenario: SCN-POS-013 — Отказ внешнего канала

• GIVEN Итог опубликован; управляемые часы; провайдер возвращает503 четыре раза
• WHEN Пройти расписание повторов до исчерпания попыток
• THEN Сигнал ≤60 с с диагностическими полями без текста

Подробности и данные: acceptance/scenarios/scn-pos-013.json.

Requirement: REQ-NFR-001 — Производительность подтверждения приёма

{
  "id": "REQ-NFR-001",
  "level": "REQ",
  "status": "agreed",
  "owner": "product-owner",
  "parents": [
    "HLR-POS-008"
  ],
  "sources": [
    "docs/performance.md"
  ],
  "questions": [],
  "required_aspects": [
    "measured"
  ],
  "verification": "test",
  "risk": "high"
}

Система MUST подтверждать приём с p95 ≤ 2 с и долей 5xx < 0.1% при 100 запросах/с в течение 30 минут после 5 минут прогрева, на входах длиной до 3000 символов без вложений. Измерение: от отправки полного тела клиентом до получения полного подтверждения регистрации, без времени ввода пользователем; выборка содержит успешные запросы, ошибки считаются отдельно. Конфигурация стенда и генератора фиксируется в протоколе.

Scenario: SCN-POS-019 — Нагрузочная приёмка регистрации

• GIVEN Стенд и генератор описаны по docs/performance.md; чистые синтетические ключи
• WHEN 5 мин прогрева; 30 мин100 запросов/с; собрать времена и ошибки
• THEN p95≤2 с; 5xx<0.1%; среда и сырые замеры сохранены

Подробности и данные: acceptance/scenarios/scn-pos-019.json.