Reducing the risk of requirements volatility: findings from an empirical survey

Ferreira, Susan; Shunk, Dan L.; Collofello, James; Mackulak, Gerald T.; Dueck, Amylou C.

doi:10.1002/smr.515

Cited by 14 publications

(18 citation statements)

References 25 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Taken together, these results indicate that a prediction of changing requirements will not be achieved based solely upon the requirement attributes examined in this study. Further consideration of more complex causal factors, such as the process factors and analysis techniques that have been found to correlate with requirements volatility [8,9], and also levels of effort and ability thought to influence the likelihood of defects [30].…”

Section: Discussion Of Resultsmentioning

confidence: 99%

“…As discovered in the second case study, apart from requirements dependency, no single attribute correlates with requirements volatility in all change domains. Previous studies have noted an influence of environmental factors, software development process and techniques, and effective communications upon requirements change [8,9]. Therefore, all factors are causally relevant and must work in combination to affect requirements uncertainty, as illustrated in the box labelled ''Uncertainty''.…”

Section: Discussion Of Resultsmentioning

confidence: 99%

“…An investigative survey [9] concluded that requirements volatility has a significant impact on schedule and cost overrun, but can be constrained by effective communication, definable methodology, and requirements inspections. These findings are echoed by Ferriera et al [8] in a survey completed by over 300 software development practitioners, who also note that higher levels of project maturity appear to reduce volatility. Jones [4] recommends elicitation and inspection techniques for mitigating the negative effects of volatility.…”

Section: Empirical Studies Of Requirements Volatility During Softwarementioning

confidence: 86%

“…Nuseibeh [7] maintains that attempts should be made to answer some difficult questions, among them ''What classes of requirements are more stable than others, and how do we identify them?'' While there have been studies undertaken to investigate the correlation between requirements volatility and process factors, such as maturity level and elicitation technique [8,9], there are no attempts to determine whether there are attributes of the requirements themselves that predispose them to change.…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Towards an understanding of the causes and effects of software requirements change: two case studies

McGee

Greer

2012

Requirements Eng

View full text Add to dashboard Cite

Changes to software requirements not only pose a risk to the successful delivery of software applications but also provide opportunity for improved usability and value. Increased understanding of the causes and consequences of change can support requirements management and also make progress towards the goal of change anticipation. This paper presents the results of two case studies that address objectives arising from that ultimate goal. The first case study evaluated the potential of a change source taxonomy containing the elements 'market', 'organisation', 'vision', 'specification', and 'solution' to provide a meaningful basis for change classification and measurement. The second case study investigated whether the requirements attributes of novelty, complexity, and dependency correlated with requirements volatility. While insufficiency of data in the first case study precluded an investigation of changes arising due to the change source of 'market', for the remainder of the change sources, results indicate a significant difference in cost, value to the customer and management considerations. Findings show that higher cost and value changes arose more often from 'organisation' and 'vision' sources; these changes also generally involved the co-operation of more stakeholder groups and were considered to be less controllable than changes arising from the 'specification' or 'solution' sources. Results from the second case study indicate that only 'requirements dependency' is consistently correlated with volatility and that changes coming from each change source affect different groups of requirements. We conclude that the taxonomy can provide a meaningful means of change classification, but that a single requirement attribute is insufficient for change prediction. A theoretical causal account of requirements change is drawn from the implications of the combined results of the two case studies.

show abstract

Section: Discussion Of Resultsmentioning

confidence: 99%

Section: Discussion Of Resultsmentioning

confidence: 99%

Section: Empirical Studies Of Requirements Volatility During Softwarementioning

confidence: 86%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Towards an understanding of the causes and effects of software requirements change: two case studies

McGee

Greer

2012

Requirements Eng

View full text Add to dashboard Cite

show abstract

“…In many cases, when the deadline is approaching a re-allocation of the human resources is made to increase the chances of delivering critical and important features in the established deadlines. 3) Requirements volatility [19], known as one of the main causes of software project failure. Despite advances in software engineering over the last decades, most software projects still experience considerable requirements' changes during their development as a consequence of customers' required changes, initial requirement misunderstanding, technology change, or even political changes.…”

Section: Human Resources Allocation In Project Managementmentioning

confidence: 99%

Project Schedule Simulation: Incorporating Human Factors’ Uncertainty and Features’ Priority in Task Modeling

