Разработка системной модели

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

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

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