Задача: Управление зависимостями
В этой задаче рассмотрена процедура управления областью действия проекта и изменениями требований с помощью зависимостей между требованиями.
Дисциплины: Требования
Назначение

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

Взаимосвязи
Шаги
Присвоение атрибутов

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

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

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

Ниже приведен пример набора возможностей инструмента RequisitePro из документаВидение вместе со связанными атрибутами требований. Прибыль определена в соответствии с мнением заказчика, а трудозатраты указаны разработчиками.

Функции  Уровень прибыли  Уровень трудозатрат  Уровень риска  Уровень воздействия
на архитектуру 
Уровень стабильности 
Функция 1: Сохранение и восстановление критериев сортировки и фильтрации  Высокий  Низкий  Низкий  Низкий  Высокий 
Функция 2: Возможность сохранения документов RequisitePro в формате Microsoft ® Word®.   Высокий  Низкий  Низкий  Низкий  Высокий 
Функция 3: Отображение удаленных требований в окне просмотра.   Средний  Высокий  Средний  Низкий  Средний 
Функция 4: Поддержка атрибутов типа данных денежной единицы.   Средний  Средний  Низкий  Низкий  Средний 
Функция 5: Поддержка типа документов "Все" (простой способ определения общих атрибутов нескольких типов документов).   Высокий  Средний  Средний  Низкий  Высокий 
Функция 6: Возможность выбора требований на панели и перехода к документу Word.   Высокий  Средний  Средний  Низкий  Высокий 
Функция 7: Отображение атрибута требования в тексте документа требования.   Средний  Средний  Средний  Низкий  Высокий 
Функция 8: Мастер создания проекта  Высокий  Высокий  Высокий  Высокий  Средний 
Функция 9: Быстрое создание требований (без открытия окна диалога при создании).   Высокий  Низкий  Низкий  Низкий  Высокий 
Функция 10: Автоматическое сохранение проекта (архив проектов).   Средний  Низкий  Средний  Низкий  Средний 
Функция 11: Изменение атрибутов выбранного набора требований.   Средний  Высокий  Средний  Низкий  Средний 
Функция 12: Возможность дублирования структуры проекта, позволяющая пользователям создавать новые проекты на основе старых.   Высокий  Средний  Средний  Низкий  Низкий 
Функция 13: Повышенная эффективность печати и идентификации требований.   Низкий  Высокий  Средний  Низкий  Высокий 
Функция 14: Порт Microsoft® Windows95®.  Высокий  Средний  Высокий  Высокий  Высокий 

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

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

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

Задание и проверка трассируемости

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

Управление изменяющимися требованиями

Изменения требований управляются в соответствии с планом управления требований. Ниже приведены дополнительные рекомендации:

Пересмотр атрибутов требований и трассируемости

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

Иерархическое управление изменениями

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



Дополнительные сведения