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