Requirements-driven deployment

Softw Syst Model (2014) 13:433–456DOI 10.1007/s10270-012-0255-y

REGULAR PAPER

Requirements-driven deploymentCustomizing the requirements model for the host environment

Raian Ali · Fabiano Dalpiaz · Paolo Giorgini

Received: 25 May 2011 / Revised: 1 April 2012 / Accepted: 20 June 2012 / Published online: 22 July 2012© Springer-Verlag 2012

Abstract Deployment is a main development phase whichconfigures a software to be ready for use in a certain environ-ment. The ultimate goal of deployment is to enable users toachieve their requirements while using the deployed soft-ware. However, requirements are not uniform and differbetween deployment environments. In one environment, cer-tain requirements could be useless or redundant, therebymaking some software functionalities superfluous. In anotherenvironment, instead, some requirements could be impossi-ble to achieve and, thus, additional functionalities would berequired. We advocate that ensuring fitness between require-ments and the system environment is a basic and critical stepto achieve a comprehensive deployment process. We pro-pose a tool-supported modelling and analysis approach totailor a requirements model to each environment in whichthe system is to be deployed. We study the case of a con-textual goal model, which is a requirements model that cap-tures the relationship between the variability of requirements(goal variability space) and the varying states of a deploy-ment environment (context variability space). Our analysisrelies on sampling a deployment environment to discover itscontext variability space and use it to identify loci in the con-textual goal model where a modification has to take place.

Communicated by Prof. Robert France.

R. Ali (B)School of Design, Engineering and Computing,Bournemouth University, Bournemouth, UKe-mail: [email protected]

F. Dalpiaz · P. GiorginiDepartment of Information Engineering and Computer Science,University of Trento, Trento, Italye-mail: [email protected]

P. Giorginie-mail: [email protected]

Finally, we apply our approach in practice and report on theobtained results.

Keywords Requirements engineering ·Contextual requirements · Deployment ·Context-sensitive systems modelling

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 effi-cient way to satisfy their requirements. Traditionally, soft-ware deployment concerns the technical configuration of animplemented 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 unde-sirable, and possibly harmful, mismatch between softwareand its development purpose. Let us take as an example arequirement like “get user input”. This requirement is achiev-able via two alternative requirements: “by voice recognition”and “by click-based dialogue”. If the deployment environ-ment is often noisy then the alternative “by voice recognition”is inapplicable regardless a correct deployment of softwarefunctionalities, settings and equipments.

The software environment includes whatever provides asurrounding within which the software operates. The stateof such environment is denoted by the notion of context [1].Context is variable and requirements are highly affected by

123

434 R. Ali et al.

context variability. The system has to monitor context atruntime and decide upon which requirements to activate,which software alternatives are applicable and can satisfythe activated requirements, and the quality of each of thesealternatives. Specifying and implementing the relationshipbetween context and requirements is essential to obtain soft-ware systems which meet user requirements in a dynamicenvironment. However, the space of context variability dif-fers from one deployment environment to another. Each envi-ronment exhibits a specific contextual variability space and,thus, the requirements have to be customized so as to maxi-mize the fitness 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 require-ments analysis phase to explain the why of a software sys-tem. Goal models have been used to represent the rationaleof both humans and software systems [7] and they provideuseful constructs to analyse high level requirements (goals)and discover ways to satisfy them. Such features are essen-tial for the analysis and design of a software system thatreflects the stakeholders’ rationale and their adaptation to adynamic system environment [8,9]. Moreover, goal modelshelp to identify alternative software functionalities to satisfygoals. This feature is essential to adapt to context variabil-ity of a deployment environment so that a change in con-text would cause a switch to a suitable alternative to fulfilrequirements. However, the context variability profile of adeployment environment makes some of these alternativesredundant and useless. Moreover, the space of alternativesmay be unable to accommodate certain contexts occurring inthe environment. The discovery of these cases is important todetermine whether extra functionalities have to be developedand deployed.

In this paper, we advocate that software customizationshould be first studied at the requirements level. The reasonis that requirements are not uniform and differ according todifferent factors. Hui et al. [10] describe how requirementscan be 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 asgoals, and the business process of an organization based onmonitoring a set of Key Performance Indicators (KPIs) andthen decide whether an adaptation action should take place.The context variability of a system environment is also avery important factor which highly affects the customizationof requirements 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 specified

at a set of variation points on the goal model and its truthvalue defines which requirements are applicable and active.We refine high-level descriptions of context into concrete andmonitorable criteria to judge if the analyzed context holds.Moreover, we have developed reasoning mechanisms for (i)runtime derivation of software configurations to satisfy goalsthat are applicable in a monitored context and able to accom-modate user priorities, and (ii) design time identification ofthe least expensive alternative which guarantees goals sat-isfaction 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 var-iability which characterizes a deployment environment.

In this paper, we propose an engineering approach forcustomizing requirements models to fit their deploymentenvironments as an essential step for a comprehensive andcomplete systems deployment process. We consider the caseof contextual goal models, which is a requirements model thatexplicitly captures the relation between variability of bothrequirements, expressed as goals, and the state of the systemsurrounding environment (its context). We develop reason-ing mechanisms to analyse a contextual goal model givena certain deployment environment and customize it by (i)removing 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 Sect. 2 we reviewcontextual goal models and present our research questions.In Sect. 3 we introduce our approach for requirements-drivendeployment and explain our CASE tool. In Sect. 4 we pro-pose a process model for requirements-based deployment.In Sect. 5 we apply our approach in practice and discuss theresults. In Sect. 6 we discuss related work, and in Sect. 7 weconclude 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 thedynamism of a system environment affects whether a require-ment needs to be achieved, restricts the space of adoptablealternatives to achieve it, and affects the quality of each of

123

Requirements-driven deployment 435

Table 1 Summary of ourprevious work and contributionof this paper

Work Contribution

Weaving context withrequirements [15,16]

A theoretical ground for weaving together the variabilities of both context andrequirements

Defining a set of variation points on goal models where context conditionscan be specified

A basic formalization of the model and a set of basic analysis implemented inDatalog

Context analysis[17,20]

A systematic way to refine context and elicit its specificationA modelling language for context refinementA systematic way to derive contextual workflows from contextual goal models

Automated analysis ofcontextual goalmodels [18,19]

Derivation of the goal alternatives which fit a context monitored at runtimeand a set of user preferences expressed over softgoals

Derivation of a set of alternatives with minimal costs and able to meet all goalsChecking the consistency of context specificationChecking the consistency of tasks and avoid conflicting actionsA first version of a CASE tool (RE-Context) which implements the above four

reasoning mechanismsThis work Advocating the need to explore a deployment environment and customize the

requirements modelProviding a systematic approach, based on contextual goal models, to explore a

deployment environmentProposing analysis mechanisms to customize a contextual goal model to fit the

characteristics of an explored environment by removing uselessness andredundancy and suggesting augmentations

Extending our CASE tool (RE-Context) proposed in [18,19] to implement theproposed analysis

these alternatives. We have advocated the need to weavetogether context and requirements. We have proposed tospecify context (we called it “location” in that work) as aprecondition at certain variation points of a goal model. Wehave also proposed basic automated analysis to (i) derive theset of adoptable system’s alternatives for a certain contextand (ii) determine the context that supports a given alter-native. In [17,20], we have proposed the context analysismodel, which includes constructs (statement, fact, support,decomposition) to hierarchically refine context into a formulaof monitorable facts. We also proposed a way to derive thecontextual workflow of the 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,alternatives which best fit both a monitored context and thepreferences of a user expressed as ranking over softgoals. Inthe same work, we also developed a design-time reasoningfor deriving systems’ alternatives with minimal developmentcosts. In [19], we have developed automated analysis to checkthe consistency of context in a contextual goal model. Wehave also developed an analysis to check the conflicts aris-ing from the parallel execution of the software actions (goalmodel tasks). A first version of a CASE tool was implementedto perform the above four types of reasoning.

Research question and contribution In this work, we addressa different and important research challenge concerningthe analysis of contextual requirements to fit a certaindeployment environment. We analyse the fitness between a

contextual goal model, which captures the relation betweenrequirements and a space of context variations, and thespace of contexts occurring in and characterizing a certaindeployment environment. That is, we customize a contex-tual goal model to the characteristics of a specific deploy-ment environment. We provide a systematic way to explorethat environment and an automated analysis to customize therequirements model. The customization here means remov-ing parts of the model which are unusable or redundant in aspecific environment and, also, indicating loci in the modelwhere an augmentation is needed to cover cases where thesystem is unable to meet its requirements in that environment.We also extend our CASE tool (RE-Context) to support theproposed deployment analysis (unusability, redundancy, andaugmentation) and evaluate our approach on a system forbooking meeting rooms in an academic environment. Table 1highlights the relations between our previous work and thispaper.

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 products tothe customers that are inside the shopping mall. Both custom-ers and sales staff are provided with PDAs as communicationand interaction devices. The system can satisfy its main goal

123

436 R. Ali et al.

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

“promoting a product to a customer” through different execu-tion courses. The adopted execution course depends on thecontext 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 ofexecutable processes (tasks).

