Specifying and reasoning about contextual preferences in the goal-oriented requirements modelling

Goal-oriented requirements variability modelling considers both the intentions, which are captured as goals in goal models, and the preferences of different stakeholders as the main sources of system behaviour variability. Most often, however, intentions and preferences vary according to contexts. In this paper, we propose an approach for a contextual preference-based requirements variability analysis in the goal-oriented Requirements Engineering. We introduce a quantitative contextual preference specification to express the varying preferences imposed over requirements that are represented in the goal model. Such contextual preferences are used as criteria to evaluate alternative solutions that satisfy the requirements variability problem. We utilise a state-of-the-art reasoning implementation from the Answer Set Programming domain to automate the derivation and evaluation of solutions that fulfill the goals and satisfy the contextual preferences. Our approach will support systems analysts in their decisions upon alternative design solutions that define subsequent system implementations.


INTRODUCTION
Requirements variability, which is typically characterised by creating multiple subsets of requirements, has long been advocated in Requirements Engineering (RE) to establish a problem-space-oriented approach to software adaptability [5], This is an eprint version of the work published in the Proceedings of the Australasian Computer Science Week Multiconference 2018.The definitive version is accessed via https://doi.org/10.1145/3167918.3167945[17], [9].Each subset, called a requirements variant, describes a candidate solution to the general requirements variability problem: deriving which requirements to achieve, as well as which alternatives to adopt in reaching those requirements.
Preferences have become an important factor to consider in this challenge of requirements variability analysis.Various preference-based goal models have been proposed to support the goal-oriented approach of requirements specification.Such models represent requirements as goals which are classified as either hardgoals or softgoals.In the context of this paper, hardgoals are the mandatory stakeholder requirements that need to be fulfilled.Each hardgoal has a means of fulfilling it, and such means is likewise considered a hardgoal.In a given goal model, a set of these means compose a requirements variant, defining a candidate solution to the depicted requirements problem.Softgoals, on the other hand, are the optional requirements often expressed as high-level quality requirements.
Traditionally, qualitative or quantitative preference valuations specified over the softgoals are used to distinguish the requirements variants.With the qualitative preference valuation, preferences between any of the softgoals are directly specified, typically as a binary relation.This presents a natural way of expressing the desirability of one softgoal over another.A qualitative approach can directly model an explicit expression of a stakeholder's preference, such as: "We prefer maintaining patient's independence than providing better comfort".In this regard, we take for example a goal such as patient takes medication as one of the hardgoals of a personal medication assistant application.There are two means of fulfilling this hardgoal: a self-initiated intake which can encourage a patient to be independent, or a robot-assisted intake which can provide a patient with better comfort.Consequently, solutions containing the former would be more desirable than those with the latter.With approaches using quantitative preferences, goal models integrate scoring functions associating numerical scores over softgoals to indicate prioritisation by stakeholders.Such numerical preferences are more precise and intuitively understandable as long as there is a readily available knowledge about the degree to which one softgoal is desired over another.For instance, the softgoals that the stakeholders may be interested to satisfy could be ranked by assigning scores based on importance.
Most often, preferences vary.Different stakeholders can have different preferences in different situations.We refer to such situations as contexts, which are facts that capture the nature of the system's operational environment.Referring again to the means of achieving the goal patient takes medication: a robotassisted or a self-initiated (non-robot assisted) intake, varying preferences can be imposed between these two alternatives.For instance, when the patient has dementia, a robot-assisted intake may be preferred, whereas when the patient goes outdoors, a self-initiated intake is necessary.A patient may also state particular preferences such as, "I prefer robot assistance when I am busy or when I'm tired", "I believe I'm still strong and capable of taking the medication on my own, but it would be nice to use the robot when my rheumatism attacks as it'd be difficult for me to move", or "As long as the medicine is within my reach, I might not need the robot".It is worth noting that variations in stakeholder preferences depend on context.However, such contextual preference variability has been given little attention in the literature.
In this paper, we propose an approach for a contextual preference-based requirements variability analysis in the goaloriented RE.We propose a contextual preference model that enhances preferences with contextual information to capture the changing nature of stakeholders' desires caused by context variation.Here, we capture two ways of expressing preferences.First, stakeholders may attribute different levels of importance to softgoals.Preferences are therefore imposed over such goals.Second, stakeholders may also express preferences over the alternatives, i.e., a means to achieving a goal is preferred over another alternative.Hence, preferences are not only asserted for softgoals but may also be expressed for hardgoals.As such, a stakeholder may convey their preferences explicitly, particularly among alternative hardgoals.We then propose a reasoning technique that applies the contextual preferences to derive and evaluate requirements variants.Our approach can guide analysts in their decisions about alternative design solutions that will best satisfy a requirements problem.

