3 - 2003 - p132-n_robinson.pdf

8/11/2019 3 - 2003 - p132-n_robinson.pdf

1/59

Requirements Interaction Management

WILLIAM N. ROBINSON, SUZANNE D. PAWLOWSKI, AND VECHESLAV VOLKOV

Georgia State University

Requirements interaction management (RIM) is the set of activities directed toward thediscovery, management, and disposition of critical relationships among sets ofrequirements, which has become a critical area of requirements engineering. Thissurvey looks at the evolution of supporting concepts and their related literature,presents an issues-based framework for reviewing processes and products, and appliesthe framework in a review of RIM state-of-the-art. Finally, it presents seven researchprojects that exemplify this emerging discipline.

Categories and Subject Descriptors: C.0 [General]:System architectures; systemspecification methodology; C.4 [Performance of Systems]:Modeling techniques;

performance attributes; D.2.1 [Software Engineering]:Requirements/Specifications;D.2.2 [Software Engineering]: Design Tools and TechniquesComputer-aidedsoftware engineering (CASE); D.2.4 [Software Engineering]: Software ProgramVerification; D.2.9 [Software Engineering]: ManagementLife cycle; software qualityassurance (SQA); D.2.10 [Software Engineering]: Design; H.1.1 [Models andPrinciples]: Systems and Information Theory; I.2.11 [Artificial Intelligence]:Distributed Artificial Intelligence

General Terms: Design, Management, Performance, Reliability, Verification

Additional Key Words and Phrases: Requirements engineering, system specification,system architecture, analysis and design, dependency analysis, interaction analysis,composite system, WinWin, Telos, distributed intentionality, viewpoints, KAOS,deficiency driven design, KATE, Oz, software cost reduction (SCR).

1. INTRODUCTION

One of the main objectives of requirementsengineering (RE) is to improve systemsmodeling and analysis capabilities so thatorganizations can better understand crit-ical system aspects before they actuallybuild the system. As Brooks [1987] noted,requirements definition is the most diffi-cult development stage:

The hardest single part of building a soft-ware system is deciding precisely what to build.No other part of the conceptual work is as

Authors address: Department of Computer Information Systems, Georgia State University, Atlanta, GA30302; email: {wrobinson,spawlowski}@gsu.edu;[email protected] to make digital/hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute to lists requiresprior specific permission and/or a fee.c2003 ACM 0360-0300/03/0600-0132 $5.00

difficult as establishing the detailed technicalrequirements. . . . No other part of the work socripples the resulting system if done wrong. Noother part is as difficult to rectify later. [Brooks1987, p. 18]

Consequently, requirements engineer-ing research spans a wide range of topics[Pohl 1997], but a topic of increasingimportance is the analysis and man-agement of dependencies among require-ments. We call this requirements inter-action management (RIM) and define itas the set of activities directed toward

ACM Computing Surveys, Vol. 35, No. 2, June 2003, pp. 132190.

8/11/2019 3 - 2003 - p132-n_robinson.pdf

2/59

Requirements Interaction Management 133

the discovery, management, and disposi-tion of critical relationships among setsof requirements. Although the term it-

self is new, requirements engineers havelong recognized that the topics and issuesRIM encompasses are crucial to obtaininga good requirements specification.

The thrust of RIM is to analyze theextent to which a system can satisfymultiple requirements simultaneously. Asystem has many components, and eachcomponent has many requirementsrequirements that can interact with otherrequirements and with the environment.The satisfaction of one requirement canaid or detract from the satisfaction of an-other, and the environment can increase

or reduce requirement satisfaction [vanLamsweerde and Letier 2000]. Single-requirement methods existfor example,to minimize network latency or maximizenetwork throughputbut they typicallyapplyto only one or a few requirements. Asobject-oriented methods and networkedsystem deployment become more common,the number of components (and their in-teractions) will increase. Satisfying allthese requirements through componentcomposition becomes extremely difficult.

As Neumann [1995] has suggested,

The satisfaction of a single requirement is dif-ficult enough, but the simultaneous and con-tinued satisfaction of diverse and possibly con-flicting requirements is typically much moredifficult. [Neumann 1995, p. 2]

Yet, despite the importance of manag-ing requirements interactions, the state ofthe art suffers three major problems [vanLamsweerde et al. 1998]:

(1) The specific kind of interaction beingconsidered is not always clear.

(2) There is a lack of systematic tech-niques for detecting conflicts amongnonoperational requirements.

(3) There is a lack of systematic tech-niques for resolving conflicts.

RIM seeks to address all three.

1.1. Problematic Interaction

Component interaction errors, which arise

from incorrect requirements, have becomea significant development problem. Re-quirements errors are numerous: theytypically make up 25% to 70% of totalsoftware errorsUS companies averageone requirements error per function point[Jones 1995]. They can be persistent: two-thirds are detected after delivery. Theycan be expensive: the cost to fix them canbe up to a third of the total productioncost [Boehm 1981]. Moreover, many sys-tem failures are attributed to poor require-ments analysis [Jones 1996; Lyytinen andHirschheim 1987; Neumann 1995].

Component interaction errors can bemore serious than simple component fail-ures [Perrow 1984]. As Leveson [1995]observed:

Whereas in the past, component failure wascited as themajor factorin accidents, today moreaccidents result from dangerous design char-acteristics and interaction among components[Hammer 1980]. [Leveson 1995, p. 9]

Leveson documented several cases inwhich incorrect requirements caused com-ponent interaction errors with grave con-sequences.

1.2. Understanding Requirements Conflict

At first glance, it may appear straightfor-ward to support requirements interactionanalysis: simply formalize the require-ments, or at least structure them, and thenuse a computer-aided software engineer-ing (CASE) tool to check syntax and con-sistency. However, although CASE toolshave successfully provided support formodeling and code generation [Chikofskyand Rubenstein 1993; Lempp and Rudolf1993; Norman and Nunamaker 1989],they have been less successful in support-

ing requirements analysis [Lempp andRudolf 1993]. (In fact, the downstreamlife-cycle successes of these tools may beone reason systems analysts are spend-ing increasing amounts of time on require-ments analysis [Graf and Misic 1994].)Moreover, requirements analysis is not

just about checking the consistency of

ACM Computing Surveys, Vol. 35, No. 2, June 2003.

8/11/2019 3 - 2003 - p132-n_robinson.pdf

3/59

134 Robinson et al.

descriptions. In fact, inconsistent require-ments often reflect the inconsistent needsof system stakeholderssomething devel-

opers need to see. Inconsistent require-ments are the starting point for derivinguseful information that might otherwisego unnoticed [Finkelstein et al. 1994].

Inconsistency [Nuseibeh et al. 1994],conflict, breakdown[Winograd and Flores1987], cognitive dissonance [Festinger1964]all are terms that characterizeaspects of uncovering unexpected ideasduring problem solving and they arecommon in requirements engineering lit-erature (see Section 4.2.1). Conflict isan important driver of group commu-nication and productive work [Robbins

1983], and research has shown empiri-cally that it drives systems development[Lyytinen and Hirschheim 1987; Markusand Keil 1994; Robey et al. 1989] and,more specifically, requirements develop-ment [Bendifallah and Scacchi 1989; Kimand Lee 1986; Magal and Snead 1993;Robinson 1990].

Two basic forces give rise to require-ments conflict. First, the technical na-ture of constructing a requirements doc-ument gives rise to inconsistencyanysituation in which two parts of a [re-quirements] specification do notobey some

relationship that should hold betweenthem [Easterbrook and Nuseibeh 1996,p. 32]. Second, the social nature of con-structing a requirements document givesrise toconflictrequirements held by twoor more stakeholders that cause an incon-sistency. Applying the general conventionin requirements engineering, we use theterm conflict to indicate both problems un-less the context calls for the use of a morespecific term.

Consider three technical difficulties thatlead to requirements conflict:

Voluminous requirements. The sheersize of a requirements document canlead to conflicts, such as varied useof terminology. This is especially truewhen multiple analysts elaborate therequirements.

Changing requirements and analysts.As a requirements document evolves,

developers add new requirements andupdate older ones. One change requestcan lead to a cascade of other change re-

quests until the requirements reach aconsistent state. Consequently, the doc-ument is typically in a transitory statewith many semantic conflicts. Require-ments analysts expect to resolve most ofthese by bringing them to their currentstate (as the analysts interpret cur-rent state). Unfortunately, the implicitcurrent state of requirements is lostwhen analysts leave a long-termproject.Moreover, requirements concepts andtheir expressions vary with the devel-opment team composition.

Complex requirements. The complex-ity of the domain or software specifi-cation can make it difficult to under-stand exactly what has been specifiedor how components interact. If the de-velopment team and stakeholders arestruggling to understand the require-ments naturally, they are less likely tosee any requirements dependencies andthus likely to overlook requirementsconflicts.

Consider threesocial difficultiesthatlead to requirements conflict:

Conflicting stakeholder requirements.

Different stakeholders often seek dif-ferent requirements that the systemcannot satisfy together. For example,one stakeholder might want to usean open-source communication proto-col, while another wants a proprietarysolution.

Changing and unidentified stakehold-ers. In the attempt to understand sys-tem requirements, analysts often seeknew stakeholders for an ongoing project.

Analysts report that they can under-stand system requirements when inter-acting with actual users, but that it isdifficult to gain access to them [Lubarset al. 1993]. Moreover, one departmentof an organization may claim to bethe customer, but another departmentmay make the final purchasing decision[Lubars et al. 1993]. Thus, a previouslyunidentified stakeholder becomes animportant contributor of requirements.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

