Your what is my how: Why requirements and architectural design should be iterative

Abstract

Systems are naturally constructed in hierarchies in which design choices made at higher levels of abstraction levy requirements on system components at lower levels of abstraction. Thus, whether an aspect of the system is a design choice or a requirement depends largely on one's location within the hierarchy of system components. In addition, it is often the case that systems are not constructed top-down, but rather middle-out; compatibility with existing systems and architectures, or availability of specific physical components may influence high-level requirements. Despite these facts, several of the reference models commonly used for requirements, including the four-variable model and world machine model, do not account for hierarchical decomposition. In this position paper, we argue that requirements and architectural design should be more closely aligned: that requirements reference models should account for hierarchical system construction, and that architectural design notations should better support specification of requirements for system components. We briefly describe work to this end that was performed on the META II project and describe the gaps in this work that need to be addressed to meet practitioner needs.