Conflict-Oriented Requirements Restructuring - Semantic Scholar

Conflict-Oriented Requirements Restructuring William N. Robinson and Slav Volkov

Abstract—Requirements engineering necessitates the analysis of relationships among the requirements of system stakeholders. Poor analysis of these relationships has led to numerous failures. To improve such analysis, researchers have created models and methods for recording, analyzing, and modifying stakeholder requirements. However, the critical aspect of representing and reasoning about stakeholder interactions remains relatively implicit. Herein, we explicitly define: (1) a meta-model for capturing stakeholder requirements, (2) transformations for restructuring requirements which remove stakeholder conflicts, and (3) strategies for interactively guiding the restructuring process. To validate the utility of our approach, we have applied it to the analysis of a distributed meeting scheduler. We conclude that the meta-model can provide substantial automated support for the removal of stakeholder conflicts through its requirements restructuring transformations. Index Terms—Requirements engineering, meta-modeling, stakeholder negotiation, conflict resolution I. INTRODUCTION

R

EQUIREMENTS engineering is largely concerned with bridging the gap between the informal descriptions of clients and the more formal descriptions of systems developers. Naturally, much of requirements engineering research has focused on the processes and products of elicitation and formalization. Across the variety of research efforts, there is a growing consensus that requirements analysis must entail the representation and analysis of the agents that interact with the proposed system at run-time[18]. This approach has been called stakeholder analysis. Stakeholder analysis concerns the representation and reasoning about agents which affect or are affected by the system. It is mainly focused on run-time agents (e.g., system users)[7], but can include support for design-time agents (e.g., systems analysts)[36]. In requirements engineering, stakeholder analysis aims to derive a quality system description that covers all relevant interests by incorporating the varied developer, user, and other system perspectives[5]. It is a technique aimed to better development through cooperative work[25], as well as better systems use through analysis of stakeholder interactions[43]. Stakeholder analysis aims to understand the rich interactions among system stakeholders. Common concerns include: • Who are the relevant system stakeholders? • For a decision concerning requirement, Ri, which other requirements will be effected?

•

Who are the effected stakeholders concerning changes to requirement, Ri?

•

How can negative interactions among requirements held by different stakeholders be removed? For requirement interaction, Ii, what is the relation to other requirements interactions? (For example, does removing interaction, Ii remove interaction, Ij?)

•

These kinds of questions focus on the implications of multiple stakeholder requirements. A system, once installed, perpetuates policies (intended or otherwise) which affect how users interact with each other[30]. By analyzing such interactions prior to system installation, we have a better chance of meeting user needs. Stakeholder analysis has received considerable attention from the softer side of systems development, including participatory[49], social-technical[33], or soft systems design[6]. These approaches were developed to overcome the failure of systems to address users’ needs—too often systems fail because developers do not assess and meet the needs of system users [30]. More recently, concurrent engineering has taken up a similar approach with regard to development—by considering development issues from analysis through design and manufacturing, the development cycle is reduced while producing better products[27]. Stakeholder requirements analysis can be likened to the multi-agent planning problem: one attempts to achieve all agents goals despite any conflicting or contradictory goals[53]. However, unlike many planning contexts, requirement engineering is about determining the appropriate goals[44]. Hence, goal modification and restructuring are just as much a part of requirement engineering, as is goal formalization. Unfortunately, there has been less research into modeling and formalizing requirements restructuring in response to stakeholder conflicts. Two streams of research have made substantial progress on formal stakeholder analysis. First, various modeling formalisms for stakeholder goals and relationships have been developed [7][8][43]. Second, various procedures for resolving stakeholder goal conflicts have developed[1][24][25][52]. However, currently there is no formal requirements model which explicitly links stakeholder conflicts to resolution producing requirements transformations. In fact, resolution procedures and strategies from a variety of domains implicitly defined in the code of programs[1][22][46]. To support stakeholder analysis and bring to the fore conflictoriented requirements restructuring, we have developed a metamodel with a focus on stakeholder requirements interaction. Formal meta-modeling has been applied to Methodology Engineering[26], Meta-CASE tools[19], Database Management [4], and Requirements Engineering[35]. In general, meta-modeling involves: • formalization of contextual representations • formalization of transformation and integration methods

CONFLICT-ORIENTED REQUIREMENTS ANALYSISGSU Working Paper CIS-96-15

• linkage of models and methods into overall methodologies Our meta-model defines representations for stakeholder requirements, their interactions, as well as associated restructuring transformations. Additionally, we have developed a control strategy for guiding the application of the restructuring transformations. Together, we call this approach Conflict-Oriented Requirements Analysis (CORA). To evaluate the effectiveness of the CORA meta-model and strategies, we conducted a case-study of its application. The study involved stakeholder analysis of requirements for a distributed meeting scheduler. Additionally, we have constructed a prototype to support CORA, called REQUIREMENTS DEALMAKER. From the analysis of the case-study and our prototype implementation, we conclude that the CORA meta-model can provide substantial automated support for the restructuring of conflicting requirements. The remainder of this article consists of four parts. First, in sections II and III, we introduce the conflict-oriented requirements analysis and the CORA meta-model. Next, we describe automated tool support for CORA. The case-study description follows. Finally, we present our conclusions. II. CONFLICT-ORIENTED REQUIREMENTS ANALYSIS Our meta-modeling techniques support a generic paradigm of requirements analysis which we call Conflict-Oriented Requirements Analysis (CORA). CORA assumes a cycle among three phases requirements analysis: 1) System requirements are defined. 2) Issues arise, through analysis of the requirements, which indicate possible conflicts among requirements. 3) Requirements are changed in response to the conflicts. Many requirements process models can be seen as instantiations of this generic model. Issues often arise through some scenario-like analysis of requirements interactions[10][37]. Issues can also arise through an attempt to combine requirements which originate from multiple stakeholders[5][36]. In both cases, requirements are often found to have undesirable interactions which prevent their mutual satisfaction; that is, they conflict. While our meta-modeling techniques are oriented toward conflicts among requirements which originate from different stakeholders, they can still be applied when the requirements are initially defined without associated stakeholders (as shown herein). As illustrated in Fig. 1, our CORA Meta-Model (CORAMM) provides modeling and transformations for a CORA cycle: 1) System requirements are defined as instantiations of a requirements meta-model. 2) Issues arise through analysis of the requirements which lead to varied responding stakeholders positions. 3) A focusing strategy guides the order in which possible conflicts are to be analyzed. 4) Conflicts are identified through analysis of the varied stakeholder positions. 5) Applicable requirements restructuring transformations are instantiated from a restructuring meta-model. 6) A restructuring strategy guides the application of the requirements transformations which result in new requirements.

2

We also have interactive tools which support analysis using CORA. Our the tool set does conflict analysis, indicates applicable transformations, applies a transformation, and suggests a transformation ordering; however, it is the analyst who makes the decisions transformation application and resolution selection. III. A CORA META-MODEL CORA-MM is not a complete methodology or process model. Instead, it defines a meta-model and meta-strategies for restructuring requirements as a means to remove or reduce stakeholder conflicts. It can be viewed as a tool-kit of basic resolution transformations and strategies linked to a requirements model. As such, the CORA-MM requirements model was defined as an interface to restructuring transformations and indicates minimal meta-model requirements for the application of CORA-MM. Hence, users of the CORA-MM may extend the requirements model and create domain specific restructuring transformations and strategies. Within this section, after introducing our example domain, we trace the analysis cycle of Fig. 1 describing the CORA requirements meta-model, conflict analysis within the model, the CORA restructuring meta-model, and strategic application of the transformations. A. Requirements for a Distributed Meeting Scheduler Throughout this article, we draw on examples from our analyses of requirements for a distributed meeting scheduler. We choose the meeting scheduler because of: (1) the complex multi-stakeholder interactions (e.g., privacy, responsibility, efficiency) which lead to considerable variation in the resulting implementations, (2) the availability of a widely circulated compact, yet rich, requirements document[55], and (3) the publication of prior analysis of the case[37][54]. Hence, we can compare our analysis with those of others to determine: (1) if the restructuring meta-model would have aided their analyses, and (2) if the restructuring meta-model provides new analyses. Finally, because our restructuring meta-model was developed while analyzing the library[42][44][45] and electronic applet commerce domains[47], we wanted to analyze the meta-model in a new domain—that of distributed meeting scheduling. The general problem of the meeting scheduler can be summarized by the introduction to the requirements[55] Restructuring Strategy

Meta-Level

Requirements MetaModel

Restructuring MetaModel Focusing Strategy