BACKGROUND AND MOTIVATION
Goal-Oriented Requirements Engineering (GORE) [26], [19] has become a mainstream technique in RE that has shifted the perspective of requirements from functional to intentional.The functional perspective is reflected in traditional structured analysis techniques and considers requirements as functions that the system should support.The intentional perspective views requirements as the main expression of stakeholders' intentions and explicitly represents the why (intended purpose) of the system [13], [8], [7].In GORE, goal models capture and refine stakeholders' goals, where such goals represent the requirements of a system.
Our attention to requirements variability focuses on finding solutions to a given requirements problem.We consider a solution as a combination of tasks that must be operationalised to achieve the overall goal, i.e., the root goal.A considerable source of requirements variability are preferences.In RE practice, managing requirements has been strongly influenced by optionality and prioritisation [7].In this regard, goal modelling classifies requirements into two types, based on their optionality among potential solutions: mandatory requirements are the necessary ones to fulfill the root goal, and optional requirements are desired but not necessary to fulfill the root goal [16], [7].A mandatory requirement is represented by a hardgoal while an optional requirement is the nice-to-have one, represented by a softgoal.In order to become acceptable, a solution has to fulfill the mandatory requirements.An acceptable solution does not have to achieve an optional requirement, but if it does, such a solution becomes more desirable than those which do not.We aim to understand how contextual preferences posed by stakeholders over these requirements impact the variability of the alternative choices that will comprise a solution.

Overview of Goal Modelling
A typical goal model is an annotated AND/OR graph showing how higher-level goals are satisfied by lower-level ones (i.e., goal refinement), and conversely, how lower-level goals contribute to the fulfilment of higher-level ones (i.e., goal abstraction) [27].We show in Figure 1 a partial goal model that specifies the requirements of a personal medication assistant further described in Section 2.2.The main elements of a goal model are goals.Goals, represented by the oval and cloud shapes, prescribe the intents (i.e., state of affairs or conditions) the system or actors of interest would like to satisfy.The leaf-level goals are called tasks -those in the hexagonal shapes -and define specific activities performed by the system or actors to operationalise and fulfill their goals.The relationships among goals and tasks are mainly depicted by means-end links ( → ).There is a means (i.e., sub-goal or task) to fulfill a certain end (i.e., parent goal).Multiple means are associated with the AND-/OR-decomposition links ).An AND-decomposed goal implies that the satisfaction/performance of each of its children is necessary for it to be fulfilled.An OR-decomposed goal indicates that the satisfaction/performance of any of its children is sufficient to satisfy the parent goal.
Goals are mainly classified as either hardgoals or softgoals.A hardgoal, also called a behavioural goal [27], declaratively prescribes an intended system behaviour.It is denoted by an oval shape in Figure 1.A hardgoal has a clear-cut criterion to decide whether it is satisfied or not, e.g., a set of system operations can be performed to satisfy such goals.For instance, the goal track medication history (g2) is satisfied by performing the tasks: patient confirms intake, auto-monitoring of vital signs, and inform relatives.In contrast, a softgoal (denoted by the cloud shape) cannot be established in a clear-cut sense.It can be satisfied to a 'good enough' degree, depending on subjective judgement and based on relevant evidence.For the personal medication assistant, we cannot say in a strict sense whether a certain system behaviour satisfies or not the goal of minimal patient effort.However, we may say that one system behaviour contributes further to minimising the patient's effort than another.Thus, the degree of satisfaction of a softgoal may be higher or lower when comparing between the alternatives.Because goal satisfaction should not be judged in a strict sense with softgoals, the phrase goal satisficing is sometimes used instead [27].Relationships between hardgoals and softgoals are then established by the contribution links -the make ( ++ → ) and break ( −− → ) links, denoted by the dashed arrow lines in the figure .The make link means that satisfying or performing the origin hardgoal or task satisfices the target softgoal.The break link means that satisfying or performing the origin hardgoal or task denies satisficing the target softgoal.Nonetheless in both cases, if the origin is neither satisfied nor performed, this does not imply anything about the target.Through such correlations, the different alternatives that contribute to different degrees of satisfying the softgoals can be reflected.
A goal model can be represented formally so that each goal g is associated with a propositional literal and the satisfaction of the root goal is represented by the propositional formula G ≡ Tg  Qg.This Propositional Calculus equivalent formalism is similarly used in [15] and can directly apply to the diagrammatic formalism in our goal model.The formula Tg denotes the AND/OR structure in terms of leaf level literals, i.e., tasks.Qg is the additional constraint links, i.e., contribution links.Given two goals g1 and g2, the constraint links g1 ++ → g2 and g1 − − → g2 respectively result as conjuncts g1 → g2 and g1 → ¬g2 in the formula Qg.In both Tg and Qg, a literal representing a non-leaf node is recursively replaced by its AND/OR decomposition until a clause that contains only leaf level nodes is reached.For instance, for the goal g1 in Figure 1: Tg1 ≡ t1 OR ((t2 AND (t3 AND t4))) and Qg1 ≡ (t1 → sg3) AND (t1 → sg1) AND (t1 → ¬sg4) AND ((t2 AND (t3 AND t4)) → sg4) AND (t1 → ¬sg4) AND ((t2 AND (t3 AND t4)) → ¬sg1).Hence, an alternative solution for a goal model would satisfy the resultant propositional formula G.
Our goal model adopts a subset of the i* goal modelling language originally proposed in [29].Multiple variants of this language have been proposed and an effort towards its standardisation is already initiated, i.e., iStar 2.0 [4].In our example in Figure 1, we omit some fundamental language constructs for simplicity.For example, some of the leaf-level tasks can be delegated (i.e., via dependency links) to other actors such as external services and systems, e.g., the task inform relatives may be delegated to a service provided by a mobile notification application.Moreover, we minimise refinements of the leaf-level goals (i.e., considered as tasks), even though they could be further AND-/OR-decomposed into lower level forms such as by applying the variability frames approach introduced in [15].For instance, the task of informing relatives could be refined by considering the concern of the information, whether it's a problem alert or an intake notification.Likewise, the manner to provide intake directions (e.g., through mobile phone or medicine cabinet screen) or the different ways of manual monitoring of medication side effects (e.g., patient manually inputs observation, tele-consultation, or a visit to the physician) could be represented.

