ieee transactions on software engineering, vol. x,no. … · the goal-obstacle analysis steps of...

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. X,NO. DAY, MONTH 2012 1

Systematic Elaboration of ScalabilityRequirements through Goal-Obstacle Analysis

Leticia DubocDept. of Computer Science

State University of Rio de JaneiroBrazil 20550 900

Email: [email protected]

Emmanuel LetierDept. of Computer ScienceUniversity College London

United Kingdom WC1E 6BTEmail: [email protected]

David S. RosenblumSchool of Computing

National University of SingaporeSingapore 117417

Email: [email protected]

F

Abstract—Scalability is a critical concern for many software systems.Despite the recognized importance of considering scalability from theearliest stages of development, there is currently little support for rea-soning about scalability at the requirements level. This paper presents agoal-oriented approach for eliciting, modeling and reasoning about scal-ability requirements. The approach consists of systematically identifyingscalability-related obstacles to the satisfaction of goals; assessing thelikelihood and severity of these obstacles; and generating new goalsto deal with them. The result is a consolidated set of requirements inwhich important scalability concerns are anticipated through the precise,quantified specification of scaling assumptions and scalability goals. Thepaper presents results from applying the approach to a complex, large-scale financial fraud detection system.

Index Terms—D.2.1 Requirements/Specifications, D.2.0.a Analysis,D.2.8.b Performance measures, D.2.10.h Quality analysis and evalua-tion, Goal-oriented requirements engineering, KAOS, Scalability

1 INTRODUCTION

S CALABILITY is widely regarded as one of the mostimportant qualities of software-intensive systems [1],

yet fundamental principles for developing scalable sys-tems are still poorly understood. As with other non-functional system qualities, a system’s ability to scaleis strongly dependent on decisions taken at the re-quirements and architecture levels [2], [3]. Failure toconsider scalability adequately in these stages may resultin systems that are impossible or too costly to change ifscalability problems become apparent during testing orsystem usage.

Current technologies, such as virtualization and cloudcomputing, may help to achieve scalability in softwaresystems. However, a system whose architecture fails tosupport some of its scalability goals cannot be madescalable simply by employing virtualization and cloudsfor its implementation. In order to take advantage ofthese technologies, one must understand and define thesystem’s scalability goals precisely. An a priori analysisof scalability goals prevents system analysts from beingcaught prematurely into discussions about technology

and gives them more freedom to explore, negotiate andfulfill these goals. There is therefore a strong need forsystematic techniques to reason about scalability duringthe early stages of development.

In our previous studies of scalability, we defined scala-bility as the ability of a system to maintain the satisfaction ofits quality goals to levels that are acceptable to its stakeholderswhen characteristics of the application domain and the systemdesign vary over expected operational ranges [4]. A system’sscalability is therefore relative to other primary qualitygoals for the system. For example, the scalability of aWeb search engine may be characterized by its abilityto return search results in a time that remains almostinstantaneous (a performance goal) when the numberof simultaneous queries and the number of pages in-dexed increase. Scalability, however, is not limited toperformance goals. The scalability of an air traffic controlsystem may be characterized by its ability to keep safeseparation distances between airplanes (a safety goal)when the number of airplanes in the airspace managedby the system increases. One should note that, as illus-trated by the latter example, scalability is not limited toperformance goals. Performance is only one of the manypossible indicators of scalability; there are others such asare reliability, availability, dependability and security [4].

Defining the scalability requirements of a complexsystem is not trivial. Many issues arise during theirelaboration [5]:• how to specify scalability requirements that are

precise and testable so that they provide adequateinputs for architectural design and analysis;

• how to identify and manage scalability-related risksearly in the development process, and in particularhow to make sure one has identified all applicationdomain quantities whose variations could have animpact on the system’s scalability;

• how to deal with the inevitable unknowns, uncer-tainties and disagreements about expected ranges ofvariations for these domain quantities;


• how to ensure that the specified scalability require-ments are neither too strong nor too weak withrespect to business goals, to expected ranges of vari-ations in the application domain, and to capabilitiesof current technologies; and

• how to find adequate tradeoffs between scalabilityrequirements and other qualities, in particular thoserelated to cost and development time.

Existing requirements engineering techniques providelittle concrete support to address these specific issues.User stories and use-case based approaches to require-ments engineering overlook scalability concerns andother non-functional requirements altogether. A few in-dustry white papers provide high-level guidelines forwriting quantifiable scalability requirements, but no pre-cise foundations nor any guidance to deal with theabove issues [6], [7]. Goal-oriented approaches such asKAOS [8], i* [8] [9], and Problem Frames [10] providegeneric support for elaborating, structuring and analyz-ing software requirements, including both functional andnon-functional requirements, but no specific support todeal with scalability concerns. A rudimentary applica-tion of a goal-oriented approach that would consist of,say, specifying a high-level goal named Scalable Systemand gradually refining it into more precise requirementsis not satisfying because of the lack of a precise definitionfor the scalability goal and the lack of support forrefining it into testable scalability requirements.

Dedicated requirements engineering techniques existfor other important categories of non-functional require-ments such as safety [11], [12] and security [13], [14], [15];however, up to now no specific attention has been givento scalability requirements. Surprisingly, scalability is noteven included in some taxonomies of non-functionalrequirements in industrial standards or in the softwareengineering literature [8], [16], [17], [18], [19]. As a con-sequence, scalability requirements are often overlookedor defined in vague terms at best [5].

This paper presents a systematic method for elab-orating and analyzing scalability requirements, and itpresents the results of a case study in which we appliedthe method to a complex, large-scale financial frauddetection system. The method has been formulated inthe context of the KAOS goal-oriented requirementsengineering method [8], and it relies on KAOS for theelaboration of goal models, for managing conflicts be-tween goals, and for evaluating and selecting amongalternative system designs. We extend the conceptualframework of KAOS with precise characterizations ofthe concepts of scalability goals, scalability requirements andscaling assumptions that are essential for reasoning aboutscalability at the requirements level. We also extend theKAOS model elaboration process with concrete supportfor elaborating and analyzing such concepts.

Our approach deals with scalability concerns duringthe goal-obstacle analysis steps of the goal-oriented elab-oration process [20]. The basic idea consists in system-atically identifying and resolving potential variations

in domain quantities that will cause goals to fail; wewill define such conditions as scalability obstacles. Theaim of a scalability obstacle analysis is to anticipatescalability related risks at requirements elaboration time,when there is more freedom for finding adequate waysto deal with them, rather than discovering them duringsystem development or, worse, experiencing unantici-pated scalability failures at runtime. Existing obstacleanalysis techniques [20] are not sufficient for handlingscalability obstacles because they support only genericanalyses in which the specifics of scalability obstacles arenot considered. As a result, scalability obstacles are likelyto be overlooked during obstacle identification (as theywere, for example, in a previous obstacle analysis of theLondon Ambulance Service case study [20]). We presentnew, more specific heuristics, formal patterns, and Eventhough, we recognize the potential of virtualization andcloud for achieving scalabilitymodel transformation tacticsfor identifying and resolving scalability obstacles.

2 BACKGROUND

2.1 The Intelligent Enterprise Framework

Our presentation relies on examples of a real-worldsystem, Searchspace’s Intelligent Enterprise Framework(IEF), that we used to develop and validate our tech-niques.

IEF is a platform used by banks and other financialinstitutions for processing large volumes of financialtransaction data, and notifying users (such as bank em-ployees) of potentially fraudulent behavior within thedata. IEF has important scalability requirements due tothe recent widespread consolidation in the banking andfinance sector. The rate of electronic transactions hasincreased dramatically, analytical methods have becomemore complex, and system performance expectationshave become higher. Over the last 10 years, the numberof installations of the company’s software went from ahandful of deployments in a small number of countriesto many hundreds of deployments, spread worldwide.The volume of data processed increased from a singledeployment peak of about 3 million transactions per dayto over 90 million transactions for a recent deployment,coupled with an increase in the complexity of the pro-cessing performed.

The system uses a number of analytical methods forrecognizing fraudulent transactions. For simplicity, weconsider here only the comparison of transactions de-livered by a bank against known fraudulent patterns,which may be done continuously or overnight. In theformer, transactions are streamed by the bank systeminto the IEF and processed as soon as they arrive. Inthe latter, transactions are provided periodically andprocessed in data batches. The choice of approach de-pends on the type of fraud being addressed and theupstream banking processes. Alerts about potentiallyfraudulent transactions are generated by the IEF and


then investigated by the bank, which will dismiss orconfirm the frauds and then take appropriate measures.

2.2 Goal-Oriented Requirements Engineering

Goal orientation is a paradigm for the elicitation, evalu-ation, elaboration, structuring, documentation and anal-ysis of software requirements. The KAOS approach iscomposed of a modeling language and a constructiveelaboration method supported by informal heuristicsand formal techniques [8]. The modeling language com-bines multiple system views for modeling goals, do-main objects, agents and their responsibilities, agentoperations, and system behaviors through scenarios andstate machines. The method consists of a series of stepsfor elaborating and analyzing the different views. Inthis section, we focus on presenting the key conceptsthat are used in the paper. Further details about theKAOS modeling language and elaboration method canbe found in Lamsweerde’s book [8].

A goal is a prescriptive statement of intent that asystem should satisfy through the cooperation of agents.Agents are active system components, such as humans,hardware devices and software components, that arecapable of performing operations that modify systemstate in order to satisfy goals. The word system refers tothe composition of the software under development andits environment. Goals range from high-level businessobjectives whose satisfaction involves multiple agents(such as minimizing loss due to financial fraud, andmaintaining the bank’s reputation, etc.), to fine-grainedtechnical properties involving fewer agents (such asprocessing all transaction batches within eight hours).Unlike goals that are prescriptive, domain properties aredescriptive statements that are always true in the appli-cation domain, irrespective of agents’ behaviors. Physicallaws are typical examples of domain properties. Do-main hypotheses are also descriptive statements about theapplication domain, but unlike domain properties areconsidered to be more uncertain and subject to change.

In a goal model, goals are organized in AND/OR re-finement structures. An AND-refinement relates a goal toa set of subgoals; this means that satisfying all subgoalsin the refinement is a sufficient condition in the domainfor satisfying the goal. OR-refinement links relate a goalto a set of alternative AND-refinements; this means thateach AND-refinement represents an alternative way tosatisfy the parent goal.

The KAOS elaboration process consists in constructinga system’s goal model both top-down (by asking HOWquestions to refine goals into subgoals) and bottom-up(by asking WHY questions to identify parent goals).During the goal refinement process, goals are decom-posed into subgoals so that each subgoal requires thecooperation of fewer agents for its satisfaction; the refine-ment process stops when it reaches subgoals that can beassigned as the responsibility of single agents. In orderto be assignable to an agent, a goal must be realizable

Fig. 1. Partial Model for a Previous Version of the IEF [5].

by the agent. Realizability here is a formal conditionrequiring that the goal definition corresponds to a transi-tion relation between the agent’s monitored variables (itsinput) and controlled variables (its internal and outputvariables) [21]. A goal assigned to the software underdevelopment is called a software requirement. A goal as-signed to an agent in the environment is called a domainexpectation. The term domain assumption is used to referto both domain expectations and domain hypotheses.

As an example, Figure 1 shows a portion of the goalmodel we have elaborated for a previous version of theIEF system that supported batch processing only [5].Graphically, goals are depicted as parallelograms, andAND-refinement links are represented as arrows fromsubgoals to a parent goal. Agents are depicted ashexagons, and a link between an agent and a goal meansthat the agent is responsible for the goal. The top of thefigure shows three stakeholders’ goals for this system,namely Avoid [Loss Due to Fraud], Maintain [Bank Reputation], andAvoid [Inconvenience to Account Holder]. The goal Achieve [FraudDetected and Resolved] contributes to these three goals and isrefined into the goal Achieve [Alerts Generated] requiring thatfraud alerts be generated for potentially fraudulent banktransactions, and the expectation Achieve [Alerts Investigatedand Acted Upon Quickly], under the responsibility of a humanFraud Investigator, requiring that generated alerts either beconfirmed as fraudulent and resolved, or cleared as falsealerts. The goal Achieve [Alerts Generated] is itself refinedinto an expectation on the Bank System to provide thebatches of transactions data, and a requirement on theAlert Generator software component to process the batchesof transactions overnight.

2.3 Specifying Goals

Each goal has a specification including its pattern (e.g.,Achieve, Maintain, Avoid), name and natural language defini-tion. A goal also may be specified as belonging to oneor more categories (e.g., functional, performance, safety)


and be given an optional formal definition expressed inMetric Linear Temporal Logic [22], which is used todisambiguate natural language definitions and to allowautomated reasoning on goal models. In this paper, wewill use the following standard temporal logic operators:

