BRD, MRD, PRD, FSD

Во всех профессиях профессиональный жаргон это каша

Управление продуктом и аналитика продукта не исключение – особенно, когда дело касается описания требований. У нас есть BRD, MRD и PRD; у нас также есть FSD, PSD и SRS и еще много вариаций на ту же тему.

BRD – Business Requirements Document (Бизнес требования)

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

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

Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком. В маленьких компаниях это может быть даже директор или владелец фирмы.

Пример:

Предположим, ваша компания разрабатывает систему управления взаимоотношений с клиентами (customer relationship management CRM).

BRD может фокусироваться на проблемах стоящих перед менеджерами по продаже – отслеживание всех сделок и возможность формирования достоверных прогнозов. Он может определять:

Перед кем стоят подобные проблемы: - Менеджеры по продаже компаний входящих в список Fortune-500 В чем заключаются эти проблемы: - Отсутствие отслеживания статуса заказов в реальном времени - Невозможность формирования достоверных прогнозов Предлагаемое решение - Создание web-ориентированного ПО для отслеживания (проведения) сделок и формирования прогнозов

MRD – Market Requirements Document (Требования рынка)

MRD фокусируется на определении требований рынка к предлагаемому новому продукту.

Если BRD определяет круг проблем и предлагает вариант их решения – то MRD более подробно описывает детали предлагаемого решения. Он может включать несколько или все нижеприведенные аспекты:

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

Чаще всего он пишется Менеджером по продукту, Менеджером по маркетингу продукта или Бизнес аналитиком совместно с Системным аналитиком.

"Пример:

Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).

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

Функциональные требования: - Должно работать под Internet Explorer (версии 6.0 и выше) и Firefox (версии 1.5 и выше) - Должно использовать SSL для обеспечения безопасности - Пользователь должен иметь возможность вводить данные через web-формы для: пользователей, компаний, контактов, и т.д. - ... другое Не функциональные требования - Должно поддерживаться до 100.000 одновременных пользователей - Необходимо полное руководство пользователя на Английском, Немецком и Японском - ... другое

Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в следующей – и может содержать более 50 страниц.

PRD – Product Requirements Document (Требования к продукту)

PRD фокусируется на определении требований к предлагаемому новому продукту.

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

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

Обычно он пишется Менеджером по продукту, Бизнес аналитиком или Продуктовым аналитиком.

Пример

Давайте продолжим предыдущий пример компании, разрабатывающей систему управления взаимоотношением с клиентами (customer relationship management – CRM).

PRD может фокусироваться на детализации требований, таких как:

Форма авторизации должна включать поля для имени пользователя и пароля.
Она также должна включать ссылку «Забыли пароль?»
Страница «Контакты» должна включать поля для имени, фамилии, телефона, email и т.д.
Алгоритм формирования прогноза должен содержать 5-шаговый мастер, который проведет пользователя через шаги, необходимые для создания ежегодного отчета. Все шаги описаны далее…
другое ...

PRD может также включать подробные варианты использования.

Некоторые организации объединяют MRD и PRD в один документ и называют этот документ MRD. В этом случае MRD будет включать то, что описано в этой части и то, что описано в предыдущей.

FSD – Functional Specifications Document (Функциональная спецификация)

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

Если MRD и PRD фокусируются на требованиях с точки зрения потребностей рынка и продукта, FSD фокусируется на определении деталей продукта, в форме, которая может быть использована разработчиками. FSD может также включать законченные скриншоты и детальное описание пользовательских интерфейсов (UI).

Обычно он пишется Системным аналитиком, Архитектором решения или Главным разработчиком – т.е. автор обычно сам относится к разработчикам.

PSD – Product Specifications Document (Спецификация продукта)

PSD – это наименее популярная аббревиатура, но в тех организациях, которые используют эти документы, они обычно соответствуют по содержанию и объему Функциональной спецификации (Functional Specifications Document FSD) описанный выше.

SRS – Software Requirements Specification (Спецификация требований)

SRS – это еще одна не очень популярная аббревиатура. В организациях, которые используют SRS, они обычно очень похожи на то, что описывается в PRD и FSD.

Итак, вот они – 6 типов документов, описывающих требования, расшифрованные и разжеванные. Только хочу вас предостеречь – все организации по-разному используют эти документы. Каждая организация определяет, какие документы создавать и что именно в них описывать, в зависимости от своих нужд.