The actor standing for a customer’s mobile informationsystem (“Customer IS”) has the top-level goal “promoteproduct [p] to customer [c] in mall [m]”. Goals are itera-tively decomposed into subgoals by AND-Decomposition(all subgoals should be achieved to fulfil the top goal) and byOR-Decomposition (at least one subgoal should be achievedto fulfil the top goal). The goal “sales staff [ss] delivers aproduct [p] sample to customer [c]” is AND-Decomposedinto “[ss] is notified” and “[ss] meets [c]”. The goal “pro-mote by giving free sample of product [p] to customer [c]” isOR-Decomposed into “[c] gets [p] sample of machine [mc]”

and “deliver [p] sample to [c] by sales staff [ss]”. Goals areultimately satisfied by means of executable tasks. For exam-ple, the goal “[c] knows about [p] and confirm the sampleoffer” can be satisfied by one of the tasks “interact via voicedialogue and voice recognition” and “interact via visual dia-logue and 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 to it.

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 byselecting one subnode in OR-Decompositions and Means-Ends, all subnodes in AND-Decompositions, and one depen-dency when multiple dependencies exist for the same node.

123


Table 2 Description andvariation point type for eachcontext in Fig. 1

Ci Description Variation point type

C1 The customer is in the product area for more than 5 minutes, has notgot a previous promotion on it, and promotion is potentiallyrealizable

Root goal

C2 The product can be used with another product the customer already has OR-Decomposition

C3 The product is discountable and interesting to the customer OR-Decomposition

C4 The product is free sampled and the customer does not have theproduct and does not know about it

OR-Decomposition

C5 The customer has experience with free samples machines and canreach one of the machines and start to use it in a short time

OR-Decomposition

C6 A sales staff has the ability and time to explain sufficiently about theproduct to the customer

Actors dependency

C7 The customer place is not noisy, and the system is trained enough onthe customer voice

Means-end

C8 The customer has a good level of expertise with regards to usingtechnology and a good control on his fingers, and the used device hasa touch screen

Means-end

C9 There is a sample machine close to and in the same floor as thecustomer and he is familiar with digital maps technology

Means-end

C10 The path between customer and the machine is complex and thecustomer knows how to interact and follow the guidance wizard

Means-end

C11 The sales staff PDA vibration is activated and he is holding his PDAand not using it for a call

Means-end

C12 The sales staff is putting his headphone on and he is not using his PDAfor a call

Means-end

C13 The customer is not moving quickly Means-end

C14 The customer stays around the sales staff and can be seen easily AND-Decomposition

C15 There are other people around the customer and the place is quiet Contribution

The model explicitly represents the relation between thespace of alternatives incorporated in it and context. Contexts,labelled by C1 . . . C15 in Fig. 1 and explained in Table 2, canbe specified at the following variation points:

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

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 fulfilthe top-level goal (task).

6. Contribution to softgoal Softgoals are qualitative objec-tives, i.e., there is no clear-cut criteria for their satisfac-tion. 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 or atask no matter where it appears in the goal model hierarchy.That is, certain contexts could inherently precondition theoperability of a goal or a task. For example, let us take thetask T = “print the map of the shopping mall” which belongsto the reception office system actor, say. For the operability ofT , a context like C = “the receptionist’s PC is connected toa printer” should hold no matter where this task appears. Letus call this an inherent context. However, some other contex-tual conditions apply on this same task only when it is partof a certain refinement and we call this a refinement context.If T is a means to satisfy a goal G1 = “familiarize emer-gency team with the mall”, we should add to C the contextCa = “there is an emergency situation and the emergencyteam is not familiar with the mall”. If T is a means to achievea goal G2 = “promote the mall” then we should add to C acontext like Cb = “the customer is visiting the mall for thefirst time and he did not visit another branches with a similarstructure”.

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 design

123

438 R. Ali et al.

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

The context preconditions propagate in a top-down style.The context which preconditions a root goal G 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 atask T = “turn on the siren”, which could be a means to fulfiltwo goals G1 = “protect mall from robbery” and G2 = “pro-tect mall from fire”. Each of these two goals is activated indifferent contexts: C1 = “a customer with unchecked item isleaving”, and C2 = “smoke sensors indicate a fire”, respec-tively. When task T is a means to satisfy G2, it is also precon-ditioned by C3 = “there is some staff or someone who canhear the siren and call the emergency”. Thus, C2 and C3 arenot always preconditions for T but only when it is meant tosatisfy goal G2. When T is part of the goal model alternativeto fulfil G1, context C1 will be propagated to it, while C2 andC3 will not be considered.

2.2 Context analysis

Similar to goals, contexts need to be analysed. On the onehand, goal analysis provides a systematic way to discoveralternative 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 contextas a formula of world predicates. The EBNF of this formulais shown in Code 1. We classify world predicates, based ontheir observability by an actor, into two types: facts and state-ments:

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

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

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 cap-ture the necessary data and compute the truth value of a fact.A statement cannot be observed by an actor for differentreasons, such as (i) lack of information to verify it: (ii) itsabstract nature makes it hard to find an evaluation criteria.Some decisions that an actor takes may depend on contextsspecifiable by means of only facts, while some other deci-sions may depend on contexts that include also statements.However, a statement can be refined into a formula of factsand other statements. We call the relation between such aformula of word predicates and a refined statement Support,and we define it as following:

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

The support relation is an approximation that analystsintroduce to infer the validity of a statement from moni-torable facts. In turn, this enables to verify high-level con-texts (expressed in business terms) from monitorable facts(expressed in physical terms). In an iterative way, a statementis refined to a formula of facts that supports it. In our contex-tual goal model, we allow only for monitorable contexts. Acontext is monitorable if it can be specified in terms of factsand/or statements that are supported by facts. A monitorablecontext, specified by a world predicate formula ϕ, applies ifall the facts in ϕ and all the formulae of facts that supportthe statements in ϕ are true. In Fig. 2, we analyse contextC1. In this figure, statements are represented as shadowedrectangles and facts as parallelograms. The relation supportis represented as curved filled-in arrow. The and, or, impli-cation logical operators are represented as black triangles,white triangles, 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-

123


Fig. 2 Context analysis for C1

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

ment environment. Such environment could exhibit certaincharacteristics that originate shortcomings, redundancies anduselessness in parts of the requirements model. Modifyingthe requirements model to fit its environment is an essentialstep for a holistic software deployment. While requirementscustomization could also consider decisions about differ-ent aspects, such as users preferences, costs, qualities, andorganizational rules, we are here interested in modifying themodel to suit the contextual variability profile of a deploy-ment environment. For this reason, we propose to first sam-ple the environment where the system is to be deployed(Sect. 3.1). Then, the collected samples are analyzed for twopurposes: (i) to locate loci in the contextual goal model whereaugmentation with extra alternatives is required (Sect. 3.2)and (ii) to minimize development costs by removing alterna-tives which are inapplicable or redundant (Sect. 3.3).

3.1 Sampling a deployment environment

The context variations in a system environment can influenceusers requirements. Certain variations may activate certainrequirements, or be required to adopt a specific alternativeset of functionalities to satisfy the active requirements. Forexample, if a customer seems interested in a product (con-text) then a product promotion has to be established (require-ment). Establishing the promotion can be done via differentalternatives, such as giving a free sample, cross-selling, ordiscounting. The adoptability of each of these alternativesrequires a certain context to hold. For example, promotingby giving a sample requires a context like “the product is newto the target 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 a sample. Samplingthe system environment is an iterative activity which shouldbe performed during a period of time at the deploymentphase.

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 alternatives andtheir qualities. Accordingly, we have specialized context into

123

440 R. Ali et al.

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

three 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 activation and (ii) AND-decomposition. An acti-vation context decides if a goal should be satisfied ora task should be executed. The activation context of agoal model alternative is the logical conjunction of thecontexts at the variation points of these two types (seeFig. 4).

2. Required context is necessary to adopt a certain wayfor achieving (executing) a set of active goals (tasks).Required contexts are those associated to the contextualvariation points (i) OR-decomposition, (ii) Means-end,and (iii) Actors dependency. These contexts are requiredto make a specific alternative of the goal model applica-ble. The required context of a goal model alternative isthe logical conjunction of contexts at the variation pointsof these 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 softgoals are 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 untilone context is true. Such event activates one or more alter-natives in the goal model. whose required contexts are thenmonitored. At this point, we can face two situations:

– If there exists at least an alternative with a holdingrequired context, then the sample is positive and the sys-tem has a way to satisfy the activated set of goals/tasks.

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

The sampling process stores the values of monitored con-texts as environment samples. The sampling process willmonitor the environment at deployment time and collect aset of environment samples to decide upon whether there is aneed to augment the goal model with additional alternatives(Sect. 3.2) and also if we need to clean it from redundant anduseless ones (Sect. 3.3).

3.2 Augmenting contextual goal models

A contextual goal model can be deployed in multiple envi-ronments. The space of alternatives that the goal model sup-ports, each preconditioned by a specific context variation,could be insufficient for meeting users’ goals in one envi-ronment for several reasons. The reason we address in thispaper is the unsatisfiability of contexts that are required toadopt activated goal model alternatives. In other words, cer-tain contexts of the deployment environment activate a set ofgoals and there is no alternative with a valid required context.Thus, some requirements are activated but unsatisfiable. Wepropose a solution to this problem based on augmenting thegoal model alternatives space to enhance the operability ofthe system when contextualized alternatives are missing.

We augment the goal model with default domain-indepen-dent solutions that can be adopted when no adoptable con-textualized alternatives exist. Default solutions are backupoptions, and are typically not as good as contextualized ones.They are meant to allow operability of the system when it

123


Fig. 5 Algorithm Discover Global Solutions

