1 / 22

Requirements Engineering: Goal-Oriented Approach to RE

Requirements Engineering: Goal-Oriented Approach to RE. UFCE4S-10-3 Lecture Three Stewart Green. Lecture Structure. Conceptualising the served system using goals Decomposing goals to create goal hierarchies Leaf goals and alternative solutions Goal conflict and goal resolution

rfedler
Télécharger la présentation

Requirements Engineering: Goal-Oriented Approach to RE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirements Engineering: Goal-Oriented Approach to RE UFCE4S-10-3 Lecture Three Stewart Green

  2. Lecture Structure • Conceptualising the served system using goals • Decomposing goals to create goal hierarchies • Leaf goals and alternative solutions • Goal conflict and goal resolution • Problems can be turned into goals • Building a hierarchy • Inferred goals • Case study exercise Requirements Engineering UFCE4S-10-3 Lecture Three

  3. References • Systems Requirements Engineering, P. Loucopoulos et al., Mc Graw-Hill, 1995 • Goal-Oriented Requirements Engineering: A Guided Tour, A. van Lamsweerde, 5th International Symposium on Requirements Engineering, IEEE Computer Society Press, 2001 • The Use of Goals to Surface Requirements for Evolving Systems, A. Anton et al. International Conference on Software Engineering, pp157-166, IEEE Comp. Soc. Press, 1998 Requirements Engineering UFCE4S-10-3 Lecture Three

  4. Conceptualising The Served System Using Goals • We can understand a served systems in terms of the goals it is intended to meet • A goal is an expression of a state to be achieved or avoided • For example, one goal might be: “This department should process 20 widgits per hour at least” • Another goal might be: “The company should make an annual profit greater than £2,000,000.” • So we see that there may be high-level goals, e.g., the latter, and low-level goals, e.g., the former Requirements Engineering UFCE4S-10-3 Lecture Three

  5. Decomposing goals • High-level goals may be decomposed into lower-level goals in two ways to produce a goal hierarchy: Requirements Engineering UFCE4S-10-3 Lecture Three

  6. A Goal Hierarchy Requirements Engineering UFCE4S-10-3 Lecture Three

  7. Alternative Serving Systems 1 • The process of decomposing higher- to lower-level goals may proceed until leaf-goals are reached that can be satisfied by a computer-based system or a computer-based system component. Requirements Engineering UFCE4S-10-3 Lecture Three

  8. Another Goal Hierarchy Requirements Engineering UFCE4S-10-3 Lecture Three

  9. Alternative Serving Systems 2 • Here we can see that two alternative serving systems (computer-based systems) may achieve goal G1.2.2. And, in general, the goal-oriented approach leads to the identification of multiple applicable serving systems. Requirements Engineering UFCE4S-10-3 Lecture Three

  10. Conflicting Goals 1 • Once a goal-hierarchy has been created, the next task is to identify conflicting goals. • One way of detecting conflicting goals is to read through them all. Clearly this method does not scale up well: the more goals there are, the harder it becomes to detect conflict in this way. • Another way is to re-express each goal formally in, e.g., the language of predicate logic, and then use a theorem prover to detect inconsistencies, i.e. conflict. Requirements Engineering UFCE4S-10-3 Lecture Three

  11. Conflicting Goals 2 • Sometimes goals in a goal hierarchy may conflict with one another. For example, in a library system, two conflicting goals may be: Requirements Engineering UFCE4S-10-3 Lecture Three

  12. Resolving Goal Conflict • When conflicting goals have been identified, the next task is to resolve the conflict, or to try to mitigate the conflict, a process known as conflict resolution. • One way of trying to achieve conflict resolution is to return to the stakeholders who “own” the conflicting goals to see whether they would be prepared to accept a compromise. Perhaps one new goal would satisfy both stakeholders, not perfectly, but to a reasonable extent, a process known as satisficing. • This is one example of a goal resolution strategy. Another strategy might involve selecting the goal with the highest priority. Requirements Engineering UFCE4S-10-3 Lecture Three

  13. Problems Can Be Turned Into Goals • Problems that are elicited by the requirements engineer during the investigation of a served system may be easily re-expressed as goals. • For example: • Problem: “Too many problems that users report to the Helpdesk are being lost in the system” • Corresponding Goal: “ “Lost” user problems are minimised or eliminated” • Problem: “Annual profit targets are not being met” • Corresponding goal: “Annual profit targets are being met.” • The general idea is to obtain the goal by negating the problem: put “It is not the case that” in front of the problem, and then rewrite it. Requirements Engineering UFCE4S-10-3 Lecture Three

  14. Building a Goal Hierarchy • In addition to top-down decomposition of high-level goals, two other approaches may be used to create a goal-hierarchy: • Elicit goals from the stakeholders; then build a hierarchy from the elicited goals • Infer the existence of goals (see the next slide) Requirements Engineering UFCE4S-10-3 Lecture Three

  15. Inferred Goals 1 • Higher-level goals may be inferred from lower-level goals. • For example, in the context of an organisation’s Helpdesk system, the goal “minimise time to solve user problems” may be inferred from the goals, “match expert to user problem”, “provide access to problem solutions”, and “facilitate access to problem information”. Requirements Engineering UFCE4S-10-3 Lecture Three

  16. Inferred Goals 2 Requirements Engineering UFCE4S-10-3 Lecture Three

  17. Inferred Goals 3 • Inferred goals may be useful because • They may help the stakeholders to understand their goals better • They may make explicit what stakeholders think is obvious • They may provide low-level (leaf) goals from which requirements for CBSs may be directly derived Requirements Engineering UFCE4S-10-3 Lecture Three

  18. Advantages of the Goal-Oriented Approach • Characterised by a systematic process • Facilitates the detection and resolution of intrinsic conflict • Facilitates the identification and exploration of alternative solutions • Goals provide a precise criterion of completeness of a requirements specification • Goals provide a rationale for a set of requirements • Helps to avoid irrelevant requirements • Facilitates understanding of a system • Facilitates evaluation of a system and its design • Encourages implementation detail independence • Facilitates the provision of reusable structures • Provides a starting point for traceability Requirements Engineering UFCE4S-10-3 Lecture Three

  19. Disadvantages of the Goal-Oriented Approach • How can one be sure that a goal is precisely satisfied by its sub goals? • Distinguishing between leaf-goals and the means top achieve them is not always clear (Loucopoulos and Karakosta) • In some organisations goals change so quickly that the goal-oriented approach is rendered less useful Requirements Engineering UFCE4S-10-3 Lecture Three

  20. Case Study Exercise 1 • Consider the following case study. Mr A is the manager of a University Helpdesk to which staff and students bring their problems. Helpdesk staff either solve problems on-the-spot or write them down and pass them to back-office experts. When an expert solves a problem, the solution is communicated to the user. Some problems have been experienced with this way of operating: • Some of the users’ problems seem to get lost in the system • Some of the users' problems never seem to get solved • Staff and students find it difficult to track the status of their problems Requirements Engineering UFCE4S-10-3 Lecture Three

  21. Case Study Exercise 2 • In addition, the manager would like to manage the system more effectively. In particular he would like to know: • How many problems are being solved in unit time • Who is working on what problems at any time • The manager would also like a system that made it possible for students to access solutions to frequently occurring problems. • The experts would like to be able to prioritise problems assigned to them • The Helpdesk staff do not think that it is is necessary to record details of problems that they solve on-the-spot Requirements Engineering UFCE4S-10-3 Lecture Three

  22. Case Study Exercise 3 • Identify each type of stakeholder • Identify the high-level goals of each type of stakeholder • Convert stakeholders’ problems to corresponding goals • Use the various techniques to create a goal hierarchy • Try to decompose high-level goals in different ways to create alternative goal hierarchies • Identify leaf goals that could be computer-based systems, or components of computer-based systems • Identify conflicting goals Requirements Engineering UFCE4S-10-3 Lecture Three

More Related