Search

Systems engineering continues to increase in importance. Therefore systems engineering practices need to continue to increase in rigor. One of these practices, critical to successful projects, is cost estimation. The parametric systems engineering cost estimating model COSYSMO 1.0 was introduced in 2005. Since then, some significant enhancements have been proposed. These include covering projects using development with reuse, development in the presence of requirements volatility, development for reuse, or development in a system-of-systems context. However, these enhancements have not been brought together into a single cost estimating model. The author’s recently completed parametric cost estimating model COSYSMO 3.0 does in fact include all these enhancements, plus many other detailed improvements to COSYSMO 1.0; furthermore, it’s an open model, allowing users to understand numerically exactly how its parameters affect cost estimates, and encouraging development of estimating tools. COSYSMO 3.0 will be presented, highlighting its coverage of these enhancements, and pointing out some of its unique properties.

This paper focuses on information systems (hereafter IS) requirements volatility during development projects. First, it provides a comprehensive research-based map that integrates measurements, antecedents, consequences and solutions for IS requirements volatility. Second, it offers insights into industry practices related to the key IS requirements volatility components identified in that map. Findings from a survey of 44 professionals leading IS development projects show that IS requirements volatility continues to be an issue most likely caused by requirements misspecification problems. Findings also present a ranking of the relative importance of possible solutions used to minimize that volatility. Implications for research and practice are discussed.

International audience; This paper describes an approach for requirements volatility in systems development. The methodology is based on an original traceability model. The impact of requirements on safety is outlined through backward and forward traceability.

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 signifiant 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 semi-structured, 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., Comment: Journal of Software: Evolution and Process, 03/2019

NPS NRP Executive Summary Project Summary: Software effort estimates are necessary and critical at an early phase for decision makers to establish initial budgets, and in a government context to select the most competitive bidder for a contract. The challenge is that estimated software requirements is the only size information available at this stage, compounded with the newly increasing adoption of agile processes in the United States (U.S.) Department of Defense (DoD). The objectives are to improve cost estimation by investigating available sizing measures, and providing practical effort estimation models for agile software development projects during the contract bidding phase or earlier. This analysis explores the effects of independent variables for product size, peak staff, and domain on effort. The empirical data for model calibration is from 20 industrial projects completed recently for the US DoD, among a larger dataset of recent projects using other lifecycle processes. Statistical results showed that initial software requirements is a valid size metric for estimating agile software development effort. Prediction accuracy improves when peak staff and domain are added as inputs to the cost models. It is concluded that these models may be used for estimates of agile projects, and evaluating software development contract cost proposals with inputs available during the bidding phase or earlier. ASN (RDA) Naval Center for Cost Analysis NPS-18-N363-A Approved for public release; distribution is unlimited.

Requirements volatility is a crucial risk factor in software projects as it directly results in cost and time overruns. Accurately predicting requirements volatility is important for better project management. This paper presents a systematic literature review that focuses on the prediction of the requirements volatility. This literature review aims to answer four research questions: 1) how is requirements volatility prediction applied to different software development methods? 2) What are the machine learning algorithms used to predict requirements volatility in software development? 3) What are the attributes (predictors) used to predict requirements volatility in software development? 4) What are the performance metrics for evaluating existing prediction models? This study presents predictors used in the literature and their performances.

Requirements volatility is a major issue in software (SW) development, causing problems such as project delays and cost overruns. Even though there is a considerable amount of research related to requirement volatility, the majority of it is inclined toward project management aspects. The relationship between SW architecture design and requirements volatility has not been researched widely, even though changing requirements may for example lead to higher defect density during testing. An exploratory case study was conducted to study how requirements volatility affects SW architecture design. Fifteen semi-structured, thematic interviews were conducted in the case company, which provides the selection of software products for business customers and consumers. The research revealed the factors, such as requirements uncertainty and dynamic business environment, causing requirements volatility in the case company. The study identified the challenges that requirements volatility posed to SW architecture design, including scheduling and architectural technical debt. In addition, this study discusses means of mitigating the factors that cause requirements volatility and addressing the challenges posed by requirements volatility. SW architects are strongly influenced by requirement volatility. Thus understanding the factors causing requirements volatility as well as means to mitigate the challenges has high industrial relevance.

