Руководство pmbok ® Шестое издание

Часть 1 - Руководство

Многие организации подразделяют требования на различные типы, например бизнес-решения и технические 

решения, причем первые относятся к потребностям заинтересованных сторон, а последние — к способу реализации 

этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение 

и детализацию в процессе их выработки. Данные классы включают в себя:

u

u

Бизнес-требования. Бизнес-требования описывают высокоуровневые потребности организации в целом, 

например проблемы или благоприятные возможности организации, а также причины, по которым проект 

был инициирован.

u

u

Требования заинтересованных сторон. Требования заинтересованных сторон описывают потребности 

заинтересованной стороны или группы заинтересованных сторон.

u

u

Требования к решению. Требования к решению описывают свойства, функции и характеристики продукта, услуги 

или результата, который удовлетворяет бизнес-требованиям и требованиям заинтересованных сторон. Требования 

к решению, в свою очередь, группируются в функциональные и нефункциональные требования:

u

n

Функциональные требования. Функциональные требования описывают поведение продукта. Примеры включают 

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

u

n

Нефункциональные требования. Нефункциональные требования дополняют функциональные и описывают 

условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают 

в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность 

поддержки, требования к хранению/уничтожению и т. д.

u

u

Требования на переходный период и по обеспечению готовности. Требования к переходу описывают 

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

из текущего состояния «как есть» в желаемое состояние в будущем.

u

u

Требования к проекту. Требования к проекту описывают действия, процессы или другие условия, которым должен 

соответствовать проект. В качестве примеров можно назвать даты контрольных событий, договорные обязательства, 

ограничения и т. п.

u

u

Требования к качеству. Требования к качеству, включающие в себя любое состояние или критерии, необходимые 

для подтверждения успешного получения поставляемого результата проекта или выполнения других требований 

к проекту. В качестве примеров можно назвать тестирование, сертификацию, подтверждения и т. п.

5.2.3.2 МАТРИЦА ОТСЛЕЖИВАНИЯ ТРЕБОВАНИЙ

Матрица отслеживания требований — это таблица, связывающая требования к продукту, начиная от их создания 

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

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

организации и проекта. Это позволяет отслеживать требования на протяжении жизненного цикла проекта, что помогает 

удостовериться в том, что требования, одобренные в документации по требованиям, выполнены в конце проекта. Наконец, 

матрица отслеживания требований обеспечивает структуру для управления изменениями содержания продукта.

149

Требования к отслеживанию включают в себя, среди прочего:

u

u

бизнес-потребности, а также благоприятные возможности, цели и задачи организации;

u

u

цели проекта;

u

u

содержание проекта и поставляемые результаты ИСР;

u

u

проектирование продукта;

u

u

разработку продукта;

u

u

стратегию и сценарии тестирования;

u

u

детализацию от высокоуровневых до более детальных требований.

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

Данные параметры помогают определить ключевую информацию относительно требований. Типичные параметры, 

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

описание требования, обоснование включения в список требований, владельца требования, источник, приоритет, 

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

статуса. Дополнительные параметры, позволяющие удостовериться, что требование удовлетворяет заинтересованные 

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

пример матрицы отслеживания требований с включенными в нее параметрами требований.

Рис. 5-7. Пример матрицы отслеживания требований

Матрица отслеживания требований

Описание требований

ИД

Бизнес-потребности, 

благоприятные 

возможности, 

цели и задачи

Цели

проекта

ИД

работника

Поставляе-

мые 

результаты 

ИСР

Проектиро-

вание 

продукта

Разработка 

продукта

Название проекта: 

Центр затрат: 

Описание проекта:

1.0

1.1

1.2

1.2.1

2.0

2.1

2.1.1

3.0

3.1

3.2

4.0

5.0

001

002

003

004

005

Практичес-

кие примеры 

испытаний

150 

Часть 1 - Руководство

5.3 ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ

Определение содержания — процесс разработки подробного описания проекта и продукта. Ключевая выгода 

данного процесса состоит в том, что он позволяет описать границы и критерии приемки продукта, услуги или 

результата. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-8. На рис. 5-9 показана 

диаграмма потоков данных процесса.

Рис. 5-8. Определение содержания: входы, инструменты и методы, выходы

Инструменты и методы

Входы

Выходы

Определение содержания

.1  Экспертная оценка

.2  Анализ данных

  • Анализ альтернатив

.3  Принятие решений

  • Анализ решений на основе 

    множества критериев

