Model-Driven Development for Requirements Engineering: The Case of Goal-Oriented Approaches

Abstract

Abstract-Goal-Oriented Requirements Engineering (GORE) has received increasing attention over the past few years. There are several goal-oriented approaches, each one using different kinds of models. We believe that it would be useful to relate them or even perform transformations among them automatically, in order to understand their similarities and differences, their advantages and disadvantages, allowing a possible migration or comparison between approaches. This is something that has not received enough attention. In this paper we propose the definition and implementation of goal model transformations between i* and KAOS. As an immediate contribution, the approach can be used to migrate from one goal model to another through automatic model transformations. This approach also contributes to relate the concepts of i* and KAOS models and will help, for example, a development team in making the decision on which approach to follow, according to the nature of the project and the expressiveness of an approach to represent certain concepts (e.g., obstacles are represented explicitly in KAOS, but not in i*). Another contribution is to facilitate communication among members of the same team, if they are specialized in different approaches.

Automated Completeness Check in KAOS

“…A parent goal may be decomposed, or refined, into child subgoals [20]; a leaf goal has no children. A KAOS goal model is said to be complete when all leaf goals are assigned to agents [23].…”

“…The essence of GORE is to provide an alternative to the traditional systems development paradigm, where systems requirements are analysed based on the intentions/why/motivations rather than the behaviour of the system. Among varieties of competing GORE languages such as i* [28], GBRAM [2], and BMM [21], KAOS [23] [20] [6] [10] [17] [26] is one of the most popular and widely used languages [10]. It can be used in both early, and late requirement phases, but it mainly focuses on analysing system goals [18].…”

“…Since KAOS has been widely used and is representative of other GORE languages, we use it as the basis of our study. Currently KAOS is receiving attention both in research, and practice [19] [20]. For instance, it has been applied in requirements acquisition, specification and analysis [19] [1]; enterprise architecture alignment [22] [8] [5]; solving service mediation problems [3]; model driven development [20]; and business process modeling [16].…”

“…KAOS can provide a basis for mechanical language processing in MDE such as model transformation. For instance Monteiro et al proposed and implemented an automatic transformation between KAOS and i* models, and suggests that such transformation can support a migration from i* model to KAOS model and vice versa, and offers flexibility for choice of GORE language to be used in a software development project [19] [20]. MDE Mechanical language processing such as model transformation depends on inter mapping and manipulations of model elements in the different models concerned [20], thus an incomplete model can lead to incomplete mapping and erroneous MLP in MDE, thereby compromising the benefits offered by integrating GORE with MDE.…”

“…For instance Monteiro et al proposed and implemented an automatic transformation between KAOS and i* models, and suggests that such transformation can support a migration from i* model to KAOS model and vice versa, and offers flexibility for choice of GORE language to be used in a software development project [19] [20]. MDE Mechanical language processing such as model transformation depends on inter mapping and manipulations of model elements in the different models concerned [20], thus an incomplete model can lead to incomplete mapping and erroneous MLP in MDE, thereby compromising the benefits offered by integrating GORE with MDE. Few manual techniques for completeness checks in GORE model are available in literature, for instance the use of Temporal Logic to check completeness is proposed in [25], while Goal-Question-Metric (GQM) techniques has been proposed in [9].…”