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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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