Software and Systems Modeling (SoSyM) manuscript No.(will be inserted by the editor)

Requirements-Driven Deployment

Customizing the Requirements Model for the Host Environment

Raian Ali1, Fabiano Dalpiaz2, Paolo Giorgini2

1 Bournemouth University, UK2 University of Trento, Italy

Received: date / Revised version: date

Abstract Deployment is a main development phase whichconfigures a software to be ready for use in a certain envi-ronment. The ultimate goal of deployment is to enable usersto achieve their requirements while using the deployed soft-ware. However, requirements are not uniform and differ be-tween deployment environments. In one environment, certainrequirements could be useless or redundant, thereby mak-ing some software functionalities superfluous. In another en-vironment, instead, some requirements could be impossibleto achieve and, thus, additional functionalities would be re-quired. We advocate that ensuring fitness between require-ments and the system environment is a basic and critical stepto achieve a comprehensive deployment process. We proposea tool-supported modelling and analysis approach to tailorarequirements model to each environment in which the sys-tem is to be deployed. We study the case of contextual goalmodel, which is a requirements model that captures the re-lationship between the variability of requirements (goal vari-ability space) and the varying states of a deployment envi-ronment (context variability space). Our analysis relies onsampling a deployment environment to discover its contextvariability space and use it to identify loci in the contextualgoal model where a modification has to take place. Finally,we apply our approach in practice and report on the obtainedresults.

Key words Requirements Engineering, Contextual Require-ments, Deployment, Context-sensitive Systems Modeling

1 Introduction

Deployment is a main development phase that, among otherthings, customizes a software to fit its operational environ-ment. The goal of deployment is that software becomes readyfor use in its environment and users find it a valid and ef-ficient way to satisfy their requirements. Traditionally, soft-ware deployment concerns the technical configuration of an

implemented system, so as to fit to an instalment environ-ment which includes specific computing resources, operat-ing systems, etc. Though essential, we argue that having asystem correctly assembled and fitting its technical environ-ment is only a part of the deployment process. Deploymenthas to ensure fitness between requirements and the systemenvironment. Lack of such fitness could lead to an undesir-able, and possibly harmful, mismatch between software andits development purpose. Let us take as an example a require-ment like “get user input”. This requirement is achievable viatwo alternative requirements: “by voice recognition” and “byclick-based dialogue”. If the deployment environment is of-ten noisy then the alternative “by voice recognition” is in-applicable regardless a correct deployment of software func-tionalities, settings and equipments.

The software environment includes whatever provides asurrounding within which the software operates. The stateof such environment is denoted by the notion ofcontext[1].Context is variable and requirements are highly affected bycontext variability. The system has to monitor context at run-time and decide upon which requirements to activate, whichsoftware alternatives are applicable and can satisfy the acti-vated requirements, and the quality of each of these alterna-tives. Specifying and implementing the relationship betweencontext and requirements is essential to obtain software sys-tems which meet user requirements in a dynamic environ-ment. However, the space of context variability differs fromone deployment environment to another. Each environmentexhibits a specific contextual variability space and, thus,therequirements have to be customized so as to maximize thefitness with the environment at hand.

Goal models (i* [2], Tropos [3,4], KAOS [5], and GRL[6]) are an intentional ontology used at the early requirementsanalysis phase to explain thewhyof a software system. Goalmodels have been used to represent the rationale of both hu-mans and software systems [7] and they provide useful con-structs to analyse high level requirements (goals) and dis-cover ways to satisfy them. Such features are essential forthe analysis and design of a software system that reflects thestakeholders’ rationale and their adaptation to a dynamic sys-

2 Raian Ali et al.

tem environment [8,9]. Moreover, goal models help to iden-tify alternative software functionalities to satisfy goals. Thisfeature is essential to adapt to context variability of a deploy-ment environment so that a change in context would cause aswitch to a suitable alternative to fulfil requirements. How-ever, the context variability profile of a deployment environ-ment makes some of these alternatives redundant and useless.Moreover, the space of alternatives may be unable to accom-modate certain contexts occurring in the environment. Thediscovery of these cases is important to determine whetherextra functionalities have to be developed and deployed.

In this paper, we advocate that software customizationshould be first studied at the requirements level. The reasonisthat requirements are not uniform and differ according to dif-ferent factors. Hui et al. [10] describe how requirements canbe customized to fit the actual skills of users. Liaskos et al.[11,12] discuss customizing the requirements to users’ pref-erences expressed over non-functional and optional require-ments. Baresi et al. [13] propose adaptation requirements,called adaptation goals, to customize a system at runtime andmaintain a correct execution course. Pourshahid et al. [14]study the alignment between requirements, expressed as goals,and the business process of an organization based on moni-toring a set of Key Performance Indicators (KPIs) and thendecide whether an adaptation action should take place. Thecontext variability of a system environment is also a very im-portant factor which highly affects the customization of re-quirements and we focus on it in this paper.

In our previous work, we have proposed contextual goalmodels to capture the relation between requirements variabil-ity and the variability of context [15–17]. Context is spec-ified at a set of variation points on the goal model and itstruth value defines which requirements are applicable and ac-tive. We refine high-level descriptions of context into con-crete and monitorable criteria to judge if the analyzed contextholds. Moreover, we have developed reasoning mechanismsfor (i) runtime derivation of software configurations to satisfygoals that are applicable in a monitored context and able toaccommodate user priorities, and (ii) design time identifica-tion of the least expensive alternative which guarantees goalssatisfaction in the considered space of contexts [18] and (iii)detecting modelling errors which cause inconsistent require-ments models [19]. Contextual goal models capture the rela-tionship between the variability spaces of both requirementsand context. Each deployment environment exhibits a differ-ent context variability space and this makes some parts ofthe contextual goal model useless, redundant, or insufficient.In this work, we address the customization of requirements,expressed via contextual goal models, to the contextual vari-ability which characterizes a deployment environment.

In this paper, we propose an engineering approach forcustomizing requirements models to fit their deployment en-vironments as an essential step for a comprehensive and com-plete systems deployment process. We consider the case ofcontextual goal models, which is a requirements model thatexplicitly captures the relation between variability of both re-quirements, expressed as goals, and the state of the system

surrounding environment (its context). We develop reason-ing mechanisms to analyse a contextual goal model given acertain deployment environment and customize it by (i) re-moving redundancy and uselessness, and (ii) adding defaultbackup alternatives when the model lacks of alternatives thataccommodate certain context variations. We develop a CASEtool to automate our reasoning and propose a methodologi-cal process to support a systematic customization of require-ments. We evaluate our approach in practice and discuss theresults.

The paper is structured as follows. In Section 2 we reviewcontextual goal models and present our research questions.InSection 3 we introduce our approach for requirements-drivendeployment and explain our CASE tool. In Section 4 we pro-pose a process model for requirements-based deployment. InSection 5 we apply our approach in practice and discuss theresults. In Section 6 we discuss related work, and in Section7we conclude the paper and present our future work directions.

2 Background and Research Question

Each system is situated in a possibly dynamic environment.In our previous work [15,16], we have observed that the dy-namism of a system environment affects whether a require-ment needs to be achieved, restricts the space of adoptable al-ternatives to achieve it, and affects the quality of each of thesealternatives. We have advocated the need to weave togethercontext and requirements. We have proposed to specify con-text (we called it “location” in that work) as a preconditionat certain variation points of a goal model. We have also pro-posed basic automated analysis to (i) derive the set of adopt-able system’s alternatives for a certain context and (ii) deter-mine the context that supports a given alternative. In [17,20],we have proposed the context analysis model, which includesconstructs (statement, fact, support, decomposition) to hier-archically refine context into a formula of monitorable facts.We also proposed a way to derive the contextual workflow ofthe tasks of a contextual goal model.

In [18], we have proposed an automated analysis to rea-son about contextual goal models and derive, at runtime, al-ternatives which best fit both a monitored context and thepreferences of a user expressed as ranking over softgoals.In the same work, we also developed a design-time reason-ing for deriving systems’ alternatives with minimal develop-ment costs. In [19], we have developed automated analysis tocheck the consistency of context in a contextual goal model.We have also developed an analysis to check the conflictsarising from the parallel execution of the software actions(goal model tasks). A first version of a CASE tool was im-plemented to perform the above four types of reasoning.

Research question and contribution. In this work, weaddress a different and important research challenge concern-ing the analysis of contextual requirements to fit a certaindeployment environment. We analyse the fitness between acontextual goal model, which captures the relation betweenrequirements and a space of context variations, and the space

Requirements-Driven Deployment 3

of contexts occurring in and characterizing a certain deploy-ment environment. That is, we customize a contextual goalmodel to the characteristics of a specific deployment envi-ronment. We provide a systematic way to explore that envi-ronment and an automated analysis to customize the require-ments model. The customization here means removing partsof the model which are unusable or redundant in a specificenvironment and, also, indicating loci in the model where anaugmentation is needed to cover cases where the system isunable to meet its requirements in that environment. We alsoextend our CASE tool (RE-Context) to support the proposeddeployment analysis (unusability, redundancy, and augmen-tation) and evaluate our approach on a system for bookingmeeting rooms in an academic environment. Table 1 high-lights the relations between our previous work and this paper.

2.1 Weaving together context and goals

In this section, we describe contextual goal models [15–17],our framework to model contextual requirements. As a run-ning example, we consider a mobile information system sce-nario for promoting products to customers in a shopping mall.The main goal of this system is to promote a set of productsto the customers that are inside the shopping mall. Both cus-tomers and sales staff are provided with PDAs as communica-tion and interaction devices. The system can satisfy its maingoal “promoting a product to a customer” through differentexecution courses. The adopted execution course depends onthe context that may include the state of customers, products,sales staff and other elements in a shopping mall.

In Fig. 1, we show an example of a Tropos contextual goalmodel representing a part of the promotion information sys-tem. Tropos goal analysis [3,4] views the system as a set ofinterdependent actors, each having its own strategic interests(goals). Goals represent requirements at the intentional leveland are analysed iteratively in a top-down way to identifythe more specific subgoals needed for satisfying the higher-level goals. Goals can be ultimately satisfied by means of ex-ecutable processes (tasks).

The actor standing for a customer’s mobile informationsystem (“Customer IS”) has the top-level goal “promote prod-uct [p] to customer [c] in mall [m]”. Goals are iterativelydecomposed into subgoals by AND-Decomposition (all sub-goals should be achieved to fulfil the top goal) and by OR-Decomposition (at least one subgoal should be achieved tofulfil the top goal). The goal “sales staff [ss] delivers a prod-uct [p] sample to customer [c]” is AND-Decomposed into“[ss] is notified” and “[ss] meets [c]”. The goal “promote bygiving free sample of product [p] to customer [c]” is OR-Decomposed into “[c] gets [p] sample of machine [mc]” and“deliver [p] sample to [c] by sales staff [ss]”. Goals are ulti-mately satisfied by means of executable tasks. For example,the goal “[c] knows about [p] and confirm the sample offer”can be satisfied by one of the tasks “interact via voice dia-logue and voice recognition” and “interact via visual dialogueand click-based interaction”.

A dependency indicates that an actor (depender) relies onanother (dependee) to attain a goal or to execute a task: theactor “Customer IS” depends on the actor “Sales Staff IS”for achieving goal “deliver [p] sample to [c] by sales staff[ss]”. Softgoals are qualitative objectives for whose satisfac-tion there is no clear-cut criteria (“less disturbance” is rathera vague objective), and they can be contributed either posi-tively or negatively by goals and tasks: “interact via visualdialogue and click-based interaction” contributes positivelyto “less disturbance”, while “interact via voice dialogue andvoice recognition” in some cases contributes negatively toit.

