Предыдущая: Жизненный цикл продукта: основные методики управления требованиями

На главную

Следующая: Сокрушительный успех PowerPoint презентации

Алфавитная каша в документах описывающих требования к продукту

Статья Майкла Шриватсана, в которой он проливает свет на запутанную систему документов с описаниями требований к продукту. BRD, MRD, PRD, FSD, PSD, SRS, IRS – хотя последнее как-то связано с налогами, нет? :) Кроме шуток – если вы хотите понять разницу между Business Requirements Document и Market Requirements Document то читайте это статью.

На этой неделе я получил любезное письмо от одной читательницы. Она спрашивала, не мог бы я написать статью, сравнивающую различные форматы документов, описывающих требования к продукту, которые используются в индустрии программной разработки. Ну вы знаете - BRD, MRD, PRD, FSD, PSD, SRS, IRS и т.д.

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

Алфавитная каша

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

Сейчас мы все выросли и редко едим эту алфавитную ерунду, но практически во всех профессиях профессиональный жаргон это алфавитная каша, наводненная ТБА (трех буквенная аббревиатура). ХЭП (хорошо это или плохо)!

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

И, как будто этого мало, так еще все организации используют эти аббревиатуры по-разному. То, что в одной организации называется MRD, в другой называют PRD. Иногда я не могу сдержать смех, когда вижу очередную ТБА. Как говорится, дайте нам шанс, а уж мы то постараемся!

Аббревиатуры описаний требований

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

1. BRD
2. MRD
3. PRD
4. FSD
5. PSD
6. SRS

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

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

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

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

   Обычно это документ 1-3 страницы, или PowerPoint презентация слайдов на 10.

   ---

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

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

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

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

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

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

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

   Обычно это документ на 5-25 страниц, а в некоторых компаниях и длиннее, как вы увидите ниже.

   ---

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

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

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

   Подробности о написании MRD можно посмотреть в этой статье (а вот мой перевод).

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

   

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

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

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

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

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

   Обычно это документ Word на 20-50 страниц, и даже длиннее для более масштабных продуктов.

   ---

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

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

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

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

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

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

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

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

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

   Обычно это документ Word включающий несколько десятков страниц.

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

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

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

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

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

НВВ (ну вот и все) – наше путешествие в замечательный мир аббревиатур документов описывающих требования завершен.

Опубликовано в дневнике Michael on Product Management & Marketing 19 августа 2006

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

Предыдущая: Жизненный цикл продукта: основные методики управления требованиями

На главную

Следующая: Сокрушительный успех PowerPoint презентации