В CMMI две области процессов посвящены работе с требованиями — «Управление требованиями» (Requirements Management) и «Разработка требований» (Requirements Development).
Часть 2. Разработка требований*
Управление требованиями относится к процессам второго уровня зрелости, а разработка требований — к третьему уровню зрелости. Область процессов «Управление требованиями» подразумевает, что организация-разработчик получила требования от заказчика, а область процессов «Разработка требований» — что организации-разработчику известны потребности заказчика, но эти потребности должны быть трансформированы в требования.
Задача области процессов «Разработка требований» заключается в установлении нужд клиента и трансляции их в требования к продукту, которые затем «назначаются» компонентам продукта. Комплекс требований к продукту и его компонентам должен ясно описывать характеристики продукта, особенности дизайна, требования к верификации и т.д. в терминах, которые понятны разработчику.
При разработке требований не всегда можно ограничиться требованиями к продукту, так как клиент может выдвинуть специфические требования к проектированию. В дополнение к требованиям клиента источником требований к продукту могут быть также выбранные проектные решения. Требования устанавливаются и уточняются в течение всего жизненного цикла продукта.
При разработке требований следует принимать во внимание целый ряд факторов, среди которых:
- ограничения различного рода;
- технологические возможности;
- стоимость и факторы, влияющие на стоимость;
- ограничения по времени и факторы, влияющие на график;
- риски;
- проблемы, которые существуют, но которые не были явно сформулированы клиентом;
- особенности бизнеса клиента, нормативные акты и законодательство;
Для установления эффективного процесса разработки требований CMMI рекомендует:
- выявить реальные потребности клиента;
- разработать требования клиента;
- установить требования к продукту и его компонентам;
- «назначить» требования к компонентам продукта;
- установить требования к интерфейсам;
- разработать концепции и сценарии использования системы (operational concepts and scenarios);
- выработать определение требуемой функциональности;
- проанализировать требования;
- достичь баланса между потребностями и ограничениями;
- подтвердить (validate) требования;
Общая схема разработки требований представлена на рис. 1.
|
| Рис. 1. Разработка требований |
При установлении потребностей клиента следует учитывать нужды всех заинтересованных сторон-заказчиков, конечных пользователей, поставщиков, проектантов, тестировщиков. Эти потребности и ожидания, а также налагаемые ограничения, интерфейсы, концепции работы системы и продукта следует тщательно проанализировать, гармонизировать, уточнить и транслировать в комплект требований клиента. Довольно часто потребности, ожидания, ограничения и интерфейсы могут быть плохо установлены или конфликтовать друг с другом. Поэтому данная работа проводится итеративно в течение всего жизненного цикла проекта.
Установление потребностей не ограничивается сбором требований от клиента и других заинтересованных сторон. Необходимо определить и те требования, которые клиент не смог представить в явном виде. В качестве примеров методов, используемых при выявлении потребностей, CMMI приводит следующие:
- технологические демонстрации;
- промежуточные анализы (review) результатов проекта;
- вопросники, интервью и сценарии использования системы, полученные от пользователей;
- прототипы и модели;
- «мозговые штурмы»;
- обзоры рынка;
- бета-тестирование;
- использование документов, стандартов и спецификаций из различных источников;
- реверсивный инжиниринг.
Разработка требований клиента
Информация о потребностях клиента может быть получена из различных источников. Ее следует консолидировать, добыть отсутствующую информацию и разрешить имеющиеся конфликты. Итогом этой работы являются документированные требования клиента, в которых отражены его нужды и ожидания, ограничения и интерфейсы. В требованиях должны быть установлены ограничения по верификации и валидации.
Общая схема разработки требований клиента представлена на рис. 2
|
| Рис. 2. Разработка требований клиента |
Рекомендуемые рабочие продукты — результаты этапа «Разработать требования клиента»:
- требования клиента;
- ограничения по проведению верификации.
Требования клиента могут быть выражены в его собственных терминах и представлять собой нетехнические описания. Требования к продукту являются представлением требований клиента с помощью технической терминологии и могут быть использованы для проектных решений. Требования к продукту и его компонентам детализируют и уточняют требования клиента, что подразумевает учет потребностей, связанных с каждой фазой жизненного цикла продукта; учет ограничений; рассмотрение вопросов, подразумеваемых, но не сформулированных заказчиком в явном виде; учет факторов, связанных с выбранной архитектурой, дизайном и спецификой разработчика. CMMI рекомендует учитывать в требованиях к продукту удовлетворенность заказчика, деловые и проектные цели и связанные с ними атрибуты, такие как эффективность и возможность реализации.
Требования к продукту «назначаются» (allocated) функциям и компонентам продукта, включая объекты, людей и процессы. Особое внимание CMMI обращает на прослеживаемость требований к функциям, объектам, тестам и другим сущностям. По мере развития технического решения разрабатываются внутренние компоненты, уточняются дополнительные интерфейсы и устанавливаются требования к интерфейсам.
Требования разрабатываются в технических терминах, понятных тем, кто проектирует продукт и его компоненты. Выбор технологии может привести к появлению дополнительных требований, например, при использовании электроники будет сформулировано такое требование, как «пределы электромагнитной интерференции».
Для управления изменениями, которые неизбежны в ходе выполнения проекта, рекомендуется установить и поддерживать взаимосвязи между требованиями. Под взаимосвязями подразумеваются зависимости, при которых изменение одного требования может оказать влияние на другие.
Рекомендуемые рабочие продукты — результаты этапа «Установить требования к продукту и его компонентам»:
- производные (derived) требования;
- требования к продукту;
- требования к компонентам продукта.
«Назначение» требований к компонентам продукта
В тех случаях, когда требование более высокого уровня специфицирует характеристику, реализуемую двумя или более компонентами продукта, это требование должно быть разделено и «назначено» каждому компоненту. В CMMI такие требования определены как производные (derived) требования.
Требования могут быть распределены по функциям и компонентам продукта. Проектные ограничения также целесообразно распределить по компонентам продукта. Взаимосвязи между распределенными требованиями необходимо документировать.
Рекомендуемые рабочие продукты — результаты этапа «Назначить требования к компонентам продукта»:
- листы распределения требований (requirements allocation sheets);
- временное распределение требований (provisional requirements allocation);
- ограничения по дизайну;
- производные требования;
- взаимосвязи между производными требованиями.
Установление требований к интерфейсам
Интерфейсы должны быть установлены и идентифицированы, прежде всего, между теми продуктами или компонентами продукта, которые заложены в архитектуре. Идентифицируются как внешние, так и внутренние по отношению к продукту (между функциональными частями или объектами) интерфейсы. По мере развития проекта архитектура может изменяться, что приведет к созданию новых интерфейсов между компонентами продукта и компонентами, внешними по отношению к продукту. Следует установить и интерфейсы с процессами жизненного цикла продукта. К примерам таких интерфейсов можно отнести интерфейсы с тестовым оборудованием, системами транспортации, системами поддержки, производственными помещениями.
Требования к интерфейсам целесообразно определять в терминах их происхождения, назначения, влияния, информации о программах, а также электрических и механических характеристик технических средств. Требования к интерфейсам контролируются как часть интеграции продукта и компонентов продукта и являются неотъемлемой частью определения архитектуры.
Разработка концепций и сценариев использования системы
Разработка концепций и сценариев использования системы является первым шагом процесса анализа и утверждения требований, который представлен на рис. 3.
Окружающая рабочая среда может оказать воздействие на способность удовлетворить нужды и ожидания заинтересованных сторон, накладываемые ограничения и интерфейсы. Такие воздействия следует проанализировать с учетом возможности реализации, ограничений по стоимости, объема потенциального рынка и стратегии закупок.
Целью этого анализа является определение возможных требований к концепции продукта, которые позволят удовлетворить нужды, ожидания и ограничения заинтересованных сторон. Эта концепция затем может быть преобразована в четкие требования. При трансляции концепции в требования CMMI рекомендует определить параметры для оценки эффективности продукта и требуемую функциональность, рассмотреть все возможные модели использования продукта и создать временную последовательность функций.
Сценарий представляет собой последовательность событий, которые могут произойти при использовании продукта. Сценарий обычно используется, чтобы «высветить» некоторые потребности заинтересованных сторон. В отличие от сценария, концепция работы описывает, каким образом продукт используется или работает. Концепция зависит как от проектных решений, так и от сценария. Обычно при начальной выработке концепции альтернативные решения еще не существуют, поэтому концептуальные решения разрабатываются для анализа требований. По мере разработки технических решений и соответствующей разработки детальных требований нижнего уровня концепция работы может уточняться. Точно так же, как проектное решение для продукта может стать требованием для компонента продукта, концепция работы может стать сценарием (требованием) для компонентов продукта.
Концепции и сценарии обычно включают функциональность, характеристики, поддержку и обслуживание, которые должны быть согласованы с уровнем детализации потребностей, ожиданий и ограничений, характеризующих реальные условия работы продукта. Поскольку разработка концепций работы и сценариев представляет собой итеративный процесс, они должны периодически анализироваться для уточнения требований и выявления новых требований.
Когда продукты и их компоненты выбраны, разрабатывается детальная концепция работы, которая определяет взаимодействие продукта, конечного пользователя и окружающих условий и удовлетворяет потребностям работы, обслуживания и поддержки.
Рекомендуемые рабочие продукты — результаты этапа «Разработать концепции и сценарии использования системы»:
- концепция работы;
- концепции установки, обслуживания, поддержки и прекращения эксплуатации;
- сценарии использования системы (Use cases);
- новые требования.
Выработка определения требуемой функциональности
Определение функциональности, которое часто называют функциональным анализом, представляет собой описание того, для чего предназначен продукт, и может включать действия, последовательность, входы, выходы и другую информацию о том, как продукт будет использоваться.
Функциональный анализ не равносилен структурному анализу в программных разработках и не предполагает функционально-ориентированного программного дизайна. В объектно-ориентированном программном дизайне этот этап относится к определению услуг. Определение функций, их логическую группировку и связь с требованиями часто называют функциональной архитектурой.
В определение требуемой функциональности CMMI включает:
- анализ и количественное определение функциональности, требуемой конечными пользователями;
- анализ требований для установления логических или функциональных разделов (подфункций);
- распределение требований по группам на основе установленных критериев (например, аналогичная функциональность, характеристики или ассоциации);
- последовательность критических по времени функций, как в начале разработки, так и в ходе разработки.
Рекомендуемые рабочие продукты — результаты этапа «Выработать определение требуемой функциональности»:
- функциональная архитектура (определение функций, их логическая группировка и их связь с требованиями);
- сценарии использования системы (Use cases);
- объектно-ориентированный анализ.
Литература
- CMMI-SE/SW Version 1.1, Staged Representation, Technical Report CMU/SEI-2002-TR-012, SEI
- CMMI-SE/SW Version 1.1, Continuous Representation, Technical Report CMU/SEI-2002-TR-012, SEI
- Boris Mutafelija and Harvey Stromberg. «Systematic Process Improvement Using ISO 9001:2000 and CMMI» SEI, 2003.
- Interpreting Capability Maturity Model Integration (CMMI) for Service Organizations. Technical Note CMU/SEI-2003-TN-005, 2003.
- CMMI Interpretive Guidance Project. Special Report CMU/SEI-2003-SR-007.
- Bruce Allgood, Mile Phillips. «CMMI v.1.1 Tutorial». SEI, 2002.
Кирилл Мильман (kmilman@regent.ru) — руководитель службы управления качеством холдинговой компании «Регент», Семен Мильман (SMilman@ibs.ru) директор по качеству центра аутосорсинга DATAFORT группы компаний IBS (Москва).
