Available online at www.sciencedirect.com

s 45 (2008) 4–21www.elsevier.com/locate/dss

Decision Support System

GRAnD: A goal-oriented approach to requirementanalysis in data warehouses

Paolo Giorgini b, Stefano Rizzi a,⁎, Maddalena Garzetti b

a DEIS, University of Bologna, Viale Risorgimento 2, 40136 Bologna, Italyb DIT, University of Trento, Italy

Available online 29 January 2007

Abstract

Several surveys indicate that a significant percentage of data warehouses fail to meet business objectives or are outright failures.One of the reasons for this is that requirement analysis is typically overlooked in real projects. In this paper we propose GRAnD, agoal-oriented approach to requirement analysis for data warehouses based on the Tropos methodology. Two different perspectivesare integrated for requirement analysis: organizational modeling, centered on stakeholders, and decisional modeling, focused ondecision makers. Our approach can be employed within both a demand-driven and a mixed supply/demand-driven designframework.© 2006 Elsevier B.V. All rights reserved.

Keywords: Data warehouse design; Requirement analysis; Conceptual design; Goal-oriented analysis

1. Introduction

Data warehouse (DW) projects are inherently risky.In confirmation of this, several surveys indicate that asignificant percentage of data warehouse projects fail tomeet business objectives or are outright failures. Thereasons for a failure are often related to how the orga-nization reacts to the project or to the low quality of data,but in several cases they may be traced back to how thedesign process was conducted. In particular, a commondesign-related reason for failure is that requirement

⁎ Corresponding author. Tel.: +39 051 2093542; fax: +39 0512093540.

E-mail addresses: paolo.giorgini@unitn.it (P. Giorgini),srizzi@deis.unibo.it (S. Rizzi), garzetti@dit.unitn.it (M. Garzetti).

0167-9236/$ - see front matter © 2006 Elsevier B.V. All rights reserved.doi:10.1016/j.dss.2006.12.001

analysis is typically overlooked in DW projects, for thefollowing reasons [24]:

• Warehousing projects are long-term projects, andit is very difficult to anticipate future require-ments for the decision-making process; conse-quently, only a few requirements can be statedfrom the beginning.

• Information requirements for DW applications aredificult to specify because decision processes areflexibly structured, poorly shared across large orga-nizations, jealously guarded by managers, and un-stable over time in keeping up with evolving businessprocesses.

• Requirements for decision making often refer to in-formation that does not exist in the required form,and must be derived from data sources by integrating,transforming, and cleaning them.

5P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

Most methodologies for DW design claim there mustbe a phase dedicated to analyzing the business re-quirements (e.g., [8,13,16,20]), still there is no consen-sus on what relevance and priority should be assigned toit. Indeed, the approaches to DW design are usuallyclassified in two categories [24]:

• Supply-driven (also called data-driven) approachesdesign the DW starting from a detailed analysis of thedata sources [11,9,19]. User requirements impact ondesign by allowing the designer to select whichchunks of data are relevant for the decision-makingprocess and by determining their structuring accord-ing to the multidimensional model.

• Demand-driven (or requirement-driven) approachesstart from determining the information requirementsof business users [21,3]. The problem of mappingthese requirements onto the available data sources isfaced only a posteriori, by designing proper ETLroutines.

While supply-driven approaches simplify the de-sign of the ETL because each data in the DW cor-responds to one or more attributes of the sources, theygive user requirements a secondary role in determiningthe information contents for analysis as well as givethe designer little support in identifying facts, di-mensions, and measures. Conversely, demand-drivenapproaches bring requirements to the foreground, thusensuring that the DW will be tightly tailored to theusers' needs, but require a larger effort when designingETL.

Supply-driven approaches are feasible when all ofthe following are true: (1) detailed knowledge of datasources is available a priori or easily achievable; (2) thesource schemata exhibit a good degree of normalization;and (3) the complexity of source schemata is not toohigh. In practice, when the chosen architecture for theDW relies on a reconciled level (or operational datastore) these requirements are largely satisfied, in fact,normalization and detailed knowledge are guaranteed bythe source integration process. The same requirementsare also satisfied, thanks to a careful source recognitionactivity, in the frequent case when the source is a singlerelational database, well-designed and not very large. Ina supply-driven approach, conceptual design is heavilyrooted on source schemata and can be largely automated(e.g. see [9]). Our in-the-field experience shows thatrequirement analysis can then be carried out informally,based on simple requirement glossaries (such as in [14])rather than on formal diagrams. On the other hand, suchan informal approach is unsuitable for a demand-driven

framework, that needs a more structured and compre-hensive technique.

In this paper we propose GRAnD (Goal-orientedRequirement Analysis for Data warehouses), a goal-oriented technique for requirement analysis in DWsbased on the Tropos methodology [2]. GRAnD can beemployed:

• within a demand-driven framework, that is the onlyalternative whenever a deep analysis of data sourcesis unfeasible, or data sources reside on legacysystems whose inspection and normalization is notrecommendable. In this case, conceptual design willbe directly based on requirements.

• within a mixed supply/demand-driven framework. Inthis case, requirement analysis and source inspectionare carried out in parallel; conceptual design is stillcarried out in a semi-automated way, as in the supply-driven framework, but it exploits user requirementsto reduce complexity. The mixed framework isrecommended when source schemata are well-known, and their size and complexity are substantial.In fact, the cost for a more thorough and formalanalysis of requirements is balanced by the acceler-ation of the conceptual design.

In GRAnD, as in Tropos, analysis is focused on whatin software engineering is called early requirements. Inother words, analysis concerns the high-level objectivesof the stakeholders and decision makers rather than thespecific functionalities of the system-to-be (in this case,the DW) and the organizational setting where it willoperate. This enables the analyst to understand andexplore the real motivations (the why) behind the users'requests before getting down to explore the possiblesolutions for their implementation. As commonly re-cognized in the software engineering literature [25],analyzing early requirements will significantly decreasethe possibility of misunderstanding the users' requestsand, consequently, reduce the risk of failure for the DWproject.