The goal model of Fig. 1 incorporates multiple alterna-tives the system can adopt to fulfil its main goal “promoteproduct [p] to customer [c] in mall [m]”. A goal model alter-native is a root-to-leaf path in a goal model constructed by se-lecting one subnode in OR-Decompositions and Means-Ends,all subnodes in AND-Decompositions, and one dependencywhen multiple dependencies exist for the same node. Themodel explicitly represents the relation between the spaceofalternatives incorporated in it and context. Contexts, labelledbyC1 . . . C15 in Fig. 1 and explained in Table 2, can be spec-ified at the following variation points:

1. OR-Decomposition. The adoptability of a subgoal (sub-task) in an OR-Decomposition may require a specific con-text.

2. Means-end. Goals can be ultimately satisfied by meansof specific executable processes (tasks). The adoptabilityof each task may require a specific context.

3. Actors dependency. A certain context may be requiredfor an actor to establish a dependency on another actorfor a goal to be achieved or a task to be executed.

4. Root goal. A root goal may be activated only in certaincontexts.

5. AND-Decomposition. The satisfaction (execution) of asubgoal (subtask) in an AND-Decomposition could berequired only in certain contexts. In other words, somesubgoals (subtasks) are not always mandatory to fulfil thetop-level goal (task).

6. Contribution to softgoal. Softgoals are qualitative ob-jectives, i.e., there is no clear-cut criteria for their satis-faction. Softgoals can be contributed either positively ornegatively by goals and tasks. The contributions to soft-goals can also vary from one context to another.

Observation.Some contexts could precondition a goal ora task no matter where it appears in the goal model hierarchy.That is, certain contexts could inherently precondition the op-erability of a goal or a task. For example, let us take the taskT = “print the map of the shopping mall” which belongs tothe reception office system actor, say. For the operability ofT , a context likeC= “the receptionist’s PC is connected to aprinter” should hold no matter where this task appears. Let uscall this aninherent context. However, some other contextualconditions apply on this same task only when it is part of acertain refinement and we call this arefinement context. If Tis a means to satisfy a goalG1= “familiarize emergency teamwith the mall”, we should add toC the contextCa= “there

4 Raian Ali et al.

Work ContributionWeaving context withrequirements [15,16]

- A theoretical ground for weaving together the variabilities of both context and requirements- Defining a set of variation points on goal models where context conditions can be specified- A basic formalization of the model and a set of basic analysis implemented in Datalog

Context analysis [17,20]

- A systematic way to refine context and elicit its specification- A modelling language for context refinement- A systematic way to derive contextual workflows from contextual goal models

Automated analysis ofcontextual goal mod-els [18,19]

- Derivation of the goal alternatives which fit a context monitored at runtime and a set of user preferencesexpressed over softgoals- Derivation of a set of alternatives with minimal costs and able to meet all goals- Checking the consistency of context specification- Checking the consistency of tasks and avoid conflicting actions- A first version of a CASE tool (RE-Context) which implementsthe above four reasoning mechanisms

This work - Advocating the need to explore a deployment environment and customize the requirements model- Providing a systematic approach, based on contextual goalmodels, to explore a deployment environment- Proposing analysis mechanisms to customize a contextual goal model to fit the characteristics of an ex-plored environment by removing uselessness and redundancyand suggesting augmentations- Extending our CASE tool (RE-Context) proposed in [18] to implement the proposed analysis

Table 1 Summary of our previous work and contribution of this paper

Fig. 1 A goal model annotated with contexts at its variation points

is an emergency situation and the emergency team is not fa-miliar with the mall”. If T is a means to achieve a goalG2=“promote the mall” then we should add toC a context likeCb= “the customer is visiting the mall for the first time andhe did not visit another branches with a similar structure”.�

By attaching the context condition to the refinement andnot to the task/gaol itself, we capture both cases: the draw-back is that the annotation of the inherent contexts is repeatedeach time the corresponding tasks or goals appear in a refine-

ment. On the other hand, associating context with a task or agoal itself regardless where it appears in the model leads tomistakes as the previous example shows. It was our designchoice to tolerate this redundancy to improve simplicity andreadability of the model. Alternatively, the analyst can spec-ify inherent and refinement contexts separately. The analysiswe propose in the rest of this paper apply to both ways asit processes the accumulated context of a whole goal modelalternative rather than the individual contexts specified on it.

Requirements-Driven Deployment 5

Ci Description Variation point typeC1 the customer is in the product area for more than 5 minutes, has not got a previous promotion on it, and

promotion is potentially realizableRoot goal

C2 the product can be used with another product the customer already has OR-DecompositionC3 the product is discountable and interesting to the customer OR-DecompositionC4 the product is free sampled and the customer does not have theproduct and does not know about it OR-DecompositionC5 the customer has experience with free samples machines and can reach one of the machines and start to

use it in a short timeOR-Decomposition

C6 a sales staff has the ability and time to explain sufficientlyabout the product to the customer Actors dependencyC7 the customer place is not noisy, and the system is trained enough on the customer voice Means-endC8 the customer has a good level of expertise with regards to using technology and a good control on his

fingers, and the used device has a touch screenMeans-end

C9 there is a sample machine close to and in the same floor as the customer and he is familiar with digitalmaps technology

Means-end

C10 the path between customer and the machine is complex and the customer knows how to interact andfollow the guidance wizard

Means-end

C11 the sales staff PDA vibration is activated and he is holding his PDA and not using it for a call Means-endC12 the sales staff is putting his headphone on and he is not usinghis PDA for a call Means-endC13 the customer is not moving quickly Means-endC14 the customer stays around the sales staff and can be seen easily AND-DecompositionC15 there are other people around the customer and the place is quiet Contribution

Table 2 Description and variation point type for each context in Fig. 1

The context preconditions propagate in a top-down style.The context which preconditions a root goalG will also pre-condition all the nodes belonging to its subhierarchy whenG

is to be achieved. However, certain nodes in the subhierar-chy might also belong to the hierarchies of other goals. Thus,the context preconditioning a node depends on the top nodeswhich were activated and selected. For example, consider ataskT= “turn on the siren”, which could be a means to fulfiltwo goalsG1= “protect mall from robbery” andG2= “protectmall from fire”. Each of these two goals is activated in differ-ent contexts:C1= “a customer with unchecked item is leav-ing”, andC2= “smoke sensors indicate a fire”, respectively.When taskT is a means to satisfyG2, it is also precondi-tioned byC3 = “there is some staff or someone who can hearthe siren and call the emergency”. Thus,C2 andC3 are notalways preconditions forT but only when it is meant to sat-isfy goalG2. WhenT is part of the goal model alternative tofulfil G1, contextC1 will be propagated to it, whileC2 andC3 will not be considered.

2.2 Context analysis

Similarly to goals, contexts need to be analysed. On the onehand, goal analysis provides a systematic way to discover al-ternative sets of tasks an actor can execute to satisfy a goal.On the other hand, context analysis should provide a system-atic way to discover alternative sets of facts an actor needsto verify to judge if a context applies. We specify context asa formula of world predicates. The EBNF of this formula isshown in Code 1. We classify world predicates, based on theirobservability by an actor, into two types:factsandstatements:

Definition 1 (Fact) A world predicate F is a fact for an actorA iff F is observable by A.

Code 1The EBNF of context world predicates formulaFormula :- WorldPredicate| (Formula)| Formula AND Formula|Formula OR Formula

Definition 2 (Statement) A world predicate S is a statementfor an actor A iff S is not observable by A.

An actor can observe a fact if it has the ability to capturethe necessary data and compute the truth value of a fact. Astatement cannot be observed by an actor for different rea-sons, such as (i) lack of information to verify it: (ii) its ab-stract nature makes it hard to find an evaluation criteria. Somedecisions that an actor takes may depend on contexts specifi-able by means of only facts, while some other decisions maydepend on contexts that include also statements. However,a statement can be refined into a formula of facts and otherstatements. We call the relation between such a formula ofword predicates and a refined statementSupport, and we de-fine it as following:

Definition 3 (Support) A statement S is supported by a for-mula of world predicatesϕ iff ϕ provides enough evidence tothe truth of S.

Thesupportrelation is an approximation that analysts in-troduce to infer the validity of a statement from monitorablefacts. In turn, this enables to verify high-level contexts (ex-pressed in business terms) from monitorable facts (expressedin physical terms). In an iterative way, a statement is refinedto a formula of facts that supports it. In our contextual goalmodel, we allow only for monitorable contexts. A context ismonitorable if it can be specified in terms of facts and/orstatements that are supported by facts. A monitorable con-text, specified by a world predicate formulaϕ, applies if all

6 Raian Ali et al.

the facts inϕ and all the formulae of facts that support thestatements inϕ are true. In Fig. 2, we analyse contextC1.In this figure,statementsare represented as shadowed rectan-gles andfactsas parallelograms. The relationsupportis rep-resented as curved filled-in arrow. Theand, or, implicationlogical operators are represented as black triangles, white tri-angles, filled-in arrows, respectively.

Our context analysis technique helps the analyst to refinethe high level descriptions of contexts in an iterative and sys-tematic way to ultimately reach observable facts. In order todecide the observability of a world predicate, i.e., to decidewhether it is a statement or a fact, the analyst looks first fora set of data the system can collect and judge upon the truthvalue of that world predicate. If such a set exists, then theworld predicate is a fact. When reaching a fact, the analysthas also to depict explicitly those data required to verify it.For example, and taking the context analysis shown in Fig. 2,the truth values of the leaf facts can be determined based onthe data conceptually modelled in Fig. 3. Each fact, however,concerns a fragment of the model and the figure shows theaggregation of those fragments in one model.

3 Requirements-Driven Deployment Framework

In this section, we discuss the customization of requirements,expressed via contextual goal models, to fit a system deploy-ment environment. Such environment could exhibit certaincharacteristics that originate shortcomings, redundancies anduselessness in parts of the requirements model. Modifying therequirements model to fit its environment is an essential stepfor a holistic software deployment. While requirements cus-tomization could also consider decisions about different as-pects, such as users preferences, costs, qualities, and organi-zational rules, we are here interested in modifying the modelto suit the contextual variability profile of a deployment en-vironment. For this reason, we propose to first sample the en-vironment where the system is to be deployed (Section 3.1).Then, the collected samples are analyzed for two purposes: (i)to locate loci in the contextual goal model where augmenta-tion with extra alternatives is required (Section 3.2) and (ii) tominimize development costs by removing alternatives whichare inapplicable or redundant (Section 3.3).

3.1 Sampling a deployment environment

The context variations in a system environment can influenceusers requirements. Certain variations may activate certain re-quirements, or be required to adopt a specific alternative setof functionalities to satisfy the active requirements. Forex-ample, if a customer seems interested in a product (context)then a product promotion has to be established (requirement).Establishing the promotion can be done via different alterna-tives, such as giving a free sample, cross-selling, or discount-ing. The adoptability of each of these alternatives requires acertain context to hold. For example, promoting by giving a

sample requires a context like “the product is new to the tar-get customer“ to hold.

Sampling a deployment environment means monitoringwhat context variations, which influence the systems require-ments, occur in that environment. The sampling process mon-itors the contexts that activate requirements. If one of thesecontexts holds, then the process also monitors the contextsrequired to adopt each of the alternatives that the model sup-ports for fulfilling the activated requirement. The values ofthe monitored contexts will be stored as asample. Samplingthe system environment is an iterative activity which shouldbe performed during a period of time at the deployment phase.

Contextual goal models can provide guidance and ratio-nale for the environment sampling process as they explicitlycapture the influence of context variations on requirementsat the goal level. Our models represent the influence of con-text on goal activation, as well as on possible alternativesandtheir qualities. Accordingly, we have specialized contextintothree types, each associated with a different set of variationpoints in a contextual goal model:

1. Activation context makes it necessary to achieve (exe-cute) a set of goals (tasks). In our contextual goal model,activation contexts reside at the variation points (i)Rootgoals activationand (ii) AND-decomposition. An acti-vation context decides if a goal should be satisfied or atask should be executed. The activation context of a goalmodel alternative is the logical conjunction of the con-texts at the variation points of these two types (see Fig. 4).

