Business Requirements Document (BRD, документ бизнес-требований)

В 2000 году ФБР заказало систему Virtual Case File — электронное дело, которое должно было заменить бумажный документооборот следователей. Через пять лет и более чем 170 миллионов долларов проект закрыли, так и не запустив. Расследование журнала IEEE Spectrum («Who Killed the Virtual Case File?», Гарри Голдстейн, сентябрь 2005) показало картину, знакомую любому аналитику: требования менялись на ходу, их никто не связывал с целями ведомства, а при приёмке выяснилось, что в продукте есть функции, на которые нет требований, и нет функций, которые требовались. Из 59 первых найденных дефектов 19 были прямыми изменениями требований со стороны заказчика. Документ бизнес-требований (Business Requirements Document, BRD) существует ровно для того, чтобы такой разговор случился в начале проекта, а не в конце: зачем компании изменение, по каким показателям будет понятно, что оно удалось, что входит в решение и — не менее важно — что в него не входит.

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

BRD — это договорённость о цели и границах до того, как начались споры о функциях. Всё, что не записано в «вне рамок», рано или поздно будет предъявлено как «забытое».

Происхождение и исследовательская база документа бизнес-требований (BRD)

У документа бизнес-требований нет одного автора: он сложился как практика инженерии требований и бизнес-анализа и затем был закреплён в нескольких сводах знаний и стандартах. Это важно понимать сразу — термин «BRD» в разных компаниях наполняют по-разному, и единственный способ не запутаться — опереться на первоисточники.

Свод знаний BABOK: бизнес-требования как отдельный класс

Международный институт бизнес-анализа (IIBA) в третьей версии своего свода знаний BABOK Guide (2015) ввёл классификацию требований из четырёх классов. Бизнес-требования — формулировки целей, задач и результатов, которые описывают, почему инициируется изменение; они могут относиться ко всей организации, к направлению бизнеса или к отдельной инициативе. Требования заинтересованных сторон описывают потребности конкретных групп, которые нужно удовлетворить, чтобы достичь бизнес-требований. Требования к решению описывают возможности и качества решения и делятся на функциональные (что решение делает) и нефункциональные (насколько хорошо: производительность, безопасность, удобство). Переходные требования описывают то, что нужно для перехода из текущего состояния в будущее и что перестаёт быть нужным после перехода — миграция данных, обучение, параллельная работа систем. Из этой классификации следует главное правило BRD: он содержит верхний класс и опирается на него, а детализация решения уходит ниже — в функциональные требования и спецификацию.

Карл Вигерс: три уровня требований и документ «Видение и границы»

Карл Вигерс и Джой Битти в книге «Software Requirements» (3-е издание, Microsoft Press, 2013; русское издание — «Разработка требований к программному обеспечению») описывают три уровня требований: бизнес-требования, пользовательские требования и функциональные требования, а нефункциональные выносят отдельно. Бизнес-требования у Вигерса фиксируются в документе «Видение и границы» (Vision and Scope). Его шаблон показывает, из чего на практике состоит BRD: предпосылки и бизнес-возможность, бизнес-цели и показатели успеха, потребности рынка или клиентов, бизнес-риски, видение решения с основными функциями, допущения и зависимости, границы и ограничения — что входит в первый релиз, что в последующие и что не будет сделано вовсе, — а также профили заинтересованных сторон и приоритеты проекта. Именно Вигерс настаивает, что бизнес-цель должна быть измеримой: без показателя успеха нельзя ни расставить приоритеты требований, ни принять результат.

ISO/IEC/IEEE 29148: спецификация бизнес-требований как часть семейства документов

Международный стандарт ISO/IEC/IEEE 29148 (первая редакция — 2011, действующая — 2018) «Системная и программная инженерия — процессы жизненного цикла — инженерия требований» определяет семейство документов требований, каждый для своей аудитории и своего уровня детализации: спецификация бизнес-требований (Business Requirements Specification, BRS), спецификация требований заинтересованных сторон (StRS), концепция эксплуатации (OpsCon), спецификация требований к системе (SyRS) и спецификация требований к программному обеспечению (SRS). BRS в стандарте — структурированный набор требований бизнеса или миссии: определение проблемы или возможности, концепции и обязательные условия решения, связь с внешней средой; в него входят цели, границы, критерии успеха, ограничения и ожидаемые результаты. По сути это и есть BRD, только в строгой стандартизованной форме. Стандарт также задаёт характеристики хорошего требования — необходимость, однозначность, полнота, единичность, выполнимость, проверяемость, корректность, соответствие — и требование трассируемости: каждое требование нижнего уровня должно вести к требованию верхнего.

