Бизнес-требования: что это, виды и управление требованиями проекта

Разработчики сделали «не то» — знакомая ситуация? Или требования менялись каждую неделю, а проект вышел за бюджет вдвое? Эта статья для тех, кто хочет разобраться, как правильно формулировать и фиксировать требования к проекту: для бизнес-аналитиков, менеджеров проектов и заказчиков, которые устали переделывать.

Что такое бизнес-требования и чем они отличаются от ТЗ? Как выглядит документ BRD изнутри и кто его составляет? Как собрать требования, расставить приоритеты и не допустить, чтобы проект разросся за все разумные рамки? Ответы — ниже.

Что такое бизнес-требования и зачем они нужны

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

Без чётко сформулированных требований большинство IT-проектов не достигают своих целей. По данным Project Management Institute, около 37% проектов проваливаются именно из-за неточных или неполных требований. Команда разрабатывает одно, заказчик ожидает другое — и к финальной приёмке оказывается, что система работает, но не решает нужную задачу.

Отличие бизнес-требований от бизнес-потребностей и технического задания

Три понятия часто путают, хотя они описывают разные уровни задачи.

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

Бизнес-требование — это уже конкретная формулировка того, что система или процесс должны обеспечить, чтобы закрыть эту потребность. Например: «система должна автоматически распределять заявки между менеджерами в течение 5 минут с момента поступления».

Источник: shutterstock.com

Техническое задание (ТЗ) отвечает на вопрос «как именно это реализовать»: какой стек, какая архитектура, какие интеграции. Бизнес-требования отвечают на вопрос «что именно нужно» — без привязки к технологии.

Бизнес-требования фиксируются до написания ТЗ. Если начать с технической стороны, не разобравшись с бизнес-целями, — высок риск разработать систему, которая технически безупречна, но не решает реальную задачу.

Виды бизнес-требований: функциональные, нефункциональные и другие

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

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

Уровни требований: от верхнеуровневых до системных

Требования не существуют в одном слое. В зрелом подходе к управлению требованиями выделяют три уровня.

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

2. Пользовательские требования — средний уровень. Описывают, что пользователи должны уметь делать с системой. Формат — пользовательские истории (user stories) или use cases.

3. Системные требования — детальный уровень. Описывают конкретное поведение системы, понятное разработчикам. Это уровень ТЗ.

Каждый нижний уровень конкретизирует верхний. Бизнес-требование «сократить время обработки заявок» трансформируется в пользовательское требование «менеджер должен видеть новые заявки в реальном времени» и далее в системное «система обновляет список заявок каждые 30 секунд без перезагрузки страницы».

«Голодные игры» для бизнеса:
Как занять нишу за 3-4 месяца, пока конкуренты режут бюджеты

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

Мы разработали стратегию, которая помогла 196 нашим клиентам стать №1 в своих нишах за 3–6 месяцев.

Что показали кейсы:

• стратегия сработала в 93%;
• средняя окупаемость инвестиций — 312%;
• в сложных нишах заявка в 7 раз дешевле, чем в Директе;
• клиенты в среднем увеличили прибыль на 217% за первые 3 месяца.

Мы уверены в результате, поэтому даём финансовую гарантию в договоре.
И да, вы можете внедрить стратегию сами (хотя мы будем немного ревновать).

Скачайте бесплатно нашу пошаговую стратегию с кейсами в 78 нишах и начните забирать в 3-5 раз больше клиентов, пока конкуренты продолжают терять рынок.

Скачать стратегию роста

PDF 2,3 MB

Документ бизнес-требований (BRD): структура и содержание

Результатом работы по выявлению требований становится документ бизнес-требований — BRD (Business Requirements Document). Это формальный артефакт, который фиксирует всё, что команда разработки должна знать о проекте до написания первой строки кода: цели, стейкхолдеров, границы, функции и критерии успеха.

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

Что входит в BRD: обязательные разделы

Структура BRD варьируется в зависимости от методологии и масштаба проекта, но семь блоков присутствуют в любом качественном документе.

• Цели и бизнес-контекст

Этот раздел отвечает на вопрос «зачем». Здесь описывают текущую ситуацию, проблему или возможность, которую решает проект, и ожидаемые бизнес-результаты. Хорошая формулировка цели привязана к измеримым показателям: «сократить время обработки заявок с 2 часов до 20 минут», а не просто «ускорить обработку заявок».

• Стейкхолдеры

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

Источник: shutterstock.com

• Границы проекта (Scope)

Scope определяет, что входит в проект, а что — нет. Это один из самых важных разделов: без чётких границ возникает «расползание задач» (scope creep), когда в процессе разработки добавляются новые функции, не предусмотренные изначально.

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

• Функциональные требования

Детальное описание того, что система должна делать. Каждое требование формулируют в виде «система должна [действие]» и присваивают уникальный идентификатор для трассировки.

• Нефункциональные требования

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

• Ограничения и допущения

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

• Критерии приёмки

Конкретные условия, при выполнении которых заказчик принимает результат. Критерии приёмки устраняют субъективность на финале проекта: вместо споров о том, «хорошо ли работает система», есть чёткий список проверяемых пунктов.

Кто участвует в составлении: роли и стейкхолдеры

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

