A domain ontology based approach for analytical requirements elicitation

Transcription

1 A domain ontology based approach for analytical requirements elicitation Fahmi Bargui, Hanene Ben-Abdallah, and Jamel Feki FSEG, University of Sfax Tunisia, Po Box 1088 Abstract - In recent years, goal-oriented approaches have been used in Data warehouse (DW) projects to elicit the analytical requirements of decision makers. However, these approaches still suffer from a lack of assistance in goal elicitation, and provide little support to generate the suitable information for decision-making from the defined goals. To address these limitations, in this paper we introduce a domain ontology that aims at formalizing the semantic relationships between decision makers goals, and representing explicitly the semantic links between the decision-making knowledge and the goals. The formal aspect of our ontology allows automated reasoning about the goals, and supports their decomposition which assists the automatic elicitation of these goals. Furthermore, the semantic links stored in the ontology ensure the automatic generation of suitable analytical requirements from the defined goals. Keywords: Ontology, Requirements analysis 1 Introduction A Data Warehouse (DW) is a special type of data repository dedicated for decision-making support, which organizes information into facts and dimensions based on Multidimensional (MD) modeling. Since a DW often integrates data issued from several data sources, the construction of its MD model is often guided by the analysis of these sources [1]. In fact, several approaches have been proposed to automate the construction of a MD model from given data sources, cf. [3]. These bottom-up approaches apply a set of heuristics to derive candidate facts from which the decision maker chooses the MD model better reflecting his/her requirements. Although bottom-up approaches can reach a high degree of automation, they ignore the decisionmaking requirements. As a result, they may produce a MD model that does not meet the decision makers needs. In addition, the decision maker has to invest a considerable effort in identifying which parts of the produced MD model are pertinent to his/her analysis. To overcome these limits, several approaches advocate a requirements-driven DW design process. The proposed topdown, cf. [5] and Mixed, cf. [4] approaches include a requirements analysis phase in order to first elicit the information required by the decision makers, and then derive an adequate MD model. Within the literature, there is a consensus that this phase should be goal-oriented for two main reasons: (i) the DW provides useful information to make decisions contributing to the achievement of the organization goals, and (ii) decision makers often express their requirements in terms of goals that the DW should support [5]. On the other hand, there are several goal-oriented approaches proposed in the literature for the development of information systems (e.g., I*[6] ). Thanks to their graphical languages and tool supports, these approaches gained acceptance both in the academic and industrial communities. However, their widespread usage is hindered by their lack of support in the elicitation of goals. In general, goal elicitation is conducted through the decomposition of high level goals into more concrete sub-goals, which requires domain knowledge and skills. Such knowledge is mastered by domain experts, and to the best of our knowledge, except for the work of Nabli et al [11], there is no attempt to formalize it in order to allow its interpretation by both humans and machines. In [11], the authors represent the technical concepts of decisionmaking in a decisional ontology. This latter contains the technical concepts of MD models (facts, dimensions, measures, etc) of a given domain. It can be used by a data warehouse expert to specify his/her analytical requirements. Even though the ontology specifies structural and semantic relationships between its technical concepts, it presents one major limit: it specifies neither the business process to evaluate nor the goals to fulfill, which are things most familiar to decision makers. This limit may hinder the identification of sub-goals and, consequently, the automation of goal elicitation. Furthermore, our literature review highlighted that requirements-driven approaches provide little or no assistance in identifying appropriate performance indicators to measure the fulfillment degree of the elicited goals. The same shortage is also present in identifying information (i.e. data to be stored in the DW) that could be analyzed when the defined/expected goals are not met. In most cases, such information is elicited informally, and without explicitly matching to the goals. Consequently, when decision maker s goals change, it is difficult to trace the parts of the MD model that should be modified.

