ИЗМЕНЯЮЩИЕСЯ ТРЕБОВАНИЯ

ИЗМЕНЯЮЩИЕСЯ ТРЕБОВАНИЯ

Традиционные подходы разбивали требования к системе на требования к подсистемам, требования к подсистеме — на требования к компонентам, а требования к компоненту — на требования к отдельным блокам. Требования структурировались таким образом, что их трассировка оказывалась довольно простой. Притом, что на ранних стадиях жизненного цикла основное внимание уделялось в первую очередь требованиям, во вторую очередь проектированию, после чего устанавливалась полная трассировка между требованиями и элементами проекта, естественной оказывалась тенденция, при которой структура проектных решений принимала организационные формы, параллельные организационной структуре требований. Поэтому нет ничего удивительного в том, что функциональная декомпозиция проблемной области вела к функциональной декомпозиции области решения.
Большинство современных архитектур, использующих коммерческие компоненты, наследуемые компоненты, распределенные ресурсы и объектно-ориентированные методы, не может тривиально выводиться из требований, которым они удовлетворяют. На сегодняшний день между требованиями и элементами проекта устанавливаются сложные связи типа один к одному, многие к одному, один ко многим, а также условные связи, зависящие от времени и состояния.
Системные требования верхнего уровня по-прежнему представляются в форме общей концепции, однако требования более низкого уровня выражаются критериями оценки, применимыми к каждой промежуточной версии. Эти рабочие продукты (см. рис. 15.3) имеют тенденцию изменяться по ходу процесса, становясь все более и более точными по мере того, как развивается жизненный цикл и понимание требований становится все более зрелым. В этом и заключается фундаментальное отличие от подхода к работе с требованиями, при котором погоня за точностью начинается на слишком ранних стадиях жизненного цикла.
Рис. 15.3. Организация программных компонентов, являющаяся результатом применения современного процесса