Instance-Level

Restructuring Application

Stakeholderx (Requirementi) Stakeholdery (Requirementi) Issue

Restructuring Transformations Conflict Analysis

Conflict ⊥

i

Fig 1. The instantiation of CORA meta-models during analysis.

A CORA META-MODEL

GSU Working Paper CIS-96-15

The purpose of a meeting scheduler is to support the organization of meetings—that is, to determine, for each meeting request, a meeting date and location so that most of the intended participants will effectively participate. The meeting date and location should thus be as convenient as possible to all participants. Information about the meeting should also be made available as early as possible to all potential participants. ...

The remaining requirements of the four page description refine the roles of the meeting scheduler and participants. However, this introduction will be sufficient to understand the examples that follow. B. Requirement Meta-Model Our requirements meta-model is illustrated in Fig. 2; it defines the semantics of entities and relations by which analysts can define systems requirements. The key elements are: requirement, issue, response, and conflict. Requirements lead to issues whose conflicting relationships can be analyzed. Requirements themselves are qualified assertions about desired states of the system or environment. Issues are questions, such as, “how will requirement Ri be satisfied?”, “what does term ti of Ri mean?”, or “requirements Ri and Rj appear to conflict, how can they be resolved?”. Responses provide the answers to such questions in three different types which resolve the issue: (1) answer, by asserting a universally accepted position— answers end further dialog unless they are retracted or another position is added; (2) position, by providing an (alternative) solution of the issue; and (3) resolution, by providing a solution aimed to satisfy all positions through restructuring. Resolutions are generated through analysis of requirements conflicts, which are of two different types: static and dynamic (cf., [34][51]). Static conflicts indicate differences in the definitions of requirements. Dynamic conflicts indicate a type of operational interaction between requirements; such analysis requires an environmental description which we call context[2]. A context can be associated with all descriptions (e.g., stakeholder, environment, etc.; cf., [36]). Dynamic conflict interaction types include: instrumental, Ri satisfies some preconditions of Rj;

3

enable, Ri satisfies all preconditions of Rj; thwart, Ri removes an assertion which satisfies a precondition of Rj; disable, Ri prevents the satisfaction of Rj. Fig. 3 illustrates a graphic instantiation of the meta-model taken from an analysis of a distributed meeting scheduler. The model begins with requirement Rprivacy which states: Privacy rules should be enforced; only the meeting initiator should be aware of constraints stated by potential participants.

This requirement is typical of stakeholders type found in our case-study requirements document[54]; that is, it is defined from a generic perspective without the attribution or biases of an individual system stakeholder. Stakeholder analysis of such requirements lead to issues, such as issue I19 (“Who should be aware of potential participant constraints?”), which is addressed by stakeholder positions P30 (“Only potential participants”) and P31 (“Only the meeting initiator”).1 As shown in Fig. 3, subsequent conflict analysis of the positions determines that they are mutually disabling. Finally, restructuring based on the conflict analysis provides resolutions Rs79 and Rs80 which address requirement Rprivacy. Resolution Rs79 suggests that both meeting initiators and potential participants should be aware of constraints, but not of the association of participants with constraints. Resolutions Rs80 is simply a compromise among scheduler agents where only the meeting scheduler system is aware of the constraints. In order to determine specific conflict types, a more detailed requirement meta-model is necessary. Fig. 4 illustrates CORA meta-model used for requirements conflict analysis. We assume requirements are stated as quantified logical expressions; hence, the meta-model provides for quantified objects over assertions joined through logical operators (and, or, not). Additionally, a requirement has a mode indicated how it is to be pursued (maintain, achieve, avoid, cease). Other meta-models describe many of the same relationships. For example, our requirement, issue, and response relationships

Rprivacy

I19: Who should be aware of PParticipant(C)?

generates

Context 1,m

Entity

Requirement isA 1,n Position

PartOf PartOf 1,n 0,n connects 2,m Stakeholder Relationship

isA

isA

isA

1

PartOf 1

isA

Issue 0,n responds to 1,n

isA

isA

1,1 1,n

Specialize partOf Requirement

1,m

Transform isA

isA PartOf 0,n

Fig 2. The CORA requirements meta-model.

results in Thwart Enable Disable Instrumental

applies to

1,m

Rs79: PParticipant and MInitiator aware of PParticipant and Constraint

responds to Thwart

transforms

Tt: Distribute

Dynamic 0,m isA

Static

Resolution

Template

P30: PParticipant and no other aware of PParticipant(C)

Conflict

0,n

generates

responds to

P31: MInitiator and no other aware of PParticipant(C) transforms

Tt: Compromise results in Rs80: MScheduler aware of PParticipant(C)

Fig 3. An instantiation of the requirements meta-model. Strategy 1 Position P came about when graduate students wanted to ar30 range a meeting initiated by faculty; it allows students to arrange a meeting without disclosing their complete schedules to faculty.

A CORA META-MODEL

GSU Working Paper CIS-96-15

Mode isA 1

constrains

achieve cease maintain avoid

0,n

Requirement

TABLE I GENERAL CONFLICT CATEGORIES Operational Interaction Conflict

isA 0,n

join

Assertion 0,n

1,n

PartOf 1,m

1,n

Operator

4

No Conflict

Structural Similarity equal unequal Equal requirements but with an Different requirements in implicit agent achiever and which the achievement of at limited resources. least one requirement thwarts the other. Identical requirements. Different requirements with no interaction.

PartOf 0,n

Quantifier

quantifies

1,n

0,n

Entity

join

Fig 4. A more detailed illustration of the requirement meta-model.

are similar to REMAP[40], which in turn is based on the IBIS issue, position, and argument model[57]; however, argumentation is outside the scope of our current model—decisions are simply left to the stakeholders without further analysis. On the other hand, requirement interaction analysis is the focus of the model. Consequently, the requirement and conflict modes are similar to, and partially derived from, the KAOS[8] and strategic[7] meta-models. Of course, there are still other related meta-models, such as the intra-language requirements metamodels[35]. Nevertheless, the CORA meta-model adds functionality, with its focus on conflict-oriented requirements restructuring, which can be integrated into the meta-models from which it was derived. C. The Conflict Analysis Process The goal of conflict-oriented requirements analysis is to uncover the conflicting requirements relationships, such as illustrated in Fig. 3, select an ordering for their resolution, and resolve them through requirements restructuring. An operational model of conflict is a key part of this process. It is assumed that requirements can be characterized as goals which are to be satisfied through the operation of a system within an environment. Hence, requirement interactions can be determined through planning for their satisfaction via the application of environmental or system actions (a.k.a. operators). In this paradigm, requirements failures can be traced to thwarting relations among system or environmental actions (cf., [2]). Static structural comparisons on requirements only hint at their operational interactions.2 As table I indicates, requirements may be structurally equal, but conflicting. This occurs in requirements where multiple agents must use a common limited resource and the distinct agents are implicit in the requirements. Conversely, requirements may be different, and yet have no interaction. By enforcing the explicit use of agents in requirements and engaging a planner among structurally different requirements associated with an issue, one can determine requirement conflict types. Given a set of requirements, one can engage in various strategies for detecting conflicts. For example, one could consider the interactions among all subsets to ensure that every requirement conflict is uncovered. (Analysis of subsets rather than pair-wise comparison is required because some conflicts only arise from 2 This distinction between structural and interaction conflicts is commonly referred to as ends vs. means conflicts in the decision science literature[58].

the interactions of many requirements; for example, resource depletion conflicts.) Even with such complete analysis, new conflicts may still arise from environmental changes. Rather than employ a complete conflict discovery strategy, we employ a domain independent meta-strategy which focuses on the requirements issues and alternative positions as identified by the analyst. The steps of the issue-oriented conflict analysis strategy are: 1) Select an issue. 2) Determine structural differences by comparing definitions of the associated positions. 3) Determine interaction conflicts by engaging a planner to satisfy the joined requirements. Specific pre-condition relationships can be determined by back-propagating requirements failures through a plan of actions [3][43]. Conflicts will fall into four types: instrumental, enable, thwart, and disable. As the conflict strategy is applied, specific conflict types are instantiated from the meta-model. Note that during the requirements analysis, multiple issues may remain unresolved at any one time. To guide the ordered selection of issues for resolutions, we have applied the following two heuristics. • Select an issue which, should it be resolved, may resolve other dependent issues. These can be particularly important as interactions can be causally linked—resolving issue I1 may eliminate issue I2, while the reverse ordering may not be so beneficial. For example, consider where the requirements involved in I2 are instrumental to those in I1—if I1 is resolved by changing the requirements, then I2 may not occur in the new requirements. • Select the issue which has the largest number of dependent issues. This simple corollary to the above heuristic aims to focus restructuring on the most issue which is causing the most conflicts. Once the conflict are identified, their resolution can follow as described next. D. The Restructuring Meta-Model The purpose of the restructuring meta-model is to provide a set of domain-independent transformations which can generate useful resolutions from requirement conflict instances. These transformations are restructuring in that they change the meaning of the requirements in response to requirements interactions, as opposed to design or implementation transformations which attempt to satisfy requirements through various operationalizations.3 We have defined three related classes of restructuring trans-

