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 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 engineering 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.

中文翻译：

---

软件需求规范中持续性模棱两可的普遍性和严重性：是否需要付出特殊的努力才能找到它们？

情境和动机

为避免，检测和消除需求规范中的歧义而进行的所有方法和工具研究均假设这样做是必要的，并且为此而努力的方法和工具值得使用它们。de Bruijn等人的两次尝试中的每一次。和Philippo等。为了通过案例研究以经验方式检验这些假设，研究了对已经构建的软件的需求规范中模糊性的随机抽样。每项研究得出的结论是，所检查的需求规范中的歧义不会在下游开发中导致任何严重的缺陷，并且似乎已经通过表征严重需求工程过程的正常多次检查和讨论得到了解决。

问题/问题

但是，由于每项研究仅检查了其规范中许多歧义的少量随机样本，因此它可能错过了导致所构建软件严重缺陷的罕见歧义。此外，作为一个案例研究，其结果不能一概而论。因此，未解决的问题是：（1）“引起缺陷的歧义有多普遍？” （2）“这些歧义会导致哪些缺陷？”

主要思想/目标

本文报道的研究试图在三个不同的案例研究中伪造de Bruijn和Philippo的结果，每个案例都有一个需求规范和已经开发的软件。每项研究均在其需求规格书中使用了歧义性的有目的抽样，以查找那些在检查和讨论规范时最不可能讨论和解决的歧义性，以期发现导致或可能导致重大缺陷的未检测到歧义性。已实施的软件。目的抽样是为了识别歧义的类型，称为持续歧义其中许多人不知道；因此，在有关要求的任何讨论中都不会​​提到这些内容；并将持续存在于实施中以导致缺陷。在获得项目需求规范中的持续歧义后，我们询问项目的首席需求工程师是否其中任何一个导致或可能导致项目软件的严重缺陷。

结论/贡献

对于这三个项目，每个首席需求工程师审查的抽样歧义都不会造成昂贵的损害，因为所有项目的需求工程师似乎都以相同的方式下意识地消除了歧义。第一个主要结论是，在需求工程和后续开发过程中始终没有发现持续的歧义。第二个主要结论是，认真的需求工程流程足以使所有项目涉众有意识地或无意地以相同的需求规格说明消除歧义，无论是否持久。因此，在规范中存在歧义时，不会在下游软件中引起缺陷。第三个主要结论是，在需求规范中识别持续的歧义可能是一种有效且有效的策略，可将由于歧义引起的损害降到最低，这恰恰是因为它关注因缺乏意识而无法发现的歧义。有必要进行进一步的研究以确定哪些因素与持续的歧义及其普遍性及其潜在影响有关。