4/59


Changing expectations. In additionto the technical problem of trackingchanged requirements, there is the so-

cial problem of informing stakeholdersof the consequences of changes, as wellas managing stakeholders requests andtheir expectations of change. Researchshows that user behavioral partici-pation and psychological involvementpositively influence user satisfactionof the development products [Barkiand Hartwick 1989]. User participa-tion is particularly effective duringrequirements development [Kim andLee 1986; Leventhal 1995; Liou andChen 19931994; Magal and Snead1993; McKeen and Guimaraes 1997].

By managing conflict, organizations canmanage these technical and social dif-ficulties. RIM attempts to address suchtechnical and social problems as partof a strategy to manage the conflictsthat contribute to the essential difficul-ties of requirements engineering. It ad-dresses many problems by supportingrequirements traceability in a dynamic,multistakeholder environment [Gotel andFinkelstein 1995]. For example, by track-ing the statements asserted by analystsand stakeholders as they enact a re-

quirements dialog, developers can man-age voluminous requirements and visu-alize the changes in requirements, theanalyst team, or system stakeholders.Problems that are more social can alsobe addressed. For example, by trackingstakeholder statements, analysts can findtrends (e.g., convergence or divergence)of expectations. RIM tools can even sup-port the detection and resolution of mul-tistakeholder requirements conflict (seeSection 5).

1.3. Article OverviewThis survey has three major themes.First, we define RIM and its history(Sections 2 and 3). Second, we examinebasic research themes involving the RIMactivities (Section 4). Third, we summa-rize research projects illustrative of RIM(Section 5). We conclude by showing that

RIM has become a critical area of require-ments engineering whose methods willlead to the development of systems with

higher stakeholder satisfaction and fewerfailures (Section 6).

2. ELEMENTS OF RIM

As its name implies, RIM is about re-quirements, interactions, and manage-ment. Requirements are descriptions ofneeds. Interactions can be understoodby comparing requirements descriptionsor analyses of their underlying imple-mentations. Management focuses on theactivities that uncover and resolve re-

quirements interactions.

2.1. Requirements

Requirement has many definitions, eachemphasizing an aspect of requirementsengineering [Zave and Jackson 1997].Central to any definition is a stakeholderneed. For example, Davis [1993] statedthat a requirement is a user need or anecessary feature, function, or attribute ofa system that can be sensed from a posi-tion external to that system [Davis 1993].From such a broad definition stem many

specialized requirement types that ana-lysts use to categorize requirements (for amore refined description, see Pohl [1997]):

System. These requirements describethe type of system, such as hard-ware or software. There may even bedevelopment requirements concerningthe development process (cost-effective,timely) or development aspects of theresulting product (reusable, maintain-able, portable).

Functional and nonfunctional. Theserequirements describe the form of ser-

vice. Functional requirements describea service relation between inputs andoutputs. Nonfunctional requirementsdo not define a service, but instead de-scribe attributes of the service provi-sion, such as efficiency and reliability.Nonfunctional requirements are some-times calledsystem qualities.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

5/59

136 Robinson et al.

Abstraction level. Analysts describerequirements at different levels of ab-straction. They can add new details and

define them in more specialized subre-quirements. By specializing or refiningabstract requirements, or by generaliz-ing detailed requirements, they define arequirements abstraction hierarchy.

Representation. One requirement canhave several representations. It may be-gin as an informal sketch, become anatural language sentence (The systemshall. . . ), and end as a more formalrepresentation (temporal logic, SCR,Knowledge Acquisition in autOmatedSpecification of software (KAOS; seeSection 5.4)).

2.2. Interactions

Requirements are part of a managed de-velopment activity. As such, their interac-tions may or may not be formally analyzed.In fact, many projects maintain informalrequirements and only informally esti-mate their interactions. This leads to threebroad characterizations of requirementsinteractions:

Perceived interaction. Requirementdescriptions seem to imply that satis-

fying one requirement will affect thesatisfaction of another.

Logical interaction. The require-ments logical descriptions imply acontradiction or conclusions that can beinferred only through their combinedcontributions.

Implementation interaction. Require-ments interact through the behaviors ofthe components that implement them.If the implementation is correct, theseinteractions will be the same as the log-ical interactions. If the implementation

is incorrect or if environmental assump-tions differ from modeled assumptions,implementation and logical interactionsmay differ.

Taking a more formal perspective canbe helpful in understanding how require-ments interact. Consider a set of require-ments, R. If we take each requirement

as a logical statement, then logical incon-sistency occurs ifFalseis a logical conse-quence of the set of requirements [Wing

1990]:

Logical Inconsistency:

R |= False

Logical inconsistency means that nomodel can satisfy the requirements. Prac-tically, this means that no software behav-ior will satisfy the requirements.

Development seeks to create an imple-mentation, Impl, that behaves correctlyaccording to R:

Correct Implementation:Impl |= R

This means that Impl exhibits the be-haviors required in R.

Real systems are a bit more compli-cated. Behaviors of the systems environ-ment impose their own constraints, de-noted by E:

Correct Implementation within

an Environment:

E, Impl|=

R

This means that Impl, within E, ex-hibits the behaviors required in R.

Figure 1 illustrates environmentand implementation behaviors as sets[Jackson 1995] whose intersection rep-resents the admissible behaviors of theimplementation within its environment.Requirements define this intersectionbecause they describe the behaviors of theimplementation within an environment.We can view requirements interac-tions in the context of this conceptual

illustration:Requirements interaction. Require-

ments R1 and R2 interact in environ-ment E, if some conclusion, C, can bederived only when both are included inthe requirements. This may be triviallysatisfied where C is the conjunction ofrequirements.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

6/59


Fig. 1. Requirements as the boundary between environment behaviors and imple-mentable behaviors.

Requirements interaction:

(1) E, R1 |=/ C(2) E, R2 |=/ C(3) E, R1,R2 |= C(4) C |=/ False

Negative interaction (conflict). A neg-ative interaction is a kind of re-quirements interaction where False isderived from the conjunction of the re-quirements. In the preceding interac-tion definition, clause 4 becomes:C |=False.

Positive interaction. A positive inter-action is a kind of requirements in-teraction where False is not derivedfrom the conjunction of the require-ments. In the preceding interaction def-inition, clause 4 is important, as C de-

fines the effect of the interaction. (SeeSection 5.4 where van Lamsweerdesdefinitions of conflict and divergence ac-count for inconsistencies among sets ofrequirements.)

Requirements implementation conflict.Requirements R1 and R2 in environ-ment E , interact through the behaviorsof their respective implementations ifeach requirement can be individuallysatisfied by the component implement-ing it, whereas the two implementationcomponents cannot be combined to sat-isfy both requirements together.

A requirements implementationconflict:

(1) E, Impl1 R1

(2) E, Impl2 R2

(3) E, Impl1 Impl2 / R1 R2

(In the preceding formula, the satisfiesrelation is denoted with; does not satisfyis denoted with / [Wing 1990].) It is pos-sible that no implementation can satisfyboth requirements:

All known requirementimplementations conflict:

(1) Impl1: E, Impl1 R1(2) Impl2: E, Impl2R2(3) Impl3: E, Impl3R1 R2

Much requirements engineering litera-ture addresses requirements descriptionsand analyses, but less is said about how todescribe environmental actions, laws, andnorms, which can also be quite difficult.In some cases, the failure to consider en-

vironmental characteristics can result indisastrous system failures.Flight systems are an example. In the

air, braking is not allowed, but a safe land-ing obviously requires brakes. To ensurethat pilots did not inadvertently engagethe A320s braking system, the softwarerequired that the wheels detect the fullweight of the airplane. However, when aLufthansa pilot attempted to land in War-saw on a wet, runway in high winds, thesystem did not detect the full weight ofthe plane on the wheels [Ladkin 1995a,1995b], with the following results:

[. . . ] thespoilers, brakesand reverse thrustweredisabled for up to 9 seconds after landing in astormon a waterlogged runway, and the airplaneran off the end of the runway and into a con-veniently placed earth bank, with resulting in-

juries and loss of life. [Ladkin 1995b]

Disastrous system failures, such asthe Lufthansa A320, can arise from


8/11/2019 3 - 2003 - p132-n_robinson.pdf

7/59

138 Robinson et al.

undesirable interactions among require-ments or between the required behaviorsand the environment.

At some point, of course, the scope ofthe environmental model must have someboundary. Determining what about the en-vironment to model is a development de-cision that depends on the available timeand the budget. The assertions in E candetermine if a requirements conflict ex-ists. In fact, analysts can work backward.Given requirements R1 and R2, is therea condition, B, that could cause them toconflict? If so, is it likely that Bwill occurwithin the environment?B could be a rain-soaked runway, for example. Had suchan obstacle been considered, the accident

might not have happened. On the otherhand, what is the likelihood of a rain-soaked runway? If it is low, its analysiscan be postponed indefinitely. If it is high,analysis and modeling are more pressing.

Analyst decisions regarding what to modelcan greatly influence the scope of the inter-actions that are uncovered.

2.3. Requirements for a Distributed

Meeting Scheduler

The distributed meeting scheduler prob-lem illustrates the challenges of analyzing

requirements interactions. We chose thisproblem because the schedulers require-ments definition involve complex multi-stakeholder interactions that raise manyissues like privacy, responsibility, and ef-ficiency. We also chose it because its com-pact, yet rich, requirements document hasbeen widely circulated [van Lamsweerdeet al. 1993] and analyses have been pub-lished [Potts et al. 1994; van Lamsweerdeet al. 1995; Robinson and Pawlowski1997].