GRAnD adopts two different perspectives for re-quirement analysis: organizational modeling, centeredon stakeholders, and decisional modeling, focused ondecision makers. Decisional modeling is directly relatedto the information needs of decision makers; with ref-erence to the terminology introduced in [24], it achievesto be analysis. On the other hand, organizational mod-eling is aimed at as is analysis; it has a primary rolein enabling identification of facts and in supportingthe supply-driven component of the approach. Thediagrams produced, that relate enterprise goals to facts,

6 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

dimensions, and measures, are then used during con-ceptual design. Within a demand-driven design frame-work, the requirements are translated into a conceptualschema to be mapped on data sources a posteriori.Within a mixed framework, while the data sources arestill explored to shape hierarchies, user requirementsplay a fundamental role in restricting the area of interestfor analysis and in determining facts, dimensions, andmeasures.

The paper is structured as follows. In Section 2 wesummarize the most relevant literature related to re-quirement analysis in DW design. Section 3 illustratesthe technique we propose for requirement analysis bydiscussing organizational and decisional modeling.Section 4 shows how our technique results in con-ceptual design within both demand-driven and mixeddesign frameworks. Section 5 introduces the prototypesupporting our approach. Finally, Section 6 draws theconclusions.

2. Related literature

In the field of DW design, it is necessary to dis-tinguish between supply-driven and demand-drivenapproaches. The prototypical supply-driven approachdates back to 1992, when Inmon claimed that the de-velopment of DWs is data-driven, as opposed to therequirement-driven development of operational systems[12]. Other supply-driven approaches were proposed in[11], [9], and [19], where conceptual design of the DWis rooted in the schema of operational sources and iscarried out starting, respectively, from the identificationof measures, from the selection of facts, and from aclassification of the operational entities. Also the com-prehensive design method described in [16] leans on aconceptual model; a mixed approach to conceptualdesign is recommended, but no further details are given.

In demand-driven approaches, collecting userrequirements is given more relevance. The approachdescribed in [18] shares some similarities with ours,since it is based on the i⁎ framework. However, re-quirements are directly used to build a conceptual modelin a fully demand-driven perspective, without any feed-back from the data sources. Besides, organizationalmodeling is not supported. In [24], a wish-list for DWdesign methodologies is proposed, and a multi-stagetechnique for requirement analysis is outlined. Here, twodifferent phases are interlaced: as is analysis, aimed atanalyzing and describing the actual information supply,and to be analysis, aimed at analyzing the informationdemand and matching it with the supply. In [21], a goal-oriented approach based on the goal-decision-informa-

tion model is proposed. Though this approach sharessome similarities with ours, it mainly focuses on re-quirement analysis and does not show how to move fromrequirements to design. A process-oriented approach ispresented in [3], where three different perspectives atincreasing levels of detail, each associated to a specificrequirement template, are used. Though the authorsrecommend to iteratively and incrementally gather re-quirements with use cases, only a few details are givenand no examples are provided, so it is very hard toprovide a comparison. A comprehensive framework forrequirement management, based on the Unified Process,is proposed in [20]; though there is a strong emphasis ondocumenting the project through document templates,nothing is said about how to model requirements.

In [1], a goal-oriented method to support the iden-tification and design of DWs is presented. This approachcan be regarded, like ours, as mixed demand/supplydriven. The main difference is that organizational mod-eling is not supported and that requirement analysis startsfrom the goals of decision makers. Goals are analyzedseparately using abstraction sheets, and general con-siderations about how they relate to the organizationactivities are given in natural language. Conversely, inour approach an explicit goal model of the organizationis given and the analysis of decision makers' goals isdirectly related to such a model. Moreover, in our goalanalysis, goals are decomposed into subgoals and spe-cific relationships between goals are specified. Anotherimportant difference with our approach, is that wesupport early requirements analysis [6,25] that allows formodeling and analyzing processes that involve multipleparticipants (both humans and software systems) andthe intentions that these processes are supposed to ful-fill. By so doing, one can relate the functional and non-functional requirements of the system-to-be to relevantstakeholders and their intentions.

An interesting case-based comparison of supply-driven and demand-driven approaches can be found in[15]. Remarkably, it is concluded that data-oriented andgoal-oriented techniques are complementary, and maybe used in parallel to achieve optimal design.

Finally, it is worth mentioning that a few CASE toolsfor DW design have been implemented, either fromsoftware vendors or as research protoypes. In ADAPT[4] and in GOLD [17] the conceptual schema for theDW is directly drawn by the designer, thus a demand-driven approach is implied — though no active supportfor requirement analysis is given. Conversely, in WAND[10] the conceptual schema is semi-automaticallyderived from the source schemata, thus implementingde facto a supply-driven approach.

7P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

3. Requirement analysis with GRAnD

Tropos [2,5] is an agent-oriented software devel-opment methodology, based on the i⁎ conceptualframework [25], where the concepts of agent, goal,and related mentalistic notions are used to support allsoftware development phases, from early requirementanalysis to implementation. Tropos differs from othergoal-oriented methodologies since it moves the notionsof agent and goal to the early stages of software de-velopment. During early requirement analysis, therequirements engineer identifies the domain stake-holders and models them as social actors, who dependon one another for goals to be fulfilled, tasks to beperformed, and resources to be furnished. Through thesedependencies, one can answer why questions, as well aswhat and how, regarding system functionality. Answersto why questions ultimately link system functionality tostakeholder needs, preferences, and objectives.

The Tropos methodology has been successfullyapplied in different domains. In the following we sum-marize the part of the Tropos notation that can be used inthe DW context:

• Actors. An actor represents an enterprise stakeholder.More precisely, it can model a physical or softwareagent (e.g., Mr. Brown), a role, meant as an abstractcharacterization of the behavior one or more agentstake in a specific context (e.g., sale analyst), or aposition, i.e. a set of roles generally played by asingle agent (e.g., marketing manager). Graphically,actors are represented by circles.

• Dependencies. A dependency represents an “agree-ment” between two actors, one depending on the otherto respect the agreement. The agreement can be a goalto be fulfilled, a task to be performed, or a resource tobe delivered. In our context, the main interest is ongoals, that are represented as ovals.

• Actor diagram. It is a graph of actors related bydependencies, used to model how actors depend oneach other.