The article of record as published may be found at http://dx.doi.org/10.1109/ESEM.2017.10 Background: Software effort estimates are necessary and critical at an early phase for decision makers to establish initial budgets, and in a government context to select the most competitive bidder for a contract. The challenge is that estimated software requirements is the only size information available at this stage, compounded with the newly increasing adoption of agile processes in the US DoD. Aims: The objectives are to improve cost estimation by investigating available sizing measures, and providing practical effort estimation models for agile software development projects during the contract bidding phase or earlier. Method: The analysis explores the effects of independent variables for product size, peak staff, and domain on effort. The empirical data for model calibration is from 20 industrial projects completed recently for the US DoD, among a larger dataset of recent projects using other lifecycle processes. Results: Statistical results showed that initial software requirements is a valid size metric for estimating agile software development effort. Prediction accuracy improves when peak staff and domain are added as inputs to the cost models. Conclusion: These models may be used for estimates of agile projects, and evaluating software development contract cost proposals with inputs available during the bidding phase or earlier.

This paper introduces a requirements entropy framework REF for measuring requirements trends and estimating engineering effort during system development. The REF treats the requirements engineering process as an open system in which the total number of requirements R transition from initial states of high requirements entropy HR, disorder and uncertainty toward the desired end state of HR min as R increase in quality. The cumulative requirements quality Q reflects the meaning of the requirements information in the context of the SE problem. The distribution of R among N discrete quality levels is determined by the number of quality attributes accumulated by R at any given time in the process. The number of possibilities P reflects the uncertainty of the requirements information relative to HR min . The HR is measured or estimated using R, N and P by extending principles of information theory and statistical mechanics to the requirements engineering process. The requirements information I increases as HR and uncertainty decrease, and ΔI is the additional information necessary to achieve the desired state from the perspective of the receiver. The HR may increase, decrease or remain steady depending on the degree to which additions, deletions and revisions impact the distribution of R among the quality levels. Current requirements volatility metrics generally treat additions, deletions and revisions the same and simply measure the quantity of these changes over time. The REF measures the quantity of requirements changes over time, distinguishes between their positive and negative effects in terms of Q,HR, and ΔI, and forecasts when a specified desired state of requirements quality will be reached, enabling more accurate assessment of the status and progress of the engineering effort. Results from random variable simulations suggest the REF is an improved leading indicator of requirements trends that can be readily combined with current methods. The additional engineering effort ΔE needed to transition R from their current state to the desired state can also be estimated. Simulation results are compared with measured engineering effort data for Department of Defense programs, and the results suggest the REF is a promising new method for estimating engineering effort for a wide range of system development programs.

Global software development (GSD) is a modern approach that is currently being adopted by software organisations, mainly because of significant return on investment it produces. In the GSD projects, the development teams operate under the three distributed dimensions: geographical, cultural and temporal distances which increases substantial communication difficulties and becomes the development activities more challenging especially related to requirement volatility. The objective of this study is to identify the relationship between requirements volatility, and GSD project success. We have proposed a GSD risk-based model that consider project performance risk as a mediating variable for analysing the impact of requirement volatility on GSD project success. A questionnaire study was conducted from the 103 GSD experts to validate the proposed model. The findings reveal that requirements volatility increases the project performance risk which has a negative impact on the GSD project success which can be managed by the flexible management.

Business process models greatly contribute to analyze and understand the activities of enterprises. However, it is still a challenge to cope with the complexity of systems specifications and their requirements. This issue of the journal of Complex Systems Informatics and Modeling (CSIMQ) presents papers that discuss topics on managing complexity and information systems engineering. The papers are extended versions of selected papers from the workshop on Continuous Requirements Engineering held at the requirements engineering conference REFSQ 2016 in Gothenburg, the workshop on Managed Complexity held at the business informatics conference BIR 2016 in Prague, and the CAiSE 2016 Forum held in Ljubljana.

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.