2. Required contextis necessary to adopt a certain way forachieving (executing) a set of active goals (tasks). Re-quired contexts are those associated to the contextual vari-ation points (i)OR-decomposition, (ii) Means-end, and(iii) Actors dependency. These contexts are required tomake a specific alternative of the goal model applicable.The required context of a goal model alternative is thelogical conjunction of contexts at the variation points ofthese three types (see Fig. 4).

3. Quality context influences the quality of an alternativeof the goal model. Only the contexts at the variation pointContribution to softgoalsare quality contexts. Contribu-tions (links) to softgoals are, indeed, used in Tropos tocapture the impact of a goal/task to a quality measure(i.e., softgoal). In this paper, we do not address softgoalsand quality contexts. We only focus on the operability ofthe system and we leave the quality dimension for futurework.

Sampling the environment means monitoring the activa-tion contexts of a contextual goal model alternatives untilonecontext is true. Such event activates one or more alternativesin the goal model. whose required contexts are then moni-tored. At this point, we can face two situations:

– If there exists at least an alternative with a holding re-quired context, then the sample ispositiveand the systemhas a way to satisfy the activated set of goals/tasks.

Requirements-Driven Deployment 7

Fig. 2 Context analysis forC1

Fig. 3 The data needed to verify the facts of contextC1 shown in Fig. 2

– If there exists no such alternative, then there is no adopt-able way to satisfy the activated goals/tasks and, thus, thesample isnegative.

The sampling process stores the values of monitored con-texts as environment samples. The sampling process will mon-itor the environment at deployment time and collect a set ofenvironment samples to decide upon whether there is a needto augment the goal model with additional alternatives (Sec-tion. 3.2) and also if we need to clean it from redundant anduseless ones (Section. 3.3).

3.2 Augmenting contextual goal models

A contextual goal model can be deployed in multiple environ-ments. The space of alternatives that the goal model supports,each preconditioned by a specific context variation, could beinsufficient for meeting users’ goals in one environment forseveral reasons. The reason we address in this paper is the un-satisfiability of contexts that are required to adopt activatedgoal model alternatives. In other words, certain contexts ofthe deployment environment activate a set of goals and thereis no alternative with a valid required context. Thus, some re-quirements are activated but unsatisfiable. We propose a so-lution to this problem based on augmenting the goal modelalternatives space to enhance the operability of the systemwhen contextualized alternatives are missing.

8 Raian Ali et al.

promote product [p] tocustomer [c] inmall [m]

promote by giving freesample of product [p] to

customer [c]

deliver [p] sample to[c] by sales staff [ss]

guide [ss] to [c]place

and

sales staff [ss] delivers aproduct [p] sample to

customer [c]

notify [ss] byvibration

show [c] placeto [ss]

show [c]picture to [ss]

and

[ss] is notified[ss]meets [c]

Sales StaffIS

C4

C6

C11

C14

Customer IS

C1

V1: GoalModel Alternative

V1.Activation_Context= C1 C14V1.Required_Context= C4 C6 C11 C13V1.Context = C1 C14 C4 C6 C11 C13

C13

Fig. 4 An example of a goal model alternative and its accumulative contexts

We augment the goal model with default domain-independentsolutions that can be adopted when no adoptable contextual-ized alternatives exist. Default solutions are backup options,and are typically not as good as contextualized ones. They aremeant to allow operability of the system when it does not findan alternative that is expressly tailored to a current context.

Example 1Consider the contextual goal model of Fig. 1. WhenC1= “the customer is in the product area for more than 5 min-utes, he has not already got a promotion on it, and the pro-motion is potentially realizable” is true, the root goal “pro-mote product to customer in mall” is activated. If none of thecontextsC2= “the product can be used with another productthe customer already has”,C3= “the product is discountableand interesting to the customer”, andC4= “the product is freesampled and the customer does not have the product and doesnot know about it” holds, then none of the alternatives to ful-fil the activated root goal will be adoptable. Thus, we havean activated requirement and no alternative to fulfil it. Whensuch a situation occurs, a default solution could be executedby sending an SMS to the customer introducing the basic fea-tures of the product.

The algorithmDiscover Global Solutionsshown in Fig. 5takes as an input a contextual goal model and a set of envi-ronment samples obtained as described in Section 3.1. As anoutput, it returns the set of possible solutions (alternative aug-mentations sets) for each negative sample. To this end, the al-gorithm generates the set of goal model alternatives togetherwith their contexts (Line 1). For each environment sample(Line 2), the algorithm checks if the system can find a wayto satisfy the activated set of goals (Line 3). If so, the algo-rithm does not need to find any solution as the sample is pos-itive (Lines 3-4). Otherwise (Line 5), the algorithm invokesanother algorithmProcess Sample(reported in Fig. 6 and de-scribed later) to specify loci in the goal model where an aug-mentation could be needed (Line 6). Then, the algorithm tra-verses the resulting annotated goal model to organize the par-tial augmentations suggested by the invoked algorithmPro-cess Sampleas sets of global solutions and associates these

solutions with the processed sample (Line 7). The algorithmcleans the contextual goal model by deleting the annotatedaugmentations (Line 8), before processing the next sample.

Input: CGM : a contextual goal modelSamples: Array [1..n] of environment samples

Output: Solutions: Array [1..n] of set of possible solutions

1: V := Generate Alternatives Set(CGM)2: for i = 1 to n do3: if ∃v ∈ V,Holds(v.Activation C, Samples[i]) ∧

Holds(v.Required C, Samples[i]) then4: Solutions[i] := ∅5: else6: Process Sample(CGM.Root Goal, Samples[i], CGM)7: Solutions[i] := Construct Global Solutions(CGM)8: Delete Annotated Augmentations(CGM)9: end if10: end for

Fig. 5 Algorithm Discover Global Solutions

The algorithmProcess Sampleis shown in Fig. 6. The al-gorithm is invoked for negative samples and its purpose is toidentify loci where augmentations with default non-contextualalternatives are needed and to annotate the goal model ac-cordingly. The algorithm starts processing the root goal nodeand traverses the model recursively. For each subnode of thenode being processed (Line 1), the algorithm checks if an-other recursion is needed (Lines 2-4), i.e, if augmentationsin the hierarchy rooted by that subnode could be needed.This happens when the context preconditioning this subnodeis true in the processed negative sample (Line 2). If such acontext is false then any augmentations in that subnode hi-erarchy will not be even satisfiable and are therefore use-less. While traversing the model, the algorithm annotates apossible augmentation for each refinement of the typesOR-Decomposition, Means-end, Dependency(Lines 5-6). The rea-son is that these types of refinements introduce alternativesand, therefore, a non-contextualalternative may be added therewhen contextualized alternatives are not adoptable.

Example 2In Fig. 7, we show the results of processing thecontextual goal model of Fig. 1 with respect to a negative

Requirements-Driven Deployment 9

Input: N : a contextual goal model node (goal/task)s: an environment sampleCGM : contextual goal model

Output: CGM annotated by possible augmentations

1: for all {Ni : IsSubnode(Ni, N)} do2: if Holds(Ni.Context, s) then3: Process Sample(Ni, s, CGM)4: end if5: if N.Refinement Type ∈ {OR,Means−end, Dependency}

then6: Annotate Augmentation(CGM,N.Refinement)7: end if8: end for

Fig. 6 Algorithm Process Sample

environment sample. The activation context that holds hereis C1 ∧ C14. In this sample, there is no alternative to satisfythe activated set of goals and tasks. In other words, there isno alternative with a true required context supported in thecontextual goal model. AlgorithmDiscover Global Solutionswill find this sample negative and then invoke the algorithmProcess Samplethat will traverse the model looking for lociwhere augmentations could convert the sample to a positiveone. The algorithmProcess Samplereturns the goal modelannotated with the augmentationsA1 . . . A7. Algorithm Dis-cover Global Solutionstraverses the goal model and orga-nizes these partial augmentations as a set of global solutions{{A1, A2}, {A3, A4}, {A5}, {A6}, {A7}}. The implementa-tion of any of these sets will enable an alternative to fulfilgoals when the sample under discussion occurs.

The algorithmDiscover Global Solutionsproduces a setof possible solutions concerning each negative sample sep-arately. Each solution includes one or more augmentationsto the goal model (e.g.,{A1, A2} is a solution that includes2 augmentations as shown in Fig. 7). However, a suggestedaugmentation is could not be implementable. Therefore, theanalyst has to specify for each augmentation whether it is re-alizable and refine the model specifying how this can be done.This specification will decide which samples are convertibleto positives and support the final decision about which aug-mentations to implement. The decision may rely upon, e.g.,a cost-benefit analysis concerning the feasibility of the aug-mentations. We leave this topic for future work.

Example 3Taking the augmentations suggested in Example2 and illustrated in Fig. 7, the analyst could findA4, A5, A6,andA7 unrealizable by contrast toA1, A2, andA3. The an-alyst has then to specify each realizable augmentation. Theanalyst may specify thatA1 can be realized via task“informvia text message & get confirmation by OK button”, A2 via“leaving a voice mail”, andA3 via “sending SMS”. All ofthese augmentations are less effective than the contextualizedones. For example, by“inform via text & get confirmationby OK button”, the system cannot interact with the customerand provide expressive information that leads to better man-agement of the sample delivery process.

3.3 Reducing contextual goal models

The system environment may exhibit properties having staticnature which help to customize the requirements model at thedeployment stage. In one environment, some requirementsare never activated or applicable and other requirements havealways more than one alternative to satisfy. Contextual goalmodels may have unusable or redundant parts when the sys-tem operates in a specific environment. Thus, the deploymenthas to check a contextual goal model against its environmentto detect whether it contains such parts and derive a reducedversion of it that is expressly tailored to its deployment en-vironment. Reducing contextual goal models helps to reducethe functionalities the deployed software has to support. Con-sequently, it reduces the time of the deployment process andavoids the costs of implementing functionalities that are notgoing to be used. We propose a process to reduce contextualgoal models mainly by detecting and removing unusability(Section 3.3.1) and redundancy (Section 3.3.2).

3.3.1 Processing unusabilityThe contexts specified at a con-textual goal model may have static values in a certain envi-ronment. The environment samples may show that some ofthese contexts are always true or always false. Each case hasdifferent effect and requires a different reduction action.

The contexts having true truth values in all of the col-lected samples lead to useless monitoring functionalitiesand,thus, unjustified costs. Context monitoring requires collect-ing environment data which requires deploying equipments(databases, sensors, positioning systems, cameras, etc.)andprocessing collected data. If a context is always true, we donot need to deploy its monitoring functionalities. To detectand remove this type of contexts, we need to traverse the goalmodel and check whether each context (specified at each vari-ation point) is always true in all the environment samples.

Example 4If the shopping mall, where the system is to be de-ployed, consists of one floor, has plenty of sample distributionmachines and it is for products usable by young people whoare usually familiar with new technology, thenC9= “there isa sample machine close to and in the same floor as the cus-tomer and he is familiar with digital maps technology”wouldbe always true and there is no need to monitor it. Such con-text has to be removed from the goal model deployed in thatspecific mall. Removing this context avoids installing a posi-tioning system, preparing a map for the mall, and developinga database to store customer profiles (presuming that othersystem functionalities do not require that).

On the other hand, the contexts having false truth valuesin all collected samples lead to unjustified monitoring func-tionalities. Moreover, the existence of such contexts meansthat some goal model alternatives are never applicable. Boththe contexts specified at the variation points and the accu-mulative contexts of goal model alternatives could have falsevalues. As we mentioned earlier, the context of a goal modelalternative is the conjunction of two accumulative contexts:

10 Raian Ali et al.

by offeringdiscount on [p] to

[c]

promote product [p] tocustomer [c] inmall [m]

promote by giving freesample of product [p] to

customer [c]

by cross-selling[p] to [c]

deliver [p] sample to[c] by sales staff [ss][c] gets [p] sample of

machine [mc]

[c] arrives to [mc]

or

