Resolving Inconsistency and Incompleteness Issues in Software Requirements
In this chapter, we present an approach toward better understanding and analyzing significant aspect of software – the requirements. Comprehending the semantics of requirements is crucial to the success of the intended software. In order that the software
- PDF / 199,280 Bytes
- 19 Pages / 439.37 x 666.142 pts Page_size
- 69 Downloads / 156 Views
Resolving Inconsistency and Incompleteness Issues in Software Requirements R. Sharma and K.K. Biswas
Abstract In this chapter, we present an approach toward better understanding and analyzing significant aspect of software – the requirements. Comprehending the semantics of requirements is crucial to the success of the intended software. In order that the software requirements be well understood, it is imperative that these must be complete and consistent. But, the elicited requirements are often incomplete, inconsistent, and, consequently, ambiguous in nature. Requirements engineer is presented with the task of examining and analyzing such requirements and detecting these issues, i.e., instances of incompleteness and inconsistency. We present here courteous logic-based representations of requirements as an approach toward resolving the issues of incompleteness, inconsistency, and ambiguity in the elicited requirements and assisting improved understanding of elicited requirements. We explain how courteous logic can be an effective solution to requirements interpretation in terms of observable behavior of the system and can be a useful tool for requirements engineer toward improving the quality of software requirements. We will be more concerned toward inconsistency and incompleteness issues in this chapter.
11.1
Introduction
Requirements engineering (RE hereafter) is the basis for subsequent phases of software development cycle. Software design and development take off once the requirements are well understood and agreed upon by the developers, clients, and the involved stakeholders. The question of well or better understanding of the requirements calls for an adequate representation of requirements. IEEE’s recommended guidelines [1] for good requirements specification suggest that R. Sharma (*) • K.K. Biswas IIT Delhi, New Delhi, India e-mail: [email protected]; [email protected] W. Maalej and A.K. Thurimella (eds.), Managing Requirements Knowledge, DOI 10.1007/978-3-642-34419-0_11, # Springer-Verlag Berlin Heidelberg 2013
245
246
R. Sharma and K.K. Biswas
requirements should be correct, complete, consistent, unambiguous, verifiable, and traceable. The guidelines precisely define these characteristics in terms of requirements specified or mentioned in the document, referred to as software requirements specification. We however stress that these attributes are equally applicable to the requirements representation in context of the domain under study, albeit the interpretations differ. Correctness, completeness, and consistency of requirements have been described in detail in [2]. Zowghi and Gervasi suggest that correctness has at least two different perspectives: 1. From a formal point of view, correctness is usually meant to be the combination of consistency and completeness. Consistency refers to situations where a specification contains no internal contradictions, whereas completeness refers to situations where a specification entails everything that is known to be “true” in a certain context. Consist
Data Loading...