Российская линия: стадии ГОСТ 34 и концепция автоматизированной системы

В российской практике документа с названием BRD в стандартах нет, но его функцию выполняют ранние стадии создания автоматизированной системы по ГОСТ 34.601-90: «Формирование требований к АС» (обследование объекта, обоснование необходимости системы, формирование требований пользователя) и «Разработка концепции АС». Отчёт об обследовании и концепция отвечают на те же вопросы, что и BRD: какие проблемы решаем, какие цели и показатели, какие границы автоматизации. Техническое задание по ГОСТ 34.602-2020 — следующий шаг, ближе к спецификации требований, чем к BRD. Поэтому в российских компаниях BRD часто называют «бизнес-требованиями», «концепцией» или «запросом бизнеса» — суть от этого не меняется.

Эмпирическая база: почему требования решают судьбу проекта

Институт управления проектами (PMI) в исследовании Pulse of the Profession «Requirements Management: A Core Competency for Project and Program Success» (2014) установил, что 47 % проектов, не достигших своих целей, провалились из-за неточного управления требованиями, а 5,1 % каждого доллара, потраченного на проекты, теряется из-за плохого управления требованиями — 51 миллион долларов на каждый миллиард. Те же организации, которые выстроили управление требованиями как процесс, показывают заметно лучшие результаты. Отчёт Счётной палаты США GAO-14-694 (2014) о провальном запуске портала Healthcare.gov зафиксировал, что задания подрядчикам выдавались, когда ключевые требования оставались неизвестными — сколько штатов и сколько пользователей будет обслуживать система, — а основной причиной роста затрат и сдвига сроков стали постоянно меняющиеся требования.

Ключевые идеи и принципы документа бизнес-требований (BRD)

Документ бизнес-требований отвечает на «зачем» и «что должно стать возможным». Всё, что отвечает на «как», — уже следующий уровень требований.

Принцип: бизнес-цель измерима

Цель «повысить удобство для клиентов» в BRD бесполезна: её нельзя ни проверить, ни использовать для выбора между требованиями. Измеримая бизнес-цель состоит из четырёх элементов: показатель (что измеряем и в каких единицах), текущее значение (база, от которой меряем), целевое значение и срок. «Сократить среднее время оформления заказа с 12 до 5 минут к 1 марта» — цель; «улучшить процесс заказа» — пожелание. Для формулировки удобно пользоваться методом SMART: конкретность, измеримость, достижимость, значимость и ограниченность во времени — ровно те свойства, без которых бизнес-цель в BRD не работает.

Принцип: границы задаются в обе стороны

Раздел границ (scope) перечисляет, какие процессы, подразделения, данные и функции меняет проект, — и отдельно, явно, что в него не входит. Второй список важнее первого: именно о невключённом спорят на приёмке. Хороший пример — реальный BRD Европейского управления по ценным бумагам и рынкам ESMA для системы обмена данными о заявках OBOOK (2022): в разделе «Out of scope» прямо записано, что система не будет проверять содержимое файлов по XSD-схеме и не будет их обрабатывать — только передавать между национальными регуляторами. Одна такая фраза снимает целый класс будущих претензий.

Принцип: требования бизнеса, а не решения

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

Принцип: трассируемость к цели

Каждое требование в BRD должно отвечать на вопрос «какую цель оно обслуживает». Требование без цели — кандидат на удаление или признак того, что пропущена цель. Цель без требований — признак того, что не продумано, за счёт чего она будет достигнута. Трассируемость, которую ISO/IEC/IEEE 29148 требует для всего семейства документов, начинается именно здесь: дальше каждое функциональное требование ссылается на бизнес-требование, а каждый тест — на функциональное.

Принцип: приоритет по MoSCoW

