A Measurement-Driven Process Model For Managing Inconsistent SoftwareRequirements

Kedian MuSchool of Mathematical Sciences, Peking University, Beijing 100871, P. R. China

Zhi JinSchool of Electronics Engineering and Computer Science, Peking University

Key Laboratory of High Confidence Software Technologies, Ministry of EducationBeijing 100871, P. R. China

Didar ZowghiFaculty of Engineering and Information Technology

University of Technology, Sydney, NSW2007, Australia

Abstract

Inconsistency is a pervasive issue in software engineer-ing. Both general rules of inconsistency management andspecial case-based approaches to handling inconsistencyhave recently been considered. In this paper, we presenta process model for handling requirements inconsistencywithin the Viewpoints framework. In this process model,when an inconsistency among viewpoints is detected, a setof candidate proposals for handling inconsistency will begenerated using techniques from Multi-agent automated ne-gotiations. The proposals are then prioritized using an inte-grated measurement of inconsistencies. The viewpoints in-volved in the inconsistency will then enter the negotiationsby being presented with the candidate proposals and thusselecting an acceptable proposal based on the priorities as-sociated with each candidate proposal. To facilitate usabil-ity, in our process, we assume that the natural language re-quirements statements are first translated into correspond-ing logical formulas using a translator software. Moreover,the candidate proposals for handling inconsistency are alsotranslated back from formal logic into natural language be-fore being presented for selection.

Keywords: Inconsistency handling, automated negotia-tion, measure of inconsistency.

1. Introduction

Support for evolutionary processes is needed at all stagesof software development but especially during Require-ments Engineering (RE), since it is the requirements modifi-

cations that typically triggers other changes in the develop-ment life cycle. Requirements often evolve because stake-holders cannot possibly envision all the ways in which asystem can be utilized. The environment where the soft-ware is situated frequently changes and so do the softwareboundaries and business rules governing the utilization ofthat software. Correspondingly, designs change because therequirements change. Implementation has to be changedbecause designs evolve and defects have to be fixed.

Software Requirements Specification (SRS) plays an im-portant role in the development process because it providesa baseline for the development of all the subsequent artifactssuch as design, code and test cases. Eliciting and document-ing high quality requirements as well as an effective andefficient management of requirements process are consid-ered crucial for software development projects. This state-ment is supported by claims in the literature that ineffectiverequirements management is identified as a major sourceof problems [9] and that errors made during requirementsstage account for 40-60% of all defects found in softwareprojects [13]. It is generally accepted that it is much moreexpensive to correct these types of errors if they are left un-detected and leaked into the subsequent phases of softwaredevelopment projects.

One of the main classes of defects in requirements speci-fications is that of inconsistency. Inconsistency occurs whena specification contains conflicting, contradictory descrip-tions of the expected behavior of the system. Such contra-dictory descriptions could be attributed to conflicting goalsbetween the various participants that contribute to the de-velopment of the specification, namely the stakeholders. In-consistencies could also result from uncoordinated changes

2008 15th Asia-Pacific Software Engineering Conference

1530-1362/08 $25.00 © 2008 IEEE

DOI 10.1109/APSEC.2008.24

291

introduced in the specification during the usual evolution ofthe requirements.

Inconsistency is considered as a serious problem and amajor source of risk that permeates all aspects of softwaredevelopment. It makes it very hard to design and implementa system that fully satisfies its specification. In some cases,the programmer may arbitrarily resolve inconsistencies dur-ing the implementation of the system. This means that oneof the conflicting requirements will be preferred over theothers, usually without performing an in-depth analysis ofthe consequences, and without notifying the relevant stake-holders. In worst-case scenarios, undetected inconsistencymay lead to incorrect and unreliable systems, whose faultsare only discovered after deployment when it is too late.

In requirements elicitation, it is often advocated to con-sult all relevant stakeholders so that each can express his/herown needs for the system under construction. In viewpoint-based approaches to RE [2, 5, 11], it is recognized that allthe necessary requirements information cannot be elicitedby viewing the system from a single perspective and that re-quirements have to be gathered and organized from a num-ber of different viewpoints. A viewpoint is an encapsulation(from a certain perspective), of partial information abouta system’s requirements. Information from different view-points then has to be integrated into the final product of RE,the SRS.