• Rationale diagram. It is used to represent the logicalfoundations that rule the relationships between actors.It appears as a balloonwithin which goals of a specificactor are analyzed and dependencies with other actorsare established. Goals are decomposed into subgoals,with either AND (all subgoals must be achieved) orOR (any of the subgoals must be achieved) semantics,possibly specifying the positive/negative contribu-tions of subgoals to goals. The intuitive meaning of apositive (negative) contribution is that the satisfactionof a goal encourages (discourages) the satisfaction of

another goal. Notations + and ++ (− and − −) specifythe different strengths of the contribution.

When analyzing user requirements for DWs, twoperspectives should be taken into account. Firstly, it isimportant to model and analyze the organizational set-ting in which the DW will operate (organizationalmodeling); this includes designing the actor diagram aswell as the rationale diagrams for each stakeholder.Secondly, in order to capture the functional and non-functional requirements of the DW, we need to designrationale diagrams for the decision makers, who arethe main actors in the decisional process (decisionalmodeling).

Fig. 1 summarizes the analysis phases encom-passed by these two perspectives, together with thediagrams they consume and produce, in order to pro-vide an overall picture of the GRAnD methodology. Inthe following subsections the phases are describedin detail with reference to a real case study, the BI-BANK project, developed at the University of Trentoin collaboration with DeltaDator S.p.a. BI-BANK is aproject that is developing a Banking Business Intelli-gence System which will able to support the decisionalprocess with a set of basic banking analyses. For sim-plicity, in this paper we only focus on analysis of thebanking transactions.

As concerns graphical notation, using Tropos inthe DW context requires some new concepts to beintroduced:

• Facts. In organizational modeling, a fact models a setof events that happen when a goal is achieved. Indecisional modeling, a fact is more properly meant asa possible focus of analysis related to an analysisgoal. In both cases, facts are graphically representedas rectangles connected to a goal.

• Attributes. They are fields whose value is providedwhen a fact is recorded to fulfill a goal. They aredenoted as small diamonds connected to goals.

• Dimensions. A dimension is a fact property thatdescribes a possible coordinate of analysis, i.e. apossible perspective for looking at the fact to fulfillan analysis goal. Dimensions are represented as smallcircles connected to goals.

• Measures. A measure is a numerical property of afact that describes a quantitative aspect that isrelevant for decision making. Graphically, mea-sures are represented as small squares connected togoals.

The graphical notation is summarized in Table 1.

Fig. 1. The GRAnD approach.

8 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

3.1. Organizational modeling

Organizational modeling consists of three differentphases: (i) goal analysis, in which actor and rationalediagrams are produced; (ii) fact analysis, in whichrationale diagrams are extended with facts; and (iii) at-tribute analysis, in which rationale diagrams are furtherextended with attributes. Each phase is a differentiterative process utilizing the diagrams produced by theprevious phase.

3.1.1. Goal analysisThe first step for goal analysis is to represent the

relevant stakeholders for the organization and theirdependencies by means of an actor diagram, in whichactors can represent agents, roles, or positions within theorganization. This starts with a very high-level analysisaimed at expressing the responsibilities and relationshipsinvolving the different components (e.g., departments)of an organization. Then, the analysis proceeds intogathering more detail by decomposing the high-levelactors in sub-actors (e.g., the divisions of a department)and ending up with the identification of the agent(s) whois responsible for each single activity. The analysis is

conducted by interviewing the stakeholders and produc-ing documentation organized in a number of templates.Three different types of templates are provided:

• Main actor, where the main actors of the analyzedenvironment are identified together with theirstrategic objectives and goals. A table of the form(Actor, Objectives) is used to collect theinformation.

• Sub-actor, where each main actor is decomposed intoa number of sub-actors (including roles, positions, andagents). For each main actor, a table of the form(Sub-actor, Type, Goals) is used to collectthe information.

• Dependencies, where all the dependencies amongactors are identified and analyzed. A table of the form(Depender, Dependee, Goal) is used tocollect the information.

The second step consists in analyzing goals of eachactor in more detail to produce a rationale diagram foreach actor. Goals are AND-decomposed and contributionlinks between goals are discovered. See for instance[7,23] for details on how goal analysis can be carried out.

Table 1Notation for actor and rationale diagrams

Symbol Meaning

Actor

Goal

Dependency

Fact

AND decomposition

OR decomposition

Attribute

Dimension

Measure

9P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

Goal analysis ends when all the relevant goals of eachactor have been analyzed and all the dependencies amongactors are established. As for the first step, the infor-mation are collected and organized using a predefinedtemplate. For each actor, we mainly use a table of theform (Goal, Sub-goal, InContrib, OutCon-trib), where InContrib is the list of goals thatcontribute to the satisfaction of the goal and Out-Contrib is the list of goals that receive a contributionfrom the satisfaction of the goal.

Note analyzing the dependencies is important becauseit allows new goals to be discovered for each actor, and ingeneral it explains the reasons behind some of the goals,thus leading to a comprehensive view and model of theorganization. The analysis, of course, is limited to someareas of the organization, thus excluding some aspectsthat are not considered to be relevant for the design of theDW. It is the responsibility of the analyst to decide whathas to be included and what not; however, we emphasizethat it is necessary to include in the model the externalactors (e.g., clients of the bank) who do not belong to theorganization but still play a crucial role in its activities.

Example 1. Fig. 2 shows a partial actor diagram for theBI-BANK case study. The Client depends on theBank for achieving the goal manage transactions,and on the ATM for the goal use ATM. Moreover, theBank depends on the ATM actor for the goal supply

ATM. Fig. 3 presents a part of the rationale diagram forthe Bank actor focusing on the goal of managingtransactions. The goalmanage transactions is decom-posed into manage debit transactions and managecredit transactions, and in turn manage debittransactions is decomposed into manage permanentpayments and manage occasional payments. Newdependencies may be discovered at this point, forexample, the Bank depends on the ATM to manageinternal ATM withdrawals.

3.1.2. Fact analysisThe objective of fact analysis is to identify all the