Van Lamsweerde et al. [1995, p. 197]stated the general requirements for a

scheduler:

The purpose of ameeting scheduleris to supportthe organization of meetingsthat is, to deter-mine, for each meeting request, a meetingdateandlocationso that most of the intended partic-ipants will effectively participate. The meetingdate and location should thus be as convenientas possible to all participants. Information about

the meeting should also be made available asearly as possible to all potential participants.

The remaining requirements of the four-page baseline description refine the rolesof the meeting scheduler and participants.However, this introduction is sufficient tounderstand the examples that follow.

2.3.1. Requirements Definition. To showhow requirements may interact, wepresent two requirements for informa-tion privacy and we describe them for-mally so that we can include examplesof formal interaction analysis. The first isthe InitiatorKnowsConstraintsrequire-ment [Robinson and Volkov 1997; van

Lamsweerde et al. 1998]:

Requirement InitiatorKnows

Constraints

Mode Achieve

InformalDef

A meeting initiator shall

know the scheduling constraints of the

various participants invited to the

meeting within some deadline d (days)after the meeting initiation.

FormalDef

m: Meeting, p: Participant,i: Initiator

Invited(p, m) dKnows(i, p.Constraints)

This requirement definition is in a vari-ant of the KAOS language (see Sections 5and 5.4), which allows for both informaland formal descriptions. The formal defi-nition uses real-time temporal logic oper-ators [Koymans 1992]. The means sometime in the future. Other operators referto the next state (o), the previous state (),some time in the past (), always in thepast (), and always in the future ().

The second requirement for informa-tion privacy is, InitiatorNever Knows-Constraints:

Requirement InitiatorNeverKnowsConstraints

Mode Avoid


8/11/2019 3 - 2003 - p132-n_robinson.pdf

8/59


InformalDefA meeting initiator shall

never know the scheduling constraints

of the various participants invitedto the meeting after the meetinginitiation.FormalDef

m: Meeting, p: Participant,i: InitiatorInvited(p, m)

knows(i, p. Constraints)

2.3.2. A Conflict and Its Resolution. Thetwo requirements can conflict under cer-tain circumstances, described in boundarycondition,B [van Lamsweerde et al. 1998].That is:

InitiatorKnowsConstraints,

InitiatorNeverKnowsConstraints,

B |= False

We can show a condition, B, that leads toa contradiction:

( p : Participant, m : MeetingInvited(p, m))

The following shows that we can indeedderive a contradictory assertion from theconjunction of the two requirements andthe boundary condition:

( p : Participant, m : MeetingInvited(p, m)d Knows(i, p.Constraints) Knows(i, p.Constraints))

There are several ways to resolvethis conflict [Robinson and Volkov 1996].One is to rely on a scheduler pro-

gram. Rather than provide schedulingconstraints to the initiator, enable thescheduler to find a meeting time. Usingthis approach, only the scheduler pro-gram knows the constraints, while theinitiator is simply notified of the meet-ing time. This approach is captured inthe following requirement, which replaces

InitiatorKnowsConstraints:Requirement SchedulerKnows

Constraints

Mode AchieveInformalDef

A meeting scheduler shall

know the scheduling constraints of the

various participants invited to the

meeting within some deadline d (days)after the meeting initiation.

FormalDef

m: Meeting, p: Participant,s: Scheduler

Invited(p, m) d Knows(s, p.Constraints)

Relying on the scheduler to performcomplex actions may be wishful thinking.That is, an implementation that satisfiesthe schedulers required function may notexist. A step toward determining an im-plementation is to describe the schedulersmain function as follows:

Operation DetermineScheduleInput MeetingRequestOutput MeetingPreCondition

Scheduled(m)

(i: Initiator) Requesting(i, mr)PostCondition

Feasible(mr) Scheduled(m) Feasible(mr) DeadEnd(m)

Still, the question remains: is therean implementation that either derivesa meeting schedule or identifies infea-sible meeting constraints (a dead end)?Moreover, this is simply one require-ment. Analysts must still determine if allmeeting scheduler requirements can besatisfied together. Additionally, the envi-ronment may cause problems, such as net-

work delays in sending or receiving par-ticipant constraints, or reduced processingcapacity on the (shared) computer. There-fore, while the initial requirements maybe acceptable (R|=/ False), analysts mayneed to elaborate them to ensure that theyare satisfied within their environment (E,Impl |= R).


8/11/2019 3 - 2003 - p132-n_robinson.pdf

9/59

140 Robinson et al.

2.3.3. A Nonfunctional Conflict. Require-ments may involve nonfunctional qual-ities of service, such as effort, cost, or

usability. These can be analyzed in thesame manner as the functional con-flict between InitiatorKnowsConstraintsandInitiatorNeverKnowsConstraints. Considerthe following nonfunctional requirement(we have deliberately omitted formal defi-nitions here):

Requirement SchedulerShallNotIncreaseParticipantEffort


A meeting scheduler fora meeting shall not increase the

effort of invited participants."

SchedulerShallNotIncreaseParticipantEffort indicates that thescheduler shall not increase the effortof participants. This may be difficultto achieve because we assume that thescheduler is to determine a meetingtime. To do so, it must know the cur-rent participant scheduling constraints.Thus, there is a functional assump-tion, InviteeRespondsWithUpdatedConstraints, that captures the as-sumption that participants will reply

to the schedulers request with updatedconstraints:

Assumption InviteeRespondsWithUpdatedConstraints

InformalDefA meeting participant

shall update his scheduling constr-aints within some deadline d1 (days)after the meeting request and thenreply to the request with his cons-traints (within d2 days).

A domain definition links the sched-ulers behavior to the participants behav-ior. The followingRequestIncreasesEffortdefinition indicates that, by the request,the requesting agent has increased the ef-fort of the receiving agent. This definitionshows that the scheduler can increase theeffort of a participant:

DomainDef RequestIncreasesEffort

InformalDef"An agent that requests a

reply from a second agent imposes

an increased effort on the secondagent.

It may be clear by now that there is apotential nonfunctional conflict, which canbe summarized as

SchedulerShallNotIncreaseParticipantEffort, InviteeRespondsWithUpdatedConstraints, RequestIncreasesEffort|= False

The increased burden imposed by thescheduler conflicts with the decreasedeffort specified by the requirementSchedulerShallNotIncreaseParticipant

Effort.

2.4. Interaction Features

Analysts can define requirements interac-tions through their features, such as basis,degree and direction, and likelihood.

2.4.1. Basis. The basis specifies the ele-ments of the interaction. In the precedingexample, a nonfunctional requirement, anenvironmental assumption, and a domainproperty together form the basis of thenonfunctional conflict. More specifically,the conflict basis is the minimal set ofstatements (environment and require-ment) that imply a contradiction. (SeeSection 2.2.)

2.4.2. Degree and Direction. Some re-quirements imply a logical contradiction,and thus define a 100% conflict. How-ever, analysts can specify requirementssatisfaction as a range of values1 to100%, for example, see Liu and Yen [1996].Given that requirements satisfaction maybe partial, requirements interaction maybe partially positive or partially negative.

Looking again at SchedulerShallNotIncreaseParticipantEffort, suppose wereplace the statement that the sched-uler shall not increase the effort ofinvited participants with the state-ment that the scheduler shall mini-mize the effort of invited participants.Call this new requirement, SchedulerMinimizeParticipantEffort.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

10/59


Given this formulation, analysts mustdetermine if an increase in a partici-pants effort, caused by InviteeResponds

WithUpdatedConstraints, conflicts withthe schedulers requirement to minimizeparticipant effort. One conclusion is thatsuch an increase somewhat conflictswith effort minimization, which suggeststhe use of a qualitative scale. Of course,multiple occurrences of an increase couldlead to a strongly conflicts conclusion[Chung et al. 1995].

So far, we have focused mainly on nega-tive interactions. Requirements may alsointeract to reduce conflict. Consider, for ex-ample, an automated reply mechanism forthe participant in the scheduler problem.

Given a request, another agent replies in-stead, thereby reducing the effort of the re-quested agent. The following domain defi-nition describes this:

DomainDef AutoReplyReducesEffortInformalDef

A proxy agent that rep-lies to a request for another agentdecreases the effort for the otheragent."

Now, an analyst can conclude that AutoReplyReducesEffort increases the satis-

faction ofSchedulerMinimizeParticipantEffort. Thus, the same requirementscan have both positive and negative in-teractions. For example, if the schedul-ing system required both autoreply andparticipant reply, then the satisfactionof SchedulerMinimizeParticipantEffortwould be indeterminate.

Others have modeled partial require-ments satisfaction as follows: the de-gree of satisfaction, d , of a requirement,R, by the behaviors of implementation,Impl, is defined by the following ternaryrelation:

Partial Requirements Satisfaction:

PartSat(Imp, R, Degree), whereImp : set of implementationsR : set of requirementsDegree : [0, 100]

We can use Impl dR to indicate thatImplpartially satisfies R to the degree,d .

A simple and practical approach placesscaled attributes on requirements [Gilb1977, 1988]. Then, stakeholders associate

values with the attributes, such as Usabil-ity= 60 Availability= 20 (on a scale of100). Analysts can use these metrics toidentify unsatisfied requirements.