A CORA META-MODEL

GSU Working Paper CIS-96-15

formations: 1) Object restructuring transformations take objects as input and return related objects for substitution as output; for example, given the object PotientialMeetingParticipant, the specialize transformation can return ActiveMeetingParticipant and ImportantMeetingParticipant. One of these new agents can be substituted in the case of an agent conflict. 2) Distribution transformations distribute conflicting requirements positions across specific contexts, thereby conditionalizing the state under which each position will be met. Sharing a resource through turn-taking is a classic instantiation of distribution.4 As an example, a conflict concerning permissions granted to a PotientialMeetingParticipant could be restructured to a distribution of permissions across specializations of PotientialMeetingParticipant; that is, an ActiveMeetingParticipant receives different permissions than an ImportantMeetingParticipant. Hence, the original positions (varied permissions) are satisfied, but in different contexts. 3) Interaction transformations restructure requirements based on their implied operational relationships. For example, given the possible failure of the requirement Rrespond :: “Participants must respond to a meeting request” and conflicting responding positions of CancelMeeting and DropParticipant, interaction transformations use analysis of the operational relationships among Rrespond, CancelMeeting, and DropParticipant to suggest how to prevent the initial

requirement failure. For example, the transformation, ReinforcePreCondition, can suggest more notifications be provided. Similarly, Replan will attempt to resolve the conflicting positions through planning. In this case, it considers DropParticipant as a substep in a plan satisfying CancelMeeting; hence, the conflict may be resolved by creating a recovery plan for Rrespond with both DropParticipant and CancelMeeting. Of course, the stakeholder putting forward the DropParticipant position probably did not intend for the whole meeting to be cancelled. However, the transformations cannot infer such intent unless it is explicitly part of the requirements. (For example, the “and no other” clause in Fig. 3.) Thus, an analyst must select the appropriate resolution. All of the transformations can be composed with each other. For example, it is common to resolve a conflict by distributing specializations of the conflicting objects over different requirement contexts. Tables III to V define transformations from the three classes. They include specialized notations (for multiple stakeholders, requirements, domain models, etc.) which are summarized in table II. In general, the transformations are presented in the following form: T(⊥in,m, Ri) ⇒ O where T denote transformations applied to n conflicts concerning m stakeholders of requirement Ri producing output O . Based on this representation, we call this approach transformation-oriented conflict resolution. To illustrate each of the three restructuring transformations 3 Decision scientists use the term restructuring to indicate modification to the desired ends[24]. 4 This can be generated by the Onto distribution transformation of table IV applied over a specialized (via partOf) time object.

5

TABLE II SUMMARY OF TRANSFORMATION NOTATION Notation

Meaning

Θ

Domain of values as defined in domain model; Θi is a specific domain.

ℜ

Domain of relations as defined in domain model.

∗

y is an element of the transitive closure of relation ℜi applied to x.

xℜ iy R

Domain of requirements. Ri is the specific requirement i.

∆x ➟Ri

Plan x to satisfy requirement i.

∆y ➟RFRi Plan y to recover from the possible failure of requirement i. ⊥in,m

Conflicting requirement elements. n indexes the conflict, while m indexes the perspective. For example, m different stakeholders may conflict over Ri where the conflict entails n differences in the elements of Ri. “*” matches all, (e.g., all values of perspective m is ⊥i*,m).

Tt

Restructuring transform t.

classes, we present a conflict from the meeting scheduler problem and show the application of three representative transforms. The initial requirement, Rrespond, states that: for all potential meeting participants, if there exists a meeting request of a participant from a meeting initiator, then that participant must respond to that request. Rrespond :: ∀p ∈ PParticipant : ∃ mi ∈ MInitiator, ∃ mr ∈ MeetingRequest (agent mi Send p mr) → ∃rs ∈ MeetingResponse, (agent p Send mi rs)

(Elsewhere, the requirements state that the a meeting request is part of a plan to satisfy a meeting requirement: mr ∈ ∆, m ∈ Meeting : (∆ ➟ m) .) The consideration of what to do if the above requirement failed led to two different stakeholder positions: x:: Drop the non-responding agent from the meeting. ⊥respond*,x = (agent mi DropParticipant p)

y:: Cancel the meeting. ⊥respond*,y = (agent mi CancelMeeting m)

These requirements positions led to the following conflict analysis. 1) The positions have an interaction conflict on the means to recover from a possible requirement failure. (agent mi ax,1 a2,x) ↔ (agent mi a1,y a2,x) a1,x,a2,x ∈ ∆x, ∆x ➟RFRrespond ∧ a1,y,a2,y ∈ ∆y, ∆y ➟RFRrespond

2) There is a structural conflict in the first element which concerns the operation to be performed (DropParticipant or CancelMeeting). ⊥respond1,* = (a1,x ∈ DropParticipant) ≠ (a1,y ∈ CancelMeeting)

3) There is a structural conflict in the second element which concerns the object of the operation. ⊥respond2,* = (a2,x ∈ PParticipant) ≠ (a2,y ∈ Meeting)

Thus, there is a conflict, ⊥respond, concerning the two stakeholder positions, ⊥respond*,x and ⊥respond*,y, over how to recover from a possible failure of requirement Rrespond ; the conflict consists of two conflict elements, ⊥respond1,* and ⊥respond2,*. Given the conflict, various restructuring transforms, T, may apply. Here, we only consider the output, O, of three: T(⊥respond, Rrespond) ⇒ O 1) Compromise. Given a conflict where the conflicting stakeholders put forward different values from the same

A CORA META-MODEL

GSU Working Paper CIS-96-15

TABLE IV DISTRIBUTION RESTRUCTURING TRANSFORMATIONS

TABLE III OBJECT RESTRUCTURING TRANSFORMATIONS

T

Description

Equivalence If objects were intended to be the same, and a choice can be made, then no further modifications are needed—select a perspective. Generalize Determine if the objects fall within a covering class. If so, isA then use the covering class (thereby, downplaying any specialized differences). Generalize Determine if the objects are part of a common object. If so, then partOf use the common object (thereby, downplaying any part specialization). Compromise Determine if a similar object (from within the given domain) will be acceptable.

T

Definition ∃j : ∀x,y ⊥ij,x ≅⊥ij,y, x≠y (⊥ij,*, Ri) ⇒ ⊥ij,x

Onto

Partial ∃j, zj : ⊥ij,* isA* zj (⊥ij,*, Ri) ⇒ zj

Multiple

∃j, zj : ⊥ij,* partOf* zj (⊥ij,*, Ri) ⇒ zj

vj ∈ Θj : ∀x vj ≠⊥ij,x

Specialize partOf

Determine if a part of an object ∃j,x,z : z partOf* ⊥ j,x j j i will be acceptable. (⊥ij,* , Ri) ⇒ zj

New Domain

Run-time Decision

Select Object

Determine if an outside source (e.g., user) can identify an acceptable new object from a new domain. Consider making the decision at run-time. This introduces considerations of: (1) who will decide at run-time, and (2) what part of the conflict will they decide. As default, decide the whole conflict by all agents directly involved. Select an object from the conflicting requirement.

Attempt to satisfy exactly what has been specified, some in the same context.

Dist • Obj(⊥)

All the above transformations composed with transformation of the conflict.

∃j,x,∃vj ∈ Θk: ⊥ij,x ℜ vj

(⊥i, Ri) ⇒ ∀x (if Τ(⊥i, Ri) → ⊥i*,x) (⊥i, Ri) ⇒ (if Τ(⊥i, Ri) → ⊥i*,x) ∧ ∃y : ¬ (if Τ(⊥i, Ri) → ⊥i*,y) (⊥i, Ri) ⇒ (if Τ(⊥i, Ri) → ⊥i*,x) ∧ ∃k,l : (if k → ⊥i*,x) ∧ (if l → ⊥i*,x), k≠l (⊥i, Ri) ⇒ (if Τ(⊥i, Ri) → ⊥i*,x) ∧ ∃x,y,k : (if k → ⊥i*,x) ∧ (if k → ⊥i*,y) ∧ ¬(thwart ⊥i*,x ⊥i*,y) ∧ ¬(thwart ⊥i*,y ⊥i*,x ) x≠y (⊥i, Ri) ⇒ (if Τ(⊥i, Ri) → Τ(⊥i*,x)) ∧ ...

