Structuring requirement speci®cations with goals
Jonathan Lee
a,*, Nien-Lin Xue
a, Jong-Yih Kuo
baSoftware Engineering Laboratory, Department of Computer Science and Information Engineering, National Central University, Chungli, Taiwan, ROC
bDepartment of Computer Science and Information Engineering, Fu-Jen Catholic University, HsinChuang, Taipei Hsien, Taiwan, ROC Received 24 April 2000; revised 22 June 2000; accepted 18 July 2000
Abstract
One of the foci of the recent development in requirements engineering has been the study of con¯icts and vagueness encountered in requirements. However, there is no systematic way in the existing approaches for handling the interactions among nonfunctional require- ments and their impacts on the structuring of requirement speci®cations. In this paper, a new approach is proposed to formulate the requirement speci®cations based on the notion of goals along three aspects: (1) to extend use cases with goals to guide the derivation of use cases; (2) to analyze the interactions among nonfunctional requirements; and (3) to structure fuzzy object-oriented models based on the interactions found. The proposed approach is illustrated using the problem domain of a meeting scheduler system. q 2001 Elsevier Science B.V. All rights reserved.
Keywords: Requirements engineering; Con¯icting requirements; Goals; Fuzzy object-oriented model
1. Introduction
In recent years, goal-based requirements analysis meth- ods have attracted increasing attention in the area of require- ments engineering, as goals information is valuable in identifying, organizing and justifying software requirements [2,3,9,12,26,27,37,38]. The tenet of goal-based approaches is to focus on why systems are constructed, which provides the motivation and rationale to justify software require- ments. Other bene®ts include: (1) helping to acquire requirements by elaborating what requirements are needed to support the goals; (2) making easy the justi®cation and explanation of the presence of requirements in a progressive way by starting from system-level and organizational objec- tives from which such lower level descriptions are progres- sively derived [12]; and (3) providing the information for detecting and resolving con¯icts that arise from multiple viewpoints among agents [12,29,37].
Subsequently, a number of researchers have reported progress toward the improvement of goal-based techniques [3,12,26,37]. In particular, Dardenne et al. [12] have advo- cated a goal-directed approach to models acquisition. Mylo- poulos et al. [26] have proposed a framework for representing nonfunctional requirements in terms of goals, which can be evaluated in order to determine the degree to
which a nonfunctional requirement is supported by a parti- cular design. Moreover, they advocated that object-oriented modeling approach can then be used to model functional requirements to compensate the goal-oriented approach [27]. Meanwhile, Anton [3] has proposed a goal-based requirement analysis method to identify, elaborate and re®ne goals for requirements speci®cations.
However, there are three main problems with these approaches: (1) though their approaches support a systematic way to acquire and analyze requirements, no de facto stan- dard modeling language has been adopted, which may impose a negative impact while applying to large scale systems; (2) though interactions among goals are a crucial factor in the structuring of requirement speci®cations, no attempt has been made to address such issues; and (3) though informality is an inevitable (and ultimately desirable) feature of the speci®cation process [4,5], little effort has been devoted to the formulation of imprecise requirements.
To model imprecise requirements and con¯icting require- ments, we propose, in this paper, an approach to structure fuzzy object-oriented models [25] by extending our previous work on the goal-driven use cases approach [24]
to formulate requirement speci®cations based on the notion of goals along three aspects (see Fig. 1 for an overview):
² Extending use cases1with goals to guide the derivation of
0950-5849/01/$ - see front matter q 2001 Elsevier Science B.V. All rights reserved.
PII: S0950-5849(00)00144-0
www.elsevier.nl/locate/infsof
* Corresponding author. Tel.: 1886-3-422-7151; fax: 1886-3-422-2681.
E-mail addresses: [email protected] (J. Lee), [email protected] sie.ncu.edu.tw (N.-L. Xue).
1 Use cases diagrams are one of the modeling techniques in UML to elicit, analyze and document requirements [11,21,32,33,34].
use cases: a faceted classi®cation scheme is proposed to identify goals from domain descriptions and system requirements; and a use case is viewed as a process that can be associated with a goal to be achieved, opti- mized, maintained, ceased, or impaired by the use case.
² Analyzing the interactions among nonfunctional require- ments: four types of interactions among nonfunctional requirements are identi®ed, which could be either con¯icting, cooperative, irrelevant, or counterbalanced.
² Structuring fuzzy object-oriented models based on the interactions analyzed: goals are organized into several alternatives based on the interactions analyzed to form a goals hierarchy; and a stable kernel is constructed to serve as a basis for further re®nement in an incremental fashion. Various techniques are also proposed for resol- ving con¯icts between goals into several alternatives based on the interactions analyzed to form a goals hier- archy; a stable kernel is constructed to serve as a basis for further re®nement in an incremental fashion. Various techniques are also proposed for resolving con¯icts between goals.
We chose the meeting scheduler problem as an example throughout this paper to illustrate our approach for two main reasons: First, as was pointed out by Potts et al. [28], the research community has adopted the meeting scheduling problem as a benchmark, and the requirements illustrate problems typical of requirements for real systems (see also Ref. [37] for more details). Second, the meeting sche- duler problem can help us to address the main challenge for requirements analysis, that is, to turn a vague and contra- dictory mission statement into a detailed speci®cation [8,28].
In this sequel, we ®rst outline the related work in Section 2. The way to use the goals information to structure use cases is described in Section 3. The analysis of goals inter- actions is presented in Section 4. In Section 5, the structur- ing mechanism for modeling fuzzy object-oriented models requirement speci®cations based on the goals information and goals interactions is fully discussed. Finally, we summarize the potential bene®ts of the proposed approach and outline our future research plan in Section 6.
2. Related work
Work in a number of ®elds has made its mark on our research. Our approach has drawn upon several ideas from goal-based approaches [3,12,26], techniques in handling con¯icts (Table 1) [7,15,36,39], and formulations of impre- cise requirements [22,42].
2.1. Goal-based requirements engineering approaches In Ref. [12], Dardenne et al. have proposed a goal-direc- ted approach for model acquisition. Goals are seen as deter- mining the respective roles of agents in the system and providing a basis for de®ning which agents should best perform which actions. In their approach, a goal is a nono- perational objective while a constraint is an operational one.
That is, a goal cannot be achieved directly by the application of actions available to some agents. Instead, it is achieved by satisfying the constraints operationalizing it. To satisfy these constraints, appropriate restrictions may be required in turn on actions and objects.
Mylopoulos et al. have proposed a framework for repre- senting and using nonfunctional requirements during the development process [26]. Goals are used to represent nonfunctional requirements, design decisions, and argu- ments in support of or against other goals. Goals represent- ing nonfunctional requirements can rarely said to be ªaccomplishedº or ªsatis®edº in a clear-cut sense. Instead, different design decisions contribute positively or nega- tively towards a particular goal. A labeling procedure to determining the degree to which a set of nonfunctional requirements is supported by a particular design is also proposed.
In Ref. [3], Anton proposes a goal-based requirement
Fig. 1. Overview of our approach.
Table 1
Variations of goal-based requirements engineering approaches
Dardenne [12] Mylouplos [26] Anton [3] Our approach
Types of goals System goal, Nonfunctional reqt. Achievement goal Rigid, soft, actor-speci®c
Privacy goal Goal, satisfying
goal, argument goal Maintenance goal System-speci®c, functional, nonfunctional
Roles of goals Reqt. Acquisition, Nonfunctional Reqt. analysis Use case structuring,
Reqt. Analysis Reqt. Analysis Reqt. evolution Reqt. evolution, models structuring
Relationships between goals Con¯icting Support, against Dependent Con¯icting, cooperative,
irrelevant, counterbalanced
analysis method (called GBRAM) to identify, elaborate and re®ne goals for requirement speci®cations. In GBRAM, an agent is responsible for the achievement of goals, which can be identi®ed from process descriptions, transcripts of inter- views, or searching action works. Goals are classi®ed into two types: achievement goals and maintenance goals.
Achievement goals usually map to actions that occur in a system, while maintenance goals map to nonfunctional requirements. Goals in GBRAM are elaborated and re®ned through identifying goal obstacles, analyzing scenarios and constraints. Scenarios are also used to help uncover hidden goals.
Rather than using scenarios to concretize goals, Rolland et al. [9] have proposed a new approach to discovering goals from scenarios. The basic modeling component is a combi- nation of goal and scenario where the scenario is authored for the goal. Goals discovery and scenario authoring are complementary activities. Once a goal is discovered, scenario authoring can be done, followed by goal discovery.
These goal-discovery/scenario-authoring sequence is repeated to incrementally populate a requirement chunks hierarchy.
2.2. Techniques in handling con¯icts
A number of researchers have reported progress towards the analysis of con¯icting requirements, which can be clas- si®ed into three different types of con¯ict: con¯icts due to the interactions among requirements advocated by different stakeholders [1,2,15,29,30], con¯icts in between various designs [7,39,40], and con¯icts resulted from the different structures adopted [18,36].
2.2.1. Interaction con¯icts
In this case, requirements are said to be con¯icting if the satisfaction of one requirement may impair or cease the satisfaction of another requirement. In a library system, a librarian wishes to minimize loan periods whereas a patron wishes to maximize the loan periods. A con¯ict arises due to the interactions among the requirements advocated by librarians and patrons. Robinson and Fickas [29] proposed an approach, called Oz, to requirements negotiation. There are three steps involved in Oz: con¯ict detection, resolution generation and resolution selection. The con¯ict detector of Oz does a pairwise comparison across all speci®cations. It does so by matching up design goals from perspectives and by comparing their plans. The speci®cations and con¯icts will be passed to the con¯ict resolver, which will provide analytic compromise and heuristic compensation and disso- lution for each con¯ict. Compensation is to add similar but con¯ict free requirements to negotiations, while, dissolution is to replace con¯icting items potentially less contentious items. Finally, the resolver will provide guidance for search control by choosing intermediate alternatives and auto- mated negotiation methods. Each method can be applied in any sequence to derive resolutions. The noncon¯icting
speci®cations are jointed into a single speci®cation by merger of Oz.
Easterbrook [15] proposes a framework for representing con¯icting viewpoints in a domain model. A viewpoint in his framework is a self-consistent description of an area of knowledge representing the context in which a role is performed. In evolving viewpoints, a new viewpoint will need to be split if it causes inconsistency. The new view- point and its negation are placed in different descendants of the original viewpoint, so that each remains self-consistent individually. The detection of con¯ict might be based on detection of logical inconsistencies. Thus, a hierarchy of viewpoints is established as the elicitation proceeds. The inheritance structure implies that the higher an item in the hierarchy, the more widely agreed it is. One of the aims of using viewpoints is to reduce the need for consistency checks. This approach allows many viewpoints to be combined into a single domain model without necessary resolving con¯icts between them. Con¯icts are treated as an important part of the domain and are to be represented and understood.
In Ref. [2], Lamsweerde et al. introduce a weak form of con¯ict called divergence. A divergence is de®ned as a logical inconsistency between goals under a speci®c bound- ary condition. Formal techniques and heuristics are proposed for detecting divergences from the speci®cations (based on real-time temporal logic) of goals. Various diver- gence patterns are also identi®ed to help divergence detec- tion by selecting a matching generic pattern and by instantiating it accordingly. Divergences can be resolved by creating/modifying/deleting goals assertions or trans- forming the objects in the speci®cation into a con¯ict-free version.
2.2.2. Design con¯icts
Con¯icts may arise if two requirements cannot be both supported by a design architecture or model. For example, portability can be improved via a layered architecture, but usually at some cost in performance. In this case, the requirements portability and performance are con¯icting w.r.t. an architecture, rather than con¯icts on their de®nitions.
To examine the requirements tradeoffs involved in soft- ware architecture and process strategies, Boehm et al. [7]
proposed an exploratory knowledge-based tool, quality attribute risk and con¯ict consultant (QARCC), for identi- fying potential con¯icts among quality attributes, ¯agging them for affected stakeholders, and suggesting options to resolve the con¯icts early in the software life cycle. It oper- ates in the context of the WinWin system, a groupware support system for determining software and system requirements as negotiated win conditions. The WinWin system uses Theory W to generate the objectives, constraints, and alternatives to provide win condition. To meet its goal of ªmaking everyone a winner,º Theory W involves stakeholders in a process of identifying their
quality-attribute win condition and reconciling con¯icts among quality-attribute win conditions.
A number of researchers have put effort into making generic conceptual models available and reusable for bene-
®ting from reusing experience with previous design. One of their challenges is to face the tradeoffs about selecting conceptual model components, as a conceptual design component property may contribute to a particular require- ment, but adversely affect another requirement. To model the history of discussion, negotiation and compromise that led to a conceptual design, Vanwelkenhuysen [39,40]
proposes a Design Requirement Embedding (DRE) approach. In DRE, by recognizing the interactions between design properties and interactions between design properties and requirements, competing requirements are explored and a design guideline is proposed for the con¯ict. Design teams can negotiate with users based on proposed design guide- lines.
2.2.3. Structural con¯icts
A structural con¯ict arises whenever parts of the same reality are represented in different views using different structural constructs. For instance, an object may be repre- sented as an entity type in one view and as an attribute of an entity type in another view. The generalization concept has been extensively used as a solution to such con¯icts (see Ref. [18] for a survey). In particular, Spaccapietra [36]
proposes a view integration methodology, designed to be able to automatically resolve structure con¯icts among differ- ent views without modifying the initial models. To that purpose, knowledge about correspondences that exist among different views should be acquired initially and repre- sented as a formal model. Finally, integration rules are used to build a integrated schema according to the known corre- spondences and based on the concept of generalization.
2.3. Formulations of imprecise requirements
Our previous work on Requirements Trade-off Analysis technique (RTA) has been on the formulation of vague requirements based on Zadeh's canonical form in test- score semantics [44] and an extension of the notion of soft conditions [22]. The trade-off among vague requirements is analyzed by identifying the relationship between require- ments, which could be either con¯icting, irrelevant, coop- erative, counterbalance, or independent. Parameterized aggregation operations, fuzzy and/or [45], are selected to combine individual requirements. An extended hierarchical aggregation structure is proposed to establish a four-level requirements hierarchy to facilitate requirements and criti- calities aggregation through the fuzzy and/or. A compromise overall requirement can be obtained through the aggregation of individual requirements based on the requirements hierarchy. The proposed approach provides a framework for formally analyzing and modeling con¯icts between
requirements, and for users to better understand relation- ships among their requirements.
Yen et al. [42,43] take the notion of con¯icting and coop- erative degrees as the view of distance-wise between any two individual requirements. They present a formal approach for reasoning about the relative priority by analyz- ing the customer's trade-off preference among imprecise con¯icting requirements. A requirement R1 is supposed to be more important than another requirement R2whenever the domain expert is willing to sacri®ce a lot in the satisfac- tion degree of a requirement R2for a small increase in the satisfaction degree of R2. Moreover, the ratio of R1's priority to that of R2is proportional to the ratio of their changes in the satisfaction degrees.
3. Structuring use cases with goals information
Goal-driven use cases is an approach for requirements engineers to elicit and structure users requirements, and to analyze and evaluate relationships between requirements.2 There are three steps to construct use cases: (1) identify actors by investigating all possible types of users that inter- act with the system directly; (2) identify goals based on a faceted classi®cation scheme; and (3) build use case models.
3.1. Identifying actors
An actor is an outside entity that interacts directly with a system, which may be a person or a quasi-autonomous object, such as machines, computer tasks, and other systems. More precisely, an actor is a role played by such an entity. For example, the meeting scheduler system is mainly designed for an initiator to organize a meeting sche- dule, and therefore, the initiator is marked as an actor.
3.2. Identifying goals
A faceted classi®cation scheme is proposed for identify- ing goals from domain descriptions and system require- ments. Each goal can be classi®ed under three facets we have identi®ed: competence, view and content. The facet of competence is related to whether a goal is completely satis®ed or only to a degree. A rigid goal describes a mini- mum requirement for a target system, which is required to be satis®ed utterly. A soft goal describes a desirable property for a target system, and can be satis®ed to a degree. For example, if a meeting schedule is convenient for all atten- dants, the goal MaxConvenienceSchedule is de®ned to be satis®ed completely. However, if the schedule is convenient only to some of the attendants, the goal is said to be satis®ed to a degree. A soft goal is related to a rigid one in the sense that the existence of the soft goal is dependent on the rigid one.
2 In order to map fuzzy object-oriented models to code level, we will need to have a program language with fuzzy features, that is, to de®ne membership function of a fuzzy set, to construct fuzzy rules and fuzzy inference, etc.
The facet of view concerns whether a goal is actor-speci-
®c or system-speci®c. Actor-speci®c goals are objectives of an actor in using a system; meanwhile, system-speci®c goals are requirements on services that the system provides.
For example, through examining the system description, we have found out that the initiator has three objectives in using the meeting scheduler system: (1) to create a meeting; (2) to make the meeting schedule as convenient as possible for the participants; and (3) to maximize the number of participants for the meeting. Therefore, three actor-speci®c goals can be identi®ed: MeetingRequestSatis®ed, MaxNumberOfPartici- pants and MaxConvenienceSchedule. On the other hand, a system-speci®c goal takes into consideration ªwhat kinds of properties the system should have in supporting services to all users?º, or ªwhat are the requirements on the services for the system to provide?º. In our example, to construct a meeting is an objective of an initiator, but to accommodate a more important meeting is a requirement of the system.
Therefore, a system-speci®c goal Ð SupportFlexibility, is identi®ed.
Usually, requirements can be classi®ed into functional and nonfunctional requirements based on their content [22]. The construction of functional requirements involves modeling the relevant internal states and behavior of both the component and its environment. Nonfunctional require- ments usually de®ne the constraints that the product needs to satisfy. Therefore, a goal can be further distinguished based on its content, that is, a goal can be either related to the functional aspects of a system or associated with the nonfunctional aspect of the system.3A functional goal can be achieved by performing a sequence of operations. A nonfunctional goal is de®ned as constraints to qualify its related functional goal. In our example, creating a meeting
is accomplished by a sequence of operations, therefore the goal MeetingRequestSatis®ed is de®ned as a functional goal.
On the other hand, goals like MaxNumberOfParticipants and MaxConvenienceSchedule can be viewed as constraints for a schedule to satisfy, which are identi®ed as nonfunc- tional goals.
3.3. Building use case models
To structure a use case and its extensions, we extend the work by Cockburn [10] by considering several different types of goal. Essentially, each use case is viewed as a process that can be associated with a goal to be achieved, optimized, or maintained by the use case (Fig. 2). To start with, we ®rst consider original use cases to guarantee that the target system will be at least adapted to the minimum requirements. Each original use case in our approach is associated with an actor to describe the process to achieve an original goal which is rigid, actor-speci®c and functional (Fig. 2). Building original use cases by investigating all original goals will make the use case model satisfy at least all actors' rigid and functional goals.
The basic course in an original use case is the simplest course, the one in which the goal is delivered without any dif®culty. The alternative course encompasses the recovery course and/or the failure one. The recovery course describes the process to recover the original goal, whereas the failure one describes what to do if the original goal is not recoverable.
In our example, the use case plan a meeting covers the case for an initiator to achieve the goal MeetingRequestSa- tis®ed (Fig. 3) which is rigid, actor-speci®c and functional.
The use case starts when an initiator issues a meeting request to the system, and lasts until a meeting schedule is generated or canceled. It is the basic course that forms the foundation when specifying a use case and this should be
3 Similar ideas are advocated in Ref. [3], where achievement and main- tenance goals map to actions and nonfunctional requirements, respectively.
Fig. 2. Extends relationships between use cases.
described ®rst. The use case has several alternative courses that may change its ¯ow. An example of this is different ways of recovering the goal MeetingRequestSatis®ed when there exists a strong con¯ict in a schedule.
Original use cases are designed to satisfy original goals for modeling users minimum requirements. To extend the model to take into account different types of goals, exten- sion use cases are created. Situations about when to create extension use cases are fully discussed below:
² To optimize or maintain a soft goal. By achieving a rigid goal, all its related soft goals can also be satis®ed to some extent. To optimize or maintain the soft goals, extension use cases are created (see Fig. 2, the use case E1). There- fore, the basic course in an extension is to optimize (or maintain) its soft goal, whereas an alternative course describes what to do if it fails to optimize (or maintain) the goal. In our example, to satisfy the rigid goal Meet- ingRequestSatis®ed does not guarantee that the meeting is convenient for all participants. To make the schedule as convenient as possible, the extension make a conve- nient schedule is created. If the constraints in the basic course are not satis®ed, the alternative course is to recover the optimization of the soft goal, for example, to extend the date range, or to ask participants to add dates to their preference sets.
² To achieve a system-speci®c goal. An extension use case may be created to achieve a system-speci®c goal (see Fig.
2, the use case E2). Referring to our example, the original use case plan a meeting describes the process to create a meeting from a personal view (the view of the actor initia- tor). The extension use case accommodate important meet- ings extends it to take all initiators into account, that is, to achieve a system-speci®c goal SupportFlexibility.
² To achieve a nonfunctional goal. To extend a use case model to capture nonfunctional requirements, extension use cases are added to achieve a nonfunctional goal (see Fig. 2, use case E3). In this case, an extension use case
serves as a constraint to qualify its original use case. In our example, the original use case plan a meeting is a direct course to create a meeting, several constraints (may be rigid or soft) on a meeting are ignored: AppropriatePerfor- mance, MaxNumerOfParticipants and MaxConvenien- ceSchedule. The basic course of make a convenient schedule indicates the soft constraints on a meeting sche- dule. If the constraints are not satis®ed, the alternative course is to recover the optimization of the soft goal.
To summarize, an original goal is a goal that is krigid, actor- speci®c, functionall, whereas a goal that is achieved, opti- mized or maintained by an extension use case is called an extension goal. An extensional goal is weakly dependent on its associated original goal, that is, the existence of an exten- sion goal is dependent on an original one. It should be noted that satisfying an original goal does not always make its asso- ciated extension goals satis®ed (or satis®ed to degree), except- ing that the extension goal is a soft one.
4. Evaluating goals interactions
Interactions between goals can be evaluated through the following steps: (1) analyze the interactions between use cases and goals by investigating the effects on the goals after the use cases are performed; (2) explore the interac- tions between goals in the use case level; and (3) derive the interactions between goals in the system level.
4.1. Relationships between use cases and goals
To better characterize the interactions between use cases and goals, we have adopted predicates proposed by Mylo- poulos et al.[26]: satis®ed, denied, satis®able, and deniable.
A goal can be either satis®ed or denied, if the goal is achieved or ceased utterly, respectively. On the other hand, the predicates satis®able and deniable are used to describe a goal that can be satis®ed or denied to a degree.
Fig. 3. A goal-driven use case model for meeting scheduler system.
In addition, a predicate independent is introduced to describe the situation that a goal will not be affected by performing a designated use case.
A use case is designed to achieve, optimize or maintain its directly associated goals. However, it may occur that goals not directly associated with the use case can also be affected, called side effects. Interactions between use cases and goals can be analyzed by investigating the effects on the asso- ciated goals and side effects on other goals after the use cases are performed:
² Effects on the associated goals. An original goal can be achieved by performing its original use case, that is, the goal can be satis®ed either by performing the basic course successfully or by recovering the goal from an alternative course (see Fig. 4, arrow (a)). The goal can also be denied under the condition that it is ceased by performing an alternative course. Similarly, an extension goal can be satis®ed or satis®ed by performing its asso- ciated extension use case (see Fig. 4 arrow (b)).
² Side effects. There are three cases that side effects may occur (see Fig. 4, arrows (c), (d) and (e)). (1) By perform- ing an original use case successfully, the extension goals which are directly associated with its extension use cases are also achieved to some extent, that is, the extension goals are satis®able (see Fig. 4, arrow (c)). For example, if the use case plan a meeting is successfully performed, the extension goal MaxConvenienceSchedule is satis®ed to a degree. (2) An extension use case may impair the original goal which is directly associated with its original use case (see Fig. 4, arrow (d)). In this case, the original goal is denied. Referring to our example, the extension use case accommodate important meetings may cease the original goal MeetingRequestSatis®ed under the condi- tion that there is a more important meeting that is in con¯ict with it. (3) An extension use case may achieve or impair an irrelevant goal which is associated with other extension use cases (see Fig. 4, arrow (e)). A typical example of impairing an irrelevant goal in the meeting scheduler system is that performing the extension use
case keep a appropriate performance may cease the activity to negotiate a convenient schedule, therefore, the soft goal MaxConvenienceSchedule is deniable.
4.2. Interactions between goals in the use case level Interactions between goals can be considered in two different levels: use case level and system level. The former concerns the interactions between goals with respect to (wrt) a speci®c use cases, and the latter focuses on the overall system. In the use case level, two goals are said to be con¯icting wrt a use case, if the satisfaction of one goal is increased, while other is decreased after the use case is performed. On the other hand, two goals are said to coop- erate with each other, if both the satisfaction degrees of the goals are either increased (positively cooperative) or decreased (negatively cooperative). The third possibility is that the satisfaction degrees of goals remain unchanged. In this case, the goals are said to be irrelevant.4
Interactions between two goals wrt a use case can be derived by interactions between the use case and goals.
For example, if the interactions between a use case Ukand goals Giand Gjare satis®able and deniable, respectively, it means that the satisfaction degree of Giis increased and that of Gj is decreased after Uk is performed. The interactions between Giand Gjwrt Ukis said to be con¯icting.
The predicates cpUk (Gi,Gj) and cfUk (Gi,Gj) are intro- duced to describe the relationship between goals Giand Gj
wrt the use case Uk, where cpUk(Gi,Gj) is true if Giand Gjare cooperative wrt the use case Uk, and cfUk (Gi,Gj) is true if Gi
and Gj are con¯icting wrt Uk. If the goals Gi and Gj are irrelevant wrt Uk, the predicates cpUk (Gi,Gj) and cfUk (Gi,Gj) are both false. Referring to our example, the relationships between the use case make a convenient schedule and the goals MaxConvenienceSchedule and AppropriatePerformance are satis®able and deniable, respectively. Therefore, we can conclude that the two goals are con¯icting wrt the use case make a convenient
Fig. 4. Interactions between use cases and goals.
4 Similar ideas are also advocated in our previous work [22].
schedule (that is, cfmake a convenient schedule (MaxConve- nientSchedule, AppropriatePerformance) True).
4.3. Interactions between goals in the system level
In the use case level, relationships between any two goals are analyzed wrt a speci®c use case, whereas relationships between goals in the system level are mainly on the use case models where related use cases are amalgamated together.
In addition, as Ebert pointed out in Ref. [16], there is more relevance in the case of nonfunctional requirements compared to functional requirements as there are in most systems severe trade-offs among nonfunctional require- ments. Our approach focuses on the relationships between nonfunctional goals in the system level.
The interaction between the goals Giand Gjin the system level is denoted as Rs(Gi,Gj), and is de®ned as a pair of predicates kcp(Gi,Gj),cf(Gi,Gj)l, where cp(Gi,Gj) is true if G
iis cooperative with Gj, and cf(Gi,Gj) is true if Giis con¯ict- ing with Gj in the system level. There are four possible interactions between goals in the system level:
² Rs Gi; Gj kFalse; Falsel : Giand Gj are irrelevant in the system level;
² Rs Gi; Gj kTrue; Falsel : Giand Gjare cooperative in the system level;
² Rs Gi; Gj kFalse; Truel : Gi and Gjare con¯icting in the system level;
² Rs Gi; Gj kTrue; Truel : Gi and Gj are counter- balanced in the system level.
In our approach, interactions between nonfunctional goals in the system level can be derived based on use case models and relationships between use cases in the use case level. In the following paragraphs, we will describe how to derive interactions between goals in the system level by means of the example in Fig. 5, where Gi1and Gj1 are two nonfunctional goals and Ui1, Uj1 are their associated use cases, respectively. Ui is an original use case of Ui1, and Giis its associated original goal.
To explore the interaction between the nonfunctional goals Gi1and Gj1, the original goals that the nonfunctional goals are weakly dependent on should also be considered. In Fig. 5, the extension goal Gj1 is achieved (optimized or
maintained) under the situation that Gi is satis®ed, thus the interaction between Gi1 and Gj1 wrt the use case Ui should be also taken into account. More precisely, the interaction between Gi1 and Gj1 (i.e. Rs(Gi1,Gj1)) hinges on: (1) the interaction between Gi1 and Gj1 wrt the use case Ui; (2) the interaction between Gi1 and Gj1 wrt the use case Uj; (3) the interaction between Gi1 and Gj1 wrt the use case Ui1; and (4) the interaction between Gi1 and Gj1 wrt the use case Uj1. That is, Rs Gi1; Gj1 kcp Gi1; Gj1; cf Gi1; Gj1l; where
cp Gi1; Gj1 cpUi Gi1; Gj1 _ cpUj Gi1; Gj1 _ cpUi1 Gi1; Gj1 _ cpUj1 Gi1; Gj1;
cf Gi1; Gj1 cfUi Gi1; Gj1 _ cfUj Gi1; Gj1 _ cfUi1 Gi1; Gj1 _ cfUj1 Gi1; Gj1
In our example, let Rs GMCS; GAP kcp GMCS; GAP;
cf GMCS; GAPl be the relationship between the nonfunc- tional goals MaxConvenienceSchedule (GMCS) and Appro- priatePerformance (GAP) (UPM and UKAP are abbreviation for the use cases plan a meeting and keep appropriate performance, respectively):
cp GMCS; GAP cpUPM GMCS; GAP _ cpUMCS GMCS; GAP _ cpUKAP GMCS; GAP
False
cf GMCS; GAP cfUPM GMCS; GAP _ cfUMCS GMCS; GAP _ cfUKAP GMCS; GAP
True
Therefore, the goals MaxConvenienceSchedule and Appro- priatePerformance are in con¯ict with each other.
5. Structuring fuzzy object-oriented models speci®cations through goals interactions
Having developed use cases and analyzed their interac- tions, we can now focus on the structuring of fuzzy object- oriented models. The tenet of our structuring mechanism is on the utilization of the interactions found among goals.
There are two steps involved: (1) to establish a goals hier- archy for obtaining alternative models speci®ed using fuzzy object-oriented models notations; and (2) to construct a stable kernel in an incremental fashion to serve as a basis for integrating alternative models.
5.1. Establishing a goals hierarchy
Instead of putting heavy efforts on resolving con¯icts at the beginning of system design which may overload
Fig. 5. All illustration of a use case model.
analysts, we start with constructing a model to meet a set of con¯ict-free requirements. To this end, we organize the goals into several alternatives based on the interactions analyzed such that each alternative contains a set of goals that are not con¯icting with each other. In another word, no con¯ict is allowed in an alternative. More speci®cally, goals organized into alternatives must satisfy the constraints below:
² For any two goals Gi and Gj in an alternative, the interaction between Giand Gjis either cooperative or irre- levant.
² For any two alternatives Aiand Aj, there exist goals Gi[ Ai
and Gj[ Ajsuch that the interaction between Giand Gjis either con¯icting or counterbalanced.
² For any alternative Ak and goal Giwhere GiÓ Ak, there exists a goal Gk[ Aksuch that the interaction between Gi and Gkis either con¯icting or counterbalanced.
In order to explore all the possible alternatives, we utilize the notion of a goals hierarchy in which alternatives are obtained by tracing each path from a leaf node up to the root. The following algorithm outlines the process involved in establishing a goals hierarchy. As functional goals are usually the basic requirements that must be satis®ed, they are placed on the root of the hierarchy and therefore included in every alternative.
Algorithm (Establish a Goals Hierarchy)
1. Place the functional goals on the top of the hierarchy (i.e. the root of the hierarchy).
2. Create an alternative:
(a) Select a nonfunctional goal, say Gi; place Gias a child node of the root and set it as the current node;
(b) If there exist nonfunctional goals that are not con¯icting or counterbalanced with any goal that precedes the current node;
i. Select a goal from those nonfunctional ones, say Gj.
ii. Place Gjas the child node of the current one.
iii. Set Gjas the current node.
iv. Repeat step 2.b.
(c) Else go to step 3.
3. Backtrack to create another alternative:
(a) If there exist nonfunctional goals that are con¯ict- ing or counterbalanced with the current node, but not con¯icting or counterbalanced with any goal that precedes the current node;
i. Select a goal from those nonfunctional ones, say Gj.
ii. Place Gjon the right of the current node.
iii. Set Gjas the current node.
iv. Go to step 2.b.
(b) Else if the current node is the root node, then exit;
else reset the current node as the parent of the current node and go to step 3.
Fig. 6b illustrates how a goals hierarchy is established.
The goals G2, G3and G5are added incrementally to the root (i.e. the functional goals) to form an alternative. Since adding the goal G6or G4to the alternative will result in a con¯ict, we backtrack to create another alternative. By
Fig. 6. An illustration on how to establish a goals hierarchy.
Fig. 7. A goals hierarchy for meeting scheduler system.
doing so, we have come up with three different alternatives:
{GFG,G2,G3,G5}, {GFG,G2,G6}, and {GFG; G4; G3; G5} (Fig. 6c).
By applying the above algorithm to our meeting scheduler example, two alternatives can thus be built (Fig.
7): {GMRS,GPD,GMCS,GMNOP,GSF}, and {GMRS; GPD; GAP; GMI}:
5.2. Constructing a stable kernel
Essentially, a kernel contains all the functional require- ments and a set of nonfunctional requirements that are either cooperative or irrelevant to each other (i.e. no con¯ict is allowed). A kernel is stable in the sense that no engagement in the annoying con¯icts resolution is required, and that it can be used to serve as a basis for further re®nement in an incremental fashion.
To choose a stable kernel from the alternatives found in the previous step, the cooperative degree and importance degree of an alternative are introduced. A cooperative degree of an alternative is de®ned as the total numbers of cooperative interactions within the alternative. In Fig. 6c, the cooperative degree of the alternative A1 is equal to 1 since there is a cooperative interaction between G3and G5.
The importance degree of an alternative is the sum of the weights of goals in the alternative. We adopt Saaty's pair- wise comparison approach to the assignment of weights to goals [35]. That is, the relative weights of each goal pair are used to form a reciprocal matrix, and the absolute weight of each goal is obtained from the normalized eigenvector using eigenvalue method. In the meeting scheduler system (Fig.
7), as the alternatives A1and A2have the same cooperative degrees, we evaluate the alternatives based on their impor- tance degrees. The alternative A1 is chosen as the stable kernel since it carries a higher importance degree than that of the alternative A2.
To construct the kernel model, fuzzy object-oriented models [25] are used to model imprecise requirements. In fuzzy object-oriented models, we have identi®ed several kinds of fuzziness that are required to model imprecise information involved in user requirements.
² classes with imprecise boundary to describe a group of objects with similar attributes, similar operations and similar relationships;
² rules with linguistic terms that are encapsulated in a class to describe the relationships between attributes;
² ranges of an attribute with linguistic values or typical values in a class to de®ne the set of allowed values that instances of that class may take for the attribute;
² the membership degree (i.e. ISA degree) between an object and a class, and between a subclass and its super- class (i.e. AKO degree) can be mapped to the interval [0,1]; and
² associations between classes that an object instance may participate to some extent.
5.2.1. Inside a fuzzy class
Traditionally, a class is used to describe a crisp set of objects with common attributes, common operations and common relationships. In order to model the impreciseness rooted in user requirements, fuzzy object-oriented models extends a class to describe a fuzzy set of objects (called a fuzzy class), in which objects may have similar attributes, similar operations and similar relationships, for example, a set of interesting books or a class of clever students. In the meeting scheduler system, the class ImportantParticipant is modeled as a fuzzy class, that is, a participant may be an important one to a degree.
A fuzzy class in fuzzy object-oriented models is an encapsulation of a number of properties that can be classi-
®ed as static properties or dynamic ones. Static properties are viewed as integral features of an object that exist for its lifetime including identi®er, attributes and operations. On the other hand, dynamic properties are optional for an object and can be short-lived such as fuzzy rules.
Since a fuzzy class is a group of objects with similar static properties (i.e. attributes, operations) and similar dynamic properties (i.e. relationships and rules), the membership degree of an instance to a fuzzy class is dependent on the properties, especially the values of attributes and the values of link attributes. In our example, the degree that a person belongs to the class ImportantParticipant depends on his status and his role in the meeting he attends.
5.2.1.1. Attributes with fuzzy ranges. In fuzzy object- oriented models, the fuzziness in the range of an attribute in a class may be due to either a linguistic term or a typical value.
² A class may be fuzzy for the linguistic values its attributes can take. For example, the class YoungMan has a fuzzy range for the attribute age, since a person may take young or very young as values for his age.
² The range of an attribute is fuzzy [19] because some of its values are deemed as atypical (i.e. less possible than other values), therefore, each value the attribute may take is associated with a typical degree.5 In our example, the class ImportantParticipant has a fuzzy range {student/0.4, staff/0.7, faculty/1} for the attribute status, which means that a faculty is typically an important participant, and a student is an important participant with a typical degree of 0.4.
It is of interest to note that a crisp class may have attributes with fuzzy ranges. For instance, the class MeetingRegistration is a crisp class, with an attribute participant importance, which is associated with a fuzzy range.
5.2.1.2. Fuzzy rules. Incorporating fuzzy rules in
5 The notion of typical values is adopted from Ref. [14].
object-oriented analysis can help enrich the semantics of analysis models [17]. Using fuzzy rules is one way to deal with imprecision where a rule's conditional part and/or the conclusions part contains linguistic variables. More speci®cally, fuzzy rules in a fuzzy class play two important roles: to specify internal relationships between attributes, and to describe triggers more explicitly. Fuzzy rules are used to describe the internal relationship or external relationship. In the former, fuzzy rules describe the relationship between attributes inside a class. For example, a rule ªif the role is a staff, the participant importance is less importantº describes the relationship between the attributes role and participant importance. In the latter, fuzzy rules are used to describe the relationship between two different classes.
5.2.2. Fuzzy classi®cation
Perceptual fuzziness refers to the compatibility between a class and an object (i.e. ISA), and the class membership between a class and its subclass (i.e. AKO) [41]. In fuzzy object-oriented models, we extend crisp class memberships to fuzzy class memberships by allowing the existence of perceptual fuzziness. In the meeting scheduler system, a person may belong to the class ImportantParticipant to some extent.
The membership degree of an object to a class is estab- lished either explicitly or implicitly [6]. In [20], the ISA degree is explicitly given, and used to derive the values of attributes of the object. In fuzzy object-oriented models, the
ISA degree is implicitly determined by the structure of classes. The perceptual fuzziness of an object to a class or a subclass to its superclass is calculated by evaluating both the static properties and dynamic properties. Referring to our example, the membership degree of a person to the class ImportantParticipant can be obtained by checking his status (static property) and his role in the meeting he attends (dynamic property).
5.2.3. Uncertain fuzzy associations
Links and associations are means for establishing rela- tionship among objects and classes. A link is a physical or conceptual connection between object instances. For exam- ple, John work-for Simplex company. An association describes a group of links with common structure and common semantics. For example, a person work-for a company. In traditional object-oriented approaches, only crisp associations are introduced, namely, an object either participates in an association or not.
Usually, certain and precise knowledge about an associa- tion is not always available in the user requirements;
furthermore, users' observations are sometimes uncertain and imprecise. Therefore, an adequate management of uncertainty and imprecision in the phase of requirements analysis is an important issue. The distinction between imprecise and uncertain information can be best explained by Dubois and Prade [13]: imprecision implies the absence of a sharp boundary of the value of an attribute; whereas,
Fig. 8. A kernel model for the meeting scheduler system.
uncertainty is an indication of our reliance about the fuzzy information.
A uncertain fuzzy association is allowed in fuzzy object- oriented models. The imprecision of an association implies that an object can participate in the association to some extent, whereas uncertainty is referred to the con®dence degree about the association. To represent the imprecision of an association, a special link attribute is introduced in fuzzy object-oriented models to indicate the intensity that objects participate in an association. Fuzzy truth value, such as true, fairly true and very true, is used to serve as the representation of uncertainty for its capability to express the possibility of the degree of truth [23].
A link between x and y which is an instance of the asso- ciation R is represented as a canonical form in fuzzy object- oriented models:
link attribute; kx; yl; degree of participation; t
where the ®rst component of the quadruple is a link attribute of an association. The value that a link kx,yl takes for the link attribute is described in the degree of participation, which represents the degree that objects x and y participate in the association R. The value is a linguistic term such as very high, high or low. The fuzzy valuationtis a con®dence level of the fuzzy association, whose value is a fuzzy truth value.
For example, an important participant can identify his preference for locations and the intensity of his preference.
Sometimes it is not certain whether a participant prefers a speci®c location or not. To model the relationship between important participants and locations to be an uncertain fuzzy association prefer will help the meeting scheduler system to resolve con¯icts and make a most convenient schedule. A link attribute preference is associated with the association prefer to indicate the degree of preference. By stating that a link between John and L102 is (preference,kJohn, L102l, strong,very true), we mean that it is very true that John strongly prefers the location L102.
Constraints with imprecise information are also allowed in fuzzy object-oriented models, called soft constraints. For example, the requirement ªa meeting location should be as convenient as possible for all important participantsº is modeled as a soft constraint on the associations prefer and take place.
Fig. 8 is a kernel model for the meeting scheduler system in fuzzy object-oriented models notations. Goals Meetin- gRequestSatis®ed, ParticipantDelegated and MaxConve- nienceSchedule are included in the kernel model.
5.3. Integrating alternatives
Since the rest of the requirements are con¯icting with the requirements in the kernel, con¯icts resolution is required in this stage. In order to handle con¯icts, we explore the root of con¯icts to lead us to the resolution of con¯icts or even better the prevention of con¯icts.
Fig. 9. An alternative use case to achieve support¯exibility.
Fig. 10. Resolving con¯icts from competing resources by specialization.
Table 2
Con¯icts resolution for the con¯ict between the goals GMCSand GAP
Degree of impairment Degree of importance Solution
IGAP(GMRS) . IGMRS(GAP) P(GMRS) . P(GAP) Competition: selecting GMRS
IGAP(GMRS) . IGMRS(GAP) P(GMRS) . P(GAP) Compromise IGAP(GMRS) , IGMRS(GAP) P(GMRS) , P(GAP) Compromise
IGAP(GMRS) , IGMRS(GAP) P(GMRS) , P(GAP) Competition: selecting GAP
5.3.1. Root of con¯icts
5.3.1.1. Competing resources. A con¯ict occurs when goals are competing with a mutually exclusive resource (i.e. the resource can not be shared by at the same time).
In the library system, patrons wish to keep books as long as they need, whereas the librarians wish to keep books avail- able in the library. A con¯ict arises because patrons and librarians are competing with the resource ªbooksº.
5.3.1.2. Divergent expectations. A con¯ict occurs whenever goals have divergent expectations on their common interest.
For example, the goal MaxPro®ts from producers and the goal MinCosts from customers are both interested in the cost of a product. A con¯ict arises in that they have divergent expectations on the production's price. The common interest of goals may be an object's properties (e.g. the price of a product), an object's behavior, or a relationship between objects. In the meeting scheduler system, the goals ParticipantPreferenceKnown and ParticipantPrivacy are both interested in the relationship between participants and their preferences: whether a participant can know other participants' preferences. A con¯ict arises in that one goal expects that a participant can know other participants' preferences, whereas another goal does not.
5.3.1.3. Side effects. A con¯ict between goals arise whenever a use case to achieve a goal has a side effect on other goals. Con¯icting goals in this case do not necessarily have a common interest. Referring to the meeting scheduler system, the goal MaxConvenienceSchedule is interested in the convenience of a meeting and AppropriatePerformance is interested in the elapsed time to make a schedule.
Applying the use case make a convenient schedule to optimize the goal MaxConvenienceSchedule leads to the
behavior of resolving weak con¯icts (i.e. a meeting schedule is not preferred by all participants). On the other hand, applying the use case keep appropriate performance leads to the prohibition of resolving weak con¯icts. It should be noted that the con¯ict is caused by the side effects of use cases, rather than divergent expectations on a common interest or competing with a common resource.
Another example is the con¯ict between MeetingRequest- Satis®ed and SupportFlexibility. The use case accommodate important meetings illustrates the process to optimize the goal SupportFlexibility: if a meeting's schedule is deter- mined but con¯icting with another meeting with a higher priority, it may be canceled in order to accommodate a more important goal. Note that this kind of con¯ict is tightly related to the use cases we constructed, and can be prevented by constructing alternative use cases (Section 5.3.2).
5.3.2. Con¯icts resolution
A con¯ict can be resolved based on the causes of the con¯ict, the possibility of occurrence of the con¯ict, and the severity of the con¯ict consequences. Three resolution techniques are proposed to handle con¯icts: to avoid the occurrence of con¯icts by prevention, to reach a consensus between con¯icting goals by compromise, and to achieve a goal without regard to another by competition.
5.3.2.1. Prevention. The best strategy of handling con¯icts is to prevent con¯icts from happening. Con¯icts can be prevented by adding arbitrators or seeking alternative use cases, based on the causes of con¯icts.
² To prevent a con¯ict from competing resources, a resource arbitrator may be introduced to distribute the resource. Using this heuristic rule, the con¯icts between patrons and librarians can be prevented by introducing a book arbitrator.
² To prevent a con¯ict from side effects, an alternative use case is proposed to substitute for the original one. As mentioned in Section 5.3.1, the con¯ict between SupportFlexibility and MeetingRequestSatis®ed occurs is due to the use case accommodate important meetings which may cancel a meeting.
The use case described in Fig. 9 is an alternative use case to optimize the goal SupportFlexibility without having to cancel a meeting: a meeting
Fig. 11. Resolving con¯icts from divergent expectations by specialization.
Fig. 12. Integrating alternative for the meeting scheduler system.
excludes all meetings' schedules out of its date range to avoid possible con¯icts with other meetings.
5.3.2.2. Compromise. To reach a compromise, each goal involved in the con¯ict should make some concessions.
Compromise can be reached by specializing an object class into disjoint subclasses with different associations linked to the corresponding subclasses.6
² Con¯icts from competing resources can be resolved by specializing the resource or the objects competing with the resource. Consider the con¯ict between the goal BookKeptAsLongAsNeeded and BookAvailableInLib, we can resolve it by specializing the Patron (the object competing with the resource) into two subclasses:
Student who must return books in two weeks and Faculty who can keep books as long as he/she needs, or specializing the Books (the resource) into ReservedBook and UnreservedBook (Fig. 10).
² Con¯icts originated from divergent expectations on a relationship can be resolved by specializing the objects involved in the relationship. The con¯ict between ParticipantPreferenceKnown and ParticipantPrivacy can be resolved by specializing Participant into PrivilegedParticipant and NonPrivilegedParticipant, and restricting the privileged participants to have the right to access other participants' preferences.
² Con¯icts due to divergent expectations on an object's behavior can also be resolved by specialization. For example, the con¯ict between MaxConvenience Schedule and AppropriatePerformance can resolved by specializing Meeting into two subclasses: Professional Meeting that must be scheduled as convenient as possible, and PrivateMeeting that must be scheduled as soon as possible (Table 2, Fig. 11).
5.3.2.3. Competition. Resolving con¯icts by competition refers to satisfying one of the con¯icting goals without regard to the others. The competition between goals depends on: (1) the importance degree of each goal involved in the con¯ict; and (2) the degree of impairment7 to each goal when it cannot be satis®ed. Supposing that G1
con¯icts with G2, IG2 G1 is the degree of impairment to G1
when G2 is satis®ed. IG2 G1 . IG1 G2 denotes that achieving G1 is more bene®cial than achieving G2 (since the overall impairment of achieving G1is less than that of achieving G2).
In our example, if we use competition as a way of resol- ving the con¯ict between MaxConvenientSchedule and AppropriatePerformance, both the degrees of importance and impairment should be considered. The goal MaxConve-
nientSchedule is more important than AppropriatePerfor- mance (Fig. 7). If IGMCS GAP . IGAP GMCS; we prefer to achieve the goal MaxConvenientSchedule without regard to the goal AppropriatePerformance. If IGMCS GAP , IGAP GMCS; a compromise strategy is recommended to resolve the con¯ict because none of the goals can be neglected.
Fig. 12 illustrates the steps involved in resolving con¯icts when integrating the goals MaxNumberOfParticicpants, SupportFlexibility and AppropriatePerformance.
6. Conclusion
As was pointed by Lamsweerde [37], goal information should be captured in the requirements acquisition phase, which is useful for analyzing con¯icting requirements and nonfunctional requirements. The proposed approach is spawned based on this belief to fuse the goal-oriented and object-oriented modeling techniques in requirements engineering.
Our approach offers several bene®ts in: (1) serving as a structuring mechanism to facilitate the derivation of use case speci®cations and objects model; (2) bridging the gap between the domain description and the system require- ments, that is, the interactions between functional and nonfunctional requirements; (3) making easy the handling of soft requirements, and the analysis of con¯icting require- ments; and (4) extending traditional object-oriented techni- ques to fuzzy logic to manage different kinds of fuzziness that are rooted in user requirements.
Our future research plan will consider the following tasks: to investigate the worth-oriented domain advocated by Rosenschein et al. [31] to evaluate dynamic behaviors without actually executing the statechart diagrams; and to conduct a case study on using the proposed approach for modeling university timetabling of our university (National Central University).
Acknowledgements
This research was supported by the National Science Council (Taiwan) under grants NSC88-2213-E-008-006.
References
[1] B. Nuseibeh, A. Russo, J. Kramer, Restructuring requirements speci-
®cations for managing inconsistency and change: a case study, Proceedings of the 20th International Conference on Software Engi- neering, 1998.
[2] R. Darimont, A. van Lamsweerde, E. Leitier, Managing con¯icts in goal-driven requirements engineering, IEEE Transactions on Soft- ware Engineering 24 (11) (1998) 908±926.
[3] A.I. Anton, Goal-based requirements analysis, Proceedings of the International Conference on Requirements Engineering, 1996, pp.
136±144.
[4] R. Balzer, N. Goldman, Principles of good software speci®cation and
6A similar idea is also proposed in Ref. [2].
7A use case is said to impair a goal if the performance of the use case may result in the dissatisfaction of the goal.