Some analysts have used fuzzy set the-ory to formalize requirements satisfactioninto linguistic terms, such as high, or low.Fuzzy set theory maps ranges of satisfac-tion onto terms, as illustrated in the fol-lowing definition of the PartSat fuzzy set[Liou and Chen 19931994; Liu and Yen1996; Yen and Tiao 1997]:

FuzzySetPartSat(Degree) = High, where

Degree [75..100]FuzzySetPartSat(Degree) = Medium,where Degree [25..74]

FuzzySetPartSat(Degree) = Low, whereDegree [0..25]

Utility theory and fuzzy set theoryprovide techniques to aggregate require-ments satisfaction across a variety of at-tributes, such as cost or reliability.

2.4.3. Conflict Likelihood. Often, require-ments can conflict; but the likelihood ofsuch a conflict may be acceptable. Regard-

less, characterizing the likelihood that aninteraction will occur is always helpful.

In the scheduler problem, the de-gree of satisfaction for the requirementSchedulerMinimizeParticipantEffortdepends on the environment. In anenvironment where a participant re-ceives many requests from the scheduler,the satisfaction of SchedulerMinimizeParticipantEffort may be low (Impl

LowR). An analyst can model the numberof requests,k , that a participant receives.Then, the likelihood that a participantreceives many requests (Pk) determines

the likelihood that the requirementSchedulerMinimizeParticipantEffortwill be satisfied. If the analyst knows thatPk 0, or the consequences ofSchedulerMinimizeParticipantEffort failing areacceptable, then it is likely that therequirements will be satisfactory withinthe specified environment.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

11/59

142 Robinson et al.

Fig. 2. A descriptive framework of RIM research.

2.5. Managing Interaction

The management element of RIM con-cerns the strategic application of activitiesto identify, analyze, monitor, document,communicate, and change requirementsinteraction. The activities may be appliedwithin an ad hoc or a defined process, mayinvolve the use of special tools and tech-niques, and may be conducted solely byanalysts or by analysts and other stake-holders. In any case, the overall goals ofthese activities include the following:

Detect and resolve requirements con-flict (negative interactions).

Increase system effectiveness by mutu-ally reinforcing requirements (positiveinteraction)

Increase involvement from a variety ofstakeholders.

Satisfying these goals reduces overallsystem errors and costs and increases sys-tem effectiveness and stakeholder satis-faction.

As a discipline, RIM is new and evolving.It has five major dimensions:

Representation of requirements, inter-actions, resolutions, and other prod-

ucts. Researchers are defining the setof terms, or ontology, that describe re-quirements and their interactions.

Activities for discovery, management,and disposition of interactions. Re-searchers are defining techniques, someautomated, that manage or aid in man-aging interactions. Often, this research

aims to provide early life-cycle analysisrather than address interactions at sys-tem runtime.

Views of the activities and products.RIM research is not conducted in isola-tion. Rather, it is being integrated intotraditional software development toolsand methods. Thus, different stakehold-ers may access different views of RIManalysis. Views include abstract agentdescriptions found in i* (see Section 5.3)to the tabular transition tables of SCR(see Section 5.6). Eventually, customers,developers, and users will be able toaccess requirements interactions from

views tailored to their purpose.Goals of stakeholders. Researchers are

defining goal ontologies and analyses toaid in requirements negotiations amongstakeholder views and the strategic ap-plication of RIM.

Theoretic basis for representation, acti-vities, and views. Researchers areaugmenting traditional requirements-engineering theories with theories fromdatabase, artificial intelligence, knowl-edge acquisition and representation,and social conflict and negotiation to es-tablish a theoretical basis for the sup-port and application of RIM.

Figure 2 proposes a classification of RIMresearch along these five dimensions. Thetheories provide a basis for developingnew specialized techniques. Drawn froma variety of disciplines, they include con-cepts like database schema integration


8/11/2019 3 - 2003 - p132-n_robinson.pdf

12/59


that researchers can adapt to fit RIM.Other concepts include models, ontolo-gies, and formal analyses for requirements

engineering.Thegoalsdimension defines RIM goals

and strategies. For example, a commonsocial negotiation strategy suggests re-solving simple conflicts first and difficultones later [Pruitt 1981]. Such a strategymay also be appropriate for software de-velopment. However, defining and deter-mining simple and difficult conflicts willbe among the concerns in specializing thestrategy. The goals dimension also definesgoals for individual and collective stake-holder views.

The views dimension defines stake-

holder interfaces to the activities andproducts that make up RIMs technolog-ical component. For example, an analysttypically has access to all the activi-ties and their products during develop-ment, while a system user may have amore limited view. Similarly, the method-ologies and tools used provide variedperspectives on RIM issues. For exam-ple, a tool may address the managementof requirements interactions in supportof a RIM-oriented development method-ology, while another tool ignores RIMissues.

The activitiesdimension defines analy-ses and modifications for requirements in-teraction.

Theproductsdimension includes inter-mediate and final results used during theactivities.

3. AN HISTORICAL PERSPECTIVE

RIM has a narrow systems focus oninteraction management, but it borrowsfrom many theories and techniques fromother disciplines.

3.1. Conceptual Evolution

Table I summarizes prominent conceptsand their evolution into the emerging dis-cipline of RIM. Because of space limita-tions, the references for each concept arerepresentative, not exhaustive. We distin-guish conceptsby timeand by the five cate-

gories described in Figure 2: theory, goals,views, products, and activities.

The top-most row of Table I summa-

rizes some RIM theoretical developments.Many of these concepts, such as prefer-ence, conflict, negotiation, and resolution,derive from human negotiation [Pruitt1981] and group decision-making [Janisand Mann 1979]. A general overarchingtenet of RIM is analogous to that of groupdecision-making:

Specifying stakeholder views on system require-ments, followed by their negotiated integration,will result in systems that are both technicallybetter, but are also more accepted by systemstakeholders.

Goals and strategies make this tenetoperational.

3.1.1. Development Goals Interaction. Re-searchers and practitioners recognizedearly on that specifying developmentgoals is important. In a 1974 experi-ment, Weinberg and Schulman [1974]gave teams one of the following goals tosatisfy: minimize effort, minimize linesof code, minimize memory use, maximizeprogram clarity, and maximize clarity ofprogram output. All but one team did beston their given goal. Since then, many re-

searchers have specified a variety of soft-ware development goals, and their re-lationships [Barbacci et al. 1995, 1997;Boehm 1981; Chung et al. 1995; Kazmanet al. 1998]. Most recently, the empha-sis has been on creating models and toolsto aid in the analysis of software devel-opment goal interactions. An example isWinWin [Boehm 1996], which we describein Section 5.1.

Reasoning about requirements goalshas evolved concurrently with the evolu-tion of software development goals. Mul-tiple Attribute Utility Theory (MAUT)

[Raiffa 1968] and later Multiple CriteriaDecision Making (MCDM) [Zeleny 1982]have provided general decision theoretictechniques that help analysts elicit crite-ria and trade them off during decision-making. An example is Oz [Robinson1994], which we describe in Section 5.5.The more specialized decision technique


8/11/2019 3 - 2003 - p132-n_robinson.pdf

13/59

144 Robinson et al.

Tab

le

I.

EvolutionofRIM

Concepts

Before1970

1970s

1980s

1990s

Theory

Codifiednegotiation

techniques:log

rolling,condition

restructuring[Pruitt

1981]

Groupdecision-making

[HeymandOsterle

1993]

Requirements

NegotiationBehavior

[BendifallahandScacchi1989;

Robinson1990]

Negotiationexperts:

case-based[Sycara1991],

rule-based[Werkman1990b]

Domain-independent

resolutiongeneration

[RobinsonandVolkov1996]

Goals

Programminggoals

[Weinbergand

Schulman1974]

Softwarequalities

[Boehmetal.1978]

Softwaredevelopmentgoalstruct

ure

[Boehm1981]

Softwarequalityattributes[Ba

rbacci

etal.1997]

Managementby

Objectives

[D

rucker1954]

Softwaremetrics[Gilb1977]

Softwarequalityinteractionex

perts

[Boehm1981]

MAU

T[Raiffa

19

68]

MCDMprogramming

[Zeleny1982]

MCDMforrequirements[Robinso

n1994]

Softwarequalityarchitecting[K

azman

etal.1998]

QFD[Hauser1988]

QFDforrequirements[Jacobsand

Kethers1994]

Nonfunctionalframework[Mylopoulos

etal.1992]

Views

Multiviewspecification

[Mullery1979]

MethodEngineering[Kumarand

Welke

1992]

Parallelelaboration[Feather1989]

RequirementsViewpoints[Nus

eibeh

etal.1994]

Processprogramming[Osterweil

1987]

Processcompliance[Emmerich

etal.

1997]

Interactionmonitoring[Fickas

and

Feather1995]

Products

RequirementsModelingLanguag

e

[Greenspanetal.1994]

Requirementstraceability[Pottsand

Bruns1988]

Goalorientedrequirements[Da

rdenne

etal.1993]

Agent-orientedrequirements

[Mylopoulosetal.1997]

Activities

Goal-baseddesign[Kant

and

Barstow1981]

Goal-basedrequirementsnegotiation

[Robinson1989]

Programslicing[Horwitzetal.19

89]

Goalregressionforrequiremen

ts

[Robinson1993,1994;van

Lamsweerdeetal.1998]

Schemaintegration[Batinietal.

1986]

Inconsistencydialog[Finkelstein

and

Fuks1989]

Inconsistencyreasoning[Hunterand

Nuseibeh1998]