Let a ∈ (MInitiator ∨ PParticipant), pi ∈ partOf(a), vi ∈ userValues,

(⊥ij,* , Ri) ⇒ vj

Onto(⊥respond1,*, Rrespond) ⇒ ∀i (if (a.pi = vi) →

∃j,x,∃Θk, new vj ∈ Θk: ⊥ij,x ℜ vj (⊥ij,* , Ri) ⇒ vj ∃j,x,newΘk, new vj ∈

Definition

will be predicated to indicate under which conditions the requirement applies. Object restructuring methods, such as partOf or isA, can be applied to the non-conflicting elements of the requirement (Ri) to create conditional requirements. Then, a user can supply values indicating the precise mapping of which conditions lead to which requirements. For example,

Related Determine if a similar require- ∃j,x,∃v ∈R : ⊥ j,x ℜ v j k i j Requirement ment object (related via relation j,* , R ) ⇒ (⊥ i i ℜ) will be acceptable. vj

New Object

Attempt to satisfy exactly what has been specified, but in different contexts. Attempt to satisfy some of what has been specified, but in different contexts. Attempt to satisfy exactly what has been specified, but in multiple different contexts.

(⊥ij,*, Ri) ⇒

Determine if a specialization of ∃j,x,z : z isA* ⊥ j,x j j i an object will be acceptable. (⊥ij,* , Ri) ⇒ zj

Determine if a similar domain object (related via relation ℜ) will be acceptable.(A typical ℜ is CousinDomain: generalization followed by specialization.) Determine if an outside source (e.g., user) can identify an acceptable new object.

Description

Overlap

∃j, Θj : ⊥ij,* ∈ Θj

Specialize isA

Related Domain Object

6

Θk: ⊥ij,x

ℜ vj

(⊥ij,*, Ri) ⇒ vj (⊥i, Ri) ⇒ When Occur(⊥i*,*) → Decide(⊥i*,*)

(⊥ij,*, Ri) ⇒ ⊥ij,m

domain, a resolution of the conflict can include the selection of another value from the domain. So, assume that DropParticipant and CancelMeeting are in the domain of meeting schedule recovery (see Fig. 5). Then, Compromise(⊥respond1,*, Rrespond) ⇒ oneOf MScheduleRecovery

2) Distribution Onto. Unlike compromise, distribution methods attempt to satisfy the conflicting positions, but under specific circumstances. In the case of Onto, each of the positions will become part of the requirements, but they

(⊥respond1,* = DropParticipant) else (⊥respond1,* = CancelMeeting)

Notice again, that the domain hierarchy (see Fig. 5) is used to define the conditions of the new requirements. 3) Interaction PostCondition. Finally, an interaction transform considers operational relationships. Here, PostCondition attempts to ensure that Rrespond does not fail in operation, thereby resolving the conflict by making the two recovery positions unnecessary. It does so by restructuring the requirement (Rrespond)—in this case, by weakening the postcondition of Rrespond. PostCond(⊥respond, Rrespond) ⇒ Rrespond :: ∀p ∈ PParticipant : ∃ mi ∈ MInitiator, ∃ mr ∈ MeetingRequest (agent mi Send p mr) → ∃rs ∈ MeetingResponse, (agent p MakeAvailable mi rs)

As shown above, one way to weaken the requirement is to generalize the conflicting operation: ⊥respond1,* = MakeAvailable. where MakeAvailable is a generalization of Send. (For example, the participant, p, makes his response available via a shared calendar.) Presumably, it is easier to simply make a response available, than to send a response (via email). Hence, Rrespond is less likely to fail and therefore, does not require failure recovery requirements. Other post-condition weakenings include: (a) having other agents provide the response for the participant, p; and (b)

A CORA META-MODEL

GSU Working Paper CIS-96-15

increasing the time period for a response. TABLE V INTERACTION RESTRUCTURING TRANSFORMATIONS

T

Description

Definition

Reinforce PreCondition

If a requirement can be prevented (or significantly reduced) from failing, then a conflict over how to recover from that failure may be removed by: attempting to reinforce the establishment of a pre-condition in an existing plan.

x ∈ ∆x, ∆x ➟RFRi ∧ y ∈ ∆y, ∆y ➟RFRi (⊥i, Ri) ⇒ Τj(v.pre-condition) : v ∈ ∆i, ∆i ➟Ri, Τj ∈ Reinforce

Restructure PostCondition

If the conflict concerns how to satisfy a requirement, then a conflict may be removed by: restructuring the requirement’s post condition. Weakening is most applicable: it restricts restructuring to types of generalization (via hierarchies, dropping, or distribution).

x ∈ ∆x, ∆x ➟RFRi ∧ y ∈ ∆y, ∆y ➟RFRi (⊥i, Ri) ⇒ Τj(v.post-condition) : v ∈ ∆i, ∆i ➟Ri

Replan

If the conflict concerns how to satisfy a requirement, then a conflict may be removed by: attempting to find other means of satisfaction via replanning the establishment of the requirement. If the conflict concerns how to satisfy a requirement, then a conflict may be removed by: restructure the requirement.

x ∈ ∆x, ∆x ➟RFRi ∧ y ∈ ∆y, ∆y ➟RFRi (⊥i, Ri) ⇒ Replan(Ri)

Restructure Requirement

x ∈ ∆x, ∆x ➟RFRi ∧ y ∈ ∆y, ∆y ➟RFRi (⊥i, Ri) ⇒ Τj(Ri)

As indicated above, the object restructuring transformations of table III make use of object hierarchies as illustrated in figure 5. These hierarchies may be derived from the requirements or be explicitly defined in a domain model. They describe basic taxonomic information of objects, operations, and relations of a domain[3]. Finally, as defined in tables IV and V, the restructuring transformations are composable. For example, the above PostCondition transformation applied Generalize.isA to the post-condition of Rrespond. Similarly, the distribution Onto above applied Specialize.partOf to the create the requirement condition. In fact, focusing the application of such transformations toward relevant structures is a difficult task. One can define a utility function, composed of stakeholder preferences, to guide search; however, the definition of utility functions is a complex task itself. It would be preferable to have more general domain dependent, or even domain independent restructuring heuristics to guide transformation application toward reasonable resolutions across all domains. This is the approach we take below. Currently, such a meta-level strategy is only a fall back when more specific knowledge is not available. E. The Restructuring Process Given a conflict, one can engage in various strategies for (a)

(b)

isA

Agent

partOf

MInitiator PParticipant MScheduler

Name Title Location

MScheduleRecovery isA Substitute Drop Reschedule Cancel

(c)

MakeAvailable isA Send Post

Fig 5. A portion of the meeting scheduler domain hierarchies.

7

removing the conflict. For example, one could consider all possible representations related to the original positions and select a single position which is “closest” to the original positions.5 In fact, given a conflict within an object-oriented language, the object and distribution transformations are complete in that they can derive all valid representations.6 Unfortunately, where domain or requirements models have more than a few objects, this is too large of a search space. Instead, we prefer to engage a domain-independent meta-strategy which generally focuses on the better resolutions. The general negotiation strategy for resolving such conflicts is as follows7. 1) Define criteria by which one can identify the maximal satisfaction of each stakeholder position. 2) Select one of the conflicting positions and for each criteria modify it (while ensuring feasibility) such that it equally maximizes all stakeholder positions, i.e., so it is a pareto optimal solution. From the above general negotiation strategy, we have derived our position-oriented resolution strategy: 1) Assume each stakeholder position, as defined in the conflicting requirement, embodies the criteria and “best” values for that stakeholder. (That is, a stakeholder position implicitly reflects any high-order criteria which may be obtained [43]; this is supported by negotiation behavior research which suggests that conflicts are often best resolved by addressing them directly[38].) 2) Apply restructuring transformations, as specified in table IV, to each requirement element conflict. 3) Select the resolution which is “closest” to the original positions (thereby, maximizing the implicit criteria). To make the concept of “closest” operational, we use what we call the relational distance, which is the minimum number of relations which link two concepts.8 Relational distance of n :: C ℜn O : A ℜ Oi , Oi ℜ Oi+1, ...Oi+1 ℜ O, C is related to O through a minimum of n relations.