does not find an alternative that is expressly tailored to acurrent context.

Example 1 Consider the contextual goal model of Fig. 1.When C1 = “the customer is in the product area for morethan 5 minutes, he has not already got a promotion on it, andthe promotion is potentially realizable” is true, the root goal“promote product to customer in mall” is activated. If noneof the contexts C2 = “the product can be used with anotherproduct the customer already has”, C3 = “the product is dis-countable and interesting to the customer”, and C4 = “theproduct is free sampled and the customer does not have theproduct and does not know about it” holds, then none ofthe alternatives to fulfil the activated root goal will be adopt-able. Thus, we have an activated requirement and no alter-native to fulfil it. When such a situation occurs, a defaultsolution could be executed by sending an SMS to the cus-tomer introducing the basic features of the product.

The algorithm Discover Global Solutions shown in Fig. 5takes as an input a contextual goal model and a set of environ-ment samples obtained as described in Sect. 3.1. As an output,it returns the set of possible solutions (alternative augmenta-tions sets) for each negative sample. To this end, the algorithmgenerates the set of goal model alternatives together with theircontexts (Line 1). For each environment sample (Line 2), thealgorithm checks if the system can find a way to satisfy theactivated set of goals (Line 3). If so, the algorithm does notneed to find any solution as the sample is positive (Lines 3–4).Otherwise (Line 5), the algorithm invokes another algorithmProcess Sample (reported in Fig. 6 and described later) tospecify loci in the goal model where an augmentation couldbe needed (Line 6). Then, the algorithm traverses the result-ing annotated goal model to organize the partial augmenta-tions suggested by the invoked algorithm Process Sample assets of global solutions and associates these solutions withthe processed sample (Line 7). The algorithm cleans the con-textual goal model by deleting the annotated augmentations(Line 8), before processing the next sample.

The algorithm Process Sample is shown in Fig. 6. Thealgorithm is invoked for negative samples and its purpose is

Fig. 6 Algorithm Process Sample

to identify loci where augmentations with default non-con-textual alternatives are needed and to annotate the goal modelaccordingly. The algorithm starts processing the root goalnode and traverses the model recursively. For each subnodeof the node being processed (Line 1), the algorithm checks ifanother recursion is needed (Lines 2–4), i.e, if augmentationsin the hierarchy rooted by that subnode could be needed. Thishappens when the context preconditioning this subnode istrue in the processed negative sample (Line 2). If such a con-text is false then any augmentations in that subnode hierarchywill not be even satisfiable and are therefore useless. Whiletraversing the model, the algorithm annotates a possible aug-mentation for each refinement of the types OR-Decomposi-tion, Means-end, Dependency (Lines 5–6). The reason is thatthese types of refinements introduce alternatives and, there-fore, a non-contextual alternative may be added there whencontextualized alternatives are not adoptable.

Example 2 In Fig. 7, we show the results of processing thecontextual goal model of Fig. 1 with respect to a negativeenvironment sample. The activation context that holds hereis C1 ∧ C14. In this sample, there is no alternative to sat-isfy the activated set of goals and tasks. In other words,there is no alternative with a true required context supportedin the contextual goal model. Algorithm Discover GlobalSolutions will find this sample negative and then invoke thealgorithm Process Sample that will traverse the model look-ing for loci where augmentations could convert the sam-ple to a positive one. The algorithm Process Sample returnsthe goal model annotated with the augmentations A1 . . . A7.Algorithm Discover Global Solutions traverses the goalmodel and organizes these partial augmentations as a set ofglobal solutions {{A1, A2}, {A3, A4}, {A5}, {A6}, {A7}}. Theimplementation of any of these sets will enable an alternativeto fulfil goals when the sample under discussion occurs.

The algorithm Discover Global Solutions produces 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, the

123

442 R. Ali et al.

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

analyst has to specify for each augmentation whether it isrealizable and refine the model specifying how this can bedone. This specification will decide which samples are con-vertible to positives and support the final decision aboutwhich augmentations to implement. The decision may relyupon, e.g., a cost-benefit analysis concerning the feasibilityof the augmentations. We leave this topic for future work.

Example 3 Taking the augmentations suggested in Example2 and illustrated in Fig. 7, the analyst could find A4, A5, A6,and A7 unrealizable by contrast to A1, A2, and A3. The ana-lyst has then to specify each realizable augmentation. Theanalyst may specify that A1 can be realized via task “informvia text message & get confirmation by OK button”, A2 via“leaving a voice mail”, and A3 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 requirements

are 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 envi-ronment. 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(Sect. 3.3.1) and redundancy (Sect. 3.3.2).

3.3.1 Processing unusability

The contexts specified at a contextual goal model may havestatic values in a certain environment. The environment sam-ples may show that some of these contexts are always trueor always false. Each case has different effect and requires adifferent reduction action.

The contexts having true truth values in all of the collectedsamples lead to useless monitoring functionalities and, thus,unjustified costs. Context monitoring requires collecting

123


environment data which requires deploying equipments (dat-abases, sensors, positioning systems, cameras, etc.) and pro-cessing 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 var-iation point) is always true in all the environment samples.

Example 4 If the shopping mall, where the system is to bedeployed, consists of one floor, has plenty of sample dis-tribution machines and it is for products usable by youngpeople who are usually familiar with new technology, thenC9 = “there is a sample machine close to and in the samefloor as the customer and he is familiar with digital mapstechnology” would be always true and there is no need tomonitor it. Such context has to be removed from the goalmodel deployed in that specific mall. Removing this contextavoids installing a positioning system, preparing a map forthe mall, and developing a database to store customer profiles(presuming that other system functionalities do not requirethat).

On the other hand, the contexts having false truth values inall collected samples lead to unjustified monitoring function-alities. Moreover, the existence of such contexts means thatsome goal model alternatives are never applicable. Both thecontexts specified at the variation points and the accumulativecontexts of goal model alternatives could have false values.As we mentioned earlier, the context of a goal model alter-native is the conjunction of two accumulative contexts: theactivation context and the required context of that alternative(see Fig. 4). The alternatives including contexts (individualor accumulative) that are false in all the environment samplesshould be removed from the model. This is to avoid deploy-ing functionalities meant to support inapplicable goal modelalternatives. By removing these alternatives, we potentiallyreduce the costs of monitoring the contexts included in them.However, the removal of one alternative does not mean thatthe goals, tasks, and contexts included in it will be removeddefinitely from the final model, as they might also appear inother 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 alterna-tives together with their contexts (Line 1). An alternative isadoptable with regards to one environment sample if bothits activation and required contexts hold in that sample. Thealgorithm then checks all the contextual goal model alter-natives (Line 3–7). If an alternative is adoptable in at leastone of the environment samples (Line 4) then it is added tothe set of the adoptable alternatives V ′ (Line 5). Finally, thealgorithm gives as an output the set of adoptable alternativesas a reduced version of the contextual goal model (Line 8).

Fig. 8 Algorithm Process Unusability

Example 5 In a noisy shopping mall, the context C7 = “thecustomer’s place is not noisy, and the system is trainedenough on the customer voice” will never hold and any alter-native preconditioned by a context includes C7 will be inap-plicable. Such alternative should be removed from the finalset of adoptable alternatives. Excluding alternatives meansexcluding some functionalities (tasks) from the deployed sys-tem. The task “voice dialogue and voice recognition” can beexcluded from the requirements model, as it will never beadoptable. The exclusion of alternatives leads also to exclud-ing contexts to minimize monitoring costs. Removing C7

avoids us the costs of sensing and analyzing the noise levelin the location of customer and tracking the system learningof the user voice.

3.3.2 Processing redundancy

Some functionalities might be redundant when the systemoperates in a certain environment. An early and main sourcefor redundancy is the requirements model. The environmentmay make some requirements redundant and therefore thefunctionalities that are deployed to satisfy these requirementswill be redundant as well. Accommodating a large spaceof functional alternatives, even though redundant, could bedesirable for reasons such as supporting high flexibility, dif-ferent users’ preferences, and fault tolerance. However, forreasons such as costs and time constraints, detecting the func-tionalities that allow the system to fulfil its requirementswithout redundancy is often needed.

Contextual goal models represent explicitly the relationbetween two spaces: the space of requirements alternativesand the space of context variations. Analysing contextualgoal models to discover which requirements alternatives areredundant leads to a model that incorporates the minimumbut sufficient space of alternatives. We consider an alterna-tive of the goal model v redundant if there is another alter-native v′ that is applicable whenever v is applicable. In otherwords, we deal with redundancy originated by the replace-ability of some alternatives. As we mentioned earlier, sup-porting redundant alternatives in the deployed system could

123

444 R. Ali et al.

Fig. 9 Algorithm Process Redundancy

be justified to develop high-variability systems. We leave theselection between redundant alternatives for future work.

The processing of a contextual goal model to removeredundant alternatives and group the rest based on applica-bility equivalence is reported in Fig. 9. The algorithm takesas input a contextual goal model and a set of environmen-tal samples and returns the redundant and equivalent groupsof alternatives. First, the algorithm generates the set of goalmodel alternatives together with their contexts (Line 1) andinitializes the set Equivalent_Gv to an empty set. This setwill be used later to represent the sets of equivalent alterna-tives (Line 2). The algorithm then organizes the adoptablegoal model alternatives in groups based on equivalence ofapplicability in the environment samples (Line 3–11). To thisend, the algorithm picks randomly an alternative v (Line 4)and finds the group of alternatives Gr.alternatives that areapplicable exactly when v is applicable (Line 5). The samplesset in which these alternatives are applicable is also recorded(Line 6). The group of equivalent alternatives is eliminatedfrom the set of all alternatives (Line 7) and considered forfurther processing if there exists at least one sample in whichv (and therefore the other alternatives in the group) holds1. Ifa group of equivalent alternatives is replaceable by another,i.e., if in all samples where the first is applicable so the sec-ond is, then the first group is marked replaceable and removedfrom the output (Line 11–12).