Все требования важны только до первого конфликта сроков и бюджета. Метод MoSCoW (Must — обязательно, Should — желательно, Could — можно, Won't — не в этот раз), предложенный Даем Клеггом и закреплённый в методологии DSDM, делит требования на четыре группы. Must — то, без чего решение не имеет смысла для бизнеса; Won't — то, что сознательно отложено и тоже должно быть записано, чтобы не возвращаться к нему на каждом совещании.

Принцип: заинтересованные стороны и источник требования

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

Принцип: ограничения и допущения отделены от требований

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

Принцип: BRD — живой документ с версиями

Требования меняются, и это нормально; ненормально, когда они меняются незаметно. BRD ведут с номером версии, датой и списком изменений, а каждое изменение согласуют с тем, кто утверждал предыдущую версию. Учебный шаблон Enterprise Project Methodology прямо называет BRD «прогрессивным документом»: он фиксирует то, что известно сейчас, и уточняется по ходу проекта.

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

Сведя BABOK, шаблон Вигерса и ISO/IEC/IEEE 29148, получаем рабочую структуру BRD:

1. Краткое резюме: проблема, предлагаемое изменение, ожидаемый эффект.

2. Предпосылки и бизнес-возможность: текущее состояние, боли, причины начать сейчас.

3. Бизнес-цели и показатели успеха.

4. Границы: входит в решение, не входит в решение, этапы.

5. Заинтересованные стороны и их потребности.

6. Текущий и целевой процесс (кратко, со ссылкой на модели процессов).

7. Бизнес-требования с идентификаторами, приоритетом и источником.

8. Бизнес-правила, которые должно соблюдать решение.

9. Ограничения, допущения, зависимости, риски.

10. Оценка затрат и выгод.

11. Критерии приёмки и порядок согласования, глоссарий, подписи.

Описание текущего и будущего процесса удобно строить по методике сравнения As-Is и To-Be процессов, а оценку эффекта — по анализу рентабельности инвестиций.

Ограничения, слепые зоны и критика документа бизнес-требований (BRD)

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

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

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

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

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

Чем BRD не является. Это не устав проекта: устав (Project Charter) даёт полномочия руководителю и фиксирует проект как управленческий объект, а BRD описывает потребность бизнеса. Это не бизнес-кейс: бизнес-кейс обосновывает, стоит ли вкладываться, а BRD — что именно нужно получить. На практике документы ссылаются друг на друга, но не подменяют друг друга.

Типовые ошибки при составлении документа бизнес-требований

Ошибка 1: цели без показателей.

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

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

Ошибка 2: не записано, что вне рамок.

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

Как избежать: заведите отдельный раздел «Не входит в решение» и согласуйте его так же явно, как основной. Перечислите в нём всё, о чём хотя бы раз заходила речь на встречах.

Ошибка 3: функциональные детали вместо бизнес-требований.

BRD заполняется описаниями экранов и полей. Спонсор не может его прочитать, а важные бизнес-потребности теряются среди деталей.

Как избежать: проверяйте каждое требование вопросом «это нужно бизнесу или это способ сделать?». Способы переносите в функциональные требования и сценарии использования.

Ошибка 4: требования без связи с целями.

В документ попадают пожелания отдельных сотрудников, которые не ведут ни к одной цели, а бюджет уходит на них. Это прямой путь к ситуации Virtual Case File: функции, на которые нет требований, и требования, которых нет в продукте.

Как избежать: у каждого требования должна быть ссылка на цель. Требование без цели либо вычеркните, либо найдите пропущенную цель и согласуйте её.

Ошибка 5: всё «обязательно».

Все требования помечены как критичные. При первом же сдвиге сроков команда режет не то, что можно отложить, а то, что проще всего вырезать.

Как избежать: используйте MoSCoW и ограничивайте долю Must — заметно меньше половины требований. Запишите Won't, чтобы отложенное не всплывало на каждом совещании.

Ошибка 6: нет владельца требования.

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

Как избежать: у каждого требования — источник (роль или подразделение), у документа — утверждающие с подписями и датой.

Ошибка 7: допущения выданы за факты.

«Данные из склада приходят в реальном времени» записано как данность, хотя никто этого не проверял. Когда допущение не подтверждается, переделывать приходится и требования, и решение.

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

Главное, что нужно знать о документе бизнес-требований (BRD)

• BRD фиксирует, зачем компании изменение, как будет измерен успех, что входит и что не входит в решение, — до обсуждения функций.

• Бизнес-цель измерима: показатель, текущее значение, целевое значение, срок.

• Границы задаются в обе стороны; раздел «Не входит в решение» защищает проект от бесконечного расширения.

• Каждое бизнес-требование трассируется к цели, у каждой цели есть требования, у каждого требования — источник и приоритет.

• BRD — верхний уровень семейства документов: дальше идут функциональные требования, сценарии использования и спецификация требований к ПО (по ISO/IEC/IEEE 29148 — BRS → StRS → SyRS → SRS).

• Почти половина проектов, не достигших целей, проваливается из-за управления требованиями (PMI, 2014) — BRD самый дешёвый способ снизить этот риск.

Хороший BRD можно проверить за минуту: у каждой цели есть число и срок, у границ есть список «вне рамок», у каждого требования есть цель.

План внедрения документа бизнес-требований (BRD)

Неделя 1. Предпосылки и цели. Проведите интервью со спонсором и ключевыми заинтересованными сторонами: какая проблема, сколько она стоит, почему решать сейчас. Сформулируйте 2–5 бизнес-целей и для каждой найдите показатель и текущее значение. Если значения нет — запланируйте измерение.

Неделя 2. Границы и заинтересованные стороны. Составьте списки «входит» и «не входит в решение», ограничения и допущения. Постройте карту заинтересованных сторон и определите, кто утверждает документ. Опишите текущий процесс и целевую картину на уровне шагов.

Неделя 3. Бизнес-требования. Выпишите требования с идентификаторами, привяжите каждое к цели, задайте приоритет MoSCoW и источник. Проверьте трассируемость: нет требований без цели и целей без требований. Добавьте бизнес-правила и критерии приёмки.

Неделя 4. Проверка и согласование. Проведите разбор документа с заинтересованными сторонами: читают ли они цели и границы одинаково. Закройте или зафиксируйте открытые вопросы, утвердите версию 1.0, договоритесь о порядке изменений. После согласования BRD передаётся на детализацию — в функциональные требования и спецификацию.

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

Как реализовать этот план с помощью фрейма «Документ бизнес-требований (BRD)» в OrgDevTools

Фрейм «Документ бизнес-требований (BRD)» — бесплатный тренажёр на странице методики: он проводит по логике BRD и проверяет его качество на ходу. Над вкладками всегда видна строка из пяти проверок, которые загораются зелёным по мере заполнения: цели измеримы, задано «что входит», задано «что не входит», каждое требование ведёт к цели, у каждой цели есть требования.

Вкладка «1. Цели» — неделя 1 плана

Каждая бизнес-цель — строка с пятью полями: формулировка цели, показатель с единицей измерения, текущее значение и целевое значение (числовые поля), срок (выбор даты). Если цель названа, но чего-то из показателя, текущего и целевого значения или срока не хватает, под строкой появляется красная подсказка «Не хватает: …» с перечнем пустых полей. Цели добавляются кнопкой «+ добавить бизнес-цель» и удаляются крестиком.

Вкладка «2. Границы» — неделя 2 плана

Четыре блока со списками: «Входит в решение», «НЕ входит в решение», «Ограничения», «Допущения». Каждый пункт — отдельная строка, новая добавляется клавишей Enter или ссылкой «+ добавить». Под заголовком каждого блока — наводящий вопрос, что именно сюда записывать.

Вкладка «3. Требования» — неделя 3 плана

Каждое бизнес-требование — строка: текст требования, выпадающий список «к какой цели» (в нём только уже названные цели с первой вкладки), четыре кнопки приоритета MoSCoW (по умолчанию стоит Must) и поле «чья потребность» для заинтересованной стороны. Требование без выбранной цели подсвечивается оранжевой рамкой.

Вкладка «Визуализация»

Полоса готовности показывает, сколько из пяти проверок пройдено. Ниже — карта трассировки: по каждой цели значок измеримости и цветные метки привязанных требований (цвет — приоритет MoSCoW), отдельная строка «Без цели» для непривязанных требований и надпись «нет требований» у целей без требований. Внизу — два счётчика: сколько пунктов входит в решение и сколько вынесено за рамки.

Вкладка «Итоги» — неделя 4 плана

Вердикт вычисляется автоматически и называет только первую проблему по порядку: нет целей → первая неизмеримая цель с перечнем недостающих полей → не задано «что не входит» или «что входит» → первое требование без цели → нет ни одного требования → первая цель без требований. Когда всё пройдено, вердикт сообщает, что BRD готов к согласованию, с числом целей, требований и требований уровня Must. Под вердиктом — список пяти проверок, а в рабочей тетради — кнопка создания задачи («Согласовать BRD с заказчиком и спонсором» или «Доработать BRD до согласования» со списком непройденных проверок).

Чего фрейм не делает

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