Семинары с участием модератора

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

Например, в области разработки программного обеспечения используются семинары с участием модератора под названием «Совместная разработка (или проектирование) приложений» (Joint Application Development (or Design), JAD). Такие собрания с участием модератора направлены на предоставление пользователям возможности встретиться с командой разработчиков для улучшения процесса разработки программного продукта. В производственных отраслях существует «Развертывание функции качества» (Quality Function Deployment, QFD) –это еще один пример семинара с участием модератора, который помогает определить критически важные характеристики для продвижения нового продукта. QFD начинается со сбора потребностей заказчика, что также называется мнением заказчика (Voice of the Customer, VOC). Затем эти потребности объективно сортируются, и между ними расставляются приоритеты, а также устанавливаются цели для их достижения.

Групповые творческие методы

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

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

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

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

· Составление интеллект карт. Идеи, возникшие во время отдельных сессий мозгового штурма, объединяются в единой интеллект-карте с целью отражения сходства и различия в понимании и формирования новых идей.

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

· методы группового принятия решения. Групповое принятие решений –это процесс оценки различных альтернатив с ожидаемыми результатами в форме разрешения будущих действий. Данные методы могут быть использованы для создания, классификации требований к продукту и расстановки приоритетов между ними.

Существует множество методов принятия группового решения, например:

- единогласие. Все соглашаются с определенным направлением действий.

- большинство голосов. Поддержка со стороны более 50 % членов группы.

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

- Диктатура. Один человек принимает решение за всю группу.

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

· анкеты и опросы

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

· наблюдения

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

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

· прототипы Создание прототипов представляет собой метод раннего получения обратной связи по требованиям путем создания рабочей модели ожидаемого продукта до его фактического производства.

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

Выходы процесса Сбор требований:

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

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

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

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

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

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

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

•цели бизнеса и проекта для возможности контроля;

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

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

•требования к качеству;

•критерии приемки;

•бизнес-правила, описывающие руководящие принципы организации;

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

•влияние на другие органы внутри и за пределами исполняющей организации;

•требования к технической поддержке и обучению;

•допущения и ограничения в отношении требований..

План управления требованиями документирует порядок анализа, документирования и управления требованиями на всем протяжении проекта. Связи между фазами, влияют на порядок управления требованиями. Менеджер проекта должен выбрать наиболее эффективные связи для фаз проекта и задокументировать данный подход в плане управления требованиями. Многие элементы плана управления требованиями основаны на их связях.

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

•порядок планирования, отслеживания и составления отчетов о действиях в отношении требований;

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

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

•процесс расстановки приоритетов требований;

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

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

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

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

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

•требования к целям проекта;

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

•требования к проектированию продукта;

•требования к разработке продукта;

•требования к стратегии и сценариям проверки;

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

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

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

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

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

Входы процесса Определение содержания:

· Устав проекта (описан выше);

· Документация по требованиям(описаны выше);

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

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

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

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

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

Инструменты и методы процесса Определение содержания:

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

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

· Поиск альтернатив

· Семинары с участием модератора

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

• другие подразделения в рамках организации;

• консультанты;

• заинтересованные стороны проекта, в том числе заказчики или спонсоры;

• профессиональные и технические ассоциации;

• промышленные группы;

• эксперты по отдельным вопросам.

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

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

Семинары с участием модератора описаны выше

Выходы процесса Определение содержания:

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

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

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

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

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

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

Результаты могут быть описаны обобщенно или с высокой степенью детализации.

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

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

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

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

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

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

•документы по требованиям;

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

 

Создание ИСР

Создание иерархической структуры работ (ИСР) – это процесс разделения результатов проекта и работ по проекту на более мелкие элементы, которыми легче управлять. Иерархическая структура работ – это ориентированная на результаты иерархическая декомпозиция работ, которые должна выполнить команда проекта для достижения целей проекта и создания требуемых результатов; на каждом более низком уровне ИСР представляет все более детальное описание работ по проекту. ИСР организует и определяет общее содержание проекта и представляет работы, указанные в текущем одобренном описании содержания проекта. Запланированные работы содержатся в элементах ИСР самого нижнего уровня, которые называются пакетами работ. Для пакетов работ могут составляться расписания, оцениваться стоимость, может проводиться их мониторинг и управление. В контексте ИСР работа означает продукты или результаты работ, являющиеся результатами действий, но не сами действия. Для получения дополнительной информации по иерархическим структурам работ обратитесь к документу the Practice Standard for Work Breakdown Structures –Second Edition.

Входы процесса Создание ИСР

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

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

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

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

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

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

•знания, накопленные в предыдущих проектах.