Inconsistency has been recognized as one of the impor-tant issues in the Viewpoints framework[4, 8]. Handlinginconsistency arising in overlapped viewpoints is not justa technical issue. It is also associated with a process ofnegotiation over actions of inconsistency handling betweenrelated stakeholders. For each stakeholder, many factors,e.g., his/her expected benefits from the system-to-be, rel-ative value of each requirement, cost of implementation,and subjective preference and so on will have influence onhis trade-off decision on inconsistency handling. It is noteasy to persuade stakeholders to change their needs thathave been expressed. Moreover, lack of appropriate prin-ciples for evaluating negotiation proposals prevents partici-pants from reaching a reasonable agreement. Thus, the finalproposal could often become an unsuccessful compromisebetween stakeholders.

If a proposal for inconsistency handling is acceptable to aparticular viewpoint, then acceptance of the proposal shouldintuitively result in decreasing the degree and significanceof inconsistency in overlapped viewpoints from the perspec-tive of the viewpoint. Previously [14], we have argued thatthe relative importance of requirements with regard to theviewpoint always affects the evaluation of significance ofinconsistent viewpoints. Therefore, the appropriate princi-ples for evaluating proposals of negotiation over inconsis-tent viewpoints should also take the priority of requirementsstatement into account.

Generally speaking, inconsistency management may bedivided into two parts, i.e. consistency checking and in-consistency handling. Consistency checking focuses ontechniques for detecting inconsistencies in a set of require-ments. Typical techniques include logic-based approaches[7, 8, 21] and consistency-rule-based approaches [15, 17].For logic-based approaches, the term inconsistency is re-ferred to as the logical contradiction. Detecting this type ofinconsistency entails that the SRS should be represented informal notation such as logic. Writing and analyzing a spec-ification in formal logic requires very specialized knowl-edge and expertise. Often, such expertise is not readilyavailable, and this contributes to the limited use of formalspecification languages in software industry. Translationbetween formal and informal languages is thus needed ifwe are to benefit from the power of formal logic in man-agement of inconsistencies in requirements specificationsand make automated inconsistency management accessibleto requirements engineers.

“Inconsistency Implies Actions” is recognized as a meta-rule for inconsistency handling [6, 8]. That is, when incon-sistencies are detected, some actions should be performedto manage these inconsistencies. However, identifying ap-propriate actions still remains a difficult, but important chal-lenge [8] in software development. The choice of an incon-sistency handling action always depends on the nature andcontext of these inconsistencies [6, 4]. Thus it is difficult toprovide a universal approach to handling all types of incon-sistencies in requirements engineering.

In this paper we build upon our previous work [14] onan integrated measurement-driven approach to handling in-consistency in Viewpoints framework. Firstly, we presentour framework for handling inconsistency among multipleviewpoints using an integrated measurement of inconsisten-cies that combines the notions of degree and significance ofinconsistencies. When an inconsistency among viewpointsis detected, a set of candidate proposals for handling this in-consistency will be generated using techniques from Multi-agent automated negotiations. The viewpoints involved inthe inconsistency will then enter the negotiation by beingpresented with the candidate proposals and thus selectingan acceptable proposal based on the priorities of each can-didate proposal.

In our recognition of the need for a software tool thatcan fully automate the process of detection and handling ofrequirements inconsistencies in an evolutionary viewpointsframework, and motivated by our desire to make this toolaccessible to any requirements engineer, we thus proposea process model for the management of requirements in-consistencies. This process model will also include the de-tails of generating a set of candidate proposals for handlinginconsistency and identifying an acceptable common pro-posal. Our proposed process model will envisage the use of

292

a translator application (e.g. Carl in [7]), that would allowrequirements engineers interact in natural language with anautomated inconsistency handler application.

This paper is organized as follows. Section 2 presents ameasurement-driven process model for managing require-ments inconsistencies. Section 3 gives some preliminar-ies for formulating this process model. Section 4 describescomponents of the process model. Section 5 gives a casestudy to illustrate the use of the process model during therequirements stage. Section 6 compares our process modeland related works. Finally, we conclude the paper in section7.

2. A Process Model for Handling Require-ments Inconsistencies

We propose a measurement-driven process for manag-ing requirements inconsistencies, as shown in figure 1. Itshould be noted that this process model is intrinsically aniterative and evolutionary model for arriving at a consistentsoftware requirements specifications. The process beginswhen a requirements analyst aims to develop an SRS (pos-sibly from an empty set of requirements initially), by addingnew requirements statements to SRS or by deleting an ex-isting requirements from the SRS (assuming that SRS is notempty). Adding or deleting individual requirements to andfrom SRS may create inconsistencies in the resulting set asdiscussed in [6]. Thus in figure 1 the user on the left handside could be interpreted as either an analyst or as any stake-holder with a viewpoint.

The input and the output of this process model are re-quirements in natural language with priority and the consis-tent requirements specification respectively. The activitiesin this process model are described as follows:

• requirements translation: translates the requirements writ-ten in natural language (together with their correspondingpriorities), submitted by the stakeholders (or the analyst) intoformal logic.

• specification revision: revises the requirement set into anordered requirement specification. This activity initially rep-resents adding new requirements statements (represented inlogic), to the SRS. In subsequent iteration of the process,it represents the action of revision carried out in modifyingthe SRS based on the selected proposal by the stakeholder.These actions could be any combination of adding and/ordeleting individual requirements from the SRS in order tomaintain consistency.

• inconsistency management: the inconsistency managerconsists of two independent yet related activities. First is theinconsistency detector and the other is the inconsistencymeasurer. The detector is designed for detecting the incon-sistency in requirements specification. We can use a range

Figure 1. A Process Model for Handling Re-quirements Inconsistencies

of existing tools for this purpose such as model checkers ortheorem provers. Once inconsistent requirements statementsare detected, a minimum inconsistent set is determined andthis triggers the measurement of the degree of inconsistencyto be calculated. After measurement, an integrated measureof inconsistency will be obtained. If no inconsistency canbe detected, then a consistent software requirement specifi-cation can be obtained and returned to the stakeholders

• negotiation: the negotiation mechanism is designed to gen-erate the proposals from each individual viewpoint for re-solving the inconsistencies in the minimum inconsistent set.A group decision maker is also provided for getting a sortedlist of proposals by adopting some priority-based strategiesas described in section 4.2.

• proposal translation: translates the proposals into naturallanguage sentences so that the stakeholder can understandthem and be able to make a choice from the presented pro-posals based on the measurement of inconsistency.

293

It should be noted that among the collection of activitiesmaking up the proposed process model, the inconsistencymanagement (consisting of detection and measurement ofinconsistency), and the automated negotiation are the twokey activities and novel in this process. The other activi-ties such as translation are just included for enhancing thecommunication with the stakeholders.

3. Preliminaries for Formulating the Process

The principle of heterogeneity of representation al-lows different viewpoints use different notations and toolsto represent their requirements during the requirementsstage [16]. However, classical logic is appealing for for-mal representation of requirements [8]. Moreover, in logic-based framework for representing requirements, reasoningabout requirements is always based on some facts that de-scribe a certain scenario [8]. That implies that checkingconsistency of requirements collections considers groundformulas rather than unground formulas. These reasonsmake the classical logic the most convenient to illustrateour approach, as will be shown in the rest of the paper.

Let LΦ0 be the language composed from a set of classicalatoms Φ0 and logical connectives {∨,∧,¬,→} and let �be the classical consequence relation. Let α ∈ LΦ0 be aclassical formula and Δ ⊆ LΦ0 a set of formulas in LΦ0 .In this paper, we call Δ a set of requirements while eachformula α ∈ Δ represents a requirements statement.

Let V = {v1, v2, · · · , vn} be a set of viewpoints. Foreach i (1 ≤ i ≤ n), Δi is a set of requirements of vi. Gen-erally, the requirements specification could be representedby a n tuple 〈Δ1, · · · , Δn〉.

The term of inconsistency has different definitions in re-quirements engineering [21]. Most logic-based works suchas [8, 21, 7] concentrated on a particular kind of inconsis-tency, i.e. the logical contradiction: any situation in whichsome fact α and its negation ¬α can be simultaneously de-rived from the same set of requirements. In this paper, weshall be also concerned with the logical contradiction. Ifthere is a formula α such that Δ � α and Δ � ¬α, then weconsider Δ to be inconsistent and abbreviate α ∧ ¬α by ⊥.

It has been recognized that the relative priority of re-quirements can help stakeholders resolve conflicts andmake some necessary trade-off decisions [19, 3]. A com-mon approach to prioritizing requirements specification isto group requirements into several priority categories, suchas the most popular three-level scale of {High, Medium,Low} [19] and the IEEE recommended scale of {Essential,Conditional, Optional} [10].

Let m, a natural number, be the scale of the priority andL be {l0, · · · , lm−1}, a totally ordered finite set of m sym-bolic values of the priorities, i.e. li < lj iff i < j. Further-more, each symbolic value in L could associate with a lin-

guistic value. For example, we have a totally ordered set Las L = {l0, l1, l2} where l0 : Low, l1 : Medium, l2 : High.For example, if we assign l2 to a requirements statement α,it means that α is one of the most important requirementsstatements. Prioritization over Δi is in essence to establisha prioritization function Pi : Δi → L by balancing thebusiness value of each requirements statement against itscost and technique risk. Then in the Viewpoints framework,the requirements specification with preference may be rep-resented by 〈(Δ1, P1), · · · , (Δn, Pn)〉, where Pi is the pri-oritization function of viewpoint vi.

