ir stability cannot be guaranteed.
For that purpose, an approach using event-based formal language (called FLEA) is developed to give users the ability to monitor functional requirements and assumptions on-the-fly . The approach is able to describe the conditions required for executing an adaptation. Moreover,  integrates FLEA approach with a goaloriented approach to identify requirements deviation at run-time.
Nevertheless, classical requirement engineering techniques [9,10,14,15,17,20,21,23-27] are not adequate to support the adaptive behavior in context-aware SBAs. Most of the current approaches do not consider adaptive behavior of the system. Although the approaches are automatic but they do not support run-time adaptation and in most cases after detecting any violation, the requirement engineering starts from design time. An approach for run-time monitoring and adaptation of web services works based on feedback control loop is proposed in . Using the feedback the current requirement model will be updated and analyzed to detect violation. Consequently automatic reconfiguration is done to perform recovery actions.
Regarding requirements monitoring at run-time,  proposes an approach (called ReqMon) to monitor requirements satisfaction in information systems. The approach uses an event-based framework that accepts goalbased requirements formalized by LTL, and afterwards generates a monitor code, which eventually makes a relation between high-level goals and low-level run-time events. Monitoring of functional and non-functional requirements in the context of service-oriented architecture is addressed in  so that binding between service consumer and provider can be changed dynamically over time.
As we presented above, some significant approaches have been addressed to support RE activities for adaptive systems. However, the research in this area has still much to do and is in its beginning steps. Besides, these approaches are dealing with a specific activity at one time and therefore they are isolated approaches and there is a need to provide a comprehensive framework that incorporates complete RE activities in one approach. In the following we argue about some initial work trying to provide a comprehensive approach including RE activities and adaptation decisions with respect to the context changing.
A framework of RE in context-aware services is proposed in . A reflection-based framework is presented for such purpose. The framework address issues such as changing context and changing requirement. In their approach the context changes include: changing location, changing bandwidth, changing display characteristics such as graphic PDAs or text-only mobile phones, changing usage paradigm and the last one that the target platform is unknown in advance.
RE techniques for context aware systems are proposed in . The authors presented a model-based requirement engineering approach named RE-CAWAR to analyze the basic system and adaptation behavior of the context aware systems. In their approach the context changes include: changing participants such as changing location and personal properties (e.g. age and education), changing activities that indicate tasks and goals of participants influenced by environmental events, and finally changing operational environment such as network conditions and physical factors (e.g. temperature, light, humidity).  proposes PC-RE (Personal and Contextual Requirements Engineering) method that allows requirements to change over the time in presence of contextual uncertainty. A scenario-based approach is described to specify the requirements and their changes.
A common limitation of above approaches is a lack of proper context model that provides information for adaptation decisions. The requirement that identified at design-time, may not be satisfiable when the context changes. This can affect the performance of SBAs. However, context is a very broad term and understanding it requires a special care. Different elements of the context need to be accurately classified. Moreover, dependencies between context elements need to be identified in order to prevent propagation of changes from one context element to the other one. In the following we first of all present our definition of the term context and then classify context elements into different categories.
Here we present our definition of context as such: “Context” is any information that influences the interaction between users and a service-based application.
We classify context elements into six distinct categories: resource, user, provider, environment, web service quality and web service functionality. This provides us a comprehensive view of information that influences Service-base applications. The context information model drives situation that triggers adaptation. Context classification is illustrated in Figure 2. These elements are subject to change during the life-cycle of SBAs. We explain each of them in the following briefly.
Resource Context: It includes hardware and software properties that influence SBAs. Availability of the resources has an impact on satisfying the requirement. The information of resources and their availability could be updated during changes. The resource context also contains characteristics of network and operating systems for accessing the SBA.
User Context: The user context includes the user’s requirement and preferences. Requirement priorities from user perspective are expressed in this category. For example, regarding QoS requirement it shows which properties will be maximized among others. It also contains the information about the role of the user in the application e.g. guest or administrator.
Provider Context: It covers information from the provider side on the usage of the SBA. Provider may change the offered requirement during the execution. For example the provider may increase or decrease the computational charge and this will have a direct impact on the perceived requirement of SBA from the used side.
Environment Context: It has information about the time in which users access the SBA or the information about where the user is located. It also covers the surrounding environment such as the current date, temperature and weather. The modification of this context is performed by either users or external events.
Web Service Quality Context: It covers information about non-functional properties of web services in SBAs. Typical non-functional properties include availability, throughput, response time, level of security and they are often collectively referred to as quality dimensions. Changes of other contexts have mostly direct impact on the quality context. However, any changes in the quality context will trigger adaptation.
Web Service Functional Context: It contains information about functional properties of web services in SBAs regarding interface, structure of messages and different protocols. The cause of a functional change could be performed by changing requirement from user, provider and even environment contexts. Consequently there is a need to add, remove or update functionality. For instance, changes in the physical environment (e.g., temperature) can influence the network characteristic and the quality context (e.g. response time) also change. This will triggers an adaptation situation and the functional context is required to be updated.
5. Challenges and Discussions
In this section, we discuss and highlight some issues and challenges in order to support adaptation for SBAs.
Requirement Reflection: Requirements of adaptive systems need to be represented at run-time (run-time entities) to support adaptation. This involves modeling requirements at design time and reasoning them at runtime according to changing context to support adaptation. Therefore, the selection of the best adaptation strategy will be postpone at run-time by reasoning the existing requirements model and run-time data acquired from the context changes. This way, it is possible to revise and re-evaluate design-time decisions at run-time.
Goal-oriented approaches [17-19] seem to be a promising method for supporting requirement reflection. For example KAOS  provides a modeling language with formal semantics that allows automated reasoning over requirements and goals.
Dynamicity of Requirements: Due to the dynamicity of the requirements, it is necessary to specify the evolution of the requirement model . There are some challenges and research issues that need to be taken into account when the requirement model changes at run-time.
At one hand, the requirement model itself should be supported with model transformation patterns. With this regards, a library of requirements model transformation operators is proposed by . Examples of such operators are: add-requirement, delete-requirement, replacerequirement, add-goal, delete-goal, replace-goal and so on. On the other hand, these transformation models and requirement evolution models need to be synchronized with other software components, particularly software architecture. Coulson et al.  proposed an approach that supports such synchronization by introducing reflective architectures. The approach is composed of two layers, namely a base layer which include the actual running architecture and a meta layer that is responsible for dynamically managing the running architecture. A similar approach is proposed in  which the authors discuss a semantic integration between the requirements and architecture models.
A process called LoREM is proposed in  for handling requirement engineering activities, where each level describes requirement engineering activities of different developers in a dynamic adaptive system. These levels are motivated from four levels of requirement engineering proposed in . Requirements, goals and system functionality are represented in level 1, adaptation scenarios are identified in level 2 and adaptation infrastructure is presented and configured in level 3 in order to provide adaptation scenarios. The relationship between levels is supported through a model-driven development.
Uncertainty of Requirements: Uncertainty is a fundamental issue and a major challenge in almost all intelligent systems. Theories of uncertainty have been identified in management and economics. Such theories could be application for self-adaptive software systems. So far there is a lack of such theories in dealing with uncertainty in requirement engineering models. In order to deal with uncertainty, we need to be able to represent/ model it and reason about it. Various Techniques and frameworks have been introduced for reasoning uncertainly . Apart from this, understanding the degree of uncertainty of the context is necessary. Classification of uncertainty degree is reported in the literatures .
For example, consider a situation that there are different possible future scenarios but it is possible to list them all. Considering adaptation scenarios, this requires all possible scenarios to be taken into account at the design time. This could be done by considering all alternative contextual conditions and design all adaptation scenarios based on them. Therefore, run-time decision will be mainly based on requirement engineering at design time. In general, as long as the changes in the context are known, run-time decisions could be handle using existing requirement engineering techniques such as defining adaptation trigger conditions. Now, consider a situation that it is feasible to construct future scenarios but these are mere possibilities and are unlikely to be exclusive. This is a situation that context changes cannot be anticipated. RE at design time would not support run-time decisions. Defining adaptation trigger conditions at design-time is not adequate any longer as the new triggering conditions cannot be predicted.
In order to overcome such challenges we argue that two consideration need to be taken into account. First is a move from binary satisfaction of the requirement. Degree of the requirement satisfaction need to be evaluated (e.g. using a fuzzy approach) and corresponding adaptation actions should be selected accordingly. Second is defining critical and non-critical requirement. Therefore we can distinguish between vital and trivial requirement. For example, it is possible to temporarily ignore some requirement with non-criticality in favor of other critical requirement (requirement trade-off approach).
Dealing with uncertainty has been recently treated as a hot issue in the literatures . Initial solutions for overcoming uncertainty limitations are reported in  which later resulted in development of a new language named RELAX . It provides the system with the flexibility to trade-off the requirements at run-time and allows some certain requirement to be temporarily RELAXed.
Adaptation Strategies and Decision Making: A range of available adaptations (strategies) could be identified at the design time. Requirements obtained from various context information models (see Figure 2) can identify triggering conditions for adaptation. Then the changes of the context can be linked to the adaptation strategies by identifying rules. Therefore, finding most suitable adaptation strategies (between the alternatives) will be done at run-time. However, the two aforementioned challenges namely dynamicity and uncertainty of the requirements make the adaptation decisions to be unpredictable.
Figure 2. Categorization of context information.
In this situation, decisions have to be evaluated. Besides, each adaptation strategy has a different trade-off and consequences that has to be analyzed with the information at run-time. Multi-objective decision making may be applicable when the uncertainty exists. It usually defines a utility function that calculates the weighted sum of different objectives. However, regarding adaptation strategies this can be a difficult task identifying the weight of each strategy.
There are issues that need to be taken into account as following. First of all, the monitoring data should be used to evaluate the context properties identified in the context model. Therefore the context changes need to be detected and the degree of changes need to be evaluated. Understanding uncertainty level as we explained earlier is also necessary. The aggregation of this consideration will result to identify the adaptation triggers. The triggers are the base to define adaptation needs. The existing rules and links between the context and adaptation strategies need to be updated according to the information obtained at monitoring. Apart from these, the user preferences could mainly affect choosing the right adaptation. Furthermore, adaptation purpose need to be identified in the early stage whether is it for optimization, recovery or prevention as each may have different requirements.
Feedback Loop: From Control Theory to Software Engineering: The notion of feedback loop has been widely used in the field of control engineering. Actually the control loop is recognized as the central element of control theory.  presents a generic model of a control loop that includes four key activities namely: collect, analyze, decide and act. Cheng et al.  upgraded the generic model by identifying properties of control for each activity which were ignored in the generic model. For example in the analyzing part, we need to know how much past state may be needed in the future. In the decision part, we need to know how the future state of the system is inferred. Or what are the priorities for adaptation across multiple control loops. And finally in the last part, action part, we need to know when the adaptation should be performed.
Applicability of using control theories for self-adaptive systems is still under investigation. However, in order to address changes in the context, borrowing theories from control engineering and apply them from selfadaptive systems could be beneficial.  identifies engineering principles for self-adaptive systems through feedback loop. Discussions about the control loops should be an explicit activity is reported in . There is a similar discussion in  about the need of the control loop to be explicit. Additionally the authors argue that one explicit loop in not enough and in order to support various changes the system is required to have different nested loop.
There are some work particularly uses feedback loop for adaptation in SBAs.  uses a feedback loop at runtime to handle both functional and non-functional properties of services. The feedback loop is used to update the requirement model and analyze it at runtime which make it possible to detect the violations and perform the automatically recovery action in order to guarantee the system goals. An explicit feedback loop technique for the adaptation of complex service oriented systems is used in .
We discussed the state of the art of requirements engineering for adaptive systems. We started by briefly describing significant characteristics of self-adaptive systems and continued by explaining the adaptation lifecycle in SBAs. With this regard, we discussed about corresponding activities and issues need to be incorporated into the framework in each phase. We focused on requirements engineering activities namely requirements elicitation, requirements modeling and specification, and requirements monitoring, as a basic discipline in developing adaptive systems and in particular for SBAs. We argued about our definition of context and classified different elements of it. Moreover, we pointed out the importance of defining a context model as part of the requirement engineering for SBAs. Such context model provides information for triggering situations for the adaptation of SBAs.
“This work was partially supported by the Industrial Strategic technology development program (10040142, Development of a qualitative customer feedback analysis and evaluation method for effective performance management in B2C Industry) funded by the Ministry of Knowledge Economy (MKE, Korea)”. In addition, the initial part of the work was done at Politecnico di Milano and the first author would like to thank Dr. Elisabetta di Nitto for her supervision.