Goal-Oriented Approach to Deriving Requirements for Computer-Based Systems, Lecture notes of Requirements Engineering

Download Goal-Oriented Approach to Deriving Requirements for Computer-Based Systems and more Lecture notes Requirements Engineering in PDF only on Docsity!

UFCE4S-10-3: Requirements Engineering Faculty of Computing, Engineering and Mathematical Sciences University of the West of England

Goal-Oriented Approaches to

Requirements Engineering

by

Stewart Green

List of Figures

• 1.1 Goal decomposition (after [LK95a])
• 1.2 Goal lattice - a fragment
• 1.3 Air Traffic Control goal hierarchies (after [LK95b])
• 1.4 Air Traffic Control goal graph (after [LK95b])
• 1.5 Air Traffic Control functional requirements (after [LK95b])
• 1.6 Air Traffic Control non-functional requirements (after [LK95b])
• 1.7 Overview of the KAOS approach
• 1.8 A portion of a KAOS meta model
• 1.9 The KAOS process
• 1.10 Partial decomposition of a meeting scheduler system goal
• 1.11 Operationalising goals into constraints
• 1.12 Fragment of a requirements model for a meeting scheduler system
• 1.13 Provision of IT support (one)
• 1.14 Provision of IT support (two)
• 1.15 OPM: a RAD diagram model
• 1.16 OPM: system model for the Helpdesk context
• 1.17 OPM: goal model for the Helpdesk context
• 1.18 OPM: method model for the Helpdesk context
• 1.19 OPM: creating the active model

Chapter 1

Deriving requirements from

goals

1.1 Introduction

Each of the socio-technical approaches to requirements engineering described in Chapter Three—Checkland’s Information Systems Development [WBPB95], Holtzblatt’s and Beyer’s Contextual Inquiry [HB96, HB98], and Eason’s socio-technical approach [Eas88]—featured, to a greater or lesser extent, the use of current goals and knowledge of current organisational activities to derive requirements for computer-based systems. However, if the goal- oriented and the related process-oriented approaches were fully articulated in these socio-technical approaches, then it is likely that they would become even more effective at tackling some of the problems associated with the tra- ditional approaches, for example at tackling the problem of high-level organ- isational objectives often being ignored. So the goal-oriented and process- oriented approaches to deriving requirements for computer-based systems need to be fully understood, and this chapter now reviews both. The chap- ter begins by discussing the rationale for the goal-oriented approach. This is followed by a basic description of this approach. Then existing work on goal-oriented approaches is reviewed, and advantages and problems of the goal-oriented approach are listed. Goals are seen to have a close relation- ship to processes in that processes are enacted to achieve goals. The chapter ends with a review of process-oriented methods associated with the develop- ment of computer-based systems, and, therefore, with the derivation of the requirements for such systems. The reviews highlight the salient features of process-oriented approaches, and surface problems associated with each approach considered. The detailed description of goal-oriented and process- oriented approaches presented in this chapter are used to inform the design of the synthesised approach in the next. And the problems with the goal- oriented and process-oriented approaches encountered here are taken to be problems that need to be addressed by the new, synthesised approach that is presented in Chapter Six.

1.2 Rationale for a goal-oriented approach to re-

quirements engineering

Asking and answering the “why” questions during software development is viewed as important by a number of researchers in the field. For example, McDermid provides a strong justification for this position [McD94]. He first observes that, traditionally, requirements specifications are characterised by the description of a system’s functions. Then, after enumerating a num- ber of problems perceived with such specifications, he says “perhaps most significantly, such specifications may violate the ‘high level objectives’ of the organisation the system is intended to serve” [McD94] 1. The violation occurs because “the process which leads to such specifications is effectively ‘starting at the wrong place’, that is with the derived requirements not fundamental ones. By this is meant looking at the desired properties at a presupposed system boundary instead of starting with business needs or ob- jectives of the embedding system” [McD94]^2 (thesis author’s italics). In other words, McDermid is saying that much system development starts with too

(^1) Page 25 (^2) Page 26

Increase sales

Increase profits

Reduce production costs

Reduce costs of raw materials

Reduce cost of machinery

Increase productivity

Reduce staff costs

Automate task XYZ

Automate task PQR

Figure 1.1: Goal decomposition (after [LK95a])