We consider each individual viewpoint as a negotiationparticipant during the process of inconsistency handling.And assume that they are negotiating over a finite set Ω ofpossible modifications of requirements (which is referred toas outcomes in [20]).

Negotiation proceeds in a series of rounds, where at eachround, every participant presents a proposal which is a sub-set of Ω. And it is assumed that any proposal is acceptableto the offerer. As we use the classical logic-based negotia-tion language L proposed in [20], the proposal made by aparticipant at each round is a formula of L. Then each roundcould be described by a tuple 〈ϕ1, · · · , ϕn〉, where ϕi is theproposal presented by participant i [20]. A negotiation his-tory is a finite sequence of rounds. Let ϕk

i be the proposalmade by participant i in the kth round, then a negotiationhistory could be viewed as the following matrix of formulasof L [20]:

ϕ01 ϕ1

1 · · · ϕm1

......

. . ....

ϕ0n ϕ1

n · · · ϕmn .

In this paper, we use the combination of the two aboveagreement conditions mentioned in [20], that is, the agree-ment will be reached if and only if (ϕm

1 ∧· · ·∧ϕmn )∧(ϕm

1 ⇔· · · ⇔ ϕm

n ) is satisfiable. This agreement condition guaran-tees that if an agreement is reached in negotiation over in-consistency handling, then all the viewpoints involved willundertake a feasible global proposal of inconsistency han-dling and they should agree on the meanings of the pro-posal.

4. Components of Tool Set

We discuss components of tool set for supporting ap-plication of the process model to requirements engineeringpractice. A translator, an inconsistency manager, and a ne-gotiation controller may be considered as the most impor-tant components of the process. As mentioned earlier, theprocess model would allow requirements engineers interactin natural language with an automated inconsistency han-dler. Consequently, a translator for mapping requirements

294

in natural language into logic formulas (e.g. Carl in [7])would be built in the process. In this paper, we focus on theinconsistency manager and the negotiation controller.

4.1. Inconsistency manager

The inconsistency manager consists of an inconsistencydetector and an inconsistency measurer.

Inconsistency detector. An inconsistency detector is de-signed to detect inconsistencies in a set of requirements.Generally, most logic-based approaches [8, 21, 7] designsome paraconsistent logics to represent the requirements,moreover, reasoning engine is considered as inconsistencydetector. In contrast, consistency rules base plays an impor-tant role in consistency rule-based approaches. In this pa-per, the term of inconsistency is defined as the logical con-tradictions. Consequently, inconsistency detector should bea type of paraconsistent reasoning engine.

Inconsistency Measurer. Inconsistency measurer playsan important role during the process for handling inconsis-tent requirements. The degree and the significance of in-consistency are two essential aspects for articulating an in-dividual inconsistent requirements set. The degree of incon-sistency describes how inconsistent a set of requirements is,whilst the significance of inconsistency measures how im-portant the inconsistency of a requirements set is. Then theymay be viewed as two distinct dimensions of measurementof an inconsistency.

• Degree of inconsistency. Suppose that Δ is a set of require-ments. Let

MI(Δ) = {Φ ⊆ Δ|Φ � ⊥,∀φ ∈ Φ, Φ − {φ} �� ⊥},CORE(Δ) =

⋃

Φ∈MI(Δ)

Φ.

Note that MI(Δ) is the set of minimal inconsistent subsets ofΔ; and CORE(Δ) is the union of all its minimal inconsistentsubsets of Δ. For any set of requirements, we consider theunion of all its minimal inconsistent subsets as the collectionof all the problematical requirements.

Hunter’s approach [1] to measuring the degree of inconsis-tency of a formulas set captures contribution of each subsetto the inconsistency. Given Δ, a scoring function S is de-fined from P(Δ) (the power set of Δ) into the natural num-bers so that for any Γ ∈ P(Δ), S(Γ) gives the number ofminimal inconsistent subsets of Δ that would be eliminatedif the subset Γ was removed from Δ [1]. That is, for Γ ⊆ Δ,

S(Γ) = |MI(Δ)| − |MI(Δ − Γ)|.

As such, sets of formulas could be compared using theirscoring functions so that an ordering relation, which means

“more inconsistent than”, over these sets can be defined [1].That is, assume that Γ1 and Γ2 are of the same cardinal-ity, S1 is the scoring function for Γ1, and S2 the scoringfunction for Γ2. S1 ≤ S2 holds iff there is a bijectionf : P(Γ1) →P(Γ2) such that the following condition canbe satisfied: ∀Θ ∈ P(Γ1), S1(Θ) ≤ S2(f(Θ)). We say Γ2

