Self-adaptive systems (SAS) automatically adjust their behavior at runtime in order to manage changes in their user requirements and operating context. To achieve this goal, a SAS needs to carry knowledge in artifacts (e.g., contextual goal models) at runtime. However, identifying, representing, and re ning requirements and their context to create and maintain such artifacts at runtime is a challenging task, especially if the runtime environment is not very well known. In this short paper, we present an early concept to requirements engineering for the implementation of SAS in the context of uncertainty. Especially the wide variety of knowledge materialized in artifacts created during software engineering activities at design time is considered. We propose to start with a list of ambiguous requirements - or under-speci ed requirements -, leaving the ambiguity in the requirements, which will in the later steps be resolved further as more information is known. In contrast to conventional requirements engineering approaches, not all ambiguous requirements will be resolved. Instead, ambiguities serve as key input for self-adaptation. We present ve steps for the resolution of the ambiguity. For each step, we describe its purpose, identi ed challenges, and resolution ideas.
and behavioral adaptation points explicitly (where, when, what, how). In traditional RE approaches, a particular set of artifacts (e.g., requirements lists, goal models, feature models, and statecharts) is created and managed by requirements engineers. To achieve adaptation, a SAS must be aware of this knowledge gathered at design-time to be able to adapt itself and carry the knowledge, e.g., in the form of models at runtime [2]. Furthermore, based on this knowledge, a SAS can decide about the best suitable adaptation at runtime. In related work, adaptive requirements have been introduced to explicitly de ne variation points in requirements to leave room for adaptation [10].
We propose to focus on the reuse of the knowledge contained by the set of artifacts usually created and managed at design-time and to enable their facilitation at runtime systematically. We de ne an artifact as a machine-readable document relevant to requirements and context. A draft of the artifacts are created by requirements engineers at design time, and they will be updated at runtime.
We start from a set of elicited requirements tolerating some degree of ambiguity. We propose to keep on purpose the potentially contained ambiguity captured in the requirements artifacts and to design and implement the software without (entirely) resolving the ambiguity. We de ne the ambiguity as of under-speci cation of requirements. Usually, resolving ambiguities is an essential part of the traditional RE activities. In a SAS, however, we claim that embracing ambiguity throughout software design and implementation is a major step towards de ning and extending relevant context attributes for self-adaptation. Nevertheless, only the ambiguity that leads to feasible variability points should be maintained. For example, for autonomous vehicles, the requirements will be re ned after the vehicle is developed (e.g., using continuous experimentation). A SAS shall resolve contextually relevant ambiguity itself or with human help at runtime. Runtime testing will then serve to guarantee that the detailed requirements are implemented properly. This resolution requires an implementation of the system without fully hard coding all choices, thereby leaving space for runtime variability.
Two aspects enable a SAS to adapt to emerging situations at runtime within safe and secure bounds. On the one hand, the combination of knowledge about ambiguity in requirements and its context (problem space). On the other hand, foreseen adaptation points in the software itself (solution space). 2
To guide software engineers during requirements engineering and design of SAS, we propose an iterative and incremental approach comprising ve steps. Table 1 summarizes the steps and its associated artifacts. The steps are described in the rest of this section.
Step 1: Capture Requirements This rst step starts with a traditional requirements elicitation activity at design time resulting in a set of requirements. Some of these requirements can be Step
Activity
Artifact 1 Capture requirements Speci cation (e.g., early goal models) 2 (Iter.) Identify variability points Model (e.g., late goal models) 3 (Iter.) Identify context Context model (e.g., ontologies) 4 (Iter.) Identify situations Situations model (e.g., reasoning support) 5 (Iter.) Design variability (solution space) Architecture models (e.g., component models) ambiguous. The assumption here is that such ambiguities will be either resolved by the SAS or with human participation at runtime. Therefore, it is crucial that the requirements elicited in this step be documented or mapped to a machinereadable notation (e.g., goal models). In later steps when more information on the context is available, goal models can be extended to contextual goal models [12] and use cases can be extended to adapt cases [7].
Challenges: The consideration of leaving ambiguity in requirements: Some types of ambiguity might need to be resolved, as they will not lead to any adaptation needs (e.g., logical inconsistencies, stakeholders' interpretations) while other types of ambiguity are necessary for the SAS variability at runtime.
Ideas: De ne di erent categories of ambiguity and their e ect on adaptation capabilities of a SAS through empirical investigations.
Step 2: Identify Variability Points
The identi cation of ambiguities is an iterative process comprising three cases:
(
Existing work on variability in software engineering focuses on software product lines (SPL) [14], in which variability is used to produce new versions of a software product whereas goal-oriented modeling use variability to de ne behaviors of the system [4]. A Dynamic software product line (DSPL) target a single system with multiple and dynamic bindings [3]. REFAS [8] includes support the sub-speci cation with concern levels and aggregation relations. The speci cation is centered on constraints that are applicable at design time and runtime.
Challenges: Techniques and methods are required to provide (
Ideas: (
Step 3: Identify Context which In uences System Behavior After having identi ed variation points, the requirements engineer has to understand the in uence factors for variation points. We propose to represent these factors through context-attributes [6], which means that ambiguous parts of requirements can be re ned further through context attributes (i.e., relevant information for the system that can be sensed and monitored). The context data can be obtained from the system and information about the external environment.
Challenges: (
Ideas: Modeling constraints between variables for particular values and evaluate them at runtime. With the results of this evaluation, the system can reduce the adaptation possibilities of the model.
Step 4: Identify Context Situations and Variabilities During this step, context is analyzed with the purpose of identifying the situations that are relevant to runtime events. For this purpose, the context already identi ed is traced to each requirement while specifying the meaning for each of them. Changes in the context have di erent reactions and implications for requirements depending on the interpretation of the situations and requirements.
Existing work on context situations in software engineering include techniques to manage context information, such as context models [16, 13] and using machine learning techniques to keep context information up-to-date [5].
Challenges: (
Ideas: (
Existing work includes external and internal approaches [9]. External
approaches use explicit feature models linked to artifact elements using (
Challenges: Knowledge about variability is not fully (re)used at runtime. DSPL approaches support this reuse, but the relation between design-time and runtime variability is not well established.
Ideas: To have di erent views on the variability data: some for design-time (suited for requirements engineers) and some for runtime (suited for software: adaptation manager components). These views imply a language that requires the integration of knowledge (meta-data) from both { design time and runtime, i.e., make explicit why a variation at a certain variation point is an alternative. Such knowledge can also facilitate automated decision-making at runtime. 3
SAS are expected to deal with uncertainty from their requirements and operating context, resulting in situations that require adaptations of the system. Some of these situations already occur at requirements level.
In this short paper, we sketched an artifact-centric approach for RE in the domain of SAS comprising ve guiding, incremental, and iterative steps. For each step, we described its purpose, estimated associated challenges and potential ideas on how to resolve these challenges. The overall goal of the presented concept is to bridge design-time and run-time RE activities to manage ambiguities better.
Future work has to investigate the presented challenges and corresponding evaluation of results. As for the methodology, our proposal is to use empirical research methods, but combining quantitative and qualitative experiments with selected project cases from industry. 4
We thank T. Vogel, M. Tichy, and A. Gorla, organizers GI-Dagstuhl Seminar 14433 in which this paper was conceived. This work was supported by Vinnova grant 2014-06229.