Motivating Scenario: Personal Medication Assistant
We consider a requirements scenario from the RAMCIP (Robotic assistant for MCI patients) project [12], particularly the function of providing assistance for taking medications.We describe an assistive medication system, i.e., personal medication assistant, which facilitates patients' medication routine, both to ensure that a patient takes the needed medication, and to monitor proper medication or food supplement intake.We enumerate some objectives and functions of the system.It gives reminders when an intake is missed, or when a patient is leaving home and has to take some pills.It provides intake directions (e.g., correct dosage), or a warning at an attempt to take the wrong pill.It keeps a record of the patient's medicine intakes and monitors medication results and side-effects.To maintain peace of mind and the feeling of assurance, an intake is conveyed to relatives.
Similarly, for problems such as consecutive misses or negative side-effects, the system informs external parties like relatives or caregivers.In order to perform such functions, the system utilises appropriate services from objects within the smart home of the patient.For example, a reminder uses the display service of the kitchen TV when the patient is in the kitchen.The capability of the patient should also be considered by the system.When a patient with a mild hearing impairment is in their backyard lawn, a reminder utilising an audio speaker service is adjusted to a higher volume to ensure being noticed.At times when a patient is tired or unable to walk to the medicine cabinet, the medicine dispenser is fetched by a robot service.But when an accompanying person (e.g., relative or caregiver) is present, the use of a robot should be restrained as human assistance is preferred for self-initiated intake.We illustrate in Figure 1 a partial requirements goal model of the personal medication assistant.A candidate solution, which satisfies the overall requirements problem posed by the root goal, is a set of tasks.For instance, the tasks [t1, t5, t7, t9] and [t3, t4, t2, t5, t8, t9] are each a candidate solution to the requirements problem defined by the root goal g0.A solution strictly satisfies the AND/OR structure.In contrast, neither the tasks [t6, t7, t9] nor [t2, t3, t4, t6, t7] are acceptable solutions.Neither satisfies the AND/OR decomposition, i.e., the goal g1 is not achieved in the former, and the latter failed to satisfy the AND refinement of g2.
From the aforementioned requirements scenario, we observe the potential alternatives of behavioural designs that can be specified to meet every system objective.These alternatives (aka.variabilities) come as the OR-decompositions in the goal model, e.g., t1 or g3 are alternatives to fulfill g1.We call an ORdecomposed goal as variability point, e.g., g1.Because operationalising such large space of alternatives would be onerous, it becomes practical to identify the more suitable ones to comprise a solution from which conforming design decisions can be derived.The suitability of a solution may depend on either context instances or the criteria given by stakeholders, or both.On the one hand, the applicability of each alternative can be context dependent.On the other hand, various stakeholders, like patients, care givers, relatives, physicians, and organisations providing services or goods, may have different prioritisation over i) the elements comprising the solution set (alternative hardgoals) or ii) the high-level objectives of the alternative solutions (softgoals).Moreover, even the same stakeholder, e.g., an individual patient, can have different priorities in different times and situations.Overall, this requirements scenario raises the question, "Which among the behavioural design alternatives are suitable to the stakeholders' preferences in a given situation and context".Accordingly, there is a need to represent both context instances and stakeholders' criteria as means to explicitly characterise every solution set.

THE CONTEXTUAL PREFERENCE MODEL
In this section, we present a model that associates preferences with contexts.We enhance a quantitative preference specification over goals, e.g., [16], with contextual annotations.In particular, we build our model from the approach proposed by Stefanidis et al. in [23].

