Классификация и специфицирование требований

Выбор формы описания варианта использования

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

• Размеры проекта,
• Важность проекта и варианта использования,
• Традиции, сложившиеся в коллективе "Заказчик-Разработчик".

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

Степень подробности зависит также от критичности проекта в целом и критичности варианта использования в данном проекте. А.Коберн делит все программные проекты по степени критичности на 4 категории: исходя из цены ошибок: "проекты, ошибки в которых могут привести к…":

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

Очевидно, что военные системы, либо системы управления сложными техническими объектами требуют более скрупулезного документирования, в том числе - и на уровне описания вариантов использования.

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

Наконец, спецификация вариантов в стиле Коберна, стиле RUP, в табличной форме, с использованием псевдокодов или графических конструкций (см. материалы "Расширенный анализ требований. Моделирование" ) во многом определяется субъективным выбором автора прецедентов и сложившимся опытом работы с заказчиком проекта.

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

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

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

Описания требований должны быть операбельны. Для этого все требования должны учитываться в той или иной учетной системе, будь то электронная таблица MS Excel, специализированная база данных, либо интегрированная среда управления изменениями. При регистрации требования оно проходит классификацию в соответствии с определенной системой признаков. Основные признаки (атрибуты) требований были рассмотрены в "Понятие требования. Классификации требований" . Кроме того, для оперативного управления требованиями бывает полезно назначить им такие свойства, как проект, ответственное лицо, статус, риск, степень законченности и т.п. В RUP для управления атрибутами требований предусмотрен артефакт "Атрибуты требований".

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

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

Трассируемость описывается в виде дерева, показывающего в графическом виде входящие и (или) исходящие связи трассируемости (см. "Введение в управление требованиями" ).