The Prevalence and Severity of Persistent Ambiguity in Software Requirements Specifications: Is a Special Effort Needed to Find Them?

Abstract Context and motivation All the research in methods and tools for avoiding, detecting, and removing ambiguities in requirements specifications assumes that doing so is necessary and that the methods and tools for doing so are worth the effort to use them. Each of two attempts by de Bruijn et al and Philippo et al to test these assumptions empirically with a case study examined a random sampling of the ambiguities in the requirements specification for already constructed software. Each study concluded that ambiguities in the examined requirements specification did not result in any serious defects in the downstream development and seem to have been resolved through the normal multiple inspections and discussions that characterize a serious requirements engineering process. Question/problem However, because each study examined only a small random sampling of the many ambiguities in its specification, it may have missed the rare ambiguity that causes a serious defect in the constructed software. Moreover, as a case study, its results cannot be generalized. So the unanswered questions are: (1) “How prevalent are ambiguities that cause defects?” and (2) “What kinds of defects do these ambiguities cause?” Principal idea/Goal The research reported in this paper tried hard to falsify de Bruijn's and Philippo's result in three different case studies, each with a requirements specification and already developed software. Each study used a purposive sampling of the ambiguities in its requirements specification to find those ambiguities that are least likely to have been discussed and resolved during the inspections and discussions about the specifications in an attempt to find undetected ambiguities that caused or can cause major defects in the implemented software. The purposive sampling was to identify types of ambiguity, called persistent ambiguities of which many people are not aware; which, therefore, will not not come up in any of the discussions about the requirements; and which will persist into the implementation to cause defects. After obtaining the persistent ambiguities in the project's requirements specification, we asked the project's chief requirements engineer if any of them caused or can cause serious defects in the project's software. Conclusion/Contribution For the three projects, none of the sampled ambiguities reviewed by each chief requirements engineer caused expensive damage because all of the project's requirements engineers seem to have subconsciously disambiguated the ambiguities in the same way. The first main conclusion is that persistent ambiguities remain undetected during requirements enginering and the subsequent development. The second main conclusion is that a serious requirements engineering process is sufficient to cause all project stakeholders to disambiguate, consciously or not, all ambiguities, persistent or not, in a requirements specification the same way; thus, ambiguities, while present in the specification, do not cause defects in the downstream software. The third main conclusion is that the identification of persistent ambiguities in a requirements specification is potentially an effective and efficient strategy for minimizing damage caused by ambiguity precisely because of its focus on ambiguities that remain undetected due to lack of awareness. Further study is necessary to determine what factors are involved in persistent ambiguity and its prevalence, as well as its potential impacts.