Example 6 Figure 10 shows an example of a replaceablealternative. In this example, we suppose that the assistancestaff members have to put the headphone on when they areavailable for serving customers. If such a policy holds in theshopping mall where the system is to be deployed, then theimplication C11 → C12, where C11 = “the sales staff PDAvibration is activated and he is holding his PDA and not usingit for a call” and C12 = “the sales staff is putting his head-phone on and is not using his PDA for a call”, holds in all

1 This check is unneeded if unusability is already processed.

Fig. 10 V1 is replaceable by V2 in a mall where C11 → C12 in allsamples

of the environment samples collected from that mall. Thismeans that V2 is applicable in all samples where V1 is appli-cable. Therefore, V1 can be considered replaceable and canbe removed from the model. Consequently, the task “notifysales staff by vibration” will not be deployed and the contextC11 can be also removed from the set of contexts to monitor.

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

123


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 inJava and are linked to external reasoners via wrappers. Thedeployment component is the component specifically devel-oped for this paper. The derivation of the space of alternativesfor a contextual goal model is a basic step for all types ofanalysis of RE-Context. RE-Context can derive alternativesincluded in a contextual goal model by running the DLV rea-soner as a planner. RE-Context outputs all the valid modelsthat satisfy the Datalog inference rules in the input file encod-ing the contextual goal model. Each alternative consists of aset of tasks to execute and a set of contexts associated with it.For more details about the generation of alternatives pleasesee our work in [18]. In the following, we describe the maincomponents of RE-Context:

– Derivation RE-Context generates the space of alterna-tives included in a contextual goal model. Re-Contextenables the choosing between alternatives in two styles.The first is a runtime derivation of the alternatives match-ing a given context and user’s preferences expressed asranking over softgoals. The second concerns the deriva-tion of a set of tasks with minimal development costswhich, if implemented, allows the system to cover andoperate in the space of context variations captured in acontextual goal model. To this end, the analyst has to spec-ify the resources needed for the development of each taskin a goal model and their costs. Please see our work [18]for more details about this component.

– Verification RE-Context generates the space of contex-tual goal model alternatives and checks context satisfi-ability for each alternative. This checking is done byrelying on the state-of-the-art SMT solver MathSAT2.The alternatives with unsatisfiable contexts are excludedfrom the model since they are inapplicable. Furthermore,

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

the tool checks the generated alternatives to detect thoseincluding 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 alternative a1 is redundant given that there isalways an alternative a2 which is applicable whenever a1

is applicable. However, the verification might show thata2 has a conflict and, therefore, we cannot consider a1

redundant, since a2 is not functionally correct and cannotreplace a1. The process shown in Fig. 12 and discussedin Sect. 4 explains the way of using the automated analy-ses. The deployment component performs three types ofanalysis 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 inSect. 3.3.1), excluding the alternatives which are inap-plicable and replacing the contexts which were alwaystrue 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 designerdecides to keep redundant alternatives for reasonssuch as flexibility and accommodating the preferencesof different users.

– Augmentation The purpose of this analysis is to findloci in a contextual goal model where an augmentationwith a default non-contextual alternative is necessaryto deal with negative samples. This processing enactsthe algorithm reported in Fig. 5. It returns a set ofpossible global solutions after processing individualalternatives. We still did not provide automated anal-ysis to qualify and evaluate solutions. The decisionabout this is still left for the analyst and we plan toprovide automated support for that in our future work.

123

http://mathsat4.disi.unitn.it

446 R. Ali et al.

Fig. 12 The deployment process

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 identifiedand 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 bya context 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 var-iation point in a goal model can be contextual.Context may affect either goal activation or theselection of alternatives to meet a goal. When avariation point is identified to be contextual, a high

level description of the correspondent context hasto be written down. As a result of this activity, thecontextual variation points at the goal model shouldbe annotated similarly to the model we have shownin Fig. 1. Moreover, the contexts associated withthese variation points should be described similarlyto the descriptions shown in Table 2.

(b) Context refinement The contexts at each contextualvariation point should be analysed. The analysisgoal is to identify ways through which the systemcan verify if a context holds. In other words, thecontext refinement has to define the environmentalfacts the system has to capture and the way thesefacts are composed to judge if an analysed contextholds. An example of context refinement is shownin Fig. 2.

3. Verification The requirements model has to be veri-fied to ensure freedom of modelling errors which leadto inconsistencies in the context specification and con-flicts between the executable tasks of a goal model.RE-Context supports this automated reasoning in ourwork described in [19]. Some alternatives of the goalmodel may be preconditioned by a set of contexts whichnever hold together. This make the alternative inappli-cable and useless if implemented. Moreover, the tasksof a goal model could lead to contradicting changes onthe system environment. This leads to conflicted actionsthat prevent a correct satisfaction of requirements. The

123


verification of contextual goal models should be doneas a preliminary step for the analysis that concerns thedeployment.

4. Environment sampling The deployment environmenthas to be explored through sampling. The samples areused to process the requirements model and ensure fit-ness between the model and the system environment.To do the sampling, the contexts specified at the con-textual goal model need to be monitored iteratively fora period of time and their values should be recorded assamples. More specifically, the contexts that activate goalmodel alternatives should be monitored until one of themholds. When this happens, the sampling process recordsthe values of the contexts specified at all of the varia-tion points of the activated goal model alternatives. Thiswill allow for further analysis to judge if the model sup-ports or lacks ways to satisfy its activated requirements.Monitoring the environment could be established by dif-ferent techniques such as surveying prospective users,being physically there and recording context variations,recording via cameras and analysing observations, etc.The sampling period has to be long enough in order tocapture contexts variations that happen less frequently orperiodically. However, the analyst would need to com-promise between the coverage and quality of the sampleset and the sampling period as we discuss in Sect. 5.2.

5. Augmenting alternatives space In this activity, the con-textual goal model has to be analysed using the col-lected environment samples to identify places wheredefault non-contextual solutions are needed. To this end,RE-Context can be used to analyse the model withregards to each sample and record the results. Doingthat, the tool will ask the analyst about the realizabil-ity of each suggested augmentation. The analyst can alsoassign costs to each augmentation and then use the tool toanswer queries like calculating the minimum-cost solu-tion that converts the largest number of negative sam-ples to positive. The tool will record the augmentationsapproved by the analyst to be added later to the finalgoal model. These default solutions may be recorded tobe suggested when deploying the contextual goal modelto other environments that shares similar contextual pro-file.

6. Processing unusability The goal of this activity is toremove unusable functionalities from the model. Thisactivity is fully automated and executable in our auto-mated RE-Context tool. The tool will scan the environ-ment samples to elicit the set of contexts specified at thevariation points of the goal model and having always-true values in all the samples. It will also check theaccumulative context of each goal model alternative tosee if it holds in at least one sample. After doing thesetwo checks, the tool will remove the always-true con-

texts from the model since deploying the functionalitiesto monitor them is unjustified. Moreover, the tool willremove the goal model alternatives having always-falsecontexts to avoid deploying unusable functionalities. Aswe mentioned earlier, the removal of one alternative doesnot necessarily mean that all the goals, tasks and contextsincluded in it are removable as, indeed, they may appearin other alternatives that are applicable.

7. Processing redundancy The purpose of this activity isto discover the set of goal model alternative which arereplaceable when operating in a certain host environ-ment. To this end, RE-Context can be used to group thealternatives based on the equivalence of their applicabil-ity in all the environment samples. Obviously, the groupof alternatives that are inapplicable in any of the deploy-ment environment samples are not further processed aswe described in the last activity (processing unusabili-ty). The tool will remove any group of alternatives forwhich there is another group applicable in all the samplesthe first one is applicable in. Such group will be redun-dant and inessential for the availability of the system.The analysts can then use the tool to select an alternativeof each of the remaining groups according to a certainselection criteria. The criteria that is currently supportedby RE-Context is the costs of resources needed for eachtask of the goal model. The tool is able to select a set oftasks of the goal model able to implement at least onealternative of the irreplaceable groups of variants with aminimum total cost. The selection algorithm is explainedin our previous work in [18].

8. Composing final contextual goal model In this activity,RE-Context can be used to merge the augmentationssuggested by the activity of augmenting the alternativesspace with the goal model alternatives that are usableand not redundant, i.e., the alternatives delivered bythe activities of processing unusability and processingredundancy. This goal model will be the final outcomeof our deployment process. It is a version of the origi-nal contextual goal model tailored to context variationshappening in the system operational environment. Thisversion removes the useless and redundant parts of theoriginal model and adds default alternatives to be adoptedwhen a contextual alternative one is missing. Thus, itleads to a version of software with maximized opera-bility and reduced development costs with regards to acertain deployment environment. The tool delivers thefinal goal model as a DLV code. We need to extend ourtool to draw a visual notation based on such code.

5 Evaluation

To evaluate our proposed approach, we have developed acontextual goal model for a room booking system used by

