Коллектив авторов - Руководство к Своду знаний по управлению проектами (Руководство PMBOK)

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

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

Сбор требований – процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения и управления содержанием проекта, включая содержание продукта. Входы, инструменты и методы, а также выходы этого процесса показаны на рис. 5–4. На рис. 5–5 показана диаграмма потоков данных процесса.

Рис. 5–4. Сбор требований: входы, инструменты и методы, а также выходы

Рис. 5–5. Диаграмма потоков данных сбора требований

На успех проекта напрямую влияет активная вовлеченность заинтересованных сторон в выявление и декомпозицию потребностей в требования, а также тщательность определения, документирования и управления требованиями к продукту, услуге или результату проекта. Требования включают в себя условия или возможности, которым должен соответствовать проект или которые должен иметь продукт, услуга или результат, чтобы удовлетворить соглашению или другой формальной предписанной спецификации. Требования включают в себя количественно определенные и документированные потребности и ожидания спонсора, заказчика и прочих заинтересованных сторон. Данные требования должны быть выявлены, проанализированы и зарегистрированы со степенью детализации, достаточной для того, чтобы их включить в базовый план по содержанию и измерять после начала исполнения проекта. Требования становятся базой для ИСР. Планирование стоимости, расписания, качества и иногда закупок основывается на данных требованиях. Разработка требований начинается с анализа информации, содержащейся в уставе проекта (раздел 4.1.3.1), в реестре заинтересованных сторон (раздел 13.1.3.1) и в плане управления заинтересованными сторонами (раздел 13.2.3.1).

Многие организации подразделяют требования на различные типы, например бизнес-решения и технические решения, причем первые относятся к потребностям заинтересованных сторон, а последние – к способу реализации этих потребностей. Требования могут быть сгруппированы в классы, что обеспечивает их дальнейшее уточнение и детализацию в процессе их выработки. Данные классы включают в себя:

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

• Требования заинтересованных сторон, описывающие потребности заинтересованной стороны или группы заинтересованных сторон.

• Требования к решению, описывающие свойства, функции и характеристики продукта, услуги или результата, который удовлетворит бизнес-требованиям и требованиям заинтересованных сторон. Требования к решению, в свою очередь, группируются в функциональные и нефункциональные требования:

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

– Нефункциональные требования дополняют функциональные и описывают условия или качества среды, необходимые для обеспечения эффективности продукта. Примеры включают в себя: надежность, защищенность, производительность, безопасность, уровень обслуживания, возможность поддержки, требования к хранению/уничтожению и т. д.

• Требования к переходу описывают временные возможности, такие как требования к преобразованию данных и обучению, необходимые для перехода из текущего состояния «как есть» в состояние «как должно быть» в будущем.

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

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

Описан в разделе 5.1.3.1. План управления содержанием разъясняет то, как команда проекта будет определять, какой тип требований необходимо собрать для проекта.

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

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

Описан в разделе 4.1.3.1. Устав проекта используется для предоставления высокоуровнего описания продукта, услуги или результата, позволяющего разработать детальные требования.

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

Интервью представляют собой формальный или неформальный подход, используемый для получения информации у заинтересованных сторон путем прямого разговора с ними. Обычно в ходе интервью задают подготовленные и непосредственно возникающие вопросы и записывают ответы. Интервью часто проводятся на индивидуальной основе между интервьюером и интервьюируемым, но иногда в них могут участвовать несколько интервьюеров и/или интервьюируемых. Проведение интервью с опытными участниками проекта, спонсорами и другими представителями руководства, а также экспертами по предметной области может помочь в выявлении и определении характеристик и функций желаемых продуктов (поставляемых результатов). Интервью также помогают в получении конфиденциальной информации.