Are ambiguous requirements really a problem in software development? The authors of this paper sought to answer this question using a three-pronged approach: interviews were conducted with four experts; a difference test was applied to determine if off-budget projects suffered from more ambiguity in their requirements than on-budget projects; and a root cause analysis (RCA) was made of a random sample of 100 reported defects to determine how frequently ambiguity actually caused defects.

The RCA found that requirement ambiguity caused only three out of the 100 reported defects in one project. The difference test, applied to data gathered from 40 projects, was not statistically significant. The interviews resulted in the identification of factors that influence the risk of ambiguity. As described in section 5.3, the majority of these factors are alleviated using software development approaches such as Scrum that emphasize communication. The authors conclude that their findings cast doubt on the notion that ambiguous requirements can threaten success in software development projects.

In analyzing the data, some experienced researchers would likely have been far more rigorous, taking a grounded theory approach to analyze the interview transcript data. Graphs showing the degree of budget overrun against the density of ambiguity in requirements would have been helpful. It also seems like it would have made more sense to undertake an RCA of all 389 reported defects on one project rather than a random sample. Despite these criticisms, the paper does succeed in questioning the importance attached to requirement ambiguity, and I recommend it to the software engineering community.