Towards Requirements and Architecture Co-evolution

Abstract

The relationship between requirements and architectures is an important research field on software engineering. One of its challenges is to provide proper support for their co-evolution, i.e., how to assess the mutual impact of requirements and architecture changes on each other, as well as how to react to these changes in order to prevent misalignment between them. We advocate the use of a single goal model to express both requirements and architectural concerns. In this paper we put forward an approach for requirements and architecture co-evolution considering such a model. Moreover, we outline the reasoning required in order to support forward and backward co-evolution of service oriented systems.

Systematizing the Service-Oriented Requirements Engineering through i* Framework and Web Services

“…The drawbacks of the i* Framework, considering SORE context, are the following: (i) it needs to be adapted in order to monitor the system at runtime [8]; (ii) it needs to be combined with other methodologies to offer support to Quality of Service and variability [8]; (iii) it does not promote models' reuse [9]; (iv) it does not promote heterogeneity [9];…”

“…Its drawbacks could be minimized whether they are combined with other methodologies, as proposed in some works in SORE [7], [8], [9].…”

“…In the SORE context, the main benefits of the i* Framework are the following: (i) it represents system's requirements whilst keeping information about alternatives [8], [20]; (ii) it assists in managing different aspects of the system specification, such as -stability, support conflict detection, analysis, negotiation, and ability to decompose within the problem domain [4]; (iii) it allows rationalizing on modeled requirements [8]; (iv) it exploits intentional dependencies among actors or strategic roles to assist the description of the system and the organizational environment [14]; (v) it is useful to describe architectural aspects acting as a bridge between requirements and architecture [9]; (vi) it facilitates the composition of components [9]; and (vii) it promotes the abstraction and analysis of a problem domain [9].…”

“…(v) it does not present a powerful model configuration support [9]; and (vi) it does not promote the analysis of economic feasibility of the system being modeled [7].…”

“…Therefore, SORE emerged as an important discipline in the context of SOC because of the key role played by requirements engineering in the systems development life cycle [6]. The number of published works in SORE increased in the middle of 2007 with regard to these two main points: (i) the extension of techniques in traditional requirements engineering (for instance, new proposals that employed current techniques as the i* Framework [7], [8], [9] emerged); and (ii) novel techniques designed especially for SOC (for instance, the definition of metamodels Role, Goal, Process and Service -RGPS [6], [10]). …”