Context Specification
It is important to show how to specify the contexts in which preferences apply.Given the system's high-level goals and their refinements, we identify a finite set of entities comprising the operational environment.
Definition 1 (Context dimension).Given a system S, the context dimension of S, CDS, is a finite set of entities, CDS = {C1, C2, …, Cn}.Each entity Ci, 1 ≤ i ≤ n, is called a context element.
Context dimension is a set of environment entities relevant to the system.Each entity represents a physical or conceptual object that can take observable values to describe a particular contextual instance.For example, take the personal medication assistant.We identify several relevant context elements: patient_activity, patient_location, patient_illness, weather, body_condition, and accompanying_people.Hence, its context dimension is CDPMA = {patient_activity, patient_location, patient_illness, weather, body_condition, accompanying_people}.We show in Table 1 context elements composing the context dimension of our personal medication assistant.Each element has an enumerated domain of values.Here, we adopt the representational view for context described in [6].We note that context values are data the system has to capture from its environment.Methods of capturing context, however, are beyond the scope of this paper.
A context instance is the state of fact that describes the environment by assigning values to the elements of a context dimension.For our personal medication assistant, (busy, outdoor, dementia, good, normal, alone) and (busy, near_dispenser, where cq  dom(Ci), 1 ≤ q ≤ r.
A combined context assertions of the elements in a context dimension is used to specify context instances.This combination, which we call con, is an expression (con(C1)  …  con(Cn)), where con(Ci) is a context assertion for a single element Ci  CDS and there is at most one context assertion for Ci.If the context assertions of all context elements do not appear in con, the values of the missing element are considered indifferent.Hence, whenever Ci is not found in con, an assertion Ci  {All} is implicitly included as part of con, where All is a value that denotes all the values from the domain dom(Ci) of context element Ci.For example, given CDPMA, the combined context assertion con = (patient_location  {indoor}  weather  {good}  body_condition  {tired, sick}) specifies two context instances: (All, indoor, All, good, tired, All), and (All, indoor, All, good, sick, All).Essentially in this example, con would specify a set of 36 context instances defined by the Cartesian product V1 × V2 × … × Vn, where Vi = {c1, …., cr} for each context assertion Ci  {c1, …., cr}.However, the use of the value All reduces this number of context instances to only two.

Contextual Preference Specification
Preference specification has two general approaches: a qualitative and a quantitative preference.The qualitative approach directly specifies preferences between objects of concern, typically by using binary preference relations.The quantitative approach indirectly specifies preferences, using scoring functions that associate a numeric score to the objects of concern.Contextual preference specification, which explicitly indicates the context instance a preference holds, can apply to both approaches.In this work, we use a quantitative contextual preference model in which we annotate preferences with both contexts and scoring components.


Action is a satisfaction expression of a desired property in the solutions implied by the goal model.Action is in the form satisfy(g) or perform(t) respectively denoting the preference to the satisfaction of goal g or performance of task t.
 con is a (combined) context assertion.


score is a numerical value in the range [0,n].
Our contextual preference specification employs a scoring mechanism that follows the quantitative preference framework of Agrawal and Wimmers [1], which was also used in [10] and [23].The scoring component score indicates the degree of prioritisation assigned to an Action considering the set of context instances specified by con.The value n, which in this paper is set to 10, means extreme interest and the value 0 means no interest.
The contextual preference specification allows the expression of priorities through priority rankings of the desired properties of expected solutions, as well as considering the circumstances that hold for such priorities.We take as an example the goal model of our personal medication assistant.The contextual preference (perform(robot-assisted), patient_illness  {dementia}, 9) expresses that when the patient has dementia, performing the task robotassisted for taking a medication is preferred with a priority score of 9.
Multiple satisfaction expressions that are given similar preference scores on a particular situation can be combined in a single contextual preference notation.The contextual preference p1 in Figure 2 combines the three preferences for perform(t1), perform(t5), and perform(t7), and each one is similarly preferred with a score of 9 when the patient's illness is dementia.The symbol • is used as a separator in this shortcut notation.Definition 5 (Preference catalogue).A preference catalogue P is a set of contextual preferences that applies to a particular requirements goal model.
A preference catalogue, through its set of contextual preferences, defines the priorities imposed over the hardgoal alternatives and softgoals in a certain situation or context.A catalogue may contain the desires of an individual stakeholder or a combination of desires from various stakeholders.A higher score for a contextual preference indicates a higher level of importance of satisfying/performing the associated goal/task.This stands in comparison to the respective alternatives that either have contextual preferences with lower scores or those not mentioned at all.For instance in Figure 2, which shows a preference catalogue for our personal medication assistant, contextual preference p2 and p4 are respectively associated to t1 and g3, which are both alternatives to satisfying goal g1.It becomes explicit that g3 is preferred over t1 when the patient location is near_dispenser, or even if both context instances in p2 and p4 hold.A similar notion is applied to the contextual preferences over softgoals.Softgoals do not always have equal importance.Different stakeholders in different contexts are interested in satisfying different subsets of softgoals, to which they also give different levels of importance.Referring to Figure 2, only three softgoals are given importance among all softgoals in the goal model.This is regardless of the type of patient illness, p1 = (perform(t1) • perform(t5) • perform(t7), patient_illness  {dementia}, 9) p2 = (perform(t1), body_condition  {tired, sick}, 3) p3 = (perform(t1), accompanying_people  {alone}  patient_activity  {busy}, 4) p4 = (satisfy(g3), patient_location  {near_dispenser}, 8) p5 = (satisfy(g3), accompanying_people  {caregiver, relatives}, 5) p6 = (perform(t8), weather  {good}, 7) p7 = (satisfy(sg1), patient_illness  {All}, 6) p8 = (satisfy(sg6), patient_illness  {All}, 2) p9 = (satisfy(sg5), patient_illness  {All}, 2) Figure 2: A preference catalogue.
i.e., patient_illness  {All}.The most important softgoal sg1 has the highest preference score of 6, both sg6 and sg5 with a preference score of 2, while all other softgoals are regarded as indifferent, i.e., their preference score is 0.

REQUIREMENTS VARIABILITY IN VARYING CONTEXTS AND PREFERENCES
We show how the candidate solutions in a goal model satisfy the given preference specification in various degrees.To simplify discussion in this section, we take a fragment of our personal medication assistant goal model as shown in Figure 3.That fragment is a subgraph that describes the goal track medication (g2) which is AND-decomposed to: record intake (g5), monitor medication effects (g6), and inform relatives (t9).Both g5 and g6 are further OR-decomposed to: patient confirms intake (t6), autoconfirm intake (t5), and auto-monitoring of vital signs (t7), manual monitoring (t8) respectively.Even in this small example, there can be several potential solutions for satisfying the root goal g2.
Each solution, which is composed of a set of leaf-level tasks, must satisfy the AND/OR structure of the root goal.For instance, the tasks [t6, t5] do not comprise a solution for the root goal because the monitoring of medication side effects is achieved at all.Given a preference catalogue P, we identify the contextual preference specifications from P that are relevant to a given situation.This situation is defined by a context instance which may refer to either case: a potential condition for a system-to-be or the current operational environment.In the former case, the context instance is explicitly expressed to explore the suitability of various behavioural designs.In the latter case, the context instance corresponds to the current context, that is, the context surrounding a running system.In such latter case, we assume a requirements model at runtime [25] that facilitates runtime adaptation, such as the goal-based service composition approach in [3].The advances in sensor and context-aware technologies enable the capture of such context instances and various methods for capturing this (implicit) context are considerably discussed in the literature.
A contextual preference p is relevant to a given situation when any context instance of p implies the context instance of the given situation.A context instance of p must be the same or more general than that of the given situation.Suppose a situation is described by the context assertion con = (patient_activity  {idle}  patient_location  {living_room}  patient_illness  {dementia}  weather  {good}  body_condition  {normal}  accompanying_people  {caregiver}).Consequently, this situation is specified by the context instance (idle, living_room, dementia, good, normal, caregiver).From the preference catalogue in Figure 2, we identify the relevant contextual preferences: p1, p5, p6, p7, p8, and p9.However, using the goal model in Figure 3, only p1, p6, p7, p8, and p9 would be relevant, i.e., we exclude p5 because it involves g3 which is not part of Figure 3.These relevant preferences are shown in Figure 4.The contextual preference p1 is an explicit expression of prioritisation on the alternatives t5 and t7 for achieving goals g5 and g6 respectively.p6 expresses the degree of preference to t8 for achieving g6.p7, p8, and p9 are the preferences for the preferred softgoals sg1, sg6, and sg5 respectively.

Softgoal Preferences
To calculate the softgoal preference score, we regard the contribution links from a solution to the preferred softgoals.We apply the approach, set forth by the NFR framework [18] and further reused in [27] and [2], using quantitative estimations for assessing the positive or negative contribution of the candidate solutions to the softgoals.This approach considers every contribution link as evidence of the positive or negative satisfaction of a preferred softgoal.

→
) with respect to the total number of contributions from sol to sgi.These functions are used to normalise the different number of contribution links upon softgoals.The function score(sgi) is the priority degree defined for sgi in a contextual preference.Where sgi appears in multiple relevant contextual preferences, the highest defined score for sgi from among the relevant preferences is chosen for score(sgi).
We show in Table 2 the derived softgoal preference score of each candidate solution of our requirements problem illustrated in Figure 3.A matrix cell associated with a candidate solution sol and a softgoal sg captures the contrib(sol, sg), which is the estimated preference score of sol with respect to sg.The last column of the matrix shows the total preference scores of each candidate solution, i.e., sps(sol).For instance, sps(a) = 6 is the sum of the preference scores of solution a: [t5, t7, t9] with respect to each preferred softgoal.