Advances in threats, geopolitical developments, and commercial technologies continually challenge combat system stability because they constantly create new demands and therefore requirements for the system. Because the life cycle of major Department of Defense (DoD) systems can last decades, long-fielded systems in particular are vulnerable to requirements creep. One technique to mitigate the impact requirements volatility can have on a system is through the implementation of technologies that have been developed to allow the system to adapt while minimizing the effect of change on the system as a whole. This paper investigates the application of one such technology-Rules Engine-to the Decision Automation domain of two Navy combat systems. This paper also proposes modifications to the systems engineering process given that using change-tolerant technologies affects the way a system can be developed and maintained.

In an organization operating in the bancassurance sector we identified a low-risk IT subportfolio of 84 IT projects comprising together 16,500 function points, each project varying in size and duration, for which we were able to quantify its requirements volatility. This representative portfolio stems from a much larger portfolio of IT projects. We calculated the volatility from the function point countings that were available to us. These figures were aggregated into a requirements volatility benchmark. We found that maximum requirements volatility rates depend on size and duration, which refutes currently known industrial averages. For instance, a monthly growth rate of 5% is considered a critical failure factor, but in our low-risk portfolio we found more than 21% of successful projects with a volatility larger than 5%. We proposed a mathematical model taking size and duration into account that provides a maximum healthy volatility rate that is more in line with the reality of low-risk IT portfolios. Based on the model, we proposed a tolerance factor expressing the maximal volatility tolerance for a project or portfolio. For a low-risk portfolio its empirically found tolerance is apparently acceptable, and values exceeding this tolerance are used to trigger IT decision makers. We derived two volatility ratios from this model, the π-ratio and the ρ-ratio. These ratios express how close the volatility of a project has approached the danger zone when requirements volatility reaches a critical failure rate. The volatility data of a governmental IT portfolio were juxtaposed to our bancassurance benchmark, immediately exposing a problematic project, which was corroborated by its actual failure. When function points are less common, e.g. in the embedded industry, we used daily source code size measures and illustrated how to govern the volatility of a software product line of a hardware manufacturer. With the three real-world portfolios we illustrated that our results serve the purpose of an early warning system for projects that are bound to fail due to excessive volatility. Moreover, we developed essential requirements volatility metrics that belong on an IT governance dashboard and presented such a volatility dashboard. © 2008 Elsevier B.V. All rights reserved.

In new product development, design requirements are a formalization of a product vision and can evolve substantially in the early stages of product design. This paper describes an empirical study of the relationships among design requirements volatility, risk, prioritization and the quality of design outcome in the context of a graduate level product development course for mid-career professionals. Among other findings, a pattern of decreasing risk of a design requirement, especially the risk of high priority requirements, was found to be a key predictor of success. The findings suggest the importance of managing design requirement risk in early stage design and the potential benefit of using risk and priority level of design requirements to monitor design project health.Copyright © 2015 by ASME

This chapter will give readers a number of best practices to improve the quality of the requirements elicitation and development process in their organization. Formulation of high quality requirements (complete, concise, accurate, modular, prioritized, analyzed, verified, and testable) reduce project risk, improve product quality, and allow for effective control of requirements volatility, which increases the likelihood of a successful project.

One of the main recommended practices to enhance software development process is dealing with requirement change. It represents risks to the success and completion of a project. In this paper a comprehensive review on the impact of Software Requirement Change has been conducted. The literature was written in a historical way and divided into four periods. The results of this review show that most addressed fields in this topic studied the requirement change impact on the time (schedule) and the cost of the software project. Furthermore open research directions in this field are proposed.

Initial margin requirements represent: (1) a cost impediment to the wealth constrained investor and (2) a potential way of mitigating excessive volatility. However, prior empirical research finds that margins are not an effective tool in reducing volatility. We consider the possibility that margins primarily affect certain stocks and investors. Specifically, we test whether margins affect individuals who, as a group, we believe to be the investors most affected when margin requirements change. Our initial empirical tests, however, do not support this contention.