�P (P is true in all future states)

♦P (P is true in some future state)

♦≤dP (P holds in some future state that is lessthan d time units from the current state)

The natural language and formal definitions of a goaldefine what it means for the goal to be satisfied inan absolute sense. Partial levels of goal satisfaction arespecified by extending goal specifications with domain-specific quality variables and objective functions [23]. Math-ematically, quality variables correspond to probabilisticrandom variables. The specification of objective func-tions and quality variables extends the goal model witha probabilistic layer that can be used to compute theimpact of alternative goal refinements and responsibilityassignments on the degrees of goal satisfaction.

As an example, the goal Achieve [Batch Processed Overnight]has the following specification.

Goal Achieve [Batch Processed Overnight]

Category Performance goal

Definition Batches of bank transactions provided by the banksystem should be processed in less than 8 hours. Processingconsists in generating alerts about transactions in the batch thatmatch known fraudulent patterns stored in the system.

Formal Spec (∀ b:Batch)� (EndOfDay ∧ b.Submitted→ ♦ ≤8hours b.Processed)

Quality Variable: procTime: Batch→ TimeDefinition The time to process the full batch of transactions afterthe end of the day;Sample Space The set of daily batches of bank transactionssubmitted by the bank system.

Objective Functions At least 9 out of 10 batches should beprocessed within 8 hours, and all batches should be processedwithin 9.6 hours.

Name Definition Target

% of Batches Processed Pr(procTime ≤ 8h) 90%

in 8 hours

% of Batches Processed Pr(procTime ≤ 9.6h) 100%

in 9.6 hours

Responsibility Alert Generator

The natural language and formal definitions state thatthis goal is satisfied in an absolute sense if every batchof transactions submitted to the IEF is processed in lessthan 8 hours. The quality variable procTime is a randomvariable whose sample space is the set of daily batchessubmitted to the IEF and whose value denotes the timeto process a batch. The first objective function statesthat the system should be designed to maximize theprobability that a batch is processed in less than 8 hours.

Fig. 2. Obstacles to the Expectation Achieve [Transac-tions Submitted in Daily Batches].

The final column specifies the target to be achievedfor each objective function; at least 90% of the batchesshould be processed within 8 hours, and there is atolerance of 20% in the processing time (i.e., 9.6 hours)for the remaining batches. The goal is assigned to theAlert Gnerator agent, a subsystem of the IEF.

2.4 Goal-Obstacle AnalysisGoals, requirements and assumptions elaborated duringa requirements elaboration process are often too idealbecause they fail to take into consideration exceptionalconditions in the application domain that may violatethem. The principle of obstacle analysis is to take apessimistic view of the model elaborated so far bysystematically considering how the actual system mightdeviate from the model.

An obstacle to some goal is an exceptional conditionthat prevents the goal from being satisfied [20], [24]. Anobstacle O is said to obstruct a goal G in some domaincharacterized by a set of domain properties Dom if, andonly if:• the obstacle entails the negation of the goal in the

domain (i.e., O,Dom � ¬G); and• the obstacle is not inconsistent in the domain (i.e.,

Dom 2 ¬O)Graphically, obstacles are depicted as “reverse” par-

allelograms and related to the goals they obstruct by“negated” arrows. Obstacles can be refined into sub-obstacles. The resulting model correspond to a goal-anchored form of risk model. For example, Figure 2shows the obstacle Daily Transactions Batch Not Submittedobstructing the goal Achieve [Transactions Submitted in DailyBatches] and its OR-refinement into sub-obstacles No BatchSubmitted, Submitted Batch is Corrupted and Wrong Batch Submitted.

Starting from an idealized goal model, a goal-obstacleanalysis consists of

1) identifying as many obstacles as possible by system-atically considering all leaf goals and assumptionsin the goal graph;

2) assessing the relative importance of the identifiedobstacles in terms of their likelihood and impactson top-level goals;


3) resolving the more critical obstacles by modifyingexisting goals, requirements and assumptions, orby introducing new ones so as to prevent, reduceor tolerate the obstacles.

For example, having identified the obstacle that theBank System could provide a corrupted batch of transac-tions will generate additional requirements on the AlertGenerator. This identify-assess-resolve loop is repeateduntil all remaining obstacles are considered acceptablewithout further resolution.

3 SPECIFYING SCALABILITY REQUIREMENTS

According to our definition of scalability, the elementsrequired to define what it means for a system to bescalable are (1) the quality goals of the system; (2) thecharacteristics of the application domain and systemdesign that are expected to vary, and their ranges; and(3) the acceptable levels of quality goal satisfaction underthese variations. In the KAOS framework, these elementscan be represented as follows:

1) Quality goals correspond to goals whose specifi-cation includes domain-dependent objective func-tions.

2) Expected variations of characteristics in the appli-cation domain correspond to a new kind of domainassumption that we call a scaling assumption.

3) The acceptable levels of quality goal satisfactionunder these variations are specified as target valuesfor the quality goal objective functions. We referto quality goals that are constrained by scalingassumptions as scalability goals.

Note that, even though scalability is highly influencedby the system design and implementation, goals andassumptions related to scalability should be describedin terms of domain phenomena only and should notrefer to design or implementation concerns. Goals willimpose constraints on the system design by makingreference to assumptions about variations in the domain.Stating the constraints in terms of domain phenomenanot only avoids over-specification, but also gives systemdesigners more freedom in choosing the design that willsatisfy these goals best. We describe these elements andtheir roles in more detail in the following sections.

3.1 Specifying Scaling AssumptionsWe define a scaling assumption as a domain assumptionspecifying how certain characteristics in the applicationdomain are expected to vary over time and across de-ployment environments. The latter dimension is espe-cially important in the context of product families. Thespecification of scaling assumptions should therefore bedefined in terms of the following items:

1) one or more domain quantities whose expected vari-ations are defined in the assumption;

2) the periods of time and classes of system instances overwhich the assumption is defined; and

3) the range of values each quantity is expected toassume for each system class over each period oftime.

For example, the scaling assumption Expected Batch SizeEvolution presented below specifies how the number oftransactions in daily batches submitted to the IEF isexpected to vary over time and for banks categories.Assumption Expected Batch Size EvolutionCategory Scaling assumptionDefinition From 2011 to 2015, daily batches are expected to contain upto the following numbers of transactions for different bank categories:1

Bank 2011 until 2013 until 2015

small 10,000 15,000 20,000

medium 1 million 1.2 million 1.8 million

large 50 million 55 million 60 million

merger 80 million 85 million 95 million

Our definition of scaling assumption covers the casewhere variations of domain quantities refer to a singleperiod of time and a unique class of system instances.For example, an alternative, simpler scaling assumptionon the batch size could be the following:

Assumption Expected Batch Size EvolutionCategory Scaling assumptionDefinition Over the next five years, daily batches of transactions for allbanks are expected to vary between 10,000 and 95 million transactions.

Following the KAOS classification of properties (Sec-tion 2.2), a scaling assumption could either be a descrip-tive scaling hypothesis, in which case the assumption isassumed to hold without being prescribed on any systemagent, or a prescriptive scaling expectation, in which casesome agent would be expected to restrict its behaviorso as to ensure that the scaling assumption is satisfied.Scaling assumptions are not, however, software require-ments, as they describe properties that are assumed tobe true in the application domain rather than propertiesthat must be enforced by the software-to-be.

Scaling assumptions can be specified with varyinglevels of precision. For some systems, specifying ordersof magnitude for some of the domain quantities may besufficient to inform the early design decisions adequatelyat the requirements and software architecture levels. Forothers, one may need more precise figures, such as theones in the above examples. In some cases, it may beuseful to distinguish between the average and peakvalues of some of the domain quantities. The specifi-cation of a scaling assumption might even refer to thefull probability distribution of a domain quantity underconsideration (e.g., the distribution of the number oftransactions in daily batches and the expected evolutionin the distribution’s parameters or moments over time).

The ranges of values referenced in scaling assumptionsmust be elicited and negotiated with project stakehold-

1. These numbers are fictitious and used for illustration only.


ers. These may be obtained by analyzing characteristicsof the existing system, extrapolating characteristics fromrelated systems, making predictions about future sys-tem evolutions, and eliciting and negotiating the rangeswith stakeholders. A variety of requirements elicitationtechniques is available to support such activities [8].Applying such techniques to elicit these numbers ofcourse remains difficult, due to uncertainties about fu-ture behaviors and divergences of opinion among sys-tem stakeholders. But surfacing the uncertainties anddivergences explicitly during requirements elaboration isessential to an adequate analysis of a system’s scalabil-ity requirements. A systematic approach for identifyingwhat scaling assumptions need to be elicited, such as thescalability obstacle analysis technique to be described inSection 4, greatly facilitates this process.

A key feature of our approach is that the valuesto be estimated in scaling assumptions denote measur-able, domain-specific quantities whose validity eventu-ally can be checked in the running system. This contrastswith other quantitative techniques for specifying non-functional requirements that rely on estimating sub-jective quantities that have no domain specific mean-ing [25], [26], [27], [28], [29] and can therefore never bevalidated empirically.

3.2 The Role of Scaling Assumptions

Like other kinds of domain assumptions, scaling as-sumptions support the refinement of goals towards re-quirements and expectations that can be satisfied by asingle agent [8], [30]. Semantically, scaling assumptionsexpress constraints on the ranges of values that domainquantities are expected to assume over specified timeperiods and classes of system instances. Logically, theabsence of a scaling assumption for a domain quantitymeans that there is no assumed constraint on its possiblevalues; that is, its value at any point in time potentiallycould be infinite.

To illustrate this, consider again the goal Achieve [BatchProcessed Overnight] in Section 2.3. In Figure 1, we hadassigned that goal as the responsibility of the AlertGenerator agent. The goal is indeed realizable by theagent, as it is defined entirely in terms of quantities thatare monitored and controlled by that agent. Realizabilityimplicitly assumes that agents have infinite resourcecapacities to perform the operations required to satisfytheir goals. In practice, however, all agents have finitecapacities that may be insufficient for satisfying thegoal—a form of scalability obstacle. In this example, itwill be impossible for the Alert Generator to guarantee thesatisfaction of the goal for any size of daily batches tobe processed. To obtain a goal whose satisfaction can beguaranteed by the Alert Generator alone, the goal Achieve[Batch Processed Overnight] needs to be refined into a scalingassumption on the size of daily batches, such as one ofthose given in the previous section, and a goal requiringdaily batches to be processed within 8 hours only for

batches satisfying the scaling assumption. Using the scalingassumption Expected Batch Size Evolution in Section 3.1, weobtain the following subgoal:

Goal Achieve [Batch Processed Overnight Under Expected BatchSize Evolution]Category Performance goal, scalability goalDefinition At the end of each day, the batch of transactions submittedby the bank should be processed in less than 8 hours, provided thatthe batch size does not exceed the bounds stated in the scaling as-sumption ‘Expected Batch Size Evolution’.

This goal can now be satisfied by an Alert Generator withsufficiently large but nevertheless finite capacities (i.e.,finite processing speed, memory and storage capacities).

3.3 Specifying Scalability Goals

We define a scalability goal as a goal whose definitionand required levels of goal satisfaction (as specified byits objective functions) make explicit reference to one ormore scaling assumptions. The goal Achieve [Batch ProcessedOvernight Under Expected Batch Size Evolution] is a scalabilitygoal because its definition refers to the scaling assump-tion Expected Batch Size Evolution.

Our definition is consciously in opposition with a com-mon intuition about scalability that consists of viewinga system as scalable if it can handle any increased work-load in a cost-effective way [31]. In this more commonview, the satisfaction of a scalability goal should not berestricted to bounds explicitly stated in scaling assump-tions. Our definition, in contrast, takes the view thatexpected variations of relevant domain characteristicsshould always be stated explicitly in order to adequatelyinform a cost-effective design strategy.

The specification of a scalability goal involves describ-ing how the required level of goal satisfaction is allowedto vary when domain characteristics vary within thebounds specified in scaling assumptions. This goal speci-fication takes different forms, depending on whether thegoal satisfaction level is required to stay the same oris allowed to vary for different values of the domaincharacteristics. For example, for an air traffic controlsystem, the required safety level would remain the samewhen the number of airplanes simultaneously presentin a region increases, whereas for an online store, onemay accept system performance to slow as the numberof simultaneous requests increases.

• A scalability goal with fixed objectives is one in whichthe same level of goal satisfaction must be main-tained under the full range of variations specified inthe scaling assumptions. These are goals for whichthe goal definition, objective functions and targetvalues are the same across the whole range of valuesconsidered in the scaling assumptions.

