Characterizing the Impact of Requirements Volatility on Systems Engineering Effort

Abstract

This paper describes the results of a study aimed at increasing the understanding of the causes of requirements volatility, its impact on systems engineering effort, and its changing dynamics over the system life cycle. The objective of the research is to improve the ability of systems engineers to anticipate and manage the effects of changing requirements. The ultimate goal of this study is to develop a model for quantifying the impact of requirements volatility on systems engineering effort that can be incorporated into the Constructive Systems Engineering Cost Model. Based on a review of the literature and expert judgment collected through surveys in five workshops, we identify five observations that summarize the key considerations of requirements volatility. First, a set of project organizational, technical, and contextual factors were ranked by subject matter experts in terms of their influence on requirements volatility. Their responses point to poor initial understanding of the system and customer needs as the leading cause of requirements volatility. Second, our results suggest that, while volatility tends to decrease over time, the number of requirements changes may increase during transitions between life cycle phases. Third, requirements volatility increases the functional size of the project and causes rework of engineering products, driving an increase in systems engineering effort. Fourth, the effect of requirements volatility on systems engineering effort increases the later the change occurs in the system life cycle. Fifth, the effort impact of a requirements change varies depending on the type of change (added, deleted, and modified).

Project manager and systems engineer: a literature rich reflection on roles and responsibilities

“…With new systems, innovative elements have characteristics not yet fully measured or understood and subject to change (Peña & Valerdi, 2014). Their usage in the engineering of new systems increases the risk of incurring in unexpected properties with potential impacts on cost, time and system performance (Kossiakoff, et al, 2011).…”

Towards Measuring Software Requirements Volatility: A Retrospective Analysis

“…However, if topics did not appear in meetings, software faults using the metric cannot be predicted. Peña and Valerdi [19] discussed a number of factors (technical, organizational and contextual) that could lead to requirements volatility being identified, ranked, and depicted in a causal model diagram. Besides, survey results and workshop discussions resulted in a set of observations regarding the expected level and impact of requirements volatility across the system life cycle.…”

“…The impact of requirements volatility varies depending on the type of change [18] [19]. Sherif reported that the modification type of change is the least risky with the least effort especially with mission critical requirements [16].…”

“…Retrospective analysis is primarily concerned with the study of successive system versions itself [19] [28] It is a quantitative measure that can be used to study the requirements evolution and, in turn, the software evolution. Consider two software versions v1 and v2 with two sets of UCs: UC1 and UC2, Let N be the number new UCs in v2, R be the number of removed UCs from v1 and O be the number of initial UCs that exist in v1.…”

“…Furthermore, the volatility on requirements depends on several factors. For instance, one might be organizational complexity, the process maturity of the company, the phase of the life cycle, the volatility of the market and so on [1] [3][18] [19]. As a result of an increased number of interacting components, the more complex the system or product developed becomes, the higher is the volatility [11].…”