2 In our previous work [7], we proposed an approach that addresses the two main limits in current MD modeling: goal elicitation, and the correspondence between the elicited goals and the derived MD model concepts. In this paper, we show how to automate the steps of this approach. As illustrated in Figure 1, the input of our approach is a domain ontology formalizing the decision-making concepts. The ontology assists in the identification of the analytical requirements elements pertinent to the decision maker goals. Furthermore, the semantic relationships between the decision maker goals, stored in the ontology, assist the decomposition of goals and, consequently, the goal elicitation step. Moreover, the formal aspect of our ontology, which makes the domain knowledge machine readable, provides for potentially new requirements to emerge. This contributes to the completeness of the resulting specified requirements. Finally, all elicited elements are organized in order to assist the filling of our template for analytical requirements specification [8]. The resulting template is then used as input of our approach (presented in [10]) which ensures both the validation of the specified requirements with respect to the available data sources, and the design of a DW loadable from these sources. In this approach, the analytical requirements are parsed to extract pertinent terms that could be fact, measures, dimensions or parameters. To decide on the multidimensional type of a term, our approach applies a set of matching and expansion rules on the data source represented through its data dictionary. Processes-Goals- Indicators graph in progress I 1 G 1 G G 2 P 1 I 2 P 2 Specified Analytical Requirements Requirements analyst 1) Business processes elicitation 2) Goals elicitation 3) Indicators elicitation 4) Analytical queries generation Domain ontology Fig.1. Overview of our analytical requirements elicitation approach. G (Goal), P (Process) and I (Indicator). The rest of this paper is organized as follows. In the next section, we present our NL-based requirements specification template. In section 3, the description of the decision-making ontology is given along with an ontology for the commercial domain. Section 4 explains how the ontology is used to automate the elicitation of analytical requirements elements. Finally, Section 5 summarizes our proposal and presents our future work. G2 M2 G P2 Decision maker Requirements Decision maker analyst 2 Analytical requirements definition In our previous work [8], we have defined a Natural Language (NL) based template for analytical requirements specification. The components of this template were determined through an empirical study covering samples of decision-making processes (cf. [9]). As illustrated in Figure 2, in addition to meta-data documenting each template instance, the template identifies the business process being analyzed and the goals of the analyses. The realization of each goal is measured through an indicator monitored through one formula. For instance, the performance of the business process sales can be analyzed through the achievement of the goal increase sales. The achievement degree can be measured through the indicator turnover growth rate. The decision maker (Actor in the template) can fix a target value (estimated value) that the process must reach for a given goal during a period of time not exceeding an estimated deadline. The attained value for a goal is measured by the corresponding indicator. 0..n Dimensional- Marker <<Abstract>> AnalyticalQuery {disjoint} <<Abstract>> Marker 0..n Comparative- Marker Fig.2. Analytical requirements template metamodel The analysis of the discrepancy between the attained and target values allows the decision maker to evaluate the realization level of the goal and, hence, to judge the performance of the analyzed process. In the case of a negative variation, the decision maker notes an anomaly and looks for its origins. To do so, he/she examines detailed information retrieved from the DW through analytical queries. These queries refer to the indicator and formula terms. To provide for a flexible requirements specification, our template allows decision makers to express their analytical queries in Natural Language (NL). Note that, In accordance with, a NL is the best means of expressing analytical requirements, mainly because it facilitates communications with the decision maker. However, the diversity of writing styles often causes semantic ambiguities. To overcome this difficulty, we chose to fix an expression style while benefiting from the advantages of NL. To identify this expression style, we conducted an interview with twenty decision makers at different hierarchical levels (executives, managers ) and belonging Actor specify RequirementsTemplate Title Author UpdateDate Description Indicator Label Formula is_analysed_through control BusinessProcess fulfill Goal is_measured_by TargetValue Deadline

