Заметки консультанта

Шамрай Александр Владимирович

CMMI DEV v1.3 – Разработка Требований

Posted by Шамрай Александр на Февраль 21, 2011

Перевод Шамрай А.В.

Инженерная Процессная область уровня зрелости 3

Назначение

Назначением Разработки Требований (РТ) является выявление, анализ и установка требований заказчика, продукта и компонентов продукта.

Вступительный комментарий

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

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

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

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

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

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

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

Анализ используется, чтобы понять, определить и выбрать требования на всех уровнях от конкурирующих альтернатив. Этот анализ включают следующее:

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

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

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

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

  • Ограничения различных типов
  • Технологические ограничения
  • Затраты и управление затратами
  • Ограничение по времени и управление графиком
  • Риски
  • Рассмотрение вопросов подразумеваемых, но прямо не указанных заказчиком или конечным пользователем
  • Факторы, введенные уникальными бизнес соображениями разработки, правилами и законами

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

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

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

В Agile среде потребности и идеи заказчика итеративно выявляются, разрабатываются, анализируются и утверждаются. Требования описаны в таких формах, как пользователь истории, сценарии, сценарии использования, журнал продукта и результаты итераций (работающий код в случае программного обеспечения). Какие требования будут разработаны в данной итерации, решается оценкой риска и приоритетом, основанным на том, что осталось в журнале продукта. Какие детали требований (и другие артефакты) будут документироваться, определяется потребностями координации (между членами команды, командами и дальнейшими итерациями) и риском потерять то, что было изучено. Когда заказчик в команде, может еще присутствовать необходимость для отдельных заказчиков и документации к продукту позволить изучить несколько решений. В то время как возникает решение, ответственность для производных требований назначаются соответствующим командам. (См. «CMMI при использовании Agile подходов» в части I.)

Связанные процессы

См. процессную область Интеграция Продукта для получения дополнительной информации об обеспечении совместимости интерфейсов.

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

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

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

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

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями.

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

Перечень специфических целей и практик

  • СЦ 1 Разработать Требования Заказчика
    • СП 1.1 Выявляйте Потребности
    • СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика
  • СЦ 2 Разработать Требования к Продукту
    • СП 2.1 Устанавливайте Требования к Продукту и Компонентам Продукта
    • СП 2.2 Распределите Требования к Компонентам Продукта
    • СП 2.3 Идентифицируйте Требования к Интерфейсам
  • СЦ 3 Выполнить Анализ и Валидацию Требований
    • СП 3.1 Устанавливайте Операционную Концепцию и Сценарии
    • СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества
    • СП 3.3 Анализируйте Требования
    • СП 3.4 Анализируйте Требования для Достижения Баланса
    • СП 3.5 Выполняйте Валидацию Требования

Специфические практики по целям

СЦ 1 Разработать Требования Заказчика

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

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

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

СП 1.1 Выявляйте Потребности

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

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

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

  • Технологические демонстрации
  • Рабочие группы контроля взаимодействия
  • Рабочие группы технического контроля
  • Промежуточный проектный анализ
  • Анкетирование, интервью и сценарии (операционные, поддержки и разработки), полученных от конечных пользователей
  • Операционный анализ, анализ поддержки и разработки и анализ задач конечных пользователей
  • Семинары с заинтересованными сторонами по выявлению атрибутов качества
  • Прототипы и модели
  • Мозговой штурм
  • Развертывание Функций Обеспечения Качества
  • Исследования рынка
  • Бета-тестирование
  • Извлечение из источников, таких как документы, стандарты или спецификации
  • Наблюдение за существующими продуктами, условиями работы и рабочими моделями
  • Сценарии использования
  • Пользовательские истории
  • Предоставление небольших инкрементальных «вертикальных срезов» функциональности продукта
  • Анализ бизнес сценариев
  • Обратный инжиниринг (для наследуемых продуктов)
  • Исследования удовлетворенности заказчиков

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

  • Бизнес-политики
  • Стандарты
  • Предыдущие архитектурные решения проектирования и принципы
  • Бизнес требования среды (например, лаборатории, испытательные и другие средства, инфраструктура информационных технологий)
  • Технологии
  • Наследование продуктов или компонентов (компонентов продукта повторного использования)
  • Нормативные уставы

Примеры рабочих продуктов:

1. Результаты деятельности выявления требований

Подпрактики

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

СП 1.2 Трансформируйте Потребности Заинтересованных Сторон в Требования Заказчика

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

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

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

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

Пример рабочих продуктов

1. Требования заказчиков с установленными приоритетами

2. Ограничения заказчика на проведение верификации

3. Ограничения заказчика на проведение валидации

Подпрактики

1. Трансформируйте потребности, ожидания, ограничения и взаимодействия заинтересованных сторон в документированные требования заказчика.

2. Установите и поддерживайте установку приоритетов для требований для функциональности и атрибутов качества.

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

3. Определите ограничения для верификации и валидации.

СЦ 2 Разработать Требования к Продукту

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

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

Требования выделяются в функции продукта и компонентов продукта, включая объекты, людей и процессы. В случае итерационной или инкрементальной разработки, требования также распределяются по итерациям или инкрементам на основе приоритетов заказчика, технических проблем и целей проекта. Трассировка требований до функций, объектов, тестов, проблем или других сущностей документируется. Установленные требования и функции (или другие логические сущности) являются основой для синтеза технического решения; однако, когда архитектура определена или проявляется, она служит основой основ для направления распределения требований в решении. После того как внутренние компоненты разработаны, определяются дополнительные интерфейсы и устанавливаются требования к взаимодействиям.