relevant facts for the organization. The analyst navigatesthe rationale diagram of each actor and extends it byassociating goals with facts that model the set of events tobe recordedwhen goals are achieved.Here the informationare collected using two different types of templates: Thefirst one is a simple table that describes each single fact(Fact, Description); and the second one is a tablein which each goal is associated with a number of facts(Goal, Facts). Fact analysis is carried out accordingto a top-down approach, in fact the analyst starts byidentifying relevant facts from the top goals of each actorand thenmoves down towards the leaf goals. Usually, factsassociated with leaf goals are not considered.

The structure of the rationale diagrams induces somerelevant relationships between facts. In particular, whena goal is decomposed in subgoals, all the facts related tothe subgoals become subfacts of the fact associated tothe goal. As we will see in Section 4.1.3, these inducedrelationships are useful for defining the final conceptualschema for the DW.

3.1.3. Attribute analysisAttribute analysis is aimed at identifying all the

attributes that are given a value when facts are recorded.Starting from the extended rationale diagrams producedin the previous phase, the analyst explores all thesubgraphs to associate goals with the attributes they use.Note that, in this phase, the attributes are identifiedwithout specifying their possible role as dimensions ormeasures; from the organizational point of view, attri-butes are simply data associated to goals. To collectinformation for attribute analysis, the analyst uses atable of the form (Attribute, Goal, Fact).

Example 2. Fig. 4 shows an extended rationale dia-gram for the Bank actor, still focusing on goalmanagetransactions. First, the fact transaction is associatedto the main goal manage transactions, the fact debittransaction to the goal manage debit transactions,

Fig. 2. An actor diagram for the BI-BANK case study.

10 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

and so on. Then, by analyzing the subgraph of the goalmanage ATM withdrawals that fact ATM withdrawalis associated with, we introduce attributes currency,date, card number, amount, etc.

3.2. Decisional modeling

After organizational modeling, the methodologyproposes a second type of analysis focused on the

Fig. 3. Rationale diagram for the Bank acto

goals of decision makers, i.e., the actors that play themost relevant role in the decision-making process. Herethe analysis is substantially different from the organiza-tional analysis since the main objective is not to modelthe organization as it is, but rather to model how the DWcan support the decisional process of the organization.Basically, we focus on the requirements of the DW fromthe perspective of the decision makers. The organiza-tional model is extremely important in this phase since it

r from the organizational perspective.

Fig. 4. Extended rationale diagram for the Bank actor from the organizational perspective.

11P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

actively supports the analyst during the identification ofthe facts to be associated with the decisionmakers' goals.

Firstly, all the decision makers are identified; then, foreach of them, four steps are carried out: (i) goal analysis,that produces rationale diagrams; (ii) fact analysis, thatextends them with facts; (iii) dimension analysis, thatfurther extends them with dimensions; and (iv) measureanalysis, that further extends them with measures.

3.2.1. Goal analysisSimilar to organizational modeling, goal analysis

starts by analyzing the actor diagram for the decisionmakers. Decision makers are identified and initialdependencies between them are established. The goalsassociated to each decision maker are then decomposedand analyzed in detail, to produce a set of rationalediagrams. Goals may be completely different from thoseanalyzed during organizational modeling, indeed theyare part of the decision process andmight be not included

in the operative process of the organization. The sametemplates used for organizational modeling are used hereto collect and organize information about goal analysis.

Example 3. Fig. 5 shows a rationale diagram fordecision maker Financial Promoter, focusing on thegoal of analyzing transactions. The goal analyzetransactions is OR-decomposed into analyze debittransactions and analyze ATMwithdrawals,which inturn are further decomposed. So, for instance, the goalanalyze debit transactions is OR-decomposed intoanalyze total amount and analyze number oftransactions.

3.2.2. Fact analysisLike for organizational modeling, rationale diagrams

are extended by identifying facts and associating them tothe goals of decision makers. Facts are possible objects ofanalysis, and correspond to business events that

Fig. 5. Rationale diagram for the Financial Promoter decision maker from the decisional perspective.

12 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

dynamically happen within the enterprise. Facts arenormally imported from the extended rationale diagramsproduced during organizational modeling. Indeed, veryoften the goals of decision makers are related to theinformation produced in the operational process, so thefacts associated to the organization activities are funda-mental for fulfilling the decision makers' goals. In somecases, the analyst can also introduce some new facts bydirectly analyzing the decision maker rationale diagrams.

3.2.3. Dimension analysisIn this phase, each fact is related to the dimensions

that decision makers consider necessary in order tosatisfy their decisional goals. Dimensions are identifiedby analyzing the leaf goals of the rationale diagram ofthe decision makers and the relevant facts associated tothe upper level goals. Here, analysis requires a stronginteraction with the decision makers in order to capturethe possible perspective of analysis. To support analysiswe propose a template based on two different tables, thefirst capturing of the relationship between goals, facts,and dimensions (Goal, Fact, Dimensions), thesecond describing dimensions (Dimension,Description).

3.2.4. Measure analysisFinally, the analyst associates a set of measures to

each fact previously identified. Analysis is carried outby analyzing the leaf goals and the facts associated tothe upper-level goals, and it requires a strong interactionwith the decision makers.

Example 4. In Fig. 6 the analyst associates fact trans-action, identified during organizational modeling (see

Fig. 4), to the goal analyze transactions. Then, di-mensions are connected to the goals associated to thefact; for instance, dimensions account number andmonth are associated to goal analyze total amount.Finally, two measures are identified for goal analyzetotal amount: total amount and average amount.

4. From requirement analysis to conceptual design

The organizational model produced by requirementanalysis represents the main data on which the enterpriseoperation is based, thus it comprises the most relevantattributes that are part of the source database. Onthe other hand, the decisional model describes the de-cision makers' needs, thus summarizing the role played,in glossary-based requirement analysis, by the glossariesof facts, dimensions, and measures and by the prelim-inary workload. In this section we explain how thesediagrams are used for conceptual design within,respectively, a mixed and a demand-driven framework.

4.1. Mixed design framework

The mixed framework joins the facilities of supply-driven approaches with the guarantees of demand-driven ones. In fact, the requirements derived duringorganizational and decisional modeling are matchedwith the schema of the source database to generate theconceptual schema for the DW. Three phases are in-volved: (i) requirement mapping, where facts, dimen-sions, and measures identified during decisionalmodeling are mapped onto entities in the sourceschema; (ii) hierarchy construction, where a basicconceptual schema is generated by navigating the

