6.2Пирамида Требований

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

• Потребности заинтересованного лица: требование от заинтересованного лица.

• Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.

• Сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий.

• Дополнительное требование: другое требование (обычно нефункциональное), которое не может быть охвачено сценариями использования.

• Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.

• Сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.

Эти типы требований могут быть представлены в виде пирамиды, как показано на Рисунке 1.1.

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

Например, потребность может быть следующей: «Данные должны быть неизменными». Функциональная особенность этого требования будет: «Система должна использовать реляционную базу данных». На уровне дополнительных требований, требование еще более точное: «Система должна использовать базу данных Oracle 9i».

Чем дальше вниз, тем более детальным становится требование. Один из лучших способов управления требованиями – обобщать требования, по крайней мере, на двух различных уровнях.

Например, документ Концепция («Vision») содержит высокоуровневые требования (особенности), а низшие уровни пирамиды представляют требования на более детальном уровне. У вышестоящих заинтересованных лиц (таких, как вице-президент) нет времени читать 200 страниц детально описанных требований. Но можно надеяться, что они смогут прочитать 12 страниц Концепции.

Рисунок. Пирамида требований.

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

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

6.3Трассировка (Связь) между Требованиями

Трассировка – это способ представления отношений между требованиями различного уровня в системе. Она помогает определить источник любого требования. Каждая потребность обычно соответствует нескольким функциональным особенностям. Обычно это отношение «многие-ко-многим», т.к. одна потребность может трассироваться ко многим функциональным особенностям, но из нескольких потребностей может быть получена одна функциональная особенность. Одна потребность, соответствующая одной функциональной особенности – это также общий случай. Функциональные особенности соответствуют сценариям использования в отношении «многие-ко-многим». Функциональные особенности также соответствуют дополнительным требованиям в отношении «многие-ко-многим».

Каждый сценарий использования соответствует одному или более сценарию (алгоритму), таким образом, их тип отношений – «один-ко-многим». Сценарии (алгоритмы) соответствуют тестовым сценариям в отношении «один-ко-многим».

Трассировка играет несколько важных ролей:

• Подтверждение, что реализация удовлетворяет всем требованиям: Все, что требовал заказчик, было реализовано.

• Подтверждение, что приложение делает только то, что было заказано: Не реализовывать то, что заказчик никогда не просил.

• Анализ воздействия: Какие элементы будут затронуты при добавлении новых требований или изменении текущих?

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

Элемент трассировки – это элемент проекта, который должен быть получен (трассирован) из другого элемента. В терминах RequisitePro под ним понимается все, что принадлежит какому-либо типу требований. Примеры типов требований в RequisitePro: потребности заинтересованных лиц, функциональные особенности, сценарии использования, действующие лица и термины справочника. В RequisitePro есть очень удобный способ отображения трассировки (связи) с помощью специальных представлений (views).