The Process Road Between Requirements and Design
The software engineering literature contains many examples of methods, tools and techniques that claim to facilitate a verity of requirements engineering and design activities. Guidance on how use activities are related within a coherent software development process is much less apparent. A central problem that makes such guidance difficult to achieve is that requirements engineering addresses problem domains whereas design addresses solution domains. This is in the face of frequent changes in requirements contrasted with the need for stable design solutions. The traditional characterization of the relationship between requirements and design is to view design as a refinement of requirements. Consequently, there is a bias in the forward direction (from requirements to design) with the reverse direction only considered for verification purposes (that is, to verify that a design solution addresses specified requirements). In reality, however, there is a significant influence of design solutions on requirements, with particular design solutions changing, even driving, the requirements engineering process (e.g., requirements changes resulting from new facts learned during design, or particular design architectures constraining the requirements that can be met). Clearly then, there is a need to study the relationship between artifacts and processes at the requirements and design engineering stages of development. A desirable objective is to provide guidance for navigating this network of relationship, and to collect and generate (new) information in doing so. We begin by examining some of the causes and consequences of changing requirements and contrast these with our desire to construct stable design structures, such as software architectures. This will give us some processes that synthesizes requirements and design engineering processes and products.<
Dieser Eintrag ist freigegeben.