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