Когда аналитик начинает изучать документирование требований проекта, ему приходится сталкиваться с разными видами требований. Такими как Business Requirements Document (BRD), Software Requirement Specifications (SRS) и Functional Requirement Specifications (FRS). Если быть кратким то, BRD содержит «высокоуровневые» бизнес-требования, SRS содержит «детальные» функциональные и нефункциональные требования, а FRD/FRS содержит «детализированные» функциональные требования вместе с диаграммами потока данных и UML.
Однако, если вы хотите понять отличия и использование всех трех документов, прочтите дальше…
Бизнес-анализ управляется определенными стандартами и рамками. Они должны соблюдаться для проведения практического анализа требований в любом проекте. Однако, нет общепринятых принципов для BRD, SRS и FRS относительно их структуры, содержания и детализации. Это приводит к тому, что организации применяют эти документы на основе своих процессов и стандартов, ресурсов, доступных для них, и типа проекта.
Ниже приведено сравнение в соответствии с наиболее широко принятыми практиками бизнес-анализа и документации проектов.
Business Requirements Document
BRD – один из самых широко используемых документов требований и BABOK – всемирно признанный стандарт бизнес-анализа, определяет его следующим образом:
Business Requirements Document (BRD) – это документ, который описывает бизнес-требования к продукту или проекту, их приоритеты, основные характеристики и ограничения, а также определяет причины их необходимости.
Например. Одно из утверждений в BRD может выглядеть так.
Компания хотела бы повысить эффективность путем отслеживания времени, затраченного сотрудниками на различные задачи.
BRD обычно является одним из первых документов, создаваемых в жизненном цикле проекта. Он описывает общие цели компании, которые она пытается достичь или потребности, которые она пытается удовлетворить, создавая услугу или продукт. Кроме того, BRD также содержит потребности заинтересованных сторон, которые будут взаимодействовать с конечным продуктом. Таким образом, он отвечает на вопрос «почему» (а не «что» или «как») требования будут выполнены и какие результаты ожидаются от системы. Следует отметить, что все будущие требования, улучшения и запросы на изменения в рамках проекта должны быть обоснованы целями и потребностями компании (или бизнеса), перечисленными в BRD.
BRD всегда готовится бизнес-аналитиком и создается после проведения анализа и общения с заинтересованными сторонами клиента. После того, как BRD будет подготовлен, он обычно проверяется и утверждается. Это необходимо, чтобы, документ в точности отражал ожидания бизнеса и ключевых заинтересованных сторон.
Основной аудиторией BRD являются заказчики проекта, руководители и аналитики.
Software Requirement Specifications (SRS) Document
Как только было определено «почему» проект должен быть реализован (с помощью создания BRD), настало время задокументировать «что» требуется для удовлетворения потребностей бизнеса.
Документ «Software Requirement Specifications» (SRS) является подробным и структурированным документом, содержащим функциональные требования (описывающие поведение), нефункциональные требования (описывающие характеристики) и любые сценарии использования, которые должно реализовать программное обеспечение.
Пример: Программное обеспечение для отслеживания рабочего времени сотрудников будет содержать следующие модули:
Модуль авторизации: будет аутентифицировать пользователя на основе введенных учетных данных и разрешать вход только зарегистрированным пользователям.
Модуль администратора: будет содержать функции, позволяющие администратору управлять пользователями — добавлять пользователя, редактировать пользователей, удалять / деактивировать пользователя, добавлять / редактировать разрешения пользователя, группировать пользователей, добавлять проекты и т. д.
Модуль сотрудника: будет включать функции, которые помогут сотруднику вводить информацию о его трудозатратах — вводить / редактировать информацию о затраченном времени, вводить / редактировать информацию о задачах, выбирать проект, редактировать основную информацию, сбрасывать пароль, просматривать предыдущую информацию о затратах и т. д.
Модуль отчетности: модуль для администратора, позволит извлекать сводные отчеты о времени и затратах по пользователям, проектам и задачам. Кроме того, администратор должен иметь возможность экспортировать эти отчеты в форматах .xlsx и PDF.
SRS — это один из важных документов в любом проекте. Он устраняет разрыв между тем, что хочет бизнес, и тем, что они получат. SRS содержит общую структуру, характеристики и рабочие процессы разрабатываемого программного обеспечения. Часто SRS используют для оценки затрат на разработку, поскольку он содержит основные требования к системе. Иногда он даже используется как документ, обязывающий стороны, поскольку содержит достаточно деталей.
Вы можете рассматривать SRS как документ, который «разворачивает» общие требования BRD на уровне модулей, подмодулей и функций, не углубляясь в них.
Документ SRS создает системный или бизнес аналитик проекта. Чтобы подготовить SRS, аналитик должен обсудить требования с заинтересованными сторонами, тщательно проанализировать все аспекты разрабатываемого программного обеспечения и затем составить требования к каждому из них. Каждое требование указанное в SRS должно соответствовать бизнес-целям, перечисленным в BRD.
Functional Requirement Specifications (FRS) Document
Документ FRS является самым подробным и детализированным из трех. Он, наконец, описывает «как» именно должна функционировать система, чтобы удовлетворить всем требованиям, перечисленным в BRD и SRS.
Документ «Спецификации функциональных требований» (FRS) — это детализированный и низкоуровневый документ, который подробно описывает все функциональные требования проекта.
Пример: Модуль входа в систему будет содержать следующие поля:
Ввод имени пользователя. Это поле представляет собой текстовое поле, в которое пользователь может ввести имя пользователя, являющееся идентификатором электронной почты его зарегистрированной компании.
Ввод пароля. Это поле представляет собой текстовое поле, в которое пользователь может ввести пароль. Введенный пароль не должен отображаться пользователю и должен быть зашифрован в виде «*».
Кнопка «Отправить». При нажатии этой кнопки проверяется, действительны ли введенные учетные данные. В случае, если имя пользователя или пароль неверны, система должна отобразить предупреждающее сообщение «Неверное имя пользователя или пароль»…
Документ FRS очень подробный и однозначно излагает все функциональные требования. В документе указываются все поля и взаимодействия пользователей на каждой странице разрабатываемого программного обеспечения. Кроме того, для облегчения понимания в FRS добавлены диаграммы потоков процессов, диаграммы UML и тд.
Следует отметить, что документ FRS создается с точки зрения пользователя и описывает, как будет вести себя программное обеспечение при взаимодействии с ним внешнего пользователя. Команда разработчиков обращается к этому артефакту проекта, чтобы понять, что именно им нужно создать, а команда тестирования/контроля качества — чтобы узнать, каковы различные сценарии и тестовые примеры, на которых должно быть протестировано программное обеспечение.
FRS готовится бизнес-аналитиком/системным аналитиком проекта, а после завершения проверяется руководителем проекта. После этого FRS передается клиентам для окончательного рассмотрения и утверждения. После утверждения FRS становится стандартным документом, который определяет, как должно функционировать программное обеспечение.
Основной аудиторией FRS являются технические руководители, группы разработчиков и группы тестирования.
Другие названия — документ функциональных спецификаций (FSD), функциональная спецификация (FS), спецификация продукта и функциональные спецификации.