show [p] demoto persuade [c]

show [p] placeto [c]

make& show[p] discount to

[c]

make& give [p]discount code to

[c]

discount [p] to [c]

and

or

[c] allowed to get [p]sample from[mc]

and

[c] knows about [p]& confirm thesample offer

interact via voicedialogue& voicerecognition

interact via visualdialogue& click-based interaction

generate& giveauthentication code

on [p] to [c]

Interactivewizardto guide [c] to [mc]showpath to

[mc] on [m]map

persuade and inform[c] about [p]

and

less disturbance

C1

C2

C4

C7

C5

C9

C10C8

C3

Customer IS

C15 -- +

guide [ss] to [c]place

and

sales staff [ss] delivers aproduct [p] sample to

customer [c]

notify [ss]by vibration

notify [ss] byvoice

command

show [c] placeto [ss]

show [c]picture to [ss]

and

[ss] is notified [ss]meets [c]

Sales StaffIS

C6

C11

C12

C14

FALSE

C13

Sample[i].TrueContexts:= {C1, C4, C5, C6, C14}

Sample[i].FalseContexts:={C2, C3, C7, C8, C9, C10, C11, C12, C13}

The partial augmentations proposed by the algorithmProcess_Sample= {A1, A2, A3, A4, A5, A6, A7}

The augmentations organized as global solutions in Solutions[i]={{A1,A2}, {A3, A4}, {A5}, {A6}, {A7}}

TRUEA7

A6

A5

A1

A2

A3 A4

FALSETRUE

TRUE

TRUE

FALSE FALSE

FALSE

FALSE

FALSE

FALSE

FALSE

TRUE

Fig. 7 An example of augmentations found by sample processing, andalternative solutions resulted by organizing augmentations

the activation context and the required context of that alter-native (see Fig. 4). The alternatives including contexts (indi-vidual or accumulative) that are false in all the environmentsamples should be removed from the model. This is to avoiddeploying functionalities meant to support inapplicable goalmodel alternatives. By removing these alternatives, we po-tentially reduce the costs of monitoring the contexts includedin them. However, the removal of one alternative does notmean that the goals, tasks, and contexts included in it will beremoved definitely from the final model, as they might alsoappear in other applicable alternatives.

The algorithm reported in Fig. 8 processes a contextualgoal model against a set of environment samples and reducesit by removing alternatives with always-false contexts. Thealgorithm generates all the contextual goal model alternativestogether with their contexts (Line 1). An alternative is adopt-able with regards to one environment sample if both its ac-tivation and required contexts hold in that sample. The algo-rithm then checks all the contextual goal model alternatives(Line 3–7). If an alternative is adoptable in at least one ofthe environment samples (Line 4) then it is added to the setof the adoptable alternativesV ′ (Line 5). Finally, the algo-rithm gives as an output the set of adoptable alternatives asareduced version of the contextual goal model (Line 8).

Example 5In a noisy shopping mall, the contextC7= “thecustomer’s place is not noisy, and the system is trained enoughon the customer voice”will never hold and any alternativepreconditioned by a context includesC7 will be inapplica-ble. Such alternative should be removed from the final setof adoptable alternatives. Excluding alternatives means ex-cluding some functionalities (tasks) from the deployed sys-

Input: CGM : a contextual goal modelS: a set of environment samples

Output: CGM ′: CGM cleaned from useless alternatives

1: V := Generate Alternatives Set(CGM)2: V ′ := ∅3: for all v ∈ V do4: if ∃s ∈ S,Holds(v.Context, s) then5: V ′ := V ′ ∪ {v}6: end if7: end for8: CGM ′ :=

⋃{v ∈ V ′}

Fig. 8 Algorithm Process Unusability

tem. The task“voice dialogue and voice recognition”canbe excluded from the requirements model, as it will neverbe adoptable. The exclusion of alternatives leads also to ex-cluding contexts to minimize monitoring costs. RemovingC7

avoids us the costs of sensing and analyzing the noise level inthe location of customer and tracking the system learning ofthe user voice.

3.3.2 Processing redundancySome functionalities might beredundant when the system operates in a certain environment.An early and main source for redundancy is the requirementsmodel. The environment may make some requirements re-dundant and therefore the functionalities that are deployedto satisfy these requirements will be redundant as well. Ac-commodating a large space of functional alternatives, eventhough redundant, could be desirable for reasons such as sup-porting high flexibility, different users’ preferences, and faulttolerance. However, for reasons such as costs and time con-straints, detecting the functionalities that allow the system tofulfil its requirements without redundancy is often needed.

Requirements-Driven Deployment 11

Contextual goal models represent explicitly the relationbetween two spaces: the space of requirements alternativesand the space of context variations. Analysing contextual goalmodels to discover which requirements alternatives are re-dundant leads to a model that incorporates the minimum butsufficient space of alternatives. We consider an alternative ofthe goal modelv redundant if there is another alternativev′

that is applicable wheneverv is applicable. In other words,we deal with redundancy originated by the replaceability ofsome alternatives. As we mentioned earlier, supporting re-dundant alternatives in the deployed system could be justifiedto develop high-variability systems. We leave the selectionbetween redundant alternatives for future work.

The processing of a contextual goal model to remove re-dundant alternatives and group the rest based on applicabilityequivalence is reported in Fig. 9. The algorithm takes as inputa contextual goal model and a set of environmental samplesand returns the redundant and equivalent groups of alterna-tives. First, the algorithm generates the set of goal model al-ternatives together with their contexts (Line 1) and initializesthe setEquivalent Gv to an empty set. This set will be usedlater to represent the sets of equivalent alternatives (Line 2).The algorithm then organizes the adoptable goal model al-ternatives in groups based on equivalence of applicabilityinthe environment samples (Line 3–11). To this end, the algo-rithm picks randomly an alternativev (Line 4) and finds thegroup of alternativesGr.alternatives that are applicable ex-actly whenv is applicable (Line 5). The samples set in whichthese alternatives are applicable is also recorded (Line 6). Thegroup of equivalent alternatives is eliminated from the setofall alternatives (Line 7) and considered for further process-ing if there exists at least one sample in whichv (and there-fore the other alternatives in the group) holds1. If a group ofequivalent alternatives is replaceable by another, i.e., if in allsamples where the first is applicable so the second is, thenthe first group is marked replaceable and removed from theoutput (Line 11 – 12).

Input: CGM : contextual goal modelS: a set of environment samples

Output: CGM ′: CGM without redundancy

1: V := Generate Alternatives Set(CGM)2: Equivalent Gv := ∅3: while V <> ∅ do4: v := Pick alternative(V )5: Gr.alternatives := {v′ ∈ V,∀s ∈ S,Holds(v.context, s) ↔

Holds(v′.context, s)}6: Gr.samples := {s ∈ S,Holds(v.context, s)}7: V := V \ Gr.alternatives8: if Gr.samples <> ∅ then9: Add element(Gr.alternatives, Equivalent Gv)10: end if11: end while12: Replaceable Gv := {G ∈ Equivalent Gv, ∃ G′ ∈

Equivalent Gv and G.samples ⊂ G′.samples}13: CGM ′ :=

⋃{v ∈ (Equivalent Gv \ Replaceable Gv)}

Fig. 9 Algorithm Process Redundancy

1 This check is unneeded if unusability is already processed

Example 6Fig. 10 shows an example of a replaceable alter-native. In this example, we suppose that the assistance staffmembers have to put the headphone on when they are avail-able for serving customers. If such a policy holds in the shop-ping mall where the system is to be deployed, then the impli-cationC11 → C12, whereC11 = “the sales staff PDA vibra-tion is activated and he is holding his PDA and not using itfor a call” andC12 = “the sales staff is putting his headphoneon and is not using his PDA for a call”, holds in all of the en-vironment samples collected from that mall. This means thatV2 is applicable in all samples whereV1 is applicable. There-fore, V1 can be considered replaceable and can be removedfrom the model. Consequently, the task“notify sales staff byvibration” will not be deployed and the contextC11 can bealso removed from the set of contexts to monitor.

guide [ss] to[c] place

and

sales staff [ss]delivers a product[p] sample tocustomer [c]

notify [ss] byvibration

show [c]place to[ss]

show [c]picture to

[ss]

and

[ss] is notified [ss]meets [c]

SalesStaff IS

C11

C14

C13

promote the product[p] to customer [c] in

mall [m]

promote by giving freesample of product [p] to

customer [c]

deliver [p] sampleto [c] by sales staff

[ss]

C4

C6

CustomerIS

C1

GoalModel Alternative V1

GoalModel Alternative V2

guide [ss] to[c] place

and

sales staff [ss]delivers a product[p] sample tocustomer [c]

show [c]place to[ss]

show [c]picture to

[ss]

and

[ss] is notified [ss]meets [c]

SalesStaff IS

C14

C13

promote the product[p] to customer [c] in

mall [m]

promote by giving freesample of product [p] to

customer [c]

deliver [p] sampleto [c] by sales staff

[ss]

C4

C6

CustomerIS

C1

notify [ss] byvoice command

C12

Fig. 10 V1 is replaceable byV2 in a mall whereC11 → C12 in allsamples

3.4 CASE tool: RE-context

We have developed a prototype automated tool (called RE-Context) to support the customization of a contextual goalmodel for a host environment. In our previous work [18,19],we have developed earlier versions of this tool for different

12 Raian Ali et al.

kinds of analysis concerning the generation and processingof a contextual goal model alternatives and the verificationof consistency and freedom of conflicts in a contextual goalmodels. In this paper, we implement a new component tosupport the activities of deploying a contextual goal modelin a host environment: augmentation, unusability, and redun-dancy processing. The architecture of RE-Context is shownin Fig. 11 where we highlight the “deployment” componentwhich is the one implementing the analysis proposed in thispaper.

Fig. 11 The architecture of RE-Context CASE tool

As shown in Fig. 11, RE-Context is composed of threelogical components. These components are developed in Javaand are linked to external reasoners via wrappers. The de-ployment component is the component specifically developedfor this paper. The derivation of the space of alternatives for acontextual goal model is a basic step for all types of analysisof RE-Context. RE-Context can derive alternatives includedin a contextual goal model by running the DLV reasoner asa planner. RE-Context outputs all the valid models that sat-isfy the Datalog inference rules in the input file encoding thecontextual goal model. Each alternative consists of a set oftasks to execute and a set of contexts associated with it. Formore details about the generation of alternatives please seeour work in [18]. In the following, we describe the main com-ponents of RE-Context:

– Derivation. RE-Context generates the space of alterna-tives included in a contextual goal model. Re-Context en-ables the choosing between alternatives in two styles. Thefirst is a runtime derivation of the alternatives matching agiven context and user’s preferences expressed as rank-ing over softgoals. The second concerns the derivation ofa set of tasks with minimal development costs which, ifimplemented, allows the system to cover and operate inthe space of context variations captured in a contextualgoal model. To this end, the analyst has to specify the re-sources needed for the development of each task in a goal

model and their costs. Please see our work [18] for moredetails about this component.

– Verification. RE-Context generates the space of contex-tual goal model alternatives and checks context satisfia-bility for each alternative. This checking is done by re-lying on the state-of-the-art SMT solver MathSAT2. Thealternatives with unsatisfiable contexts are excluded fromthe model since they are inapplicable. Furthermore, thetool checks the generated alternatives to detect those in-cluding tasks executing in parallel and leading to con-flicts. RE-Context expects the analyst to specify the effectof each task on the environment, the parallel and sequenceoperators on a goal model [21], and the logical relationsbetween contexts. More details on this component can befound in [19].

