To do or not to do: If the requirements engineering payoff is so good, why aren' t more companies doing it?

Berry, Daniel M.; Damian, Daniela; Finkelstein, Anthony; Gause, Donald C.; Hall, Robert J.; Simmons, Emilee Lauran; Wassyng, Alan

doi:10.1109/re.2005.74

Cited by 14 publications

(7 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…2 We do not report here the results from the Eclipse project due to the poor quality of the data it contains as discussed in the Sect. 2 The questions that we wished to answer with our experiments are the following:…”

Section: Prediction Experimentsmentioning

confidence: 99%

“…This latter approach, however, requires a radical change from the way feature requests management systems are currently used, and the benefits of such a change are hard to demonstrate. The general argument that every defect found and corrected during requirements elaboration saves up to 100 times the cost it would take to correct it after delivery is hard to make in this context: It is not clear whether a requirements defect will actually cause a failure later on in the development process (many features are implemented correctly even if starting from an ambiguous description), and the speed of feature delivery is often viewed as more important than its quality [2].…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Early failure prediction in feature request management systems: an extended study

2012

View full text Add to dashboard Cite

Online feature request management systems are popular tools for gathering stakeholders' change requests during system evolution. Deciding which feature requests require attention and how much upfront analysis to perform on them is an important problem in this context: too little upfront analysis may result in inadequate functionalities being developed, costly changes, and wasted development effort; too much upfront analysis is a waste of time and resources. Early predictions about which feature requests are most likely to fail due to insufficient or inadequate upfront analysis could facilitate such decisions. Our objective is to study whether it is possible to make such predictions automatically from the characteristics of the online discussions on feature requests. This paper presents a study of feature request failures in seven large projects, an automated tool-implemented framework for constructing failure prediction models, and a comparison of the performance of the different prediction techniques for these projects. The comparison relies on a cost-benefit model for assessing the value of additional upfront analysis. In this model, the value of additional upfront analysis depends on its probability of success in preventing failures and on the relative cost of the failures it prevents compared to its own cost. We show that for reasonable estimations of these two parameters, automated prediction models provide more value than a set of baselines for many failure types and projects. This suggests automated failure prediction during requirements elicitation to be a promising approach for guiding requirements engineering efforts in online settings.

show abstract

Section: Prediction Experimentsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Early failure prediction in feature request management systems: an extended study

2012

View full text Add to dashboard Cite

show abstract

“…[86]. Indeed, with the common management mantra that "Weeks of coding can save hours of planning" [87], and the pressure placed on developers to "get on to the real work, designing and programming" [87], this is not surprising. The incentive to read requirements documents will be even less if there is a high degree of repetition between them.…”

Section: Reducing Problems In Current Projects (Where Ur-sysr Repetitmentioning

confidence: 99%

Repetition between stakeholder (user) and system requirements

et al. 2015

View full text Add to dashboard Cite

Stakeholder requirements (also known as user requirements) are defined at an early stage of a software project to describe the problem(s) to be solved. At a later stage, abstract solutions to those problems are prescribed in system requirements. The quality of these requirements has long been linked to the quality of the software system and its development or procurement process. However little is known about the quality defect of redundancy between these two sets of requirements. Previous literature is anecdotal rather than exploratory, and so this paper empirically investigates its occurrence and consequences with a case study from a UK defence contractor. We report on a survey of sixteen consultants to understand their perception of the problem, and on an analysis of real world software requirements documents using natural language processing techniques. We found that three quarters of the consultants had seen repetition in at least half of their projects. Additionally, we found that on average, a third of the requirement pairs' (comprised of a system and its related stakeholder requirement) description fields were repeated such that one requirement in the pair added only trivial information. That is, solutions were described twice while their respective problems were not described, which ultimately lead to suboptimal decisions later in the development process and reduced motivation to read the requirements set. Furthermore, the requirement attributes considered to be secondary to the primary 'description' attribute, such as the 'rationale' or 'fit criterion' fields had considerably more repetition between UR-SysR pairs. Given that the UR-SysR repetition phenomena received most of its discussion in the literature over a decade ago, it is interesting that the survey participants did not consider its occurrence to have declined since then. We provide recommendations on preventing the defect, and describe the freelyavailable tool developed to automatically detect its occurrence and alleviate its consequences.

show abstract

“…This latter approach, however, requires a radical change from the way feature requests management systems are currently used, and the benefits of such a change are hard to demonstrate. The general argument that every defect found and corrected during requirements elaboration saves up to 100 times the cost it would take to correct it after delivery is hard to make in this context: it is not clear whether a requirements defect will actually cause a failure later on in the development process (many features are implemented correctly even if starting from an ambiguous description), and the speed of feature delivery is often viewed as more important than its quality [1].…”

Section: Introductionmentioning

confidence: 99%

Early failure prediction in feature request management systems

Fitzgerald

Letier

Finkelstein

2011

2011 IEEE 19th International Requirements Engineering Conference

View full text Add to dashboard Cite

Abstract-Online feature request management systems are popular tools for gathering stakeholder requirements during system evolution. Deciding which feature requests require attention and how much upfront analysis to perform on them is an important problem in this context: too little upfront analysis may result in inadequate functionalities being developed, costly changes, and wasted development effort; too much upfront analysis is a waste of time and resources. Early predictions about which feature requests are most likely to fail due to insufficient or inadequate upfront analysis could facilitate such decisions. Our objective is to study whether it is possible to make such predictions automatically from the characteristics of the online discussions on feature requests.The paper presents a tool-implemented framework that automatically constructs failure prediction models using machinelearning classification algorithms and compares the performance of the different techniques for the Firefox and Netbeans projects. The comparison relies on a cost-benefit model for assessing the value of additional upfront analysis. In this model, the value of additional upfront analysis depends on its probability of success in preventing failures and on the relative cost of the failures it prevents compared to its own cost. We show that for reasonable estimations of these two parameters automated prediction models provide more value than a set of baselines for some failure types and projects. This suggests that automated failure prediction during online requirements elicitation may be a promising approach for guiding requirements engineering efforts in online settings.

show abstract

To do or not to do: If the requirements engineering payoff is so good, why aren' t more companies doing it?

Cited by 14 publications

References 0 publications

Early failure prediction in feature request management systems: an extended study

Early failure prediction in feature request management systems: an extended study

Repetition between stakeholder (user) and system requirements

Early failure prediction in feature request management systems

Contact Info

Product

Resources

About