Управление требованиями представляет собой систематизированный подход к обнаружению, документированию, организации и
отслеживанию требований на изменение системы.
Мы определяем требование как "условие или возможность, которым должна соответствовать система".
Мы формально определяем управление требованиями как систематизированный подход к:
-
выявлению, организации и документированию требований к системе
-
установлению и обеспечению согласования между заказчиком и коллективом проекта по требованиям на изменение системы
Ключевыми моментами эффективного управления требованиями является обеспечение четкой формулировки требований вместе с
соответствующими атрибутами и возможность отслеживания для других требований и артефактов проекта.
Сбор требований может представляться достаточно простой задачей. Однако в действительности в проектах возникают
сложности по следующим причинам:
-
Требования не всегда являются очевидными и приходят из нескольких источников.
-
Требования не всегда удается ясно выразить словами.
-
Существует много различных типов требований на различных уровнях детализации.
-
При отсутствии контроля число требований может стать неуправляемым.
-
Требования связаны между собой и с другими результатами процесса проектирования программного обеспечения.
-
Требования имеют уникальные свойства или значения свойств. Например, они необязательно являются одинаково важными
или имеют неодинаковую сложность исполнения.
-
Существует много заинтересованных сторон, что означает необходимость управления требованиями со стороны групп
сотрудников с пересекающимися функциями.
-
Требования изменяются.
Не имеет значения, насколько тщательно были определены требования. Всегда существуют вещи, которые изменяются.
Сложность управления изменением требований заключается не только в том, что при изменении требования необходимо
затратить время на реализацию определенной новой функциональной возможности, но также и в том, что изменение одного
требования может повлиять на другие требования. Управление изменениями включает установление базовой линии, определение
того, какие зависимости следует проследить, установление возможности трассировки между связанными элементами и
реализацию контроля за изменениями.
Рекомендуемым методом организации функциональных требований является использование вариантов. Вместо ненумерованного
списка требований организуйте их таким образом, чтобы было понятно, как можно использовать систему. Это обеспечит
большую полноту и согласованность, а также лучшее понимание важности требования с точки зрения пользователя.
В традиционной объектно-ориентированной модели системы часто бывает трудно определить, каким образом система выполняет
то, что она должна делать. Эта сложность связана с отсутствием "красной нити", проходящей по системе, когда она
выполняет определенные задачи. В Rational Unified Process (RUP) варианты являются такой нитью, поскольку они определяют
поведение системы. Варианты не являются частью традиционной ориентации на объекты, однако их важность даже более
очевидна. Это также подчеркивается тем фактом, что варианты являются частью Unified Modeling Language.
В RUP применяется "управляемый вариантами подход". Это означает, что варианты, определенные для системы, являются
основой всего процесса разработки.
Варианты играют роль в нескольких разделах.
-
Концепцию вариантов можно использовать для представления бизнес-процессов. Этот вид вариантов называется
"бизнес-вариант". Он описан в разделе Бизнес-моделирование.
-
Варианты как требования в программному обеспечению описаны в разделе Требования. Варианты составляют важную
фундаментальную концепцию, которая должна быть принята и заказчиком, и разработчиками, и тестерами системы.
-
В разделе Управление проектом варианты применяются как основа планирования итерационной разработки.
-
Варианты реализуются в модели проектируемой системы как часть раздела Анализ и проектирование. Реализации вариантов
описывают, как вариант поддерживается с точки зрения взаимодействующих объектов в модели проектируемой системы.
-
Варианты в конечном счете становятся реализованными и тестируемыми сценариями, и таким образом важны в разделах
Реализация и Тестирование. Они применяются для получения тестовых вариантов и тестовых сценариев; функциональность
системы проверяется путем выполнения тестовых сценариев, которые осуществляют каждый вариант.
-
В разделе Развертывание варианты формируют основание для того, что описывается в руководствах пользователя.
Прецеденты также можно использовать для определения порядка блоков продукта. Например, пользователь может получить
систему, настроенную с определенным набором вариантов.
|