Fig. 6. Extended rationale diagram for the Financial Promoter decision maker from the decisional perspective.

13P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

source schema; and (iii) refinement, where the basicconceptual schema is edited to fully meet the user'expectations.

4.1.1. Requirement mappingDuring this phase the facts, dimensions, and

measures included in the extended rationale diagramsproduced by decisional modeling are mapped, wherepossible, onto the source schema. More precisely:

(1) Assuming that sources are modeled by a relationalschema, the facts of decisional modeling aremapped onto relations.

(2) Mapping of dimensions and measures is achievedby using the attributes represented during organi-zational modeling as a bridge. In fact, each suchattribute is mapped to a physical attribute in thesource schema on the one hand, and to adimension or a measure in the decisional modelon the other.

(3) Attributes in the organizational model that were notmapped to dimensions ormeasures in the decisionalmodel, are mapped nonetheless on the sourceschema; as we will see in Section 4.1.2, this may beuseful to provide the designer with an additionalchoice of dimensions and measures for the fact.

Example 5. In our case study, as shown in Fig. 7, factATM withdrawal is mapped to some WITHDRAWALStable in the source schema. Then, attribute card numberassociated to goal record withdrawal card number inthe organizational model is mapped to dimension card

number associated to the analysis goals analyze with-drawals amount and analyze number of withdrawalsin the decisional model; the same attribute card numbermight for instance correspond, on the source schema, toan attribute cardNumber within the WITHDRAWALStable. Similarly, attribute amount of goal record with-drawal amount corresponds to measure total amount ofthe analysis goalanalyzewithdrawals amount and to anattribute amount on the WITHDRAWALS table. Anexample of an attribute in the organizational model thatcannot be mapped to the decisional model but shouldnevertheless be mapped to the source schema is desti-nation a/c, associated to goal record transfer dest. a/c.

Interestingly, if the names in the extended rationalediagrams are chosen by the analyst consistently withthose in the source schema, this phase can be partiallyautomated. In particular, if the source schema was actu-ally obtained by normalizing and integrating differentsources – which very often is the case, especially whencomplex cleaning and transformation procedures arenecessary to improve data quality – its name space islargely under the designer's control. Otherwise aThesaurus must be built, as suggested in [1], in orderto establish the mappings between the organizationalmodel and the source schemata.

4.1.2. Hierarchy constructionThis phase implements the supply-driven part of

GRAnD. For each fact identified during decisionalmodeling and successfully mapped onto a relation F inthe source schema, the many-to-one associations

Fig. 7. Mapping from the decisional model (left) to the source schema (right) passing through the organizational model (center).

14 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

expressed in the source schema by foreign keys are iter-atively navigated, starting from F, to build the attributehierarchies and create a basic conceptual schema, e.g. inthe form of a fact schema. Fact schemata are the con-ceptual artifacts provided by the Dimensional Fact Model,proposed in [9] as a support for conceptual design ofDWs.Note that any other conceptual model for multidimen-sional databases could be equivalently adopted.

This phase can be largely automated, as discussed in[9] where an algorithm is proposed that creates attributehierarchies from the source schema. The underlying ideais that, given a relation, a functional dependency – i.e., amany-to-one association – holds between its primary keyand each of its attributes, including foreign keys. Since aforeign key maps on the primary key of another relation,that in turn functionally determines each of its attributes, atree of attributes related by functional dependencies – i.e.,a hierarchy – can easily be built by recursively navigatingthe source schema. In the following, considering thatfunctional dependencies are transitive, we will say that amany-to-one path exists from a relation R to any attributea in the schema if the primary key of R (transitively)functionally determines a.

Remarkably, while in the supply-driven approachdescribed in [9] navigation is “blind”, meaning that all theattributes connected to the fact F by a many-to-one pathare reached and included in hierarchies, here navigation isactively biased by the user requirements. In fact:

1. Every dimension d associated to a goal related toF andsuccessfully mapped from the decisional model to thesource (see Section 4.1.1) is included in the conceptualschema, and the full hierarchy rooted in d is generated

by navigation. If the path from F to d is not many-to-one but many-to-many, d is modeled as a multipledimension [22]; this means that multiple values of dcan be related to a single instance of the fact F.

2. Every measure m associated to a goal related to Fand successfully mapped from the decisional modelto the source is included in the conceptual schema,provided that a many-to-one path exists from F to m,and no hierarchy is generated for it.

3. For each attribute a in the organizational model thatcould be mapped onto the source schema but not ontothe decisionalmodel, the designer has different choices:3.1 Decide that a is not interesting for analysis and

ignore it.3.2 Decide that a may be interesting for analysis of

some fact F, in which case it should be includedin the conceptual schema for F. The designeralso has to choose the primary role of a:3.2.1 The rolemay be that of a dimension, in which

case the full hierarchy rooted in a is generatedby navigation and a is labeled as “supplied”in the conceptual schema. If the path from Fto a is not many-to-one but many-to-many, ais modeled as a multiple dimension.

3.2.2 The role may be that of a hierarchy attribute.In this case, if a has not already beenreached by navigation of the source schemastarting from some dimension (see point 1.),the designer selects one of the attributes inthe path from F to a as a new dimension d,and labels d as “supplied”.

3.2.3 The role may be that of a measure, providedthat a many-to-one path exists from F to a.

15P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

Even in this case, a is labeled as “supplied”in the conceptual schema.

4. Among the dimensions and measures associated to agoal related to F on the decisional model, those forwhich no mapping on the source schema could befound are nevertheless included in the conceptualschema for F and labeled as “demanded”.

5. All the attributes in the source schema that were notmapped and were not reached by navigation ofmany-to-one associations starting from a dimensionare not included in the conceptual schema for F.

Remarkably, the basic conceptual schemata generat-ed here may be considerably simpler and smaller thanthose generated in [9]. Besides, while in [9] the designeris asked for identifying facts, dimensions, and measuresdirectly on the source schema, here such identification isdriven by the diagrams developed during requirementanalysis. We also note that the names used for measuresin decisional diagrams can give the designer precioussuggestions regarding which aggregation operators touse: for instance, from Fig. 6 we may presume thatmeasure amount is to be aggregated through both thesum and the average operators.