3 to nine different domains (commercial, e-commerce ). In the interview, each decision maker was asked to write a set of queries describing samples of OLAP ( On-Line Analytical Processing) analyses he/she used to perform in decisionmaking. Our study of the 200 collected queries allowed us to elaborate a query format formalizing the recurrent and common components of these queries [8]. Furthermore, through our study, we identified two formats of analytical queries: simple and compound queries. As illustrated in Figure 3, a simple query includes one indicator and several analysis axes each of which is introduced by one dimensional marker. SIMPLE QUERY Analyze theturnover by customer s name and address Verb indicator Dimensionalmarker Analysis axis COMPOUND QUERY (two indicators) Analyze the turnover by product and the delivery by supplier SIMPLE QUERY SIMPLE QUERY Fig.3. Format of simple queries On the other hand, a compound query can always be divided into two or more simple queries. Figure 4 illustrates the decomposition of a compound query into two simple queries. Analyze the turnover by product Analyze the delivery by supplier Fig.4. Decomposition of a compound query into simple queries For the sake of simplicity of query processing, we adopt the simple query format as a means of analytical requirements specification in our template. This query format formalizes frequent writing styles of analytical queries. Moreover, it includes dimensional markers to introduce analysis axes, and comparative markers to specify analyses where the comparison between the realized and target values is significant. In addition, we have demonstrated that analytical requirements specified according to our template can be transformed to a MD model validated with respect to a given data source [10]. 3 A decision-making ontology We have conducted a second interview with decision makers at different hierarchical levels and belonging to different domains. The interview aimed at identifying the terminology used in the decision-making process. As illustrated in Figure 5, our study identified the following concepts:. DecisionMaker: a person in the enterprise having the responsibility to evaluate and control the performance of a business process. BusinessProcess: is a collection of related activities that produce a specific service or product (serve a goal) for a particular customer. Goal: a measurable goal that a business process must reach during a given period of time. Goals can be classified into quantitative and qualitative. Quantitative goal is measurable, i.e. its achievement degree is evaluated by comparing an estimated value that the goal must reach (fixed by decision maker) with a realized value of the goal (calculated through an indicator). The period designates the latest time for achieving the goal. Qualitative goals do not have these properties and, therefore, must have a textual description. The study of qualitative goals is beyond the scope of this paper. Indicator: provides a value (calculated through a formula) designating the realization level of the corresponding goal. AnalysisAxis: over time, an indicator produces different values that could be aggregated (SUM, MAX, AVG ) according to an analysis axis. The aggregated value represents a point of view or a perspective that decision makers use in analysis tasks. AnalysisLevel: an analysis axis is composed of several analysis levels each of which represents a granularity echelon to aggregate indicator values. For instance, SupplierID, its City and Country are three analysis levels. Fig.5. Decision-making Ontology metamodel in Protégé (thesaurus part)

4 AnalysisAttribute: an analysis level has a name that may not be significant enough (e.g., SupplierID or a surrogate key). The role of an analysis attribute is to provide a textual description that explains the meaning of this analysis level name; e.g., the supplier name (Sname). AnalysisHierarchy: The analysis levels are organized into analysis hierarchies where level names are semantically ordered from the finest to the highest granularity. As an example, the SupplierID, City, Country build a hierarchy. Relationships formalize semantic links that associate concepts in the ontology. For the sake of clarity, we adopt the following abbreviations: P, G, D, I, F, A, H, L and At to designate, respectively, a business Process, a Goal, a Decision maker, an Indicator, a Formula, an Analysis axis, a Hierarchy, a Level and an Attribute. The identified relationships for the ontology are described as follows: Control(D, P): The decision maker D controls the performance of the business process P. Fulfill(P, G): The business process P is defined to fulfill the goal G. Is_Measured_By(G, I): The fulfillment degree of the goal G is measured by the indicator I. Is_Calculated_Through(I, F): The value produced by the indicator I is calculated through the formula F. Is_Anlyzed_Through(I, A): The indicator I is analyzed through the analysis axis A. Is_Composed_Of(A, H): The analysis axis A is composed of a hierarchy H. Has_Level(H, L): Hierarchy H has level L. Is_Described_By(L, At): The level L is described by the analysis attribute At. Require(G, G1): The fulfillment of goal G requires the achievement of G1 Figure 6 illustrates an instance for the commercial domain of our ontology metamodel. In this instance, the concept SalesManager is defined to control the performance of the three business processes: Order, AuctionOrder and Delivery; each of which must fulfill some goals. For instance, the process Order is defined to fulfill the goal IncreaseSales. The realization of this later requires the achievement of three goals: IncreaseCustomers, ProductAvailable and IncreaseShops. Note that relationships among goals are represented in the ontology by means of predicates. For example, the realization of the goal IncreaseSales requires the availability of the products in the stock, and either increasing the customers or shops. This knowledge is represented in the ontology through the predicate :(Require (IncreaseSales, IncreaseCustomers) Require (IncreaseSales, IncreaseShops)) Require (IncreaseSales, ProductAvailable). On the other hand, the fulfillment degree of each goal (e.g., IncreaseSales) is measured through an indicator (e.g., Turnover). For example, the values produced by the indicator Turnover are calculated through the Formula: (price * quantity sold). This indicator could be analyzed according to the product perspective during a period of time, which allows the decision maker to identify both the most-in-demand and the least-in-demand product. Additionally, when the target value of the indicator is not reached, the decision maker notes an anomaly and looks for its origin by carrying out various analyses of this indicator according to different analysis axes. These axes provide the decision maker with detailed values of the indicator. The comparison of these detailed values with their corresponding target values allows the decision maker to locate the problem at certain levels of the analysis axis. Fig.6. An extract of the commercial domain ontology (the thesaurus part)