is more inconsistent than Γ1 iff S1 ≤ S2.

• Significance of inconsistency. Intuitively, the significanceof an inconsistency depends on the relative importance of re-quirements statements involved in the inconsistency. In ourprevious paper [14], we provided the following intuitive as-sumptions about significance of a requirements set in a givenviewpoint:

– the requirements statements with the same priorityhave the same significance;

– any requirements statement with a higher priority ismore significant than all of those with lower priorities;

– those requirements statements with higher prioritiesplay dominant roles in measuring the significance ofa requirements set.

Then given a requirements set Γ in viewpoint vi, we use thepriority-based cardinality vector, denoted

−→C i(Γ), to mea-

sure the significane of Γ with regard to vi, where−→C i(Γ) =

(|Γ0|, · · · , |Γm−1|), and for each k, Γk = {γ ∈ Γ, Pi(γ) =lk} [14]. Informally, vector

−→C i(Γ) provides the number of

requirements with each priority level as well as the prefer-ences of vi. In this sense, it gives a measure of priority-basedsignificance of Δ from the perspective of vi. Moreover, in agiven viewpoint, the sets of requirements of the viewpointscould be compared using the lexicographical vector orderingrelation �P provided in [14].

Based on the cardinality vector ordering, we can comparetwo minimal inconsistent subsets in the sense of significancewith regard to vi using their cardinality vectors:

– For any Φ1, Φ2 ∈ MI(Δ), if−→C i(Φ1) �P

−→C i(Φ2),

then Φ2 is more significant than Φ1 with regard to vi.

4.2. Negotiation Controller

Based on the measurement of a given inconsistency, eachviewpoint involved in the inconsistency need to provide atleast one proposal for handling the inconsistency from itsown perspective. Also, all the viewpoints involved in theinconsistency need to reach an agreement on the final pro-posal for handling the inconsistency. Measurement of in-consistency provides support for putting forward a desir-able proposal for handling inconsistency as well as reach-ing a successful compromise among viewpoints. Negotia-tion controller will simulate the behavior of viewpoints(orstakeholders) during this stage. It consists of proposal gen-erators and an automated group decision maker.

295

• Proposal Generators. For each viewpoint, the correspond-ing proposal generator is responsible for providing appropri-ate proposals from its own perspective during the negotiationprocess. Just for convenience, we focus our attention on ne-gotiation between two viewpoints in this paper. The negotia-tion among multiple viewpoints could be discussed based onnegotiation in multi-agents system in the way similar to thatpresented in this paper. Let Δi,j = Δi ∪ Δj , 1 ≤ i, j ≤n, i �= j. If Δi,j is inconsistent, then vi and vj are trying toreach an agreement on the modifications of CORE(Δi,j).For each individual viewpoint, we consider two kinds ofatomic actions appropriate for modifying CORE(Δi,j):

– delete(vi, α, Δi): vi deletes the requirement α fromΔi;

– add(vi, (β, lk), Δi): If neither β nor ¬β appears inΔi, then vi add the requirements statement β with pri-ority of lk to Δi.

A proposal is a series of such actions under ∧. In particu-lar, we abbreviate delete(vi, α, Δi)∧add(vi, (γ, lt), Δi) byreplace(vi, α, Δi, (γ, lt)). A desirable proposal should beable to decrease the degree of inconsistency or decrease thesignificance of inconsistency. Moreover, change of the re-quirements with lower priorities should be considered firstly.Generally, if viewpoint vi wants to put forward a proposal ϕk

i

at k-th step, the following strategies should be considered:

– the degree of inconsistency in the union of the view-points should be decreased;

– from the perspective of vi, a desirable proposal shouldhelp to eliminate the most significant minimal incon-sistent subsets of the current requirements set;

– changes of the requirements with lower prioritiesshould be considered firstly.

However, these proposals presented by different viewpointsreflect different concerns and intentions. Viewpoints need toidentify a common acceptable proposal by proceeding nego-tiation. It is a process of group decision making.

• Group Decision Maker. When a proposal for handling in-consistency is presented by a viewpoint, the negotiation for acommon acceptable proposal starts. For proceeding the ne-gotiation process, we may use a negotiation meta-languagedefined in [20]. This language is richer for talking about pro-posals than negotiation languages designed for special sce-narios [20], since it includes the following illocutions for de-scribing the speech acts of conveying intentions:

– request(i, j, ϕ) : a request from agent i to agent j forproposal ϕ;