123

448 R. Ali et al.

academic research groups. The purpose of the system is toassist researchers in the room booking process. Room book-ing can be performed for different purposes: giving seminars,holding brainstorming sessions, making conference calls, orhaving a project meeting. Different rooms are available anddiffer in their equipment, availability status and times, etc.The three main requirements of the room booking systemare to assist researchers in booking a room, to announcethe meeting/event, and to assist researchers to get and useof supplementary equipments needed to establish the meet-ing/event. To collect the environment samples, we moni-tored the room booking processes for a period of time oftwo research groups (RG1 and RG2) at the Department ofInformation Engineering and Computer Science (DISI)3 atthe University of Trento. Then we have used the samples tocustomize the contextual goal model as we will explain later.Here we give more details about the three main requirementsof the room booking system 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 thedepartment secretary or the research group secretarywhen the later is available and assigned to the task ofrooms booking. The secretary has to be informed by thesystem and, then, she has to check if there is a roomavailable and reply to the staff who requested to book aroom. The communication with secretaries follows dif-ferent alternatives in different contexts. Booking a roomcan be done by the staff who requested a booking himselfif he has the permission to use the room booking calendar(we used a free calendar web service).

– Announcing a seminar The meeting requester needsassistance to announce the meeting/event either to pub-lic or specific set of people. Public announcements canbe done via the website of the research group of therequester, the website of the department, or the recep-tion screens visible to people who enters the depart-ment. Private announcements can be done via designatedmailing lists (all members of the research group) or viachosen contacts from the contact book of the researchgroup.

– 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 procedureto follow in order to do that, etc.

3 http://disi.unitn.it/.

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

Our monitoring process lasted 3 months and the samplesset consists of 61 booking processes: 34 reservations weremade by RG1, and 27 by RG2. To collect samples, we askedresearch groups members and department personnel involvedin the booking process to fill in a form for the contexts val-ues 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 contex-tual goal model for rooms booking. Group members wereasked to specify the truth values of the dynamic contexts,i.e., whose which vary from one reservation to another. Someother contexts were static and their values were known by usin advance (e.g., the profile of each research group, the roomseach group is granted access to, and installed equipments).After the samples collection phase, we used our automatedsupport tool RE-Context to process the collected samplesaccording to the analysis proposed in Sect. 3 and obtainedthe results reported and discussed later in this section.

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 canbe done by following various alternatives: the researcher cando it autonomously or can interact either with the researchgroup secretary or with the department secretary. Each alter-native is adoptable in a different set of contexts (e.g., C3

states that the department secretary can be involved only ifhe is in charge of that specific group and if he is currently notoccupied in higher-priority tasks) and the system is supposed

123

http://disi.unitn.it/~ali/index_files/RoomBooking.pdf

http://disi.unitn.it/


Table 3 The results ofanalysing the room bookingcontextual goal model for tworesearch groups

The size of the original goal model Value

Number of actors 5

Number of goals 33

Number of tasks 52

Number of softgoals 6

Number of contexts at variation points 34

Number of goal model alternatives 2808

Sampling Research Group 1 Research Group 2

Time of collect the samples 3 months 3 months

Number of samples 34 27

Number of positive samples 26 22

Number of negative samples 8 5

Unusability processing

Number of contexts true in all samples 3 3

Number of contexts false in all samples 3 2

Number of alternatives with always false contexts 1512 2592

Number of tasks that are never executed 6 20

Number of contexts removed with useless alternatives 3 12

Redundancy processing

Number of equivalent groups of alternatives 864 144

Number of redundant groups of alternatives (RGV) 792 126

Number of alternatives included in RGV 1152 180

Number of tasks that appear only in RGV 18 5

Number of contexts that appear only in RGV 11 4

Augmentation processing

Number of augmentations suggested for all negative samples 6 4

Number of realizable augmentations 2 2

Number of samples convertible from negative to possible 5 3

Size of the resulting goal model

Number of actors 4 4

Number of goals 25 22

Number of tasks 28 27

Number of softgoals 6 6

Number of contexts at variation points 14 13

Number of goal model alternatives 144 36

to support and track the room booking accomplishment. Forinstance, the research group secretary can be notified eitherby sending an e-mail to him (task t1) or via a specific webinterface (task t4), depending on the context. Another require-ment for the system is to support the announcement of bothpublic meetings and close meetings. Such requirement hasto be supported via different alternatives: announcing via thewebsite of the department or the research group, circulat-ing via mailing lists, displaying on electronic screens in thedepartment, etc. Each alternative requires a specific context

to hold. The last requirement of the room booking system isto remind meeting requesters about the supplementary equip-ment he would need such as projectors, web cams, networkcables, and also to explain to a meeting requester how toget needed equipments and to use them. The contextual goalmodel we developed for the room booking system consistedof 5 actors, 33 goals, 52 tasks, 6 softgoals, and 34 contex-tual variation points. The space of alternatives to fulfil themain goal “having a room booked” included 2808 alterna-tives.

123

450 R. Ali et al.

5.1 Samples processing results

In Table 3, we summarize the results obtained by applyingthe analysis described in Sect. 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 group RG1 led to 26positive samples—where the top-level goals have beenachieved—out of 34 samples, while the sampling for RG2

led to 22 positive samples out of 27 samples. The mainreason for failure in booking a room in RG1 was thatrooms are asked for booking short time before the eventand this led to failure in completing the booking pro-cess on time. For example, the room requester did nothave time to answer the emails concerning the supple-mentary equipments needed or to confirm the reservationafter being made by the secretary. The main reason forfailures in RG2 was that the group did not have a secre-tary that assists in booking rooms. This group had to relyon the department secretary who often had other higherpriority tasks to do.

– Unusability processing This activity detects andremoves static contexts that never vary and, also, inap-plicable goal model alternatives. The developed systemdoes not need to monitor static contexts (those havingthe same truth value in all collected samples). For exam-ple, the rooms assigned to RG2 had all supplementaryequipments and there was no need to monitor that. ForRG1, 3 contexts had false values in all the collected sam-ples and 3 had true values. For RG2, 3 contexts had falsevalues while 2 contexts had true values in all the col-lected samples. The contexts that are always false in all thesamples produced a large number of unadoptable alterna-tives (1512 for RG1 and 2592 for RG2). Consequently,the tasks that appear only in unadoptable alternatives arenever executed (6 tasks for RG1 and 20 tasks for RG2).Also, it is useless to monitor the non-static contexts whichappear in only unadoptable alternatives (3 contexts forRG1 and 12 contexts for RG2). For example, having aset of well-equipped rooms for RG2 means the removalof all the goal model alternatives where researchers arereminded to bring supplementary equipments. This, inturn, led to unadoptability of the tasks and uselessness ofmonitoring the contexts needed to accomplish the assis-tance of the researcher to bring such equipments.

– Redundancy processing A goal model alternative Vis redundant if in every sample where V is applicablethere exists another alternative V ′ which is applicable aswell. As explained in Sect. 3, to discover redundant alter-natives, we first remove inapplicable alternatives whichhave always-false contexts in all samples, i.e., unusable

alternatives. Then, we partition the rest into groups onthe basis of context value equivalence in all the samples,i.e., on the basis of applicability equivalence. The num-ber of equivalent groups was 864 for RG1 and 144 forRG2. A group is redundant if its set of positive sam-ples is included in the set of positive samples of anothergroup. We got 792 redundant groups for RG1 (contain-ing 1152 alternatives) and 126 groups for RG2 (contain-ing 180 alternatives). The importance of this computationwas the discovery of tasks that appear only in redundantalternatives (18 for RG1 and 5 for RG2). These tasks areredundant and, therefore, their deployment is optional.For example, our requirements model has two alternativesto notify a meeting requester: notification via email to beadopted when the person is often in office or has accessto Internet, and notification via mobile phone (such asvoice mail or SMS) that is adoptable when the staff is outof the department and has no access to Internet. In bothresearch 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 solu-tion 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 possible tofind a realizable default augmentation. For example, someof the collected samples of RG2 were negative due to thefact that the group secretary and the department secretarywere busy or having a day off. Finding a default non-contextual human-supported alternative was not possibleand the sample could not be converted to positive. RE-Context performed the analysis we explained in Sect. 3,which locates a set of augmentations to the goal modeland organizes these individual augmentations as alterna-tive solutions in the form of sum-of-products formula.Then, analysts need to specify which augmentations arerealizable. On the basis of this specification, a numberof solutions will be marked realizable and, consequently,some negative samples will be convertible to positive.The total number of augmentations proposed to convertthe negative samples to positive was 6 for RG1 and 4 forRG2. Out of these augmentations, the number of real-izable ones was 2 in RG1 and 2 in RG2. This enabledus to convert 5 of the 8 negative samples in RG1 topositive (3 of 5 in RG2). For example, one sample ofRG1 was negative due to the fact that one overseas staffcould not speak a language in common with the tech-nician to understand the use of video-conferencing. Thedefault solution was to develop a demo in multiple lan-guages.

123


Table 4 Comparing the analysis outcome to the original goal modeland collected samples

Factor ResearchGroup 1

ResearchGroup 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 uselessalternatives

3/34 = 8.8 % 12/34 = 35.3 %

Appear only in redundantalternatives

11/34 = 32.4 % 4/34 = 11.8 %

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

Appear only in uselessalternatives

6/52 = 11.5 20/52 = 38.5 %