– Deployment. This component implements the analysiswe have proposed in this paper. It takes as input the DLVinput file which encode the contextual goal model, and theCSV file encoding the samples collected from a host envi-ronment. Both files are provided by the analyst. The DLVshould encode an already verified contextual goal model(using the verification component) to avoid having unnec-essary processing and incorrect results. For example, ifwe check redundancy before verification, the tool mightreturn that an alternativea1 is redundant given that thereis always an alternativea2 which is applicable whenevera1 is applicable. However, the verification might showthata2 has a conflict and, therefore, we cannot considera1 redundant, sincea2 is not functionally correct and can-not replacea1. The process shown in Fig. 12 and dis-cussed in Section 4 explains the way of using the au-tomated analyses. The deployment component performsthree types of analysis which are all implemented in Java:

– Unusability. This analysis implements the algorithmdescribed in Fig. 8, where the samples file is scannedto identify contexts which are always true or alwaysfalse. Based on that, the analysis reduces the set ofcontextual goal model alternatives (as described inSection 3.3.1), excluding the alternatives which areinapplicable and replacing the contexts which werealways true or false with their static value.

– Redundancy. This analysis discards redundant alter-natives, i.e., those operating in an environment whereother alternatives can operate and achieve the samegoals. The analysis enacts the algorithm reported inFig. 9 to identify and remove redundant alternatives.This analysis becomes unnecessary if the designer de-cides to keep redundant alternatives for reasons suchas flexibility and accommodating the preferences ofdifferent users.

– Augmentation. The purpose of this analysis is to findloci in a contextual goal model where an augmenta-tion with a default non-contextual alternative is nec-essary to deal with negative samples. This processingenacts the algorithm reported in Fig. 5. It returns a set

2 http://mathsat4.disi.unitn.it

Requirements-Driven Deployment 13

of possible global solutions after processing individ-ual alternatives. We still did not provide automatedanalysis to qualify and evaluate solutions. The deci-sion about this is still left for the analyst and we planto provide automated support for that in our futurework.

4 Systematic Process

In this section, we provide guidance for modelling contex-tual requirements by means of contextual goal models andcustomizing it to a certain host environment. The processis depicted in the activity diagram of Fig. 12. A number ofmacro-activities are identified: goal analysis, context analy-sis, verification, environment sampling, augmenting alterna-tives space, processing unusability, processing redundancy,and composing the final contextual goal model.

1. Goal analysis. Actors and high level goals are identi-fied and analysed. Actors and goals can be iteratively dis-covered through the set of scenarios which describe theproblem domain [22]. Moreover, an intentional variabil-ity taxonomy [23] can guide variability acquisition whenrefining a goal/task to discover alternative ways of ful-filling/executing it. Each refinement step is followed by acontext analysis.

2. Context analysis. This activity is meant to link betweenthe requirements and the context in which they are acti-vated and adoptable. The context analysis activity is com-posed of two steps:

(a) Contextual variation points identification. Each varia-tion point in a goal model can be contextual. Contextmay affect either goal activation or the selection ofalternatives to meet a goal. When a variation point isidentified to be contextual, a high level description ofthe correspondent context has to be written down. Asa result of this activity, the contextual variation pointsat the goal model should be annotated similarly to themodel we have shown in Fig. 1. Moreover, the con-texts associated with these variation points should bedescribed similarly to the descriptions shown in Ta-ble 2.

(b) Context refinement. The contexts at each contextualvariation point should be analysed. The analysis goalis to identify ways through which the system can ver-ify if a context holds. In other words, the context re-finement has to define the environmentalfactsthe sys-tem has to capture and the way these facts are com-posed to judge if an analysed context holds. An exam-ple of context refinement is shown in Fig. 2.

3. Verification . The requirements model has to be verifiedto ensure freedom of modelling errors which lead to in-consistencies in the context specification and conflicts be-tween the executable tasks of a goal model. RE-Contextsupports this automated reasoning in our work describedin [19]. Some alternatives of the goal model may be pre-

conditioned by a set of contexts which never hold to-gether. This make the alternative inapplicable and use-less if implemented. Moreover, the tasks of a goal modelcould lead to contradicting changes on the system envi-ronment. This leads to conflicted actions that prevent acorrect satisfaction of requirements. The verification ofcontextual goal models should be done as a preliminarystep for the analysis that concerns the deployment.

4. Environment sampling. The deployment environment hasto be explored through sampling. The samples are usedto process the requirements model and ensure fitness be-tween the model and the system environment. To do thesampling, the contexts specified at the contextual goalmodel need to be monitored iteratively for a period oftime and their values should be recorded as samples. Morespecifically, the contexts that activate goal model alterna-tives should be monitored until one of them holds. Whenthis happens, the sampling process records the values ofthe contexts specified at all of the variation points of theactivated goal model alternatives. This will allow for fur-ther analysis to judge if the model supports or lacks waysto satisfy its activated requirements. Monitoring the envi-ronment could be established by different techniques suchas surveying prospective users, being physically there andrecording context variations, recording via cameras andanalysing observations, etc. The sampling period has tobe long enough in order to capture contexts variations thathappen less frequently or periodically. However, the ana-lyst would need to compromise between the coverage andquality of the sample set and the sampling period as wediscuss in Section 5.2.

5. Augmenting alternatives space. In this activity, the con-textual goal model has to be analysed using the collectedenvironment samples to identify places where default non-contextual solutions are needed. To this end, RE-Contextcan be used to analyse the model with regards to eachsample and record the results. Doing that, the tool willask the analyst about the realizability of each suggestedaugmentation. The analyst can also assign costs to eachaugmentation and then use the tool to answer queries likecalculating the minimum-cost solution that converts thelargest number of negative samples to positive. The toolwill record the augmentations approved by the analyst tobe added later to the final goal model. These default so-lutions may be recorded to be suggested when deploy-ing the contextual goal model to other environments thatshares similar contextual profile.

6. Processing unusability. The goal of this activity is to re-move unusable functionalities from the model. This ac-tivity is fully automated and executable in our automatedRE-Context tool. The tool will scan the environment sam-ples to elicit the set of contexts specified at the variationpoints of the goal model and having always-true valuesin all the samples. It will also check the accumulativecontext of each goal model alternative to see if it holdsin at least one sample. After doing these two checks, thetool will remove the always-true contexts from the model

14 Raian Ali et al.

Fig. 12 The deployment process

since deploying the functionalities to monitor them is un-justified. Moreover, the tool will remove the goal modelalternatives having always-false contexts to avoid deploy-ing unusable functionalities. As we mentioned earlier, theremoval of one alternative does not necessarily mean thatall the goals, tasks and contexts included in it are remov-able as, indeed, they may appear in other alternatives thatare applicable.

7. Processing redundancy. The purpose of this activity isto discover the set of goal model alternative which are re-placeable when operating in a certain host environment.To this end, RE-Context can be used to group the alter-natives based on the equivalence of their applicability inall the environment samples. Obviously, the group of al-ternatives that are inapplicable in any of the deploymentenvironment samples are not further processed as we de-scribed in the last activity (processing unusability). Thetool will remove any group of alternatives for which thereis another group applicable in all the samples the firstone is applicable in. Such group will be redundant andinessential for the availability of the system. The analystscan then use the tool to select an alternative of each of theremaining groups according to a certain selection criteria.The criteria that is currently supported by RE-Context isthe costs of resources needed for each task of the goalmodel. The tool is able to select a set of tasks of the goalmodel able to implement at least one alternative of the ir-replaceable groups of variants with a minimum total cos.The selection algorithm is explained in our previous workin [18].

8. Composing final contextual goal model. In this activ-ity, RE-Context can be used to merge the augmentationssuggested by the activity of augmenting the alternativesspace with the goal model alternatives that are usable andnot redundant, i.e., the alternatives delivered by the ac-tivities of processing unusability and processing redun-dancy. This goal model will be the final outcome of ourdeployment process. It is a version of the original con-textual goal model tailored to context variations happen-ing in the system operational environment. This versionremoves the useless and redundant parts of the originalmodel and adds default alternatives to be adopted whena contextual alternative one is missing. Thus, it leads toa version of software with maximized operability and re-duced development costs with regards to a certain deploy-ment environment. The tool delivers the final goal modelas a DLV code. We need to extend our tool to draw a vi-sual notation based on such code.

5 Evaluation

To evaluate our proposed approach, we have developed a con-textual goal model for a room booking system used by aca-demic research groups. The purpose of the system is to assistresearchers in the room booking process. Room booking canbe performed for different purposes: giving seminars, hold-ing brainstorming sessions, making conference calls, or hav-ing a project meeting. Different rooms are available and dif-fer in their equipment, availability status and times, etc.Thethree main requirements of the room booking system are to

Requirements-Driven Deployment 15

assist researchers in booking a room, to announce the meet-ing/event, and to assist researchers to get and use of supple-mentary equipments needed to establish the meeting/event.To collect the environment samples, we monitored the roombooking processes for a period of time of two research groups(RG1 andRG2) at the Department of Information Engineer-ing and Computer Science (DISI)3 at the University of Trento.Then we have used the samples to customize the contextualgoal model as we will explain later. Here we give more de-tails about the three main requirements of the room bookingsystem and for more details, please see:http://disi.unitn.it/∼ali/index files/RoomBooking.pdf:

– Booking a room. This activity can be in charge of the de-partment secretary or the research group secretary whenthe later is available and assigned to the task of roomsbooking. The secretary has to be informed by the systemand, then, she has to check if there is a room availableand reply to the staff who requested to book a room. Thecommunication with secretaries follows different alterna-tives in different contexts. Booking a room can be doneby the staff who requested a booking himself if he has thepermission to use the room booking calendar (we used afree calendar web service).

– Announcing a seminar. The meeting requester needs as-sistance to announce the meeting/event either to public orspecific set of people. Public announcements can be donevia the website of the research group of the requester, thewebsite of the department, or the reception screens visibleto people who enters the department. Private announce-ments can be done via designated mailing lists (all mem-bers of the research group) or via chosen contacts fromthe contact book of the research group.

– Assistance about supplementary equipment. The systemhas to inform a room booking requester if there is a needto get supplementary equipment such as projector, con-nection cables, remote control, and keys before startingthe seminar. In case supplementary equipment is needed,the system has to provide the requester with informationon how to get and use that equipment. For example, therequester has to be assisted on how to get the projectorand use it, the place to get the keys from and the proce-dure to follow in order to do that, etc.

Our monitoring process lasted for 3 months and the sam-ples set consists of 61 booking processes: 34 reservationswere made byRG1, and 27 byRG2. To collect samples, weasked research groups members and department personnel in-volved in the booking process to fill in a form for the contextsvalues regarding each room booking process. Thus, and sincewe have not implemented an automated system for the mon-itoring of context, we did not do the context refinement asthe main purpose of such analysis is to specify contexts asformulae of facts monitorable by an automated system. Theform included questions to determine the truth values of theactivation and required contexts in our developed contextual

3 http://disi.unitn.it/

goal model for rooms booking. Group members were askedto specify the truth values of the dynamic contexts, i.e., whosewhich vary from one reservation to another. Some other con-texts were static and their values were known by us in ad-vance (e.g., the profile of each research group, the rooms eachgroup is granted access to, and installed equipments). Afterthe samples collection phase, we used our automated supporttool RE-Context to process the collected samples accordingto the analysis proposed in Section 3 and obtained the resultsreported and discussed later in this section.

g2: Schedule aRoom

g5: Secretary todo it

g6:Autonomously

g9: Via the researchgroup secretary g10: Via the

departmentsecretary

or

g13: Researchgroup ssecretary is

informed

g14:Secretary

finds a roomg15: Secretary

Informs if room found

and

t1: Viamail

t4: Viaspecificinterface

t2: Urgentemail

t3:Normalemail

t5: Onetime

message t6: Repetitivereminder

oror t8: Via

specificinterface

t7: Viaregular

format email

or

and

g16: Room isrequested

g20:Request is

made

g21:Coordinator

approves

t9: Requester fillsin automated form

t10: Viamail

t11:Emailsent

t12:Responseanalyzed

and

C2

C3

C8C9

C4 C5 C6C7

C10 C11

and

...

...

...

...

C1 C16

Staff Comfort

RequesterComfort

--

+

--

+

...

and