Requirements volatility is a common phenomenon present in most software development projects. Change Management dealing with requirement changes is an important function of project managers. If the changes are not handled effectively, then there will be huge difference in efforts, cost, and quality of the Product which results in project delay or project may be failed. Taxonomy of requirements change consists of three components: Change Type, Reason, and Sources. Changes in requirements are additions, deletion or modifications of requirements. These changes to the requirements after the basic set has been agreed to by both clients and maintainers are known as requirement’s volatility. Requirements volatility cannot be avoided, but we have to understand the requirements volatility problems to deal with the impact. In this paper we have reviewed the requirement volatility, identified the reasons and sources of changes, and introduced few guidelines to managing changes effectively.

COTS integration is well accepted and is a viable solution offering for most of business problems. In this paper we enhance the basic effort estimation methodology to align to more requirements centric approach for development, testing and deployment. The paper is structured with best practices to ease projects that involve multiple estimation cycles with extremely high requirements volatility. The estimation approach and practices mentioned can be used as a reusable approach for estimations across multiple COTS integrations.

For high quality software, software requirements must be complete. In practice, not all software requirements are complete. In case of incomplete software requirements, software engineers fill in the requirements' gaps by getting feedback from the stakeholders or by making explicit or implicit assumptions. Explicit assumptions can be validated during analysis, while implicit assumptions validation is carried to design and implementation. Thus, compared to implicit assumption, explicit assumptions are better. Software requirements specifications change during different phases of project life-cycle. In an attempt to improve software development processes, we conducted an empirical study to search possible relationships between the number of implicit assumptions made by software engineers and requirements' volatility. This practice paper presents data from three completed projects at one CMMI level 3 company. Within the limit of our data set, our experience shows that possible relationships between projects' requirements volatility and the number of implicit assumptions are worth studying.

Requirements volatility is an important risk factor for software projects. Software measures can help in quantifying and predicting this risk. In this paper, we present the results of a correlational study with the goal of predicting requirements volatility for a medium size software project. Based on the data collected from two industrial software projects for four measures of size of requirements (number of actors, use cases, words, and lines), we have evaluated prediction models for requirements volatility. These models can help project managers to estimate the volatility of requirements and minimize the risks caused by volatile requirements, like schedule and cost overruns. In cross systems validation our best model showed a mean magnitude of relative error (MMRE) of 0.25, which can be considered reliable. In an earlier study, we showed that decisions solely based on developers perception of requirements volatility are, instead unreliable. Predictions models, like the ones presented here, can therefore help taking more reliable decisions.

Requirements volatility is an important risk factor for software projects. Software measures can help in quantifying and predicting this risk. In this paper, we present an industrial case study that investigated measures of volatility for a medium size software project. The goal of the study was twofold: 1) to empirically validate a set of measures associated with the volatility of use case models (UCM); 2) to investigate the correlation between subjective and objective volatility. Measurement data was collected in retrospect for all use case models of the software project. In addition, we determined subjective volatility by interviewing stakeholders of the project. Our data analysis showed a high correlation between our measures of size of UCM and total number of changes, indicating that the measures of size of UCMs are good indicators of requirements volatility. No correlations was found between subjective and objective volatility. These results suggest that project managers at this company should measure their projects because of the risk to take wrong decisions based on their own and the developer's perceptions.

A discussion on object-oriented analysis (OOA) is summarized. Among the topics discussed are: whether objects facilitate understanding; whether autonomy facilitates understanding; whether OOA encourages premature design; whether OOA addresses requirements volatility; the Shlaer-Mellor method; the separation of problem domains; the translation of domains; the role of prototyping in requirements engineering; tool support; and the question of distinguishing models from requirements. >

This paper describes analysis techniques used to quantitatively assess the software maintenance process of a large military contractor, and the results obtained. The analysis techniques make use of basic data collected throughout the maintenance process. The data collected are extensive and allow a set of functional enhancements to be traced to process activities and product impact. Simple nonparametric statistical techniques are then applied to test relationships between data items. The results provide valuable information for predicting process and product characteristics, and assessing the maintenance process.