Часть 3. Управление требованиями

В CMMI две области процессов посвящены работе с требованиями — «Управление требованиями» (Requirements Management) и «Разработка требований» (Requirements Development).

Управление требованиями относится к процессам второго уровня зрелости, а разработка требований — к третьему уровню зрелости. Область процессов «Управление требованиями» подразумевает, что организация-разработчик получила требования от заказчика, а область процессов «Разработка требований» — что организации-разработчику известны потребности заказчика, но эти потребности должны быть трансформированы в требования. Разработке требований была посвящена предыдущая публикация [1].

Управление требованиями

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

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

Рис. 1. Общая схема управления требованиями

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

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

CMMI обращает особое внимание на необходимость тщательно документировать как сами требования и их изменения (если они не были документированы клиентом), так и обоснование этих изменений.

Для эффективного управления требованиями CMMI рекомендует:

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

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

Достижение понимания требований

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

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

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

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

Рекомендуемые рабочие продукты — результаты этапа «Достичь понимания требований»:

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

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

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

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

Рекомендуемые рабочие продукты — результаты этапа «Получить обязательства по выполнению требований»:

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

Управление изменениями к требованиям

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

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

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

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

Рекомендуемые рабочие продукты — результаты этапа «Управлять изменениями к требованиям»:

  • статус требований;
  • база данных требований;
  • база данных принятых решений.

Поддержка двусторонней прослеживаемости требований

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

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

Рекомендуемые рабочие продукты — результаты этапа «Поддерживать двустороннюю прослеживаемость требований»:

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

Идентификация несоответствий между работой по проекту и требованиями

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

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

Рекомендуемые рабочие продукты — результаты этапа «Идентифицировать несоответствия между работой по проекту и требованиями»:

  • документация о несоответствиях, включая источники, условия и обоснование,
  • корректирующие действия.
Литература.
  1. Кирилл Мильман, Семен Мильман. CMMI — шаг в будущее. Часть 2. Разработка требований. «Открытые системы», 2005, № 7-8.
  2. CMMI-SE/SW Version 1.1, Staged Representation, Technical Report CMU/SEI-2002-TR-012, SEI.
  3. CMMI-SE/SW Version 1.1, Continuous Representation, Technical Report CMU/SEI-2002-TR-012, SEI.
  4. Boris Mutafelija, Harvey Stromberg. Systematic Process Improvement Using ISO 9001:2000 and CMMI. SEI, 2003.
  5. Interpreting Capability Maturity Model Integration (CMMI) for Service Organizations. Technical Note CMU/SEI-2003-TN-005, 2003.
  6. CMMI Interpretive Guidance Project. Special Report CMU/SEI-2003-SR-007.
  7. Bruce Allgood, Mile Phillips. CMMI v.1.1 Tutorial. SEI, 2002.

Кирилл Мильман (kmilman@regent.ru) — руководитель службы управления качеством холдинговой компании «Регент», Семен Мильман (smilman@ibs.ru) — директор по качеству Центра аутосорсинга Datafort группы компаний IBS.

Поделитесь материалом с коллегами и друзьями