1 Introduction

The Dynamic Variability for Complex, Adaptive Systems (DiVA) project aims to produce a new tool supported methodology with an integrated framework for managing dynamic variability in complex, adaptive systems. The project is comprised of a number of workpackages, each focusing on a particular faade of this problem. The present work is carried out under the workpackage dedicated to the issues of Requirements Engineering for DiVA (workpackage 1). The present survey aims to contribute towards the tasks of: identifying requirements relevant for Requirements Engineering in presence of variability and dynamic changes understanding requirements configuration management and configuration dependency analysis techniques in presence of dynamic variability; sketching the initial outlining for addressing challenges pertaining to analysis for dynamic variability requirements and co-existing, co-dependent configurations of variants at runtime in the DiVA Requirements Engineering Approach which will be developed as part of DiVA project. Moreover, since DiVA intends to devise an approach based on Aspect-Oriented Software Development (ASOD) and Model-Driven Development (MDD) techniques, work on Requirements Engineering in both of these areas is also of high relevance to the survey. Thus, in order to understand the issues related to managing requirements variability in presence of dynamic change using AOSD and MDD techniques, this report needs to survey the current work related to the individual components contributing to this issue. These components are work on: 1. Requirements Engineering for Variability which is being addressed in the area of Software Product Lines; 2. Requirements Engineering for Dynamic Change which is being actively addressed in the area of Ubiquitous and Mobile Computing, in particular Context Modelling for these; 3. Requirements Configuration Management and configuration dependency analysis which is being addressed in the area of Requirements Configuration Management; 4. Aspect-Oriented and Model-Driven Requirements Engineering techniques addressed in these two respective areas.

1.1 Requirements Engineering

In (Lamsweerde 2000) Requirements Engineering is defined as an intertwined combination of the following activities: Domain analysis which refers to study of the environment of the system to be, whereby the relevant stakeholders are identified and interviewed, the problems with the current system are their improvement options are investigated, and the objectives of the future system are defined; Elicitation: alternative models of the target system are analysed with the aim of fulfilling the previously identified objectives. Requirements and assumptions for these models are identified. Negotiation and agreement: the identified alternatives and risks are evaluated to select the best alternative; Specification: requirements and assumptions are formulated precisely; Specification analysis: specifications are checked for inconsistencies, incompleteness, conflicts, and feasibility; Documentation: decisions and their rational and related assumptions are recorded;
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 7 of 48

Evolution: requirements are modified to accommodate corrections, changes or new objectives.

As summarised in (Lapouchnian 2005) all these activities are centred around the modelling of requirements, i.e., building abstract descriptions of the requirements that are amenable to interpretation. (Buhr and Casselman 1996). From perspective of DiVA, domain analysis, elicitation, negotiation and agreement and evolution are the most critical activities, as they relate to problem identification, definition of solution variants, variant selection, and further change adaptation in the selected solution respectively.

1.2 Requirements Engineering for Dynamic Change

The main body of Requirements Engineering work is concerned with static elicitation, representation, and analysis of requirements (Nuseibeh, Kramer et al. 1994; Jackson 2001; Sommerville 2004). The issues of handling changing requirements have also been mainly studied within the context of a static set of requirements. With the recent emergence of a number of continuously dynamically changing mobile and ubiquitous systems the need for consideration of dynamic change at requirements level has also emerged. In this report we consider the work on requirements and dynamic change from three perspectives: 1. identifying requirements (in sense of characteristics) that are necessary to support dynamic change at requirements level (Strang and Linnhoff-Popien 2004; Henricksen, Indulska et al. 2005); 2. developing Requirements Engineering approaches for handling dynamic change at the requirements level (Berry, Cheng et al. 2005; Kolos-Mazuryk, Poulisse et al. 2005; Goldsby and Cheng 2006; Kolos-Mazuryk, P. A. T. van Eck et al. 2006; Sitou and Spanfelner 2007; Xu, Cheung et al. 2007). 3. understanding as to how does the present-day RE work relate to the dynamic change, or, more specifically, to the characteristics of such change defined in above point 1. In the rest of this report we consider each of the above perspectives. The characteristics required to support dynamic change in requirements (Point 1) are discussed in section 2 of this report. The currently available work on dynamic RE (Point 2) is discussed in section 3. The issue as to how the existing RE approaches satisfy the characteristics required for dynamic change (Point 3), is presented in section 4. Here the present-day RE approaches are grouped into 5 categories in accordance with the way that requirements are structured: a) goal-based approaches; b) feature-based approaches; c) use case-based approaches; d) viewpoint-based approaches; and e) aspect-oriented approaches. Some representative approaches from each of these groups are then evaluated against the criteria defined in section 2. Section 5 considers the current state of research and practice in requirements configuration management to shed some light on the way that change is currently supported in RE. In order to provide a manageable and reversible run-time re-configuration support for requirements, the DiVA RE approach would need to handle at least a minimal set of requirements configuration management activities. Finally, section 6 concludes the report by presenting the initial outline of Diva RE approach which aims to build on the strengths of the RE approaches discussed in section 4 and aims to satisfy the criteria of section 2 as fully as possible.
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 8 of 48

