1.2 Пирамида Требований
В зависимости от формата, источника и общих характеристик, требования могут быть разделены на различные типы. Несколько типов требований, наиболее часто использующихся в проектах:
Потребности заинтересованного лица: требование от заинтересованного лица.
Функциональная особенность: предоставляемая системой функциональность, обычно формулируемая бизнес-аналитиком; назначение особенности – удовлетворить потребности заказчика.
Сценарий Использования (Use Case): описание поведения системы в терминах последовательности действий.
Дополнительное требование: другое требование (обычно нефункциональное), которое не может быть охвачено сценариями использования.
Тестовые сценарии (Test Cases): спецификация тестовых исходных данных, условий выполнения и ожидаемых результатов.
Сценарий (Алгоритм, Scenario): особая последовательность действий; определенный путь по сценариям использования.
Эти типы требований могут быть представлены в виде пирамиды, как показано на Рисунке 1.1.
Н
а
верхнем уровне располагаются потребности
заинтересованного лица. На последующих
уровнях находятся функциональные
особенности, сценарии использования и
дополнительные требования. Достаточно
часто на разных уровнях этих требований
могут быть выяснены детали различного
уровня. Чем ниже уровень, тем более
детально описывается требование.
Например, потребность может быть
следующей: «Данные должны быть
неизменными». Функциональная особенность
этого требования будет: «Система должна
использовать реляционную базу данных».
На уровне дополнительных требований,
требование еще более точное: «Система
должна использовать базу данных Oracle
9i».
Чем дальше вниз, тем более детальным
становится требование. Один из лучших
способов управления требованиями –
обобщать требования, по крайней мере,
на двух различных уровнях. Например,
документ Концепция («Vision»)
содержит высокоуровневые требования
(особенности), а низшие уровни пирамиды
представляют требования на более
детальном уровне. У вышестоящих
заинтересованных лиц (таких, как
вице-президент) нет времени читать 200
страниц детально описанных требований.
Но можно надеяться, что они смогут
прочитать 12 страниц Концепции.
Рисунок 1.1. Пирамида требований.
Однако то, какой будет степень детализации требований на каждом уровне, зависит от бизнес-аналитиков. Нет ничего плохого в том, чтобы расположить достаточно подробно описанные требования заинтересованных лиц на уровень потребностей заинтересованных лиц.
Главное отличие между потребностями и функциональными особенностями – в источнике требований. Потребности поступают от заинтересованных лиц, а функциональные особенности формулируются бизнес-аналитиками.
Роль тестовых сценариев – проверить, корректно ли были реализованы сценарии использования и дополнительные требования. Алгоритмы помогают получить сценарии использования из тестовых сценариев, а также способствуют проектированию и реализации определенных путей через сценарии использования. В RequisitePro мы можем определить многие другие типы требований, такие как термины справочника и действующие лица. Они не являются в чистом виде требованиями, подходящими под приведенное нами в начале главы определение требований. Но если мы представим их в RequisitePro в качестве требований, мы получим возможность отслеживать их атрибуты и трассировку (связь), используя те же механизмы, применяемые к остальным типам требований.