Fig. 8. Preliminary fact schemata for facts ATM WITHDRAWA

Example 6. The preliminary fact schemata obtained forfacts ATM WITHDRAWAL and DEBIT TRANSAC-TION in the bank example are reported in Fig. 8. Con-sistently with the Dimensional Fact Model, the fact isrepresented as a box containing the measures; dimensionsare circles connected to the fact; hierarchies arerepresented as trees rooted in dimensions. For fact ATMWITHDRAWAL, dimensions currency date, cardnumber, and a/c are derived from the decisionalmodel, as well as measures number of withdrawalsand amount. The hierarchy rooted in a/c has been builtby navigating the source schema. Dimension internal/external has been added since, though the decisionalmodel does not represent it explicitly, the two separatesubgoals analyze internal ATM withdrawals andanalyze external ATM withdrawals suggest that theuserwill ask for distinguishing between these two types ofwithdrawal. Finally, measure withdrawal cost is labeledas “demanded” since it appears as a measure associated togoal analyze external withdrawals but not as anavailable attribute on the organizational model. As tofact DEBIT TRANSACTION, we only remark thatdimension destination a/c is labeled as “supplied” sinceit is present in the organizational model but has not been

LS and DEBIT TRANSACTION in a mixed framework.

Fig. 9. Fact schema for fact TRANSACTION after refinement in a mixed framework.

16 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

indicated by decision makers as a dimension in thedecisional model.

4.1.3. RefinementThis phase is aimed at rearranging the conceptual

schemata in order to better meet the user's needs. Thebasic operations that can be carried out to this purpose are:

1. Operations on facts1.1 Fact merge. Merging facts is beneficial when the

user is often interested in analyzing them togethersince they can be seen as particular cases of a moregeneral fact. Two or more facts G1…Gn can bemerged into a single fact if they have a commonsupergoal F in the decisional model. The resultingfact takes the name of F and has the union of themeasures, dimensions, and hierarchies of theGi's.A dimension that exists only within a subset of theGi's is marked as optional in F, meaning that itcharacterizes only a subset of the events modeledby fact F.

1.2 Fact split. A fact F may be split into n facts G1…Gn when most of its dimensions and measures arerelated to specific subsets of events. Each resultingfactGi includes only the dimensions and measuresthat better characterize it; each dimension isaccompanied by the corresponding hierarchy.

2. Operations on hierarchies2.1 Attribute prune. An attribute a may be dropped

from a hierarchy while preserving the subtreerooted in a. This is useful when neither a nor itsdescendant attributes are relevant for analysis.

Fig. 10. Preliminary fact schemata for facts ATM WITHDRAWAL a

2.2 Attribute graft. An attribute a may be droppedfrom a hierarchy while preserving the subtreerooted in a; the children attributes of a becomechildren of the parent attribute of a. This isuseful when a is not interesting for analysis butits descendants are.

2.3 Association adding. A many-to-one associationbetween attributes a and b may be added to ahierarchy, which results in changing to a the parentof attribute b in the tree representing the hierarchy[9]. Adding an association may be necessary inorder to model some functional dependency thatwas not correctly captured in the source schema.

2.4 Optionality. Optional attributes, i.e., attributesthat have a value only for a subset of instances ofthe hierarchy, should be detected and properlymarked on the conceptual schema.

3. Operations on measures3.1 Measure merge. Two or more measures that only

differ for their aggregation operator may be uni-fied, provided that the conceptual model adoptedsupports the representation of different aggrega-tion operators for the same measure.

Note that, thanks to the labeling of dimensions car-ried out during hierarchy construction, the decisionmakers and the designer are enable to distinguish, onconceptual schemata, what is needed and available(unlabeled dimensions/measures), what is needed butunavailable (dimensions/measures labeled as “de-manded”), what is available but not needed (dimen-sions/measures labeled as “supplied”). While the second

nd DEBIT TRANSACTION in a demand-driven framework.

Fig. 11. Fact schema for fact TRANSACTION after refinement in ademand-driven framework.

17P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

category may drive the designers in enriching the sourcedatabase or in considering new data sources, the thirdmay stimulate the decision makers to undertake newdirections of analysis.

Example 7. We assume that (1) users are not interestedin the client granularity, so attribute client is grafted;(2) the client address is not interesting, so address ispruned; (3) measure withdrawal cost can be com-puted during ETL; (4) dimension destination a/c isconsidered by users to be relevant for analysis. The twofacts ATM WITHDRAWALS and DEBIT TRANS-

Fig. 12. Accessing the dic

ACTION are merged into fact TRANSACTION, thatis the fact associated, in the decisional model, to thecommon supergoal of subgoals analyze debit trans-actions and analyze ATM withdrawals. In mergingthe facts, measures number of withdrawals andnumber of debit transactions converge in measurenumber of transactions. Measures total amount andaverage amount are merged into measure amount, tobe aggregated by both the sum and the averageoperators. Dimension internal/external is incorporat-ed into dimension type (meaning that, among thevalues for type, there also will be “internal ATMwithdrawal” and “external ATM withdrawal”). Dimen-sion card number is marked as optional since a cardnumber is defined only for some types of transactions;the same holds for destination a/c. The final factschema obtained is shown in Fig. 9.

4.2. Demand-driven design framework

Within a demand-driven framework, in the absenceof a priori knowledge of the source schema, thebuilding of hierarchies cannot be automated; the main

tionary in DW-Tool.

18 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

assurance of a satisfactory result is the skill and ex-perience of the designer, and her ability to fruitfullyinteract with the domain experts to capture the existingdependencies between attributes.

The starting point is a set of preliminary conceptualschemata obtained by associating each fact from thedecisional model with the corresponding dimensionsand measures. In the bank case, from the rationalediagram in Fig. 6 we immediately derive the preliminaryfact schemata in Fig. 10.

The next step is related to the building of hierarchies.While, in the case of the mixed framework, hierarchiesare determined by navigating the source schema, in thiscase they must be defined manually by strictly inter-acting with business users. This is undoubtedly the mostdifficult phase of the demand-driven approach; weproceed for each fact F as follows:

(1) Detect functional dependencies between dimen-sions of F and represent them in the form ofhierarchies.

Fig. 13. Organizational mo

(2) If F is also represented on the organizationalmodel, select all the attributes associated to thegoals related to F on the organizational model. Foreach attribute a that is not already present in theconceptual schema and is considered to beinteresting for analysis ofF, understand its primaryrole:2.1 The role may be that of a dimension, in which

case a is included in the conceptual schemaand labeled as “supplied”.

2.2 The role may be that of a hierarchy attribute.In this case, the designer selects one of theexisting dimensions, d, and properly connectsa to the hierarchy rooted in d.

2.3 The role may be that of a measure, in whichcase a is included in the conceptual schema asa measure and labeled as “supplied”.

(3) Repeat step 2. for all the other attributes in theorganizational model.

(4) Enrich hierarchies with other attributes possiblyindicated by the user, labeled as “demanded”.

deling in DW-Tool.

ts for decisional modeling.

1 See the Tropos web site (http://www.troposproject.org) for moredetails.

19P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

The issues to be faced afterwards are the same de-scribed for the refinement phase in the mixed framework.

Example 8. In fact ATM WITHDRAWAL, amongall the attributes associated to goals manage ATMexternal withdrawals and manage ATM internalwithdrawals on the organizational model, date isinserted as a supplied dimension. In fact DEBITTRANSACTION, attributes currency date and cardnumber are inserted as supplied dimensions. Then,during refinement, the functional dependency betweendate and month is detected, and the two facts aremerged as seen in the mixed framework to produce thefact schema in Fig. 11.

This approach is, in our view, more difficult to pursuethan the previous one. Nevertheless, it is the only al-ternative when a detailed analysis of data sources cannotbe made (for instance when the DW is fed from an ERPsystem, whose logical schema is huge and hardly un-derstandable), or when the sources come from legacy

Fig. 14. Importing fac

systems whose complexity discourages recognition andnormalization.

5. DW-Tool

GRAnD is supported by a prototypical CASE toolnamed DW-Tool1, which has been developed in Javaand supports the analyst and the designer in thefollowing activities:

• Collection of requirements. During the interviewswith the stakeholders, the analyst organizes theinformation acquired by filling in the templatesintroduced in Section 3.

• Dictionary management. The content of the templatesis used by DW-Tool to generate a general dictionaryfromwhich the analyst can select and see the description

20 P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

of each single entity in the models. Fig. 12 showsan example where the description of a fact is provided.

• Organizational modeling. The content of the tem-plates is also used to generate a basic organizationalmodel, including actor and rationale diagrams, thatthe analyst can further rearrange to better meet theuser's expectation (see Fig. 13).

• Decisional modeling. After the basic rationalediagrams have been generated from the templates,the analyst can extend them with facts, dimensions,and measures, typically by importing entities fromthe diagrams produced during organizational model-ing (Fig. 14).

• Conceptual design. If the designer decides to followa mixed approach, the source schema is acquired viaJDBC from the operational DBMS. As to require-ment mapping, DW-Tool proposes a basic choiceof mappings that are derived where possible bymatching names in the diagrams. Hierarchy construc-tion is fully automated, and the basic refinementoperations are supported. On the other hand, if ademand-driven approach is undertaken, the attributesrelated to the fact in the organizational model areimported, so that the designer can decide which roleto give them within the conceptual model of the DW.

6. Conclusion

In this paper we have proposed GRAnD, a goal-oriented methodology for requirement analysis in DWs,which can be used within both a demand-driven and amixed supply/demand-driven design framework. Webelieve that the adoption of GRAnD can help thedesigner to reduce the risk of project failure by ensuringthat early requirements are properly taken into accountand formalized – which ensures a “good” design – and,at the same time, that the resulting DW schemata aretightly rooted to the operational database –which makesthe design of ETL simpler.

Other modeling approaches, based for instance onUML, have been proposed in the literature to captureorganizational aspects during requirements analysis.However, such approaches do not provide adequateformalisms and techniques to map high-level users' goalsto design models. Conversely, GRAnD proposes alanguage and a methodology to directly derive the DWconceptual schema from the results of organizational anddecisional analysis.

Our methodology was applied to the BI-BANK casestudy, a project developed in collaboration with a com-pany based in Trento. The experience with the companywas extremely useful for refining and validating our

approach. We received positive feedback about themethodology and, in particular, about the importance ofderiving the requirements directly from the analysis of thestakeholders and decision makers goals. The case studyalso supported us in investigating the scalability of ourapproach. With regard to this, we verified that associatingan actor diagram with several rational diagrams, one foreach actor, has a crucial role in dealing with complexapplication domains. In fact, detailed requirement anal-ysis is carried out on rationale diagrams, whosecomplexity depends on how articulated the decisionaltasks of a single actor are (which is not directly related tohow large the application domain is). On the other hand,the actor diagram – on which the size of the applicationdomain, in terms of number of stakeholders, directlyimpacts – is drawn at a high level of abstraction, thus itscomplexity never becomes overwhelming.

References

[1] A. Bonifati, F. Cattaneo, S. Ceri, A. Fuggetta, S. Paraboschi,Designing data marts for data warehouses, ACM Transactions onSoftware Engineering Methodologies 10 (4) (2001) 452–483.

[2] P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, A.Perini, Tropos: an agent-oriented software development meth-odology, Journal of Autonomous Agents and Multi-AgentSystems 8 (3) (2004) 203–236.

[3] R. Bruckner, B. List, J. Schiefer, Developing requirements fordata warehouse systems with use cases, Proceedings AmericasConference on Information Systems, 2001, pp. 329–335.

[4] D. Bulos, Designing OLAP with ADAPT, Tech. rep., AtosOrigin, 1999.

[5] J. Castro, M. Kolp, J. Mylopoulos, Towards requirements-driveninformation systems engineering: the Tropos project, InformationSystems 27 (6) (2002) 365–389.

[6] A. Dardenne, A. van Lamsweerde, S. Fickas, Goal-directedrequirements acquisition, Science of Computer Programming 20(1–2) (1993) 3–50.

[7] P. Giorgini, E. Nicchiarelli, J. Mylopoulos, R. Sebastiani, Formalreasoning techniques for goal models, Journal of Data Semantics1 (2003) 1–20.

[8] M. Golfarelli, S. Rizzi, A methodological framework for datawarehouse design, Proceedings DOLAP, 1998, pp. 3–9.

[9] M. Golfarelli, D. Maio, S. Rizzi, The dimensional fact model: aconceptual model for data warehouses, International Journal ofCooperative Information Systems 7 (2–3) (1998) 215–247.

[10] M. Golfarelli, S. Rizzi, E. Saltarelli, WAND: a case tool forworkload-based design of a data mart, Proceedings SEBD,Portoferraio, Italy, 2002, pp. 422–426.

[11] B. Hüsemann, J. Lechtenbörger, G. Vossen, Conceptual datawarehouse design, Proceedings DMDW, Stockholm, Sweden,2000, pp. 3–9.

[12] W.H. Inmon, Building the Data Warehouse, QED Press/JohnWiley, 1992.

[13] R. Kimball, L. Reeves, M. Ross, W. Thornthwaite, The DataWarehouse Lifecycle Toolkit, John Wiley and Sons, 1998.

[14] J. Lechtenbörger, Data Warehouse Schema Design, Tech. Rep. 79,DISDBIS Akademische Verlagsgesellschaft Aka GmbH, 2001.

fields of data warehou

21P. Giorgini et al. / Decision Support Systems 45 (2008) 4–21

[15] B. List, R. Bruckner, K. Machaczek, J. Schiefer, A comparison ofdata warehouse development methodologies: case study of theprocess warehouse, Proceedings DEXA, 2002, pp. 203–215.

[16] S. Luján-Mora, J. Trujillo, A comprehensive method for datawarehouse design, Proceedings DMDW, Berlin, Germany, 2003.

[17] S. Luján-Mora, J. Trujillo, I.Y. Song, The gold model case tool:an environment for designing OLAP applications, ProceedingsICEIS, 2002, pp. 699–707.

[18] J.-N. Mazon, J. Trujillo, M. Serrano, M. Piattini, Designing datawarehouses: from business requirement analysis to multidimen-sional modeling, Proceedings International Workshop onRequirements Engineering for Business Need and IT Alignment,Paris, France, 2005.

[19] D. Moody, M. Kortink, From enterprise models to dimensionalmodels: a methodology for data warehouse and data mart design,Proceedings DMDW, Stockholm, Sweden, 2000.

[20] F.R.S. Paim, J.B. Castro, DWARF: an approach for requirementsdefinition and management of data warehouse systems, Proceed-ings International Conference on Requirements Engineering,Monterey Bay, CA, 2003.

[21] N. Prakash, A. Gosain, Requirements driven data warehousedevelopment, CAiSE Short Paper Proceedings, 2003.

[22] S. Rizzi, Conceptual modeling solutions for the data warehouse,in: R. Wrembel, C. Koncilia (Eds.), Data Warehouses and OLAP:Concepts, Architectures and Solutions, Idea Group, 2006.

[23] R. Sebastiani, P. Giorgini, J. Mylopoulos, Simple and min-imum-cost satisfiability for goal models, Proc. CAiSE'04,2004, pp. 20–33.

[24] R. Winter, B. Strauch, A method for demand-driven informationrequirements analysis in data warehousing projects, ProceedingsHICSS, Hawaii, 2003, pp. 1359–1365.

[25] E. Yu, Modelling strategic relationships for process reengineer-ing, Ph.D. thesis, University of Toronto, Department ofComputer Science (1995).

Paolo Giorgini is researcher at University of

Trento. He received his Ph.D. degree fromComputer Science Institute of University ofAncona (Italy) in 1998. Between March andOctober 1998 he worked at University ofMacerata and University of Ancona as re-search assistant. In November 1998 he joinedthe Mechanized Reasoning Group (MRG) at University of Trento as post-doc researcher. In

December 1998 he was researcher visiting at the Computer ScienceDepartment of University of Toronto (Canada) and more recently hewas visiting researcher at the Software Engineering Department ofUniversity of Technology in Sydney. He has worked on the developmentof requirements and design languages for agent-based systems, and theapplication of knowledge representation techniques to software reposi-tories and software development. He is one of the funder of Tropos, anagent-based oriented software engineering methodology. His publicationlist includes more than 130 refereed journal and conference proceedingpapers and eight edited books. He has been the coordinator for Universityof Trento of the European's Network of Excellence for Agent-BasedComputing (AgentLink I, II, and III), and he has contributed to theorganization of international conferences as chair and program committeemember, such as CoopIS, ER, CAiSE, AAMAS, EUMAS, AOSE, AOIS,and ISWC. He is Co-editor in Chief of the International Journal of Agent-Oriented Software Engineering (IJAOSE).

Stefano Rizzi received his Ph.D. for his workon autonomous agents in 1996 from theUniversity of Bologna, Italy. Currently he is

Full Professor at the University of Bologna,where is the head of the Data WarehousingLaboratory and teaches Advanced InformationSystems and Software Engineering. He has

published about 70 papers in refereed journals

and international conferences, mainly in the

sing, pattern recognition, mobile robotics, and

multi-agent systems. He joined several national research projects onthe above areas and has been involved in the EU PANDA thematicnetwork concerning pattern-base management systems. He currently isscientific supervisor of the data warehousing project of the Universityof Bologna. His current research interests include data warehousedesign, advanced architectures for business intelligence, ontologyvisualization, and bioinformatics.

Maddalena Garzetti received the M.S. degreein computer science from the University of

Trento, in 2001. She worked as researcherassistant from 2001 till 2004 at Department ofInformation and Communication Technologyof the University of Trento, and in 2005 shemoved at the provincial research institute ITCIrst of Trento. Currently, Maddalena works as senior software developer at ArsLogica ITLaboratories of Mezzolombardo, Trento, Italy.

Her research interests include database design and development, P2Pdatabases systems and data warehouse design support systems. She hascontributed to the development of several prototype research system,such as Hyperion database system, DW-Tool, and AMICUS.