Goal-Oriented BI

Goals are high-level objectives of an enterprise, organization, or system. The requirements engineering community has acknowledged the importance of goal-oriented approaches to system development many years ago. Yu and Mylopoulos observe that goals are important not just for requirements elicitation, but also for relating requirements, processes, and solutions to organizational and business contexts, and for enabling trade-off analysis and conflict resolution. Complete goal-driven development approaches now exist to support software development.

The Goal-oriented Requirement Language (GRL) is a graphical notation used to model and analyze goals. Although many goal-oriented languages exist, GRL is the first and currently only standardized one. GRL is part of the User Requirements Notation (URN), a standard of the International Telecommunication Union (ITU-T) intended for the elicitation, analysis, specification, and validation of requirements using a combination of goal-oriented and scenario-based modelling. In URN, GRL is complemented by a scenario notation called Use Case Map (UCM), which offers an operational or process-oriented view of a system in terms of causal scenarios composed of responsibilities optionally allocated to a structure of components and actors.

GRL enables the modelling of stakeholders, business goals, qualities, alternatives, and rationales. Modelling goals of stakeholders with GRL makes it possible to understand stakeholder intentions as well as problems that ought to be solved. GRL enables business analysts to model strategic goals and concerns using various types of intentional elements and relationships, as well as their stakeholders called actors (). Core intentional elements include goals (), softgoals () for qualities, and tasks () for decisions; activities, and alternative solutions. Intentional elements can also be linked by AND/OR decompositions (). Elements of a goal model can influence each other through contributions, displayed as arrows (→). Qualitative positive (make, help, some positive) and negative (break, hurt, some negative) contribution levels exist, as well as quantitative contribution levels on a scale from −100 (break) to +100 (make).

Figure 1 (left) illustrates in GRL some of the above concepts with a toy retail store example, where principals (captured as an actor) want increased profits (captured as a softgoal) while the staff (another actor) wants to have many work hours (another softgoal). Reducing costs (captured as a task), which can help satisfy the principals' objective, can be decomposed into two non-mutually exclusive options: reducing the marketing cost or reducing the staffing budget. The latter option however can hurt the staff's objective. As modellers develop deeper knowledge of these relationships, they can move from a qualitative scale (e.g., Help) to a quantitative one (e.g., 35) for contributions and for satisfaction values. Such models can help capture stakeholder's objectives as well as their relationships in an explicit way in terms understandable by managers.

Figure 1

Example of GRL model (left), with evaluation (right).

GRL evaluation strategies enable modellers to assign initial satisfaction values to some of the intentional elements (usually alternatives at the bottom of a goal graph) and propagate this information to the other elements through the decomposition and contribution links. Strategies act as what-if scenarios that can help assess the impact of alternative solutions on high-level goals of the involved stakeholders, evaluate trade-offs during conflicts, and document decision rationales. Different goal evaluation algorithms (using qualitative values, quantitative satisfaction values between −100 and +100, or a mix of both types) for GRL are discussed by Amyot et al.

Figure 1 (right) illustrates the result of a strategy for our example where the reduction of the staffing budget is selected, i.e., the satisfaction value of this task is initialized to 100. In the Eclipse-based modelling tool we use, called jUCMNav (Mussbacher et al., initialized elements are displayed with dashed contours. This strategy eventually leads to a weakly satisfied (+25) "Increased profits" softgoal and to a weakly denied (−25) satisfaction level for "Have many work hours". The resulting satisfaction values in top-level goals and actors should be used to compare different strategies and find suitable trade-offs rather than be interpreted as some sort of satisfaction percentage. jUCMNav also uses a color-coding scheme to highlight satisfaction levels - red for denied, yellow for neutral, and green for satisfied (with various shades for values in between) - which again improves the intuitive understanding through dual coding.

The Use Case Map notation is a visual process modelling language for specifying causal scenarios and optionally allocating their activities to an underlying structure of components and actors. UCMs model scenarios and processes with causal relationships, where responsibilities () are sequenced and may be assigned to components (). Responsibilities represent activities performed in a process whereas components represent actors, systems, and system parts. UCMs support most of the concepts used in common workflow modelling notations including start points (), end points (|) as well as guarded alternatives and concurrent flows. Stubs () are containers for sub-maps and can be used to organize a complex model in a hierarchical structure. Furthermore, URN allows typed links to be established between modelling elements (e.g., between a GRL goal and a UCM responsibility). UCMs can be used to model as-is and to-be business processes, as will be seen in our illustrative case study.