Приложение 1-ое к статье «Структура работ по созданию решения на базе технологий DWH».
Общие положения
В данном документе содержится обязательный список пунктов содержания требований бизнеса, которые выявляются и фиксируются на первом этапе проекта. Настоящий документ предназначен для использования бизнес руководителями и менеджерами проектов при согласовании проектных заданий и организации проектных работ на этапе выявления требований бизнеса. Аналитики, которые проводят исследование бизнеса заказчика, должны использовать этот документ в качестве стандарта на содержание BRD.
Список пунктов содержания может пополняться или сокращаться менеджерами проектов и руководителями бизнес направлений после соответствующего согласования на технологическом комитете.
Введение
Текст BRD составляется в терминах бизнеса, содержание и взаимосвязь которых поясняется в глоссарии. Глоссарий обязательно должен содержать трактовки таких терминов, как „миссия“, „цель проекта“, „критерии оценки достижения“, „методики проверки критериев“, „ключевые функциональные требования“.
Формулировки требований, выраженные в терминах бизнеса, обычно подразумевают разночтения или различные трактовки. В случае явной неоднозначности требований в терминах бизнеса необходимо, также, использовать глоссарий, т.к. изменение самой формулировки (с целью достижения однозначности) может привести к ее „нечитаемости“ специалистами от бизнеса. Работая над однозначностью терминов бизнеса следует учитывать, что окончательная однозначность трактовок - это достаточно длительный процесс, который возможен только (!) на техническом уровне и требует специальной методики (см. п.п. 2.1, 2.2, 2.3 документа «Структура работ по созданию решения на базе технологий DWH»). Таким образом, однозначность требований достигается на отдельном этапе проектирования и подготовки ТЗ.
Описание обязательного содержания BRD
№ | Раздел BRD. | Содержание раздела | Примечания |
---|---|---|---|
1 | Глоссарий терминов бизнеса. | Если возможно, основные термины желательно приводить со ссылками друг на друга и указанием областей. | |
2 | Введение. | Введение должно отвечать на основные вопросы: на кого рассчитан документ, как его предполагается использовать, какие есть или будут связанные с ним внешние документы и приложения, какой уровень стандартизации (обязательное исполнение или в качестве рекомендаций) применялся и ссылка на стандарты и требования, учтенные при подготовке документа) | |
3 | Общие положения. | Описываются предположения и оценки, принятые обеими сторонами в качестве исходных суждений по важным для проекта вопросам. Особенно важно описать критические (изменение которых может сильно повлиять на содержание работ) для проекта предположения, о которых нет абсолютной уверенности (хотя бы у одной у сторон). Вместо общих положений (если их трудно сформулировать) можно приводить разделы: „Предпосылки“ и „Основания для разработки“ в которых дать описание ситуации, которая привела к необходимости проекта (это предпосылки), и по чьей инициативе, конкретно, был начат проект. | Не стоит описывать положения, которые считаются общезначимыми или слабо касаются содержания проекта. |
4 | Миссия. | Миссия проекта должна быть одна. Лучше, если она выражается ОДНИМ (пусть даже „сложно-сочиненным-подчиненным-малопонятным“ предложением). Если в ходе интервью разные специалисты (обычно это: аналитики, ИТ, и кто-то из бизнес-подразделения) формулируют различные миссии, то их надо аккуратно записать и в ходе предварительных совещаний согласовать с целью получения одной миссии. | Записанные миссии от различных специалистов хорошо смотрятся в приложении: понятно, что работа велась, понятно, как получилась итоговая единая миссия проекта. |
5 | Цели проекта. | Не более 5-7 целей, написанных в терминах бизнеса (т.е. понятных специалисту нетехнического профиля), способствующих достижению миссии. | |
6 | Критерии оценки достижения целей. | Каждой целей проекта соответствует свой критерий или несколько критериев проверки их достижения. Критерии должны быть достижимы и измеримы. Если критериев несколько, то обязательно описать их взаимосвязь (какой важнее, как сопоставлять результаты, если один выполнен, второй - нет и т.д.) | |
7 | Методики проверки критериев достижения целей. | Методики представляют собой список элементарных действий проверки критерия. Желательно указывать документы (или прочие основания), с использованием которых будут проводится проверки. Если таких документов на момент разработки BRD нет, то лучше указать кем, где и когда такие документы должны быть созданы. | |
8 | Условия на организацию проекта. | Система управления проектом может строится по-разному: разные роли, разные схемы принятия решений. Мы предлагаем двухуровневую схему: Управляющий комитет - менеджеры (со стороны исполнителя и заказчика) объединенной рабочей группы (JAD). Описание системы управления, предлагаемой с нашей стороны (она обычно принимается) стандартное, можно взять из любого образцового BRD. В этом разделе также нужно указать этапы и их содержание в терминах достижения целей. Обязательно указать подразделения, которые заинтересованы или могут быть заинтересованы в результатах проекта. | |
9 | Ключевые функциональные требования к системе. | Содержание этого раздела может быть различным и заполняется по желанию специалистов от бизнеса, если они имеют важные (ключевые) требования к функциональности системы и желают, чтобы ожидаемые объемы (количественные показатели) и требуемые (ожидаемые) технологические характеристики были зафиксированы и реализованы в проекте. Излагать эти функциональные требования надо в терминах, понятных нетехническому пользователю, несмотря на то, что такая форма изложения может подразумевать разночтения. Все технические детали будут уточняться на этапе разработки ТЗ. Для удобства требования этого пункта можно излагать в той же последовательности, как излагаются функциональные требования в ТЗ. | |
10 | Обязательства заказчика. | ||
11 | Ограничения проекта. | ||
12 | Требования к поведению разработчика и организации коммуникаций с заказчиком. | Необходимо в виде таблицы указать: ролевой состав рабочих групп, менеджеров рабочих групп, прочие роли со стороны заказчика и исполнителя с примерной областью ответственности. Обязательно указать электронные адреса и телефоны доступа. Особенности доступа или режима работы, которые необходимо знать в рабочих группах. | |
13 | Известные трудности развития бизнеса. | Описываются известные на момент исследования трудности в рамках существующих процессов бизнеса, которые связаны с ИТ технологиями. | Трудности, не связанные с применением ИТ, обычно не включаются в состав BRD. Исключение составляют процессы бизнеса, которые предполагается автоматизировать средствами проектируемой системы в ближайшем будущем |
14 | Ожидаемые изменения в связи с внедрением проекта. | Описываются ключевые процессы бизнеса и их изменение в связи с внедрением системы. | |
15 | Приложения. | Содержатся, если это возможно, документы, на которые даются ссылки в тексте BRD. Обязательно содержаться миссии проекта, с которыми велась работа по согласованию, обязательно содержатся интервью, составленные в процессе исследования. |
См. также:
«Структура работ по созданию решения на базе технологий DWH»;
«Приложение 2. Содержание отчета об исследовании бизнеса»;
«Приложение 3. Содержание концепции решения на базе технологий DWH»