Search

It is widely recognized that most software project failures result from problems about software requirements. Early verification of requirements can facilitate many problems associated with the software developments. The requirements testing is useful to clarify problematical information during the requirements stage. However, for any complex and sizeable system, the development of requirements typically involves different stakeholders with different concerns. Then the requirements specifications are increasingly developed in a distributed fashion. This makes requirements testing rather difficult. The main contribution of this paper is to present an answer set programming-based logical approach to testing requirements specifications. Informally, for an individual requirements test case, we consider the computation of the output of the system-to-be in requirements testing as a problem of answer set programming. In particular, the expected responses of the requirements test case is viewed as an intended solution to this problem. Based on the requirements and the input of the requirements test case, we design a logic program whose answer sets correspond to solutions of the problem. Then the testing is performed by an answer set solver. Finally, we identify the disagreement between the answer sets and the intended solution to detect the defects in software requirements. [ABSTRACT FROM AUTHOR]

The requirements specifications of complex systems are increasingly developed in a distributed fashion. It makes inconsistency management necessary during the requirements stage. However, identifying appropriate inconsistency handling proposals is still an important challenge. In particular, for inconsistencies involving many different stakeholders with different concerns, it is difficult to reach an agreement on inconsistency handling. To address this, this paper presents a vote-based approach to choosing acceptable common proposals for handling inconsistency. This approach focuses on the inconsistency in requirements that results from conflicting intentions of stakeholders. Informally speaking, we consider each distinct stakeholder (or a distributed artifact) involved in the inconsistency as a voter. Then we transform identification of an acceptable common proposal into a problem of combinatorial vote. Based on each stakeholder's preferences on the set of proposals, an acceptable common proposal is identified in an automated way according to a given social vote rule. [ABSTRACT FROM AUTHOR]

It seems to be inevitable to confront vague information about customer's needs during the software requirements stage. It may be desirable to record and clarify the vague information to avoid missing real requirements. In this paper, we provide an inconsistency-based strategy to handle vague information in the framework of Annotated Predicate Calculus. This strategy permits the stakeholder to describe the different vague information using statements with different levels of belief, where each level of belief is determined by the degree of vagueness. By checking consistency of the union of vague requirements and clear requirements, we then heighten the level of belief in uncontroversial vague requirements. We also lower the levels of belief in requirements involved in undesirable inferences and leave them to be articulated in some following stage. To support this, Annotated Predicate Calculus is used to represent the requirements specification. In particular, we present a special belief semilattice, which defines truth values appropriate for representing the strength of analyst's belief in the truth of requirements statements. [ABSTRACT FROM AUTHOR]

In the field of requirements engineering, measuring inconsistency is crucial to effective inconsistency management. A practical measure must consider both the degree and significance of inconsistency in specification. The main contribution of this paper is providing an approach for measuring inconsistent specification in terms of the priority-based scoring vector, which integrates the measure of the degree of inconsistency with the measure of the significance of inconsistency. In detail, for each specification Δ that consists of a set of requirements statements, if L is a m-level priority set, we define a m-dimensional priority-based significance vector to measure the significance of the inconsistency in Δ. Furthermore, a priority-based scoring vector : (Δ)→ Nm+1 has been defined to provide an ordering relation over specifications that describes which specification is "more essentially inconsistent than" others. [ABSTRACT FROM AUTHOR]