How Can Goal Modelling Be Used in Requirements Engineering?

IS1 essay

How can goal modelling be used in requirements engineering?

Danqing Dong

930828-T188

Stockholm University

1. Introduction

The notion of goal modelling(GM) has been used in requirements engineering (RE)for a long time. The GM provides the goal which is the core of RE. Also in a GM, the problems are pointed out, the opportunities are identified and then in these specific contexts the requirements are elaborated to meet the goal. As Ross and Schoman stated in their seminal paper, “requirements definition must say why a system is needed, based on current or foreseen conditions, which may be internal operations or an external market. It must say what system features will serve and satisfy this context. And it must say how the system is to be constructed” [1]. There are so many authors discussing the GM of RE which are coving many reasons from different aspects. Many scholars think that introducing the notion of goal is helpful to explain how goal modelling is used in RE. This article is to compare the various discussions of the frameworks and techniques related to GM based on ten papers and to discover further about why goal modeling exists in RE and how can GM be used in RE.

2. Summary and brief comment of ten papers

2.1Goal-oriented requirements engineering: A Guided Tour [2]

This article talks about the RE from a goal-oriented angle, which means in this approach the RE takes the goal as the core and the goal drives some parts of the RE process. Axel van Lamsweerde gives the definition of goal “A goal is an objective the system under consideration should achieve” [2]. He gives eight reasons of the need of goals:

1. Goals provide a precise criterion for sufficient completeness of a requirements specification.
2. Goals will get rid of irrelevant requirements.
3. Goals provide the rationale of requirements while explaining the requirement to stakeholders.
4. Goal refinement increases readability.
5. Alternative goal refinement helps stockholders validate choices or suggest other alternatives.
6. Goals make managing conflicts easier and help solving conflicts.
7. Goals are more stable than requirements. The higher level a goal is, the more stable it will be [2].
8. Goals drive the identification of requirements to support them [2].

There are also some steps of this approach being demonstrated in this article. He points out that goal models are usually created from an early step of RE process. The first thing to utilize goal modelling is to elicit goals from initial resources. Secondly, identify objects after formulating goals. Thirdly, elicit goals again through asking ‘why’ and ‘how’ questions. And then, identify potential task. Next, deriving agent interfaces and identifying operations should be conducted. Certainly, the goals elicited before will be realized on the next step, which is quite important. Last but not least, evaluate obstacles and handle conflicts.

Because of the importance of goal, he also specifically talks about how to model goals (goals are generally modelled by intrinsic features such as their type and attributes, and by their links to other goals and to other elements of a requirements model [2].) and specify goals. At last, he gives some advantages of goal-oriented RE and points out goal orientation is used for defining and refining architectures and for annotation design patterns [2].

This article clearly shows that why a goal is so important for requirements engineering and how we can capture goals and specify goals. But this article is written in a too straightforward way and the article will be easier to be understood if author gives more small examples.

2.2Designing information systems in social context: a goal and scenario modelling approach [3]

In this article, authors suggest to use the combination of a goal-oriented requirements language (GRL) and a scenario-oriented notation Use Case Maps (UCM) for the improvement of information system. Because ‘UCM intends to straddle requirements and high-level architectural design stages, which closely matches with the scope of GRL’ [3]. And this approach is very suitable to cope with designing applications with lots of alternatives and new goals since goals always cannot elicited completely in the beginning. This article also gives a case study of a web based training system design to exactly show how this two approaches are working together. 

The GRL is a language for supporting goal- and agent-oriented modelling and reasoning about requirements, with an emphasis on dealing with non-functional requirements [4]. The GRL elements include: goal, task, softgoal, resource and belief. In GRL, goals are used to demonstrate the objectives and both functional and non-functional requirements, which is one of the advantage of GRL. The other advantage of GRL is that it puts the design in a broader context, it considers from different stakeholders’ viewpoints, and seeking for a balanced solution for all [3].

UCM allows the behavioral aspects of the designed system to be visualized at varying degrees of abstraction and levels of detail [3]. In UCM, scenarios are used to illustrate the business process or work flow.

The author draws a chart to illustrate the operating principle of GRL and UCM working together. Basically, the two approaches are working separately, but at some points they support and interact with each other. When both of them get solutions, solutions are combined to get a complete design description.

At last, the author concludes there may be no need to use both GRL and UCM for some applications, but this approach is still very useful to deal with designing the system with lots of alternatives and competing goals. For sure, there is still a lot of knowledges we need to do to pursue and explore this approach.

2.3 Goal-based Requirements Analysis [5]

This article gives a definition of goals: goals are a logical mechanism for identifying, organizing and justifying software requirements [5]. It is also talking about goals and from two respects: goal analysis and goal evolution. Goal analysis is about to give strategies to elicit and identify goals when goals are not documented. Goal evolution is the elaboration and refinement of goals. The author brings up a concept called GBRAM (Goal-Based Requirements Analysis Method) which is used to cope with goal analysis and goal evolution. GBRAM gives some techniques for both goal analysis and goal evolution: scenario analysis, identification of goal obstacles and constraints, and goal operationalization. For the goal analysis, the author suggests that it is necessary to gather information as much as possible in the first place including process descriptions such as flow charts or Entity Relationship(ER) diagrams. And even some useful information can be extracted from stakeholder descriptions, and for this searching for action words is a useful way. When the goal refinement appears, the author suggests combining and listing synonymous goals according to precedence relations and dependencies.