Article Preview
Top1. Introduction
It has been increasingly recognized that inconsistency is inevitable during the requirements process (Easterbrook & Chechik, 2001a; Nuseibeh et al., 2001). Both general principles of managing inconsistency and special case-based approaches to handling inconsistency have recently been considered. In particular, it has been pointed out in Gervasi and Zowghi (2005) that the use of logic in managing inconsistency in requirements has been found to be effective in a number of studies. Various logic-based techniques have been proposed to manage inconsistencies in requirements engineering (Hunter & Nuseibeh, 1998; Gervasi & Zowghi, 2005; Martinez et al., 2008; Zowghi & Gervasi, 2003; Mu et al., 2005a, 2008, 2009). Most of these logic-based approaches focus on how to manage inconsistency by applying logical techniques such as paraconsistent reasoning and non-monotonic reasoning to requirements engineering. For example, Hunter and Nuseibeh (1998) developed the labeled quasi-classic logic to represent and reason about requirements specifications in the presence of inconsistency. Gervasi and Zowghi (2005) proposed methods for reasoning about inconsistencies in natural language requirements by combining natural language parsing techniques and non-monotonic reasoning. Easterbrook and Chechik (2001b) presented a framework termed χbel for merging inconsistent viewpoints using multi-valued logics. This framework was intended to highlight the source of inconsistency and to tolerate inconsistencies between viewpoints during model checking.
In contrast, there are relatively few logic-based techniques for generating appropriate proposals for inconsistency resolving actions in requirements engineering (Finkelstein et al., 1994; Gabbay & Hunter, 1993; Mu & Jin, 2007; Mu et al., 2008, 2009). Previously, we have argued that the relative priority of each requirement should play an important role in identifying appropriate proposals for resolving inconsistencies in requirement specifications (Mu & Jin, 2007; Mu et al., 2008, 2009), moreover, negotiation and combinatorial vote may be considered as two appropriate mechanisms of group decision making for identifying acceptable common proposals for handling inconsistent requirements specification (Mu et al., 2008, 2009). However, identifying appropriate actions for resolving inconsistency in requirements specification is still a challenging problem (Hunter & Nuseibeh, 1998). Generally, the choice of inconsistency handling actions is a rather context-sensitive issue (Finkelstein et al., 1994; Gabbay & Hunter, 1993). So, as pointed out in Mu et al. (2008), a feasible proposal for inconsistency resolving should focus on pointing out which requirements to be changed rather than how to change these requirements.