Inconsistencyframework[Cugo

laetal.

1996]

Multiagentplanning[Georgeff19

84]

Agentnegotiation[Sandholma

nd

Lesser1995]


8/11/2019 3 - 2003 - p132-n_robinson.pdf

14/59


of Quality Function Deployment [Hauser1988] has been applied to requirementsanalysis (e.g., Jacobs and Kether [1994]).

3.1.2. Multiple System Views. Views,or views, on sets of related require-ments have also evolved. Approaches,such as CORE [Mullery 1979], ETHICS[Mumford and Weir 1979], and later Mul-tiView [Avison 1990] and Soft Systems[Checkland 1981], combined both socialand technical development aspects in rep-resenting various system requirementsviews. Feathers [1989] parallel elabo-ration work described the algorithmicaspects of representing, comparing, andcombining various system views, as didthe ViewPoints project [Nuseibeh et al.1994] (see Section 5.3), and a growing bodyof related research [Finkelstien 1996].

3.1.3. Requirements Modeling Languages.

Requirements definition languagesevolved to support reasoning about in-teractions among requirements views.For example, the Requirements Model-ing Language (RML) [Greenspan et al.1994] has given rise to languages thatfocus on agents [Mylopoulos et al. 1997]and goals [Dardenne et al. 1993]. (See

KAOS the discussion of in Section 5.4).Such languages let analysts determinehow the actions of external and systemagents affect the satisfaction of systemrequirements.

3.1.4. Interaction Analysis. Many require-ments-interaction-reasoning techniqueshave come from related fields. For ex-ample, goal regression, an ArtificialIntelligence (AI) planning technique, canuncover certain requirements that are theroot cause of a conflict [van Lamsweerdeet al. 1998]. (See Section 5.5.) Similarly,

database schema integration ideas [Batiniet al. 1986] are helpful in combining re-quirements views [Spanoudakis andFinkelstein 1997]. Finally, from nonmono-tonic reasoning have come logics andframeworks for reasoning about logicalinconsistencies [Hunter and Nuseibeh1998].

Table II. Disciplines Influencing RequirementsInteraction Management

Software engineeringRequirements engineeringFormal specificationConcurrent engineeringQuality architectingFeature interaction

Database view integrationSchema integrationSchema reengineering

Knowledge acquisition and representationKnowledge integrationInformation integration

Distributed artificial intelligenceReasoning with inconsistency and

incompletenessDistributed problem solving, coordination,

collaborationNegotiation support systems

CoordinationCollaborationGroup issues: dominance, anonymity

Social conflict and negotiationNegotiation theory and modelsNegotiation strategies and tacticsBargaining and arbitrationPolitical negotiation

Social economicsIndividual decision-making

Cognitive dissonance theoryUtility theory

3.2. Influential Disciplines

Interaction management research, most

of which aims to identify and managenegative interactions, spans a variety ofdisciplines. To characterize influences onRIM, we surveyed over 60 published worksthat RIM articles referenced. These ref-erenced works described mainly theories,techniques, and tools for the managementof conflicts. They included disciplines fromthe computer and information to cognitiveand social sciences. From the articles, weidentified seven distinct areas of influence,which Table II lists.

3.2.1. Software Development. Research-

ers in software development are address-ing interaction management in a numberof contexts, including the following:

Requirements inconsistency. Detect-ing and resolving requirements in-consistency is a growing theme ofrequirements engineering, which weexpand in this article. The Viewpoints


8/11/2019 3 - 2003 - p132-n_robinson.pdf

15/59

146 Robinson et al.

project (see Section 5.3), for example,provides a framework in which rulescapture inconsistencies among and

within views of a system requirementsspecification.

Formal specification. Analysts haverecognized the need for methods to de-tect and resolve inconsistencies in for-mal specifications [Lamsweerde 2000].Now, formal techniques can detect in-consistencies [Spanoudakis and Finkel-stein 1995], deduce in the presence ofconflict [Hunter and Nuseibeh 1998],and manage conflict [van Lamsweerdeet al. 1998] (see the discussion of KAOSin Section 5.4).

Concurrent engineering. Detectingand resolving design differences amongthe designs of multifunctional andmultidisciplinary teams is a concern ofconcurrent engineering [Kusiak 1993].Quality function deployment (QFD) iscommonly used to identify interactionsamong system requirements as well asamong lower-level design or productionrequirements [Kusiak 1993]. Othermethods, such as heuristic conflict clas-sification and resolution identify andresolve undesirable design interactions[Klein 1991].

Feature interaction. Detecting and re-solving undesirable functional interac-tion is an established part of telephonysoftware development. For example,there is a conflict between CallerID, which provides the receiver withthe callers number, and UnlistedNumber, which keeps the caller fromrevealing the originating number. An

AI planning method that includesgoal hierarchies generates a resolu-tion in which the callee receives thecallers name, but not the callers num-ber [Velthuijsen 1993]. This planning

method is but one of a number of meth-ods for resolving feature interactions. Arecent article surveys formal, informal,and experimental methods [Keck andKuhn 1998].

Quality architecting. Analyzing howdifferent system architectures affecttradeoffs among system qualities is a

concern of software architects [Perryand Wolf. 1992]. A method, such as

ATAM [Kazman et al. 1998], analyzes

system qualities, such as performance,security, and reliability to determine if asystem architecture can satisfy multipleinteracting system qualities. If it can-not, the method helps select an archi-tecture that satisfies the most qualities.

3.2.2. Database View Integration. Re-searchers in database development areaddressing interactions inschema consis-tency. Traditionally, relational databasedesigners start with multiple views ofdata and then combine those views into

a global data schema. As part of theschema integration activity, they identifyconflicts among the views [Batini et al.1986], including differences in name orstructure. Generally, defined methodolo-gies have supported this activity [Batiniet al. 1986], but tool support is growing[Francalanci and Fuggetta 1997; Jeusfeldand Johnen 1994; Johannesson and Jamil1994; Ram and Ramesh 1995].

3.2.3. Knowledge Acquisition and Represen-

tation. Researchers in knowledge acqui-sition and representation are addressing

interactions in a number of contexts, in-cluding the following:

Knowledge integration. Knowledgebases, such as those in expert systems,should be consistent if they are tosupport deductive reasoning. To sup-port this consistency goal, there mustbe some way to combine knowledgegained from multiple experts and makeit consistent within the computerizedknowledge base. Common knowledge-integration techniques include the useof meta-knowledge, set-theoretic anal-

ysis, consensus theory, repertory gridanalysis, cluster analysis, and decisiontheory [Botten et al. 1989]. One tool,based on repertory grid and personalconstruct theory, aims to support thederivation of terminological consistencyamong experts [Shaw and Gaines 1988,1989].


8/11/2019 3 - 2003 - p132-n_robinson.pdf

16/59


Information integration. During itsexecution, a knowledge-base systemmay receive a variety of inconsis-

tent inputs. To solve its overall task,the system must appropriately dealwith these inconsistencies [Lander andLesser 1989; Hearst 1998]. For example,various scheduling databases in a meet-ing scheduling system might referencethe same person using slightly differ-ent names; an information integrationagent can reconcile this discrepancy byrecognizing naming differences [Sycaraet al. 1996].

3.2.4. Distributed Artificial Intelligence. Theanalysis of interaction among distributedartificial intelligence agents is similar tothe analysis of multiple viewpoint require-ments. Each distributed AI agent repre-sents a requirements viewpoint and theagent knowledge base represents the re-quirements viewpoint description. Thus,when distributed AI agents interact tocomplete shared tasks, their representa-tion and reasoning is similar to that foundin the integration of multiple require-ments viewpoints.

Distributed AI research is addressinginteractions in a number of contexts, in-cluding the following:

Distributed agent negotiation. Dis-tributed artificial intelligence hasexpanded the role of planning. Multi-agent planning systems identify andresolve plan failures that occur amongsets of loosely coordinated agents (e.g.,Conry et al. [1991]; Durfee [1988];Georgeff [1984]; Kraus and Wilkenfeld[1990]; von Martial 1992]). If the plan-ners reach an inconsistent state, theymay cooperatively negotiate to satisfyother plans [Conry et al. 1991]. To doso, they may use economic models to

guide their decision-making so thatthey can efficiently manage their re-sources [Sandholm and Lesser 1995].

Again, the method of resolution istypically subgoal replanning; however,the subgoal failure and replanning iscomplicated without global information.Researchers in AI, and subsequently

distributed AI, have defined negotiat-ing agents, which has given rise to twocomplimentary research areas:

Negotiation analysis knowledge. Case-based reasoning and rule-base program-ming codify and aid analyses to identifyand resolve the conflicts that arise in avariety of domains, including labor ne-gotiation [Sycara 1988], design integra-tion [Klein 1991], and specification inte-gration [Robinson and Volkov 1997].

Negotiation protocol knowledge.Frameworks [Conry et al. 1988; Smith1980] and communication protocols[Kraus and Wilkenfeld 1990; Landerand Lesser 1993; Mazer 1989; Oliver

1996; Sandholm and Lesser 1995] aid incoordinating the sequences of messagesamong distributed negotiating agents.