• Бизнес-аналитик — координирует процесс сбора требований, проводит интервью, документирует результаты и следит за полнотой документа.

• Заказчик или спонсор проекта — формулирует бизнес-цели и приоритеты, утверждает финальную версию BRD.

• Конечные пользователи — описывают свои задачи и сценарии работы, помогают выявить реальные потребности, а не предполагаемые.

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

• Менеджер проекта — контролирует соответствие требований бюджету и срокам, управляет рисками.

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

Как разработать бизнес-требования: методы и пошаговый алгоритм

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

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

Методы сбора требований: интервью, воркшопы, анализ процессов

Выбор метода зависит от типа проекта, доступности стейкхолдеров и сложности предметной области.

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

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

Источник: shutterstock.com

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

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

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

Алгоритм разработки: от KPI и бизнес-потребности до критериев приёмки

Разработка бизнес-требований проекта строится по последовательному алгоритму из шести шагов.

Шаг 1. Определить бизнес-потребность и KPI

Начинают с вопроса: «Зачем вообще нужен этот проект?» Фиксируют текущую проблему, её масштаб и влияние на бизнес. На этом же этапе определяют ключевые показатели эффективности (KPI), по которым будут оценивать успех проекта. Без измеримых KPI невозможно сформулировать критерии приёмки.

Шаг 2. Поставить SMART-цели

Бизнес-потребность трансформируют в конкретные цели по SMART-критериям: Specific (конкретные), Measurable (измеримые), Achievable (достижимые), Relevant (значимые), Time-bound (ограниченные по времени). Расплывчатое «улучшить сервис» превращается в «сократить время ответа службы поддержки с 24 часов до 4 часов к концу второго квартала».

Шаг 3. Выявить стейкхолдеров

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

Шаг 4. Определить границы проекта

Явно фиксируют, что входит в scope, а что — нет. Хорошая практика — прописать «out of scope» отдельным списком. Это предотвращает разночтения и защищает команду от неконтролируемого расширения задач.

Шаг 5. Собрать и задокументировать требования

Используя выбранные методы сбора, получают требования от всех стейкхолдеров. Каждое требование записывают с уникальным ID, описанием, приоритетом и источником (кто сформулировал). Требования проверяют на полноту, непротиворечивость и реализуемость.

Шаг 6. Сформулировать критерии приёмки

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

Как документировать: монолитный и дробный подход

Существуют два основных подхода к документированию требований.

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

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

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

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

ТОП-7 кейсов
из разных ниш с ростом
от 89% до 1732%

Узнать подробнее

Примеры бизнес-требований к системе

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

Ниже приведены примеры для типичных бизнес-ситуаций: внедрение CRM-системы и разработка клиентского портала.

Примеры функциональных требований

Функциональные требования к системе описывают конкретные действия, которые система должна выполнять. Стандартная формула: «Система должна [глагол действия] [объект] [при каких условиях / с какими параметрами]».

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

Примеры нефункциональных требований

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

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

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

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

Умение распознать слабые требования на старте экономит значительно больше времени и денег, чем попытки исправить ситуацию в процессе разработки. По оценкам Standish Group, устранение дефекта требований на этапе разработки обходится в 10–100 раз дороже, чем на этапе его фиксации.

Признаки проблем в требованиях и критерии их качества

Качественное требование проверяют по шести критериям: оно должно быть полным, однозначным, измеримым, реализуемым, необходимым и трассируемым.

Перед финальным согласованием BRD каждое требование проверяют по чек-листу: можно ли его протестировать? Понятно ли оно без дополнительных объяснений? Есть ли у него уникальный идентификатор?

Как управлять изменениями и вести трассировку требований

Требования меняются — это нормально. Меняется рынок, приходят новые данные, появляются технические ограничения. Проблема не в самих изменениях, а в отсутствии процесса управления ими.

Управление изменениями включает четыре элемента:

1. Запрос на изменение (Change Request) — любое изменение требований оформляется как формальный запрос с описанием, обоснованием и оценкой влияния на сроки и бюджет.

2. Анализ влияния — перед принятием изменения оценивают, какие другие требования оно затрагивает и что потребуется переработать.

3. Согласование — изменение утверждается уполномоченным лицом (заказчик, спонсор проекта или Change Control Board).

4. Обновление документации — после утверждения BRD обновляется с новой версией и датой. История изменений хранится в самом документе.

Трассировка требований — это связь между требованием и всеми артефактами, которые из него вытекают: дизайн-решениями, задачами разработки, тест-кейсами. Инструмент трассировки — матрица трассируемости (Requirement Traceability Matrix, RTM).

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

Для небольших проектов трассировку ведут в таблице. Для крупных — используют специализированные инструменты: Jira, Confluence, IBM DOORS, Azure DevOps. Главное условие — трассировка ведётся с первого дня и обновляется при каждом изменении.

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

Скачайте полезный документ по теме:

Чек-лист: Как добиваться своих целей в переговорах с клиентами

Источник изображения в шапке: shutterstock.com

Автор статьи

Дмитрий Свистунов

Руководитель SEO-отдела и разработки

Последние статьи этого автора:

• Как провести вебинар: правила, этапы, полезные инструменты
• Массовая рассылка email: задачи, виды, этапы создания