2 Characteristics to be supported for DiVA systems: dynamically changing systems with variability
As noted above, DiVA focuses on systems and configurations of systems (with variability) that dynamically adapt to environmental or system-internal changes. All these characteristics are also native to mobile and ubiquitous computing systems. In this section we draw on the related surveys (Strang and Linnhoff-Popien 2004; Henricksen, Indulska et al. 2005; Rigole 2007) and present some of these issues from the perspective of Requirements Engineering for DiVA. Context Awareness: since DiVA systems will adapt in response to context change, they need to

be aware of the context (Rigole 2007). This criterion related to general environmental influences, modelling of data and histories, and the quality of context. Modelling Data and Histories is relevant since, while some context information can be considered static in the sense that its value is unchanging, the majority of context information is dynamic. As a consequence, if not appropriately updated, context information can quickly get outdated. Moreover, the context histories of some activities could be used for forecasting certain events e.g., steady decline in quality of some service may be used to expect and prepare for a change of service provider. Thus requirements for need of data update (e.g., location change) and history modelling should be considered explicitly (Henricksen, Indulska et al. 2005; Rukzio, Hamard et al. 2006). The Quality of Context (QoC) is relevant since context information might be unavailable, or out of date, and additional crosscutting requirement arises in adaptive systems demanding that they evaluate the quality of context information at system run-time and to resolve any conflicts identified due to this. In (Buchholz, Kupper et al. 2003) a number of attributes (i.e., precision, probability of correctness, resolution, up-to-dateness, refresh-rate) are presented to reason about information persistence and quality of contexts. In addition, the particular characteristics of context-aware systems, such as determining the ownership of context information, and the enforcement of access control according to context-dependent privacy preferences (Henricksen, Wishart et al. 2005) need to be considered. Variability Modelling: capturing and representing variability in requirements models is an essential part of the DiVA work at all the steps of the intended methodology. One of the main goals of DiVA is to tame the complexity of dynamically adaptive systems by managing the combinatorial explosion of variants. This can be done by leveraging concepts from the Software Product Lines (SPL), Aspect-Oriented Software Development (AOSD), and Model-Driven Engineering (MDE) communities. Some initial ideas for managing dynamic variability at design- and run-time in DiVA methodology have already been sketched out (Morin, Fleurey et al. 2008). However, since support for dynamic variability identification, representation, and management, as well as some reduction of alternatives for system adaptation paths should be provided earlier in the development lifecycle, this activity will be amongst those of the primary focus for the DiVA RE work. Thus, support for variability identification and representation is to be carefully studied for the DiVA RE approach. Modularity and Composability (or Composability for Systems of Systems): DiVA systems are distributed not only in sense of one system running on more than one computer, but also as systems of systems emerging from combination of independent systems. Thus, as in distributed systems, DiVA systems do not have a central system responsible for the creation, deployment and maintenance of data and services, in particular context descriptions (Rigole 2007) and system models must be composable. From the Requirements Engineering perspective this implies that it has to be possible to analyse requirement of an individual DiVA sub-system in isolation and support run-time composition of such requirements models into larger models.
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 9 of 48

Furthermore, the context model should be separated from the application components and the parts of the system concerned with sensing and actuation, so that the context model can evolve independently, without requiring application components to be re-implemented (Rigole 2007). Conceptual modelling (or Support for semantic understanding): To realise the above requirement for composability, there needs to be a check that two context-aware systems composed into a DiVA system have compatible interpretation of the context and change information, i.e., they must have semantic interoperability (Rigole 2007). For instance, when asked to maintain good response time all participating sub-systems should have consistent interpretation of good. This relates to the notion of shared understanding (Rigole 2007) which is modelled, for instance, via ontologies for semantic web (Berners-Lee, Hendler et al.

2001; Chen, Finin et al. 2003; Gu, Wang et al. 2004; Preuveneers, Bergh et al. 2004; Paslaru 2005; Bruijn and al 2008). Incompleteness, Ambiguity and Uncertainty: although incompleteness and ambiguity are characteristics most often associated with requirements engineering, in the area of adaptive systems these characteristics also arise due to difficulty of capturing the relevant information (for instance, a data update may be lost due to poor network conditions). Consequently, incompleteness and uncertainty should be accounted for by the requirements modelling techniques (e.g., by using probabilistic methods). Support for Scalability: since a DiVA system may be composed of a number of large systems, it is important for the DiVA requirements modelling approach to scale up adequately. This, for instance, may mean that alternative representations should be allowed, e.g., a graphical as well as textual notations should be available, etc. Alternative configuration selection: DiVA systems require a mechanism for evaluating alternative configurations against some given preferences. This mechanism should allow an easy, preferably automated, way of ranking the available alternative configurations. Though some user input may be necessary for this task (e.g., if new requirements have come up the relation of which to the existing ones was not previously known) it should be kept to minimum, since alternative configuration selection is a run-time process. Moreover, once a DiVA system has identified the need to update its configuration and has selected an alternative configuration to which it must migrate, it requires support for realising such a migration, relating to the need for run-time re-configurability, which, in turn requires the ability of the system to detect and resolve conflicts between requirements.
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 10 of 48

