Goal modeling

A goal model is an element of requirements engineering that may also be used more widely in business analysis. Related elements include stakeholder analysis, context analysis, and scenarios,[1] among other business and technical areas.

Principles

Goals are objectives which a system should achieve through cooperation of actors in the intended software and in the environment.[2] Goal modeling is especially useful in the early phases of a project. Projects may consider how the intended system meets organizational goals (see also [3]), why the system is needed and how the stakeholders’ interests may be addressed.[4]

A goal model:

Notations

There are several notations in use for goal models in software development, including:

Other notations have been proposed by researchers,[10] while the Goal Structuring Notation (GSN) is used to make safety cases to satisfy the regulator in safety-related industries.[11]

Goal modeling in i*

Main article: i*

The i* goal modeling notation provides two kinds of diagram:[12]

i* shows each role (an actor, agent or position) as a large circle containing the goals, tasks, and resources which that role owns. Ownership in i* means that the role desires the satisfaction of its goals, either for its own benefit or for the benefit of some other role. Goals may be accompanied by "obstacles" (negative goals) to be surmounted. Non-functional goals can be modeled as "soft goals" in i*: they are diagrammed as clouds or indented ovals.

Goal modeling in KAOS

The KAOS goal modeling notation provides a way of defining goals and obstacles, underpinned by a formal (mathematical) method of analysis.[8]

Goal modeling in UML

Main article: Use case diagram

UML's use case diagram provides a simple goal modeling notation. The bubbles name functional goals,[13] so a Use case diagram forms a simple functions-only goal model: as Cockburn writes, use cases cover only the behavioral requirements.[14] Roles are shown as actors (stickmen on the diagram), linked to the use cases in which they take part. The use cases are drawn as elliptical bubbles, representing desired behavioral goals.[15]

With the addition of misuse cases, the notation can model both desired goals and active threats. The misuse case notation shows negative (possibly hostile) stakeholders as the primary actors for the misuse cases; these may be grouped on the right-hand side of the diagram. The notation may assist in discovering suitable mitigating or preventative goals, shown as subsidiary use cases. These often have the aim of improving security, safety, or reliability, which are non-functional goals. Non-functional requirements can to some extent be described in use case style using misuse cases to define negative goals; but the (positive) goals thus discovered are often functional. For example, if theft is a threat to security, then fitting locks is a mitigation; but that a door can be locked is a functional requirement.[16]

Bibliography

References

  1. Alexander and Beus-Dukic, 2009. Pages 17-18
  2. Lin Liu and Eric Yu (2003). "Designing information systems in social context: a goal and scenario modelling approach" (PDF). University of Toronto. Archived from the original (PDF) on February 5, 2005.
  3. Ellis-Braithwaite, R.; Lock, R.; Dawson, R.; Haque B. (2013). "Towards an Approach for Analysing the Strategic Alignment of Software Requirements using Quantified Goal Graphs". International Journal on Advances in Software 6: 119–130.
  4. E. Yu, "Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering", 1997 IEEE
  5. 1 2 3 Eric Yu and John Mylopoulos. "Why Goal-Oriented Requirements Engineering". University of Toronto.
  6. 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.
  7. Yu et al, 2011.
  8. 1 2 van Lamsweerde, 2009.
  9. Fowler, 2004. Pages 99-105
  10. Rolland, Colette; Prakash, Naveen; Benjamen, Adolphe (1999). "A Multi-Model View of Process Modelling" (PDF). Requirements Engineering 4 (4).
  11. GSN Community Standard
  12. Yu, Eric (September 6, 2011). "i*". i*: an agent- and goal-oriented modelling framework. University of Toronto. Retrieved December 17, 2011.
  13. Alexander and Beus-Dukic, 2009. Page 121
  14. Cockburn, 2001. Page 62
  15. Cockburn, 2001. Page 221
  16. Alexander and Maiden, 2004. Chapter 7. Pages 119-139.

External links

This article is issued from Wikipedia - version of the Thursday, March 31, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.