См. процессную область Управление Требованиями для получения дополнительной информации о поддержке двунаправленной трассировки требований.

СП 2.1 Установите Требования к Продукту и Компонентам Продукта

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

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

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

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

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

См. процессную область Управление Требованиями для получения дополнительной информации об управлении требованиями.

Пример рабочих продуктов

1. Производные требования

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

3. Требования к компоненту продукта

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

Подпрактики

1. Разрабатывайте требования в технических терминах, необходимых в отношении продукта и компонента продукта.

2. Выведите требования, которые появятся в результате проектных решений.

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

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

Архитектурные решения, такие как выбор архитектурных шаблонов, вводят дополнительные производные требования для компонентов продукта. Например, Шаблон Слоя будет ограничивать зависимости между определенными компонентами продукта.

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

Примеры мер атрибутов качества включают следующее:

  • Время ответа до 1 секунды
  • Доступность системы 99% времени
  • Внедрение изменений не превышает недельные трудозатраты одного сотрудника

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

См. процессную область Управление Требованиями для получения дополнительной информации о поддержке двунаправленной трассировки требований.

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

СП 2.2 Выделите Требования к Компонентам Продукта

Выделите требования для каждого компонента продукта.

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

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

Пример рабочих продуктов

1. Таблицы распределения требований

2. Предварительное распределение требования

3. Ограничения проектирования

4. Производные требования

5. Связи между производными требованиями

Подпрактики

1. Распределяйте требования по функциям.

2. Распределяйте требования по компонентам продукта и архитектуре.

3. Распределяйте ограничения проектирования по компонентам продукта и архитектуре.

4. Распределяйте требования по инкрементам поставки.

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

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

СП 2.3 Идентифицируйте Требования к Интерфейсам

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

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

См. процессную область Техническое Решение для получения дополнительной информации об обеспечении совместимости интерфейсов.

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

Пример рабочих продуктов

1. Требования к интерфейсам

Подпрактики

1. Определить взаимодействия как внешние, так и внутренние по отношению к продукту (например, между функциональными разделениями или объектами).

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

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

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

2. Разрабатывайте требования для идентифицированных взаимодействий.

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

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

СЦ 3 Выполнить Анализ и Валидацию Требований

Требования проанализированы и провалидированы.

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

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

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

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

СП 3.1 Устанавливайте Операционные Концепции и Сценарии

Установите и поддерживайте операционные концепции и связанные с ними сценарии.

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

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

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

Пример рабочих продуктов

1. Операционная концепция

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

3.Концепции утилизации

4. Сценарии использования

5. Повременные сценарии

6. Новые требования

Подпрактики

1. Разрабатывайте операционные концепции и сценарии, которые включают эксплуатацию, установку, разработку, обслуживание, поддержку и утилизацию по мере необходимости.

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

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

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

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

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

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

СП 3.2 Устанавливайте Определение Необходимой Функциональности и Атрибутов Качества

Устанавливайте и поддерживайте определение необходимой функциональности и атрибутов качества.

Один из подходов к определению требуемой функциональности и атрибутов качества для анализа сценариев использования, который некоторые называют «Функциональный анализ», направлен на описание, что продукт должен делать. Это функциональное описание может включать в себя действия, последовательности, входы, выходы или другую информацию, которая говорит, каким образом продукт будет использоваться. Результирующее описание функций, логических групп функций и их связь с требованиями называется функциональной архитектурой. (См. определение «Функциональный анализ» и «функциональная архитектура» в глоссарии.)

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

Пример рабочих продуктов

1. Определение необходимой функциональности и атрибутов качества

2. Функциональная архитектура

3. Диаграммы активности и сценарии использования

4. Объектно-ориентированный анализ с идентифицированными сервисами или методами

5. Архитектурно значимые требования атрибутов качества

Подпрактики

1. Определяйте ключевые направления миссии и бизнеса.

2. Определяйте желательные функциональность и атрибуты качества.

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

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

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

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

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

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

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

8. Распределяйте требования по функциям и подфункциям (или другим логическим сущностям).

СП 3.3 Анализируйте Требования

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

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

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

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

Пример рабочих продуктов

1. Отчеты по дефектам требований

2. Предлагаемые изменения в требования для исправления дефектов

3. Ключевые требования

4. Меры технических характеристик

Подпрактики

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

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

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

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

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

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

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

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

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

СП 3.4 Анализируйте Требования для Достижения Баланса

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

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

Пример рабочих продуктов

1. Оценка рисков, связанных с требованиями

Подпрактики

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

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

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

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

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

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

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

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

СП 3.5 Выполняйте Валидацию Требования

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

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

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

  • Анализ
  • Симуляция
  • Построение прототипов
  • Демонстрация

Пример рабочих продуктов

1. Записи по методам и результатам анализа

Подпрактики

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

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

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

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

Реклама

комментария 2 to “CMMI DEV v1.3 – Разработка Требований”

  1. Александр Кондаков said

    Намеренно молчал по поводу прошедших публикаций,но…
    Ну почему customer «клиентом» стал-то?

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: