Пример: требования и план их дополнения

Вымышленный сервис обработки обращений. Пример использует подход комплекта ПОС — два уровня HLR/REQ, предметные области, вопросы и связь с проверками. Он не описывает фактические требования ПОС и не задаёт обязательных бизнес-правил для других клиентов.

Исходное состояние

У команды есть код, трекер и несколько API-тестов. Целостного описания нет. Для Пилота выбраны изменения регистрации и маршрутизации обращений. Аналитик Мария отвечает за карту требований, владелец продукта Олег — за продуктовые решения, тестировщик Ирина — за сценарии проверки. Агент готовит черновики и предлагает связи.

Команда выбирает Markdown рядом с кодом. В другом проекте такими источниками могли бы остаться действующая база знаний и система тест-кейсов.

Два уровня на одном примере

HLR-REG-001 — зарегистрировать обращение

• Цель: заявитель получает подтверждение, что обращение принято в обработку.
• Пользователь: авторизованный заявитель.
• Входит: проверка обязательных данных, регистрация, выдача номера.
• Не входит: выбор ведомства и подготовка ответа; это отдельные возможности.
• Результат и приёмка: при корректных данных создано одно обращение, заявитель видит номер; при некорректных данных — понятную причину отказа.
• Источник: решение Олега DEC-REG-01; статус: согласовано после предметного ревью.
• Владелец: Мария; связанные правила: REQ-REG-001, REQ-REG-002.

REQ-REG-001 — успешная регистрация

При отправке авторизованным заявителем формы с заполненными категорией и текстом система создаёт обращение в статусе «Зарегистрировано», присваивает уникальный номер и показывает этот номер заявителю. Допустимые категории определяются версией справочника, указанной в контракте регистрации.

REQ-REG-002 — отсутствует текст обращения

Если текст пуст или состоит только из пробелов, система не создаёт обращение и показывает у поля текста сообщение «Укажите текст обращения».

Для обеих спецификаций: родитель HLR-REG-001, источник DEC-REG-01, владелец Мария, статус согласовано. Правила длины текста, вложений и повторной отправки не следует домысливать из этих двух записей: они перечислены в карте как отдельные позиции для уточнения.

Связь с проверками

Ожидаемые результаты взяты из согласованных правил. Успех API-теста не подтверждает отображение сообщения в UI. Запись о тест-кейсе не означает, что он уже автоматизирован или выполнен.

Работа с найденным расхождением

Агент обнаружил, что два запроса регистрации иногда создают два обращения. Это наблюдение кода и тестового прогона, а не согласованное требование.

Вопрос Q-REG-01: как распознавать повторную отправку, в течение какого периода и какой результат возвращать? Олег принимает решение, Мария уточняет правило, Ирина — проверки. До ответа не выполняется зависимое изменение обработки повторов; независимая задача переименования пункта меню продолжается.

Срез полноты и недельный план

На предварительной карте выбранного потока команда выделила 20 применимых позиций «сценарий × аспект». Из них 12 описаны и подтверждены, 5 описаны частично, 3 не описаны: 12/20 = 60%. Ещё две позиции признаны неприменимыми с обоснованием и в знаменатель не входят. Область подготовки ответа пока не обследована и в этот показатель не включена.

На неделе подтвердили ещё три позиции: 15/20 = 75% по той же карте. Затем нашли четыре существенные позиции по повторам и таймерам: новая карта даёт 15/24 = 62,5%. Это расширение известной области, а не потеря уже сделанной работы. Открытый вопрос о повторах виден отдельно от процента.

Для каждой строки в рабочем плане добавляются конкретные сроки и доступность участников. Полное описание продукта не требуется для старта Пилота. Его наполнение продолжается по реестру артефактов и недельному журналу.