3.2.5. Negotiation Support Systems. Re-searchers in negotiation support systems(NSS) are addressing interactions withthe aim of advising a human negotiatoror supporting humans gathered arounda negotiation table [Jelassi and Foroughi1989, Lim and Benbasat 19921993]. Re-search ranges from developing an NSSshell aimed at supporting the construc-tion of negotiation systems [Kersten and

Szpakowicz 1994; Matwin et al. 1989] tospecialized domain support such as airlinebuyout [Shakun 1991], product marketing[Rangaswamy et al. 1989], or electronicmarketplace [Yen et al. 1996]. Some ne-gotiation support systems have borrowedfrom AI reasoning features. Negotiationsupport systems often focus on human as-pects of negotiation including the domi-nance and anonymity of participants.

3.2.6. Social Conflict and Negotiation. The-ories and studies of conflict and negotia-tion among humans have influenced much

of the research just described. This back-ground in persuasion [Fisher and William1991], negotiation [Pruitt 1981; Raiffa1982], and decision-making [Janis andMann 1979; Raiffa 1968] is the basis formany computerized models.

Researchers have adapted techniquesfrom human negotiations to assist in


8/11/2019 3 - 2003 - p132-n_robinson.pdf

17/59

148 Robinson et al.

Fig. 3. An illustration of the activities that aremanaged as part of the requirements interactionmanagement life-cycle. Each number indicates thesection where an activity is introduced. The symbol,

R, depicts a set of requirements, while the symbol,, depicts conflicting requirements.

detecting and resolving requirements con-flicts. For example, case-based and rule-base methods [Robinson and Volkov 1996;van Lamsweerde et al. 1998] were gen-eralized and formalized from the domain-specific techniques of the 1980s.

3.2.7. Individual Decision-Making. Individ-ual decision-making has influenced thebasic theories of interaction managementresearch. Multiattribute utility theory

suggests how an individual can trade offvarious interacting goal to maximize over-all utility [Raiffa 1968]. Some decisionmodels consider the dynamic aspects ofthis process. For example, as an individ-ual learns of the tradeoffs among goals, heor she may reconsider the value, or weight,placed on individual goals [Zeleny 1982].

4. LIFE-CYCLE ACTIVITIES

Figure 3 illustrates RIM activities. We de-rived the figure from our model of auto-mated negotiation, which we created from

a survey of tools and theories [Robinsonand Volkov 1998]. The description beginswith unstructured requirements, whichanalysts may partition. Next, interactionidentification may provide conflicts thatanalysts must address. Through interac-tion focusing, they consider only a sub-set of interactions at a time. Resolution

generation provides alternative ways toresolve eachconflict. Finally, resolutionse-lection determines which resolutions will

become change requests for the require-ments document.

As Figure 3 shows, the activities in theRIM life-cycle fall into six groups. EachRIM activity has associated research is-sues, which we describe next.

4.1. Requirements Partitioning

Requirements partitioning seeks to focusinteraction analysis on manageable re-quirements subsets. This is important,since analyzing all the interactions among

all requirements can involve significantcomputation. For n requirements, therecan be n(n1)/2 binary conflicts; the spaceis even worse for n-ary conflicts. Parti-tioning seeks to divide this problem intoa set of smaller problems. Requirementspartitioning gives rise to the followingissues:

Issue: On what basis should a require-ments document be partitioned into sub-sets that enhance analysis?

Many computer science communitieshave considered problem partitioning

based on goals, among them the dis-tributed AI community [Gasser andHuhns 1989]. Partitioning based on stake-holder views is a commonly used natu-ral partitioning based on the originatingsource of the stated requirements [Check-land 1981; Gotel and Finkelstein 1995].Other partitions may be based on rootrequirements [Robinson and Pawlowski1998], requirements issues [Yakemovicand Conklin 1990], nonfunctional soft-ware attributes [Boehm 1996], require-ments consistency [Easterbrook 1993], orscenarios [Potts et al. 1994]. In compos-

ite system design, Feather [1989] has usedthe cross-product of functional partition-ing and agent responsibility to partitionrequirements. This approach is continuedin the deficiency driven design method, de-scribed in Section 5.5.

Issue:How can an analyst allocate require-ments to partitions?


8/11/2019 3 - 2003 - p132-n_robinson.pdf

18/59


Table III. Types of Requirements InteractionsType Description ExemplarPositive

interactionIncreasing the satisfaction ofR1 increases the

satisfaction ofR2.Some, +, ++, [Chung et al. 1995]Influence

+[Gustas 1995]

Negativeinteraction

Increasing the satisfaction ofR1 decreases thesatisfaction ofR2.

Hurts, , , [Chunget al.1995]Contradictory Influence -

[Gustas 1995]Unspecified

interactionChanging the satisfaction ofR1 has an unspecified

effect on the satisfaction ofR2.Impacts on

interdependencyNo

interactionIncreasing the satisfaction ofR1 has noeffect onthe

satisfaction ofR2.Neutral

If each partition has some character-ization, database and keyword searchtechnology can partition requirements.For example, commercial tools can applydatabase technology to select subsets

of requirements based on requirementattributes. Difficulties arise when therequirements are not attributed a prioriwith necessary characteristics. In suchcases, partitioning can be based on thekeywords in each requirement. However,the presence of a keyword does not neces-sarily indicate that the key characteristicis in the requirement. Some researchershave overcome the limitations of keywordretrieval by using concept-based infor-mation retrieval [Chen 1992; Chen et al.1993].

Sometimes requirements subsets con-

structed with different terminology canfurther confound partitioningfor exam-ple, when different people develop therequirements. In such cases, statisticalmeasures of usage can help generate map-pings among terms [Shaw and Gaines1988].

Issue: Given a requirements partition-ing, how can analysis of the partitions beordered to enhance analysis?

Strategies for the ordered analysisof requirements partitions are rare.

A general software life-cycle strategy,

such as the spiral model, considers theriskiest partitions first [Boehm 1988].Specialized approaches consider cost-benefit analysis [Karlsson and Ryan1997; Cornford et al. 2000] or contention[Robinson and Pawlowski 1998]. How-ever, this research area seems largelyunexplored.

4.2. Interaction Identification

In Section 2.2 we introduced the term, re-quirements interaction, and its two sub-types, negative interaction and positive

interaction. Classifying interactions anddetecting conflicts have their own sets ofissues.

4.2.1. Classifying Interactions. A variety offields have contributed to a growing clas-sification of interaction types, particularly

AI and requirements engineering.

4.2.1.1. AI-Based Classifications.AI plan-ning concepts have introduced types suchas goal/subgoal decomposition. Goal con-flict itself is explained in terms of condi-tions, or resources, of operators that at-

tempt to achieve a goal; for example, goalsmay conflict because operators that satisfygoals individually have interfering pre-conditions when achieved simultaneously.Similarly, two requirements may conflictbecause they mutually deplete availablesystem resources. Many such planningterms have also been applied to charac-terize interactions among requirements[Potts 1994; Robinson 1989; Robinson and

Volkov 1996].

4.2.1.2. Requirements-Engineering-Based

Classifications. Table III summarizes themost general types of interactions found

in the requirements-engineering-relatedliterature: positive, negative, and unspec-ified.

A more refined analysis of the litera-ture reveals the basis of most interactions.Table IV summarizes these refined types,which include interactions over structure,resources, task, causality, and time.


8/11/2019 3 - 2003 - p132-n_robinson.pdf

19/59

150 Robinson et al.

Table IV. Basis of Requirements InteractionsType Description ExemplarStructure R1 is similar to R2. Duplicate, alternative [Chung et al. 1999]Resource R1 and R2 depend on the same resource. Resource utilization/contention [Yu and

Mylopoulos 1993]Task R1 describes a task required forR2. Subtask, means/ends, operationalization

[Dardenne et al. 1993; Yu and Mylopoulos1993]

Causality R1 describes a consequence ofR2. Results in Moffett [2000]Time R1 has a temporal relation to R2. Coincident state, simultaneity constraint,

pre/post time relation [Malone and Crowston1994]

Some researchers have found that adomain model based simply on posi-tive and negative types is a practi-cal solution [Boehm 1996; Chung et al.1995; Dardenne et al. 1993; Ramesh andDhar 1992; Yakemovic and Conklin 1990;Robinson and Pawlowski 1998]. Othershave extended such work to incorpo-rate fuzzy logic concerning the degree ofconflict [Yen and Tiao 1997]. In more re-cent work, fault-trees were the basis forclassifying interactions types. A fault tree,such as that concerning human-computer-interaction requirements [Maiden et al.1997], is viewed as an a priori enumera-tion of common negative interactions be-tween the software and its environment.In a similar fashion, a classification ofcommon interactions among functional[Klein 2000] and nonfunctional softwaredevelopment attributes can serve as thebasis for annotating how requirementsconflict [Boehm 1996]. Some researchershave considered interactions other thanconflict, such as the cost/benefit of require-ments [Karlsson and Ryan 1997; Cornfordet al. 2000].

4.2.2. Conflict Detection Methods. Zaveand Jackson [1993, p. 404] suggested thatpractical consistency checking will largelybe language dependent:

In theory, the consistency of a multiparadigmspecification could be investigated within predi-cate logic, after translating all partial specifica-tions into that form. In practice, this is obviouslyinfeasible. The logical formulas resulting fromthe translation are large and incomprehensible,and the complexity of a real specification in thatform would be farbeyond thecapacityof existingautomated tools.

We believe that most practical consistencychecking must be formulated at the same con-ceptual level as the specification languagesused,and that algorithms for consistency checkingwill be specialized for particular languages andstyles of decomposition. . . .

It is already common practice for researchersto work on analyzingand verifying specificationswithin particular application areas or writtenin particular languages, and they are beginningto work on verifying specifications of popularsystem architectures. We are not proposing anychange to this practice except the use of a smallset of complementary languages instead of onelanguage, which should make the overall goaleasier to achieve.