Hardgoal Preferences
We consider the relevant contextual preferences over some hardgoals in the goal model to derive the hardgoal preference score of each candidate solution.
Definition 8 (Hardgoal preference score).A hardgoal preference score hps(sol) is the score derived for a solution sol with respect to the contextual preferences over the goal alternatives.
hps(sol) = pref(sol, hg1) + … + pref(sol, hgn), where:  pref(sol, hgi) = score(hgi), is the preference score of the solution sol to the alternative hardgoal hgi, The function score(hgi) is the priority degree defined for hgi in a contextual preference.Where hgi appears in multiple relevant contextual preferences, the highest defined score for hgi from among the relevant preferences is chosen for score(hgi).For instance, contextual preference p4 and p5 in our preference catalogue in Figure 2 both define preferences for satisfying g3.
When both p4 and p5 become relevant in a given situation, score(g3) = 8, which is the higher score of the two.Using the same goal model in Figure 3 and contextual preferences in Figure 4, we show in Table 3 the derived hardgoal preference score of each candidate solution.The middle column lists the pref(sol, hg) -the preference score of each preferred hardgoal hg that is satisfied in a particular solution sol.The last column totals the preference scores deriving the respective hps(sol).For instance, hps(a) = 18 adds the preference scores associated with the preferred hardgoals, t5: 9, t7: 9, that are satisfied in the solution a: [t5, t7, t9].