For example, the generalization: MInitiator ℜn ScheduleAgent, where {MInitiator, PParticipant} isA MSchedulerAgent has a relational distance, n, of one.

While restructuring transformations are composable (as illustrated in table IV), all compositions are not equally likely to result in good resolution. For example, in general, it makes more sense to generalizing conflicting objects and then find closely related domain objects, as opposed to first finding related domain objects related and then attempting to generalize them. That is: (a) RelatedDomainObject(Generalize(x,y)) preferred over (b) Generalize(RelatedDomainObject(x), RelatedDomainObject(y))) 5 If “closeness” is defined as a utility function, then the representation which maximizes both positions by being “closest” to both is the Nash solution[58]. 6 Through the Generalize and Specialize operators, a whole object hierarchy (and their component parts) can be explored. 7 The simplex method is a linear programming implementation of this strategy where criteria, constraints, and solutions are linear functions[58]. 8 Relation distance can take into account the semantic meaning of relationships (e.g., via weights); however, we have found the simple definition sufficient for our needs, particularly because our hierarchies have semantic meaning based on taxonomic relationships[3].

A CORA META-MODEL

GSU Working Paper CIS-96-15

TABLE VI THE DEFAULT STRATEGY. Apply T Order 1 Equivalence 2 Reinforce PreCondition

Rationale for ordering

4

Generalize isA

5

Generalize partOf

First, do not alter the original requirement objects, but attempt to recharacterize the conflict or provide for their mutual satisfaction. Notice that Distributeonto is restricted to only restructuring the context, Ri. Common patterns for this restricted distribution include combinations of:

6

Replan

(a) (if (partOf Ri = vi) → ⊥i*,j)

3

Onto

(b) (if (partOf ⊥i = vi) → ⊥i*,j) (c) (if (isA Ri = vi) →⊥i*,j) (d) (if (isA ⊥i = vi) → ⊥i*,j) where vi are (user supplied ) values used to determine which specific conditions lead to which specific assertion ⊥i*,j. Second, attempt to find a substitute object which will satisfy all associated needs.

7

Compromise

8

Related Requirement

9

Related Domain Object

10

New Object

11

New Domain

12

Run-time Decision

13

Restructure PostCondition Fourth, break down the conflicting objects and attempt to satisfy most of their constituent parts. In Onto • Spec.partOf each case, some of the initial requirement will not Onto • Spec.isA be satisfied. Select Object

14 15 16

Third, consider making the decision at run-time.

This also follows from the research which suggests that conflicts are best resolved directly[38], as well as machine learning’s concept of most specific common ancestor[32]. Minimizing relational distance justifies the choice of (a) in the decision between compositions (a) and (b) above, since in most cases it will result resolution closer to the conflict. The position-oriented resolution strategy defined in table VI is not claimed to be the best strategy. Rather, it illustrates how a strategy can be built up from the more basic transformations. (Domain specific strategies can be derived by specializing the transformations and tailoring the ordering.) Notice that this default strategy does not include every transformation; for example partial distribution is not included; however, partial distributions can be derived by applying the Onto distribution followed by Select Object. In creating the strategy, we sought to be complete in exploring the representation, while still keeping the transformation set comprehensible. In the case of this default strategy, we derived it from several case-studies, and as shown in table VI, we have rationalized the ordering. The default position-oriented resolution strategy is divided into four phases. 1) Satisfy the original positions under specific conditions. The first set of transformations determine if the original conflicting positions: (a) are the same, (b) have a common generalization, or (c) can be satisfied under specific conditions. 2) Find substitute satisfaction for the original positions. The second set of transformations determine if there is a closely related object which satisfies all stakeholders. 3) Satisfying the original positions using run-time reasoning. Next, it is determined if analysis at run-time might be the

8

TABLE VII AN EXAMPLE OF RESTRUCTURING THE “AWARE” CONFLICT ⊥privacy*,x = ∃ a1 ∈ MInitiator (aware a1 (agent p holds c)) ∧ ¬ ∃ a2 ∈ PParticipant (aware a2 (agent p holds c)) ⊥privacy*,y = ∃ a1 ∈ PParticipant (aware a1 (agent p holds c)) ∧ ¬ ∃ a2 ∈ MInitiator (aware a2 (agent p holds c))

T

Instantiation

Equivalence No. not (MInitiator ≅ PParticipant) Reinforce N/A PreCondition Onto Let a ∈ (MInitiator ∨ PParticipant), pi ∈ partOf(a), ci ∈ partOf(c) vi , wj∈ userValues, ∀i,j if (a.pi = vi) ∧ (c.cj = wj) → ⊥privacy*,x else ⊥privacy*,y Generalize {MInitiator, PParticipant} isA MSchedulerAgent, Agent isA (a1∈ MSchedulerAgent, a2∈ MSchedulerAgent) Generalize {MInitiator, PParticipant} partOf Department, Organization partOf (a1 in Department, a2 in Department) Replan N/A Compromise MSchedulerAgent = {MInitiator, PParticipant, Scheduler,...} oneOf MSchedulerAgent Related (MInitiator ∈ PParticipant) ∨ (MInitiator = Secretary) via RMInitiator, but Requirement (MInitiator ∈ PParticipant) is transform Equivalence (found above), so (a1= Secretary, a2= Secretary) Related {MInitiator, PParticipant} isA MSchedulerAgent, Agent Domain {Arbitrator, Mediator, Judge...} isA DecisionAgent Object DecisionAgent isA Agent Let a1,a2 ∈ DecisionAgent New Object Fail New Domain Fail Run-time When occur((agent p holds c)) → Decision Decide( a : (aware a (agent p holds c))) Restructure N/A PostCondition Onto • Let a ∈ (MInitiator ∨ PParticipant), pi ∈ partOf(a), ci ∈ partOf(c) Spec.partOf vi , wj∈ userValues, partOf (agent p holds c) = {(agent p), (holds c)} ∀i,j if (a.pi = vi) ∧ (c.cj = wj) → ∃ a1 ∈ MInitiator a3 ∈ PParticipant (aware a1 (agent p)) ∧ (aware a3 (holds c)) ∧ ¬ ∃ a2 ∈ PParticipant, a4 ∈ MInitiator (aware a2 (agent p)) ∧ (aware a4 (holds c)) else ∃ a1 ∈ PParticipant a3 ∈ MInitiator (aware a1 (agent p)) ∧ (aware a3 (holds c)) ∧ ¬ ∃ a2 ∈ MInitiator, a4 ∈ PParticipant (aware a2 (agent p)) ∧ (aware a4 (holds c)) Onto • No specializations of x, y, or A Spec.isA Select Object oneOf {⊥privacy*,x, ⊥privacy*,y}

most appropriate way to select which position (or its transformation) should be satisfied. 4) Satisfy elements of the original positions. Finally, elements of the original positions are dropped and only partial satisfaction is attempted. In our implementation of the default strategy, we have applied all transformations of the strategy and then selected the best resolution. Of course, other implementations could include stopping at the first acceptable resolution. To illustrate the application the default strategy, reconsider the introductory conflict over the privacy requirement Rprivacy (illustrated in Fig. 3). Table VII shows the resolutions generated

CORA TOOL SUPPORT

GSU Working Paper CIS-96-15

by the default strategy.9 Two resolution classes are particularly noteworthy. 1) In considering the aware conflict, the analyst identifies a requirement for the Related Requirement transform which indicates that the meeting initiator may be a participant or secretary (RMInitiator), so the secretary position is added. However, since position ⊥privacy*,x has already been established as an initial position, it is not duplicated. 2) The table only shows the result of one partOf transformation for the composition of the Onto distribution with specialization (Onto • Specization.partOf); specifically, it shows distributions of two parts of the requirement relation (agent p holds c). Other specializations include parts of the constraints (i.e., agents can only be aware of some constraint types). Of course, one can apply further transformations to these results; for example dropping the (aware a1 (agent p)) relation, in which case agents only know of the constraints and not who posted them. IV. CORA TOOL SUPPORT An effort to implement tool support for the CORA is underway. The current prototype, called R EQUIREMENTS DEALMAKER, provides some support for concurrent multi-user requirements analysis using the CORA meta-model. The implementation architecture is illustrated in Fig. 6; it consists of three basic components: • Database The database defines the meta-model and stores requirements and domain models. This data is stored in ConceptBase, an object-oriented deductive database which provides for abstraction and meta-modeling[18]. • Agent Experts The agent experts provide specific analyses which are not easily provided for in the database. By providing a multiagent analysis component, REQUIREMENTS DEALMAKER provides for concurrent analysis including: constraintbased[50], rule-based[14], and plan-based[3] reasoning. Currently, automated experts exists to assist: (a) the application of the meta-model transformations as defined in a rulebased system, (b) conflict analysis as determined through plan-based reasoning[3]. • Networked Interface A World Wide Web (WWW) interface is provided. Users running a browser on the Internet can connect to the REQUIREMENTS DEALMAKER server which translates information to and from the database or experts as needed. Analysts interact with the REQUIREMENTS DEALMAKER prototype as follows: 1) The analyst selects an issue. 2) The analyst runs the conflict analyzer which defines the conflict types. 3) The analyst selects a conflict, and then selects and runs transformations which define resolutions. 4) The analyst selects resolutions for an issue. Future work will entail greater integration of the tools under an 9 Fail indicates that a user could not define a new object or domain; N/A indicates that a transformation was not applicable, as its precondition were not met.