5 Fig.7. An extract of the analysis axis concept (product) Figure 7, shows various levels organized by analysis hierarchies for the analysis axis product. For example, for the hierarchy family, the indicator Turnover could be analyzed according to the level category of a product. This gives the decision maker detailed values of the Turnover by category of product. The comparison of each realized value with an estimated target value allows the decision maker to judge what category of product is not sold as expected. Our domain ontology includes also inference rules. These later are defined by the domain experts (i.e. decision makers) and identified based on the semantic relationships among concepts of the domain. An inference deduces a set of conclusions from a set of premises, possibly under a given condition. The premises express constraints on the concepts, and designate expressions always known to be true by the domain experts. Therefore, they represent knowledge (stored in the ontology) that cannot be proven or contested. When an inference rule is applied, the reasoning engine matches the premises formulas with the knowledge stored in the ontology to infer a set of new knowledge, as conclusions, not explicitly stored. In the following section, we show how the domain ontology is used to automate the elicitation of analytical requirements. For this, we use eight queries and two inference rules; they are to assist the elicitation of our analytical requirements template s components. 4 Using the ontology to elicit analytical requirements As shown in Figure 1, our elicitation process uses four steps to extract the following components: the business processes to evaluate (step 1), the goals to fulfill (step 2) and the indicators that measure the achievement degree of the goals (step 3). These components are derived from the ontology, and then they are organized by the decision maker into a Processes-Goals-Indicators (PGI) graph. This graph shows explicit links between the derived components and allows a better understanding of the elicited requirements. The last step (step 4) extracts, for each indicator, all potential analysis axes, and then generates a set of candidate NL analytical queries (see Section 2) from which the decision maker selects a subset reflecting his/her needs as well as possible. In what follows, we will refer to the ontology depicted in Figure 6 to illustrate each step of our elicitation process. Step 1: business processes elicitation In this first step, all business processes, in the ontology, that are associated to the current decision maker D with a relationship control are retrieved by executing the following query: Query 1. List all Business Processes controlled by a given Decision Maker. Suppose that the current decision maker is a SalesManager. The execution of Query 1 on our running example (Figure 6) returns three business processes: Order, Delivery and AuctionOrder. The next step involves selecting the adequate process that should be added to the PGI graph. If the sales manager chooses to evaluate the Order process, then we will get the part of the graph depicted in Figure 8, annotated with S1. The next step of our process elicits the goals that have to be fulfilled by the identified business process. Step 2: goals elicitation Retrieving goals is an iterative task. Each iteration input is a process P elicited through step 1, whereas its output is a set of goals that the process must fulfill. We identify two categories of goals. The first category, we call High level goals, results from the execution of the following query:

