Как писать BRD документ и какие инструменты вместо этого предлагает Agile?10.05.2023 18:46

14cce4c1ab7669e1d6b6b364dbf44f27.jpgАвтор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

В этой статье я расскажу как правильно писать бизнес требования, создавая BRD, а также разберем какую альтернативу предлагает Agile довольно нагруженному способу управления требованиями. Но начнем с инструкции как писать BRD.

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

Введение

  • Опишите цель и ожидаемые результаты проекта или продукта.

  • Укажите заинтересованные стороны и их роли.

  • Определите контекст и область применения проекта или продукта.

Описание целей проекта в BRD является важным шагом, который поможет всем заинтересованным сторонам понять, чего они ожидают достичь с помощью проекта. Вот несколько рекомендаций, как описывать цели проекта в BRD:

  • Будьте конкретными и измеримыми: Формулируйте цели таким образом, чтобы они были конкретными, ясными и измеримыми. Используйте количественные или качественные метрики, которые позволят оценить достижение цели. Например, «Увеличить продажи на 20% в течение первого года после внедрения» или «Сократить время ответа на запросы клиентов с 48 часов до 24 часов».

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

  • Укажите контекст и ожидания: Определите контекст, в котором проект будет реализован, и ожидания заинтересованных сторон. Укажите, какие проблемы или вызовы должны быть решены, и какие выгоды или улучшения ожидаются. Например, «Улучшение пользовательского опыта для повышения уровня удовлетворенности клиентов» или «Автоматизация процессов для снижения операционных издержек».

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

  • Свяжите цели с бизнес-стратегией: Убедитесь, что цели проекта соответствуют общей бизнес-стратегии компании или организации. Определите, какой вклад проект вносит в достижение стратегии.

Описание текущей ситуации

  • Изложите существующие проблемы или недостатки, которые проект или продукт должны решить.

  • Предоставьте обзор текущих процессов и систем, которые могут быть затронуты.

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

  • Определите основные функции: Идентифицируйте основные функции или возможности, которые должны быть реализованы в проекте или продукте. Разделите их на отдельные пункты или разделы для более ясного понимания.

  • Используйте язык, понятный заказчику: Функциональные требования должны быть выражены простым и понятным языком, который заказчик и другие заинтересованные стороны смогут понять. Избегайте использования технических терминов, если они необходимы, объясните их значение.

  • Будьте специфичными и измеримыми: Формулируйте функциональные требования таким образом, чтобы они были специфичными, конкретными и измеримыми. Используйте количественные или качественные метрики, чтобы можно было определить, выполнены ли требования. Например, «Система должна поддерживать одновременную обработку 100 запросов» или «Форма регистрации должна содержать поля для ввода имени, адреса электронной почты и пароля».

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

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

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

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

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

  • Будьте измеримыми и проверяемыми: Нефункциональные требования также должны быть измеримыми, чтобы можно было оценить, выполнены ли они. Определите конкретные метрики или стандарты, которые будут использоваться для оценки достижения требований. Например, «Система должна поддерживать время отклика не более 2 секунд для 95% запросов» или «Доступность системы должна быть не менее 99,9% в год».

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

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

  • Учтите производительность: Опишите требования к производительности системы, такие как максимальное время отклика, пропускная способность, использование ресурсов (память, процессор), емкость системы и т.д. Укажите предельные значения, которые система должна поддерживать при нагрузке.

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

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

Требования к данным

  • Укажите требования к хранению, обработке и передаче данных.

  • Опишите структуру и форматы данных, а также требования к защите информации.

Риски и ограничения

  • Идентифицируйте потенциальные риски, связанные с проектом или продуктом, и предложите меры по их управлению.

  • Укажите ограничения и факторы, которые могут повлиять на выполнение проекта.

План реализации

  • Укажите этапы разработки и внедрения проекта или продукта.

  • Определите ресурсы, расписание и ответственных лиц для каждого этапа.

  • Укажите ожидаемые результаты и критерии приемки для каждого этапа.

Оценка проекта

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

  • Опишите методы и механизмы контроля качества проекта или продукта.

  • Укажите ожидаемые выгоды и ROI (возврат инвестиций) от проекта или продукта.

Приложения

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

Согласование и утверждение

  • Убедитесь, что BRD соответствует ожиданиям заказчика и других заинтересованных сторон.

  • Запросите отзывы и комментарии, проведите необходимые согласования и внесите соответствующие изменения.

  • Получите утверждение BRD от заказчика или уполномоченного представителя.

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

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

Как управлять требованиями в Agile среде?

Если вы создаете продукт с нуля и еще не знаете каким он должен получиться, не тратьте время на создание и поддержание BRD. Обычно такие проекты ведутся по Agile.

Вот несколько рекомендаций какие инструменты используются вместо BRD в Agile среде и как организовать процесс непрерывного сбора и реализации требований:

  1. User Stories (Пользовательские истории): User Stories являются ключевым инструментом для описания требований в Agile-разработке. Они представляют собой короткие описания требований, сфокусированные на конечном пользователе. User Stories формулируются в формате «Как [пользователь], я хочу [действие], чтобы [цель]». и используются на планировании итераций.

  2. Backlog (Бэклог): Бэклог представляет собой список требований и задач, которые должны быть выполнены в проекте. Он состоит из User Stories и других типов требований, приоритизированных в соответствии с бизнес-ценностью и требованиями заказчика. Бэклог постоянно обновляется, и новые требования могут быть добавлены или изменены в зависимости от обратной связи и изменения приоритетов.

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

  4. Прототипы и эксперименты: В Agile-разработке часто используются прототипы и эксперименты для уточнения требований и проверки концепции продукта. Прототипы могут быть созданы для получения обратной связи от заказчика и проверки соответствия ожиданиям пользователей.

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

  6. Итеративное планирование: Вместо одноразового создания BRD в начале проекта в Agile-разработке используется итеративное планирование. На каждой итерации команда уточняет требования, определяет задачи и приоритеты, что позволяет адаптировать план в соответствии с изменяющимися потребностями и обратной связью.

  7. Модульность и инкрементальность: Вместо полной спецификации требований в начале проекта в Agile-разработке требования разрабатываются модульно и инкрементально. Команда фокусируется на разработке и доставке небольших, но рабочих модулей функциональности, что позволяет получать обратную связь и вносить коррективы на ранних этапах.

  8. Регулярные проверки и обратная связь: Agile-разработка предполагает регулярные проверки и обратную связь для уточнения требований и оценки продукта. Вместо того, чтобы полагаться только на документацию, команда и заказчик взаимодействуют на протяжении всего процесса разработки, что позволяет корректировать требования и ожидания.

В целом, Agile-разработка ставит акцент на гибкость, итеративность и активное взаимодействие с заказчиком. Вместо традиционного BRD, в Agile-подходе используются User Stories, бэклог продукта, прототипы и другие инструменты для описания требований. Это позволяет команде лучше адаптироваться к изменениям и доставлять ценность заказчику на ранних этапах разработки.

Статья подготовлена в преддверии старта курса «Системный аналитик. Team Lead». Узнать подробнее о курсе вы можете по данной ссылке.

© Habrahabr.ru