Fig. 13 Part of the contextual goal model for room booking

We now provide details concerning the contextual goalmodel we have developed. Part of this model is shown inFig. 13. The main requirement of a researcher is to book aroom for a certain scheduled activity. The reservation can bedone by following various alternatives: the researcher candoit autonomously or can interact either with the research groupsecretary or with the department secretary. Each alternative isadoptable in a different set of contexts (e.g.,C3 states that thedepartment secretary can be involved only if he is in chargeof that specific group and if he is currently not occupied inhigher-priority tasks) and the system is supposed to supportand track the room booking accomplishment. For instance,the research group secretary can be notified either by send-ing an e-mail to him (taskt1) or via a specific web inter-face (taskt4), depending on the context. Another requirementfor the system is to support the announcement of both pub-lic meetings and close meetings. Such requirement has to besupported via different alternatives: announcing via the website of the department or the research group, circulating viamailing lists, displaying on electronic screens in the depart-ment, etc. Each alternative requires a specific context to hold.The last requirement of the room booking system is to re-mind meeting requesters about the supplementary equipmenthe would need such as projectors, web cams, network cables,

16 Raian Ali et al.

and also to explain to a meeting requester how to get neededequipments and to use them. The contextual goal model wedeveloped for the room booking system consisted of 5 actors,33 goals, 52 tasks, 6 softgoals, and 34 contextual variationpoints. The space of alternatives to fulfil the main goal “hav-ing a room booked” included 2808 alternatives.

5.1 Samples processing results

In Fig. 14, we summarize the results obtained by applying theanalysis described in Section 3 on the contextual goal modelfor the room booking system. In the remainder of this sectionwe explain these results.

– Samples positivity/negativity. Sampling the room book-ing process for the first research groupRG1 led to 26positive samples—where the top-level goals have beenachieved—out of 34 samples, while the sampling forRG2

led to 22 positive samples out of 27 samples. The mainreason for failure in booking a room inRG1 was thatrooms are asked for booking short time before the eventand this led to failure in completing the booking processon time. For example, the room requester did not havetime to answer the emails concerning the supplementaryequipments needed or to confirm the reservation after be-ing made by the secretary. The main reason for failuresin RG2 was that the group did not have a secretary thatassists in booking rooms. This group had to rely on thedepartment secretary who often had other higher prioritytasks to do.

– Unusability processing. This activity detects and removesstatic contexts that never vary and, also, inapplicable goalmodel alternatives. The developed system does not needto monitor static contexts (those having the same truthvalue in all collected samples). For example, the roomsassigned toRG2 had all supplementary equipments andthere was no need to monitor that. ForRG1, 3 contextshad false values in all the collected samples and 3 hadtrue values. ForRG2, 3 contexts had false values while2 contexts had true values in all the collected samples.The contexts that are always false in all the samples pro-duced a large number of unadoptable alternatives (1512for RG1 and 2592 forRG2). Consequently, the tasks thatappear only in unadoptable alternatives are never exe-cuted (6 tasks forRG1 and 20 tasks forRG2). Also, itis useless to monitor the non-static contexts which appearin only unadoptable alternatives (3 contexts forRG1 and12 contexts forRG2). For example, having a set of well-equipped rooms forRG2 means the removal of all thegoal model alternatives where researchers are remindedto bring supplementary equipments. This, in turn, led tounadoptability of the tasks and uselessness of monitoringthe contexts needed to accomplish the assistance of theresearcher to bring such equipments.

– Redundancy processing. A goal model alternativeV isredundant if in every sample whereV is applicable thereexists another alternativeV ′ which is applicable as well.

As explained in Section 3, to discover redundant alter-natives, we first remove inapplicable alternatives whichhave always-false contexts in all samples, i.e., unusablealternatives. Then, we partition the rest into groups on thebasis of context value equivalence in all the samples, i.e.,on the basis of applicability equivalence. The number ofequivalent groups was 864 forRG1 and 144 forRG2.A group is redundant if its set of positive samples is in-cluded in the set of positive samples of another group.We got 792 redundant groups forRG1 (containing 1152alternatives) and 126 groups forRG2 (containing 180 al-ternatives). The importance of this computation was thediscovery of tasks that appear only in redundant alterna-tives (18 forRG1 and 5 forRG2). These tasks are re-dundant and, therefore, their deployment is optional. Forexample, our requirements model has two alternatives tonotify a meeting requester: notification via email to beadopted when the person is often in office or has access toInternet, and notification via mobile phone (such as voicemail or SMS) that is adoptable when the staff is out ofthe department and has no access to Internet. In both re-search groups, researchers had always access to Interneteven when researchers were out of the department. Thus,the option of communication via mobile phone becomesredundant and the system can exclude the deployment oftasks needed to establish it.

– Augmentation processing. Augmenting the requirementsmodel with default non-contextual alternatives is the so-lution we proposed when the model lacks applicable con-textual alternatives to meet goals, i.e., to convert negativesamples to positive. However, it is not always possibleto find a realizable default augmentation. For example,some of the collected samples ofRG2 were negative dueto the fact that the group secretary and the departmentsecretary were busy or having a day off. Finding a defaultnon-contextual human-supported alternative was not pos-sible and the sample could not be converted to positive.RE-Context performed the analysis we explained in Sec-tion 3, which locates a set of augmentations to the goalmodel and organizes these individual augmentations asalternative solutions in the form of sum-of-products for-mula. Then, analysts need to specify which augmenta-tions are realizable. On the basis of this specification, anumber of solutions will be marked realizable and, con-sequently, some negative samples will be convertible topositive. The total number of augmentations proposed toconvert the negative samples to positive was 6 forRG1

and 4 forRG2. Out of these augmentations, the numberof realizable ones was 2 inRG1 and 2 inRG2. This en-abled us to convert 5 of the 8 negative samples inRG1

to positive (3 of 5 inRG2). For example, one sample ofRG1 was negative due to the fact that one overseas staffcould not speak a language in common with the techni-cian to understand the use of video-conferencing. Thedefault solution was to develop a demo in multiple lan-guages.

Requirements-Driven Deployment 17

Fig. 14 The results of analysing the room booking contextual goal model for two research groups

5.2 Discussion of the obtained results

The evaluation of our approach for customizing requirementsto a deployment environment showed promising results (asreported in Fig. 15). A considerable percentage of contexts(58.8% forRG1 and 61.8% forRG2) were shown removable.Removable contexts include those having static—either trueor false—value in all the collected samples, those removedbecause appearing only in useless alternatives, and those re-moved when redundant alternatives are dropped. Removingstatic contexts results in lower monitoring costs, as theirval-ues are known a priori. Moreover, a considerable percentageof tasks were shown removable (46.2% forRG1 and 48.1%for RG2). The tasks appearing only in alternatives that areuseless, i.e., their contexts are false in all of the collected sam-ples, should not be supported in the deployed system as they

are not executable. The tasks that appear only in alternativesthat are redundant are optional and thus can be removed to re-duce costs. Moreover, our analysis has shown also a consider-able quantity of negative samples where the contextual goalmodel does not include alternatives tailored to support cer-tain contexts in its deployment environment (23.5% inRG1

and 18.5% inRG2). The analysis also suggested places inthe requirements model where augmentations can convert thenegative samples to positive. Some augmentations were real-izable and this led to convert 62.5% ofRG1 and 60% ofRG2

negative samples to positive. Such transformation will maxi-mize operability of the system in its prospective environment.

Though our experiment included a considerable percent-age of removable contexts and tasks, the costs saving is notproportional to this percentage. The reason is the overlap be-tween the resources needed for remaining and removed con-

18 Raian Ali et al.

Factor Research Group 1 Research Group 2

Removable contexts 20/34 = 58.8 % 21/34 = 61.8 %

True in all samples 3/34 = 8.8 % 3/34 = 8.8 %

False in all samples 3/34 = 8.8 % 2/34 = 5.9 %

Appear only in useless alternatives 3/34 = 8.8 % 12/34 = 35.3 %

Appear only in redundant alternatives 11/34 = 32.4 % 4/34 = 11.8 %

Removable tasks 24/52 = 46.2 % 25/52 = 48.1 %

Appear only in useless alternatives 6/52 = 11.5 20/52 = 38.5 %

Appear only in redundant alternatives 18/52 = 34.6 5/52 = 9.6 %

Negative Samples 8/34 = 23.5 % 5/27 = 18.5%

Samples convertible to positive 5/8 = 62.5 % 3/5 = 60 %

Fig. 15 Comparing the analysis outcome to the original goal model and collected samples

texts and tasks. For example, both tasks “send the room de-tails to secretary via email” and “send room details to staffviamail” require gathering, storing, and updating the rooms data(they need the same monitoring effort). Thus, the removalof one of these tasks leads only to a partial saving of costs.To precisely compute costs saving, we consider the resourcesneeded for task execution and context monitoring, similarlyto what we proposed in [18]. The explicit specification ofthese resources allows for identifying overlaps between tasksand contexts and, hence, for accurate calculation of costs andsavings. This enables better decision making about keepingor removing redundant alternatives.

Our approach reveals shortcomings in a designed require-ments model and, consequently, in the system to-be for ac-commodating certain contextual variations in a deploymentenvironment. Our analysis proposes loci in the requirementsmodel where augmentation with other alternatives is desir-able to maximize system ability in a certain environment. Wehave discussed augmentation with default non-contextualizedalternatives that the system can support. However, this is justone possibility to solve the problem. In many cases, the dis-covery of these loci motivates changes in the organizationalenvironment. For example, we encountered samples wherethere was no technician speaking a language in common withan overseas researcher and explain to him about the use ofthe equipments in the seminar rooms. In this case, the de-ployed system can be augmented to support a default alterna-tive, such as showing a demo. However, the solution could bealso at the organizational level by guaranteeing the presenceof at least one technical staff who speaks English. Our analy-sis motivates also the organization where the system is to bedeployed to make changes that maximize the requirementssatisfaction likelihood.

5.3 Approach limitations and threats to validity

We discuss here the limitations of our approach and the threatsto internal and external validity of our evaluation on the roombooking case study. Table 3 summarizes the main threats tointernal and external validity.

Threats to internal validityTh1. Experiment time period influenceTh2. Limited number of samplesTh3. Sampling was not transparent to participantsThreats to external validityTh4. Other factors to support the analysts decisions are missingTh5. Sampling is not always possible for privacy and securityconcerns, law, monitoring costs, etc.Th6. Experiments performed only in one domain

Table 3 Threats to internal and external validity

The definition of the sample collection period is a sen-sitive decision to take. Indeed, the contextual variationsthatmay happen in one deployment environment could vary fromone period to another. This will influence the comprehensive-ness of the samples collected and, therefore, the analysis re-sults. This is an internal threat (Th1) to validity in our casestudy, as we have studied the room booking scenarios be-tween April and June, which is an active period in academia.Probably, collecting samples in the vacation months, such asAugust, would provide different results. However, for practi-cal reasons we need to find a compromise between keepingthe samples collection time short and the accuracy of the anal-ysis results. This leads to another internal threat (Th2), i.e.,the relatively limited number of samples that we used whichprobably does not cover all possible contextual variationsinthe deployment environment.

Moreover, the sampling process itself may need an auto-mated system which means the development of another sys-tem. For example, contextual information such as the locationchanges of a person may need positioning systems, whichcannot be collected through survey forms. Interviewing do-main experts and analysing user samples sets are possibleways to overcome these issues. We leave the developmentof these techniques for future work. In our case study, the in-volvement of users (researchers, secretary, technicians,etc.)in the sampling process is a threat to internal validity (Th3).The sampling was not transparent to the system users. Indeed,they had to fill in our designated forms and answer to our in-terviews when sampling the environment.

Requirements-Driven Deployment 19