– offer(i, j, ϕ): a proposal of ϕ from i to j;

– accept(i, j, ϕ): agent i accepts proposal ϕ made by j;

– reject(i, j, ϕ): agent i rejects proposal ϕ made by j;

– withdraw(i, j): i withdraws from negotiation with j.

Table 1. The protocol at the k-th step of thenegotiation

Viewpoint vi says Viewpoint vj replies

request(vi, vj , ϕki ) offer(vj , vi, ϕ

kj )

offer(vi, vj , ϕki ) offer(vj , vi, ϕ

kj ), or

accept(vj , vi, ϕkj ), or

reject(vj , vi, ϕkj ), or

withdraw(vj , vi)

reject(vi, vj , ϕk−1i ) offer(vj , vi, ϕ

kj ), or

withdraw(vj , vi)

accept(vi, vj , ϕk−1i ) end of negotiation

withdraw(vi, vj) end of negotiation

Here ϕ is a formula of the negotiation language. Generally,a negotiation begins when one agent makes an offer to an-other, or when one makes a request to another. Negotiationceases when one agent accept an offer or withdraw fromnegotiation [20].

We adopt the protocol used in [18] in this paper, which islist in Table 1. It has been shown that the protocol guaranteessuccess in [20].

To respond to proposal ϕki presented by vi, viewpoint vj

need to evaluate the proposal. The following strategiesshould be taken into account:

– If there are some essential requirements of Δj in-volved in ϕk

i , then vj may reject the proposal ϕki , or

offer a new proposal to vi, or withdraw from negoti-ation with vi. Generally, viewpoint vj cannot acceptthe proposal.

– For vj , if the most significant minimal inconsistentsubsets of the current requirements set will be elimi-nated by performing the proposal, and the importanceof the set of requirements involved in ϕk

i is less thanthat of the set of others requirements, then vj may ac-cept the proposal ϕk

i , or offer an adaptation of ϕki to

vi in general case.

Based on these strategies, all the proposals may be sorted byeach viewpoint from its own perspective. Let MI(Δi,j) ={Φ1, · · · , Φn}. And assume that

−→C i(Φ1 ∩ Δi) �P · · · �P−→

C i(Φn ∩Δi). Given a proposal ϕ, we may define ui(ϕ) =(a1, · · · , an) to evaluate the proposal ϕ from the perspectiveof vi, where ak = 1 if ϕ can eliminate Φk without con-cession and ak = 0 otherwise. Then we may define thefollowing ordering relation over proposals as follows:

Definition 1 (Ordering relation, ≤) Given two proposalsϕ1 and ϕ2, ϕ1 ≤i ϕ2 iff ui(ϕ1) �P ui(ϕ2). We say thatviewpoint vi prefers ϕ2 to ϕ1.

However, these priority-based strategies do not provide anuniversal solution. Rather, the priority-based strategy em-phasizes that the priority of requirements should play an im-portant role in making or evaluating a proposal, since it is

296

viewed as some kind of abstraction of the statement’s signif-icance.

5. A Case Study

We give a small example to illustrate the use of the pro-cess model to handling inconsistency in software require-ments development.

Example 1 Consider the requirements for updating a soft-ware system. Stakeholder A, who will be in charge of saleof system-to-be, provides three demands as follows:

• Essential requirements: The system-to-be should be open(OPEN) , that is, the system-to-be could be extended easily;

• Conditional requirements: The user interface of system-to-beshould be fashionably designed (FASH);

• Optional requirements: The system-to-be should be devel-oped based on the newest development techniques (NEWT).

Stakeholder B, who is a delegate of the users of the ex-isting system, provides the following requirements:

• Essential requirements: The system-to-be should be devel-oped based on the techniques used in the existing system;

• Essential requirements: The user interface of system-to-beshould keep the style of that of existing system;

• Optional requirements: The system-to-be should not be openfor the sake of security.

Let 〈(ΔA, PA), (ΔB , PB)〉 denote the partial specifica-tion comprising the two viewpoints {vA, vB}, where ΔA ={OPEN, FASH, NEWT}, ΔB = {¬OPEN, ¬FASH, ¬NEWT}, andPA(OPEN) = l2, PA(FASH) = l1, PA(NEWT) = l0;

PB(¬NEWT) = l2; PB(¬OPEN) = l0, PB(¬FASH) = l2.

We can detect the following inconsistencies:

ΔA,B � OPEN ∧ ¬OPEN, ΔA,B � FASH ∧ ¬FASH,

ΔA,B � NEWT ∧ ¬NEWT.

Then MI(ΔA,B) = {Γ1, Γ2, Γ3}, CORE(ΔA,B) =3⋃

