Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.


125 Aufrufe

Veröffentlicht am

  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!


  1. 1. Requirement Engineering for Context-aware Systems Final Report for CS846 Akshat Kumar University of Waterloo Waterloo, Canada akshat.kumar@uwaterloo.ca Abstract— By this literature review I want to understand the specificrequirementsengineering difficultiesare unique to context aware systems. I also hoped to discover some new problems that are not mentionedby the papers consideredfor the review, but are only presented when I considered all the works together. The report will first try to explore and elaborate some the definitions of important concepts then we will discuss the some of the issues and some special requirement engineering techniques namely PC- RE, R4IE & CARE. Keywords—Requirements; Engineering; RE; Context; Aware; context-aware; PC-RE; R4IE; CARE I. INTRODUCTION The area of context aware has very quickly been ushered from the realm of theoretical computer science and academia into reality to an extent that its products populate ourpockets today. A quick web search leads us to the fact that oneofthe first papers to be published in the area was not so surprisingly aimed at the military application. Today leaders in this area are billion dolor companies, and the research area has received and continues to receive substantial research effort. Challenges requirement engineering are a natural concern for context aware applications. This can be argued for a variety of reasons.The dynamic nature of context aware systems make the proper detailed definition of requirements more important than in other kinds of systems. The challenges are multiplied due to the fact that requirement engineering problems for static (context-unaware systems) have not yet been tamed or understood. It is also regarded that some of the requirements engineering problems will never be truly be solved as long as humans included in the software process. But this can be countered by pointing out that one will need people to engineer the automated system that replaces humans from the software development process. As requirements engineering challenges faced by context aware systems are more challenging, it is probable that better understanding of these challenges will help us improve requirements engineering practices in general. It is becoming increasingly important to understand the specific requirements engineering problems that are faced by context aware systems as modern systems are inducing more and more context dependent features. Through this literature review I want to understand the specific requirements engineering difficulties are unique to context aware systems.Ialso hoped to discoversome new problems that are not mentioned by the papers considered for the review, but are only presented when I considered all the works together. From this review I also hoped to enhance my understanding of area. In my literature review of the papers about the topic I have covered papers from different area of application. I have tried to select prominent works from all the phases of the history of research in the area. I have tried to find some problems that have been repeatedly discussed in these works, I will also talk about some approaches that are proposed by some of the researchers, towards the end I will also talk about the some of the problems that I noticed while making the literature review. The report will first try to explore and elaborate some the definitions of important concepts then we will discuss the some of the issues and some special requirement engineering techniques namely PC-RE, R4IE & CARE. II. DEFINITION OF CONTEXT Context is a concept used forthe information that can be used to infer or compute the needs or the intent of the user. The definition of context has been evolving very rapidly thanks to the large amount of research effort dedicated to the area. The evolution of the definition of context can be used to mirror the trend of technological improvements that the world has experienced in the last few decades. The definition has become progressively more accumulation to the kinds of information that can be said to the part of the context, it can be said that the scope of the definition has been widened. The advancements of sensor technology meant that more kinds of information can be measured and associated tothe context. The rapid increase in the pervasiveness of technology means that the sensors placed at the right positions can uncover information about the user that was previously unreachable.
  2. 2. Finally the adoption of mobile devices means that any advancements to the field will benefit millions of users directly. This has increased the stakes of research and has been a great motivator for the research community over the past years. The earliest definition that I encountered was given by [1], it stated that “Context is the location, identities of nearby people and objects, and changes to those objects”. The researchers describe an active map service that supports context-aware computing by providing clients with information about located- objects and how those objects change over time, they focus on the communication issues ofdisseminating information from an active map server to its clients and discuss how to deal with various overload situations that can occur. Their approach to this problem has been to exploit multicast techniques in order to avoid requiring the active map service to repeatedly send out the same update information message to different receivers. The technique require clients to monitor sequence numbers in each multicast message and request retransmissions whenever they detect a missed sequence number. The technique also encourages the use of the same queries by many clients, we have structured our applications to offer standard queries as easily invoked menu options. From the definition it is clear that the researchers were very conservative about the kind of information that context can include. This can be because they wanted the types of information in context to be small so that strong reasoning engines can be built with predefined relations. The small number of information in context is also an attribute to the limitations in sensor technology at the time. The definition was evolved by [2], the researchers form Kent University redefined context as “Context is location, identities of the people around the user, the time of day, season, temperature”. The researcher community discovered that some kinds of relevant information that could not be accommodated by the previous definition.For this case the newinformation was time of day, season and the temperature. The update to the definition might seem trivial to us now but keep in mind that at the time of the update it was hard to imagine the realities of today’s penetration oftechnology. The researchers try to address the problem of efficient of the design of context aware application. They argue that most of the context aware applications in use were being developed in research laboratories as they required the skills of a skilled software architect, the research tried to propose a new stick-e infrastructure that aims at reducing the complexity of the context aware design and enable a lot of applications to be developed by the industry itself by reducing the need of experts in development of context-aware application. It was around this time that we see that many research groups started to coin themselves definitions of context to suit their need and application area. I believe that this practice is still widespread though limited. We will discuss this problem later in the document. Another evolution in the definition of context that I observed was introduced by [3]. Interestingly this effort did not come from a core computer science group but from the allied application area in archeology. This means that by this time the area of context aware application must have been popularenough that it was receiving research attention from an allied branch. The researchers define context as “Context is the user’s location, environment, identity and time”. This definition is an enhancement to the one provided in [2] as it talks about the environment of the user as opposed to specific properties of the users environment. The research addresses the problem of limited battery life for computing platforms such as laptops and tries to make themmore usefulfor archeologists working in the field at remote dig sites. The paper introduces JISC [3] as a solution to the problem using elements from context-aware systems. The researchers recognized context awareness as a widely applicable area, they then generalize the perspective to context to include a wide range ofphysicaland logicalproperties from the user’s environment to further enhance the flexibility. Thus with a parallel enhancement in the computing capabilities of mobile devices to make use the extended-context for making better prediction. It is also interesting to see that this enhancement was introduced by the allied branch ofarcheology, I think this supports the claim made in the previous paragraph about trend of redefining context to suit the particular need of the application area. The final evolution of the definition of context that I observed was made by [4]. The researchers defined context as “Context is any information that can be used to characterize the situation of entities”.This work explored the merits that can be achieved by the development of an integrated conceptualmodel for context. Their argument that web applications need to adapt to different contexts even though they are hosted at a fixed location but are accessed by clients that might be from different locations, different time-zones. They argued that web applications can be thought of being in multiple contexts simultaneously, thus the definition of context needed to be redefined for them. Web applications can enter and leave context based on the conditions of its clients. They argued that instead of using an extensive model context that is able to accommodate a wide kinds of kinds of context elements which will make it very difficult to develop a context reasoning mechanism, it is better to develop a mechanism that can be used for automatic generation and updating of context model at runtime. They argue that this approach will not enable the reasoning model to maintain a better accuracy with improved flexibility. The researchers propose the development of context catalogs that specialize in some specific business domains.It is thus reasonable to assume a meaningful degree of re-usability may be achieved not only for the domain ontologies, but also for the context models. It was interesting that the work proposed a different view of context, and that the definition also provided very agreeable approach to the problem. The definition of context used by this work was however very wide and is unlikely to be enhanced as it covers any information that relates the situation ofthe useror any other entity involved.
  3. 3. It is clear from the previous paragraphs that the definition of context is constantly being evolved this make difficult for other researchers to contribute to the field. It also makes it difficult for the reader to gain comfort with the concept. III. CLASSIFICATION OF CONTEXTUAL INFORMATION As with the definition of context there have been several classification of contextual information overthe past years.The proposed categories differdue to the changes in the definition of context and the inclusion of more kinds of information. The increase in the inclusiveness ofthe definition of context has also caused some pivotal changes in the way contextual information has been classified. A. Historical Classification of Contextual Information The earliest classification for contextual information encountered by during the literature review was provided by [3]. The researchers presented a classification that simply classified based on the kind of the information between the categories of location, identity, activity and time. According to the researchers,such kind of classification was logical as only these types of information could be classified as contextual information. This information can be used not only to tag information as it is collected in the field, but also to enable selective responses such as triggering alarms or retrieving information relevant to the task at hand. Anotherinteresting classification was presented by [4]. The researchers classified contextual information into the user&role, process&task,location,time and device categories.This kind of classification was used by the researchers their area of study of web applications. User&Role provides a categorization of users according to their role, such as various types of customers, or different types of employees. Process&Task represents a functional context, such as work items for employees. Location is a categorization of locations relevant to the application, in the desired granularity, for some applications, the country may be sufficient location information, for others,the city, and so forth. These locations are not to be confused with the locations sensed by the system, such as by GPS positioning, user input, or network address (IP address or the like). Furthermore, this location categorization does not refer to locations in the information space (i.e. where is a certain Web media located) northeir proximity location-wise to otherelements in this space: in ourterminology, this type ofrelationship is part of the domain ontology,not ofthe context dimensions. Time refers to different types oftime information may be relevant,such as the time-zone of the client, the actual time, a virtual time, etc. The Device category contains that device and device-related information which may be a relevant context parameter (such as in mobile scenarios), e.g. the device type, display properties, etc. A property such as bandwidth can be used for (automatic) application adaptation:if bandwidth (as a context parameter) is sensed to be below a certain threshold,or changes to fall below that threshold,the streaming of audio or video can be reduced in quality, in order to maintain the same refresh rate nonetheless. B. Modern Classification of Contextual Information A more recent kind of classification that I encountered during the literature review was the presented by [6]. The classification is much more extendible than the previous two classification. The classification used by the researchers is divided into 3 categories, namely computing context, User context and the Physical context. Unlike the previous 2 classifications this approach classifies the contextual information based on the source of the information as opposed to the type or kind of information. Computing context deals with new computing environments that can introduce new interaction styles. An important facet of context-aware applications is that users may use many mobile devices at the same time. Which devices should be used in the interaction becomes very important. People prefer a device with multiple functions. As multiple devices may be available to a user in a specific situation in ubiquitous computing. Gesture recognition devices, handwriting devices, and embedded cameras togetherprovide more opportunities forusers to interact with the environment than with each of themalone.Handwriting devices, voice recognition devices, and GPS systems enable people (especially the elderly) to input their location parameter in a convenient way in different situations. Moreover, with the help of eye-tracking devices, tourist guide systemcould benefit those with disabilities since they help automatically choose a target device from a device set. Energy is not a concern for fixed devices but a major concern for mobile devices. User context is important as Users usually have their own preferences that determine their choices. For example, some users might be interested in taking a bus, while others prefer taking a train. It is very useful for applications to make use of such preference information. Further, if the systemknows the user’s purpose of an activity, wrong recommendations or interactions can be avoided. Context-aware applications may collect some personaldata to deduce the interaction between the userand ubiquitous environment.Alternatively the user choices can be deduced by having user fill a questionnaire. Figure 1 Classification as seen by [4] Figure 2 Classification as seen by [6]
  4. 4. Physical contexts refer to non-computing-related information provided by a real-world environment. These are best explored by other existing ubiquitous applications and therefore we try to keep the discussion brief in this paper. Among them, the user’s current location is the most important context, especially in a tourist system. Not only is this information critical to most interactions, it is also the key to many othersystemfunctions,decisions, and recommendations. IV. CONTEXT-AWARE SYSTEMS A system is said to be context-aware if it can extract, interpret and use context information to adapt its functionality to enhance its utility. They are strongly related to ubiquitous computing and pervasive computing. The term ‘context-aware’ was first used by Schilit and Theimer in [1]. In their research they describe a model of computing in which users interact with many different mobile and stationary computers and classify a context-aware systems as one that can adapt according to its location of use, the collection of nearby people and objects, as well as the changes to those objectsovertime over the course of the day. Modern Internet of Things products in the existing marketplace demonstrate a significant amount of context-aware capabilities. While the computer science community initially perceived the context as a matter of user location, as Dey discuss,[5]in the last few years this notion has been considered not simply as a state, but part of a process in which users are involved which means is useris part of the context.For example: a context aware mobile phone may know that it is currently in the meeting room, and that the user has sat down. The phone may conclude that the user is currently in a meeting and reject any unimportant calls. Context awareness allow the application to gain sensitivity for many things that were beyond the reach of these systems. According to [7] human factors related context include information on the user (knowledge of habits, emotional state), the user’s social environment (co-location of others, social interaction, group dynamics), and the user’s tasks (spontaneous activity, engaged tasks, general goals). Access to these information open very exciting possibilities for all application with direct human interaction. For systems that are not involved in direct interaction with humans. It is value able to react to such events,for example the traffic management system in a large datacenter which is responsible for the routing of traffic for a multiple popular web- based services can benefit from preemptive actions taken based on the behavior of the user base as a whole. A service that is observed to gaining popularity with a large number of users can be migrated to shorter routing paths and can also be preemptively populated in the cache. Such a systemcan scale down non-essential background processing to accommodate a traffic spike predicted by the context based reasoning system. In [8] the researchers propose a cooperative, context-aware approach to data center migration across WANs to deal with outages in a non-disruptive manner. Their focus was to achieve high availability of data center services in the face of both planned and incidental outages of data center facilities. The technique uses servervirtualization to enable the replication and migration of servers. Figure 3 Context-aware server migration by [8]
  5. 5. V. ADVANTAGES OF CONTEXT-AWARE SYSTEMS There are several reasons why context is important, [6] presented a great classification for the advantages derived from the adoption of context-aware systems. A. Reduce input cost Explicit input from the user is expensive. It interrupts the user’s thoughtsand slows down the speed of the interaction. By sensing the environment and interpreting explicit actions, mobile devices such as sensors, cell phones, and PDAs could provide a rich and implicit context. Context makes the communication between humans and computing devices much more efficient. B. User experience enhancement With the help of context, interactive applications such as tourist guide system, can boost its utility if it uses natural interface that does not require a large learning effort from the user and since the systemis going to be used only for a short time. C. Context sharing We may assume that users and their friends have similar preferences, which means something that attracts one group member’s attention has a higher probability of being preferred by other members. By sharing the context, the system could provide a better service. VI. REQUIREMENT ENGINEERING CHALLENGES IN CONTEXT-AWARE SYSTEMS Unlike conventional Requirement engineering for systems that are not context aware, the development of context aware systemface ever higher levels of difficulty. The added difficulty is induced by higherlevels of uncertainty that such systems face from the environments. Usually Requirement engineering is carried out at the outset of the whole development process, but in context-aware applications Requirement engineering activities are also needed at run-time to aid seamless evolution. Requirements need to be made a runtime entity and thus enabling the systems to reason about,understand,explain and modify requirements at run-time. This is termed as requirement reflection or requirement@run- time. The area of research has been explored by [9], [10], [11] and [14]. A. Chalengesin the requirements phase As discussed earlier, conventional Requirements engineering activities made more difficult in case of context aware systems. The sharp increase in difficulty of conventional requirements activities is made worse by the mirrored increase in the importance of high quality detailed requirements gathering and documentation. This area is extensively explored by [12], the researchers analyses the role of uncertainty at various phases of the development of a dynamic context aware system. The finds that the uncertainty faced at the requirement time was by far the most manageable sources ofuncertainty.They also noted that the sources of uncertainty often go unexplored and unresolved for most of the context aware systems. If such sources of uncertainty are allowed to flow unchecked in the requirement phase they can lead to a source of uncertainty in the design phase and even the run-time phase. The study defines a “taxonomy” of different sources of uncertainties for different phases of systemdevelopment. The study also acknowledges that it might be impossible to resolve all sources of uncertainties for many application domains. It is also worth mentioning the challenges that were mentioned by [12] but not included in any ofthe taxonomies, the researchers talked about the need for the developer to code for all the possible environmental conditions that context-aware systemhopes to handle. This is a very difficult requirement to satisfy as the developer might not be able to imagine all of the inputs that a systemmight receive. Figure 4 sources of uncertainty in the requirement phase [12]. Figure 5 Sources of uncertainty in the design phase [12]. Figure 6 Sources of uncertainty in the runtime phase [12].
  6. 6. VII. TECHNIQUES FOR REQUIREMENT ANALYSIS The initial RE activities for context-aware systems are much more complex. Now we will discuss some ofthe techniques that were proposed by the researchers. A. PC-RE It is proposed by [11], the name is an acronym for Personal Contextual Requirements Engineering. The research aims to propose a method for requirements analysis that accounts for individual and personalgoals,and the effect of time and context on personalrequirements. The paperfirst proposes a framework to analyze the issues inherent in requirements that change over time and location. The paper then considers implications of the proposed framework on system architecture based on three implementation pathways, functional specifications, development of customizable features and automatic adaptation by the system, for the need to analyze system architecture requirements. PC-RE [11] is a scenario-based analysis method is de- scribed for specifying requirements goals and their potential change. It also proposes methods to addresses goal setting for measurement and monitoring, and conflict resolution when requirements at different layers and from different sources conflict. The researchers also illustrated the use of the framework with two case studies in assistive technology domains: e-mail and a personalized navigation system. The first case study illustrates personalrequirements to help cognitively disabled users communicate via e-mail. The second case study addresses personal and mobile requirements to help disabled users make journeys on their own, assisted by a mobile PDA guide. The paper describes experience from requirements analysis to implementation, requirements monitoring, and requirements evolution for both case studies. The proposed technique PC-RE is designed to complement existing requirement engineering methodologies and does not define the method itself. PC-RE provides a framework of questions that drive the requirement investigation and interpret this as a checklist of issues rather than a tree of steps that suggests different paths that can be followed. The researchers argue that while several requirements taxonomies have been proposed, almost all of the previous taxonomies have classified requirements according to their subject matterratherthan to the agents to which they pertain.For example change in location is rarely specified from an agent’s perspective, even though globalization and cultural effects on products are known to be important. Understanding cultural impact on requirements is still in its infancy, although ethnographic studies suggest that very different requirements arise in this situation, for instance, privacy requirements for automatic teller machines are very different between eastern and western societies. The researchers propose a three-layer framework for personal and contextual requirements, with two change dimensions of location and time which act on each layer, as summarized in Figure 5. The layers progress from general requirements at the user group layer, to individual user characteristics, and to personal goals. Within each layer requirements vary over space and time. Contextual influences may vary from the cultural and social systemenvironment to effects of specific locations. Stakeholder group, in this layer the change context affects requirements in cultural adaptation of products, e.g. language localization, change in business processes between European and American models; while time influences how requirements change as business processes evolve and product functionality becomes more complex. This layer also covers the architectural considerations that are design of products with variation points so they can be configured for different cultures, other aspects that concern this layer are customizations to accommodate context effects e.g. language localization, design offunctions for mobility, customizable or adaptive user interfaces to deal with userskills change, and a flexible adaptable architecture to evolve as business processes change. User characteristics this layer models the needs of the individuals who share a common profile of skills and abilities that influence how they interact with the system. A user’s characteristics are described by the individual user’s ability profile. The ability profile can be used to customize the means of human computer communication for the elderly, disabled, people with different learning styles, etc. Location affects user characteristics as people’s abilities change with place, such as the need for adapting communication modalities in noisy environments, while people’s skills and abilities change over time as they adapt. The user characteristics layer describes the users’physicaland mental abilities, so this affects requirements for inter- action directly as well as functional requirements indirectly. User characteristics requirements imply the need to develop individually tailored versions of applications that are either configured for the user at design time or automatically adapt to the user’s needs. Change over time occurs as people learn systemfunctions and need new styles of dialogue as they become more skilled, while slower change, e.g. age-related decline in cognitive and motor abilities, necessitates change in magnified visual displays and slower response times. User characteristics are assessed by psychology based questionnaires Figure 7 PC-RE [11] Personal requirements framework and change dimensions
  7. 7. and tests to measure cognitive,physical and perceptual abilities or by interviewing users to gather information on general abilities, experience and skills. These user characteristics are a specification of what we can reasonably expect from the user both individually and collectively and also what needs to be implemented to enable effective use of the system. Personal goals,it is important to analyze requirements from an individual viewpoint, especially in domains where customization is important. In this layer, change over time depends on the stability ofpeople’s wishes,while the contextual interaction may be influenced by how their goals are affected by location and social setting. Models of individual users have always been important for educational applications where the abilities of each individual are matched to content and cognitive ability. The type of requirements in each layer and their interaction with the change and context dimension are summarized in figure 8. The researchers argue that this approach generalizes beyond assistive technology applications, they propose educational technology is one area where individual characteristics are important influences on design as learner profiles. The researchers list the following features in an attempt to portray aspects common to the range of ambient assisted living application areas. B. R4IE Proposed by [13], R4IE is an acronymfor Requirements for Intelligent Environments. The researchers cite that the field of Intelligent Environments (IE) is maturing to a level at which a range of sophisticated applications are becoming a reality. The researchers focus on the area of ambient assisted living (AAL) for this study. The researchers recognize that recently numerous IE systems have been developed without adopting bestpractices from software engineering. The researchers consider a project called POSIDON in the hopes that it will promote R4IE and facilitate further refinement of the framework. It is the broad view of the authors that developers of all IE systems can potentially benefit from best practices established in many aspects ofsoftware engineering. The researchers focus on the following list of salient features of work for the framework for the assisted living area.  Goal-oriented tasks are usually evident  Contexts can vary significantly (depending on specified goals), and there can be an associated prioritization of design and implementation activities in terms of the services associated with those contexts  Depending on the nature of the assistance,there can be a clear demarcation between individual user requirements which demand a degree of personalization, or customization, and distinct user groups that support an individual who also present distinct sets of requirements  If distinct target groups and individual stakeholders are identified, then a prioritization of users and usergroups (themselves) is typically demanded, with individual users taking precedence in the sense that they present the highest stakeholder value  There can be important ethical issues, including the matter of privacy relating to context  HCI and usability aspects carry high importance, and this includes aspects ofmodality, physicaland cognitive skills, and experience. Accordingly, there is a strong association between requirements for interaction design and the design of appropriate user training support  Delivery of an ambient assisted living systemtypically involves a distributed team with each participant providing specialist knowledge such that the requirements engineering approach requires harmonization in terms of coordination, planning and management The central process to the technique is the Identification of the stakeholders and constructing theirprofiles. The researchers have identified five types of stakeholder that are typically represented within the assisted living domain, the researchers also define three levels of end-user stakeholders, which we define as primary, secondary and tertiary users. A primary stakeholder profile will represent the individual for whom the ‘assistance’ is being targeted. The secondary users will be people that have frequent contact with the primary stakeholder (typically day-to- day contact)such as friends, family members and nurses. The tertiary users would include a range of Figure 8 PC-RE [11] effect of time and location
  8. 8. stakeholders with less frequent contact with the primary user, such as school teachers, employers and work colleagues etc. In addition to the three types of stakeholder that would ultimately interact with the Intelligent Environment, the researchers define two further types ofstakeholderwith regard to the requirements engineering phase the sponsors and the operational team. The sponsors of a systemwould typically be an organisation with a vested interest in the delivery of the system. The operational team contains people that would include the analysts,designers, implementers, technicalsupport,maintenance,project managers and those responsible for delivering training support. The researchers made an acute observation that for AAL systems that, whilst a primary stakeholder is identified, it will not necessarily be the primary userwho collaborates in the core requirements elicitation activities. They assert that for primary users with cognitive disabilities it will be representatives from the secondary user classification that would not only communicate their own requirements, but would also play a significant role in communicating the requirements of the primary stakeholder. Furthermore, in these situations it is quite conceivable that tertiary stakeholders may also contribute to requirements gathering that is specific to the primary user. The researchers also considered that it might be necessity to adjust such customizations with time by suggesting that individual requirements evolve as the stakeholderages,and this can manifest as eitherincreased ability, i.e., experience and skill, or reduced ability, e.g., visual and aural acuity. They suggest a requirements engineering method that addresses a form of ongoing context-change throughout the lifetime of a system. For R4IE [13], the researchers identified six core requirements gathering categories against which dedicated requirements elicitation activities described in figure 10. The primary thrust ofthe model described above is in identifying the context-awareness requirements. In turn these requirements will inform further engineering requirements for the system, for example, systemsecurity issues, reliability and resilience, and these will ultimately determine the systeminfrastructure. VIII. TECHNIQUES FOR REQUIREMENT@RUNTIME Context-aware systems need to cope with evolving requirements by adapting to enhance the utility of the system. C. CARE Proposed by [10], targeted towards improving adaptability of Service-Based Applications (SBA) [10]. Service-Based Applications are defined as software systems that integrate existing services, which are individually made available by different service providers, and can be accessed by service consumers, through a variety of connecting devices. SBA are open systems, as they rest on a global infrastructure i.e. the Internet on which new services may become available, or existing one disappear,and need to manage the heterogeneity of service providers and the variability of contexts and devices they can be accessed from, still maintaining their expected functionalities and qualities. In the context of open and dynamic systems, as SBA, the user’s goals (or their priorities) may change at run-time, as well as the context conditions in which they have to be achieved, leading to the need of conceiving Requirements@runtime[14]. Researchers consider self-adaptability as a key property to deal with design-time uncertainty and proposeconcepts and methods to model this property in terms of monitoring, evaluation and adaptation requirements, in particular, they focus on the continuous update and refinement of requirements at run-time. The researchers distinguish between requirements for SBA that maybe identified at design-time and requirements that SBA has to address at run-time. At design-time requirements may be analyzed and operationalized in terms of alternatives, which might not be feasible at run-time. But at runtime, a flight delay may lead to many consequences which may not be possible to enumerate at design-time The researchers differentiate between RE processes performed at design-time and RE processes per-formed at run- time. RE at design-time involves activities that aim at identifying monitoring and adaptation requirements to ensure that the SBA will be able to operate while maintaining its expected function and quality. Whereas, run-time RE activities Figure 10 categories of Stakeholder for AAL systems as seen by [13] Figure 9 Core Activities in the R4IE [13] (AAL) Framework
  9. 9. help acquiring information continuously that can be treated as possible requirements, thus refining the requirements artifacts. Service Request Acquisition (Srequest): In this step, the SBA tries to acquire service requests either as a result of monitoring its context or resources orexpressed as a search query in natural language (using keywords or a whole phrase) by the user. Service Lookup (Savailability): This activity is initiated after analyzing the RRA. Lookup is performed either in the existing pool of service of the SBA or using web service search. Service Selection (Sconfirmation): User-centrality is the key, where the user is involved in the RE process at run-time. RRA is complemented with a searched list ofservices,which is shown to the user for selection and confirmation. Update (Req. Specs) (Specupdate): This activity ensures an update to the initial specification, once the RRA is completely filled with the users’ input or monitored information and the selected services that operationalizes the users’ request. An update to initial specification is performed i.e. refinement of existing or addition of new requirements. The former refers to adding, deleting, suspending or resuming an alternative goal/plan to meet existing goals, whereas,latter refers to adding a new goal along with its corresponding operationalization,thus enabling the SBA to meet its users’requests.The main concern is to keep the consistency of the existing specification. Main intended benefits of using CARE are that it allows to take into account the effects ofthe design-time uncertainty about dynamism and volatility of the environment in which SBA operates, through the concept of adaptive requirements, which captures flexibility in users’ needs and preferences, it also provides a practical means to acquire runtime service requests that are treated as new requirements, which may leads the SBA to deliver a new (composed) service to the user and later on to update the design-time requirements model specification. IX. OBSERVATIONS I completed the literature review after reading twelve research papers. The literature review answered a lot many questions but also instantiated many new ones for me. But review has definitely improved my understanding of the challenges and the popular research directions on the area both in width and depth. I found that there were some overlying issues that cut across individual research efforts, these issues might have not been mentioned in any of the research papers. I felt that that by making the field more approachable we might be able to attract more research effort towards the area. I will now attempt to describe these issues. Absence of a common vocabulary: This was a major issue when reading papers for the review. I found that all the research groups used different definitions and for concepts ranging from the high-level definitions to the core definitions like that of context. It can be considered naturaland even a sign of progress if some concepts in an area are under contention over the accepted definition, but I found that in the area of context-aware application it was very rare to find research groups agreeing on any definition. This has many implications in my opinion, this makes keeping track of prominent research in the area very difficult. I feel that this is especially unusualas the area already has been widely accepted as a major field of practical application. Need for a representation and reasoning model: compared to the number of papers that focus on a niche area of application there a surprisingly low amount of research effort being dedicated to defining concepts that can be applicable to across the area. It seems that most of the effort is being dedicated towards picking and re-picking the low hanging fruit in the area. I felt that there is need to unify the area by using some underlying concept. One of the things that I felt were missing was a common representational and/or reasoning model. The definition of a representation model would be applicable to all the individual areas of applications. Similarly a unified reasoning model will enable to the context-aware applications that this model to reason about all the unified information available. A unified representation and a reasoning model can also lead to a common notation that can then lead to automatic verification mechanisms. More attention is needed on analyzing privacy: To clarify there has been significant effort dedicated to privacy issue, whereas some think that it’s enough, but I am more concerned about the impact that these studies are producing on other research. Most of the papers do not consider privacy as a major issue.I think more researchers should try to include privacy as a concern. Figure 11 [10] CARE process at Run-time
  10. 10. ACKNOWLEDGMENT To ProfessorDaniel M. Berry thanks...To all course mates’ thanks... REFERENCES [1] Schilit, B.N., Theimer, M.M, Disseminating Active Map Information to Mobile Hosts, NY: Dept of computer science , Columbia University, 1994. [2] Brown, P.J., Bovey, J.D., Xian Chen, Context-aware applications: from the laboratory to the marketplace, Kent Univ., Canterbury, UK, 1997. [3] Ryan, N., J. Pascoe, D. Morse, EnhancedRealityFieldwork: the Context Aware Archaeological Assistant, University of Birmingham, 1997. [4] J. WolfgangKaltz, JürgenZiegler, SteffenLohmann, Context-aware Web Engineering: Modeling and Applications, Universität Duisburg-Essen, Duisburg, Germany, 2005. [5] Gregory D. Abowd, Anind K. Dey, Peter J. Brown, Nigel Davies, Mark Smith, Pete Steggles, Towards a Better Understanding of Context and Context-Awareness, Georgia Institute ofTechnology,Atlanta, GA, 1999 [6] Dan Hong, Dickson K.W. Chiu, Vincent Y. Shen, Requirements elicitation for the design of context-aware applications in a ubiquitous environment,ICEC 2005 [7] Wikipedia page https://en.wikipedia.org/wiki/Context_awareness [8] K.K. Ramakrishnan, Prashant Shenoy, Jacobus Van der Merwe, Live Data Center Migration across WANs:A Robust Cooperative Context Aware Approach, AT&T Labs-Research& Universityof Massachusetts, INM 2007. [9] Bencomo N., Whittle J., Sawyer P., Finkelstein A., Letier E., Requirements Reflection: Requirements as Runtime Entities, ICSE 2010. [10] Qureshi N., Perini, A., Requirements Engineering for Adaptive Service Based Applications, RE 2010. [11] Sutcliffe A., Fickas S., Sohlberg McKay M., PC-RE: A method for personal andcontextual requirements engineeringwith someexperience, University of Manchester, 2006. [12] Ramirez, Andres J., Jensen,Adam C., Cheng, Betty H C, A taxonomy of uncertainty for dynamically adaptive systems, SEAMS 2012 [13] Evans Carl, Brodie Lindsey, Augusto Juan Carlos, Requirements Engineering for Intelligent Environments, 2014 ICIE. [14] L. Pasquale, L. Baresi, B. Nuseibeh, Towards adaptive systems through requirements@runtime,in: Proc. MRT, CEUR-WS.org, 2011, pp.13–24.