Goal Modelling

From Wikipedia, the free encyclopedia

This article may not meet the general notability guideline or one of the following specific guidelines for inclusion on Wikipedia: Biographies, Books, Companies, Fiction, Music, Neologisms, Numbers, Web content, or several proposals for new guidelines. If you are familiar with the subject matter, please expand or rewrite the article to establish its notability. The best way to address this concern is to reference published, third-party sources about the subject. If notability cannot be established, the article is more likely to be considered for redirection, merge or ultimately deletion, per Wikipedia:Guide to deletion.
This article has been tagged since April 2008.

Within requirements engineering (RE), the notion of goal has increasingly been used. Goals generally describe objectives which a system should achieve through cooperation of actors in the intended software and in the environment [1]. Goals are central in some RE frameworks, and can play a supporting role in others.

Contents

[edit] Why use goals in RE?

Goal-oriented techniques may particularly be useful in early-phase RE. Early-phase requirements consider e.g. how the intended system meets organizational goals, why the system is needed and how the stakeholders’ interests may be addressed. [2]

Expresses the relationships between systems and their environments

Earlier, requirements engineering focused only on what the system is supposed to do. Over the past years, there has been a more or less mutual understanding, that it is also very important to understand and characterize the interaction between the intended system and its environment. Relationships between systems and their environments are often expressed as goal-based relationships. The motivation for this is “partly today's more dynamic business and organizational environments, where systems are increasingly used to fundamentally change business processes rather than to automate long-established practices”.[3] Goals can also be useful when modelling contexts. [4]

Clarifies requirements

Specifying goals leads to asking “why”, “how” and “how else”. [5] Requirements of the stakeholders are often revealed in this process. The stakeholders may seem to be more likely to become aware of potential alternatives for fulfilling their goals, and thereby less likely to over-specify their requirements. Requirements from clients and stakeholders may often be unclear, especially the non-functional ones. A goal-oriented approach allows the requirements to be refined and clarified through an incremental process, by analyzing requirements in terms of goal decomposition.

Deals with conflicts

Goals may provide a useful way of dealing with conflicts, such as tradeoffs between costs performance, flexibility, etc, and divergent interests of the stakeholders. Goals can deal with conflicts because meeting of one goal can interfere with the meeting of others. Different opinions on how to meet a goal has led to different ways of handling conflicts. [6]

Decides requirements completeness

Requirements can be considered complete if they fulfil explicit goals in the requirement model.

Connects requirements to design

Goals can be used in order to connect the requirements to the design. For some, goals are an important mechanism in this matter. (The Non-Functional Requirements (NFR) framework uses goals to guide the design process.)

[edit] Modelling Goals

Several techniques have been developed for modelling goals. Some of the most reputable are:

Goal modeling in EEML

Goal-oriented Requirements Language (GRL)

Goal Modelling with i*

Non-Functional Requirements framework (NFR)

[edit] References

  1. ^ L. Liu and E. Yu, “Designing information systems in social context: a goal and scenario modelling approach”, 2003 Elsevier Ltd. http://www.cs.toronto.edu/~liu/publications/ISj03.pdf
  2. ^ E. Yu, “Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering”, 1997 IEEE
  3. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html
  4. ^ K.Pohl and P. Haumer, “Modelling Contextual Information about Scenarios”, Proc. 3rd Int. Workshop on Requirements Engineering: Foundations of Software Quality REFSQ ’97, Barcelona, Catalonia, Spain, June 1997 pp. 187-204.
  5. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html
  6. ^ E. Yu and J. Mylopoulos, “Why Goal-Oriented Requirements Engineering”, http://www.cs.toronto.edu/pub/eric/REFSQ98.html

[edit] Further Reading

"The Business Motivation Model ~ Business Governance in a Volatile World", Relase 1.3, Business Rules Group, 2007, http://www.businessrulesgroup.org/bmm.shtml

Bolchini, D., Paolini, P., "Goal-Driven Requirements Analysis for Hypermedia-intensive Web Applications", Requirements Engineering Journal, Springer, RE03 Special Issue (9) 2004: 85-103.

B.Berkem,"Running Business on the basis of your Goals and Directives" Inreasing Business Agility using a Goal-Driven Service Oriented Architecture (GD-SOA)