Miguel Goulão

We can regard Domain-Specific Languages (DSLs) as User Interfaces (UIs) because they bridge the gap
between the domain experts and the computation platforms. Usability of DSLs by domain experts is a key
factor for their successful adoption. The few reports supporting improvement claims are persuasive, but
mostly anecdotal. Systematic literature reviews show that evidences on the effects of the introduction of
DSLs are actually very scarce. In particular, the evaluation of usability is often skipped, relaxed, or at
least omitted from papers reporting the development of DSLs. The few exceptions mostly take place at
the end of the development process, when fixing problems is already too expensive. A systematic
approach, based on techniques for the experimental evaluation of UIs, should be used to assess suitability
of new DSLs. This chapter presents a general experimental evaluation model, tailored for DSLs’
experimental evaluation, and instantiates it in several DSL’s evaluation examples.

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 argue 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.