6 Query 2. List all Goals that must be fulfilled by a given Business process. The decision maker chooses a subset from the resulted goals. Then the selected goals are added to the PGI graph. For example, for the selected process order, Query 2 returns the high level goal IncreaseSales added to the PGI graph (see figure 8) and annotated with S2. In the case of a complex goal, it is necessary to decompose it into more concrete sub-goals, we call operational goals (second category). These later are deduced using the following inference rule: Rule 1. If a process P is defined to fulfill a goal G, and G requires G1, then P must fulfill G1 to achieve G. The application of Rule 1 returns all goals that are indirectly related to the process P via the transitive closure of the relation require obtained by the subsequent Rule: Rule 2. If a goal G requires G1, and G1 requires G2, then G requires G2. The first application of Rule 1 gives goals at a second level of abstraction, from which the decision maker D chooses those that better reflect his/her requirement. For example, in the case of the goal IncreaseSales, the application of Rule 1 will propose the following goals: IncreaseCustomers, ProductAvailable and IncreaseShops. Figure 8 shows the two selected goals annotated with S2.1. Next, for each selected goal, Rule 1 is applied again (second application) to produce goals at a lower level of abstraction. This rule is applied as many times as there are goals in the ontology related by a require relationship. For instance, the result of the second application of Rule 1 is annotated in Figure 8 with S2.2. Step 3: retrieve indicators The achievement of each goal in the PGI graph is measured through the difference between the attained value calculated by the indicator and the target value. Sales- Manager S1 <<control>> Order <<require>> S2.1 ProductAvailable <<is_measured_by>> QuantitySold <<fulfill>> IncreaseSales <<require>> <<require>> S2.2 DiscountPrices <<is-measured-by>> DiscountAmount S2 S1 IncreaseCustomers <<is_measured_by>> S2.1 Turnover <<is-measured-by>> PercentageNewCustomers Fig.8. Part of the constructed PGI graph For each goal G the corresponding indicator I is retrieved from the ontology by executing Query 3: Query 3. Select the Indicator that measures a given Goal The formula needed to calculate the attained value of an indicator I is then obtained from the ontology by Query 4: Query 4. Select the Formula of a given Indicator. The annotation text in Figure 8 highlights the output of this step. Step 4: analytical queries generation This step identifies, for each tuple (P,G,I) in the PGI graph, the relevant analysis axes, and uses the simple NL query format (cf. section 2) to generate the analytical queries. The analysis axes are deduced from the ontology by executing the following query: Query 5. List all Analysis Axes of a given Indicator. We propose the template (Process, Goal, Indicator, Choice of analysis axes) to represent the result of Query 5. This template assists the decision maker by proposing all possible analysis axes from which he/she selects those relevant to his/her analysis tasks. Table 1 shows the result of Query 5 for the business process Order. Note that the analysis axis Time is checked by default since any analysis must be realized during a given period of time. TABLE 1. Template for choosing the analysis axes related to the process order. P(Business Process), G (Goal), I (Indicator) and? ( choice) P G I? analysis axes? SalesPerson? Customer IncreaseSales Turnover? Product? Product Order ProductAvailable QuantitySold? store IncreaseCustomers DiscountPrices PercentageNewC ustomers DiscountAmount? SalesPerson? Customer? Product The output of this step is a set of tuples of the form T i = (P, G, I, A) where A indicates the set of selected analysis axes for the tuple (P, G, I). Suppose that the decision maker has chosen the tuple T 1 = (order, IncreaseSales, turnover, {SalesPerson, Customer, Product, Time}. The next step involves the derivation of the analytical queries for each tuple T i. To do so, for each selected analysis axis A A in T i, the corresponding analysis hierarchies H are deduced from the ontology by the following query: Query 6. List all analysis hierarchies of a given analysis axis. Then, for each analysis hierarchy H H, the corresponding analysis levels and analysis attributes are derived by the subsequent queries:

7 Query 7. List all analysis level of a given analysis hierarchy. Query 8. List all analysis attribute of a given analysis level. The resulted analysis levels and analysis attributes of the queries 7 and 8 are combined with the analysis axis A A and the indicator I in the tuple T i, to generate an analytical query. For example, for the case of the analysis axis Product A in T 1, the execution of queries 6 and 7 will generate the analytical queries illustrated by Table 2. Note that, for each hierarchy, the analytical query including the first level of analysis, i.e. code, is selected by default since every analysis hierarchy must contain at least a root called the first analysis level. The last step of our analytical requirements elicitation process organizes the elicited information according to our requirements template. Figure 9 shows a part of the graphical representation of the resulted requirements. TABLE 2. Choice of hierarchies and analytical queries for the analysis axis Product T1? Hierarchy Choice of analytical queries Analyze the turnover by product s code and? ProductUnity designation? Analyze the turnover by product s unity? Analyze the turnover by product s code and? ProductPrice designation? Analyze the turnover by product s price Analyze the turnover by product s code and designation? ProductFamily? Analyze the turnover by product s category? Analyze the turnover by product s subcategory? ProductType Analyze the turnover by product s code and designation? Analyze the turnover by product s type 5 Conclusion and future work In this paper, we have proposed an ontology driven approach for analytical requirements elicitation. The formal aspect of the ontology automates the reasoning about the decision-making knowledge, which allows systematic requirements elicitation. In addition, the proposed approach enables a more intuitive requirements analysis process, starting from the identification of the business processes to evaluate, followed by the identification of the goals that must be fulfilled and their decomposition from high-level goals into more concrete sub-goals. In turn, the goals provide for the identification of the indicators and their associated formulas that measure the achievement degree of the defined goals. The last step of our requirements elicitation generates a set of analytical queries that can be used by the decision maker to carry out different analysis tasks when his/her goals are not met. The output of the proposed approach is a template that ensures the traceability between the elicited requirements elements. This traceability ensures a better understanding of the specified requirements, and facilitates the maintenance of the MD model when changes in the goals occur. Although the issue of completeness of our ontology, for a given domain, still needs more investigation, we can have several semi-automated techniques to do it. More precisely, many existing ontologies for various domains represented in standardized OWL language, can be easily used to improve the population of our ontology. Furthermore, some existing approaches that extract ontological concepts and their relationships from NL documents can be used to extract the concepts goals, indicators and business processes from available organizations Balanced Scorecard. Furthermore, we are currently working on finalizing a supporting tool for our approach. Our immediate future work comprises the evaluation of the obtained results within a case study. As a long term research axis, we plan to study how the evolution of the decision-making ontology may be handled. Meta-data TITLE SUMMARY Order process analysis UPDATE DATE 08/03/2011 AUTHOR ACTOR PROCESS Goal 1: Increase the sales This requirement analysis theperformance of the process order according to Fahmi Bargui Sales Manager Order INDICATOR 1 LABEL Turnover FORMULA ( price * quantity sold ) TARGET ANALYTICAL QUERIES TND 1) Analyze the turnover by product s code and designation. 2) Analyze the turnover by product s category. 3) Analyze the turnover by product s sub- category. 4) Analyze the turnover by month. Fig.9. Extract of the specified analytical requirements 6 Reference [1] W. Inmon, Building the Data Warehouse. Wiley & Sons, [2] E. Yu, Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering. In Proc. 3rd IEEE Int. Symposium on Requirements Engineering, USA, pp , [3] J. Feki, Y. Hachaichi, Conception assistée de MD: Une démarche et un outil. Journal of Decision Systems, vol. 16, no. 3, pp , [4] P. Giorgini, S. Rizzi, M. Garzetti, GRAnd: A goal-oriented approach to requirement analysis in data warehouses. Journal of Decision Support Systems, vol. 45, no.1, pp. 4-21, [5] J.-N. Mazón, J. Pardillo, J. Trujillo, A Model-Driven Goal-Oriented Requirement Engineering Approach for Data Warehouses. ER Workshops, LNCS vol. 4802, pp , [6] J. Mylopoulos, L. Chung, E. Yu, From Object-Oriented to Goal-Oriented Requirements Analysis. Communications of the ACM, vol. 42, no. 1, pp , [7] F. Bargui, H. Ben-Abdallah, J. Feki, Analyse des besoins analytiques : une approche dirigée par les buts et basée processus métiers. In Proc. 14th IBIMA, Turkey, pp , [8] F. Bargui, J. Feki, H. Ben-Abdallah, A natural language approach for data mart schema design. In the 9th Int. ACIT, Tunisia, [9] M. Mard, R.R. Dunne, E. obsborne, J.S. Rigby, Driving your company s value: strategic benchmarking for value. Wiley & Sons, [10] F. Bargui, H. Ben-Abdallah, J. Feki, Multidimensional Concept Extraction and Validation from OLAP Requirements in NL. In Proc. the IEEE NLP-KE, China. pp , [11] A. Nabli, J. Feki, F. Gargouri, An Ontology Based Method for Normalisation of Multidimensional Terminology, SITIS 2006, LNCS 4879, pp , 2009.