.4  Навыки межличностных 

  отношений и работы с командой

  • Фасилитация

.5  Анализ продукта

.1  Устав проекта

.2  План управления проектом

  • План управления 

    содержанием

.3  Документы проекта

  • Журнал допущений

  • Документация по требованиям

  • Реестр рисков

.4  Факторы среды предприятия

.5  Активы процессов организации

.1  Описание содержания проекта

.2  Обновления документов проекта

  • Журнал допущений

  • Документация по требованиям

  • Матрица отслеживания 

требований

  • Реестр заинтересованных 

сторон

151

5.3

Определение

содержания

Предприятие/ 

организация

4.1

Разработка

устава проекта

•  Описание содержания проекта

•  Устав проекта

Документы проекта

•  Журнал допущений

•  Документация по требованиям

•  Реестр рисков

• Факторы среды предприятия

• Активы процессов организации

Документы

проекта

План управления проектом

•  План управления содержанием

План

управления

проектом

Документы

проекта

Обновления документов 

проекта

• Журнал допущений

• Документация по требованиям

• Матрица отслеживания требований

• Реестр заинтересованных сторон

Рис. 5-9. Определение содержания: диаграмма потоков данных

Поскольку в проект невозможно включить все требования, выявленные в процессе сбора требований, окончательные 

требования к проекту выбираются в ходе процесса определения содержания из документации по требованиям, 

разработанной в рамках процесса сбора требований. Затем создается подробное описание проекта, а также продукта, 

услуги или результата.

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

и ограничениях, документированных во время инициации проекта. Содержание проекта определяется во время 

планирования и описывается более подробно по мере поступления информации о проекте. Существующие риски, допущения 

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

определения содержания может быть в высокой степени итеративным. В проектах с итеративным жизненным циклом 

высокоуровневое видение разрабатывается для всего проекта, но подробное содержание определяется последовательно 

в процессе каждой итерации, а детализированное планирование следующей итерации осуществляется по мере выполнения 

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

152 

Часть 1 - Руководство

5.3.1 ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ: ВХОДЫ

5.3.1.1 УСТАВ ПРОЕКТА

Описан в разделе 4.1.3.1. Устав проекта предоставляет высокоуровневое описание проекта и высокоуровневые 

характеристики продукта, а также требования к одобрению.

5.3.1.2 ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ

Описан в разделе 4.2.3.1. Компонент плана управления проектом включает в себя, среди прочего, план управления 

содержанием, как описано в разделе 5.1.3.1, который документирует порядок определения, подтверждения и контроля 

содержания проекта.

5.3.1.3 ДОКУМЕНТЫ ПРОЕКТА

В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, 

среди прочего:

u

u

Журнал допущений. Описан в разделе 4.1.3.2. В журнале допущений определяются допущения и ограничения 

в отношении продукта, проекта, среды, заинтересованных сторон и других факторов, которые могут повлиять на проект 

и содержание продукта.

u

u

Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям определяет 

требования, которые будут включены в состав содержания.

u

u

Реестр рисков. Описан в разделе 11.2.3.1. Реестр рисков содержит стратегии реагирования, которые могут влиять на 

содержание проекта, например сокращение или изменение содержания проекта и продукта, чтобы уклониться от риска 

или снизить риск.

5.3.1.4 ФАКТОРЫ СРЕДЫ ПРЕДПРИЯТИЯ

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

среди прочего:

u

u

организационную культуру,

u

u

инфраструктуру,

u

u

управление персоналом,

u

u

ситуацию на рынке.

5.3.1.5 АКТИВЫ ПРОЦЕССОВ ОРГАНИЗАЦИИ

Активы процессов организации, которые могут оказывать влияние на процесс определения содержания, включают 

в себя, среди прочего:

u

u

политики, процедуры и шаблоны описания содержания проекта;

u

u

архивы предыдущих проектов;

u

u

извлеченные уроки из предыдущих фаз или проектов.

153

5.3.2 ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ: ИНСТРУМЕНТЫ И МЕТОДЫ

5.3.2.1 ЭКСПЕРТНАЯ ОЦЕНКА

Описана в разделе 4.1.2.1. Следует учитывать экспертные заключения, полученные от лиц или групп, обладающих 

специальными знаниями или опытом работы над аналогичными проектами.

5.3.2.2 АНАЛИЗ ДАННЫХ

В качестве примера метода анализа данных, который можно использовать в данном процессе, можно привести, среди 

прочего, анализ альтернатив. Анализ альтернатив можно использовать для оценки способов исполнения требований 