Preference Satisfaction Degree
Each solution satisfies the relevant contextual preference specifications to a different degree.By considering both the softgoal and hardgoal preference scores, we derive the preference satisfaction degree for each candidate solution.We add the softgoal and hardgoal preference scores psd(sol) = sps(sol) + hpd(sol).Hence, given the context instance (idle, living_room, dementia, good, normal, caregiver) and the contextual preference specifications in Figure 2, the preference satisfaction degree of solution a, b, c, d, are 24, 14, 11, and 1 respectively.In a different situation, such as for a patient without dementia: we define a context instance (idle, living_room, normal, good, normal, caregiver).This would change the relevant contextual preferences to p6, p7, p8, and p9.Although preferences p7, p8, p9 to the respective softgoals sg1, sg6, sg5 remain the same, only the hardgoal alternative t8 is preferred, as defined in p6.
Consequently, we derive 6, 5, 2, 1 as the preference satisfaction degree of solution a, b, c, d, respectively.Should the context further change to (idle, living_room, normal, bad, normal, caregiver), such as when the weather becomes bad, the satisfaction degree of the solution a, b, c, d would be 6, -2, 2, -6, respectively.The latter context instance would consider only the softgoal preferences because no hardgoal preference applies.
As we have discussed in Section 2.2, different stakeholders have varying priorities across different situations.Our preference catalogue, for example as shown in Figure 2, captures both the different stakeholder priorities and the variations of such priorities.On the one hand, the catalogue can comprise individual preferences from various stakeholders, e.g., patient users, physicians, system default preferences, or organisational policies of the assistive medication service provider.On the other hand, expressing priorities as contextual preferences captures the variations of such priorities in different situations.For instance, the contextual preferences p1, p2, and p3 express different prioritisations over the alternative task t1.This can be interpreted as either the preferences of different stakeholders to t1, or the varying preference to t1 that depends on context.The latter can consider the preferences as the changing levels of interest of one stakeholder for t1.
Moreover, a contextual preference specification in the preference catalogue can be added, removed, or updated whenever necessary.Suppose the stakeholders decide that among the three preferred softgoals, maintaining privacy should become the most important as long as the patient has no dementia nor MCI.Otherwise, the originally set preferences remain.We can resort to either two options.The first option is keeping the present softgoal preference specifications unchanged and adding a new one that gives the softgoal minimise intrusion (sg6) with a score higher than the rest.For example, we add p10 = (satisfy(sg6), patient_illness  {normal}, 8).Hence, in a situation that defines patient_illness = normal, the contextual preference p8 and p10 would become relevant, i.e., both apply to the situation and softgoal sg6.In this case, score(sg6) = 8, that is, being the higher score between the two.The second option adds two new contextual preferences.For example, we add p10 = (satisfy(sg6), patient_illness  {normal}, 6) and p11 = (satisfy(sg1), patient_illness  {normal}, 2).This is consistent with the scoring of the existing softgoal preference specifications, i.e., similarly assigning 6 as score for the most important one.Likewise, we need to update the context assertion of p7 and p8, i.e., p7 = (satisfy(sg1), patient_illness  {dementia, MCI}, 6) and p8 = (satisfy(sg6), patient_illness  {dementia, MCI}, 2).The context assertion is now altered from patient_illness  {All} to patient_illness  {dementia, MCI} for both contextual preferences.Therefore, in both options, when the patient is normal, i.e., patient_illness = normal, the candidate solutions that may get higher softgoal preference scores are those that positively contribute to the softgoal minimise intrusion (sg6).Considering the second option and the context instance (idle, living_room, normal, good, normal, caregiver) which reflects patient_illness = normal, we derive for our goal model in Figure 3 preference satisfaction degree -2, 5, 2, 9 for solutions a, b, c, and d, respectively.