Инструменты и методы процесса Создание ИСР: Декомпозиция.

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

Декомпозиция всей совокупности работ по проекту до пакетов работ обычно включает в себя следующие действия:

•определение и анализ результатов и соответствующих работ;

•структурирование и организация ИСР;

•разбиение верхних уровней ИСР на детализированные элементы более низких уровней;

•разработку и присвоение идентификационных кодов элементам ИСР;

•проверку необходимости и достаточности степени декомпозиции.

Структура ИСР может быть создана в различных формах, например:

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

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

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

Для декомпозиции элементов ИСР верхнего уровня требуется разделение работ по каждому результату или подпроекту на основные элементы, где элементы ИСР представляют собой поддающиеся проверке продукты, услуги или результаты. ИСР может быть структурирована в виде схемы, организационной диаграммы, причинно-следственной диаграммы или другим методом. Проверка правильности декомпозиции требует удостоверения в том, что низкоуровневые элементы ИСР – именно те элементы, которые необходимы и достаточны для создания соответствующих результатов более высокого уровня. Различные результаты могут иметь различные уровни декомпозиции. Работу по некоторым результатам достаточно декомпозировать всего лишь до следующего уровня, чтобы достичь уровня пакетов работ, однако для других могут потребоваться дополнительные уровни декомпозиции.

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

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

ИСР представляет все работы продукта и проекта, включая работы по управлению проектом. Общее содержание работ на самых нижних уровнях должно сворачиваться в более высокие уровни, чтобы ничего не было пропущено, и не выполнялась лишняя работа. Иногда это называют правилом 100 %.

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

Выходы процесса Создание ИСР

· ИСР

· Словарь ИСР

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

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

ИСР – это ориентированное на результаты иерархическое разделение работ, которые должна выполнить команда проекта для достижения целей проекта и создания требуемых результатов; на каждом более низком уровне ИСР представляет собой все более детальное определение работ по проекту. ИСР окончательно оформляется с помощью создания контрольных счетов для пакетов работ и уникального идентификатора из плана счетов. Данные идентификаторы предоставляют структуру для иерархического суммирования информации о затратах, расписании и ресурсах. Контрольный счет – элемент управления, посредством которого содержание, стоимость и расписание интегрируются и сравниваются с освоенным объемом для измерения исполнения. Контрольные счета помещаются на выбранных уровнях управления в ИСР. Каждый контрольный счет может включать один или несколько пакетов работ, но каждый пакет работ должен быть привязан только к одному контрольному счету.

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

•идентификатор плана счетов;

•описание работ;

•ответственную организацию;

•список контрольных событий расписания;

•связанные запланированные операции;

•требуемые ресурсы;

•оценки стоимости;

•требования к качеству;

•критерии приемки;

•технические ссылки;

•контрактную информацию.

Базовый план по содержанию является элементом плана управления проектом. Элементы базового плана по содержанию включают в себя:

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

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

•словарь ИСР. Словарь ИСР содержит подробное описание работ и техническую документацию по каждому элементу ИСР.

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

Подтверждение содержания

Подтверждение содержания – процесс формализованной приемки завершенных результатов проекта.

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

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

Входы процесса Подтверждение содержания

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

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

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

· Подтвержденные результаты

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

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

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

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

• Словарь ИСР содержит подробное описание работ и техническую документацию по каждому элементу ИСР.

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

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

Подтвержденные результаты, завершенные и проверенные на правильность в процессе контроля качества.

Инструменты и методы процесса Подтверждение содержания: Инспекция.

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

Выходы процесса Подтверждение содержания:

· Принятые результаты

· Запросы на изменение

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

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

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

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

Управление содержанием

Управление содержанием – процесс мониторинга статуса проекта и содержания продукта, а также управления изменениями базового плана по содержанию. Управление содержанием проекта обеспечивает обработку всех запрошенных изменений и рекомендованных корректирующих и предупреждающих действий в рамках процесса осуществления общего управления изменениями. Управление содержанием проекта используется также для управления фактическими изменениями по мере их появления; оно интегрировано в остальные процессы управления. Неуправляемые изменения часто называют сдвигом содержания проект. Изменения в любом случае неизбежны, и поэтому необходим процесс управления изменениями.

Входы процесса Управление содержанием:

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

· Информация об исполнении работ

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

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

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

Выходы процесса Управление содержанием

· Результаты измерения исполнения работ

· Обновления активов процессов организации

· Запросы на изменение

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

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

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

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

•причины отклонений;

•выбранные корректирующие воздействия и причины;

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

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

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

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

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

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

•документы по требованиям;

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