Strategies for managing requirements creep

Jones, Capers

doi:10.1109/2.507640

Cited by 50 publications

(45 citation statements)

References 0 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…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. However, Weiss [25] observes that more than 75 % of changes took a day or less to make and that relatively few changes resulted in errors.…”

Section: Empirical Studies Of Requirements Volatility During Softwarementioning

confidence: 99%

“…However, requirements changes can vary greatly in terms of their cost and value; the metric 'requirements changes = 2' that results from the addition of one change costing £100 to a second change at a cost of £1,000 is not that informative. One solution is to measure the size of the change by function points [4,5]. However, there may be other qualities, such as value or stakeholder involvement, which are important considerations for change management.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

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: Empirical Studies Of Requirements Volatility During Softwarementioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

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

“…Requirements inspections reduce requirements creep by nearly 30% [Jon96]. The EPRAM model introduces requirements inspection via a series of risk assessment meetings held to discuss newly identified requirements.…”

Section: Discussion and Future Workmentioning

confidence: 99%

“…Requirements creep can be especially troublesome t o developers when it is not properly managed, due to the detrimental impact such changes may have on cost, resources, quality, or the ability to deliver a system that incorporates the new requirements on time. While it can be argued that the majority of software applications have unstable requirements and that some degree of requirements creep is observed in all requirements methodologies [Jon96], evolutionary prototyping i s particularly susceptible to significant changes i n requirements [Gra89,Gra91].…”

Section: Introductionmentioning

confidence: 99%

Evolving beyond requirements creep: a risk-based evolutionary prototyping model

Carter

Antón

Dagnino

et al.

Proceedings Fifth IEEE International Symposium on Requirements Engineering

View full text Add to dashboard Cite

show abstract

“…The most significant factor to cause these project failures were attributed to changing requirements [30]. The biggest cause for project failures happens to be lack of user input, and changing or incomplete requirements [15,18,22]. Roughly 25% of the requirements for an average project change before project completion [22], and volatile requirements tend to make the testing activities difficult and cause the software to contain high defect density [17].…”

Section: Prioritization Factorsmentioning

confidence: 99%