REASONING ABOUT CONTEXTUAL PREFERENCES
We exploit the powerful method for declarative knowledge representation and reasoning provided by Answer Set Programming (ASP) [14] to support automation of the techniques described in the previous section.We develop a prototype reasoning tool that extends DLV2 -a state-of-the-art ASP implementation.We translate both the goal model formalisms and contextual preference specifications into a disjunctive logic program appropriate for a DLV input file.Overall, our tool takes as input the goal model, the contextual preference specifications, and the context instance describing a situation.Then, it returns the derived alternative solutions to the goal model problem.The solutions are ranked by preference satisfaction degree.
We refer to the goal model in Figure 1 and apply the preference catalogue in Figure 2. Assuming a context instance (busy, living_room, dementia, good, tired, caregiver) that defines respective values for the context elements (patient_activity, patient_location, patient_illness, weather, body_condition, accompanying_people), the resulting ranked solutions are shown in Table 4.In this particular situation, the relevant contextual preferences are p1, p2, p5, p6, p7, p8, and p9.Solutions that include most of the highly preferred hardgoals and those that positively contribute to most of the preferred softgoals get better scores.We look at the solution with the highest satisfaction degree: [t1, t5, t7, t9], that is, the optimal solution.It contains t1, t5, and t7, which are the highly preferred alternatives when the patient has dementia, as specified by p1.The contextual preference p2 also applies, but its effect is overshadowed by p1, since both preferences associate with t1 (see Section 4.2).
Regarding the softgoal preferences, the optimal solution has two (non-negated) negative contributions to the preferred softgoal sg6, but the (non-negated) positive contributions to the preferred softgoals sg1 and sg5 have more weight, thus, still obtaining a significant positive softgoal preference score.We applied our approach on five goal models with increasing sizes.Table 5 summarises the results of running our tool over these models on a machine with 3.19 Ghz CPU and 16 GB RAM.Row 1 shows results for our original goal model in Figure 1.We cloned our original goal model to itself, to obtain those goal models with larger sizes, a similar approach done in [28].Simultaneously, we cloned the contextual preferences in Figure 2 to generate preferences that apply to each goal model.The times in Table 5 show the mean of 20 runs of our tool over the same goal model and set of contextual preferences.The times are rounded-off to the nearest tens.All times are directly observed from running our tool except the time for contextual preference reasoning which we derived as TPR = TOS -TNS.Our results show an exponentially increasing computation time to derive an optimal solution, as the goal model problem grows in size.Overall, although comparisons with other approaches are yet to be done, our tool performs considerably well in the test cases having up to 4,096 alternative solutions.We believe that most realistic small to medium-sized goal model problems would fall within or closely above such potential number of solutions.However, this performance is still less sufficient particularly for large-sized goal model problems, since it took 160.7 seconds to find the optimal solution among 32,768 candidate solutions.

RELATED WORK
The importance of capturing preferences in requirements modelling has been extensively recognised in the literature.With the potentially large space of candidate solutions to the requirements problem, stakeholder preferences have been used as criteria for comparison.There are two main types of preference specification: the qualitative specification, such as in [22], [11], [21], and [7]; and the quantitative specification, as like in [24], [16], and [20].We first look at the qualitative ones.In the novel requirements modelling framework Techne [11], requirements and their relations are represented in a graph called r-nets.A preference is represented as a node in the model to express a binary relation between two requirements.An arrow line is drawn from the more preferred requirement to the preference node, and from the preference node to the less preferred requirement.Another qualitative preference specification framework is the CI-net [21], which captures complex binary preferences tradeoffs between multiple optional goals and ranks those goals based on the preferences.Both frameworks aim to find a set of highly preferred optional goals to be set as criteria in comparing candidate solutions.Moreover, the pQGM framework [7] extends the qualitative goal modeling framework in [22] to accommodate priorities expressed among i) optional goals and ii) goal alternatives.This framework utilises r-nets to express a binary preference relationship between goal model elements.
Alternatively, the quantitative preference specifications are more elaborate by using numerical weights.The work in [24] quantitatively measures the impact of alternative solutions on the degree of satisfaction of softgoals.Evaluating such impacts is used in the selection of a most preferred alternative.Liaskos et al. [16] proposed a goal modelling framework that considers numerical preferences expressed over optional goals.A planner is utilised to identify solutions that would best satisfy the specified preferences.Nguyen et al. [20] proposed the CGM-Tool, a realisation of an expressive modelling language that provides constructs to express both qualitative and quantitative preferences.In addition to the binary preference relations between goal model elements, the CGM-Tool can also express numerical preferences as i) attributes (i.e., penalties or rewards) for goals and ii) numerical objectives to optimise.Our approach similarly captures stakeholders' preferences to reason about alternative solutions.However, we believe that preferences are not fixed and may vary according to context.Hence, we focus on representing and reasoning about contextual preferences, which has been given less attention in the RE literature.None of the aforementioned works have explicitly captured the varying preferences attributed to contextual changes.

