Слово из трех букв

Это моя первая статья на vc.ru, и в ней я попытаюсь разобраться в различных трехбуквенных аббревиатурах, которые часто встречаются в статьях по разработке требований к программному обеспечению. За подготовку статьи выражаю благодарность Майклу Шриватсану и Дмитрию Слуцкову.

Картинка из общедоступных источников<br />
Картинка из общедоступных источников

Введение

Не секрет, что в любой профессии очень часто любят использовать аббревиатуры. Из наиболее громоздких и пугающих- сокращения в организационно-штатных структурах государственных органов (например, ОКГЗиСФД, ООДУУМиПДН, ОАПКиИТО). Ну с государственными органами все понятно, любая бюрократическая структура любит плодить подразделения со звучными и непонятными широким массам названиями и обязанностями. Мы же поговорим об аббревиатурах документов, которые сопровождают цикл разработки программного обеспечения.

Наиболее распространенными аббревиатурами, применяемыми для обозначения документов с описаниями требований, являются такие, как: BRD, MRD, PRD, FSD, PSD и SRS. Может какие-то из них уважаемый читатель встречал в своей работе, а какие-то видит в первый раз. Попробуем разобраться, что за трехбуквенные звери обитают в этом зоопарке.

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

О чем документ?

BRD описывает бизнес-задачи, стоящие перед пользователями разрабатываемой (или дорабатываемой) системы. Также в BRD могут быть описаны такие аспекты классического бизнес-анализа, как прогноз прибылей, анализ рынка и конкурентов, стратегия продвижения и/или продаж.

Кто разрабатывает?

Бизнес-аналитик, менеджер по маркетингу, менеджер продукта. Иногда авторами BRD являются владелец бизнеса или руководитель компании (особенно в маленьких фирмах).

Какие разделы может содержать?

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

  • С какими проблемами сталкивается бизнес/продукт?
  • Перед кем стоят эти проблемы?
  • Какое решение предлагается для решения этих проблем?

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

О чем документ?

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

Кто разрабатывает?

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

Какие разделы может содержать?

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

  • Функциональные возможности, необходимые для решения бизнес задач

  • Анализ рынка и конкурентов

  • Функциональные (что должен делать продукт?) и нефункциональные (как продукт должен это делать?) требования

  • Расстановка приоритетов требований и функциональных возможностей

  • Варианты использования

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

О чем документ?

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

Кто разрабатывает?

Продуктовый аналитик, менеджер продукта, бизнес-аналитик (да, этот господин в ответе за все).

Какие разделы может содержать?

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

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

О чем документ?

FSD детально определяет функциональные требования к продукту с фокусировкой на реализации. В отличие от M(F) RD в FSD определяются детали продукта в той форме, которую могут использовать разработчики.

Кто разрабатывает?

Системный аналитик, архитектор решения, техлид команды разработки. Разумеется, к разработке всего, что касается UI/UX, может привлекаться соответствующий специалист.

Какие разделы может содержать?

В документе может последовательно, форма за формой, определяться внешний вид продукта (скриншоты и детальное описание UI), а также реализация функциональных возможностей (сценарии использования).

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

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

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

О чем документ?

Детальное описание требований к разрабатываемому программному обеспечению. Может заменять и расширять такие типы документов, как PRD и FSD. Разумеется, в «каждой избушке свои погремушки», поэтому от компании к компании содержание SRS в деталях может отличаться.

Кто разрабатывает?

Те же уважаемые люди, что и в случае с FSD (системный аналитик, архитектор, главный разработчик, дизайнер).

Какие разделы может содержать?

  • Назначение документа и соглашения
  • Границы продукта (scope)
  • Операционная среда
  • Роли и права доступа
  • Пользовательские истории (User Story)
  • Варианты использования (Use Cases), детализирующие каждую User Story
  • Системные требования, определяющие порядок реализации каждого из вариантов использования
  • Модели данных (концептуальная и логическая)
  • Детализированное описание UI/UX
  • Описание интеграций с внешними системами
  • Нефункциональные требования (производительность, безопасность, атрибуты качества).

Отдельно хочется отметить, что требования к безопасности бывают двух видов — как Safety Requirements (требования к производственной безопасности, условиям использования и эргономике), так и Security Requirements (требования к информационной безопасности). Это разные категории нефункциональных требований, и не нужно натягивать одну сову на два глобуса: )

Итоги

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

Всем удачного дня и до новых встреч!

4
2 комментария

Можно заметить, что в России всё, кроме SRS могут сокращать до первых 2-х букв, т.к. до document (полный и непротиворечивый) дело не доходит.:)

1
Ответить

Более того, часто то, что называют document, им не является именно с точки зрения проверки на полноту и непротиворечивость ) но это отдельная большая тема )))

Ответить