The authors show how features commonto different specification languages canguide the translation of a multiparadigmspecification into a logic for consistency

checking [Zave and Jackson 1996]; othershave done similar work [Ainsworth et al.1996; Niskier et al. 1989; Nuseibeh et al.1994]. Delugach [1992, 1996] translatedspecifications into conceptual graphs fordetection. Rather than rely on a commonsemantic domain, Fiadeiro and Maibaum[1995] used category theory to detect in-consistencies among multiparadigm spec-ifications. Still, many current interaction-detection techniques rely on certainfeatures of the specification language.

Table V summarizes five categories ofmethods for evaluating requirements for

possible interactions. All the methods ad-dress the following issue:

Issue:What kinds of analyses can be ap-plied to requirements to uncover require-ments interactions?

4.2.2.1. Classification-Based.A generalclassification can help in identifying


8/11/2019 3 - 2003 - p132-n_robinson.pdf

20/59


Table V. Interaction Detection MethodsMethod Description ExampleClassification-

basedRequirements interactions are

found and classified bycomparing requirementsagainst an a priori model ofrequirements interactions.

WinWin [Boehm 1996], NFR[Mylopoulos et al. 1992],CDE [Klein 1991]

Patterns-based Requirements are compared withdetection pattern conditions. Aninteraction is found when thereis a match. Resolution patternsderive resolutions in a similarmanner.

KAOS [van Lamsweerdeand Letier 2000]

AI planning Requirements interactions andresolutions are found throughplanning. Requirements arerepresented as goals, whileoperations are represented asplanning operators.

DDR (Oz) [Robinson 1993],KAOS [van Lamsweerdeand Letier 2000]

Scenarioanalysis

Requirements interactions aredemonstrated by simulating asequence of events thatrepresents a narrow aspect of asystems required behavior.

SCR [Heninger 1980],CREWS-SAVRE [Maiden,1998; Sutcliffe et al. 1998]

Formal methods Requirements interactions arefound by algorithmicverification (SPIN, SMV),deductive verification (PVS,HOL), and language-specificverification (SCR, RSML).

SPIN [Holzmann 1997], SMV[McMillan 1992], PVS[Crow et al. 1995; Owreet al. 1995], HOL[Gordon and Melham1993], SCR [Heninger1980], RSML [Levesonet al. 1994]

RuntimeMonitoring

Requirements interactions arefound by monitoring a systemexecution for certain events thatindicate violations ofrequirements specifications.

FLEA [Feather 1997;Feather et al. 1998]

requirements interactions. Classificationcaptures commonly occurring interactionsamong requirements and environmentfeatures [Fox et al. 1996; Gruninger andFox 1995; Olsen et al. 1994; Storey et al.1997]. A hierarchy of suchbinary interac-tions typically defines the classification.Most work on nonfunctional interactionsuses such binary interactions to indicateinteractions [Boehm 1996; Chung et al.1995; Dardenne et al. 1993; Ramesh andDhar 1992; Robinson and Pawlowski

1998].Classification-based interaction detec-

tion proceeds in three phases: (1) classifyrequirements according to the interactionclassification, (2) instantiate the associ-ated general interactions from the clas-sification, and (3) infer requirements in-teractions from the instantiated domain

interactions. Detection can be automated[Spanoudakis and Constantopoulos 1996],and the analysis of even five simple in-teraction types yields significant benefits[Robinson and Pawlowski 1998].

The following definition relates infor-mation accuracy and the effort required toprovide such information:

DomainDef AccuracyIncreasesEffortInformalDef

Accurate information in-creases effort of information provi-ders.

Now, consider two nonfunctional re-quirements R1 and R2 belonging to theAccuracy and Effort categories, respec-tively. The interaction model may indicatea negative interaction, which implies that


8/11/2019 3 - 2003 - p132-n_robinson.pdf

21/59

152 Robinson et al.

R1andR2 might interact negatively. Thisis summarized in the following rule:

AnalysisDef DetectNonFunctionalNegativeInteraction

InformalDefIf two requirements belong

to nonfunctional categories that theinteraction model says are negati-vely interacting then the two requi-rements might be interacting negati-vely.

An analogous rule holds for positive in-teractions.

As an example, consider theSchedulerShallNotIncreaseParticipantEffort re-quirement of Section 2.3.3, along with

the following ParticipantAccurateConstraintsrequirement.

Requirement ParticipantAccurateConstraints


A meeting particpantsconstraints shall be accurate.

SchedulerShallNotIncreaseParticipantEffort references Effortwhile Participant AccurateConstraintsreferences Accuracy. DetectNonFunctionalNegativeInteraction instan-

tiates AccuracyIncreasesEffort alongwith the two requirements to infer thatrequiring accurate participant constraintswill increase participant effort.

WinWin is probably the best knownrequirements tool that uses a classifica-tion of binary interactions to notify stake-holders of new requirements interactions[Boehm 1996; Egyed and Boehm 1996].(See Section 5.)

4.2.2.2. Patterns-Based. An interactionclassification of binary interactions canlead to wrong inferences about interac-tions. Accurate information (ParticipantAccurateConstraints) will not alwaysincrease participant scheduling effort(SchedulerShallNotIncreaseParticipantEffort), for example. Computerized selec-tion and scheduling of a meeting room candecreasethe effort of meeting participantsas well as increase schedule informationaccuracy, which implies an increase in

participant effort as they maintain theiron-line information. Thus, a classifica-tion of binary interactions is simple to

construct but, if not precise, can lead towrong conclusions.

A more precise analysis is possible withinteraction patterns. Such patterns havepre- and postconditions that constraintheir use and the conclusions they draw.Consider the following simple interactionpattern:

An activity performed by a software agent thatproduces information used by a human agent de-creases the human agents effort.

This pattern provides more conditionsof use than binary patterns of the formX increases Y. Consequently, few wronginferences will be drawn. Of course,a multiplicity of patterns leads to thesame problem of inconsistency that oc-curred with binary interaction classifica-tion. In this case, however, because thepatterns are precise, the problem is not assevere.

