An industrial case study on requirements volatility measures

Loconsole, Annabella; Börstler, Jürgen

doi:10.1109/apsec.2005.38

Cited by 22 publications

(26 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…From case study data collected in retrospect on fourteen Use Case Models (UCM) comprising 39 use cases, Loconsole [1] observed a significant correlation between the number of lines in a UCM and requirements volatility, and recommended modularization of larger UCMs. In contrast to the predictive approach by correlation, a number of researchers are seeking to develop and evaluate more complex causal relationships [27][28][29].…”

Section: Requirements Change Predictionmentioning

confidence: 99%

“…This has been used in the prediction of requirements change [1], as the measure of the health of a project [2], and to support process technique selection [3]. 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.…”

Section: Introductionmentioning

confidence: 99%

“…The case studies presented in this paper are part of a family of collaborative empirical initiatives, each of which makes progress towards the ultimate goal of requirements change anticipation. Loconsole [1] provides a model to predict requirements change which utilises the observed correlation between the size of a requirements use case document and volatility. While correlation is significant, there is no claim made with respect to causality.…”

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

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: Requirements Change Predictionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

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

show abstract

“…Loconsole et al [13] defined the term volatility as "the amount of changes to a use case over time." Their results imply that volatility is a characteristic of requirements written in use cases.…”

Section: Related Workmentioning

confidence: 99%

Estimation of the Maturation Type of Requirements from Their Accessibility and Stability

Nakatani

Hori

Katamine

et al. 2014

IEICE Trans. Inf. & Syst.

View full text Add to dashboard Cite

SUMMARYThe success of any project can be affected by requirements changes. Requirements elicitation is a series of activities of adding, deleting, and modifying requirements. We refer to the completion of requirements elicitation of a software component as requirements maturation. When the requirements of each component have reached the 100% maturation point, no requirement will come to the component. This does not mean that a requirements analyst (RA) will reject the addition of requirements, but simply, that the additional requirements will not come to the project. Our motivation is to provide measurements by which an RA can estimate one of the maturation periods: the early, middle, or late period of the project. We will proceed by introducing the requirements maturation efficiency (RME). The RME of the requirements represents how quickly the requirements of a component reach 100% maturation. Then, we will estimate the requirements maturation period for every component by applying the RME. We assume that the RME is derived from its accessibility from an RA to the requirements source and the stability of the requirements. We model accessibility as the number of information flows from the source of the requirements to the RA, and further, model stability with the requirements maturation index (RMI). According to the multiple regression analysis of a case, we are able to get an equation on RME derived from these two factors with a significant level of 5%. We evaluated the result by comparing it to another case, and then discuss the effectiveness of the measurements.

show abstract

“…It is clear that RM is a fundamental activity in RE. However, it has become a challenge because requirements change has been reported as one of the main factors affecting the project delays or project cost overruns, if not causing complete failure [5]] [9][12] [13][14] [15].…”

Section: Introductionmentioning

confidence: 99%

Towards Measuring Software Requirements Volatility: A Retrospective Analysis

Ebad

2017

MJCS

View full text Add to dashboard Cite

Requirement management (RM) is a fundamental activity in requirements engineering. It keeps track of all the requirements changes that would cause errors or resulted in software delays or cost overruns. When requirements have many changes over time, they have a tendency to be highly volatile. This volatility depends on several factors such as organizational complexity, process maturity of the company, and development phase. Managing the requirements quantitatively by metrics is a good way to understand whether RM is efficient or not. In this paper, we propose a new metric to measure the requirements volatility of object-oriented systems in terms of use cases; we use retrospective analysis that examines the amount of change applied in successive versions of a software product. We theoretically validated our metric through a set of prominent mathematical properties. We also empirically validated our metrics using three versions of an open source project, JHotDraw. Measurements of the metric were shown to be consistent with previous measurements of the JHotDraw versions conducted at the architecture design level. The study results in a foundation for further empirical retrospective studies of the requirements properties.Keywords: requirements engineering, requirements volatility, requirements management, software metrics, use cases, software evolution. INTRODUCTIONSoftware requirements describe the services provided by the system and its operational constraints [1] [2]. These requirements reflect the needs of system stakeholders (including paying customers, users and developers). The process of finding out, analyzing, documenting, and checking these services and constraints is called requirements engineering (RE) . From an evolution perspective, volatile requirements are likely to change after the system has been become operational or during the system development process. An example, is the requirements resulting from government healthcare policies [2]. These requirements must evolve to reflect the changed view of the system in development. Furthermore, the

show abstract

An industrial case study on requirements volatility measures

Abstract: Requirements volatility is an important risk factor for software projects. Software

Cited by 22 publications

References 32 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

Estimation of the Maturation Type of Requirements from Their Accessibility and Stability

Towards Measuring Software Requirements Volatility: A Retrospective Analysis

Contact Info

Product

Resources

About