9

Perl/HTML parser/ unparser Interface Server WWW Browser internet Conflict Analysis Restructuring Methods

Meta-Model Requirements ConceptBase Database Server

parser/ unparser

ORBS rule system Screamer constraint system OPIE planning system Expert Agent

Fig 6. The REQUIREMENTS DEALMAKER implementation architecture.

interactive resolution search procedure. REQUIREMENTS DEALMAKER ’s interactive decision making procedure is based on Zeleny’s Interact Decision EvoLution Aid (IDEA)[58]. Using IDEA, the attributes of the current solution defines a search space in which the best values of all attributes defines the ideal solution. The analyst then changes those attributes of the current solution which are perceived as important (via transformations) so as to improve the solution. Using the procedure, the analyst does not have to explicitly specify trade-offs between stakeholder positions. Instead, the analyst simply attends to the solutions which are deemed desirable. As search continues, the analyst will focuses on a succeeedingly narrower solution set. As such, solution optimality is the result of a specific search process, which when completed, can be interpreted as a settlement of trade-offs among stakeholder positions[13][20][43][58]. The construction of REQUIREMENTS DEALMAKER (and a similar application APPLET DEALMAKER[47]) was on-going at the time of our meeting scheduler analyses. Thus, for the most part, we only made use of it in the meeting scheduler study as a proof-of-concept; that is, to verify that the restructuring transformations and conflict analysis we employed can be implemented. To support our analyses of the meeting scheduler, we placed the requirements, domain model, and meta-models in the FrameMaker word processor. For each conflict, we copied and edited a transformation template to generate resolutions. As we describe below, the meta-model and transformations were still useful even when conflict determination and transformation were manual (cf., [5]). V. A MEETING SCHEDULER CASE STUDY In addition to our efforts to determine the extent to which we can provide automated support for CORA, we also sought to understand the utility of the transformations under our domainindependent strategy. In general, we sought to assess: • Coverage Can the transformations generate useful resolutions? • Orthogonality Are the transformations relatively independent, or are some redundant?

A MEETING SCHEDULER CASE STUDY

GSU Working Paper CIS-96-15

In keeping with the case-study, we limited our analysis to the application of the transformations under the control of the default strategy (table VI). To do the initial assessment, we applied the CORA to requirements of a distributed meeting scheduler in the following manner: 1) The requirements were placed in a word processor and the individual requirements were numbered[55].10 2) A table of the transformations was created as a template to be applied to each issue. 3) Multiple stakeholder issues were generated from the requirements by applying a set of stakeholder analysis questions. 4) Stakeholder positions were put forward in response to each question. 5) Conflict analysis was applied to the positions for each issue. 6) Resolutions were generated by applying the transformation template to each conflict. 7) Acceptable resolutions were formulated as change requests and the requirements were updated. Each author independently used templates in FrameMaker to apply CORA to the meeting scheduler requirements. The final analysis document was hypertext where the links between requirements, issues, conflicts, and resolutions conformed to CORA meta-model. As the meeting scheduler requirements are defined from a single perspective (i.e., without the biases or attributions of multiple stakeholders), we had to generate stakeholder issues from the requirements[55]. To do so, we applied each of the following questions to each requirement, as applicable. • What is the responsibility of an agent? • Who is responsible for doing an operation? • Who or what determines the status of an agent or resource? • Can agents or resources be substituted? • What should be done if a requirement fails? • Does the use of a resource differ with the class of agent? • Does the function or performance of an operation differ according to the class of agent or resource involved? These questions are typical of the sort found in the stakeholder analysis literature[6][33][49] .

10

tions using the default strategy of table VI. For each of the 16 transforms listed in the first column, the following columns indicate how many times the transformation was not applicable, failed, and succeeded. The second to last column indicates how many of the successful transformations created a resolution which was not previously created. Finally, the last column indicates how many change requests were created from a transformation. TABLE VIII SUMMARY OF THE CASE STUDY TRANSFORMATIONS Method

N/A

Fail

Success

Unique

Change

0

0

15

1

0

10

0

5

3

3

Onto

0

0

15

4

1

Generalize isA

0

1

14

4

0

Generalize partOf

0

1

14

3

3

11

0

4

1

1

Equivalence Reinforce PreCondition

Replan Compromise

0

1

14

3

0

Related Requirement

0

14

1

1

0

Related Domain Object

0

3

12

2

1

New Object

0

10

5

2

1

New Domain

0

12

4

3

0

Run-time Decision

0

0

15

1

0

10

0

5

2

2

0 0 0

6 12 0

9 3 15

8 2 1

7 3 1

31

60

150

41

23

Restructure PostCondition Onto • Spec.partOf Onto • Spec.isA Select Object

Total

From table VIII, we make the following observations: Three transforms (Equivalence, Run-time Decision, Select Object) are routine in that they tend to generate the same resolutions across all conflicts (e.g., success >> unique =1); that is, after one resolution was derived, the rest were the same. • Three transforms (Reinforce PreCondition, Onto • Spec.partOf, Onto • Spec.isA) were creative in that most their applications derived a unique resolution (success ≅ unique). • Three transforms (Reinforce PreCondition, Replan, Restructure PostCondition) have specialized application (N/A > 0); they only apply to conflicts over means of requirement failure. Of the transformations that did not result in a change to the •

A. Observations Fig. 7 shows the results of applying CORA to the meeting scheduler. The graph can be interpreted as follows: ovals indicate the number of unique instances of a type, arcs indicate the number of instances considered at the source to generate instances at the sink. The analysis generated 22 issues of from 17 requirements, which led to the consideration of 150 classes of resolutions. (A resolution class is the result of applying a transformation to a conflict; a class, like those of Onto, may contain multiple resolutions.) Finally, 23 resolutions were selected leading to 20 unique change requests. Table VIII summarizes the applications of the transforma10 Our number of requirements, 53, is larger than the number (39) indicated in [37] because we numbered most sentences, rather than paragraphs.

Requirements 53

Change Requests 20 23

17 Issues 22 7

Assumptions 7

15 Positions 37

Resolutions Classes 150

37

Fig 7. Results of applying CORA to the meeting scheduler.

A MEETING SCHEDULER CASE STUDY

GSU Working Paper CIS-96-15

requirements (Equivalence, Generalize isA, Compromise, Related Requirement, New Domain, Run-time Decision), we note that they generally succeeded, but their results were not unique. Particularly interesting is the failure of compromise—the classic negotiation technique—to be part of the final requirements document. It has been suggested that compromise does not generally provide good solutions for all participants[38]. Instead, participants should engage in “lateral thinking” to pursue some ideal alternative by restructuring the problem[58]. In fact, most of the transformations can be interpreted as problem restructuring. On the other hand, transformations, such as Equivalence, Generalize isA, simply attempt to determine if the conflicting components are really equivalent (at some level). So, while they failed to produce requirements changes in this case-study, we believe they must always be considered. Finally, some transformations require substantial work to apply. This shows in the numbers of failures for New Object, New Domain, and Related Requirement where the user must define new entities or determine a requirement relationship which can be used to resolve the current conflict. B. Lessons from the Case-Study The lessons learned from the case-study mainly arise from the use of the transformations. We also found that the metamodel adequately captured the key relationships in our stakeholder analysis. After its introduction, the meta-model has served as more of a backdrop than a focal point in this article. Similarly, it served as a backdrop within the case-study. The meta-model provides a conceptualization by which to understand important stakeholder relationships, such as issue, position, conflict, transformation and resolution. Additionally, the meta-model has provided the requisite database definitions required for automated support. The resolution transformations and strategy were the keys to routinizing and simplifying stakeholder conflict resolution. They provided support in the following ways: • Transformations routinize conflict resolution Once one is familiar with the transformations, application becomes routine. Moreover, in the case of the meeting scheduler, many of the conflicts involved the same elements so resolution generation became succeeding more familiar (and easier) as the case progressed. • Transformations can provide creative resolutions Contrary to our expectations, the transformations routinely produced interesting resolutions which were not readily apparent. For example, consider resolution R79 of Fig. 3 in which the meeting constraints are made anonymous by separating them from their participants. While obvious in hindsight, we had not previously generated this resolution ourselves, nor had it come up in previous analyses of the case[37][54].11 However, the transformations only provide heuristically “interesting” modifications of existing representations—it is up to the analyst to interpret their full meaning (cf. [29]). • Transformations can produce a large number of resolutions The transformations under the default strategy created, on average, 13 resolution classes per conflict. In the case-study, 11 The previous studies generated issues through scenario[37] and goal-directed elaboration[54]. Unfortunately, our comparison is only based on their published analyses, which are only part of their full analyses.