• A scalability goal with varying objectives is a scalabilitygoal whose required level of goal satisfaction is not


the same under the whole range of variations spec-ified in the scaling assumptions. Their goal defini-tion, objective functions definitions, or target valuesare different across the range of values consideredin the scaling assumptions.

Scalability goals also can be extended to specify grace-ful degradation of goal satisfaction when the systemoperates outside its nominal scaling range. This can bedone by specifying additional scaling assumptions, oradditional scaling ranges within scaling assumptions,characterizing possible values for the domain charac-teristics outside of the initial scaling assumptions thatthe system must still be able to react to. More than onelevel of degradation could be specified if needed. Suchconcerns for handling such cases are typically handledduring the obstacle analysis steps of the goal-orientedrequirements elaboration process that will be presentedin Section 4.

Finally, scalability goals can be specified at differentlevels in the goal refinement graph. Following the KAOSdefinitions, a scalability requirement is a scalability goalassigned to an agent in the software-to-be.

4 SCALABILITY OBSTACLE ANALYSIS

This section describes the process of elaborating require-ments models that include specifications of scalabilitygoals and scaling assumptions.

As mentioned earlier, what it means for a system to bescalable is relative to other quality goals for the system.Identifying the primary quality goals of a system istherefore a prerequisite to the precise specification of itsscalability goals. Our process for analyzing a system’sscalability and elaborating scalability goals assumes thatthe other functional and quality goals of the system havebeen elaborated following a systematic goal-orientedrequirements elaboration process [8].

As was illustrated in Section 3.2, during incrementalelaboration of requirements models, initial specificationof goals and assignments of goals to agents are typicallyidealized, in the sense that they are generally elaboratedwithout explicit considerations for the scaling character-istics in the application domain and the limited capaci-ties of agents for fulfilling the goals assigned to them.

Starting from idealized goals and goal assignments isbeneficial as it avoids premature compromises based onimplicit and possibly incorrect perceptions of what mightbe possible to achieve [32]. However, later on in therequirements elaboration process, it is necessary to takeinto account what can be achieved realistically by thesystem agents and, if needed, modify the specificationsof goals, requirements and expectations accordingly.

Therefore, a natural way to deal with scalability dur-ing requirements elaboration consists of handling scala-bility concerns during the goal-obstacle analysis steps ofthe goal-oriented method. Starting from an initial goalmodel, our process for elaborating scalability require-ments consists of the following activities:

1) systematically identifying scalability obstacles thatmay obstruct the satisfaction of the goals, require-ments and expectations elaborated so far;

2) assessing the likelihood and criticality of those ob-stacles; and

3) resolving the obstacles by modifying existing goals,requirements and expectations, or generating newones so as to prevent, reduce or mitigate the obsta-cles.

The resolution of scalability obstacles leads to the iden-tification of scaling assumptions and scalability goalsintroduced in the previous section.

4.1 Identifying Scalability Obstacles

We define a scalability obstacle to some goal G as acondition that prevents the goal from being satisfiedwhen the load imposed by the goal on agents involvedin its satisfaction exceeds the capacity of the agents.

In this definition, we define the concepts of goal loadand agent capacity to denote domain-specific measuresintended to characterize the amount of work needed tosatisfy the goal and the amount of resources availableto the agent to satisfy the goal, respectively. To identifyconcrete scalability obstacles, one must instantiate theseconcepts to domain-specific measures appropriate to thegoals and agents under consideration.

This definition suggests the following heuristic foridentifying a scalability obstacle from a goal: for each goal,identify what defines the goal load, what agent resources areinvolved in its satisfaction, and consider an obstacle of theform Goal Load Exceeds Agent Capacity. This heuristic extendsthe existing catalog of obstacle generation heuristicsin [8], [20].

For example, consider again the goal Achieve [BatchProcessed Overnight] assigned to the Alert Generator agent. Thegoal load in this case is the number of transactions inthe batches to be processed, and the agent capacity isthe Alert Generator’s throughput measured as the numberof transactions it can process per second. A scalabilityobstacle to this goal is therefore the condition BatchSize Exceeds Alert Generator Processing Speed. This obstacle’sname, which refers to a goal load and agent capacityexpressed in different units, is extended with a moreprecise obstacle definition, namely that the batch sizeexceeds the number of transactions that can be processedovernight given the alert generator’s throughput, thuscomparing terms expressed in the same unit.

As another example, consider in Figure 1 the goalAchieve [Alerts Investigated and Acted Upon Quickly] assigned tohuman Fraud Investigators. This goal requires every gener-ated alert either to be confirmed and resolved or to becleared by a fraud investigator within a day of the alertbeing generated. The goal load in this case is the numberof alerts generated per day, while the agent capacity isthe number of alerts the team of fraud investigators isable to investigate per day. The scalability obstacle tothis goal is Number of Alerts Exceeds Fraud Investigators Capacity.


In general, a scalability obstacle can be an obstacleto a goal residing at any level in the goal refinementstructure. For example, for an air traffic control system,a scalability obstacle to the high-level goal Maintain [SafeAirplane Separation] would be the condition Number of Airplanesin Region Exceeds System Capacity. However, as for standardgoal-obstacle analysis, we found it preferable to generatescalability obstacles from terminal goals because thisgenerates more specific obstacles whose likelihoods areeasier to assess and for which more specific obstacleresolutions can be envisaged.

4.1.1 Formal Patterns of Scalability ObstructionIn addition to informal heuristics, the existing obstacleanalysis method relies on a catalog of formal obstructionpatterns for identifying obstacles from goals [20]. Thesepatterns provide a formal and more precise character-ization of the informal heuristics. Two formal patternscorresponding to the above heuristics are shown inTable 1. The first pattern considers goals of the form�P , which do not refer to a scaling assumption; thesecond pattern is defined for scalability goals of theform � (SA → P ), where SA is the condition definedin a scaling assumption on the goal load. In both cases,the identification of the scalability obstacle relies on adomain property � (P → LoadG ≤ CapacityAg) statingthat P can be true only if the goal load does not exceedthe agent capacity. The identified scalability obstacleshave the form shown in the last column of the table.The first obstacle states that eventually the goal loadexceeds the agent capacity. The second one states thatdespite the values of domain quantities being within theranges defined in the scaling assumption, eventually thegoal load exceeds the agent capacity. Note that thesepatterns require that the goal load and agent capacitybe expressed in or converted to the same units.

4.1.2 Scalability Obstacles to Multiple GoalsWhen identifying scalability obstacles, it is not suffi-cient to consider obstacles to each goal in isolation.There might be situations where an agent’s capacity issufficient to satisfy each of its goals in isolation, butinsufficient when having to satisfy all goals together.

This can be characterized formally by the obstruc-tion pattern shown in Table 2. Consider a set of goalsG1, . . . , Gn assigned to an agent Ag and involving fortheir satisfaction the same agent resource AgRes. As-suming a domain property saying that the agent’s ca-pacity must always be bigger than the sum of thegoals’ loads in order for the goals to be satisfied, thatis, G1 ∧ . . . ∧ Gn → � (LoadG1 + . . . + LoadGn ≤ M),then a scalability obstacle to the combined set of goalsG1, . . . , Gn is the obstacle ♦ (LoadG1

+ . . .+LoadGn> M).

