📜Бизнес-функциональные требования, когда и зачем

БФТ - договор на языке пользователей о том, как будет работать система: сценарии, CJM, блок-схема процесса, понятные границы. Без технических деталей - они пойдут в ТЗ.

🎯 Когда требуется БФТ

Мы эксплуатируем внутренние сервисы. БФТ готовим тогда, когда меняется опыт пользователя или его сценарии, либо появляется новый путь в системе. Цель - договориться на языке пользователей о новом поведении системы, границах и критериях приемки.

🚦Триггеры для БФТ:

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

🧩 Артефакты БФТ:

CJM ключевых ролей и точек контакта;
блок-схема процесса (AS-IS/TO-BE) с границами и исключениями;
user stories с примерами и ожидаемым результатом;
список исключений и результат на языке пользователей.

🛠️Когда без БФТ можно обойтись

минорные изменения, где смысл и риск очевидны: новая колонка в отчете, переименование кнопки, сортировка по умолчанию, обязательность поля без изменения логики процесса. Здесь достаточно RFC с описанием и ожидаемым результатом.
изменения, не затрагивающие пользовательский опыт: изменение API, индексы в таблицах, оптимизация запросов или обновление вендора.