11

this has been a rich, but manageable, source of resolutions. Resolutions of different conflicts often overlap Many of the conflict involve the same objects, partly because of the common set of questions we used to derive the stakeholder perspectives. For example, the question, “Who is responsible for doing an operation?” often uncovered a conflict in which the positions entailed the various agents of the meeting scheduler (e.g., participant, meeting initiator, scheduler). Hence, this same agent responsibility conflict appeared for many different operations. Consequently, the resolution of many of these conflicts were similar, if not identical. This, in turn, made resolution generation and selection more routine and manageable as the case progressed. As an overall reality check, we compared our results with those created by an unassisted analyst who was given the requirements document containing the conflicting stakeholder positions (after step 4 on page 10). Perhaps surprisingly, the analyst did not create any resolutions not previously generated by the default strategy. Moreover, in all cases the analyst generated fewer resolutions and tended to select simple solutions (compromise or selection). In our review of the analyst’s work, we found that: • No new solutions were created. • The resolutions derived duplicated those created by two of our methods: Onto (8 resolutions) and Compromise (4 resolutions). • Five issues were resolved by simply dropping all positions except one. Hence, we are convinced that our approach not only creates more resolutions, but also more complex and creative resolutions. While such results are clearly anecdotal in nature, they do support the theory that many people are have poor conflict resolution skills[38][39]. However, a resolution framework, such as provided by CORA’s default strategy, can improve resolution. •

C. Future Research While our initial steps of automating transformation application have been helpful, there are still open problems with this transformation-oriented conflict resolution procedure. • Automated assistance for the resolution strategy Not only is the current default strategy domain-independent, it is also independent of the user or analysts preferences. Prior work demonstrates how a interactive decision procedure can incorporate group preferences into resolution search process[43]. We intend to incorporate such a procedure into REQUIREMENTS DEALMAKER to further focus search on preferred resolutions while providing more feedback on how well a resolution satisfies an individual’s preferences. • Linking resolutions As we noted above, multiple resolutions within a single case tend to involve some of the same elements. In such cases, each individual resolution may be good, but the overall solution may be poor. For example, if all responsibility conflicts are resolved by handing them to one agent, then that agent may fail to achieve its goals as it becomes overwhelmed with work (cf., [15]). Hence, it would be preferable to provide analysis of the interactions between such resolutions and show how the resolutions satisfy some over-

CONCLUSIONS

GSU Working Paper CIS-96-15

all criteria. Again, we anticipate using an interactive decision procedure to provide such feedback[43]. Overall, the transformations and strategies can be further refined and formalized so as to allow for specific guarantees on properties (e.g., goal achievement, safety, liveness) to hold after stakeholder resolution (c.f., [9]). VI. CONCLUSIONS Conflict oriented requirements analysis (CORA) is a requirements analysis technique. The individual CORA methods of conflict analysis and transformation-oriented resolution are analogous to a scenario analysis method. In fact, the CORA requirements life-cycle is derived from the Inquiry Cycle which uses scenario analysis rather than conflict analysis as its driving force[37]. CORA requires a focus on stakeholder issues, rather than general requirements problems (e.g., safety, liveness, etc.). With such a focus, we believe CORA can uncover and resolve some of the most difficult systems problems—those conflicts that occur among system stakeholders. In the meeting scheduler case, this effort amounted to roughly one person-month. We estimate a more complete analysis would take roughly three persons months. This level of effort is on the low end of that estimated for the same meeting scheduler case using a scenariobased Inquiry Cycle, the semidetached development of Basic Cocomo, and Joint Application Design[37]. Hence, as suggested for the scenario-based Inquiry Cycle in [37], the level of effort required for CORA is similar to other methods, it just focuses the effort on stakeholder analysis. Support for CORA is derived from the meta-model and its associated restructuring transformations. By explicitly defining basic domain-independent resolution transformations, we have been able to explore various transformation combinations in our effort to derive a satisfactory domain-independent resolution strategy. Under the control of a CORA’s default resolution strategy, the transformations have been shown to conservatively restructure the requirements so as to satisfactorily remove stakeholder requirements conflicts in the case of the meeting scheduler. Other approaches to requirements conflict resolution include Win-Win[5] which primarily is a resolution tractability tool without automated resolution support, CDE[25] which uses a hierarchies of cases (or conflict classifications) to automatically provide resolution alternatives, and Finkelstein’s early work on recognizing and removing conflicts by communicating logical assertions[16]. (More recently, this work has emphasized multiple ontologies and representations for requirements engineering[36].) Easterbrooke also focuses on requirements conflicts, but mainly on the terminological conflict identification and resolution[11][12]. Researchers outside of the requirements engineering community are exploring ways of automating conflict resolution. In the pioneering work of Sycara’s PURSUADER system, resolutions were generated from previously stored negotiation cases. (Klein has applied this general approach to requirements conflicts[25].) Distributed Artificial Intelligence (DAI) researchers are designing distributed agents which must cooperate to resolve conflicts, generally through compromise or goal relaxation[9][15][48]. (For a more complete review of negotiation support, see [46].) The support for CORA in REQUIREMENTS DEALMAKER dif-

12

fers from other approaches in its explicit definition of domainindependent: (1) meta-model, and (2) resolution search strategy which combines of basic resolution transformations. From our experiences of applying CORA, we find it provides substantial support. However, there are still open issues concerning a more complete resolution strategy, as well as more general issue concerning domain-dependent specialization of the approach. With these caveats, we believe CORA can be a powerful technique for requirements stakeholder analysis. REFERENCES [1] [2]

[3]

[4] [5] [6] [7]

[8] [9]

[10]

[11] [12] [13] [14] [15]

[16] [17] [18]

AAAI, Workshop on Models of Conflict Management in Cooperative Problem Solving, AAAI, Seattle, Wa, August 4, 1994. Anderson, J., Fickas, S., Viewing Specification Design as a Planning Problem: A Proposed Perspective Shift, In 5th International Workshop on Software Specification and Design, Pitts burgh, 1989 Also to appear in Artificial Intelligence and Software Engineering, D. Partridge (ed), Ablex, 1991 Anderson, J. S. and Farley, A. M. Plan Abstraction Based on Operator Generalization. AAAI, Proceedings of the 1988 AAAI National Conference on Artificial Intelligence, Morgan Kaufmann, St.Paul, Minnesota, 1988, 100-104. Atzeni, P., and R. Torlone. “A Metamodel Approach For The Management of Multiple Models and The Translation of Schemes,” Information Systems, Vol. 18, No. 6, 349-362, 1993. Boehm, B., In, H., Identifying Quality-Requirement Conflicts, IEEE, Software, March, 1996, 25-36. Checkland, P., Systems Thinking, Systems Practice, John Wiley & Sons, 1981. Chung, L., Nixon, B., Yu, E., Using Non-Functional Requirements to Systematically Support Change, IEEE, Second International Symposium on Requirements Engineering, March 2729, 1995, pp. 132-139.. Dardenne, A., van Lamsweerde, A., Fickas, S., Goal-directed requirements acquisition, Science of program Darimont, R, van Lamsweerde, A., Formal Refinement Patterns for Goal-Driven Requirements Elaboration, ACM SIGSOFT, Fourth Symposium on the Foundations of Software Engineering, San Francisco, CA, October 16-18, 1996. Downing, K., Fickas, S., A Qualitative Modeling Tool for Specification Criticism, Conceptual Modelling, Databases, and CASE: An Integrated View of Information Systems Development, Peri Loucopoulos (ed), Ablex, 1991 Easterbrooke S., Domain modeling with hierchies of alternative viewpoints, IEEE, International Symposium on Requirement Engineering, January 4-6, 1993, 65-72. Easterbrooke S., Co-ordinating distributed ViewPoints: the anatomy of a consistency check, Concurrent Engineering: Research & Applications, CERA Institute, (2), 1994. Festinger, L., Conflict, Decision, and Dissonance, Tavistock Publications, Ltd., London(1964). Fickas S., Supporting the programmer of a rule based language, Expert Systems, 4(2), May 1987. Fickas, S., Helm, R., Knowlege representation and reasoning in the design of composite systems, IEEE, Transactions on Software Engineering, Special issue on knowledge representation and reasoning, June, 1992. Finkelstein, A., Fuks, H., Multi-party specification, 5th International workshop on software specification and design, (1989) 185-195. Gasser, L., Huhns, M.N., (Eds), Distributed Artificial Intelligence, Morgan Kaufmann Publishers Inc, San Mateo, 1989. Greenspan, G. Mylopoulos, J., Borgida A., : On formal requirements modeling languages: RML revisited. In Proc. 16th International Conference on Software Engineering, 1994, pp. 135148

