Software Requirements Changes Research Articles

Change management methodologies trained for automotive infotainment projects

An Automotive Electronic Control Units (ECU) development project embedded within a car Environment is constantly under attack of a continuous flow of modifications of specifications throughout the life cycle. Root causes for those modifications are for instance simply software or hardware implementation errors or requirement changes to satisfy the forthcoming demands of the market to ensure the later commercial success. It is unavoidable that from the very beginning until the end of the project “requirement changes” will “expose” the agreed objectives defined by contract specifications, which are product features, budget, schedule and quality. The key discussions will focus upon an automotive radio-navigation (infotainment) unit, which challenges aftermarket devises such as smart phones. This competition stresses especially current used automotive development processes, which are fit into a 4 Year car development (introduction) cycle against a one-year update cycle of a smart phone. The research will focus the investigation of possible impacts of changes during all phases of the project: the Concept-Validation, Development and Debugging-Phase. Building a thorough understanding of prospective threats is of paramount importance in order to establish the adequate project management process to handle requirement changes. Personal automotive development experiences and Literature review of change- and configuration management software development methodologies led the authors to new conceptual models, which integrates into the structure of traditional development models used in automotive projects, more concretely of radio-navigation projects.

Management of Changes in Software Requirements during Development Phases

Change, in software requirements during its development phases, is considered as a major risk which may affect a software project to fail. Therefore, software engineering processes, methods, and tools are used in order to manage these risks whereas changes in requirements have many negative influences such as effects on system development life cycle (SDLC) phases, project progress, and outcome of a software project. Consequently, project managers must use risk management strategies, activities, and estimation techniques in order to manage and mitigate these risks which are caused due to changes in requirements. A novel model is proposed in this paper to manage and mitigate risks related to changing requirements. The proposed model is validated through qualitative research design. The results are in favor of the proposed model to show its effectiveness. It is anticipated that the proposed model will solve the problems of software companies in major to deal with risks about changing requirements.

From requirements to source code: a Model-Driven Engineering approach for RESTful web services

During the last few years, the REST architectural style has drastically changed the way web services are developed. Due to its transparent resource-oriented model, the RESTful paradigm has been incorporated into several development frameworks that allow rapid development and aspire to automate parts of the development process. However, most of the frameworks lack automation of essential web service functionality, such as authentication or database searching, while the end product is usually not fully compliant to REST. Furthermore, most frameworks rely heavily on domain specific modeling and require developers to be familiar with the employed modeling technologies. In this paper, we present a Model-Driven Engineering (MDE) engine that supports fast design and implementation of web services with advanced functionality. Our engine provides a front-end interface that allows developers to design their envisioned system through software requirements in multimodal formats. Input in the form of textual requirements and graphical storyboards is analyzed using natural language processing techniques and semantics, to semi-automatically construct the input model for the MDE engine. The engine subsequently applies model-to-model transformations to produce a RESTful, ready-to-deploy web service. The procedure is traceable, ensuring that changes in software requirements propagate to the underlying software artefacts and models. Upon assessing our methodology through a case study and measuring the effort reduction of using our tools, we conclude that our system can be effective for the fast design and implementation of web services, while it allows easy wrapping of services that have been engineered with traditional methods to the MDE realm.

Generic Approach for Goal Driven Software Requirement Risk Management

An analysis of many software program assignments in between 2011, as well as 2014, shows an interesting pattern. Author identified areas which may lead to project failure which are weak requirement analysis and management, weak cost calculating, weak handling of requirement change requests, weak milestone monitoring and requirement gold plating habit. By comparison, prosperous local software program assignments tended to be much better than onsite software development and management. Maybe the most interesting part of most of these many problem areas can be that each is regarding project managing instead of using technical personnel. We focused over the impact of software requirement change requests and requirement gold plating while dealing with onsite project assignments. Author also evaluated new model to avoid global software engineering requirement failure, which in turn curtails the estimated time and budget with client satisfaction. In this paper, Author discuss the ideas that support requirements reflection as a means to articulate some of the outstanding research challenges. General Terms Software Engineering

Software Requirement Engineering Risk Prediction Model

Analysis of many software program assignments from 2011 through 2014 shows interesting patterns. When you compare large assignments that have efficiently attained their own cost as well as schedule quotes versus the ones that ran delayed, ended up over spending budget, or maybe ended up, half a dozen popular difficulties ended up noticed: weak requirement analysis and management, weak cost calculating, weak handling of requirement change requests, weak milestone monitoring as well as requirement gold plating habit. By comparison, prosperous local software program assignments tended to be much better than on-site software development and management. Maybe the most interesting part of most of these many problem areas can be like everyone is coordinating project management instead of using technical focus. Author focused over the impact of software requirement change requests and requirement gold plating while dealing with on-site project assignments. Author also evaluated new algorithmic model to avoid global software engineering requirement failure, which in turn curtails the estimated time and budget with client satisfaction.

An Enhanced Negotiation-Style Framework for Requirements Change

There are many uncontrolled requirements changes existed in the software requirements engineering. Currently, under the premise of managing the software requirements changes using the logic-based technique, there is a framework that be proposed by Ke-Dian Mu etc based on Booth Negotiation-Style which managed the requirements changes conveniently and effectively. On the basis of the Mu's framework, this paper presents a selection strategy for selecting the negotiation scheme, which perfected the part that can be improved and managed the software requirements changes flexibly and effectively.

Towards an understanding of the causes and effects of software requirements change: two case studies

Abstract 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.

Managing software requirements changes based on negotiation-style revision

For any proposed software project, when the software requirements specification has been established, requirements changes may result in not only a modification of the requirements specification but also a series of modifications of all existing artifacts during the development. Then it is necessary to provide effective and flexible requirements changes management. In this paper, we present an approach to managing requirements changes based on Booth's negotiation-style framework for belief revision. Informally, we consider the current requirements specification as a belief set about the system-to-be. The request of requirements change is viewed as new information about the same system-to-be. Then the process of executing the requirements change is a process of revising beliefs about the system-to-be. We design a family of belief negotiation models appropriate for different processes of requirements revision, including the setting of the request of requirements change being fully accepted, the setting of the current requirements specification being fully preserved, and that of the current specification and the request of requirements change reaching a compromise. In particular, the prioritization of requirements plays an important role in reaching an agreement in each belief negotiation model designed in this paper.

Impact propagation and risk assessment of requirement changes for software development projects based on design structure matrix

Requirement change is a major source of risk to software development projects. The prediction of requirement changes provides a challenge in software risk management, especially in early stages of software development projects. This paper predicts the risk of change propagation in terms of change propagation probability and change impact. First, the process of software requirement changes is discussed. Then, a probabilistic model based on design structure matrix (DSM) is established to evaluate the risk of change propagation from requirements to software architecture. Furthermore, the proposed model is utilized to estimate the schedule and cost of a software development project. The model supports the prediction of potential risk of change propagation for each component, which is able to accommodate module reorganization to avoid unnecessary redesigns. Thus it helps software project managers make a choice between different architecture candidates based on requirement changes. Finally, the proposed model is verified via computational experiments, in which sensitivity analysis is applied to validate the reliability of the model.

Managing Software Requirements Changes Based on Negotiation-Style Revision

Managing Software Requirements Changes Based on Negotiation-Style Revision

Developing a profit and loss (P&L) model for mid-development software requirement change

Requirement changes early in the software design process are an expected part of the iterative development process and have been effectively analyzed [1] and modeled [2]. Mid-project requirement ch...

9.4.2 The Biggest Peoplesoft Implementation Ever – Implications for Systems Engineering

AbstractThis paper describes the largest Commercial Off The Shelf (COTS) human resources implementation ever attempted. The Department of Defense has chosen to combine its payroll and personnel functions for all four branches of the military: Army, Navy, Air Force and Marines. The software they have chosen is Peoplesoft. Changes will occur for a variety of technical and political reasons, including Peoplesoft release updates, hardware updates, supporting software updates, requirements changes, funding changes and changes in Congressional leadership. How will the project deal with these changes? System engineering expertise is needed to manage the change that will occur inevitably on a COTS implementation as massive as this one is.

An architecture for software that adapts to changes in requirements

The goal of the research presented in this paper was to study a new software paradigm – adaptive software – in which the structure of an adaptive program is patterned upon the structure of an adaptive controller. Towards this aim, we implemented a domain-specific (object/target recognition) program (A Reconfigurable Architecture for Adapting to Changes in the Requirements (RAACR)) that can adapt to changes in software requirements through the incorporation of feedback. RAACR is a hierarchy of domains (blackboards). Each domain includes multiple knowledge sources (KSs) and a domain scheduler (DS). In response to feedback, KSs change their processing parameters, while DSs change the scheduling policy of the KSs. A generic communication mechanism is implemented on the CORBA compliant SPRING operating system. The adaptability of the program is evaluated quantitatively using a requirements volatility measure and the probability of correct recognition.