Appear only in redundantalternatives

18/52 = 34.6 5/52 = 9.6 %

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

Samples convertible topositive

5/8 = 62.5 % 3/5 = 60 %

5.2 Discussion of the obtained results

The evaluation of our approach for customizing require-ments to a deployment environment showed promisingresults (as reported in Table 4). A considerable percentageof contexts (58.8 % for RG1 and 61.8 % for RG2) wereshown removable. Removable contexts include those hav-ing static—either true or false—value in all the collectedsamples, those removed because appearing only in uselessalternatives, and those removed when redundant alternativesare dropped. Removing static contexts results in lower mon-itoring costs, as their values are known a priori. Moreover,a considerable percentage of tasks were shown removable(46.2 % for RG1 and 48.1 % for RG2). The tasks appear-ing only in alternatives that are useless, i.e., their contextsare false in all of the collected samples, should not be sup-ported in the deployed system as they are not executable.The tasks that appear only in alternatives that are redundantare optional and thus can be removed to reduce costs. More-over, our analysis has shown also a considerable quantityof negative samples where the contextual goal model doesnot include alternatives tailored to support certain contextsin its deployment environment (23.5 % in RG1 and 18.5 %in RG2). The analysis also suggested places in the require-ments model where augmentations can convert the negativesamples to positive. Some augmentations were realizable andthis led to convert 62.5 % of RG1 and 60 % of RG2 nega-tive samples to positive. Such transformation will maximizeoperability 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 overlapbetween the resources needed for remaining and removed

Table 5 Threats to internal and external validity

Threats to internal validity

Th1. Experiment time period influence

Th2. Limited number of samples

Th3. Sampling was not transparent to participants

Threats to external validity

Th4. Other factors to support the analysts decisions are missing

Th5. Sampling is not always possible for privacy and securityconcerns, law, monitoring costs, etc.

Th6. Experiments performed only in one domain

contexts and tasks. For example, both tasks “send the roomdetails to secretary via email” and “send room details tostaff via mail” require gathering, storing, and updating therooms data (they need the same monitoring effort). Thus, theremoval of one of these tasks leads only to a partial savingof costs. To precisely compute costs saving, we consider theresources needed for task execution and context monitoring,similarly to what we proposed in [18]. The explicit spec-ification of these resources allows for identifying overlapsbetween tasks and contexts and, hence, for accurate calcula-tion of costs and savings. This enables better decision makingabout keeping or removing redundant alternatives.

Our approach reveals shortcomings in a designed require-ments model and, consequently, in the system to-be foraccommodating certain contextual variations in a deploy-ment environment. Our analysis proposes loci in the require-ments model where augmentation with other alternativesis desirable to maximize system ability in a certain envi-ronment. We have discussed augmentation with defaultnon-contextualized alternatives that the system can support.However, this is just one possibility to solve the problem. Inmany cases, the discovery of these loci motivates changesin the organizational environment. For example, we encoun-tered samples where there was no technician speaking a lan-guage in common with an overseas researcher and explain tohim about the use of the equipments in the seminar rooms. Inthis case, the deployed system can be augmented to supporta default alternative, such as showing a demo. However, thesolution could be also at the organizational level by guaran-teeing the presence of at least one technical staff who speaksEnglish. Our analysis motivates also the organization wherethe system is to be deployed to make changes that maximizethe requirements satisfaction likelihood.

5.3 Approach limitations and threats to validity

We discuss here the limitations of our approach and thethreats to internal and external validity of our evaluation onthe room booking case study. Table 5 summarizes the mainthreats to internal and external validity.

123

452 R. Ali et al.

The definition of the sample collection period is a sensitivedecision to take. Indeed, the contextual variations that mayhappen in one deployment environment could vary from oneperiod to another. This will influence the comprehensivenessof the samples collected and, therefore, the analysis results.This is an internal threat (Th1) to validity in our case study, aswe have studied the room booking scenarios between Apriland June, which is an active period in academia. Probably,collecting samples in the vacation months, such as August,would provide different results. However, for practical rea-sons we need to find a compromise between keeping thesamples 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 variations inthe 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. Interviewingdomain experts and analysing user samples sets are possi-ble ways to overcome these issues. We leave the develop-ment of these techniques for future work. In our case study,the involvement 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 answerto our interviews when sampling the environment.

Further analysis is needed to support the analyst’s deci-sions about the augmentations to support and the redundancyto remove. Our analysis outputs alternative augmentations tosupport default solutions when the model lacks contextuali-zed 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 developmenttime and operating costs, and so on. This is a threat to externalvalidity (Th4). Future work includes providing better supportto the analyst in taking the right decisions. We aim to incor-porate softgoals in the decision about which augmentationsto enact and what redundant elements to remove or keep.

Obtaining context information is not always straightfor-ward due to several reasons. People usually have privacyconcerns that prevent the system from monitoring theirbehaviours, location, activity, and so on. Some laws mayimpose constraints on monitoring contextual informationwithout people’s clear consent. Compliance with law mightbe hard to judge and might differ from one location to another.Moreover, although obtaining more contextual information

can maximize certainty while taking a context-based deci-sion, there could be a trade-off between the certainty and therequired costs to establish this monitoring. In our case study,and because we are members in the academic organizationin which the experiment was done, we have not faced suchobstacles: this is another threat to external validity (Th5). Ourapproach still needs to deal with different issues related tomonitoring context (privacy concerns, law, costs,..) and weleave this for future work. An additional threat to externalvalidity (Th6) is that we draw our conclusions with respectto a single domain (seminar rooms booking in academia).Perhaps, applying our framework in other domains mightreveal limitations in both of our modelling foundations anddeployment 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, however,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 presum-ing a prior knowledge of them, we proposed context analysisto enable a systematic hierarchical refinement to analyse con-text and 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 hier-archy. 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 influ-ence of contexts on these measures and prioritizing require-ments alternatives accordingly [10,12,18]. Lapouchnian andMylopoulos [30] share with us similar vision of integratingcontext with intentional variability captured by goal mod-els. We have investigated more in this direction and defineda set of variation points where context affects goal modelswith clear semantic and a systematic way to analyse context.Such effort allows us to develop a formal framework thatnatively supports automated reasoning.

Cheng et al. [31] deal with environmental uncertaintyusing KAOS goal models and conceptual domain models.Their core contribution is to introduce tactics to mitigate

123


uncertainty. However, unlike us, they do not rely on samplingand reflecting the actual contextual variability which charac-terizes a certain operational environment. Thus, their mitiga-tion strategies are based merely on the analyst’s expertise andknowledge. Amyot et al. [32] model the impact of contexton softgoals, using GRL models, in the context of serviceengineering. By not relying on collected contextual datafrom the operational environment where the system is to bedeployed, 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 mod-els [33,34]—concerns modelling a variety of possible con-figurations of the software functionalities to allow for asystematic way of tailoring a product upon stakeholderchoices. These approaches do not bridge the gap betweeneach functionality and the context where this functionalitycan or has to be adopted, the problem we tried to solve atthe goal level. Recently, several works recognized the roleof context in the software products derivation [35–37]. Ourwork, though proposed in the area of goal-oriented require-ments engineering, can be adapted to complement contex-tual software product lines, providing a clear semantic of therelation between contexts and features, an automated con-textualized derivation process, a systematic way to identifycontext itself, and a process to customize a product duringthe deployment. Furthermore, our work is in line, and hasthe potential to be integrated, with the work in [38] and theFARE method proposed in [39], that show possible ways tointegrate features with domain goals and knowledge to helpfor eliciting and justifying features. Recent work [40] focuseson the selection of feature model configurations that take intoaccount soft constraints that represent desired quality attri-butes. Unlike us, such approach does not explicitly considercontextual factors, which are fundamental to discriminatebetween possible and inapplicable alternatives.

Requirements monitoring adds specific code to a run-ning system to gather information, mainly about the com-putational performance, and reason if the running system isalways meeting its design objectives, and reconcile the sys-tem behaviour to them if a deviation occurs [8]. The objec-tive is to have more robust, maintainable, and self-evolvingsystems. In [41], the GORE (Goal-Oriented RequirementsEngineering) framework KAOS [5] was integrated with anevent-monitoring system (FLEA [42]) to provide an architec-ture that enables runtime automated reconciliation betweensystem goals and system behaviour with respect to a pri-ori known or evolving changes of the system environment.A similar effort along the same line is Wang’s requirements-driven diagnosis [43], which diagnoses software errors andtheir influence at the requirements level. Our work is also

focused on monitoring. Unlike such approaches, however,we provide an explicit notion of context as a main driver toderive the requirements to meet and the adoptable alternativesto meet them. The deployment process we proposed can beadapted for runtime adaptation and reconciliation, as relyingon correct models is fundamental to ensure runtime adapta-tion is in response to threats to requirements and eventuallyleads to requirements satisfaction.

Customizing goal models to fit to user skills and pref-erences was studied in [10,12]. Such work can be used atdeployment time where specific user skills and preferencewill rule out some alternatives and, thus, the deployed sys-tem will not need to support them. We envisage that a jointusage with our approach would enrich the set of aspects thedeployment process can deal with. Liaskos et al. [23] studythe variability modelling under the requirements engineeringperspective and propose a classification of the intentional var-iability when OR-decomposing a goal. We focused on con-textual variability, i.e., the unintentional variability, whichinfluences the applicability and appropriateness of each goalmodel alternative. Reasoning with goal models has been stud-ied in [44]. Adding context to goal models creates the need tointegrate contextual reasoning and goal reasoning. Our previ-ous and current work provides concrete answers to such need.