CONCLUSION AND FUTURE WORK
We introduced a goal-based requirements variability framework for modelling and reasoning about contextual preferences.The framework presents a contextual preference specification that extends the traditional requirements preferences with contextual information.Context is modelled as a set of environment elements.Each of the elements takes a value from its corresponding domain to define a context instance.The context instance describes the situation expressed by the context assertion that annotates a requirements preference.Hence, a contextual preference specification defines the situation when a particular level of importance, which is assigned as a numerical score, is given to an alternative hardgoal or a softgoal.A goal model with the contextual preference specification is further translated into a disjunctive logic program.The state-of-the-art DLV, which is a powerful implementation for knowledge representation and reasoning, is utilised to derive alternative solutions to the requirements problem.The derived solutions are further ranked according to their degree of satisfying the contextual preferences.
Our framework is useful in exploring potential system designs to be operationalised, that is, considering the satisfaction of the varying fitness criteria posed by stakeholders.While our framework aims to find one most optimal solution, it can also provide multiple potential solutions, i.e., the top-ranked (optimal) solutions.Providing multiple solution alternatives might give flexibility to the systems analysts in making their decisions.For our on-going and future work, we are looking for case studies to integrate our approach with industrial requirements analysis practices of which we expect goal model problems with more complex contextual preferences.We also plan to optimise the associated reasoning approach for our tool to scale well with large-sized goal models and complex contextual preferences.In addition, we plan to address the following problems: dealing with conflicts between contextual preferences, creating and combining contextual preference sets that would allow preferences to be grouped, e.g., according to stakeholders/users, and enabling (visual) traceability of the contextual preferences and the resulting goal model solutions.Furthermore, our quest for a comprehensive context-aware requirements variability framework drives us to continue exploring other relationships between context and requirements variability.

Figure 1 :
Figure 1: A goal model for a personal medication assistant.

Figure 3 :
Figure 3: A fragment of the personal medication assistant goal model.Definition 6 (Imply relation between context instances).Given two context instances cs1 = (c1 1 ,…,cn 1 )and cs2 = (c1 2 ,…,cn 2 ), cs2 implies cs1 if ∀, 1 ≤ i ≤ n, ci 2 = ci 1 or ci 2 = All.A contextual preference p is relevant to a given situation when any context instance of p implies the context instance of the given situation.A context instance of p must be the same or more general than that of the given situation.Suppose a situation is described by the context assertion con = (patient_activity  {idle}  patient_location  {living_room}  patient_illness  {dementia}  weather  {good}  body_condition

Definition 7 (
Softgoal preference score).A softgoal preference score sps(sol) is the score derived for a solution sol with respect to satisfying the preferred softgoals.sps(sol) = contrib(sol, sg1) + … + contrib(sol, sgn), where:  contrib(sol, sgi) = percentPos(sol, sgi) * score(sgi) -percentNeg(sol, sgi) * score(sgi), is the contribution score of the solution sol to sgi,  each softgoal sgi, 1 ≤ i ≤ n, is a softgoal associated to a contextual preference p, and for any two softgoals sgi, sgk, i ≠ k.The function percentPos(sol, sgi) refers to the percentage of the positive contributions ( ++ →) with respect to the total number of contributions from sol to sgi, while percentNeg(sol, sgi) refers to the percentage of the negative contributions ( −−

Table 1 :
Context elements and their values.

Table 5 :
Results of running our tool for five different goal models.NHG NSG NCL NVP NCP NSol TNS TPR TOS TFNS TFOSLegend (all times are in seconds) NHG: number of hardgoals, NSG: number of softgoals, NCL: number of contribution links, NVP: number of variability points, NCP: number of contextual preferences, NSol: number of solutions, TNS: time to derive all non-optimised solutions, TPR: time for contextual preference reasoning, TOS: time to derive all optimised solutions, TFNS: time to derive the first solution (may be a sub-optimal one), TFOS: time to derive the optimal solution but this is negated by the negative contribution from goal g3 upon performing the tasks t2, t3, and t4.Moreover, the resulting ranking changes with the change in context.We expect solutions that contain t2, t3, and t4 to get the better scores when a patient without dementia is near the medicine dispenser as reflected in the context instance (busy, near_dispenser, normal, good, tired, caregiver).