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

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

В ходе развития проекта требования неоднократно корректируются и изменяются. Так как требования связаны друг с другом, изменения, вносимые в одно требование, могут повлиять на связанные с ним другие требования. Требования так же являются основаниями для включения в продукт тех или иных функциональных возможностей, поэтому изменения в требованиях могут потребовать доработки или переработки продукта. Таким образом, для того чтобы проект не потерял управляемость и был создан в срок в рамках бюджета, необходимо выработать и утвердить процедуру внесения изменений в требования.
Для внесения и обсуждения изменений в требования, как правило, выделяется отдельный вид требований, называемый запросами на изменение. Создавать запросы на изменение могут все заинтересованные участники проекта, однако, до того как запрос не будет просмотрен, проанализирован и утвержден аналитиком требований. При анализе аналитик выявляет степень влияния предлагаемых доработок на требования, сроки реализации и бюджет. Затем внесенные изменения либо утверждаются, либо отвергаются.
Пример разработки требований.
Как известно, теория без практики - абсолютно бесполезна. Оставшаяся часть статьи будет посвящена рассмотрению примера управления требованиями. Цель данной части статьи показать практические приемы управления требованиями с помощью существующих средств автоматизации управления требованиями.
На сегодняшний день на рынке наиболее известными средствами управления требованиями являются:.
• Rational Requisite Pro.
• Borland Caliber RM.
• Telelogic DOORS.
• Popkin Software Architector.
В качестве инструмента управления требованиями в нашем примере я использовал CaliberRM по нескольким причинам:.
1.
Реализация объектно-ориентированного подхода управления требованиями.
2.
Простота.
3.
Наличие подробной документации.
4.
Возможность организации групповой работы.
5.
Широкие возможности.
6.
Доступность evaluation лицензии