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

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

1. Анализ запроса на изменение;

2. Создание (изменение требования)

3. Создание связи запроса с требованиями

4. Прослеживание влияния запроса на требования к системе.

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

Выводы ко второй части.

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

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

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

Литература

[1] Д. Леффингуэлл, Д. Уидриг, Принципы работы с требованиями к программному обеспечению. Унифицированный подход, Вильямс, 2002

[2] K. Baxter, Understanding Your Users., Morgan Kaufmann Publishers,2005

[3] IIBA, A guide to the Business Analysis Body of Knowledge, v1.6, 2006

[4] Г. Буч, А. Якобсон, Дж. Рамбо, UML2-е издание, Питер, 2006.

Часть 3. Качество требований

Рубрика: Качество требований,Статья,Требования

Данная статья является третьей в серии статей, которые я публикую в рамках темы “Управление качеством требований”. Введение к серии было представлено на данном сайте в теме “Управление качеством требований. Начало.” от 12 декабря 2009 года.

В третьей части приведено краткое описание системы менеджмента качества, стандарта ISO 9000 и модели зрелости CMMI, которые берутся за основу поэтапного построения процесса управления требованиями. В данной части также рассмотрены критерии качества требований.Ранее опубликованные материалы можно посмотреть здесь:Управление качеством требований. Начало Управление качеством требований. Часть 1. Требования Управление качеством требований. Часть 2. Управление требованиями