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.

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.

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.

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.

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

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.

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.