3 Requirements engineering approaches for handling dynamic change

Since addressing dynamic change in requirements is a new research area for Requirements Engineering, currently there is only a small body of work directly addressing this problem (Berry, Cheng et al. 2005; Lapouchnian, Liaskos et al. 2005; Lapouchnian, Yu et al. 2006; Yu, Lapouchnian et al. 2008). The main available work is discussed below. Since the main counterparts of this work are discussed in the following section (section 4) the work discussed in this section is not evaluated against the comparison criteria of section 1, but is provided as an overview of the current state of the art.

3.1 Reflection on Requirements Engineering for Dynamic Change

Berry et al. (Berry, Cheng et al. 2005) provide a reflective view on requirements engineering for adaptive systems. They suggest that there are four levels of RE associated with an adaptive system: 1. level one, carried out by humans, is on eliciting and analysing the domain of the adaptive systems, their features and the programmes to be used within these systems; 2. level two, carried out by running system, is on identifying unexpected input, matching it to the appropriate domain and adapting the system behaviour accordingly; 3. level 3, done by humans to determine the adaptation elements of the adaptive system in order for the system to be able at run time to carry out the required adaptations (i.e., the adaptations of level 2). 4. level 4, done by humans to understand the adaptation mechanisms in general, i.e., learning about detection and monitoring techniques for adaptation triggering events, decision making techniques upon adaptation triggering events, and the actual mechanisms for adaptation realisation. In this paper it is further noted that since for the foreseeable future software will not be truly intelligent, it will be up to humans to determine how and what the adaptive systems must do to

adapt. However, since humans do not even understand how they adapt, the software they design will be even less adaptive than humans themselves. This limitation of adaptability with human capacity to design for adaptability is termed adaptability envelope. It is this adaptability envelope that needs to be expanded to achieve better adaptability in systems.

3.2 Dynamic RE Approaches

Lapochnian et al. (Lapouchnian, Liaskos et al. 2005; Lapouchnian, Yu et al. 2006) suggest that in order to develop better autonomous systems, i.e., systems that handle their own configuration, healing, optimisation and protection at run time, one needs to use a development process that allows to: understand alternative ways as to how the system achieves its primary functionality; design these alternatives as available options for system execution. The authors further suggest use of goal-based requirements models (Lamsweerde 2000; Lamsweerde 2001) as the basis for such a development process. This is motivated by the fact that the goal-based models, using goal decomposition graphs, support representation of multiple alternatives for achieving a given goal. These alternatives are the OR-decompositions represented in the goal decomposition tree. Moreover, these alternatives are expressed from the stakeholders perspectives, so they can provide some stakeholder-based criteria for comparison of the alternatives. Lapochnian et al. (Lapouchnian, Liaskos et al. 2005; Lapouchnian, Yu et al. 2006) also suggest that, in order to reflect such goal dependencies as sequence in their realisation, the goal models
Version 0.1: Draft 20.10.2008 D1.1: Deliverable title Page 11 of 48

should be enriched with additional notations, such as ; between AND goals to indicate left to right temporal order, or || to indicate parallel execution. Furthermore, in a separate work (Yu, Lapouchnian et al. 2008) the authors discuss how a goal model may be transformed into a set of feature models, statecharts, and component and connector models. Thus, they argue that the goal model may be used to represent stakeholdermotivated alternative solutions. These solutions can then transformed into initial set of design elements, which can be utilised for run-time adaptation of the system in accordance with the solution alternatives pre-designed in the goal model.

3.3 Summary of Current work on Dynamic Requirements Engineering

Since the dynamic requirements engineering is a very new research avenue, presently there are only a few pieces of published work available. However, these few works (e.g., (Lapouchnian, Liaskos et al. 2005; Lapouchnian, Yu et al. 2006)) already indicate that it is practically possible to develop and use requirements engineering approaches that deal with dynamic change, and even trigger and propagate such changes to the running systems (Yu, Lapouchnian et al. 2008). In the following section of this report we review a number of RE approaches in order to identify the mechanisms currently present in the contemporary RE approaches which could facilitate development of such a dynamic RE approach. The characteristics relevant for a dynamically adaptive RE approach were discussed in section 2.