Что выводится из сценария использования: требования, тесты и бизнес-правила

28 сентября 2026 · 12 минут чтения

Как собирать требования от задач пользователя, выводить из сценария функциональные требования и тесты и хранить бизнес-правила отдельно — на примере записи на встречу.

Сценарий использования стоит в центре постановки. Из его шагов получаются функциональные требования, из ветвей и гарантий — тесты, а правила, от которых зависит поведение, живут рядом в отдельном списке.

Эта статья — практическое продолжение двух материалов. В статье «Как превратить бизнес-требования в функциональные» (черновик) путь идёт от бизнес-цели к пользовательским сценариям. В статье «Use case — новый исходник программы» я доказываю, что в агентной разработке сценарий становится главным редактируемым документом. Здесь — что с ним делать дальше: как получить из сценария требования и тесты и где держать бизнес-правила.

Все три приёма описаны у Карла Вигерса и Джой Битти в книге «Разработка требований к программному обеспечению». Я показываю их на одной реальной функции — записи на онлайн-встречу на моём сайте. Её спецификация, конфигурация и тесты лежат в репозитории сайта рядом с кодом.

Что понадобится:

• одна пользовательская цель, которую вы собираетесь реализовать или менять;
• люди, которые знают, как она должна работать, — или вы сами в этой роли;
• репозиторий, где рядом с кодом можно хранить текстовые документы.

Шаг 1. Спросить о задачах, а не о функциях

Вигерс и Битти различают два способа собирать требования. Можно спросить, какие функции нужны в системе, и получить список. Можно спросить, какие задачи люди решают с её помощью, и получить сценарии. Первый способ авторы называют ориентированным на продукт, второй — ориентированным на использование, и советуют второй.

Для записи на встречу список функций выглядит так: календарь свободного времени, выбор длительности, форма с именем и email, приглашение в календарь, уведомление в Telegram. Каждый пункт разумен. Но в списке нет ответа на вопросы, из-за которых такие функции ломаются в работе: что если слот заняли, пока посетитель заполнял форму? Что если посетитель нажал кнопку дважды? Можно ли перенести встречу, не создав вторую?

Список задач выглядит иначе:

Из каждой строки получается сценарий. А вопросы о занятом слоте и повторном нажатии появляются сами, когда вы проходите сценарий по шагам и спрашиваете: «А что, если здесь пойдёт иначе?»

Второй эффект — лишнее видно сразу. Функцию, которая не служит ни одной строке таблицы, либо обосновывают новой задачей, либо не делают. Для агента это особенно полезно: он охотно добавит «удобную» возможность, о которой никто не просил.

Результат шага: таблица участников и их целей. Её не нужно делать полной с первого раза, важно, чтобы каждая цель была результатом для участника, а не действием в интерфейсе.

Шаг 2. Написать сценарий для выбранной цели

Как писать сам сценарий — основной путь, ветви, гарантии — подробно разобрано в статье «Use cases, user stories и BDD для AI-агента» (черновик). Здесь нужен готовый результат. Шаблон паспорта сценария с полным набором полей — UC-XXX.md в моём шаблоне Memory Bank. Для цели «Записаться на встречу» сценарий выглядит так (сокращённая переработка реальной спецификации):

## UC-BOOK-01. Записаться на онлайн-встречу

Основной участник: посетитель сайта
Вспомогательные: Google Calendar, Яндекс Телемост, Telegram

Гарантия успеха:
G1. В календаре создано одно событие с уникальной комнатой Телемоста.
G2. Посетитель видит подтверждение и ссылку для отмены или переноса.

Минимальная гарантия:
G3. Посетитель не видит сообщения об успехе, если событие не создано.
G4. Повтор того же запроса не создаёт вторую встречу.

Основной сценарий:
1. Система показывает свободные слоты в часовом поясе посетителя.
2. Посетитель выбирает длительность и время.
3. Посетитель указывает имя, email, тему и даёт согласие.
4. Система повторно проверяет слот и создаёт событие.
5. Система показывает подтверждение и уведомляет владельца календаря.

