Что такое область решений

из "Разработка и управление требованиями "

Область решений, эта как раз та область, в которой инженеры задействуют все свои способности и изобретательность, пытаясь решить обозначенные проблемы. Основное отличие области решений от области проблем состоит, безусловно, в том, что разработка требований в области решений начинается с набора четко определенных требований, а разработка требований в области проблем стартует с нечеткой цели или размытого списка общих пожеланий. Конечно же, оценка, - насколько хорошо сформулированы требования, поступающие на вход области решений, - зависит от квалификации и аккуратности специалистов организации заказчика, которые создавали этот список (в области проблем). Самый идеальный случай - все входящие требования хорошо сформулированы и каждое из них может быть протестировано. [c.129]
Как отмечалось в главе 2, решение достаточно редко выполняется за один подход (см. рис. 6.1). [c.129]
На каждом этапе разработки вначале проводится моделирование и анализ, что, во-первых, улучшает понимание входящих требований, а, во-вторых, обеспечивает надежную базу для последующей разработки производных требований для следующих уровней (этапов). Количество уровней зависят от характера и природы создаваемой системы, а также от степени новизны предлагаемых проектных решений. И совершенно неважно, какое количество уровней вам придется создать, - значение имеет лишь степень детализации решений на каждом из уровней. [c.129]
Первым этапом в системных разработках в области решений обычно является преобразование пользовательских требований в системные. Системные требования как раз и будут определять, что именно система должна выполнять для того, чтобы решать проблемы, поставленные в пользовательских требованиях. На рис. 6.1 схематически проиллюстрировано вышесказанное - приведена ориентировочная последовательность шагов (сверху вниз) универсального процесса разработки системных требований. [c.130]
Появление излишней детализации проектных решений особенно проблематично на первом шаге. Во избежание этого, модель системы на этом этапе (см. рис.6.1) должна быть достаточно абстрактной, позволяя лишь определять необходимую системе функциональность, но не углубляться в ее излишнюю детализацию. [c.130]
Следующим шагом разработки системных требований является создание архитектуры системы. На рис. 6.1 это обозначено в виде второго (сверху) уровня основного процесса. Архитектура должна быть представлена в виде набора компонентов системы, которые, взаимодействуя, и порождают системные свойства, определенные в системных требованиях. [c.130]
На следующем шаге производные требования, вытекающие из процесса разработки архитектурного дизайна (см. нижний уровень на рис. 6.1), определяют те требования, которым должны удовлетворять компоненты системы. [c.130]
Такой процесс разработки требований должен проходить с постепенным углублением в детали реализации. [c.130]
В данной главе мы уделим особое внимание процессу преобразования пользовательских требований в системные, поскольку это самый сложный этап для большинства проектов. [c.130]
Именно на этом этапе, как показывает практика, преждевременные решения появляются слишком быстро. [c.131]

Вернуться к основной статье