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

Определение требования и заинтересованного лица

Управление требованиями

Требование – условие или особенность, которой должна удовлетворять система.

Требованием может быть:

– функциональность, необходимая заказчику или пользователю для разрешения проблем (или получения прибыли).

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

– ограничение, наложенное заинтересованным лицом.

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

В качестве заинтересованного лица можно рассматривать:

– Любого, участвующего в разработке системы (бизнес-аналитики, дизайнеры, кодировщики, тестеры, менеджеры проектов, менеджеры по внедрению, дизайнеры сценариев использования, графические дизайнеры).

– Любого, кто привносит свои знания в систему (эксперты предметной области, авторы документов, которые были использованы для сбора требований, собственники веб-сайтов, ссылки на которые были предоставлены).

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

– Лица, вовлеченные в управление, настройку и сопровождение системы (хостинговая компания, справочная служба).

– Поставщики стандартов и регламентов (стандарты устанавливаются поисковыми механизмами согласно содержанию веб-сайта, политическим нормам, а также порядку налогообложения в конкретном штате).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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