Further analysis is needed to support the analyst’s deci-sions about the augmentations to support and the redundancyto remove. Our analysis outputs alternative augmentationstosupport default solutions when the model lacks contextual-ized alternatives, and leaves the choice between them to theanalyst. It also discovers the redundant alternatives and leavesthe choice of selecting which redundant alternatives to keepand remove to the analyst. These decisions are not alwayseasy as they could be subject to different non-functional fac-tors and quality measures such as maximizing fault tolerance,accommodating user preferences, reducing development timeand operating costs, and so on. This is a threat to external va-lidity (Th4). Future work includes providing better support tothe analyst in taking the right decisions. We aim to incorpo-rate softgoals in the decision about which augmentations toenact and what redundant elements to remove or keep.

Obtaining context information is not always straightfor-ward due to several reasons. People usually have privacy con-cerns that prevent the system from monitoring their behaviours,location, activity, and so on. Some laws may impose con-straints on monitoring contextual information without peo-ple’s clear consent. Compliance with law might be hard tojudge and might differ from one location to another. More-over, although obtaining more contextual information can max-imize certainty while taking a context-based decision, therecould be a trade-off between the certainty and the requiredcosts to establish this monitoring. In our case study, and be-cause we are members in the academic organization in whichthe experiment was done, we have not faced such obstacles:this is another threat to external validity (Th5). Our approachstill needs to deal with different issues related to monitoringcontext (privacy concerns, law, costs, ..) and we leave thisforfuture work. An additional threat to external validity (Th6) isthat we draw our conclusions with respect to a single domain(seminar rooms booking in academia). Perhaps, applying ourframework in other domains might reveal limitations in bothof our modelling foundations and deployment process.

6 Related Work

The research in context modelling, such as [24–27], is aboutfinding modelling constructs to represent software and usercontext as well as reasoning about context. There is, how-ever, a gap between the context model and software behaviourmodel, i.e., between context and its use. Our work reducessuch a gap at the requirements level and allows for answer-ing questions like: “how do we decide the relevant context?”,“why do we need context?” and “how does context influencesoftware and user behaviour adaptation?”. Moreover, andrather than representing context data directly and presuminga prior knowledge of them, we proposed context analysis toenable a systematic hierarchical refinement to analyse contextand reveal the facts and the data that define it.

Recently, several papers studied the relationship betweenrequirements and contextual variability. The comparison ofthis paper to our previous work can be found in Table 1.

Salifu et al. [28,29] investigate the use of problem descrip-tions to represent and analyse variability in context-awaresoftware. However, the nature of problem frames does nothelp for representing high-variability. Goal models, instead,incorporate a large space of alternatives in one compact hi-erarchy. Moreover, quality measures, softgoals in goal mod-els, are not a first-class requirement in problem frames and,thus, goal models offer the basis of representing the influenceof contexts on these measures and prioritizing requirementsalternatives accordingly [18,10,12]. Lapouchnian et al. [30]share with us similar vision of integrating context with in-tentional variability captured by goal models. We have inves-tigated more in this direction and defined a set of variationpoints where context affects goal models with clear semanticand a systematic way to analyse context. Such effort allowsus to develop a formal framework that natively supports au-tomated reasoning.

Cheng et al. [31] deal with environmental uncertainty us-ing KAOS goal models and conceptual domain models. Theircore contribution is to introduce tactics to mitigate uncer-tainty. However, unlike us, they do not rely on sampling andreflecting the actual contextual variability which character-izes a certain operational environment. Thus, their mitiga-tion strategies are based merely on the analyst’s expertiseandknowledge. Amyot et al. [32] model the impact of context onsoftgoals, using GRL models, in the context of service en-gineering. By not relying on collected contextual data fromthe operational environment where the system is to be de-ployed, their approach heavily relies upon a domain expertto perform the customization of the requirements model. Ourapproach, instead, is more systematic as it models and anal-yses explicitly the reasons and the method to follow when acustomization is to take place.

Software variability modelling—mainly feature models [33,34]—concerns modelling a variety of possible configurationsof the software functionalities to allow for a systematic wayof tailoring a product upon stakeholder choices. These ap-proaches do not bridge the gap between each functionalityand the context where this functionality can or has to be adopted,the problem we tried to solve at the goal level. Recently,several works recognized the role of context in the softwareproducts derivation [35–37]. Our work, though proposed inthe area of goal-oriented requirements engineering, can beadapted to complement contextual software product lines, pro-viding a clear semantic of the relation between contexts andfeatures, an automated contextualized derivation process, asystematic way to identify context itself, and a process to cus-tomize a product during the deployment. Furthermore, ourwork is in line, and has the potential to be integrated, withthe work in [38] and the FARE method proposed in [39],that show possible ways to integrate features with domaingoals and knowledge to help for eliciting and justifying fea-tures. Recent work [40] focuses on the selection of featuremodel configurations that take into account soft constraintsthat represent desired quality attributes. Unlike us, suchap-proach does not explicitly consider contextual factors, which

20 Raian Ali et al.

are fundamental to discriminate between possible and inap-plicable alternatives.

Requirements monitoring adds specific code to a runningsystem to gather information, mainly about the computationalperformance, and reason if the running system is always meet-ing its design objectives, and reconcile the system behaviourto them if a deviation occurs [8]. The objective is to havemore robust, maintainable, and self-evolving systems. In [41],the GORE (Goal-Oriented Requirements Engineering) frame-work KAOS [5] was integrated with an event-monitoring sys-tem (FLEA [42]) to provide an architecture that enables run-time automated reconciliation between system goals and sys-tem behaviour with respect to a priori known or evolvingchanges of the system environment. A similar effort alongthe same line is Wang’s requirements-driven diagnosis [43],which diagnoses software errors and their influence at the re-quirements level. Our work is also focused on monitoring.Unlike such approaches, however, we provide an explicit no-tion of context as a main driver to derive the requirementsto meet and the adoptable alternatives to meet them. The de-ployment process we proposed can be adapted for runtimeadaptation and reconciliation, as relying on correct models isfundamental to ensure runtime adaptation is in response tothreats to requirements and eventually leads to requirementssatisfaction.

Customizing goal models to fit to user skills and prefer-ences was studied in [10,12]. Such work can be used at de-ployment time where specific user skills and preference willrule out some alternatives and, thus, the deployed system willnot need to support them. We envisage that a joint usage withour approach would enrich the set of aspects the deploymentprocess can deal with. Liaskos et al. [23] study the variabil-ity modelling under the requirements engineering perspec-tive and propose a classification of the intentional variabil-ity when OR-decomposing a goal. We focused on contextualvariability, i.e., the unintentional variability, which influencesthe applicability and appropriateness of each goal model al-ternative. Reasoning with goal models has been studied in[44]. Adding context to goal models creates the need to inte-grate contextual reasoning and goal reasoning. Our previousand current work provides concrete answers to such need.

Pourshahid et al. [14] address a very important aspectconcerning the customization and the improvement of a sys-tem, which is the alignment between business goals and thebusiness process. It extends the User Requirements Notation(URN) [6,45] with Key Performance Indicators (KPIs) [46],whose monitoring guides the alignment between goals anda business process. KPIs concerns the actual operation ofthe overall system and how the system performs. Context,as proposed in our work, concerns the characteristics of theenvironment surrounding the system. Each setting of such en-vironment could activate certain requirements and make ad-potable/inadoptable some of the system’s alternatives to fulfilthe activated requirements. Pourshahid et al. [47] introduceaspectsas a mechanism to model the redesign patterns andchoose the best applicable patterns based on their impact ondifferent views of the system (process, goal, validation, and

performance). Such approach could be combined with oursto allow for a comprehensive customization and adaptationsince we would be able to monitor both the characteristics ofthe system environment and the operation of the system itselfin practice and decide what modification to do both at designtime and runtime.

The idea behind requirements testing is that testing has tostart with requirements, as code correctness is unachievablein case requirements are incorrect [48,49]. Our work is sup-portive to this argument especially when we design require-ments for adaptive systems where the requirements modelrepresents a high-level abstraction of the behavior of the pro-gram itself. Our work provides models and reasoning mech-anisms to test and customize a requirements model to its de-ployment environment. We also plan to develop requirements-driven runtime adaptation, in line with the vision of require-ments reflection [50], that maximizes this fitness continuouslyand allows the system to learn from its experience in its op-erational environment.

7 Conclusions and Future Work

In this paper, we have discussed deployment of requirementsmodels as an essential activity of software deployment. Ourargumentation is that requirements are not uniform and maydiffer from one environment to another. We provided a con-ceptual model, the contextual goal model, that explicitly cap-tures the relation between context variations and requirements.We showed how this model is customized to fit each par-ticular environment in which the system is to be deployed.Our process is based on exploring the system prospectiveenvironment and collecting samples reflecting the truth val-ues of the contexts specified in the requirements models andthen processing the model against the samples set. The pro-cessing aims to discover useless and redundant parts of themodel. This, in turn, reduces the costs of the deployed systemand avoids deploying unnecessary functionalities. Moreover,our proposed processing discovers loci in the model whereextra solutions are needed to handle contexts for which themodel lacks alternatives. This maximizes the operability ofthe system in its host environment. We developed a formalframework and an automated reasoning tool to support ourapproach. We also outlined a methodological process thatguides the use of our framework to gather and deploy require-ments.

We have presented a case study of deploying a require-ments model for room reservation in an academic researchenvironment. The case study included 2 research groups andtheir room reservations for meetings during 3 months. Weprocessed the requirements model that we developed for roombooking against the reported room reservations experience.The processing aimed at customizing the requirements modelto its deployment environments. Our processing showed asignificant amount of detected unusabilities and redundanciesin the model. This is important to save the costs of deploy-ing functionalities aimed to satisfy unnecessary requirements.

Requirements-Driven Deployment 21

On the other hand, we discovered several cases in which themodel lacks solutions for fulfilling the main requirements:having a room booked. Discovering these cases and augment-ing the model with additional alternatives will maximize thesystem ability to meet users requirements in the deploymentenvironment. The application of our framework in practice(Section 5) gave us insights on several challenges to addressin a future work:

– Certain characteristics of the environment represent con-straints on the system behaviour which are hard to cap-ture by our contextual goal model. For example, the secu-rity and privacy policies in an organization might havea strong impact on the applicability of certain alterna-tives and the ability and permission to monitor certaincontexts. By considering these organizational character-istics, we would be able to customize more holistically arequirements model.

– We assume that a high percentage of context variationshappens within a period of time that is decidable by theanalyst. However, this assumption may not be true sincesome context variations could be infrequent or periodic.Thus, the environment sampling period might need to belonger than desirable. Devising techniques to maximizethe comprehensiveness of the collected samples in repre-senting the deployment environment and at the same timereducing the sampling period is part of our future work.

– Our approach enables detection of unusability, redundan-cies, and shortcomings in the requirements model withrespect to its deployment environment. While the ana-lyst’s decisions about removing unusable parts of the re-quirements model are often easy to take, decisions aboutwhat redundancies to accept and what augmentations toimplement are often complex decisions. The reason forthis complexity is that multiple factors play a role in thatdecision such as increasing flexibility and fault toleranceand accommodating different users preferences and so on.Developing a multi-criteria decision making techniquesspecialized for this problem is another research problemwe aim to solve.

– Our approach deals with systems that are in the deploy-ment stage. However, the system runtime operation mightalso reveal lack of alternatives, redundancy, uselessness,static contexts and so on. Maximizing the system aware-ness of its own behaviour and reflection to its currentstatus autonomously or semi-autonomously is another re-search question to address in our future work. This dealswith more challenging problems related to modifying al-ready deployed and operating system at runtime to takebenefit from the history of operation as a continuous pro-cess.

Acknowledgements

This work has been partially funded by the EU Commis-sion, through the ANIKETOS and FastFix projects and byScience Foundation Ireland grant 10/CE/I1855 to Lero - the

Irish Software Engineering Research Centre (www.lero.ie).We also thank Vitor E. Silva Souza for discussions that en-riched the ideas of this paper.

References

