Чем бизнес-требования отличаются от функциональных

На ревью требований спорят не о сути. Спорят о том, куда что положить.

Аналитик пишет: «сократить время обработки заявки с трёх дней до четырёх часов». Руководитель проекта вычёркивает и пишет своё: «система автоматически подтягивает данные клиента из профиля». Обе строки верные. Обе про один и тот же проект. Только первая — про результат для бизнеса, а вторая — про поведение системы, и стоят они на разных этажах.

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

Это весь ответ. Дальше — два теста, которые разводят уровни за минуту, и то, что ломается, когда уровни смешаны в одном списке.

Четыре уровня, а спорят всегда про два

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

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

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

Функциональное требование — не «более подробное» бизнес-требование. Это ответ на другой вопрос, заданный другому человеку.

Подробнее про сам свод знаний и его устройство — в отдельном разборе: что такое BABOK.

Бизнес-требование: тест на смену решения

Первый тест занимает секунды. Замените решение целиком и посмотрите, что из написанного выживет.

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

Второй тест ещё короче. Уберите из формулировки всё, что говорит про систему. Осталось что-то осмысленное для бизнеса — уровень верхний. Не осталось ничего — уровень нижний. «Отправлять письмо» без системы не значит ничего. «Обрабатывать заявку за четыре часа» значит всё.

Отсюда следствие, которое обычно и упускают. Пока бизнес-требование не сформулировано, функциональное нечем обосновать: непонятно, почему выбрано именно такое поведение и что будет считаться успехом. Не «документ не по форме» — просто нечем ответить на вопрос «а зачем».

Функциональное: поведение, а не устройство

Функциональное требование описывает, что решение делает: какую операцию, при каком условии, с каким результатом. «Система формирует счёт при закрытии заказа». «Пользователь может отменить заявку до подтверждения оплаты». Проверяемо: результат либо есть, либо нет.

Здесь своя ловушка, и в неё съезжают чаще, чем в путаницу с бизнес-уровнем. Формулировка незаметно переползает с поведения на устройство. «Модуль валидации обращается к справочнику» — это уже архитектура, а не требование. Разница не в педантизме: пока написано поведение, реализацию можно менять, не переписывая требования. Как только написано устройство, любая замена библиотеки тянет за собой правку документа.

Простой признак: если из формулировки понятно, как это устроено внутри, а не что увидит пользователь или смежная система, — вы описали решение, а не требование к нему. Записывают функциональные требования по-разному — короткой историей с критериями приёмки или сценарием со всеми ветками; чем эти формы отличаются, — в статье User Story и Use Case: чем отличаются и что писать.

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

Кто выдвигает и что переживает запуск

Разводить уровни удобнее не по словам, а по двум вопросам: кто источник требования и что с ним станет после запуска.

Последняя строка чаще всего и ломает реестр. Переходные требования выглядят как обычные, лежат в общем списке — и остаются там навсегда. Через год никто не помнит, что «загрузить остатки из старой системы» было нужно ровно один раз.

Проверка границы: пройти по связям

Формулировки врут, связи — нет. Поэтому уровень проверяется трассировкой, а не редактурой.

Стандарт ISO/IEC/IEEE 29148 прямо перечисляет, куда требование обязано трассироваться: вниз — к требованиям более низкого уровня, к архитектуре, к элементам системы, которые его реализуют, и к сущностям верификации, которые его проверяют; вверх — к родительским требованиям, из которых оно выведено, или к потребностям стейкхолдеров. Двустороннюю связь и стоит проверять.

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

Обратный проход не менее полезен. Бизнес-требование, у которого нет ни одного функционального потомка, либо не реализуется вовсе, либо реализуется тем, о чём письменно никто не договаривался.

В BABOK у связей есть свои имена. Их ровно четыре: derive, depends, satisfy и validate. Для нашей задачи важен первый: функциональное требование выводится из бизнес-требования, а не наоборот. Как вести такие связи, чтобы они не превратились в мёртвую таблицу, — отдельный разбор: матрица трассировки требований.

Три ошибки, которые видно в документе

Оба уровня в одном списке. Соседние строки: «сократить время обработки заявки вдвое» и «кнопка сохранения блокируется, пока не заполнено поле ИНН». Пока они лежат рядом, смена цели ломает половину текста, и никто не понимает, что именно переписывать. Лечится не редактурой, а разнесением по разделам.

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

Цель поменяли, функции остались. Самая дорогая из трёх, потому что незаметная. Команда продолжает делать то, что больше не нужно, и узнаёт об этом на демо. Односторонняя трассировка эту ошибку не ловит: связь вниз есть, а сигнала «родитель изменился» нет.

Разные типы требований спокойно живут в одном документе — это нормально и так обычно и бывает. Ненормально, когда они лежат в одном списке вперемешку. Про то, какой документ какой вопрос закрывает, есть отдельный разбор: BRD, FRD и SRS.

Как это звучит на собеседовании

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

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

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