Requirements Engineering: Goal-Oriented Approach to RE

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

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

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

5
Decomposing goals

• High-level goals may be decomposed into
  lower-level goals in two ways to produce a goal
  hierarchy

6
A Goal Hierarchy
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.

8
Another Goal Hierarchy
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.

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.

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

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.

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.

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)

15
Inferred Goals 1

• Higher-level goals may be inferred from
  lower-level goals.
• For example, in the context of an organisations
  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.

16
Inferred Goals 2
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

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

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

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

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

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