Pourshahid et al. [14] address a very important aspect con-cerning 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 suchenvironment could activate certain requirements and makeadpotable/inadoptable some of the system’s alternatives tofulfil the activated requirements. Pourshahid et al. [47] intro-duce aspects as a mechanism to model the redesign patternsand choose the best applicable patterns based on their impacton different views of the system (process, goal, validation,and performance). Such approach could be combined withours to allow for a comprehensive customization and adap-tation since we would be able to monitor both the charac-teristics of the system environment and the operation of thesystem itself in practice and decide what modification to doboth at design time and runtime.

The idea behind requirements testing is that testing hasto start with requirements, as code correctness is unachiev-able in case requirements are incorrect [48,49]. Our workis supportive to this argument especially when we designrequirements for adaptive systems where the requirementsmodel represents a high-level abstraction of the behavior ofthe program itself. Our work provides models and reasoning

123

454 R. Ali et al.

mechanisms to test and customize a requirements model toits deployment environment. We also plan to develop require-ments-driven runtime adaptation, in line with the vision ofrequirements reflection [50], that maximizes this fitness con-tinuously and allows the system to learn from its experiencein its operational environment.

7 Conclusions and future work

In this paper, we have discussed deployment of require-ments models as an essential activity of software deploy-ment. Our argumentation is that requirements are not uni-form and may differ from one environment to another. Weprovided a conceptual model, the contextual goal model, thatexplicitly captures the relation between context variationsand requirements. We showed how this model is customizedto fit each particular environment in which the system is tobe deployed. Our process is based on exploring the systemprospective environment and collecting samples reflectingthe truth values of the contexts specified in the requirementsmodels and then processing the model against the samplesset. The processing aims to discover useless and redundantparts of the model. This, in turn, reduces the costs of thedeployed system and avoids deploying unnecessary function-alities. Moreover, our proposed processing discovers loci inthe model where extra solutions are needed to handle contextsfor which the model lacks alternatives. This maximizes theoperability of the system in its host environment. We devel-oped a formal framework and an automated reasoning toolto support our approach. We also outlined a methodologicalprocess that guides the use of our framework to gather anddeploy requirements.

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 groupsand their room reservations for meetings during 3 months.We processed the requirements model that we developedfor room booking against the reported room reservationsexperience. The processing aimed at customizing the require-ments model to its deployment environments. Our process-ing showed a significant amount of detected unusabilitiesand redundancies in the model. This is important to save thecosts of deploying functionalities aimed to satisfy unneces-sary requirements. On the other hand, we discovered sev-eral cases in which the model lacks solutions for fulfillingthe main requirements: having a room booked. Discover-ing these cases and augmenting the model with additionalalternatives will maximize the system ability to meet usersrequirements in the deployment environment. The applica-tion of our framework in practice (Sect. 5) gave us insightson several challenges to address in a future work:

– Certain characteristics of the environment represent con-straints on the system behaviour which are hard to capture

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 therequirements model are often easy to take, decisionsabout what redundancies to accept and what augmen-tations to implement are often complex decisions. Thereason for this complexity is that multiple factors playa role in that decision such as increasing flexibility andfault tolerance and accommodating different users pref-erences and so on. Developing a multi-criteria decisionmaking techniques specialized for this problem is anotherresearch problem we 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 anotherresearch question to address in our future work. Thisdeals with more challenging problems related to modi-fying already deployed and operating system at runtimeto take benefit from the history of operation as a contin-uous process.

Acknowledgments This work has been partially funded by the EUCommission, through the ANIKETOS and FastFix projects and by Sci-ence Foundation Ireland grant 10/CE/I1855 to Lero—the Irish Soft-ware Engineering Research Centre (www.lero.ie). We also thank VitorE. Silva Souza for discussions that enriched the ideas of this paper.

References

1. Finkelstein, A., Savigni, A.: A Framework for requirements engi-neering for context-aware services. In: Proceedings of the 1st Inter-national Workshop From Software Requirements to Architectures(STRAW 01) (2001)

123

www.lero.ie


2. Yu, E.: Modelling strategic relationships for process reengineering.Ph.D. Thesis, University of Toronto (1995)

3. Bresciani, P., Perini, A., Giorgini, P., Giunchiglia, F., Mylopou-los, J.: Tropos: an agent-oriented software development methodol-ogy. Auton. Agents Multi-Agent Syst. 8(3), 203–236 (2004)

4. Castro, J., Kolp, M., Mylopoulos, J.: Towards requirements-driven information systems engineering: the tropos project. Inf.Syst. 27(6), 365–389 (2002)

5. Dardenne, A., van Lamsweerde, A., Fickas, S.: Goal-directedrequirements acquisition. Sci. Comput. Program. 20(1–2),3–50 (1993)

6. International Telecommunication Union (ITU-T): User Require-ments Notation (URN)—Language Definition. RecommendationZ.151 (11/08), Geneva, Switzerland (2008)

7. Mylopoulos, J., Chung, L., Yu, E.: From object-oriented to goal-oriented requirements analysis. Commun. ACM 42(1), 31–37(1999)

8. Fickas, S., Feather, M.: Requirements monitoring in dynamic envi-ronments. In: Proceedings of the 2nd IEEE International Sympo-sium on Requirements Engineering, pp. 140–147 (1995)

9. Sykes, D., Heaven, W., Magee, J., Kramer, J.: From goals to compo-nents: a combined approach to self-management. In: Proceedingsof the 2008 International Workshop on Software Engineering forAdaptive and Self-managing Systems, pp. 1–8 (2008)

10. Hui, B., Liaskos, S., Mylopoulos, J.: Requirements analysis forcustomizable software: a goals-skills-preferences framework. In:Proceedings of the 11th IEEE International Conference on Require-ments Engineering (RE’03), pp. 117–126 (2003)

11. Liaskos, S., McIlraith, S.A, Sohrabi, S., Mylopoulos, J.: Rep-resenting and reasoning about preferences in requirementsengineering. Requir. Eng. 16, 227–249 (2011). doi:10.1007/s00766-011-0129-9

12. Liaskos, S., McIlraith, S., Mylopoulos, J.: Representing and rea-soning with preference requirements using goals. Technical report,Dept. of Computer Science, University of Toronto (2006). ftp://ftp.cs.toronto.edu/pub/reports/csrg/542

13. Baresi, L., Pasquale, L., Spoletini, P.: Fuzzy goals for requirements-driven adaptation. In: The 18th IEEE International RequirementsEngineering Conference (RE), pp. 125–134, 27 Oct 2010 (2010)

14. Pourshahid, A., Amyot, D., Peyton, L., Ghanavati, S., Chen, P.,Weiss, M., Forster, A.: Business process management with theuser requirements notation. Electron. Commerce Res. 9, 269–316(2009). doi:10.1007/s10660-009-9039-z

15. Ali, R., Dalpiaz, F., Giorgini, P.: Location-based variability formobile information systems. In: Proceedings of the 20th Interna-tional Conference on Advanced Information Systems Engineer-ing (CAiSE’08). LNCS, vol. 5074, pp. 575–578. Springer, Berlin(2008)

16. Ali, R., Dalpiaz, F., Giorgini, P.: Location-based software mod-eling and analysis: tropos-based Approach. In: Proceedings of the27th International Conference on Conceptual Modeling (ER 2008).LNCS, vol. 5231, pp. 169–182. Springer, Berlin (2008)

17. Ali, R., Dalpiaz, F., Giorgini, P.: A goal modeling framework forself-contextualizable software. In: Proceedings of the 14th Inter-national Conference on Exploring Modeling Methods in SystemsAnalysis and Design (EMMSAD 2009). LNBIP, vol. 29, pp. 326–338. Springer, Berlin (2009)

18. Ali, R., Dalpiaz, F., Giorgini, P.: A goal-based frameworkfor contextual requirements modeling and analysis. Requir.Eng. 15(4), 439–458 (2010)

19. Ali, R., Dalpiaz, R., Giorgini, P.: Reasoning with contextualrequirements: detecting inconsistency and conflicts. Inf. Softw.Tech. (2012). doi:10.1016/j.infsof.2012.06.013

20. Ali, R., Dalpiaz, F., Giorgini, P.: Goal-based self-contextualization.In: Proceedings of the Forum of the 21st International Conference

on Advanced Information Systems (CAiSE 09-Forum), vol. 453,pp. 37–42. CEUR-WS (2009)

21. Lapouchnian, A., Yu, Y., Mylopoulos, J.: Requirements-drivendesign and configuration management of business processes. In:Proceedings of the 5th International Conference on Business Pro-cess Management (BPM 2007). LNCS, vol. 4714, pp. 246–261.Springer, Berlin (2007)

22. Rolland, C., Souveyet, C., Achour, C.B.: Guiding goal mod-eling using scenarios. IEEE Trans. Softw. Eng. 24(12), 1055–1071 (1998)

23. Liaskos, S., Lapouchnian, A., Yu, Y., Yu, E., Mylopoulos, J.: Ongoal-based variability acquisition and analysis. In: Proceedings ofthe 14th IEEE International Conference on Requirements Engi-neering (RE’06), pp. 76–85 (2006)