i=1

Γi,

Γ1 = {OPEN,¬OPEN}, Γ2 = {FASH,¬FASH}, Γ3 ={NEWT,¬NEWT},

−→C A(CORE(ΔA,B) ∩ ΔA) = (1, 1, 1),−→

C B(CORE(ΔA,B) ∩ ΔB) = (1, 0, 2).Since ¬FASH and ¬NEWT are the requirements statements with

highest priority in vB involved in inconsistency, then vB generatestwo proposals ϕ0

B and ϕ1B as follows:

ϕ0B : delete(vA, OPEN, ΔA) ∧ delete(vA, FASH, ΔA)

∧delete(vA, NEWT, ΔA);

ϕ1B : delete(vB,¬OPEN, ΔB) ∧ replace(vA, NEWT,

ΔA, (¬NEWT, l0)) ∧ delete(vA, FASH, ΔA);

For vB , based on the measurement, we can get

ϕ1B ≤ ϕ0

B .

vA may also generate two proposals ϕ0A and ϕ1

A as follows:

ϕ0A : delete(vB,¬OPEN, ΔB) ∧ delete(vB,¬FASH, ΔB)

∧delete(vB,¬NEWT, ΔB);

ϕ1A = ϕ1

B. Then ϕ1A ≤ ϕ0

A for vA.

However, if vB puts forward ϕ0B to proceed negotiation,

i.e., offer(vB , vA, ϕ0B), then vA rejects the proposal ϕ0

B:reject(vA, vB , ϕ0

B), since OPEN is essential to viewpoint vA. Sodoes ϕ0

A.If vB makes some concession, then vB puts forward the pro-

posal ϕ1B: offer(vB , vA, ϕ1

B). If vA accepts the proposal ϕ1B ,

then Γ1, Γ2, and Γ3 disappear. Moreover, there is no proposal in{ϕ0

A, ϕ1A} accepted by vB more beneficial than ϕ1

B to vA. ThenvA may accept ϕ1

B: accept(vA, vB , ϕ1B). The negotiation ends.

During this negotiation process, the proposals set{ϕ0B , ϕ0

A, ϕ1A}

is sorted as ϕ0B , ϕ0

A ≤ ϕ1A. If all the stakeholders accept ϕ1

A, thenwe get a consistent requirements specification as follows:

Δ∗A = {OPEN, ¬NEWT},

PA(OPEN) = l2, PA(¬NEWT) = l0;

Δ∗B = {¬FASH, ¬NEWT},

PB(¬FASH) = l2, PB(¬NEWT) = l2.

That is, Stakeholder B abandons the requirement of ¬OPEN.Stakeholder A gives up the requirement of ¬FASH, and change therequirement of NEWT to ¬NEWT.

6. Related Works

Inconsistency handling is a pervasive issue during thesoftware development. A similar framework for manag-ing inconsistency has been proposed in [15, 17]. Both theframework in [15, 17] and the process model presented inthis paper emphasize the role of measurement of incon-sistency in managing inconsistency. However, consistencyrule rather than logical reasoning engine is considered asa central role to the framework presented in [15, 17]. Incontrast,the process model presented in this paper consid-ers logical reasoning engine as inconsistency detector. Adetail rather than general approach to measuring require-ments inconsistency is also considered in the process model.Moreover, the process model introduces the automated ne-gotiation mechanism to resolve disagreement among differ-ent stakeholders in identifying final modification of require-ments. In particular, the significance and the degree of in-consistency play a crucial role in putting forward or evalu-ating a proposal.

On the other hand, we do not claim that negotiationshould be considered as a silver bullet for identifying an ap-propriate proposal for inconsistency handling. For example,some other strategies such as combinatorial vote [12] andgame theory should be considered in some special cases.

297

7. Conclusions

We have presented a measurement-driven process modelfor handling requirements inconsistency in the Viewpointsframework. In this process model, developers first trans-late the requirements in natural language into correspondinglogical formulas by a translator such as developed in [7].And an appropriate logical reasoning engine serves as in-consistency detector. If some inconsistencies are detected,then the inconsistent requirements set is measured in termsof the significance as well as the degree of inconsistency.Then negotiation mechanism from Multi-Agents is intro-duced to find an agreement among different viewpoints oninconsistency handling. In particular, the measurement ofinconsistency is crucial to reaching a successful compro-mise during the negotiation.

An algorithm for automated generation of proposals anda more reasonable approach to evaluating the proposals canfacilitate the application of our proposed process model topractical requirements engineering. This will be the maindirection of our future work with specific focus on de-signing an automated prototype tool set in support of ourproposed process model for managing inconsistent require-ments.