1. Anthony Finkelstein and Andrea Savigni. A Framework for Re-quirements Engineering for Context-Aware Services. InProc.of the 1st International Workshop From Software Requirementsto Architectures (STRAW 01), 2001.

2. Eric Yu. Modelling Strategic Relationships for Process Reengi-neering.Ph.D. Thesis, University of Toronto, 1995.

3. Paolo Bresciani, Anna Perini, Paolo Giorgini, FaustoGiunchiglia, and John Mylopoulos. Tropos: An Agent-Oriented Software Development Methodology.AutonomousAgents and Multi-Agent Systems, 8(3):203–236, 2004.

4. Jaelson Castro, Manuel Kolp, and John Mylopoulos. Towardsrequirements-driven information systems engineering: The tro-pos project.Information Systems, 27(6):365–389, 2002.

5. Anne Dardenne, Axel van Lamsweerde, and Steve Fickas.Goal-directed Requirements Acquisition.Science of ComputerProgramming, 20(1-2):3–50, 1993.

6. International Telecommunication Union (ITU-T). User Re-quirements Notation (URN) - Language Definition. Recom-mendation Z.151 (11/08). Geneva, Switzerland, 2008.

7. John Mylopoulos, Lawrence Chung, and Eric Yu. From Object-oriented to Goal-oriented Requirements Analysis.Communica-tions of the ACM, 42(1):31–37, 1999.

8. Steve Fickas and Martin Feather. Requirements Monitoringin Dynamic Environments. InProc. of the 2nd IEEE Inter-national Symposium on Requirements Engineering, pages 140–147, 1995.

9. Daniel Sykes, William Heaven, Jeff Magee, and Jeff Kramer.From Goals to Components: a Combined Approach to Self-management. InProc. of the 2008 International Workshop onSoftware Engineering for Adaptive and Self-managing Systems,pages 1–8, 2008.

10. Bowen Hui, Sotirios Liaskos, and John Mylopoulos. Require-ments Analysis for Customizable Software: A Goals-skills-preferences Framework. InProc. of the 11th IEEE InternationalConference on Requirements Engineering (RE’03), pages 117–126, 2003.

11. Sotirios Liaskos, Sheila A. McIlraith, Shirin Sohrabi,and JohnMylopoulos. Representing and reasoning about preferencesinrequirements engineering.Requirements Engineering, 16:227–249, 2011. 10.1007/s00766-011-0129-9.

12. Sotirios Liaskos, Sheila McIlraith, and John Mylopoulos. Rep-resenting and Reasoning with Preference Requirements usingGoals. Technical report, Dept. of Computer Science, Universityof Toronto, 2006. ftp://ftp.cs.toronto.edu/pub/reports/csrg/542.

13. L. Baresi, L. Pasquale, and P. Spoletini. Fuzzy goals forrequirements-driven adaptation. InThe 18th IEEE InternationalRequirements Engineering Conference (RE), pages 125 –134,27 2010-oct. 1 2010.

14. Alireza Pourshahid, Daniel Amyot, Liam Peyton, SepidehGhanavati, Pengfei Chen, Michael Weiss, and Alan Forster.Business process management with the user requirements no-tation. Electronic Commerce Research, 9:269–316, 2009.10.1007/s10660-009-9039-z.

15. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. Location-based Variability for Mobile Information Systems. InProc.

22 Raian Ali et al.

of the 20th International Conference on Advanced InformationSystems Engineering (CAiSE’08), volume 5074 ofLNCS, pages575–578. Springer, 2008.

16. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. Location-based Software Modeling and Analysis: Tropos-based Ap-proach. InProc. of the 27th International Conference on Con-ceptual Modeling (ER 2008), volume 5231 ofLNCS, pages169–182. Springer, 2008.

17. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. A Goal Mod-eling Framework for Self-Contextualizable Software. InProc.of the 14th International Conference on Exploring ModelingMethods in Systems Analysis and Design (EMMSAD 2009),volume 29 ofLNBIP, pages 326–338. Springer, 2009.

18. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. A Goal-basedFramework for Contextual Requirements Modeling and Analy-sis. Requirements Engineering, 15(4):439–458, 2010.

19. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. Reasoningabout Contextual Requirements for Mobile Information Sys-tems: a Goal-based Approach. Technical Report DISI-10-029,University of Trento, April 2010.

20. Raian Ali, Fabiano Dalpiaz, and Paolo Giorgini. Goal-basedself-contextualization. InIn the Forum of the 21st InternationalConference on Advanced Information Systems (CAiSE 09 - Fo-rum), volume Vol-453, pages 37–42. CEUR-WS, 2009.

21. A. Lapouchnian, Y. Yu, and J.: Mylopoulos. Requirements-driven design and configuration management of business pro-cesses. InProceedings of the 5th International Conferenceon Business Process Management (BPM 2007), volume LNCSVol. 4714, pages 246–261. Springer-Verlag, 2007.

22. Colette Rolland, Carine Souveyet, and Camille Ben Achour.Guiding Goal Modeling using Scenarios.IEEE Transactionson Software Engineering, 24(12):1055–1071, 1998.

23. Sotirios Liaskos, Alexei Lapouchnian, Yijun Yu, Eric Yu, andJohn Mylopoulos. On Goal-based Variability Acquisition andAnalysis. InProc. of the 14th IEEE International Conferenceon Requirements Engineering (RE’06), pages 76–85, 2006.

24. Karen Henricksen and Jadwiga Indulska. A Software Engineer-ing Framework for Context-Aware Pervasive Computing. InProc. of the 2nd IEEE International Conference on PervasiveComputing and Communications (PerCom’04), pages 77–86,2004.

25. Stephen S. Yau and Junwei Liu. Hierarchical Situation Mod-eling and Reasoning for Pervasive Computing. InProc. of the4th IEEE Workshop on Software Technologies for Future Em-bedded and Ubiquitous Systems (SEUS’06), pages 5–10, 2006.

26. Xiao Hang Wang, Da Qing Zhang, Tao Gu, and Hung KengPung. Ontology Based Context Modeling and Reasoning usingOWL. In Proc. of the 2nd IEEE Annual Conference on Perva-sive Computing and Communications Workshops, pages 18–22,2004.

27. Tarak Chaari, Dejene Ejigu, Frederique Laforest, andVasile-Marian Scuturici. A Comprehensive Approach to Model andUse Context for Adapting Applications in Pervasive Environ-ments. Journal of Systems and Software, 80(12):1973 – 1992,2007.

28. Mohammed Salifu, Yijin Yu, and Bashar Nuseibeh. Specify-ing Monitoring and Switching Problems in Context. InProc. ofthe 15th International Conference on Requirements Engineer-ing (RE’07), pages 211–220, 2007.

29. Mohammed Salifu, Bashar Nuseibeh, Lucia Rapanotti, andThein Than Tun. Using Problem Descriptions to RepresentVariabilities for Context-aware Applications. InProc. of the 1st

International Workshop on Variability Modelling of Software-Intensive Systems (VaMoS 2007), pages 149–156, 2007.

30. Alexei Lapouchnian and John Mylopoulos. Modeling Do-main Variability in Requirements Engineering with Contexts.In Proc. of the 28th International Conference on ConceptualModeling (ER 2009), volume 5829 ofLNCS, pages 115–130.Springer, 2009.

31. Betty Cheng, Pete Sawyer, Nelly Bencomo, and Jon Whittle. AGoal-Based Modeling Approach to Develop Requirements ofan Adaptive System with Environmental Uncertainty. InModelDriven Engineering Languages and Systems, volume 5795 ofLNCS, pages 468–483. Springer, 2009.

32. Daniel Amyot, Hanane Becha, Rolv Braek, and Judith E. Y.Rossebo. Next Generation Service Engineering. InProc. of the1st ITU-T Kaleidoscope Academic Conference on Innovationsin NGN: Future Network and Services (K-INGN 2008), pages195–202, 2008.

33. Klaus Pohl, Gunther Bockle, and Frank van der Linden.Soft-ware Product Line Engineering: Foundations, Principles, andTechniques. Springer, 2005.

34. Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, EuiseobShin, and Moonhang Huh. FORM: A feature-oriented reusemethod with domain-specific reference architectures.Annals ofSoftware Engineering, 5:143–168, 1998.

35. Herman Hartmann and Tim Trew. Using Feature Diagrams withContext Variability to Model Multiple Product Lines for Soft-ware Supply Chains. InProc. of the 12th International SoftwareProduct Line Conference (SPLC’08), pages 12–21. IEEE Com-puter Society, 2008.

36. Mathieu Acher, Philippe Collet, Franck Fleurey, PhilippeLahire, Sabine Moisan, and Jean-Paul Rigault. Modeling Con-text and Dynamic Adaptations with Feature Models. In4th In-ternational Workshop Models@run.time (MRT’09), 2009.

37. Carlos Parra, Xavier Blanc, and Laurence Duchien. ContextAwareness for Dynamic Service-oriented Product Lines. InProc. of the 13th International Software Product Line Confer-ence (SPLC’09), pages 131–140, 2009.

38. Yijin Yu, Julio C. S. do Prado Leite, Alexei Lapouchnian,and John Mylopoulos. Configuring Features with StakeholderGoals. InProc. of the 2008 ACM symposium on Applied com-puting (SAC’08), pages 645–649, 2008.

39. Muthu Ramachandran and Pat Allen. Commonality and Vari-ability Analysis in Industrial Practice for Product Line Improve-ment. Software Process: Improvement and Practice, 10(1):31–40, 2005.

40. Ebrahim Bagheri, Tommaso Di Noia, Azzurra Ragone, andDragan Gasevic. Configuring Software Product Line FeatureModels Based on Stakeholders’ Soft and Hard Requirements.In Software Product Lines: Going Beyond, volume 6287 ofLNCS, pages 16–31. Springer, 2010.

41. Martin Feather, Steve Fickas, Axel Van Lamsweerde, andCristophe Ponsard. Reconciling System Requirements andRuntime Behavior. InProc. of the 9th international workshopon Software specification and design (IWSSD’98), 1998.

42. Don Cohen, Martin S. Feather, K. Narayanaswamy, andStephen S. Fickas. Automatic Monitoring of Software Require-ments. InProc. of the 19th International Conference on Soft-ware Engineering (ICSE’97), pages 602–603, 1997.

43. Yiqao Wang, Sheila McIlraith, Yijin Yu, and John Mylopoulos.An Automated Approach to Monitoring and Diagnosing Re-quirements. InProc. of the 22nd IEEE/ACM International Con-ference on Automated Software Engineering (ASE’07), pages293–302, 2007.

Requirements-Driven Deployment 23

44. Paolo Giorgini, John Mylopoulos, Eleonora Nicchiarelli, andRoberto Sebastiani. Reasoning with Goal Models. InProc.of the 21st International Conference on Conceptual Modeling(ER’02), pages 167–181, 2002.

45. Michael Weiss and Daniel Amyot. Business process model-ing with urn. International Journal of E-Business Research,1(3):63–90, 2005.

46. Andreas Kronz. Managing of process key performance indica-tors as part of the aris methodology.Corporate performancemanagement, pages 31–44, 2006.

47. Alireza Pourshahid, Gunter Mussbacher, Daniel Amyot, andMichael Weiss. Toward an aspect-oriented framework for busi-ness process improvement.International Journal of ElectronicBusiness, 8(3):233–259, 2010.

48. Suzanne Robertson and James Robertson. Reliable Require-ments through the Quality Gateway. InProc. of the 10th Inter-national Workshop on Database & Expert Systems Applications(DEXA’99), pages 357–363, 1999.

49. Suzanne Robertson. An Early Start to Testing: How to TestRequirements. InProc. of the EuroSTAR conference, 1996.

50. Nelly Bencomo, Jon Whittle, Peter Sawyer, Anthony Finkel-stein, and Emmanuel Letier. Requirements Reflection: Require-ments as Runtime Entities. InProc. of the 32nd ACM/IEEE In-ternational Conference on Software Engineering (ICSE 2010),pages 199–202, 2010.