и достижения целей, предусмотренных в уставе.

5.3.2.3 ПРИНЯТИЕ РЕШЕНИЙ

Описано в разделе 5.1.2.2. Методы принятия решений, которые можно использовать в данном процессе, включают 

в себя, среди прочего, анализ решений на основе множества критериев. Описанный в разделе 8.1.2.4 анализ 

решений на основе множества критериев — это метод, в котором используется матрица решений для обеспечения 

систематического аналитического подхода к установлению критериев, таких как требования, расписание, бюджет 

и ресурсы, для уточнения содержания проекта и продукта для данного проекта.

5.3.2.4 НАВЫКИ МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЙ И РАБОТЫ С КОМАНДОЙ.

Описаны в разделе 4.1.2.3. Примером метода применения навыков межличностных отношений и работы с командой 

является фасилитация. Фасилитация используется при проведении семинаров и рабочих сессий с участием ключевых 

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

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

5.3.2.5 АНАЛИЗ ПРОДУКТА

Анализ продукта может использоваться для определения продуктов и услуг. Он состоит в постановке вопросов о продукте 

или услуге и формировании ответов для описания использования, характеристик и других релевантных аспектов того, что 

должно входить в поставку.

В каждой прикладной области существует один или несколько общепринятых методов перевода высокоуровневых 

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

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

анализа продукта включают в себя, среди прочего:

u

u

разбиение продукта на составные части, 

u

u

анализ требований,

u

u

анализ систем,

u

u

системную инженерию,

u

u

анализ ценности,

u

u

функционально-стоимостный анализ.

154 

Часть 1 - Руководство

5.3.3 ОПРЕДЕЛЕНИЕ СОДЕРЖАНИЯ: ВЫХОДЫ

5.3.3.1 ОПИСАНИЕ СОДЕРЖАНИЯ ПРОЕКТА

Описание содержания проекта — это изложение содержания проекта, основных поставляемых результатов, допущений 

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

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

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

содержания, что может помочь в управлении ожиданиями заинтересованных сторон. Оно позволяет команде проекта 

осуществлять более детальное планирование, направляет работу команды проекта во время исполнения и предоставляет 

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

Степень и уровень детализации, с которой описание содержания проекта определяет работу, которая будет выполнена, 

и работу, которая исключена, могут помочь определить, насколько хорошо команда управления проектом может 

контролировать содержание всего проекта. Подробное описание содержания проекта либо непосредственно, либо в виде 

ссылок на другие документы включает в себя:

u

u

Описание содержания продукта. Последовательно уточняет характеристики продукта, услуги или результата, 

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

u

u

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

способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. 

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

по управлению проектом. Данные поставляемые результаты могут быть описаны обобщенно или с высокой 

степенью детализации.

u

u

Критерии приемки. Набор условий, которые должны быть выполнены до того, как поставляемые результаты будут 

приняты.

u

u

Исключения из проекта. Определяет, что исключено из проекта. Явная формулировка того, что именно 

находится вне содержания проекта, помогает управлять ожиданиями заинтересованных сторон и может 

сократить расползание содержания.

Хотя устав проекта и описание содержания проекта иногда воспринимаются как документы, в определенной 

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

информацию, а описание содержания проекта — подробное описание компонентов содержания. Данные 

компоненты последовательно уточняются в течение проекта. В таблице 5-1 описаны некоторые из ключевых 

элементов каждого документа.

155

Устав проекта

Цель проекта 

Измеримые цели проекта и соответствую-

щие критерии успеха

Высокоуровневые требования

Высокоуровневые описания, границы и 

ключевые поставляемые результаты проекта

Совокупный риск проекта

Укрупненное расписание контрольных 

событий

Заранее утвержденные финансовые ресурсы

Список основных заинтересованных сторон

Требования для одобрения проекта 

(например, что считается успехом, кто 

принимает решение, что проект завершен 

успешно, кто утверждает окончание проекта)

Критерии выхода из проекта (т. е. какие 

условия должны быть выполнены, чтобы 

проект или его фаза были закрыты или 

отменены)

Назначенный руководитель проекта, сфера 

ответственности и уровень полномочий

Название (имя) и полномочия спонсора 

или другого (-их) лица (лиц), утверждаю-

щих устав проекта

Описание содержания проекта

Описание содержания проекта 

(с последовательным уточнением)

Поставляемые результаты проекта

Критерии приемки

Исключения из проекта

Таблица 5-1. Элементы устава проекта и описания содержания проекта

