Exploring factors affecting decision outcome and lead time in large‐scale requirements engineering

Abstract

Lead time, defined as the duration between the moment a request was filed and the moment the decision was made, is an important aspect of decision making in market-driven requirements engineering. Minimizing lead time allows software companies to focus their resources on the most profitable functionality and enables them to remain competitive within the quickly changing software market. Achieving and sustaining low decision lead time and the resulting high decision efficiency require a better understanding of factors that may affect both decision lead time and outcome. In order to identify possible factors, we conducted an exploratory two-stage case study that combines the statistical analysis of seven possible relationships among decision characteristics at a large company with a survey of industry participants. Our results show that the number of products affected by a decision increases the time needed to make a decision. Practitioners should take this aspect into consideration when planning for efficient decision making and possibly reducing the complexity of decisions. Our results also show that when a change request originates from an important customer, the request is more often accepted. The results provide input into the discussion of whether a large company should focus on only a few of its large customers and disregard its significantly larger group of small customers. The results provide valuable insights for researchers, who can use them to plan research of decision-making processes and methods, and for practitioners, who can use them to optimize their decision-making processes. In future work, we plan to investigate other decision characteristics, such as the number of stakeholders involved in the discussion about the potential change or the number of dependencies between software components.

An empirical study on decision making for quality requirements

“…Looking at security QFs after 13Q1, it appears to be a similar pattern in the decision making of high acceptance ratio of security QFs that are demanded by external stakeholders. This is similar to our previous work where we found that change requests proposed by external stakeholders are more likely to be accepted (Wnuk et al, 2015). Looking at releases 14Q2 to 15Q2, we observe that important external stakeholder QFs are discarded.…”

“…Furthermore, they discovered that 19% of all QRs are dismissed at some stage before release. In previous work, we have found that change requests from external stakeholders are more likely to be accepted (Wnuk, Kabbedijk, Brinkkemper, Regnell, & Callele, 2015). We have previously concluded that features proposed late in the release cycle are more often rejected than accepted (Wnuk et al, 2015).…”

“…In previous work, we have found that change requests from external stakeholders are more likely to be accepted (Wnuk, Kabbedijk, Brinkkemper, Regnell, & Callele, 2015). We have previously concluded that features proposed late in the release cycle are more often rejected than accepted (Wnuk et al, 2015). However, they have not focused primarily on QRs or QFs and did not study what happens across several releases in the product planning process.…”

Choosing Component Origins for Software Intensive Systems: In-House, COTS, OSS or Outsourcing?—A Case Survey

“…Furthermore, criteria need to be prioritized. Similar reflections were presented in the field of requirements engineering, where it was found that more complex decisions take more time [35]. As a consequence requirements triage has been introduced that removes the most obvious options first to avoid investigative effort [36].…”

Automated support for reuse-based requirements engineering in global software engineering

“…These 2 requirements, SUPL122 and UC16, refine ( trace‐from ) the feature FEAT25 in Figure . All the features in the VIS document have been redefined as requirements during the analysis process to prepare the software design …”