Процесса Управления Требованиями

Завершенность

Немногословность

Каждое требование должно быть обозначено только один раз, и не должно перекрываться другим требованием:

Треб.1: Для удобства ввода даты рейса в системе должен быть доступен календарь.

Треб.2: Система должна отображать всплывающее окно с календарем при вводе любой даты.

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

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

Хорошее требование должно удовлетворять как можно большему количеству критериев. Однако они могут быть выражены в виде комбинации вышеперечисленных критериев:

– Изменяемый: Если требование элементарное и немногословное, то оно обычно изменяемое.

– Трассируемое: Если оно краткое и имеет уникальный идентификатор (ID), то оно обычно трассируемое (способное к отслеживанию связи).

Самое простое описание процесса управления требованиями содержит следующие основные пункты:

– Формирование плана управления требованиями.

– Сбор требований.

– Разработка документа Концепции (Vision).

– Создание сценариев использования (Use Cases).

– Дополнительная спецификация.

– Создание тестовых сценариев (Test Cases) из сценариев использования (Use Cases).

– Создание тестовых сценариев (Test Cases) из дополнительной спецификации.

– Проектирование системы.

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

Таблица 1.1.Требования и документы, созданные на каждом шаге.

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