5.3.3.2 ОБНОВЛЕНИЯ ДОКУМЕНТОВ ПРОЕКТА

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

назвать, среди прочего:

u

u

Журнал допущений. Описан в разделе 4.1.3.2. Журнал допущений обновляется путем внесения дополнительных 

допущений или ограничений, которые были определены в ходе этого процесса.

u

u

Документацию по требованиям. Описана в разделе 5.2.3.1. Документация по требованиям может обновляться 

путем внесения в нее дополнительных или измененных требований.

u

u

Матрицу отслеживания требований. Описана в разделе 5.2.3.2. Матрица отслеживания требований может 

обновляться с целью отражения обновлений, внесенных в документацию по требованиям.

u

u

Реестр заинтересованных сторон. Описан в разделе 13.1.3.1. Дополнительная информация о существующих 

или новых заинтересованных сторонах вносится в реестр заинтересованных сторон по мере ее поступления.

156 

Часть 1 - Руководство

5.4 СОЗДАНИЕ ИСР

Создание иерархической структуры работ (ИСР) — это процесс разделения поставляемых результатов проекта и работ 

проекта на меньшие компоненты, которыми легче управлять. Ключевая выгода данного процесса состоит в том, что он 

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

моменты в проекте. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5-10. На рис. 5-11 

показана диаграмма потоков данных процесса.

Рис. 5-10. Создание ИСР: входы, инструменты и методы, выходы

Рис. 5-11. Создание ИСР: диаграмма потоков данных

Инструменты и методы

Входы

Выходы

Create WBS

.1  Экспертная оценка

.2  Декомпозиция

.1  План управления проектом

  • План управления 

    содержанием

.2  Документы проекта

  • Описание содержания проекта

  • Документация по требованиям

.3  Факторы среды предприятия

.4  Активы процессов организации

.1  Базовый план по содержанию

.2  Обновления документов 

проекта

  • Журнал допущений

  • Документация по требованиям

5.4

Создание

ИСР

Предприятие/ 

организация

• Базовый план 

  по содержанию

План управления проектом

• План управления содержанием

Документы проекта

• Описание содержания проекта

• Документация по требованиям

• Факторы среды предприятия

• Активы процессов организации

Документы

проекта

План

управления

проектом

Документы

проекта

Обновления документов 

проекта

• Журнал допущений

• Документация по требованиям

План

управления

проектом

157

ИСР — это иерархическая декомпозиция полного содержания работ, выполняемых командой проекта для достижения 

целей проекта и создания требуемых поставляемых результатов. ИСР организует и определяет общее содержание проекта 

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

Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются пакетами работ. 

Пакет работ может использоваться для группировки операций, на уровне которых составляется расписание работ 

и  проводится их оценка, осуществляется мониторинг и контроль. В контексте ИСР «работы» означают продукты или 

поставляемые результаты, являющиеся результатами операций, но не сами операции.

5.4.1 СОЗДАНИЕ ИСР: ВХОДЫ

5.4.1.1 ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ

Компонент плана управления проектом включает в себя, среди прочего, план управления содержанием: Описанный 

в разделе 5.1.3.1 план управления содержанием документально оформляет порядок создания ИСР на основе положений 

описания содержания проекта.

5.4.1.2 ДОКУМЕНТЫ ПРОЕКТА

В качестве примеров документов проекта, которые можно считать входами в данный процесс, можно назвать, 

среди прочего:

u

u

Описание содержания проекта. Описано в разделе 5.3.3.1. Описание содержания проекта описывает работы, 

которые будут исполнены, и исключенные работы.

u

u

Документацию по требованиям. Описана в разделе 5.2.3.1. Детальное описание требований содержит описание 

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

5.4.1.3 ФАКТОРЫ СРЕДЫ ПРЕДПРИЯТИЯ

Факторы среды предприятия, которые могут влиять на процесс создания ИСР, включают в себя, среди прочего, стандарты 

ИСР конкретной отрасли, соответствующие характеру данного проекта. Указанные стандарты ИСР конкретной отрасли могут 

служить внешним источником справочных материалов для создания ИСР.

5.4.1.4 АКТИВЫ ПРОЦЕССОВ ОРГАНИЗАЦИИ

Активы процессов организации, которые могут оказывать влияние на процесс создания ИСР, включают в себя, 

среди прочего:

u

u

политики, процедуры и шаблоны для ИСР;

u

u

архивы предыдущих проектов;

u

u

извлеченные уроки из предыдущих проектов.

158