That is, the scalability obstacle is a condition O such thatO,Dom ` ¬ (G1 ∧ . . . ∧Gn).

This pattern relies on the simplifying assumption thatall goal load measures are expressed in the same unitand that the total load imposed by the goals is the

sum of the load of the individual goals, but it canbe generalized easily to a situation where the domainproperty involves any monotonically increasing functionF (LoadG1

, . . . ,LoadGn) instead of simple addition. When

n = 1, this pattern is equivalent to the first obstructionpattern to a single goal in Table 1.

To illustrate this pattern, consider the Data Store agentand the two goals Maintain [Transactions Data Stored] and Main-tain [Alerts Data Stored] under its responsibility in Figure 3.Note that Figure 3 is a responsibility diagram—a diagramshowing an agent and a set of goals it is responsiblefor [8]—that has been extended with a scalability obsta-cle obtained by the application of this pattern.

Fig. 3. Scalability Obstacle to Multiple Goals.

In this example, the load for each goal is the sizeof the transaction data and alert data to be stored,respectively; both goals involve the Data Store’s storageresource for their satisfaction, and a necessary conditionfor both goals to be satisfied is that the sum of thetransaction data and alert data does not exceed the DataStore’s storage capacity. An application of the patterngenerates the scalability obstacle Transactions and Alerts DataExceeds Storage Capacity. Note that the strict application ofthe pattern for single goals described in the beginningof this section would have generated two obstacles,Transactions Data Exceeds Storage Capacity and Alerts Data ExceedsStorage Capacity. However, the logical conjunction of thesetwo obstacles is not equivalent to the joined obstacleTransactions and Alerts Data Exceeds Storage Capacity.

The pattern of scalability obstruction to multiple goalssuggests the following heuristic procedure for the sys-tematic identification of scalability obstacles from goals:

For each agent,

1) identify the set of all goals assigned to the agent;2) for each goal, identify what defines the goal load

and what agent resources are involved in its satis-faction;

3) for each agent resource Resi identified in step 2,take all goals G1, . . . , Gn requiring this resourceand consider a scalability obstacle of the form♦ (LoadG1

+ . . . + LoadGn> M) obstructing these

goals, where M is the minimum value of the agentresource needed to satisfy all goals together.


TABLE 1Scalability Obstruction Patterns

Goal Domain Property ObstacleG : �P � (P → LoadG ≤ CapacityAg) ♦ (LoadG > CapacityAg)

G : � (SA→ P ) � (P → LoadG ≤ CapacityAg) ♦ (SA ∧ LoadG > CapacityAg)

TABLE 2Pattern of Scalability Obstruction to Multiple Goals

Goals Domain Property ObstacleG1, . . . , Gn G1 ∧ . . . ∧Gn → � (LoadG1

+ . . .+ LoadGn ≤ CapacityAg) ♦ (LoadG1+ . . .+ LoadGn ) > CapacityAg

4.2 Assessing Scalability ObstaclesOnce potential scalability obstacles have been identified,their criticality and likelihood should be assessed. Asfor other kinds of obstacles, the criticality of a scalabilityobstacle depends on its impact on higher-level goals andthe importance of those goals.

A lightweight technique to support this process con-sists of using a standard qualitative risk analysis matrix inwhich the likelihood of a scalability obstacle is estimatedon a qualitative scale from Very Unlikely to Almost Certainand its criticality estimated on a scale from Insignificantto Catastrophic [8]. The goal refinement graph helps inestimating obstacle criticality by allowing one to followgoal-refinement links upward to identify all high-levelgoals affected by an obstacle.

If there exists a quantitative goal model relating qual-ity variables on software requirements and domain ex-pectations to higher-level goals [23], then this modelcan be used to perform a more detailed quantitativeanalysis of the impact of obstacles on higher-level goals.However, developing such quantitative models requiresmore effort, and a detailed quantitative analysis is notalways needed, as the main objective of the obstacleassessment step is to separate scalability obstacles forwhich resolutions need to be sought from those whoserisk is so low that they can safely be ignored.

4.3 Resolving Scalability ObstaclesScalability obstacles whose combined likelihood and crit-icality are considered serious enough must be resolved.The obstacle resolution process comprises two activities:the generation of alternative resolutions and the selectionof resolutions among generated alternatives. Only thegeneration step is considered here; the selection amongalternatives can be performed using qualitative or quan-titative techniques covered elsewhere [8], [18], [23].

Ideally, obstacle resolutions should be defined inde-pendently of any technology adopted to develop thesystem. Doing so allows the requirements analyst toexplore a broader range of resolutions and to negotiategoals with the stakeholders. For example, the resolutionadapt agent capacity at runtime according to load, described

in Section 4.3.3, predicts the future value of the goal loadat runtime and adjusts the agent capacity accordingly.Later in the development lifecycle, this resolution couldbe implemented using, say, a cloud, in which the agentswould be deployed as cloud-based services that can bereplicated to support a growing load. It is importantto note, however, that the decision of which agentswould be cloud-based and which requirements theywould be responsible for is a subsequent activity to ourmethod and should not be considered in the generationof alternative resolutions described in this section.

In Kaos, obstacle resolution tactics are model transfor-mation operators that resolve an obstacle by introduc-ing new goals, assumptions, and responsibility assign-ments in the model, or by modifying existing ones. Wehave extended the existing catalog of obstacle resolutiontactics [20] with new, specialized tactics to deal withscalability obstacles. Our tactics have been developedby systematically considering specializations of the eightgeneral obstacles resolutions strategies in [20]: goal sub-stitution, agent substitution, obstacle prevention, goalweakening, obstacle reduction, goal restoration, obstaclemitigation, and do-nothing.

The benefit of these tactics is to encode expert knowl-edge about how to deal with scalability risks in a formthat allows requirements analysts to explore system-atically during requirements elaboration the range ofalternative ways to deal with such risks.

Table 3 provides an overview of the scalability obstacleresolution tactics. The first and second columns show thegeneral obstacle resolution categories and descriptions,as defined by Lamsweerde and Letier [20]. The thirdcolumn shows the specialized tactics and sub-tactics forresolving scalability obstacles.

A complete, formal description of these tactics can befound in Duboc [33]. This section presents the main ideaof each tactic. For each of the general obstacle resolutionstrategies, we briefly discuss its relevance to resolvingscalability obstacles and, where appropriate, define newmodel transformation tactics that are specific to the res-olution of scalability obstacles. The Do-Nothing strategyconsists simply of leaving the obstacle unresolved andwill not be considered further. This tactic should be


TABLE 3Scalability Obstacle Resolution Tactics

Strategy Short Description Scalability Obstacle Resolution TacticGoal Substitution Resolve the obstacle by finding alternative Can be applied without specialization

goals in which the obstructed goal is nolonger needed

Agent Substitution Resolve the obstacle by changing the • Transfer goal to non-overloaded agentresponsibility assignment for the ◦ Automate responsibility of overloaded human agentobstructed goal • Split goal load among multiple agents

◦ Split goal load into subtasks◦ Split goal load by case

Obstacle Prevention Introduce new goals and assumptions • Introduce scaling assumptionto prevent the obstacle from occurring • Introduce scalability obstacle prevention goal

◦ Set agent capacity according to load- Set agent capacity upfront to worst-case load- Adapt agent capacity at runtime according to load

- Increase number of agent instances- Increase the capacity of the agent instance

◦ Limit goal load according to agent capacity- Limit goal load according to fixed agent capacity

- Distribute goal load over time- Limit goal load according to varying agent capacity

Obstacle Reduction Introduce new goals to reduce the obstacle’s • Influence goal load distributionlikelihood

Goal Weakening Change the definition of an obstructed goal • Weaken goal definition with scaling assumptionto make it more liberal so that • Weaken goal definition by strengthening scaling assumptionthe obstruction disappears • Weaken goal objective function

◦ Relax real-time requirement◦ Relax required level of satisfaction

Goal Restoration Introduce a new goal to restore the Can be applied without specializationsatisfaction of the obstructed goal whenviolated

Obstacle Mitigation Introduce a new goal to mitigate the Can be applied without specializationconsequences of an obstacle when it occurs

Do-Nothing Leave the obstacle unresolved No specialization needed

applied only when the likelihood and criticality of theobstacle are considered low.

4.3.1 Goal SubstitutionA first effective way to resolve an obstacle to somegoal is to eliminate the obstacle completely by findingan alternative to the obstructed goal. For scalabilityobstacles, the principle is to try to find an alternativeway to satisfy the system’s higher-level goals in whichthe scalability risk no longer exists.

Example. Consider the scalability obstacle Batch SizeExceeds Alert Generator’s Processing Speed obstructing the goalAchieve [Batch Processed Overnight]. An application of the goalsubstitution strategy in this case is to design a system inwhich transactions are processed continuously, 24 hoursper day, rather than in overnight batches. This is in fact

a strategy that has been developed for a later version ofthe IEF, which now supports both modes of operation.

4.3.2 Agent SubstitutionThis tactic consists of eliminating the possibility foran obstacle to occur by assigning the responsibility forthe obstructed goal to another agent. The followingspecializations of this tactic are useful for resolvingscalability obstacles.

• Transfer goal to non-overloaded agent: This tacticconsists of transferring responsibility for one or moreof the goals Gi assigned to an overloaded agent Agto an alternative agent Ag′ with bigger capacity orsmaller load. Possible choices for the alternative agentcan be explored systematically by considering all agents


already present in the model. This tactic may lead alsoto the introduction of a new agent role. A particular caseis the commonly used tactic automate responsibility ofoverloaded human agent.

• Split goal load among multiple agents: This tacticconsists of refining a goal G assigned to an overloadedagent Ag into subgoals Gi with smaller loads such thateach subgoal can be assigned to a different agent withenough capacity to satisfy it. An application of thistactic may lead to the introduction of new agent rolestaking responsibilities for the subgoals Gi. Two variantsare the specialized tactics split goal load into subtasksand split goal load by case that consist in generatingthe subgoals for G using a milestone-driven or acase-driven formal refinement pattern, respectively [34].In the first case, a goal of the form Achieve [Target ConditionFrom Current Condition] is refined into two subgoals Achieve[Milestone From Current Condition] and Achieve [Target ConditionFrom Milestone], each being assigned to separate agentswith sufficient capacity to perform the tasks requiredfor the satisfaction of each subgoal. In the second case, agoal G is refined into subgoals of the form G When Casei,where the set of conditions Casei cover an exhaustiveset of cases in which G must be satisfied. Each subgoalis then assigned to a separate agent with sufficientcapacity to support it.

Example. To illustrate these tactics, consider the goalAchieve [Alerts Investigated and Acted Upon Quickly] assigned tothe class of agent Fraud Investigator, and the scalabilityobstacle Number of generated alerts exceeds fraud investigators’capacity. The tactic split goal load into subtasks suggestsidentifying subgoals corresponding to subtasks that canbe assigned to different agents in the system, such as re-fining the goal Achieve [Alerts Investigated and Acted Upon Quickly]into two separate goals Achieve [Alerts Investigated Quickly] andAchieve [Fraudulent Transaction Acted Upon Quickly], each assignedto a different agent with a specialized role. The formergoal is assigned to the agent Fraud Investigator, while thelatter is assigned to the agent Collector. This division is,in fact, adopted by some of Searchspace’s customers. Thetactic split goal load by case suggests identifying a setof alternative cases of alert investigation that could beassigned to fraud investigators who specialize in suchcases and are therefore more efficient to deal with them(e.g., based on the type of alert and account holder).

4.3.3 Obstacle Prevention

Obstacle prevention consists in introducing to the modela new assertion ¬O that prevents the obstacle fromoccurring. Alternative obstacle prevention tactics makethis new assertion either a domain assumption to besatisfied by some agent in the environment, or a goalwhose satisfaction involves the software-to-be [20].

For a scalability obstacle of the form Goal Load ExceedsAgent Capacity, the following obstacle prevention tactic

can be used:

• Introduce scaling assumption: This modeltransformation tactic has been defined already inSection 3.2. It prevents a scalability obstacle fromobstructing a goal G by (1) introducing a scalingassumption SA such that its definition implies thenegation of the obstacle, and (2) using this scalingassumption SA to refine the obstructed goal G into GWhen SA.

• Introduce scalability obstacle prevention goal: Thistactic consists in preventing the scalability obstacle fromoccurring by generating a new goal of the form:

Goal Avoid [Goal Load Exceeds Agent Capacity]Formal Spec �¬ (LoadG > CapacityAg)

Alternative refinements for this goal can then begenerated using the refinement tactics described below.These tactics differ according to whether the obstacleprevention goal is achieved through constraining theagent capacity or the goal load. In both cases, one canconsider a static tactic or a dynamic one.

◦ Set agent capacity according to load: This tacticconsists of refining the above goal into a scaling as-sumption defining a bound X on the goal load (i.e.,� (LoadG ≤ X)), and a goal requiring the agent capacityto have a value above X (i.e., � (CapacityAg > X). It hasthe following static and dynamic specializations:− Set agent capacity upfront to worst-case load: Forthis specialization, X defines a fixed worst-case boundon the goal load, that is, � (LoadG ≤ WorstCaseLoad),and the goal requires the agent capacity to have aconstant value above this worst-case load, that is,� (CapacityAg > WorstCaseLoad).− Adapt agent capacity at runtime according toload: This tactic is the dynamic counterpart of theprevious one. In this tactic, X defines a time-varyingvariable representing the predicted future value of thegoal load at runtime (i.e., � (LoadG ≤ ExpectedLoad),and the goal dynamically extends the agent capacitiesbased on the predicted load (i.e., � (CapacityAg >ExpectedLoad).Two typical tactics to satisfy the subgoal in both cases

are to increase the number of agent instances so thattheir increased capacity is greater than X, or increasethe capacity of the agent instances so that it becomesgreater than X. In the IEF, for example, this could be doneby increasing the number of Fraud Investigators processingalerts or by providing training to investigators so thatalerts can be processed more quickly.◦ Limit goal load according to agent capacity:

This tactic consists of refining the obstacle preventiongoal into a requirement or expectation of the form� (CapacityAg ≥ K) requiring the agent capacity to begreater than some value K, and a subgoal of the form


� (LoadG ≤ K) limiting the goal load value at any giventime below K. This tactic also has two specializations:− Limit goal load according to fixed agent capacity:For this tactic, K is a constant value representing afixed agent capacity. One typical tactic to satisfy thissubgoal is to distribute the goal load over time;for example, for a student enrollment system, differ-ent registration dates can be set for different studentgroups.− Limit goal load according to varying agentcapacity: This tactic is the dynamic counterpart ofthe previous one, where K is a time-varying variable.The principle here is to monitor or predict variationsin the agent capacity at runtime and dynamicallychange the limit on the maximal goal load based onthese variations.

Example. To illustrate the use of these tactics for theexploration of alternative system designs, consider againthe obstacle Batch Size Exceeds Alert Generator Processing Speedand its prevention through the goal Avoid [Batch Size ExceedsAlert Generator Processing Speed]. We consider each of theabove goal refinement tactics in turn.

1) The tactic set agent capacity upfront to worst-caseload refines the goal into a scaling assumption BatchSize Below Max (where Max is a constant value) anda subgoal Maintain [Alert Generator Processing Speed AboveMax], such that the alert generator would have afixed capacity designed to deal with the largestpossible batch size.

2) The tactic adapt agent capacity at runtime ac-cording to load refines this goal into the subgoalsMaintain [Accurate Batch Size Prediction] and Maintain [AlertGenerator Processing Speed above Predicted Batch Size]. Sat-isfaction of these adaptation goals can be assignedas the responsibility of human agents who haveto manually upgrade the system, but they alsocould be partly automated by developing a self-managed system that would monitor and predictbatch sizes and automatically allocate more re-sources as needed.

3) The tactic limit goal load according to fixed agentcapacity refines the goal into a requirement Main-tain [Alert Generator Processing Speed Above K] (where Kis a constant value)—this can be translated to ahardware requirement on machines running theIEF—and a subgoal Maintain [Submitted Batch Size BelowK] requiring the size of the submitted batch toremain within the alert generator capacity. Thereare in turn different ways in which this goal couldbe satisfied. It could, for example, be assigned asthe responsibility of the Bank System, or we couldintroduce an additional agent between the BankSystem and Alert Generator responsible for truncatingbatches of transactions that are too large, and forrescheduling the remaining transactions to a latertime or redirecting them to another system.

4) The tactic limit goal load according to varying

agent capacity is the dynamic counterpart of theabove refinement, in which the limit on the batchsize submitted to the Alert Generator would varyat runtime based on observations of the actualprocessing speed of the Alert Generator (as opposedto a fixed processing speed that was estimated anddefined once when the system was deployed).

These alternative refinements would be modeled as OR-refinement links in the goal graph structure. Each alter-native would have to be evaluated in terms of cost, risks,and its contribution to high-level goals. Such evaluationwould be used then to decide which alternative orcombination of alternatives to select for implementation.

4.3.4 Obstacle ReductionObstacle reduction consists in introducing a new goalaiming at reducing the likelihood of the obstacle oc-curring. Typically, this technique plays on factors thatencourage or dissuade human agents to behave in cer-tain ways. For scalability obstacles, one common obstaclereduction tactic is to influence the distribution of goalload. Consider, for example, an e-commerce websitewishing to announce a sale. It can send notification e-mails to registered customers on different dates ratherthan all on the same date, assuming that customers aremore likely to shop as soon as they receive the e-mail.Another typical example is the tactic used in some largeoffice buildings to reduce morning congestion in theirelevators by spreading out employees’ start times ondifferent floors.

4.3.5 Goal WeakeningSometimes a goal is found to be obstructed by an obsta-cle simply because the initial goal definition is too strong.In this case, one way to resolve the obstruction is todeidealize the goal, that is, to change the goal definition tomake it more liberal so that the obstruction is no longerpresent. This process is supported by a set of formaland informal goal transformation tactics [20]. We havedefined the following new transformation tactics forresolving scalability obstacles through goal weakening:• Weaken goal definition with scaling assumption:

This tactic transforms an obstructed goal into a moreliberal goal, requiring the original goal to be satisfiedonly when its load does not exceed the agent capacity.It should be applied when a goal G that does not referto any scaling assumption is obstructed by a scalabilityobstacle Goal Load Exceeds Agent Capacity. In this tactic, theoriginal goal is transformed into the goal named GWhen Goal Load Does Not Exceed Agent Capacity, where thename corresponds to a scaling assumption. The for-mal transformation pattern associated with this tacticis given by the first row in Table 4. It states that agoal of the form �P obstructed by a scalability obstacle♦ (LoadG > CapacityAg) is transformed into a goal of theform � (LoadG ≤ CapacityAg → P ).

Note that the definition of the resulting goal isthe same as the definition of the subgoal that would


TABLE 4Goal Deidealization Patterns for Scalability Obstacles

Goal Scalability Obstacle Deidealized GoalG : �P ♦ (LoadG > CapacityAg) � (LoadG ≤ CapacityAg → P )

G : � (SA→ P ) ♦ (SA ∧ LoadG > CapacityAg) � (SA ∧ LoadG ≤ CapacityAg → P )

be obtained by applying the tactic introduce scalingassumption. The difference is in terms of how theweakening is propagated, as we illustrate on theexample below.

• Weaken goal definition by strengthening thescaling assumption: This tactic has the same objectiveas the one above, but it should be applied when theobstructed goal already refers to a scaling assumption—that is, when a scalability goal G When SA referring to ascaling assumption SA is obstructed by an additionalscalability obstacle. Applying this tactic transforms theoriginal goal into the goal G When Goal Load Is Within SA andDoes Not Exceed Agent Capacity. The formal transformationpattern associated with this tactic is given by the secondrow in Table 4.

Once a goal definition has been weakened withone of the two tactics above, the change needs tobe propagated along the refinement links in the goalgraph following the general procedure described byLamsweerde and Letier [20]. In the case of these tactics,the propagation typically is performed by weakeningthe definitions of parent goals using the same patternsin Table 4.

•Weaken goal objective function: This tactic involvesweakening the goal’s objective function or requiredlevels of satisfaction so that it requires less agentcapacity for its satisfaction. For Achieve goals of the form�(C → ♦≤dT ), a specialized tactic for goal weakeningis to relax real-time requirement by increasing the timed for achieving the condition T . The relax requiredlevel of satisfaction specialization involves relaxingthe minimum value to be achieved in order for thegoal objective function to be maximized (i.e. the targetvalues of the goal’s objective function).

Example. Applying the tactic weaken goal definitionwith scaling assumption to the goal Achieve [Batch Pro-cessed Overnight] generates the weaker goal Achieve [BatchProcessed Overnight When Batch Size Does Not Exceed Alert Gener-ator’s Speed]. This change would be propagated upwardin the goal model of Figure 1 to yield the goal Achieve[Alert Generated When Batch Size Does Not Exceed Alert Generator’sSpeed]. The purpose of considering such a tactic is toexplore systematically the space of possible resolutions.In this example, it is likely that such resolutions will notbe acceptable to system stakeholders. Consider also the

goal Achieve [Batch Processed Overnight Under Expected Batch SizeEvolution] (specified in Section 3.2). This goal is specifiedwith the following fixed objective function:

Objective Functions At least 9 out of 10 batches should be pro-cessed within 8 hours, and all batches should be processed within9.6 hours.

Name Definition Target

% of Batches Pro- Pr(processingTime ≤ 90%

cessed in 8 hours 8h | ExpectedBatch-

SizeEvolution)

% of Batches Pro- Pr(processingTime ≤ 100%

cessed in 9.6 hours 9.6h | ExpectedBatch-

SizeEvolution)

Assume that the scalability obstacle Expected Batch SizeEvolution Exceeds Alert Generator Processing Speed obstructingthis goal is considered likely to occur. In order to re-solve the obstacle, the tactic relax real-time requirementwould weaken the goal by increasing the expected pro-cessing time from 8 to 10 hours. Alternatively, the tacticrelax required level of satisfaction would weaken thegoal by allowing for less than 90% of the batches to beprocessed in 8 hours.

4.3.6 Goal Restoration and Obstacle MitigationIn some cases, it may be impossible or too costly toguarantee that all scalability obstacles will be avoided.One should therefore consider how to tolerate a scalabil-ity obstacle or mitigate its consequences when it occurs.Two general tactics here are goal restoration and obstaclemitigation.

In goal restoration, a new goal of the form � (¬P →♦P ) is added to the model to eventually restore the con-dition P of the obstructed goal. In obstacle mitigation, anew goal is added to attenuate the consequences of anobstacle occurrence. This typically involves ensuring thesatisfaction of a weaker version of the obstructed goalor of an ancestor of the obstructed goal. Consider, forexample, a call center with the goal Achieve [Calls AnsweredQuickly] stating that calls should be answered in less than3 minutes. If in a given day, the call center receives anunusually high number of calls, this goal is obstructedby the scalability obstacle Number of Calls Exceeds CustomerService Team Capacity. A tactic to mitigate this obstaclemight be to create a new goal Achieve [Return Call] whichensures a weaker version of the obstructed goal statingthat a call must be taken in less than 3 minutes or elsethe details of the customer should be recorded and thecall returned in less than half an hour.


5 CASE STUDY

We have applied the scalability obstacle analysis tech-niques described in the previous section to the elabora-tion of the scalability requirements of a major redesignof the IEF system. One of the main objectives of thisredesign was to extend the existing batch-based systemwith functionality to process transactions in a continuousstream.

This case study follows a previous case study reportedby Duboc et al. [5] in which we elaborated a KAOS goalmodel for the batch-based version of IEF. The first casestudy occurred before our development of the scalabilityobstacle analysis techniques. The elaboration of the goalmodel for the new system and its subsequent scalabilityobstacle analysis were performed by the first author byinvitation of the IEF project manager after the success ofthe first case study. Having worked at Searchspace forthree and a half years, she had good knowledge of theapplication domain and previous system versions.

Unlike a retrospective study of a fully implementedsystem with well understood requirements, this studyinvolved a system under development, with all thecomplexities normally present during the initial elab-oration of a system’s requirements. Stakeholders werebusy with their own daily tasks and had limited timefor requirements elicitation and validation; knowledgeabout the system was spread across individuals; manyassumptions originated from experience with previousprojects that may not have been valid for the newsystem; documents were contradictory and incomplete;and many requirements had no clear rationale other thanbeing present in older versions of the IEF.

Our case study lasted for a period of approximately30 working days, including interviews, brainstormingsessions, modeling, data characterization, and documentwriting and reviewing. During the first two days, theanalyst built an initial high-level model based on herown domain knowledge to serve as a starting point fordiscussions. The next 25 days were spent elaboratingthe initial, idealized goal model and applying the scal-ability obstacle identification and assessment activitiesdescribed in the previous sections. The last five dayswere spent exploring obstacle resolutions and producingthe final documentation.

The initial goal model was elaborated from a numberof sources: the goal model for the previous batch-basedsystem, a business requirements specification that al-ready had been written for the new system, and informa-tion gathered from interviews with project stakeholdersduring the goal model elaboration. The initial businessrequirements specification document contained mostlyfunctional requirements specified through use cases, anda single unjustified estimation of the number of trans-actions the system should be able to process per day.The IEF developers judged this document insufficient toinform the software design adequately.

The full goal model that we elaborated cannot be

shown here due to its size and the sensitivity of the in-formation it contains. Sanitized extracts from the modelcan be found in Duboc [33]. A portion of the goal modelon which we illustrate the scalability obstacle analysistechniques is shown in Figures 5 to 7 in Appendix A.

5.1 Identifying Scalability ObstaclesWe followed the process defined in Section 4.1 to identifyscalability obstacles systematically from goals assignedto agents. Table 5 illustrates the result of this process byshowing the scalability obstacles generated from someof the responsibility assignments included in the goalmodel of Appendix A.

In this table, the Alert Generator agent is shown to be re-sponsible for three goals: Achieve [Batch Processed Overnight],Achieve [Real-time Transactions Processed Instantaneously] andAchieve [Fraud Patterns Tested on Past Transactions]. The first goalis similar to the one defined in Section 2.2, the secondgoal bounds the processing time for transactions thatrequire immediate clearing, and the third goal requiresthat every new fraud detection rule should be testedagainst past transactions.

For these three goals, we have defined the measureof the goal load to be the number of transaction checks(txn check), where a transaction check corresponds to theapplication of a single fraud detection rule to a singletransaction. The load imposed by these goals on theAlert Generator is therefore proportional to the number oftransactions to be checked and the number of frauddetection rules to be applied on each transaction. Wethereby obtained the scalability obstacle Number of TxnChecks Exceeds Alert Generator Processing Speed obstructingthese three goals. In defining this scalability obstacle,we further took into consideration the fact that not allfraud detection rules take the same time to compute. Forexample, fraud detection rules that consider historicalinformation about a set of related accounts take muchlonger to process than simple comparisons of transac-tions against blacklisted account numbers.

Other domain characteristics, such as the percentageof new accounts in a daily batch or stream, also in-fluence the goal load and therefore were included inthe definition of this scalability obstacle. Thus, unlikeour simple illustrative example in Section 4.1 where theload of the goal Achieve [Batch Processed Overnight] was asimple scalar value (the number of transactions), in ourfull model, this load is defined as a vector composedof several domain characteristics. Significant knowledgeabout the application domain and fraud detection ruleswas necessary to identify such additional characteristics.

As shown in Table 5, the obstacle identification processalso led us to identify scalability obstacles to agentsother than the Alert Generator. In particular, the number ofgenerated alerts and the time needed to handle an alertare important factors whose variations could preventFraud Investigators from satisfying their goals.

In our model, the Data Storage agent is separate from theAlert Generator because it correspond to a given domain


TABLE 5Scalability Obstacles to IEF Goals

Agent Goal Scalability Obstacle

Alert Generator

Achieve [Batch Processed Overnight]Number of Txn Checks Exceeds Alert GeneratorProcessing SpeedAchieve [Real-time Transactions Processed Instantaneously]

Achieve [Fraud Patterns Tested on Past Transactions]

Data Store

Achieve [Incoming Transactions Stored]

Amount of Data Exceeds Data Storage SpaceAchieve [Alerts Stored]

Achieve [Fraud Detection Rules Stored]

Fraud Investigator Achieve [Alerts Investigated and and Acted Upon Quickly] Number of Alerts Exceeds Fraud InvestigatorSpeed

component the Alert Generator must interact with. Fromthe goals shown in Table 5, we generated the scalabilityobstacle Amount of Data Exceeds Data Storage Space whosedefinition refers to domain quantities such as the numberand size of transactions and generated alerts.

Our systematic identification of scalability obstaclesled us to uncover 13 important domain characteristicsthat have an impact on the system’s scalability. Allthese characteristics except one had been overlookedin the initial business requirements specification, andtheir impact on scalability never had been made fullyexplicit to the main system stakeholders. The benefit ofexposing these scaling characteristics became apparentwhen eliciting scaling assumptions on these variablesand discovering that stakeholders had diverging viewsabout the ranges of values such variables may take, andtherefore about the software scalability requirements thatdepend on these assumptions.

Two important observations can be made from ourexperience in identifying scalability obstacles for the IEFsystem:

1) The completeness of the generated scalability obstacles isrelative to the completeness of the goal model. An im-portant concern when identifying scalability obsta-cles is to try to identify all domain quantities whosevariations have an impact on the system’s ability tosatisfy its goals. The systematic process in whichscalability obstacles are generated for each agentand every goal assigned to it ensures completenessof the identified obstacles with respect to specifiedsoftware requirements and domain expectations.By completeness here, we mean that a scalabilityobstacle of the form Goal Load Exceeds Agent Capacityhas been considered for all leaf goals and agent re-sources that have been identified in the model. Thiscompleteness is of course relative to the quality ofthe initial goal model—if some important agents,requirements or domain expectations are missing,it is likely that their scalability obstacles will beoverlooked as well.

2) Detailed domain knowledge is needed to define fine-grained scalability obstacles. Defining what consti-tutes the load of a particular goal was not always

straightforward and could not be derived simplyfrom the goal definition alone. It often required agood knowledge of the application domain and ofthe factors affecting the computational complexitiesof the functions to be performed for satisfyingthe goals. This was illustrated above for the goalsassigned to the Alert Generator. In our example, itrequired good knowledge of the complexities ofthe different alert generation rules used in frauddetection systems. When this knowledge is notavailable, scalability obstacles still can be identi-fied from the goal definition, but the scalabilityobstacles as defined remain much more coarse-grained. For example, without expert knowledge,our scalability obstacles to the Alert Generator’s goalswould have been defined in terms of numbers oftransactions only, as was done in Section 4.1. Simi-larly, the scalability obstacles we have identified forthe goals assigned to the Fraud Investigator agents re-main quite coarse-grained, because during our casestudy we lacked access to the knowledge of whatdomain characteristics affect the speed at whichalerts are investigated. A benefit of our scalabilityobstacle identification process is that it structuresthe elicitation activities that need to be performedfor identifying detailed scalability obstacles.

5.2 Assessing Scalability Obstacles and ElicitingScaling AssumptionsOnce identified, scalability obstacles need to be assessedin terms of their likelihood and criticality, so that de-cisions can be made about which obstacles need to beresolved. Since obstacle analysis is an iterative process,scalability obstacles need to be reassessed after their res-olutions. During this reassessment, obstacle likelihoodsand criticality are used also to guide the selection amongalternative resolutions.

In a first assessment, we considered all identified scal-ability obstacles equally likely to happen. Since we hadno information about the potential scaling characteristicsof the various domain quantities, we pessimisticallyassumed that they all could rise to levels that wouldlead to violations of idealized goals.


TABLE 6Criticality of Scalability Obstacles

Scalability Obstacle Likelihood CriticalityNumber of Txn Checks Exceeds Alert Generator Processing Speed High High

Amount of Data Exceeds Data Storage Space High High

Number of Alerts Exceeds Fraud Investigator Speed High Moderate

The criticality of the identified scalability obstacles wasestimated by the first author and project manager byidentifying which higher-level goals would be violatedif the obstacles were to occur. Table 5.2 shows thisqualitative assessment for three obstacles.

After this first assessment, we started eliciting scalingassumptions for all domain quantities involved in thescalability obstacles and updated the goal model byapplying the tactic introduce scaling assumption to theobstructed goals. This tactic generated new obstacles thathad to be assessed as well. We did not yet consider otherscalability obstacle resolution tactics, because we felt thatwe needed first to understand the scaling assumptionsof the variables involved before investigating other res-olution tactics.

For example, the goal Achieve [Batch Processed Overnight]was refined into the scaling assumption and scalabilityrequirement shown in Figure 4. The figure also shows

Fig. 4. Obstacles to a Scaling Assumption and a Scala-bility Requirement.

new obstacles to the scaling assumption and the scal-ability requirement. Assessing the likelihoods of thesetwo obstacles consists of (1) asking how likely it is thatthe number of transaction checks in a batch will exceedthe assumed maximum value, and (2) how likely it isthat the batch will not be processed in time despite thefact that the number of transaction checks is below theassumed maximum value, respectively.

We also asked developers to estimate how feasibleit would be to develop a system that would meet thescalability requirements given these scaling assumptions.When there was a perceived risk that the scalability re-quirements may not be achievable, this signaled the needto investigate additional resolutions for the scalability

obstacles to these requirements. The exploration of theseresolutions will be discussed in the next section.

From our experience in assessing scalability obstacles,we can make the following observations.

1) Assessing scalability obstacle likelihoods and elicitingscaling assumptions are strongly related activities. Thestandard identify-assess-resolve loop of obstacleanalysis assumes that obstacle likelihoods can beassessed before deciding on their resolution. Thisproved to be impossible for the first assessment ofscalability obstacles, because assessing how likely ascalability obstacle is to occur requires knowledgeof the scaling characteristics of the domain quan-tities concerned by the obstacles. For this reason,we deviated from the standard obstacle analysisprocess, and combined the tasks of assessing scal-ability obstacles and eliciting scaling assumptionsas described above.

2) Another difficulty we faced was that the capacity ofsome agents is still unknown when the obstacle like-lihood needs to be assessed. Indeed, one of the pur-poses of the requirements engineering process isto decide what the required capacities for theseagents should be. Such analysis should take intoconsideration the varying likelihood of scalabilityobstacles to different envisioned agents capacities.For example, the scalability obstacle Batch NOT Pro-cessed In Time When Nbr Txn Checks Below Assumed Max inFigure 4 required asking IEF developers to assessthe likelihood of this obstacle occuring for feasibleAlert Generator capacities (i.e., its processing speed).However, we feel that a technique for more thor-ough analysis of the variation of obstacle likelihoodwith respect to the variation of feasible agent ca-pacities is needed, and this is a subject of futureresearch.

3) Eliciting and reaching agreements on the projected val-ues for domain quantities in the scaling assumptionsproved to be the most difficult and time consuming tasksof our case study. This was due to the uncertaintiesand divergence of opinions among stakeholdersabout future values for some of the domain char-acteristics, and to large variations in the customerbase that led people to make different (often im-plicit) assumptions. There was also a lack of aware-ness by non-software engineers of the impact thatsome of the projected values would have on thesoftware design, leading sometimes to infeasible


or extremely costly requirements due to unrealis-tically high scaling characteristics. To help resolvethese divergences, we created a simple quantitativegoal model [23] relating projected values for thedomain quantities involved in scaling assumptions(e.g., the expected growth rate in the number ofaccounts and number of transactions per account)to scalability requirements for the software system(e.g., in terms of throughput and storage). Thismodel was used during stakeholder meetings tohelp reach agreement on the scaling assumptions.

4) The qualitative assessment of the scalability obstacles’criticality was straightforward and aided by the goalmodel structure. This simply consisted of follow-ing goal-refinement links bottom-up from the ob-structed goal to higher-level business goals.

5) Qualitative vs. quantitative assessment of scalabilityobstacles. Our assessment of scalability obstacles re-mained entirely qualitative. A finer-grained quan-titative assessment of the likelihood of violationsof scaling assumptions was felt to be too uncertainto be of value. Accurate quantitative assessmentsof the likelihood of meeting the scalability require-ments are also difficult to obtain. These potentiallycould be obtained by analyzing models of theintended software architecture or by testing systemprototypes, but such analyses were not performed.A qualitative assessment of scalability obstacleswas sufficient for our purposes of identifying whatthe important scalability obstacles are and howthese can be resolved through the introduction ofnew goals and requirements. We note that similarobservations about the limitation of quantitativeassessments and benefits of qualitative assessmentshas been made about the use of fault tress for safetycritical systems [11]. However, our case study didnot involve detailed comparisons of alternativesystem designs for which a more precise, quanti-tative assessment of scalability obstacles might beneeded. This is an area where further research isrequired.

5.3 Resolving Scalability Obstacles

For resolving scalability obstacles, we have used the cata-log of scalability obstacle resolution tactics in Section 4.3to explore systematically some potential resolutions ofa few key scalability obstacles that were judged to becritical. Some of the resolutions we identified correspondto design decisions that had been taken independentlyof our study by Searchspace for the new system version.Other resolutions correspond to alternative and addi-tional requirements that had not been considered or hadbeen considered but not retained. For the case study, wefocussed on generating a wide range of resolutions forthe identified scalability obstacles. We did not performdetailed evaluations of the generated alternatives inorder to guide the selection of the preferred ones.

The process of generating resolutions to scalabilityobstacles consists of systematically considering the po-tential application of each resolution tactic in Table 3 toeach obstacle. To illustrate this process, Tables 7 and 8illustrate the set of model transformations that can beapplied to resolve the obstacles listed in Table 5. Someof the goal specifications and goal graphs obtained bythese model transformations can be found in Duboc [33].The identify-assess-resolve loop of obstacle analysis isiterative. Once a resolution tactic has been selected, oneneeds to identify its obstacles and explore new obstacleresolution tactics. In Tables 7 and 8, we only discussresolutions for the original obstacles.

A few observations can be made from our experiencein resolving scalability obstacles for the IEF system:

1) We felt that the biggest benefit of the catalog of obsta-cle resolution tactics was in encouraging a systematicexploration of a wide range of alternative options forresolving a scalability obstacle. Although we did notdo this during this case study, we believe thatsuch a catalog can be used during meetings withstakeholders, domain experts, and system design-ers to facilitate the exploration of creative designsolutions to envisioned scalability risks. Furtherstudies, such as those explored by Maiden andRobertson [35], would be needed to investigate theeffectiveness of scalability resolution tactics in thissetting.

2) A question we faced was at which level of detail tospecify the models generated by the application of theresolution tactics. In practice, when exploring alter-native resolutions, we did not specify all alternativemodels explicitly, as the enunciation of the appliedresolution tactic is in most cases enough to under-stand what the model would be. We felt it wouldbe sufficient to specify the actual requirements anddomain assumption only once an alternative wasselected. We did not specify detailed formal specifi-cations for the resulting new goals because this wasnot felt to be of benefit to the project. However, theformal descriptions of the model transformationswere helpful to clarify and disambiguate what eachresolution tactic could achieve.

5.4 Summary

Our case study produced valuable results toSearchspace. Project managers easily understoodand accepted the basic concepts of our approach andwere particularly impressed by the ability of the modelto reveal the impact of distinct projected scaling boundson leaf goals and to expose conflicting requirements.The goal model provided a rationale for low-levelrequirements and, in particular, it allowed a moreprecise and justifiable characterization of scaling rangesand objective functions. Some scaling bounds happenedto be more flexible than originally stated, while otherswere found to be more rigid. One of the tools that


TABLE 7Resolving the Scalability Obstacle Nbr of Txn Checks Exceeds Alert Generator Processing Speed

Resolution Strategy Model TransformationsGoal Substitution • none, because the obstructed goals are essential and have no alternatives

Agent Substitution • Transfer goal to non-overloaded agent: Responsibility for the goal Achieve [FraudPatterns Tested on Past Transactions] can be transferred from the Alert Generator to aSandbox agent providing a separate environment for testing new fraud detection rules.• Split goal load among multiple agents: none; we could identify no subtasks orsub-cases for the obstructed goals that could be offloaded to other agents.

Obstacle Prevention • Introduce scaling assumption: This tactic generates a series of scalingassumptions—on the numbers of transactions in a batch, distinct business entities ina batch, transactions per second in the transactions stream, distinct business entitiesper second in the transactions stream, transactions in testing data, distinct businessentities in testing data, fraudulent patterns, fraudulent patterns added in the lastday—together with the subgoals obtained by application of the refinement pattern.• Introduce scalability obstacle prevention goal: This tactic generates the newgoal Avoid [Nbr of Txn Checks Exceeds Alert Generator Processing Speed]. Alternativerefinements for this goal are as follows:◦ Set agent capacity according to load: The tactic set agent capacity upfront toworst-case load refines the goal into the assumption Assumed Worst-Case Nbr of TxnChecks and goal Maintain [Alert Generator’s Speed above Worst-Case Nbr of Txn Checks],while the tactic adapt agent capacity at runtime according to load refines it intothe subgoals Maintain [Accurate Prediction on Max Nbr of Txn Checks] and Maintain [AlertGenerator’s Speed above Predicted Max Nbr of Txn Checks].◦ Limit goal load according to agent capacity: Applying the tactic limit goalload according to fixed agent capacity imposes fixed limits on the number oftransactions that a bank can provide in its daily batches and continuous stream,while the tactic limit goal load according to varying agent capacity imposessimilar limits but with bounds that can vary over time based on the capacitiesof the Alert Generator. Alternative ways of implementing these tactics have beendescribed in Section 4.3.3.

Obstacle Reduction • Influence goal load distribution: Pricing incentives can be introduced to influencethe goal load (for example, by setting up tariffs that will influence the time at whichtransactions are submitted).

Goal Weakening • Weaken goal definition with scaling assumption and weaken goal definitionby strengthening scaling assumption consist in revisiting the scaling assumptionselicited during the scalability obstacles assessment step (see Section 5.2) so as toweaken the requirements on the Alert Generator.• Weaken goal objective function: This tactic consists in modifying the AlertGenerator’s requirements by relaxing its real-time requirement, relaxing its requiredlevels of satisfaction, or both, as illustrated in Section 4.3.5.

Goal Restoration andObstacle Mitigation

• These tactics led us to specify goals to be satisfied when the Alert Generator failsto satisfy the obstructed goals. These include the requirements to make generatedalerts available to a Fraud Investigator even if a batch has not been processed entirely,and to finish processing an uncompleted batch as soon as possible. For the real-timetransaction processing, it includes defining how to clear real-time transactions if theAlert Generator fails and how eventually to check for frauds in transactions that havebeen cleared during the Alert Generator’s failure if it were to happen.

enabled us to elaborate goals and estimate boundsmore precisely was to get an explicit statement of allunderlying assumptions about the application domain.The final model contains a number of goals that hadbeen overlooked in Searchspace’s initial requirementsspecification and replaces others that were idealized inthat specification. The approach also helped to documentand resolve numerous stakeholder disagreements. Thegoal-obstacle analysis process allowed us to exposea whole range of potential system failures, not onlyscalability-related ones. Searchspace has used the goalmodel to support the development of the new version

of the IEF. Furthermore, the model can be used bythem to aid a number of other activities, such as thederivation of test cases, and the derivation of hardwarerequirements for their different clients based on theirexpected scaling characteristics.

6 RELATED WORK

Scalability is commonly discussed in the context ofspecific technologies. Virtualization, for example, hasbeen used for years, and, a number of studies havereported on the scalability of systems running in virtual


TABLE 8Resolving the Scalability Obstacle Amount of Data Exceeds Data Storage Space

Resolution Strategy Model TransformationsGoal Substitution • none, although some of the goals obtained though goal weakening (see below) were

first identified when looking for goal substitutions

Agent Substitution • Transfer goal to non-overloaded agent: Responsibilities for storing the transactionsand alert data can be transferred to an external data store.• Split goal load among multiple agents: This tactic consists in splitting the Data Storeagent into multiple components, each of which can be responsible for storing part ofthe data. However, deciding how to organize the Data Store into multiple componentsis a design decision rather than a requirements one. The scalability requirementsdefine the constraints that the Data Store must satisfy without prescribing what itsarchitecture should be.

Obstacle Prevention • Introduce scaling assumption: This tactic introduces scaling assumptions on thenumber and size of transactions, generated alerts, and stored fraud patterns, togetherwith the corresponding scalability subgoals.• Introduce scalability obstacle prevention goal: This tactic generates the new goalAvoid [Amount of Data Exceeds Data Storage Space] for which we generate the followingalternative refinements:◦ Set agent capacity according to load: The tactic set agent capacity upfrontto worst-case load is not applicable because the worst-case load in this case isinfinite if we assume no end to the system’s lifetime. The tactic adapt agentcapacity at runtime according to load suggests that we plan for a gradualincrease of the storage space during the system’s lifetime.◦ Limit goal load according to agent capacity: This tactic suggests increasingthe alerting threshold so as to limit the number of generated alerts when storagespace is insufficient.

Obstacle Reduction • Influence goal load distribution: Influencing the number of bank transactions isout of scope and reducing this number would be against the company’s interest.The number of false alerts could be reduced by influencing the behaviors of accountholders (e.g., by allowing and encouraging them to provide information to the bankto reduce the risk of false alerts.)

Goal Weakening • Weaken goal definition with scaling assumption and weaken goal definition bystrengthening scaling assumption consist in revising the scaling assumptions andhave not been considered.• Weaken goal objective function: The data storage goal can be weakened bylimiting the amount of time during which transactions and alerts need to remainstored. This is one of the tactics implemented in the system. Many factors influencewhen transactions and alert data can be removed, notably legal requirements on theminimum time during which transactions and alert data must remain accessible.

Goal Restoration andObstacle Mitigation

• If the obstacle cannot be completely avoided, back up plans may consist of havingreserved storage space always on stand-by, erasing older data to allow for new datato be stored, or stopping all processing until the obstacle is resolved.

environments [36], [37], [38]. Earlier, the advent of gridcomputing was driven by the need to share resources,and sometimes to achieve high-performance, in collab-orative problem-solving strategies which emerged inindustry, science, and engineering [39]. Currently, cloudcomputing mechanisms, such as cloudbursting, allowcompanies to maintain their private cloud and leverage apublic cloud to handle spikes in the processing require-ments [40]. In fact, the idea of using shared resourcesas needed has been around for a decades [41] and, yetthe software engineering community struggle to developscalable software. Such technologies may make it easierto implement software systems that satisfy scalabilitygoals, but do not offer any intrinsic help in identifying,communicating and analyzing these goals. Our approach

elaborates scalability goals independently of the technol-ogy being used to fulfil them.

Works on scalability analysis recognize the need forprecise scalability requirements. However, the great ma-jority of them take the elicitation and specification ofthese requirements for granted [3], [4], [42], [43], [44].Our method can be used to elaborate the models thesetechniques need as input.

The few works in this area that attempt to give someguidance on elaborating scalability requirements takean oversimplified view of the requirements engineeringprocess. In particular, they tend to be limited to specify-ing the information that scalability requirements shouldcontain [6], [7], or to provide only vague guidelineson the kinds of scenarios such requirements should


cover [45], [46], [47]. Our approach provides a systematicapproach for elaborating scaling assumptions, scalabilitygoals and scalability requirements from an initial, ideal-ized goal model using scalability obstacle analysis.

Our definition of scalability [4] differs from otherdefinitions. For example, Weinstock and Goodenoughdistinguish two main uses of the term scalability: (1) theability to handle increased workload without addingresources to a system; and (2) the ability to handle in-creased workload by repeatedly applying a cost-effectivestrategy for extending a system’s capacity [31]. Thesedefinitions allude to alternative strategies for satisfy-ing (stated or unstated) scalability goals, and the costsinvolved in doing so, rather than ways in which thescalability goals are identified and specified initially. Incontrast, our framework distinguishes scalability goals(goals whose specification is related to one or morescaling assumptions) from the tactics for achieving thesegoals (specified as goal refinements and obstacle res-olutions). Our resolution tactics cover both notions ofscalability discussed by Weinstock and Goodenough.

Cost is an important quality that has strong interac-tions with scalability goals, as well as with all other goalsof a system. In our goal-oriented framework, cost is aseparate criterion that is used to select among alternativescalability obstacle resolution tactics, but it is not part ofthe definition of the scalability goals themselves. A viewsimilar to ours is taken by Bahsoon and Emmerich, whorelate costs and scalability in order to value the ranges inwhich a given software architecture can scale to supportlikely changes in load [3]. A different approach is takenby Jogalekar and Woodside, who define a scalabilitymetric for distributed systems that takes into accountthroughput, stakeholder’s value and running cost [48].In future work, we intend to investigate how metrics,such as this, can be used to select among alternativescalability strategies.

Existing goal-oriented requirements engineering meth-ods provide no specific support for eliciting, modellingand reasoning about scalability requirements [8], [18]. Aswe summarize in the next section, the work described inthis paper rectifies this gap.

7 CONCLUSION

Accurate scalability goals should be identified in theearliest stages of system development. Not only canthis help system designers to take proper advantageof current technologies and to avoid costly mistakes,but it also can give them greater freedom to explorealternative system designs and system evolution pathsfor achieving scalability than if such concerns were leftto later stages. However, identifying scalability goals inthose early stages is not trivial, and to date little researchhas been done on how to elicit, model and reason aboutthem in a precise and systematic way. This is surprisinggiven the importance of scalability for many software-intensive systems, and it contrasts with the extensive

treatment received by other critical quality requirementssuch as performance, safety and security.

To address this problem, we have presented precisedefinitions for the concepts of scalability goals and scal-ing assumptions in the context of the KAOS goal mod-eling framework. These definitions provide templatesthat requirements engineers can use to write preciseand testable specifications of scalability goals. Thesespecifications are testable in the sense that they are fal-sifiable by a counter-example, and the counter-exampleis reproducible [49]. This corresponds to the notion oftestability in requirements engineering [50] and to ourview of scalability analysis as a form of experimentalanalysis [4], [51].

In addition to being precise and testable, scalabilitygoals also should be complete and accurate, in the sensethat they correspond to what is truly needed for thesystem. In order to help achieve this objective, we havedeveloped a systematic method to assist requirementsengineers in elaborating scalability goals from an initialgoal model that has been elaborated without concern forscalability issues. The method consists of systematicallyidentifying and resolving scalability obstacles to theinitial goals assigned to each system agent. The resultof this is a consolidated requirements model in whichthe initial goal model has been extended with precisescaling assumptions, scalability goals and additional re-quirements to help avoid, reduce or mitigate scalabilityobstacles. Our method generates a set of alternativedesign options for resolving scalability obstacles thatneed to be evaluated in terms of costs and benefits sothat the most appropriate options can be selected forimplementation.

Our method thus contributes to addressing several ofthe key issues identified at the start of the paper:• By extending the KAOS modeling framework with

the concepts of scalability goals and scaling assump-tion, we facilitate the precise specification of testablescalability requirements.

• Our scalability obstacle analysis method provideseight new obstacle resolution tactics with 14 vari-ants for managing scalability-related risks early inthe development process; for identifying scalabilityobstacles induced by domain quantities whose ex-pected operational ranges could prevent the systemfrom satisfying its goals; and for exploring a widerange of alternative designs to prevent, reduce ormitigate those scalability obstacles. Scalability obsta-cles have not been considered explicitly in previoustechniques, such as Lamsweerde and Letier [20].Furthermore, an important and distinguishing fea-ture of our method is that we generate each scalabil-ity obstacle from all goals involving the same agent,in contrast to previous patterns and heuristics thatgenerate obstacles one goal at a time.

• The elaboration of scaling assumptions required byour method helps requirements analysts begin touncover uncertainties and disagreements about ex-


pected operational ranges for the domain quantities,as well as the impact that such quantities may haveon the system’s goals; exposing uncertainties anddisagreements that would otherwise remain implicitis a first step towards resolving these issues.

• The result of our elaboration method is a goal-oriented requirements model in which software scal-ability requirements are related to scalability ob-stacles, domain scaling assumptions and high-levelbusiness goals; such a model helps stakeholdersunderstand the rationale and costs of specific re-quirements.

• The models resulting from our elaboration methodalso can be used as input for other techniques toevaluate alternative system designs and to maketradeoffs among competing goals, including thoserelated to cost and time-to-market [3], [4], [23], [43],[44], [52].

We have validated our method by applying it to the ma-jor redesign of a state-of-the-art financial fraud detectionsystem currently in use in many financial institutionsthroughout the world. Other smaller examples of theapplication of scalability obstacle analysis, notably on aprevious model of the London Ambulance Service, havebeen presented by Duboc [33].

For future work, we intend to develop additionalsupport for our technique to address some of the issuesthat have not been addressed fully in this paper. Thisincludes the quantitative assessment of scalability goalsand obstacles. For this purpose, we envision extendingtechniques for simulating and optimizing quantitativegoal models [53] to handle time-varying domain as-sumptions, obstacle likelihoods, and levels of goal sat-isfaction needed to reason about scalability. In addition,we plan to undertake further investigation of scalabilitymodeling and analysis in the context of cloud comput-ing. We are collaborating currently with researchers atthe University of Birmingham to model the scalabilitygoals of an infrastructure for automatically composingservice-based systems in a cloud environment [54] andto use goal modelling to systematically guide an orga-nization in evaluating the choice and risks of adoptinga cloud-based solution [55] and evaluating the trade-off between scalability and consistency for replicationtechniques in clouds [56]. We also are beginning toexplore new techniques for testing that a system satisfiesits scalability requirements.

ACKNOWLEDGMENTSThis work was partially supported by the EuropeanIST FET programme in project SENSORIA (IST-2005-016004), a UCL studentship to Letcia Duboc, the EP-SRC grant EP/H011447/1 and a Wolfson Research MeritAward from the Royal Society to David Rosenblum. Theauthors thank Capacitas and NICE Actimize (formerlySearchspace) for discussions that led to many of thescalability tactics presented in this paper, and the anony-mous referees for their constructive comments.

REFERENCES

[1] R. P. Gabriel, L. Northrop, D. C. Schmidt, and K. Sullivan, “Ultra-large-scale systems,” in Proc. 21st ACM SIGPLAN Symposium onObject-Oriented Programming Systems, Languages and Applications.New York, NY, USA: ACM, 2006, pp. 632–634.

[2] D. S. Rosenblum and A. L. Wolf, “A design framework forInternet-scale even observation and notification,” in Proc. 6th Eu-ropean Software Engineering Conference Held Jointly with the 5th ACMSIGSOFT Symposium on the Foundations of Software Engineering,1997, pp. 334–360.

[3] R. Bahsoon and W. Emmerich, “An economics-driven approachfor valuing scalability in distributed architectures,” in Proc. 7thWorking IEEE/IFIP Conference on Software Architecture. Washing-ton, DC, USA: IEEE Computer Society, 2008, pp. 9–18.

[4] L. Duboc, D. Rosenblum, and T. Wicks, “A framework for char-acterization and analysis of software system scalability,” in Proc.6th Joint Meeting of the European Software Engineering Conferenceand the ACM SIGSOFT Symposium on the Foundations of SoftwareEngineering. New York, NY, USA: ACM, 2007, pp. 375–384.

[5] L. Duboc, E. Letier, D. Rosenblum, and T. Wicks, “A case study ineliciting scalability requirements,” in Proc. 16th IEEE InternationalSymposium on Requirements Engineering, Barcelona, Spain, 2008.

[6] Actuate Corporation, “Meeting scalability requirementsfor enterprise reporting solutions,” 2004, accessed fromhttp://www.onixnet.com/actuate/scalability.pdf on 01 July2009.

[7] Microsoft TechNet Library, “Quantifying availability and scalabil-ity requirements,” 2005, accessed from http://www. on 01 July2009.

[8] A. van Lamsweerde, Systematic Requirements Engineering: FromSystem Goals to UML Models to Software Specifications. John Wiley& Sons, 2008.

[9] E. S. K. Yu, “Towards modeling and reasoning support for early-phase requirements engineering,” in Proc. 3rd IEEE InternationalSymposium on Requirements Engineering. Washington, DC, USA:IEEE Computer Society, 1997, p. 226.

[10] M. Jackson, Problem Frames: Analyzing and Structuring Software De-velopment Problems. Boston, MA, USA: Addison-Wesley LongmanPublishing Co., Inc., 2001.

[11] N. G. Leveson, Safeware: System Safety and Computer. New York,NY, USA: ACM, 1995.

[12] R. R. Lutz, “Software engineering for safety: A roadmap,” in Proc.The Future of Software Engineering 2000. New York, NY, USA:ACM, 2000, pp. 213–226.

[13] R. J. Anderson, Security Engineering: A Guide to Building DependableDisributed Systems. New York, NY, USA: John Wiley & Sons, Inc.,2001.

[14] A. van Lamsweerde, “Elaborating security requirements by con-struction of intentional anti-models,” in Proc. 26nd InternationalConference on Software Engineering. ACM-IEEE, 2004, pp. 148–157.

[15] C. B. Haley, R. C. Laney, J. D. Moffett, and B. Nuseibeh, “Securityrequirements engineering: A framework for representation andanalysis,” IEEE Transactions on Software Engineering, vol. 34, no. 1,pp. 133–153, 2008.

[16] ISO 9126, “Software Product Evaluation: Quality Characteristicsand Guidelines for Their Use,” 1991.

[17] B. W. Boehm, J. R. Brown, and M. Lipow, “Quantitative evalua-tion of software quality,” in Proc. 2nd International Conference onSoftware Engineering. Los Alamitos, CA, USA: IEEE ComputerSociety Press, 1976, pp. 592–605.

[18] L. Chung, B. A. Nixon, E. Yu, and J. Mylopoulos, Non-FunctionalRequirements in Software Engineering. Kluwer Academic Publish-ers, 2000.

[19] P. Kruchten, The Rational Unified Process: An Introduction. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2003.

[20] A. van Lamsweerde and E. Letier, “Handling obstacles in goal-oriented requirements engineering,” IEEE Transactions on SoftwareEngineering, vol. 26, no. 10, pp. 978–1005, 2000.

[21] E. Letier and A. van Lamsweerde, “Agent-based tactics for goal-oriented requirements elaboration,” in Proc. 24th InternationalConference on Software Engineering. New York, NY, USA: ACM,2002, pp. 83–93.

[22] R. Koymans, Specifying Message Passing and Time-Critical Systemswith Temporal Logic. Secaucus, NJ, USA: Springer-Verlag NewYork, Inc., 1992.


[23] E. Letier and A. van Lamsweerde, “Reasoning about partial goalsatisfaction for requirements and design engineering,” in Proc.12th International Symposium on Foundations of Software Engineering.New York, NY, USA: ACM, 2004, pp. 53–62.

[24] C. Potts, “Using schematic scenarios to understand user needs,”in Proc. 1st Conference on Designing Interactive Systems. New York,NY, USA: ACM, 1995, pp. 247–256.

[25] Y. Akao, Quality Function Deployment QFD: Integrating CustomerRequirements into Product Design. Productivity Press, 1990.

[26] W. N. Robinson, “Negotiation behavior during requirementsspecification,” in Proc. 12th International Conference on SoftwareEngineering. Los Alamitos, CA, USA: IEEE Computer SocietyPress, 1990, pp. 268–276.

[27] J. Yen and W. A. Tiao, “A systematic tradeoff analysis for con-flicting imprecise requirements,” in Proc. 3rd IEEE InternationalSymposium on Requirements Engineering. Washington, DC, USA:IEEE Computer Society, 1997, p. 87.

[28] P. Giorgini, J. Mylopoulos, E. Nicchiarelli, and R. Sebastiani, “Rea-soning with goal models,” in Proc. 21st International Conference onConceptual Modeling. London, UK: Springer-Verlag, 2002, pp. 167–181.

[29] M. Feather, S. Cornford, J. Dunphy, and K. Hicks, “A quantitativerisk model for early lifecycle decision making,” in Proc. Conferenceon Integrated Design and Process Technology, 2002.

[30] P. Zave and M. Jackson, “Four dark corners of requirements en-gineering,” ACM Transactions on Software Engineering and Method-ology, vol. 6, no. 1, pp. 1–30, 1997.

[31] C. B. Weinstock and J. B. Goodenough, “On systemsscalability,” Software Engineering Institute, TechnicalNote CMU/SEI-2006-TN-012, March 2006, accessed fromhttp://www.sei.cmu.edu/publications/documents/06.reports/06tn012.html on 30 July 2008.

[32] E. Letier, “Reasoning about agents in goal-oriented requirementsengineering,” 2001, PhD Thesis, Universite Catholique de Lou-vain, Dept. Ingenierie Informatique, Louvain-la-Neuve, Belgium.

[33] L. Duboc, “A framework for characterization and analysis of soft-ware systems scalability,” 2010, PhD Thesis. University CollegeLondon, Department of Computer Science, London, UK.

[34] R. Darimont and A. van Lamsweerde, “Formal refinement pat-terns for goal-driven requirements elaboration,” in Proc. 4th ACMSIGSOFT Symposium on Foundations of Software Engineering. NewYork, NY, USA: ACM, 1996, pp. 179–190.

[35] N. Maiden and S. Robertson, “Integrating creativity into require-ments processes: Experiences with an air traffic managementsystem,” Proc. 13th IEEE International Conference on RequirementsEngineering, pp. 105 – 114, aug. 2005.

[36] V. Chaudhary, M. Cha, J. Walters, S. Guercio, and S. Gallo, “Acomparison of virtualization technologies for HPC,” in Proceed-ings of the 22nd International Conference on Advanced InformationNetworking and Applications, 2008. AINA 2008, March 2008, pp.861 –868.

[37] J. Wiegert, G. Regnier, and J. Jackson, “Challenges for scalablenetworking in a virtualized server,” in Proceedings of 16th Interna-tional Conference on Computer Communications and Networks, 2007,August 2007, pp. 179 –184.

[38] Z. Yanzhou, L. Chaoling, L. Lixin, and L. Wenjun, “Improvingthe scalability of PrivacyCAs,” in Second International Workshop onComputer Science and Engineering, 2009., vol. 2, October 2009, pp.111 –116.

[39] I. Foster, C. Kesselman, and S. Tuecke, “The anatomy of thegrid: Enabling scalable virtual organizations,” Int. J. High Perform.Comput. Appl., vol. 15, no. 3, pp. 200–222, 2001.

[40] D. Linthicum, “The case for the hybrid cloud,” Infoworld CloudComputing, March 2010.

[41] R. M. Fano, “The mac system: the computer utility approach,”Spectrum, IEEE, vol. 2, no. 1, pp. 56 –64, jan. 1965.

[42] S. Masticola, A. B. Bondi, and M. Hettish, “Model-based scalabil-ity estimation in inception-phase software architecture.” in Proc.8th International Conference on Model Driven Engineering Languagesand Systems, 2005, pp. 355–366.

[43] G. Brataas and P. Hughes, “Exploring architectural scalability,” inProc. 4th International Workshop on Software and Performance. ACMPress, 2004, pp. 125–129.

[44] E. Weyuker and A. Avritzer, “A metric to predict software scala-bility,” Proc. 8th IEEE Symposium on Software Metrics, pp. 152–158,2002.

[45] L. G. Williams and C. U. Smith, “QSEM: Quantitative ScalabilityEvaluation Method,” in Proc. International Computer MeasurementGroup, 2005, pp. 341–352.

[46] C. U. Smith and L. G. Williams, Performance Solutions: A PracticalGuide to Creating Responsive, Scalable Software. Addison-WesleyPublishing Company, September 2001.

[47] M. van Steen, S. van der Zijden, and H. J. Sips, “Softwareengineering for scalable distributed applications.” in Proc. 22ndInt’l Computer Software and Applications Conference, 1998, pp. 285–293.

[48] P. Jogalekar and M. Woodside, “Evaluating the scalability ofdistributed systems,” IEEE Transactions on Parallel and DistributedSystems, vol. 11, no. 6, pp. 589–603, 2000.

[49] K. R. Popper, The Logic of Scientific Discovery. Routledge, 1959.[50] S. Robertson and J. Robertson, Mastering the Requirements Process

(2nd Edition). Addison-Wesley Professional, 2006.[51] J. R. Ruthruff, S. Elbaum, and G. Rothermel, “Experimental

program analysis: a new program analysis paradigm,” in Proc.International Symposium on Software Testing and Analysis. NewYork, USA: ACM Press, 2006, pp. 49–60.

[52] R. Kazman, J. Asundi, and M. Klein, “Quantifying the costsand benefits of architectural decisions,” in Proc. 23rd InternationalConference on Software Engineering. Washington, DC, USA: IEEEComputer Society, 2001, pp. 297–306.

[53] W. Heaven and E. Letier, “Simulating and optimizing designdecisions in quantitative goal models,” in 19th IEEE RequirementsEngineering Conference, Sept. 2011.

[54] V. Nallur and R. Bahsoon, “Design of a market-based mechanismfor quality attribute tradeoff of services in the cloud,” in Proceed-ings of the 2010 ACM Symposium on Applied Computing. New York,NY, USA: ACM, 2010, pp. 367–371.

[55] S. Zardari and R. Bahsoon, “Cloud adoption: a goal-orientedrequirements engineering approach,” in Proceedings of the 2ndInternational Workshop on Software Engineering for Cloud Computing.New York, NY, USA: ACM, 2011, pp. 29–35.

[56] T. Chen and R. Bahsoon, “Scalable service oriented replication inthe cloud,” in IEEE International Conference on Cloud Computing,2011, July 2011, pp. 766 –767.

Leticia Duboc is a Lecturer at the Departmentof Computer Science at the State University ofRio de Janeiro (UERJ) . She also holds an Hon-orary Research Fellowship with the SoftwareEngineering Research Group at University ofBirmingham. Leticia has received her PhD in theDepartment of Computer Science at UniversityCollege London in March 2010. Prior to her PhD,she worked as a Researcher at Fortent (formerlySearchspace) and as a Research Fellow at Uni-versity College London. Her research interests

include scalability of software systems, requirements engineering andearly analysis of software qualities.

Emmanuel Letier is a Lecturer in the Depart-ment of Computer Science at University CollegeLondon. His research interests are in require-ments engineering and system design. He?sparticularly interested in the development ofpractical formal methods to assist engineers inelaborating, analysing, and evolving large-scalemodels of complex systems. He received hisPhD in Software Engineering from the Universityof Louvain in Belgium.


David S. Rosenblum is a Professor in the De-partment of Computer Science of the School ofComputing at the National University of Singa-pore (NUS). He received his PhD from StanfordUniversity in 1988. Before joining NUS, he wasa research scientist at AT&T Bell Laboratories inMurray Hill, New Jersey, from 1988 to 1996; anAssociate Professor at the University of Califor-nia, Irvine, from 1996 to 2002; the Chief Technol-ogy Officer and Principal Architect of PreCache,Inc., from 2001 to 2003; and Professor of Soft-

ware Systems at University College London from 2004 to 2011. Hisresearch interests include scalability of large-scale software systems,probabilistic modeling and analysis, and the design and validation ofmobile, context-aware ubiquitous computing systems. He is the recipientof the 2002 ICSE Most Influential Paper Award for his ICSE 1992paper on assertion checking, and the first ACM SIGSOFT Impact PaperAward in 2008 for his ESEC/FSE 1997 paper on Internet-scale eventobservation and notification (co-authored with Alexander L. Wolf). He isa Fellow of the ACM and IEEE.

APPENDIX APARTIAL IEF GOAL MODEL

Fig. 5. Refinement of the IEF Top-level Goals.

Fig. 6. Refinement of the Goal Maintain [Adequate FraudDetection Rules].

Fig. 7. Refinement of the Goal Achieve [Alerts Generated ForTransactions Matching Fraud Detection Rules].

ieee transactions on software engineering, vol. x,no. … · the goal-obstacle analysis steps of...

Documents