BRD, FRD и SRS: какой документ когда нужен

Заказчик подписывает документ и считает, что зафиксировал, каким будет продукт. Команда читает тот же документ и видит в нём цели: что мы вообще хотим изменить. Через месяц оба произносят фразы «это же было в требованиях» и «этого там никогда не было» — про один и тот же файл.

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

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

Путаница начинается со слова «бизнес-требования»

Самый частый ответ, который я слышу: «BRD — это бизнес-требования». Звучит логично, буквы совпадают. И это подмена, из которой растёт всё остальное.

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

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

Если на собеседовании перевести разговор с файлов на типы требований и обратно, разница между кандидатами становится слышна сразу. Один пересказывает три аббревиатуры. Второй объясняет, кто что читает.

Что говорит стандарт — и чего он не говорит

Здесь начинается неожиданная часть, до которой обычно не доходит разговор.

Международный стандарт по работе с требованиями — ISO/IEC/IEEE 29148

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

Замечаешь, чего в этом списке нет? BRD и FRD. Их там нет вовсе.

Из трёх аббревиатур, вокруг которых идёт спор, стандарту известна одна — SRS: её структура описана в разделе 8.5. А вот определение стандарт даёт соседнему документу, системной спецификации требований SyRS: структурированный набор требований — функций, характеристик производительности, проектных ограничений и других атрибутов — к системе, её операционным средам и внешним интерфейсам. BRD и FRD — это отраслевая практика: названия, о которых договорились компании и консалтинг, а не термины из свода.

Отсюда практический вывод, который стоит унести с собой. Спрашивать «а как правильно по стандарту оформлять BRD» бессмысленно — правильного ответа не существует. В каждой компании BRD называется чуть разное, и на новом проекте первым делом стоит спросить, что здесь понимают под этим словом, а не предполагать.

Кстати, про «правильный шаблон SRS». Его часто берут из IEEE 830 — документа 1998 года, по которому до сих пор учат на курсах. На сайте IEEE у этого стандарта статус Superseded: он заменён на ISO/IEC/IEEE 29148 ещё в редакции 2011 года. Шаблон оттуда не стал плохим, но ссылаться на него как на действующий стандарт — заметная ошибка.

Три документа по пяти вопросам

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

BRD

Кто пишет: бизнес-аналитик вместе с заказчиком или спонсором изменения. Кто читает: те, кто даёт деньги и принимает решение «делаем или нет». Какое решение закрывает: стоит ли вообще это затевать и как мы поймём, что получилось. Когда появляется: раньше всех, до выбора решения. Если в документе уже названа система, вы пишете не BRD. Чего нет без него: критерия, по которому через полгода можно сказать, что проект удался. Без BRD успех определяется настроением заказчика на демо, и спорить с этим нечем.

FRD

Кто пишет: аналитик, уже зная, какое решение выбрано. Кто читает: команда разработки и тестирования, иногда — заказчик, который хочет проверить, что его поняли. Какое решение закрывает: что система должна делать, чтобы цели из BRD были достигнуты. Когда появляется: после решения о решении, до оценки трудозатрат. Чего нет без него: границы объёма работ. Оценка без FRD — это оценка того, что каждый участник встречи вообразил себе сам, и расхождение выяснится на приёмке.

SRS

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

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

Два способа испортить всё это, которые я вижу чаще всего

Документы разошлись. Это происходит не из-за лени. У документов разные читатели и разный темп жизни: верхняя часть меняется на встрече с заказчиком, детальная — внутри спринта. Синхронизировать их не обязан никто, пока не наступит момент сверки. И тогда всплывает настоящая цена — не переписывание, а выравнивание: нужно заново выяснить, какая из версий правда, и сделать это может только тот, кто помнит оба обсуждения. Эта работа не видна в плане, не попадает ни в чью оценку и съедает дни. Лечится она не дисциплиной, а связями между документами — о том, как не терять требование по дороге, есть отдельный разбор: матрица трассировки требований.

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

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

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

Какой из них нужен в твоей ситуации

Выбирать стоит не по стадии проекта, а по вопросу, на который прямо сейчас никто не может ответить.

Не понятно, зачем мы это делаем и как поймём, что получилось, — нужен BRD, даже если он уместится на страницу. Понятно зачем, но каждый представляет объём по-своему — нужен FRD. Объём понятен, а тестировщик и разработчик ходят к тебе с одними и теми же вопросами — нужен SRS. Все три вопроса закрыты, а документа нет ни одного — возможно, он и не нужен: команда из четырёх человек, которая разговаривает каждый день, не обязана писать три спецификации.

Так этот ответ и звучит на собеседовании убедительно: не «полагается вести три документа», а «вот вопрос, который не был закрыт, поэтому мы завели вот это».

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

В нашем банке вопросов с реальных собеседований тема этих трёх документов встречается шесть раз, и четыре из этих вопросов размечены как junior. Это стоит прочитать буквально: документы спрашивают на входе в профессию. Не «когда дорастёшь до Senior», а на первом же интервью, где тебя спрашивают про артефакты.

Слабый ответ — перечислить расшифровки аббревиатур. Он формально верен и заканчивается ничем: собеседующий кивает и идёт дальше по списку.

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

Последнее отличает практика от пересказа сильнее, чем любые подробности про структуру разделов.