These are now discussed in more detail. Goals are usually defined in terms of states to be reached, maintained, or avoided (see, for example, [McD94]^8 ). Loucopoulos provides a good definition [LK95a] 9 : “A goal is defined as a defined state of the system. Since a state is described in terms of the values of a number of parameters, a goal can be alternatively defined as a set of desired values for a number of parameters”. Loucopoulos provides the following example of a goal: “To make profits of $1M in the next financial year”. Here, the two goal parameters are “profits” and a time-frame, and the desired values are “$1M” and “within the next financial year” respectively. Both in the literature and in the world of work, there are a number of common synonyms for the term goal. These include: objective, aim, end, target, and purpose. Often the terms “end” and “objective” are used to stand for goals that are either vaguely expressed or long-term or to be achieved by multiple actions (see, for example, [McD94]^10. Another term that is often used instead of goal is “constraint”. However, constraints and goals are taken here to refer to different phenomena as will be explained in the sequel. In the goal-oriented approach to deriving requirements for computer- based systems, high-level goals of a served system are first identified. These are then decomposed successively in order to derive requirements for comput- er-based systems [DvF93, McD94, LK95a] [AP98]^11. The notation that is often used to capture the high-level goals and the result of their decomposi-

(^8) Page 28 (^9) Page 44 (^10) Page 27 (^11) Page 158

User problem frequencies computed

Access to problem descriptions maximised

Lost user problems minimised

All users’ problem details recorded

Figure 1.2: Goal lattice - a fragment

tion is derived from Nilsson [Nil71]^12. The original notation has been re-used by a number of researchers employing a goal-oriented approach, but with a variety of adaptations [Chu93, Nix93, DvF93] [AMP94] 13. The basic idea is described and exemplified in Loucopoulos et al. [LK95a]^14. A goal may be decomposed in two main ways. Either a goal, G1 say, may be decomposed into a set of conjunctive sub-goals, all of which must be attained in order to attain goal G1. Or it may be decomposed into a set of disjunctive sub-goals, at least one of which must be attained in order to attain goal G1. These ideas are illustrated in figure 1.1. The goal “Increase Profits” is attained if either of the goals “Increase Sales” or “Reduce Production Costs” is at- tained. And the goal “Reduce production Costs” is attained only if all of the sub-goals “Reduce Cost of Raw Material”, Reduce Cost of Machinery”, “Increase Productivity”, and “Reduce Staff Cost” are attained. Diagrams like the one in figure 1.1 are referred to as goal hierarchies. However, goal lattice would be a more appropriate name [LK95a]^15 , as, in general, a sub-goal may support the attainment of more than one high- level goal. This is exemplified in the fragment from a goal lattice shown in figure 1.2. It was taken from a goal-hierarchy that was generated in the case study described in Chapter Seven. The case study describes how a goal-oriented approach is used to generate requirements for computer-based systems that are intended to improve the working of a university faculty help-desk. Recording the details of all problems reported to the help-desk by the users helps to attain the three higher level parent goals that are shown. For example, recording problem details helps to minimise the occurrence of “lost” problems, in other words problems reported by users for which the help-desk can find no record. So far, applications of the goal-oriented approach have been considered that have involved neither conflicting goals nor multiple views of a served system’s goals. In practice, the situation is often more complicated. Some sub-goals in a goal-hierarchy usually conflict with others. And different stakeholders frequently have different views about the goals of a served sys-

(^12) Pages 22 - 23 and 87 - 90 (^13) Pages 100 and 102 (^14) Page 45 (^15) Page 45

and resolving conflict [DvF93]^27 , others, for example [Jac91], highlight some of the major difficulties for this endeavour in some common organisational contexts.

1.4 Goal-oriented approaches in the literature

The previous section has described the goal-oriented approach to deriving requirements for computer-based systems. It has presented the main con- cepts of the approach: goal, goal hierarchy, goal decomposition, and the idea that alternative sets of requirements may satisfy given goals. It has also discussed two inter-related factors that complicate the approach: dif- ferent stakeholders may hold very different views about what are the main goals of a served system, and conflicting goals may exist both within one view and across different views. This section reviews research that has been reported in the literature on goal-oriented approaches to deriving requirements for computer-based sys- tems. Research has been categorised according to where its authors have taken the boundary of the served system to lie. Different researchers have defined their served system boundary on either a structural basis or a pro- cessual basis. The structural categories are:

• Served system scope defined by the enterprise boundary
• Served system scope defined by the application boundary

The processual category is:

• The focus is on processes

Each subsection below discusses work associated with a particular category and presents representative pieces of research in greater depth.

Served system scope defined by the enterprise boundary

A number of projects have taken the boundary of an enterprise to be the limit of the served system, including the following: GMARC [BJT+94], OR- DIT [DBCS94], F3 [BNG94, BRLD94], and [Eas88]^28. Loucopoulos and Karakostas overview a number of approaches to enterprise goal modelling in [LK95a]^29 , where they also provide a characterisation of enterprise goal modelling and a tutorial example. A representative and relatively complete description of the goal-oriented approach to deriving requirements in the context of enterprises is also provided by Loucopoulos and Kavakli [LK95b]. Their fundamental belief is that “the purpose of building a software system is to be found outside the system itself in the enterprise” [LK95b] 30 , and that, therefore, knowledge of the enterprise should be captured in a formal model and used to derive requirements for computer-based systems. Their interpretation of an enterprise model comprises knowledge about goals, roles, actors, processes, and resources in an enterprise. This knowledge is held in

(^27) Pages 33 - 35 (^28) Pages 83, 85, and 87 - 90 (^29) Pages 82 - 87 (^30) Page 47

three different views: the technical, the social, and the teleological. The “technical perspective describes a number of different aspects of the busi- ness: business processes, flow of information and data across business pro- cesses, where resources or organisations are located, where activities take place, etc.” 31 The “social viewpoint reasons about policies, structures and work roles; validates and maintains their established order”^32. The teleo- logical viewpoint is deemed the most important:“Goals are recognised as the primary factors that govern and explain the current and potential en- terprise configuration” 33. The teleological viewpoint is ideally developed in the manner described in the description of the goal oriented-approach given in section 1.3 (see page 6): goals of the stakeholders are determined, along with the constraints of the enterprise; goals are decomposed into more spe- cific sub-goals; this leads to alternative approaches to their satisfaction, each of which must be evaluated; in addition, conflicting goals should be identi- fied and resolved with the stakeholders before the alternatives are evaluated. The paper reviews an application of their approach to an Air Traffic Control (ATC) enterprise. Although an explicit process model for the approach is not given, the one presented below seems to be implicit in the paper:

1. Investigate the enterprise
2. Develop models of the technical and social viewpoints
3. Develop a model of the teleological viewpoint

(a) Identify goals, constraints, and problems (b) Construct goal hierarchies (c) Construct a goal graph (d) Identify conflicting goals (e) Identify goals to automate (f) Define automation strategies (g) Evaluate automation strategies (h) Select best automation strategy (i) Define Information System goals (j) Define functional requirements to satisfy IS goals (k) Define non-functional requirements to satisfy IS goals

Stage-three is illustrated in detail below using fragments of Loucopoulos’s and Kavakli’s example. In step 3 (a) a requirements engineer should identify goals, constraints, and problems. Some of the high-level goals, constraints, and problems of the ATC enterprise are given below:

• High-level goals
  • Safety (management, customers)
  • Efficiency (management, customers) (^31) Page 52 (^32) Pages 52 - 53 (^33) Page 53

Minimise risk of aircraft accident

Automate control process

Decrease risk of human error

Automate sequencing and planning

Automate aircraft sequencing

Continuously monitor

Visualise air traffic scenarios in real-time

Reduce delays to aircraft

Manage problems and emergencies

Goal

Supports the achievement of

Figure 1.3: Air Traffic Control goal hierarchies (after [LK95b])

Minimise risk of aircraft accident

Automate control process

Decrease risk of human error

Automate sequencing and planning

Automate aircraft sequencing

Continuously monitor

Visualise air traffic scenarios in real-time

Manage problems and emergencies

Validate scenarios

Goal

Supports the achievement of

Conflicts with

Figure 1.4: Air Traffic Control goal graph (after [LK95b])

EG Automate aircraft sequencing

EG Visualise air traffic scenarios in real-time

IG System should display scenarios

IFR Display tracks

IFR Display maps and airways

EG

IG

IFR

Supports the achievement of

Enterprise goal

Information system goal Information system functional requirement

Figure 1.5: Air Traffic Control functional requirements (after [LK95b])

EG Visualise air traffic scenarios in real-time

INFR System should perform in real- time

INFR Display aircraft in < 3/16 sec. sweep period

INFR Display radar data in real- time

INFR

Supports the achievement of

Information system non-functional requirement

EG Enterprisegoal

Figure 1.6: Air Traffic Control non-functional requirements (after [LK95b])

Create a requirements model

Client’s requirements

KAOS meta-model Meta-model traversal strategy

Requirements model

Figure 1.7: Overview of the KAOS approach

both, for example pre-condition is a meta attribute of the action meta con- cept and strengthened pre-condition is a meta attribute of the ensures meta relationship; and meta constraints, for example constraints defining the car- dinality of a meta relationship. Figure 1.8 shows a part of a KAOS meta model. The order and manner in which meta objects are acquired is deter- mined by the meta model traversal strategy (or acquisition strategy). The meta model could be traversed backwards, either from identified agents, or from client supplied scenarios; however, for the remainder of this section, only backwards traversal from a client’s requirements (or goals) is consid- ered. Knowledge about traversal strategies is included in meta knowledge used by a computer based acquisition assistant to guide an actual traversal. The assistant also uses domain knowledge of varying degrees of abstraction in order to perform analogical reasoning. The initial basic source of information for this approach, using a goal- driven strategy, is a client’s expression of functional and non-functional re- quirements for a composite system. These are input to the seven-stage KAOS process, which is shown in figure 1.9. During the KAOS process, instances of each of the meta objects discussed above are acquired, as a re- quirements model is gradually created. During stage-one, the highest level goals of a system are identified from the requirements. Goals are deemed to be system objectives which cannot be met by the actions of just one agent. Such goals are reduced to an equivalent set of objectives each of which can be met by the actions of one agent. These objectives are called constraints and are formally defined during stage-three. The reduction is achieved by decomposing goals into one or more sets of sub-goals, where each member of a set contributes to the satisfaction of a parent goal, and satisfying all the sub-goals in a set completely satisfies the parent goal [Nil71]. If it is pos- sible, goals should be expressed formally using a first-order temporal logic (currently a formalism inspired by ERAE [Dub91] is used by the KAOS group). As the goal decomposition proceeds, objects (agents, entities, rela- tionships, and events) referred to in formal and informal goal descriptions are identified and abstracted for use in stage-two. During stage-two, objects associated with goals are reviewed, and agents (objects which control state transitions) are identified along with their ac- tions and any pre-conditions, post-conditions, and trigger-conditions for their actions. This knowledge of agents and actions is then used in stage-one to identify when a goal may be reduced to a constraint, in other words to identify leaf-goals. Thus, stages one and two may be viewed as co-routining stages. In stage-three, each leaf-goal of a goal structure is converted into a constraint whose formal definition is expressed in terms of objects and

Requirements Engineer

Create goal structure Identify agents

Identify constraints

Identify new objects, actions, and attributes

Identify ensure links for constraints Assign responsibility for constraints to candidate agents Assign responsibility for each constraint to selected agent

Client's requirements available

Requirements model available

Figure 1.9: The KAOS process

actions available to some agent identified during stage-two. In stage-four, new actions and objects described in the formal defini- tions of constraints during stage-three are identified and acquired. In ad- dition, new characteristics of already acquired concepts, such as new meta attributes or new pieces of invariants, pre-conditions, post-conditions, and trigger-conditions are also identified. In general, actions, pre-conditions, post-conditions, and trigger-conditions identified in stage-two are not nec- essarily sufficient to ensure that each constraint will be satisfied. So, in stage-five, each constraint is examined and consequently, to ensure that each constraint will be met, some actions and objects may be modified, and new actions and objects may be introduced. Such modifications might involve strengthening an action’s pre-condition, for example, or strengthening an object’s invariant. This new information is held in a requirements model as meta attribute values of the ensures meta relationship. In addition, new ac- tions are acquired which allow soft constraints (see below) which may have been violated to be restored. In a complete requirements model each constraint is the responsibility of a single agent. During stage-six, each constraint is reviewed in turn, and agents which might be made responsible for it are linked to it by instances of the responsibility meta relationship. Finally, in stage-seven, the actions required to satisfy a constraint are assigned to the “best” agent from among the candidate agents for satisfying that constraint. The rationale for the meta model and the acquisition process is as follows: the system goals correspond to a client’s requirements; these are satisfied if all the leaf goals of the generated goal structure can be satisfied; these, in turn, can be satisfied if the constraints operationalising them can be met. The formal definition of each constraint defines a set of sequences of states in terms of properties of objects in the states, that is to say in terms of patterns of states. In order to move from one state in a sequence to the next, actions must be performed on one or more of the objects in the input state. In general, a set of actions (with appropriate pre-conditions, post-conditions and trigger conditions) acting on objects (conforming to appropriate invariants) will be needed to meet a constraint. A number of agents may be able to perform actions which will enable them to satisfy the constraint. One of these is selected as the agent which is responsible for meeting the constraint; this one has the appropriate actions assigned to it. The approach is used to create a requirements model for a composite system. This model comprises, among other things, a set of agents, where each agent has a set of actions and a set of constraints for which it has been assigned responsibility. Different constraints may conflict with one another. The KAOS approach is illustrated here by applying it to the Meeting Scheduler problem (see Appendix ??). The initial basic source of informa- tion for this approach, using a goal-driven strategy, is a client’s expression of functional and non-functional requirements for a composite system. For example, for the meeting scheduler system, such goals include the following: “to determine, for each meeting request, a meeting date and location so that most of the intended participants will effectively participate”, and “privacy rules should be enforced; an ordinary participant should not be aware of constraints stated by other participants”. A client’s requirements are input to the seven-stage KAOS process (see