Расширения:
2a. Посетитель меняет часовой пояс: меняется только отображение.
4a. Слот заняли, пока посетитель заполнял форму: система сообщает
    об этом и возвращает к выбору слота.
4b. Календарь недоступен: событие не создаётся, посетитель видит ошибку.
5a. Telegram недоступен: запись успешна, уведомление уйдёт позже.

Правила: BR-01 … BR-06.

Обратите внимание на последнюю строку. В сценарии нет ни часов работы, ни длительностей, ни горизонта записи. Шаг 1 говорит «свободные слоты», а что считается свободным слотом — определяют правила. Почему так, — в шаге 5.

Шаг 3. Вывести функциональные требования

Функциональное требование описывает, что система должна делать. Вигерс и Битти рассматривают сценарий как источник, из которого аналитик выводит функциональные требования: сам сценарий описывает взаимодействие, а требования — поведение системы, которое это взаимодействие обеспечивает.

Практическое правило вывода:

• каждый шаг, где действует система, даёт одно или несколько требований;
• каждое расширение даёт требование к поведению в особой ситуации;
• каждая гарантия даёт требование, которое должно выполняться при любом исходе.

Нужно ли вести такой список отдельно, если есть сценарий? Моё мнение: для одной небольшой функции — не обязательно, агенту хватает сценария и правил. Список становится полезен, когда одно и то же поведение нужно нескольким сценариям. FR-1 работает и для записи, и для переноса встречи; если описать его внутри каждого сценария, описания со временем разойдутся.

Выводить требования стоит и тогда, когда вы их не храните. Проход по таблице выше — быстрый способ найти шаг, на котором система что-то делает, но в сценарии не сказано, что именно.

Результат шага: требования, у каждого из которых есть источник в сценарии. Требование без источника — сигнал: либо пропущен шаг или ветвь, либо требование лишнее.

Шаг 4. Вывести тесты

Вигерс и Битти предлагают выводить тесты из тех же сценариев, что и требования, — и сравнивать одно с другим. Если по сценарию получился тест, для которого нет требования, пропущено требование. Если есть требование, которое не проверяет ни один тест, пропущен тест или требование лишнее.

Правило вывода тестов:

• основной сценарий даёт один сквозной тест успешного пути;
• каждое расширение — минимум один тест;
• каждая минимальная гарантия — тест, который создаёт сбой и проверяет, что гарантия выдержала;
• каждое правило — тесты на границах: последний допустимый и первый недопустимый случай.

Вот как это выглядит на реальных тестах записи на встречу. Названия тестов взяты из репозитория, связь со сценарием я провёл вручную:

Таблица сразу показывает и пробелы. Для расширения 4b — календарь недоступен — отдельного теста в этом списке нет. Поведение описано в спецификации, но закреплено слабее остального. Именно такие места агент при следующей правке может изменить, не заметив.

Честное ограничение: в моём репозитории тесты не ссылаются на идентификаторы сценария, связь пришлось восстанавливать по названиям. Если добавить идентификатор в название теста — 4a: serializes overlapping requests… — проверку покрытия можно отдать скрипту или агенту: найти ветви без тестов и тесты без ветвей.

Результат шага: список тестов, где у каждого есть источник в сценарии или правиле, и список ветвей, для которых теста пока нет.

Шаг 5. Вынести бизнес-правила отдельно

Бизнес-правило — ограничение предметной области, которое определяет поведение системы: когда можно записаться, сколько длится встреча, что считать дублем. Вигерс и Битти советуют хранить правила отдельно от сценариев и требований, а в сценариях на них ссылаться.

Причин три, и все три видны на записи на встречу.

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

Правило меняется по другим причинам и чаще. За первые три недели после запуска я поменял четыре правила: длительность 45 минут заменил на 60, горизонт записи сократил с 30 до 14 дней, шаг начала встречи увеличил с 15 минут до часа, добавил закрытые праздники. Шаги сценария записи от этого не изменились. Если правила перемешаны со сценарием, каждая такая правка — повод трогать документ, в котором легко задеть лишнее.

Правилу нужна точность на границах. Вот как правило «не день в день» сформулировано в спецификации:

Записаться в текущий московский календарный день нельзя, даже если до слота остаётся больше четырёх часов. Слоты следующего дня доступны сразу после московской полуночи: это календарное ограничение, а не плавающий интервал в 24 часа.

Короткая версия «запись минимум за сутки» допускает два разных поведения. Агент выбрал бы одно из них и написал бы для него аккуратные тесты. Отдельно записанное правило оставляет место для такой точности, в шаге сценария её обычно не пишут.

Формат каталога правил может быть простым:

В коде правилу тоже нужно одно место. На сайте почти все эти правила — значения в файле конфигурации config/booking.mjs: рабочие дни, длительности, шаг, буфер, горизонт. Сменить значение правила — значит поправить строку конфигурации и тест на его границе; сценарий при этом не трогается. Так отдельное хранение правил в документе продолжается в отдельном хранении в коде.

Результат шага: каталог правил с идентификаторами, ссылки на них из сценариев и одно место в коде для каждого правила.

Шаг 6. Передать это агенту и проверить

Агенту я передаю не одно из этих представлений, а все вместе:

• сценарий с идентификаторами шагов, ветвей и гарантий;
• каталог правил;
• функциональные требования, если их несколько сценариев используют общими;
• команды запуска тестов.

До того как агент начнёт писать код, полезно попросить его о сверке:

Результат этой сверки проверяется глазами: агент должен назвать конкретные ветви и тесты, а не общие рекомендации. После реализации та же сверка повторяется — и её результатом должен стать пустой список пробелов или список, который вы сознательно оставили на потом.

Работа закончена, когда цепочку можно пройти в обе стороны. От ветви сценария — к требованию и тесту. От упавшего теста — к ветви или правилу, которые он защищает.

Где это не работает

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

Нефункциональные требования — производительность, защита данных, доступность — из сценария не выводятся. Их записывают отдельно, и тесты для них проектируют отдельно.

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

Термины

• Сценарий использования (use case) — описание того, как участник достигает цели с помощью системы: основной путь, ветви и гарантии.
• Расширение — ветвь сценария от конкретного шага: другой вариант, ошибка или отмена.
• Гарантия — то, что система обеспечивает после сценария: при успехе или при любом исходе.
• Функциональное требование (FR) — описание того, что система должна делать; здесь — поведение, выведенное из шагов, ветвей и гарантий сценария.
• Бизнес-правило (BR) — ограничение предметной области, которое определяет поведение системы и может использоваться несколькими сценариями.
• Трассировка — связь между сценарием, требованием, правилом и тестом, по которой можно пройти в обе стороны.
• Идемпотентность — свойство операции: повтор того же запроса даёт тот же результат и не создаёт дубль.
• Coding-агент — AI-инструмент, который сам читает репозиторий, меняет файлы и запускает проверки.

Источники

1. Карл Вигерс, Джой Битти — «Разработка требований к программному обеспечению. Практические приёмы сбора требований и управления ими при разработке программных продуктов», 3-е изд., дополненное. БХВ, 2025 — подход, ориентированный на использование, вывод функциональных требований и тестов из сценариев, отдельное хранение бизнес-правил.
2. Анастасия Солдатова — «Use Case: как описывать эффективные сценарии использования. Part 1», Хабр, 2025 — состав сценария и его ограничения, включая нефункциональные требования.
3. Академия MediaSoft — «Use case: что это, из чего состоит и как избежать ошибок при написании», 2024 — шаблон сценария и типичные ошибки при его написании.
4. Шаблон паспорта сценария UC-XXX.md из репозитория dapi/memory-bank — поля паспорта и идентификаторы для трассировки.
5. Спецификация записи на встречу на pismenny.ru, конфигурация и тесты в репозитории сайта — источник сквозного примера: сценарий, правила доступности и названия тестов.
6. «Use case — новый исходник программы», «Как превратить бизнес-требования в функциональные» и «Use cases, user stories и BDD для AI-агента» — соседние материалы: зачем сценарий в центре, откуда он берётся и как его писать.

Автор: Данил Письменный · Дата: 28 сентября 2026