Mizouni

Lazarova-Molnar

2015

JSW

View full text Add to dashboard Cite

Abstract:Despite several attempts to accurately predict duration and cost of software projects, initial plans still do not reflect real-life situations. Since commitments with customers are usually decided based on these initial plans, software companies frequently fail to deliver on time and many projects overrun both their budget and time. To improve the quality of initial project plans, we show in this paper the importance of (1) reflecting features' priorities/risk in task schedules and (2) considering uncertainties related to human factors in plan schedules.To make simulation tasks reflect features' priority as well as multimodal team allocation, enhanced project schedules (EPS), where remedial actions scenarios (RAS) are added, were introduced. They reflect potential schedule modifications in case of uncertainties and promote a dynamic sequencing of involved tasks rather than the static conventional way of modeling schedules. This paper describes a methodology to introduce EPS models in the development of project plans. Our case study findings show clearly the ability of the EPS model to anticipate delays due to human factors and to predict remedial scenarios to adjust to such delays. By comparing EPS to classical schedules, EPS simulation provides more accurate results with regards to project goals.These instructions give you guidelines for preparing papers for Journal of Software (JSW). Use this document as a template if you are using Microsoft Word 6.0 or later. Otherwise, use this document as an instruction set. The electronic file of your paper will be formatted further at Journal of Software. Define all symbols used in the abstract. Do not cite references in the abstract. Do not delete the blank line immediately above the abstract; it sets the footnote at the bottom of this column.

show abstract

Impact of requirements volatility on software architecture: How do software teams keep up with ever‐changing requirements?

Dasanayake

Aaramaa

Markkula

et al. 2019

J Software Evolu Process

View full text Add to dashboard Cite

Requirements volatility is a major issue in software development, causing problems such as higher defect density, project delays, and cost overruns. Software architecture that guides the overall vision of software product is one of the areas that is greatly affected by requirements volatility. Since critical architecture decisions are made based on the requirements at hand, changes in requirements can result significant changes in architecture. With the wide adoption of agile software development, software architectures are designed to accommodate possible future changes. However, the changes has to be carefully managed as unnecessary and excessive changes can bring negative consequences. An exploratory case study was conducted to study the impact of requirements volatility on software architecture. Fifteen semistructured, thematic interviews were conducted in a European software company. The research revealed poor communication, information distortion, and external dependencies as the main factors that cause requirement volatility and inadequate architecture documentation, inability to trace design rationale, and increased complexity as the main implications of requirements volatility on software architecture. Insights from software teams' awareness of the requirement volatility, factors contribute to it, and possible ways to mitigate its implications will be utilized to improve the management of requirement volatility during software architecting process. KEYWORDS requirements management, requirements volatility, software architecture, software teams INTRODUCTIONRequirements are added, deleted, and modified throughout the software development life cycle. Despite being seen as a natural characteristic of software projects, improper management of requirement changes can have adverse consequences on project cost, schedule, and quality of the resulting product. 1 Therefore, uncertain requirements are identified as one of the main factors that contribute to project failures. 2 While it is widely accepted that requirements changes are inevitable, significance of the potential consequences demands software teams to be aware of its existence, factors, and impacts. 3 Multiple terms including requirements change, requirements uncertainty, requirements instability, and requirements volatility are commonly associated with or related to the same phenomenon. 1,4 Requirements volatility is selected as the preferred term to be used in this study, as it not only indicates the change of requirements but also highlights their fragile nature and the potential to be changed.Software architecture that guides the overall vision of the software product is one of the areas that is greatly affected by requirements volatility. 5,6 Software architecture plays a prominent role in software development and acts as the foundation of the software systems that shapes the final outcome. Making suboptimal architecture decisions can decrease system quality and cause problems later on. 7 Since critical architecture decisions are primarily made base...

show abstract

Reducing the risk of requirements volatility: findings from an empirical survey

Cited by 14 publications

References 25 publications

Towards an understanding of the causes and effects of software requirements change: two case studies

Towards an understanding of the causes and effects of software requirements change: two case studies

Project Schedule Simulation: Incorporating Human Factors’ Uncertainty and Features’ Priority in Task Modeling

Impact of requirements volatility on software architecture: How do software teams keep up with ever‐changing requirements?

Contact Info

Product

Resources

About