Спецификация нефункциональных требований

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

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

Атрибуты требований.

Описание требований должны быть операбельными.

Для этого все требования должны учитываться в той или иной учетной системе, будь то:

- таблица в Excel;

- спецификация БД;

- интегрированная среда управления изменениями.

При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены ранее.

Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.д.. В RUP для управления атрибутами требований предусмотрен артефакт «Атрибуты требований».

Артефакт «Атрибуты требований», предлагаемый RUP, представляет собой репозиторий текстов требований, их атрибутов и трассируемости.

Атрибуты требований представляются матрицей обратных??? требований для каждого типа требований.

Для каждого требования указана функция его соответствия атрибутов.

Примеры: статус во времени, приоритет, важность, риск...

ТЕМА7: Расширенный анализ требований. Моделирование

Цели моделирования

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

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

1) Требования можно формулировать на разных уровнях абстракции

2) Применение визуальных средств описания требований (моделирование)

Имеются 3 рекомендации по целям моделирования:

- анализ требований призван изучать взаимоотношения АИС и ее среды, т.е. пользователей, сетевых и системных компонент, находящихся вне системы.

- анализ требований должен находить ответ на то, что делает система, абстрагируясь от деталей реализации, т.е. как она это делает

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