The KAOS project defines formal pat-terns [van Lamsweerde et al. 1998].The Critic specification tool [Fickas andNagarajan 1988] and Kleins concurrentrequirements analysis tool (CDE; [Klein[1991]) and his Conflict Detection Sectionof the MIT Process Handbook [Klein 2000]use interaction patterns to detect conflicts.

4.2.2.3. AI Planning. It is possible toautomatically compare requirements andclassify their interaction type. Given op-erational requirements, program slicingtechniques [Horwitz et al. 1989; Yang et al.1992] can highlight semantic differencesin versions of a common root specification[Heimdahl and Whalen 1997]. For require-ments represented as nonoperational sys-tems goals, planning techniques aid in de-riving a plan for the conjunction of the

requirements set:

(1) If the planner finds a plan in a givenoperator set, then requirements can beachieved simultaneously.

(2) Ifit fails to find a plan, analysts can usegoal regression to find the reason forthe requirements conflict [Fickas and


8/11/2019 3 - 2003 - p132-n_robinson.pdf

22/59


Anderson 1989; Robinson 1993, 1994;van Lamsweerde and Letier 2000].

Finally, a set of requirements can suc-ceed and fail in the same environment.Analysts can check for this by planningfor the conjunction of some requirementswith the negation of others; if such aplan succeeds, then the requirements canfail in the way the plan demonstrates[Fickas and Anderson 1989].Of course, theoperations and other environmental re-sources must first be formalized for somepart of the system environment [Fickasand Anderson 1989]. Such a planning ap-proach to goal interaction is also suit-able for scenario analysis: requirements

become plan goals and the plan opera-tors become the scenario actions. Analystsgenerate scenarios by considering a vari-ety of plan failures, such as preconditionfailure via resource depletion [Fickas and

Anderson 1989; Maiden et al. 1997]. Dis-tributed AI research also uses such inter-action detection [Gasser and Huhns 1989;

Velthuijsen 1993; von Martial 1992].

4.2.2.4. ScenarioAnalysis. Van Lamsweerdeand Willemet [1998, p. 1089] defined a sce-nario as follows:

A temporal sequence of interaction events

among different agents in the restricted contextof achieving some implicit purpose(s). . . . A sce-nario captures just one particular, fragmentaryinstance of behavior of a system.

Because scenarios represent system ex-ecution fragments, analysts can evaluatetheir outcome relative to requirements.Positive scenarios satisfy requirements,while negative scenarios violate them. Ascenario that is both positive and neg-ative still violates certain requirements,and thus shows a negative interaction.

In scenario analysis, the analyst selectsa subset of requirements to be analyzed

and then identifies a particular scenarioto determine if the selected requirementscan be satisfied. If the analyst finds nosuch scenario, he or she has in effectdiscovered a negative interaction. Fortemporal logic requirements and state-based scenarios, model checking tools canautomate scenario analysis [McMillan

1992; Holzmann 1997]. Alternatively, aknowledge-based approach can suggestscenarios that are likely to generate

requirements interactions [Maiden 1998].Finally, scenario-based advice can bedistilled into checklists or fault-trees asa way to uncover interactions manually[Leveson 1995].

4.2.2.5. Formal Methods. Formal meth-ods are used for a variety of purposesin analyzing specifications, according tovan Lamsweerde and Jetier 2000] (cf[Heitmeyer and Mandrioli [1996]):

to confirm that an operational specifi-cation satisfies more abstract specifica-

tions, or to generate behavioral coun-terexamples if not, through algorithmicmodel checking techniques [Queille andSifakis 1982; Clarke and Emerson 1986;Holzman 1991, 1997; McMillan 1993;

Atlee 1993; Manna and Group 1996;Heitmeyer et al. 1998b; Clarke et al.1999];

to generate counterexamples to claimsabout a declarative specification[Jackson and Damon 1996];

to generate concrete scenarios illustrat-ing desired or undesired features aboutthe specification [Fickas and Helm

1992; Hall 1995, 1998] or, conversely, toinfer the specification inductively fromsuch scenarios [van Lamsweerde andWillemet 1988];

to produce animations of the specifi-cation in order to check its adequacy[Hekmatpour and Ince 1988; Harel et al.1990; Dubois et al. 1993; Douglas andKemmerer 1994; Heitmeyer et al. 1996;Thompson et al. 1999];

to check specific forms of specifi-cation consistency/completeness effi-ciently [Heimdahl and Leveson 1996;

Heitmeyer et al. 1996];to generate high-level exceptions and

conflict preconditions that may makethe specification unsatisfiable [vanLamsweerde et al. 1998; van Lam-sweerde and Letier 2000];

to generate higher-level specificationssuch as invariants or conditions for


8/11/2019 3 - 2003 - p132-n_robinson.pdf

23/59

154 Robinson et al.

liveness [Lamsweerde and Sintzoff1979; Bensalem et al. 1996; Park et al.1998; Jeffords and Heitmeyer 1998];

to drive refinements of the specificationand generate proof obligations [Morgan1990; Abrial 1996; Darimont and vanLamsweerde 1996];

to generate test cases and oracles fromthe specification [Bernot et al. 1991;Richardson et al. 1992; Roong-Ko andFrankl 1994; Weyuker et al. 1994;Mandrioli et al. 1995];

to support formal reuse of componentsthrough specification matching [Katzet al. 1987; Reubenstein and Waters1991; Massonet and van Lamsweerde1997; Zaremski and Wing 1997].

Many of the preceding methods supportof conflict detection, as well as other RIMactivities. The SCR tool kit, for example,finds missing, ambiguous, and erroneousrequirements [Bharadwaj and Heitmeyer1997; Heitmeyer et al. 1996; Schneideret al. 1998]; see Section 5.6. Using theKAOS approach, an analyst can uncoverconflicts among requirements or betweenrequirements and the environment; seeSection 5.4.

4.2.2.6. Runtime Monitoring. Runtimemonitoring tracks the systems runtimebehavior for any deviations from the re-quirements specification. Requirementsmonitoring is useful when verifying sys-tem properties is too difficult, whenresolving noncritical conflicts during spec-ification may be too costly or lead to un-necessary restrictions, when assumptionsmade about the environment are evolv-ing, or when specific dispositions must bedeployed for specific use modes. Duringrequirements definition, developers inte-grate certain assumptions, which analysts

then monitor at runtime. Should the as-sumptions fail, monitoring invokes a pre-defined procedure, such as to notify the de-signer. Monitoring differs from exceptionhandling in three ways: (1) it considers thecombined behavior of events that occur inmultiple threads or processes; (2) it linksruntime behavior with the actual design-

time requirements; (3) it provides enoughinformation for developers to reconfigurethe software or software components at

runtime.Fickas and Feather [1995] proposed re-

quirements monitoring that tracks theachievement of requirements at runtimeas part of an architecture that lets de-velopers reconfigure component softwaredynamically. Feathers working system,called FLEA (for Formal Language forExpressing Assumptions Language De-scription), lets developers monitor eventsdefined in a requirements monitoring lan-guage [Feather et al. 1997, 1998]. Con-structs in the language are mapped to trig-gers in a specialized database. As FLEA

records interesting events in the database,the database triggers provide alerts whenrequirements fail.

Fickas and Feather [1995] illustratedruntime requirements monitoring for asoftware license server. When the licenseserver fails to satisfy its requirements(e.g., a user shall be granted a license in90% of their requests) because of a changein the system environment, the systemnotifies an administrator. As a follow-on,Robinsons [2002] ReqMon demonstratedthe use of assertion checking to link run-time monitors to requirements.

Expectation agents monitor the systemsactual use [Girgensohn et al. 1994]. Devel-opers define software user expectations,such as, validate the customer addressbefore configuring the customers ser-vices. Agents then monitor the systemsuse and when it does not match the definedexpectations, agents perform the follow-ing actions: notify developers of the dis-crepancy, provide users with an explana-tion based on developers rationale, and/orsolicit a response to or comment aboutthe expectation [Girgensohn et al. 1994].Thus, in one sense, expectation agents

monitor the satisfaction of developer ex-pectations.

4.3. Interaction Focus

Issue:Given a number of requirements in-teractions, how can the interactions be par-titioned to enhance the analysis?


8/11/2019 3 - 2003 - p132-n_robinson.pdf

24/59


Some requirements interactions dependon other requirements interactions. Forexample, the resolution of one conflict may

introduce new conflicts into the require-ments set; conversely, one resolution mayremove multiple conflicts.

Efficient resolution focuses on key in-teractions. A necessary first step in gener-ating a resolution is to partition or orderinteractions for consideration. In general,any such ordering should aim first to de-crease overall conflict and minimize re-work. Robinson has ordered requirementsby their degree of contentiousnessthepercentage of conflicting interactions thata particular requirement has among allrequirements [Robinson and Pawlowski

1998]. Resolution generation then focuseson resolving conflicts among requirementswith the greatest total contention. Thisstrategy monotonically decreases the over-all conflict in a small requirements doc-ument [Robinson and Pawlowski 1998],but it considers only conflict dependencies,not factors such as the importance of therequirements. Less contentious require-ments may be a priority because the sys-tem must achieve them exactly as stated(no negotiation). In that case, the focuswould be on conflicts that involve require-ments with the greatest total importance.

However, with an importance focus, reso-lution generation considers relatively fewrequirements. Thus, resolutions may bemyopic. For example, in a limited-resourceenvironment, assigning all resources toimportant requirements solves the im-portant conflicts, but can introduce newconflicts, as some requirements cannot besatisfied. Thus, analysts must weigh a re-quirements importance in the context ofits implications for other requirements.Research into cost-value tradeoffs of re-quirements aims to assist this activity[Karlsson and Ryan 1997; Cornford et al.

2000].Techniques for partitioning a large set

of requirements are also effective in par-titioning requirements interactions. (SeeSection 4.1.) Here, the focus is on allinteractions in a particular partition:stakeholder, scenario, requirements sub-

sumption hierarchy, and so on. In fact,decision science suggests that individu-als can maximize their own benefit by

first understanding and specifying theirown preferences before negotiating withothers [Zeleny 1982]. This suggests usingstakeholder partitioning to resolve par-tition conflicts within a partition beforeattempting to resolve them among par-titions. Moreover, the negotiation litera-ture suggests that, in social contexts, re-solving the simplest conflicts first buildstrust among the negotiating participants[Pruitt 1981].

4.4. Resolution Generation

Issue: Given requirements interactions,how can resolutions be generated?

Conflict resolution can be characterizedas a multiple goal-planning problem:given goal sets G1 and G2 held by agentsA1 and A2, respectively, the resolutionactivity attempts to find a combinedgoal set similar to {G1, G2} that thesystem can achieve without conflict.Resolution is commonly characterized asa tupleagents, goals, environmentin which multiple agents seek to achievegoals within an environment, and the

environment specifies available op-erators, resources, and other domainconstraints.

Several approaches have successfullyautomated conflict resolution [Robinsonand Volkov 1998]. Table VI summa-rizes six categories of conflict-resolutionmethods described in the requirements-engineering literature. We derived the sixcategories from approximately 29 meth-ods, 11 of which we identified as unique.(Table IX summarizes projects that usethese methods.)

The compromise method in Table VI

is an example of a value-oriented ap-proach to conflict resolution. The methodsearches for alternative goals (or goalvalues) to find nonconflicting substitutegoals (or goal values). If the substitutegoals are ordered, lexicographical order-ing [Zeleny 1982] (to find less desirable


8/11/2019 3 - 2003 - p132-n_robinson.pdf

25/59

156 Robinson et al.

Table VI. Conflict Resolution MethodsMethod DescriptionRelaxation:

generalization,value-rangeextension

Conflicting requirements are relaxed to expand the range of mutually satisfactoryoptions beyond what the original requirements specify.

Generalization involves replacing the conflicting concept with a more generalconcept. Value-range extension changes the range of values acceptable to thestakeholders.

Refinementspecialization

Conflicting requirements are decomposed into specialized requirements, some ofwhich can be satisfied.

Compromise Given a conflict over a value within a domain of values, compromise finds anothersubstitute value from that domain.

Restructuring:reenforcement,replanning

Restructuring methods attempt to change the conflict context; they alterassumptions and related requirements in addition to the conflictingrequirements.

Restructuring attempts to reduce constraining interactions and allow a widerrange of resolution options.

Reenforcement is a restructuring that ensures a precondition is satisfied.Replanning is the selection of an alternative set of requirements in order toachieve a subordinate requirement.

Other:postponement,abandonment

Conflict resolution can be postponed. In complex interactions, many conflicts andrequirements are interrelated. By postponing a conflict and resolving otherconflicts, the postponed conflict might cease to exist. Alternatively, conflic

3 - 2003 - p132-n_robinson.pdf

Documents

Transcript of 3 - 2003 - p132-n_robinson.pdf