CONCLUSIONS

[19] [20] [21]

[22] [23] [24]

[25] [26]

[27] [28]

[29]

[30] [31] [32] [33] [34] [35] [36]

[37] [38] [39] [40]

GSU Working Paper CIS-96-15

Heym, M., and H. Osterle. “Computer-aided Methodology Engineering,” Information and Software Technology, Vo. 35, no. 6/7, 345-353, June/July 1993. Janis, I., Mann, L., Decision making : a psychological analysis of conflict, choice, and commitment, The Free Press, New York(1979). Jarke, M., Gallersdorfer, R., Jeusfeld, M.A., Staudt, M., Eherer, S., ConceptBase - a Deductive Object Manager for Meta Data Management, Journal of Intelligent Information Systems, 4 (2), March 1995, 167-192. Jelassi, M.T., Foroughi, A., Negotiation Support Systems: An Overview of Design Issues and Existing Software, North-Holland, Decision Support Systems, (5), 1989, 167-181. Keeney, R., Raiffa, H., Decisions with multiple objectives, John Wiley and Sons, New York(1976). Kersten, G.E., Szpakowicz, S., Negotiation in Distributed Artificial Intelligence: Drawing from Human Experience, IEEE, Proceedings of the 27th Annual Hawaii International Conference on Systems Sciences, 1994, 258-270. Klein, M., Supporting conflict resolution in cooperative design systems, IEEE, Transactions on Systems, Man, and Cybernetics, 21 (6), November 1991, 1379-1390. Kumar, K., and R. J. Welke. “Methodology Engineering: A Proposal for Situation-Specific Methodology Construction,” in Challenges and Strategies for Research in systems Development (eds. W. W. Cotterman and J. A. Senn), John Wiley and Sons Ltd., 257-269, 1992 Kusiak, A., (ed), Concurrent engineering: automation, tools, and techniques, John Wiley & Sons, 1993. Lander, S.E., Lesser, V.R., Understanding the Role of Negotiation in Distributed Search Among Heterogeneous Agents, IJCAI, Proceedings of the Thirteenth International Joint Conference on Artificial Intelligence, Chambéry, France, August, 1993, 438-444. Lenat, D.B., Brown, J.S., Why AM and Eurisko Appear to Work, Proceedings of the Third National Conference on Artificial Intelligence, August 22-26, 1983, Washington, D.C., AAAI, pp. 236-240. Markus, L., Keil, M., If We Build It, They Will Come: Designing Information Systems That People Want to Use, Sloan Management Review, Summer, 1994, pp. 11-25. Matwin, S., Szpakowicz, S., Koperczak, Z., Kersten, G.E., Michalowski, W., Negoplan: An Expert System Shell for Negotiation Support, IEEE, Expert, 4(4) 50-62. Michalski, R. S., Carbonell, J. G. Mitchell, T. M., eds., Machine Learning, An Artificial Intelligence Approach, Morgan Kaufmann, Los Altos, CA, 1983. Mumford, E., Wier, M., Computer systems in work design—the ETHICS method, London, Associated Business Press, 1979. Naiman, C. F., and A. M. Ouksel. “A Classification of Semantic Conflicts in Heterogeneous Database Systems,” Journal of Organizational Computing, 5(2), 167-193, 1995 Nissen, H., Jeusfeld, A., Jarke, M., Zemanek, G., Huber, H., Managing Multiple Requirements Perspectives with MetaModels, IEEE, Software, March 1996, pp. 37-48. Nuseibeh, B., Kramer, J., Finkelstein, A., A Framework for Expressing the Relationship between Multiple Views in Requirements Specification, IEEE, Transations on Software Engineering, October, 1994, 760-773. Potts, C., Takahashi, K., Anton, A., Inquiry-Based Requirements, Analysis, IEEE, Software, pp. 21-32. Pruitt, D., Negotiation Behavior, Academic Press Inc.(1981). Raiffa, H., The art and science of negotiation, Harvard University Press(1982). Ramesh, B., Dhar, V., Supporting systems development by capturing deliberations during requirements engineerng, IEEE, Transactions on Software Engineering, 1992, pp. 498-510.

[41] [42] [43]

[44]

[45] [46] [47] [48] [49]

[50] [51]

[52] [53] [54] [55]

[56] [57] [58] [59]

13

Rasmusen, E., A Model of Negotiation, Not Bargaining, Indiana University, Indiana University Working Paper in Economics No. 94-007, May 9, 1995. Robinson, W.N., Integrating multiple specifications using domain goals, 5th International workshop on software specification and design, (1989) 219-226 Robinson, W.N., Interactive Decision Support for Requirements Negotiation, Concurrent Engineering: Research & Applications, Special Issue on Conflict Management in Concurrent Engineering, The Institute of Concurrent Engineering, 1994 (2) 237-252. Robinson, W.N., Negotiation behavior during requirement specification, Proceedings of the 12th International Conference on Software Engineering, IEEE Computer Society Press, Nice, France (March 26-30 1990) 268-276 Robinson, W.N., Fickas, S. Supporting Multi-Perspective Requirements Engineering, First International Conference on Requirements Engineering, IEEE, (April 18-22 1994) 206-215. Robinson, W.N., Volkov, S., Supporting the Negotiation LifeCycle, GSU CIS Working Paper 96-05, Georgia State University, Atlanta, GA, May, 1996. Robinson, W.N., , Electronic Brokering for Automated Contracting of Software Applets, Georgia State University, Working Paper CIS-96-06, May 1996. Rosenschein, J., Zlotkin, G., Rules of Encounter, The MIT Press, 1994. Shakun, M.F., Airline Buyout: Evolutionary Systems Design and Problem Restructuring in Group Decision and Negotiation, The Institute of Management Sciences, Management Science, 37(10), (October 1991), 1291-1303. Schuler, D. Namioka, A., Participatory design, Lawrence Erlbaum Assoc., Hillsdale, New Jersey, 1993. Siskind, J.M., McAllester, D., Nondeterministic Lisp as a Substrait for Constraint Logic Programming, AAAI, Proceedings of the 1988 AAAI National Conference on Artificial Intelligence, 1993, 133-138. Spacappietra, S., and C. Parent. “View Integration: A Step Forward in Solving Structural Conflicts,” IEEE Transactions on Knowledge and Data Engineering, 6(2), 258-274, April 1994 Sycara, K., Problem Restructuring in Negotiation, The Institute of Management Sciences, Management Science, 37(10), (October 1991), 1248-1267. Velthuijsen, H., Distributed artificial intelligence for runtime feature-interaction resolution, IEEE, Computer, Vol. 26, No. 8, August 1993, 48-55. van Lamsweerde, A., Darimont, R., Massonet, P., GoalDirected Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt, IEEE, Second International Symposium on Requirements Engineering, March 27-29, 1995, pp. 194-203. van Lamsweerde, Darimont, R., Massonet, P., The Meeting Scheduler System—Preliminary Definition, Internal Report, University of Louvain, 1993. Werkman, K., Knowledge-based model of using shareable perspectives, Proceedings tenth international conference on distributed artificial intelligence, (October 1990) 1-23. Yakemovic, K., Conklin, J., Experience with the gIBIS model in a corporate setting, Proceedings of CSCW 90, Los Angeles, 1990. Zeleny, M., Multiple criteria decision making, McGrawHill(1982).