24. Henricksen, K., Indulska, J.: A software engineering frameworkfor context-aware pervasive computing. In: Proceedings of the 2ndIEEE International Conference on Pervasive Computing and Com-munications (PerCom’04), pp. 77–86 (2004)

25. Yau, S.S., Liu, J.: Hierarchical situation modeling and reasoning forpervasive computing. In: Proceedings of the 4th IEEE Workshopon Software Technologies for Future Embedded and UbiquitousSystems (SEUS’06), pp. 5–10 (2006)

26. Wang, X.H., Zhang, D.Q., Gu, T., Pung, H.K.: Ontology basedcontext modeling and reasoning using OWL. In: Proceedings ofthe 2nd IEEE Annual Conference on Pervasive Computing andCommunications Workshops, pp. 18–22 (2004)

27. Chaari, T., Ejigu, D., Laforest, F., Scuturici, V.-M.: A compre-hensive approach to model and use context for adapting applica-tions in pervasive environments. J. Syst. Softw. 80(12), 1973–1992(2007)

28. Salifu, M., Yu, Y., Nuseibeh, B.: Specifying monitoring and switch-ing problems in context. In: Proceedings of the 15th InternationalConference on Requirements Engineering (RE’07), pp. 211–220(2007)

29. Salifu, M., Nuseibeh, B., Rapanotti, L., Tun, T.T.: Using problemdescriptions to represent variabilities for context-aware applica-tions. In: Proceedings of the 1st International Workshop on Vari-ability Modelling of Software-Intensive Systems (VaMoS 2007),pp. 149–156 (2007)

30. Lapouchnian, A., Mylopoulos, J.: Modeling domain variability inrequirements engineering with contexts. In: Proceedings of the28th International Conference on Conceptual Modeling (ER 2009).LNCS, vol. 5829, pp. 115–130. Springer, Berlin (2009)

31. Cheng, B., Sawyer, P., Bencomo, N., Whittle, J.: A goal-basedmodeling approach to develop requirements of an adaptive sys-tem with environmental uncertainty. In: Model Driven EngineeringLanguages and Systems. LNCS, vol. 5795, pp. 468–483. Springer,Berlin (2009)

32. Amyot, D., Becha, H., Braek, R., Rossebo, J.E.Y.: Next generationservice engineering. In: Proceedings of the 1st ITU-T KaleidoscopeAcademic Conference on Innovations in NGN: Future Network andServices (K-INGN 2008), pp. 195–202 (2008)

33. Pohl, K., Böckle, G., van der Linden, F.: Software Prod-uct Line Engineering: Foundations, Principles, and Techniques.Springer, Berlin (2005)

34. Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: FORM:a feature-oriented reuse method with domain-specific referencearchitectures. Ann. Softw. Eng. 5, 143–168 (1998)

35. Hartmann, H., Trew, T.: Using feature diagrams with contextvariability to model multiple product lines for software supplychains. In: Proceedings of the 12th International Software ProductLine Conference (SPLC’08), pp. 12–21. IEEE Computer Society(2008)

36. Acher, M., Collet, P., Fleurey, F., Lahire, P., Moisan, S., Rigault,J.-P.: Modeling context and dynamic adaptations with feature mod-

123

http://dx.doi.org/10.1007/s00766-011-0129-9

http://dx.doi.org/10.1007/s00766-011-0129-9

ftp://ftp.cs.toronto.edu/pub/reports/csrg/542

ftp://ftp.cs.toronto.edu/pub/reports/csrg/542

http://dx.doi.org/10.1007/s10660-009-9039-z

http://dx.doi.org/10.1016/j.infsof.2012.06.013

456 R. Ali et al.

els. In: 4th International Workshop [email protected] (MRT’09)(2009)

37. Parra, C., Blanc, X., Duchien, L.: Context awareness for dynamicservice-oriented product lines. In: Proceedings of the 13thInternational Software Product Line Conference (SPLC’09), pp.131–140 (2009)

38. Yu, Y., do Prado Leite, J.C.S., Lapouchnian, A., Mylopoulos, J.:Configuring features with stakeholder goals. In: Proceedings ofthe 2008 ACM Symposium on Applied Computing (SAC’08), pp.645–649 (2008)

39. Ramachandran, M., Allen, P.: Commonality and variability anal-ysis in industrial practice for product line improvement. Softw.Process: Improvement Practice 10(1), 31–40 (2005)

40. Bagheri, E., Di Noia, T., Ragone, A., Gasevic, D.: Configuringsoftware product line feature models based on stakeholders’ softand hard requirements. In: Software Product Lines: Going Beyond.LNCS, vol. 6287, pp. 16-31. Springer, Berlin (2010)

41. Feather, M., Fickas, S., Van Lamsweerde, A., Ponsard, C.: Recon-ciling system requirements and runtime behavior. In: Proceedingsof the 9th International Workshop on Software Specification andDesign (IWSSD’98) (1998)

42. Cohen, D., Feather, M.S., Narayanaswamy, K., Fickas, S.S.: Auto-matic monitoring of software requirements. In: Proceedings of the19th International Conference on Software Engineering (ICSE’97),pp. 602–603 (1997)

43. Wang, Y., McIlraith, S., Yu, Y., Mylopoulos, J.: An automatedapproach to monitoring and diagnosing requirements. In: Proceed-ings of the 22nd IEEE/ACM International Conference on Auto-mated Software Engineering (ASE’07), pp. 293–302 (2007)

44. Giorgini, P., Mylopoulos, J., Nicchiarelli, E., Sebastiani, R.: Rea-soning with goal models. In: Proceedings of the 21st InternationalConference on Conceptual Modeling (ER’02), pp. 167–181 (2002)

45. Weiss, M., Amyot, D.: Business process modeling with urn. Int. J.E-Bus. Res. 1(3), 63–90 (2005)

46. Kronz, A.: Managing of process key performance indicators as partof the aris methodology. Corporate Performance Management, pp.31–44 (2006)

47. Pourshahid, A., Mussbacher, G., Amyot, D., Weiss, M.: Toward anaspect-oriented framework for business process improvement. Int.J. Electron. Bus. 8(3), 233–259 (2010)

48. Robertson, S., Robertson, J.: Reliable requirements through thequality gateway. In: Proceedings of the 10th International Work-shop on Database & Expert Systems Applications (DEXA’99), pp.357–363 (1999)

49. Robertson, S.: An early start to testing: how to test requirements.In: Proceedings of the EuroSTAR Conference (1996)

50. Bencomo, N., Whittle, J., Sawyer, P., Finkelstein, A., Letier, E.:Requirements reflection: requirements as runtime entities. In: Pro-ceedings of the 32nd ACM/IEEE International Conference on Soft-ware Engineering (ICSE 2010), pp. 199–202 (2010)

Author Biographies

Raian Ali is a lecturer in SoftwareSystems Engineering in the School ofDesign, Engineering and Computing atUniversity of Bournemouth, UK. Hereceived his Ph.D. degree in ComputerScience from the University of Tren-to, Italy (2006–2010) where he alsoworked as a post-doctorate researcher.Raian worked as a research fellow atLero—The Irish Software EngineeringResearch Centre, University of Limerick,Ireland (2011–2012). His research inter-

ests include requirements engineering, software engineering for adap-tive systems, software variability and product lines, security and privacyengineering, and social computing. Raian worked on several EU pro-jects, e.g., FastFix, ANIKETOS, and MEnSA projects. Raian servesas a reviewer for the International Requirements Engineering Journaland he is a program committee member of several international events(RESC, SCA, EMMSAD, RIGiM, DSPL, CSMR, and Requirements @runtime), and a chair of Social Software Engineering (SSE) workshop.

Fabiano Dalpiaz is a post-doctoralresearcher at the Department of Informa-tion Engineering and Computer Science,University of Trento (Italy). Previouslyhe obtained a Ph.D. from the same uni-versity (2006–2011). His main researchinterests lie in requirements engineering,conceptual modelling, and informationsystems engineering. Specific researchthreads include requirements-driven self-adaptive software, contextual require-ments engineering, open systems design,

and requirements modelling languages for secure, trustworthy, anddependable systems. He has participated in several regional, nationaland international research projects (PAT-Mostro, MIUR-Mensa, EU-IP-Serenity, EU-IP-Aniketos, ERC-Lucretius). He serves on the programcommittee of international conferences such as CAiSE and RCIS.

Paolo Giorgini is associate professorand head of the Software Engineering,Formal Methods and Security group atthe Department of Engineering and Com-puter Science of University of Trento. Hereceived his Ph.D. degree from the Com-puter Science Institute of University ofAncona, Italy (1998) and then he joinedthe University of Trento as assistant pro-fessor. He has worked on the develop-ment of requirements and design lan-guages, and the application of agent and

goal-oriented techniques to (security) software analysis. He is a co-founder of Tropos, an agent-oriented software engineering methodol-ogy co-editor in chief of the International Journal of Agent-OrientedSoftware Engineering (IJAOSE). His publication list includes morethan 180 refereed journal and conference proceedings papers and 12edited books. He has worked and coordinated a number of provin-cial, national and international research projects (e.g., PAT-Stamps,PAT-Mostro, MIUR-Mensa, EU-IP-Serenity, EU-STREP-Compas,EU-IP-Aniketos) and he has contributed to the organization of inter-national conferences as general chair, program chair and program com-mittee member, such as RE, ER, CAiSE, AAMAS, EUMAS, ICSOC,ACM-SAC.

123

Requirements-driven deployment

Documents

Transcript of Requirements-driven deployment