Acknowledgements This research is supported in part bythe National Natural Science Foundation of China underGrant No. 60703061, the National 863 High-tech Project ofChina under Grant No.2006AA01Z155, the National KeyResearch and Development Program of China under GrantNo. 2002CB312004, the National Natural Science Fundfor Distinguished Young Scholars of China under GrantNo.60625204, the Key Project of National Natural Sci-ence Foundation of China under Grant No.60496324, andthe International Science Linkage Research Grant under theAustralia-China Special fund for Science and Technology.

References

[1] A.Hunter. Logical comparison of inconsistent perspectivesusing scoring functions. Knowledge and Information Sys-tems Journal, 6(5):528–543, 2004.

[2] J. Andrade, J. Ares, R. Garcia, J. Pazos, S. Rodriguez,and A. Silva. A methodological framework for viewpoint-oriented conceptual modeling. IEEE Trans. Softw. Eng.,30(5):282–294, 2004.

[3] A. Davis. Just Enough Requirements Management:WhereSoftware Development Meets Marking. Dorset House, 2005.

[4] A. Finkelstein, D. Gabbay, A. Hunter, J. Kramer, and B. Nu-seibeh. Inconsistency handling in multiperspective specifi-cations. IEEE Trans. on Software Engineering, 20:569–578,1994.

[5] A. Finkelstein, J.Kramer, B.Nuseibeh, L.Finkelstein, andM.Goedicke. Viewpoints: A framework for integrating

multiple perspectives in system development. InternationalJournal of Software Engineering and Knowledge Engineer-ing, 2(1):31–58, 1992.

[6] D. Gabbay and A. Hunter. Making inconsistency re-spectable 2:meta-level handling of inconsistent data. InECSQARU93,LNCS, volume 747, pages 129–136. Springer,1993.

[7] V. Gervasi and D.Zowghi. Reasoning about inconsisten-cies in natural language requirements. ACM Transaction onSoftware Engineering and Methodologies, 14(3):277–330,2005.

[8] A. Hunter and B.Nuseibeh. Managing inconsistent speci-fication. ACM Transactions on Software Engineering andMethodology, 7(4):335–367, 1998.

[9] M. Ibanez. European user survey analysis. Tech. rep. ESIreport TR95104. European Software Institute, Zamudio,Spain. Web site: www.esi.es, 1996.

[10] IEEE.1998. IEEE Std 830-1998:IEEE Recommended Prac-tice for Software Requirements Specifications. Los Alami-tos, CA:IEEE Computer Society Press, 1998.

[11] G. Kotonya and I.Sommerville. Viewpoints for requirementsdefinition. IEE Software Eng.Journal, 7:375–387, Novem-ber 1992.

[12] J. Lang. From logical preference representation to combina-torial vote. In Proceedings of 8th International Conferenceon Principles of Knowledge Representation and Reasoning,pages 277–288. Morgan Kaufmann, 2002.

[13] D. Leffingwell. Calculating the return on investment frommore effective requirements management. American Pro-grammer, 10(4), 1997.

[14] K. Mu, Z. Jin, R. Lu, and W. Liu. Measuring incon-sistency in requirements specifications. In L.Godo, edi-tor, ECSQARU2005,LNCS, volume 3571, pages 440–451.Springer-Verlag Berlin Heidelberg, 2005.

[15] B. Nuseibeh, S. Easterbrook, and A. Russo. Leveraginginconsistency in software development. IEEE Computer,33(4):24–29, 2000.

[16] B. Nuseibeh, J. Kramer, and A. Finkelstein. Viewpoints:meaningful relationships are difficult! In Proceedings ofthe 25th International Conference on Software Engineering,pages 676–681. IEEE CS Press, 2003.

[17] B. Nuseibeh, S.Easterbrook, and A.Russo. Making incon-sistency respectable in software development. Journal ofSystems and Software, 58(2):171–180, 2001.

[18] C. Sierra, N. Jennings, P. Noriega, and S. Parsons. A frame-work for argumentation-based negotiation. In IntelligentAgents IV (LNAI Volume 1365), pages 177–192. 1998.

[19] K. Wiegers. First things first:prioritizing requirements. Soft-ware Development, 7(9):48–53, 1999.

[20] M. Wooldridge and S. Parsons. Languages for negotiation.In Proceedings of ECAI2000), pages 393–397. 2000.

[21] D. Zowghi and V. Gervasi. On the interplay between con-sistency, completeness, and correctness in requirements evo-lution. Information and Software Technology, 45(14):993–1009, 2003.

298