Software Requirements Changes Research Articles

Supporting Emotional Intelligence, Productivity and Team Goals while Handling Software Requirements Changes

Background: Research shows that emotional intelligence (EI) should be used alongside cognitive intelligence during requirements change (RC) handling in Software Engineering (SE), especially in agile settings. Objective: We wanted to study the role of EI in-depth during RC handling. Method: We conducted a mixed-methods study (an interview study followed by a survey study) with 124 software practitioners. Findings: We found the causal condition, intervening condition and causes lead to key direct consequences of regulating own emotions, managing relationships, and extended consequences of sustaining productivity, setting and sustaining team goals. We found several strategies of supporting EI during RC handling. Further, we found strong correlations between six strategies and one being aware of own emotions, regulating own emotions, sustaining team productivity, and setting and sustaining team goals. Conclusion: Empathising with others and tracking commitments and decisions as a team are key strategies that have strong correlations between managing emotions, between sustaining team productivity, and between setting and sustaining team goals. To the best of our knowledge, the framework we present in this paper is the first theoretical framework on EI in SE research. We provide recommendations for software practitioners to consider during RC handling.

Causes and Mitigation Practices of Requirement Volatility in Agile Software Development

One of the main obstacles in software development projects is requirement volatility (RV), which is defined as uncertainty or changes in software requirements during the development process. Therefore, this research tries to understand the underlying factors behind the RV and the best practices to reduce it. The methodology used for this research is based upon qualitative research using interviews with 12 participants with experience in agile software development projects. The participants hailed from Austria, Nigeria, the USA, the Philippines, Armenia, Sri Lanka, Germany, Egypt, Canada, and Turkey and held roles such as project managers, software developers, Scrum Masters, testers, business analysts, and product owners. Our findings based on our empirical data revealed six primary factors that cause RV and three main agile practices that help to mitigate it. Theoretically, this study contributes to the body of knowledge relating to RV management. Practically, this research is expected to aid software development teams in comprehending the reasons behind RV and the best practices to effectively minimize it.

Requirement Change Prediction Model for Small Software Systems

The software industry plays a vital role in driving technological advancements. Software projects are complex and consist of many components, so change is unavoidable in these projects. The change in software requirements must be predicted early to preserve resources, since it can lead to project failures. This work focuses on small-scale software systems in which requirements are changed gradually. The work provides a probabilistic prediction model, which predicts the probability of changes in software requirement specifications. The first part of the work considers analyzing the changes in software requirements due to certain variables with the help of stakeholders, developers, and experts by the questionnaire method. Then, the proposed model incorporates their knowledge in the Bayesian network as conditional probabilities of independent and dependent variables. The proposed approach utilizes the variable elimination method to obtain the posterior probability of the revisions in the software requirement document. The model was evaluated by sensitivity analysis and comparison methods. For a given dataset, the proposed model computed the low state revisions probability to 0.42, and the high state revisions probability to 0.45. Thus, the results proved that the proposed approach can predict the change in the requirements document accurately by outperforming existing models.

CoDEvo: Column family database evolution using model transformations

In recent years, software applications have been working with NoSQL databases as they have emerged to handle big data more efficiently than traditional databases. The data models of these databases are designed to satisfy the requirements of the software application, which means that the models must evolve when the requirements of the software application change. To avoid mistakes during the design and evolution of these NoSQL models, there are several methodologies that recommend using a conceptual model. This implies that consistency between the conceptual model and the schema must be maintained when either evolving the database or the software application. In this work, we propose CoDEvo, a model-driven engineering approach that uses model transformations to address the evolution of a NoSQL column family DBMS schema when the underlying conceptual model evolves due to software requirement changes, aiming to maintain consistency between the schema and conceptual model. We have addressed this problem by defining transformation rules that determine how to evolve the schema for a specific conceptual model change. To validate these transformations, we applied them to conceptual model changes from 9 open-source software applications, comparing the output schemas from CoDEvo with the schemas that were defined in these applications.

Constructing Traceability Links between Software Requirements and Source Code Based on Neural Networks

Software requirement changes, code changes, software reuse, and testing are important activities in software engineering that involve the traceability links between software requirements and code. Software requirement documents, design documents, code documents, and test case documents are the intermediate products of software development. The lack of interrelationship between these documents can make it extremely difficult to change and maintain the software. Frequent requirements and code changes are inevitable in software development. Software reuse, change impact analysis, and testing also require the relationship between software requirements and code. Using these traceability links can improve the efficiency and quality of related software activities. Existing methods for constructing these links need to be better automated and accurate. To address these problems, we propose to embed software requirements and source code into feature vectors containing their semantic information based on four neural networks (NBOW, RNN, CNN, and self-attention). Accurate traceability links from requirements to code are established by comparing the similarity between these vectors. We develop a prototype tool RCT based on this method. These four networks’ performances in constructing links are explored on 18 open-source projects. The experimental results show that the self-attention network performs best, with an average Recall@50 value of 0.687 on the 18 projects, which is higher than the other three neural network models and much higher than previous approaches using information retrieval and machine learning.

Design and implementation of the whole process collaborative system for software development

With the increasingly urgent and arduous task of software development, software engineering development tools that can efficiently respond to the continuous changes in software requirements, rationally plan the software development process, and control the development cost will be widely used in software engineering. In response to actual needs, the supporting tool is designed to meet the system requirements, software requirements and software design and development. First, we use visualization modeling optimization technology of structured analysis and design method to build demand analysis models and system design models; Secondly, the dynamic verification technology of data model logical consistency is adopted to verify the logical consistency of data model in evolution; finally, the verification of the system model is achieved through hierarchical flow diagrams, fully expanded flow diagrams and statistical views. The vehicle cruise control system is selected for application verification, and the tool meets the requirements of software development and improves the software quality.

Measures Driven Change Impact Analysis Approach for Prioritizing Software Requirements Changes

Measures Driven Change Impact Analysis Approach for Prioritizing Software Requirements Changes

Design and Practice of Software Architecture in Agile Development

Software architecture design is a very critical part of the software development process. In order to be able to respond to changes in user requirements in software development in a timely manner, a convenient and lightweight development model should be adopted. Agile development adopts a human-oriented, step-by-step development process that can quickly respond to changes in software requirements, adjust the design of software architecture in a timely manner and adapt to software development in a dynamic environment. Based on the analysis and comparison of traditional development process and agile development process, this paper analyzes the key technologies in agile architecture design and proposes a software architecture design method based on agile development mode.

Agile Software Development Techniques: A Survey

In this IT era, where there is a race of software development, it is necessary to introduce such types of software development techniques which will help the practitioners to deliver fast solutions. In the past, various traditional approaches were used for this purpose, but now agile techniques are getting more popular because conventional software development approaches are not efficient in managing the changing requirements. The agile software development process is one of the most emerging lightweight software development methodologies, which uses iterative and prototype development approaches to accommodate changes in software requirements. Final software products are delivered to the end-users in short iterations. One of the most noticeable drawbacks of agile methods is their limited courtesy to the structured and architectural design of the system. Hence this development approach will restrict small to medium design decisions only. In this paper, we have performed the analysis of different agile techniques, which will help the readers to understand their positive and negative points and select the most appropriate technique suited to their projects.

Critical Success Factors and Challenges in Agile Requirements Engineering

Nowadays, the requirements of the software are changing rapidly in order to meet clients’ needs, which increases the complexity of developing software. Thus, Agile requirements engineering has arisen and it focuses on how to deal with the increasing changes in software requirements by gathering requirements iteratively and collaboratively with the clients. Thus, the clients’ satisfaction could be met more easily. On the other side, researchers have tried to improve agile requirements engineering from time to time, however, there are still limitations and challenges faced, which need more attention. Thus, this study is conducted by performing a systematic literature review technique to investigate the challenges, critical success factors, and the topics that need more attention in the agile requirements engineering field. In the beginning, the study obtained 178 articles related to this topic which were published from 2002 until 2019. After a thorough analysis of the articles, the study reviewed the ten (10) challenges and the proposed solutions that mentioned in the previous studies. Besides that, the study found six (6) critical success factors, and highlighted four (4) topics that need more attention from the researchers in future studies in agile requirements engineering.

RETRACTED: Dynamic simulation modelling of software requirements change management system

Changes in the Software requirements, technological advances require flexibility in software system development. Unexpected changes and mistakes cause difficulties. They effectively manage destructive changes, rework, and errors; project managers need to consider dynamic behavior loops of feedback on lead delays and disturbances. System Dynamics (SD) modeling methods have been used in the last few decades to meet this demand for analytical and project performance improvement. The SD model is used to improve the simulated change management policy for the Iranian project in the project's planning and petrochemical industry. Dynamic simulations of the SD model. The results show that effective Knowledge Management (KM) is a crucial control factor for the project's mechanically essential controls. Therefore, the proposal on the Knowledge Management aspect and attempts are to improve the manufacturing industry model. Effective formulation of dynamic simulation models project change management policy, time, consider Cost, quality, resources, and financial indicators. This model, such as financing, outsourcing activities, adjustment of the schedule, labor management, etc., to compare the alternative change management strategy in terms of the project's performance indicators to enable the decision-makers.

Role of Critical Success Factors in Offshore Quality Requirement Change Management Using SLR

In software engineering field, requirement change management is a challenging job. Ignoring incoming changes results in customer displeasure. It may also result in late product transportation. Managing requirement changes in poor way is the main cause of product failure. It has more diverse effect in global software outsourcing. In software quality requirement change management, it is necessary to address success factors in order to accomplish the requirements of the customers. In this paper, systematic literature review approach is used for documentation and scrutinization of success factors. Total sixteen success factors were recognized having great impact on quality software requirement change management. Our identified success factors like `Proper Requirement Change Management', `Rapid Delivery', `Quality Software Product, Access to Market', `Project Management', `Skills and Methodologies', `Low Cost/Effort Estimation', `Clear Plan and Road Map', `Agile Processes', `Low Labor Cost', `User Satisfaction', `Communication/Close Coordination', `Proper Scheduling and Time Constraints', `Frequent Technological Changes', `Robust Model', `Geographical juncture/Cultural differences' are the crucial factors that affect software quality requirement change. Company size and different database have been used for the analysis of success factors. The databases/search engine used are Google scholar, Science Direct, IEEE Explore and Springer for the exploration of success factors. Companies are analyzed on the basis of their size such as small, medium and large.

A method of assessing rework for implementing software requirements changes

Software development is often affected by user/system requirements changes. To implement requirements changes, a system which is being developed needs to be reworked. However, the term ?Rework? has not been clearly defined in the literature. Depending on the complexity of the changes, the amount of rework required varies from some software module modifications to a non-trivial alteration to the software design of a system. The effort associated with such a rework obviously will vary too. To date, there has been scant research on rework assessment, and the relationship between it and change effort estimation is hardly understood. In this paper, we present a definition for rework, and describe a method of assessing rework for implementing software requirements changes. Our method consists of three stages: namely (i) change identification; (ii) change analysis; and (iii) rework assessment. To demonstrate the practicality that it enables developers to compare the rework between the different options available for implementing a requirements change and to identify the one which is less invasive and requires lesser amount of modifications to the software system design, we explain our concept with the use of a running example.

Pricing and Contract Design for Software Products in the Presence of Requirements Change

The presence of software requirements change (RC) during project development is a critical challenge for the developer to offer software contract designs. Because under the presence of RC, the decisions toward the contract offer will impact to project’s price spent by the developer. Managers of software companies must decide what contract designs to offer to clients in the development of software. ing from an example drawn from the software industry, we exhibit three designs of software contracts incorporating fixed price (FP) and time-and-materials (T&M) policies. Specifically, a software company offers a fixed-price and agree to RC with adjustment cost (SW contract), or initially provides a fixed price and then charges an additional fee based on the time-and-material in response to RC (MP contract). We examine the strategic choices of two contract designs in a two-stage game. We carry out a full analysis of distinct settings of monopoly model. We characterize the conditions under which the contracts can be the best decision for developers. As the result, we found that the MP contract performed better when accommodating the presence of RC instead of the SW contract.

Empirical Study of Function Point Analysis during Software Development Phase

During the development of the software, Software Requirement Changes (SRC) often occurs. Software estimation helps in maintaining a balance between the increase and decrease of the price, time, etc. Function Point Analysis (FPA) is a software effort estimation technique used for measuring the size and complexity of software by calculating the functionality from a user's point of view. Function count focuses on what functionality is being delivered. It enables programmers to perform function point counting themselves instead of contacting an expert. An empirical study has been conducted to analyze the capability of the FPA technique. The results of the FPA-SDP (Function Point Analysis for Software Development Phase) model can help software project managers in (i) knowing the inconsistent states of software artifacts (ii) estimating the actual size of a change request with its complexity level for the software development phase.

SOFTWARE REQUIREMENT CHANGE EFFORT ESTIMATION MODEL PROTOTYPE TOOL FOR SOFTWARE DEVELOPMENT PHASE

In software development phase software artifacts are not in consistent states such as: some of the class artifacts are fully developed some are half developed, some are major developed, some are minor developed and some are not developed yet. At this stage allowing too many software requirement changes may possibly delay in project delivery and increase development budget of the software. On the other hand rejecting too many changes may increase customer dissatisfaction. Software change effort estimation is one of the most challenging and important activity that helps software project managers in accepting or rejecting changes during software development phase. This paper extends our previous works on developing a software requirement change effort estimation model prototype tool for the software development phase. The significant achievements of the tool are demonstrated through an extensive experimental validation using several case studies. The experimental analysis shows improvement in the estimation accuracy over current change effort estimation models.

ARCHITECTURE OF PORTS AND ADAPTERS IN ITERATIVE DEVELOPMENT WITH LIMITATIONS ON TIME

The application of ports and adapters architecture (other names bulbous, layered, hexagonal) in iterative software development is considered in accordance with the requirements that come in chronological order in the practical example. Each iteration is supported by the schema architecture, problems encountered and their solution. The expediency of using the considered architecture in the iterative development of software with time constraints is shown. The system of collecting data on the concentration of carbon dioxide of the environment and air temperature in real time from a distributed network of sensors with a predetermined geolocation for medical institutions was developed. Put sensor information (ID, commissioning date and end date) in the Google Sheets spreadsheet. The data from the sensors should be collected on the server by REST service. The process of PPP in a specific project with significant time constraints is investigated, applying the rules and principles laid down in the architecture of ports and adapters, using the basic metrics to evaluate the complexity of adding new functionality, testing, concurrent development, speed and ease of development; draw conclusions about the conditions when it is appropriate to apply the chosen software design approach, and the ability of such an approach to perceive software requirements changes. The architecture of ports and adapters is useful if the system has many external integrations (mail service, push messages, databases, reporting system, etc.). The one-way communication with adapters guarantees the integrity of the main algorithmic part of the program. A thorough knowledge of the domain allows you to immediately determine the domain layer. Building a system structure that optimally reflects the domain requires the most time, and it will be costly in the future to correct errors made during the process of defining system layers (interfaces and systems). Domain logic testing is fast due to Unit tests, other tests are easy to write due to the small connectivity between layers. This architecture is not a completely new approach, but it takes the best of OOP, SOLID, DDD and determines how to apply these principles in the best way.

A NOVEL EFFORT ESTIMATION MODEL FOR SOFTWARE REQUIREMENT CHANGES DURING SOFTWARE DEVELOPMENT PHASE

Software Requirements Changes is a typical phenomenon in any software development project. Restricting incoming changes might cause user dissatisfaction and allowing too many changes might cause delay in project delivery. Moreover, the acceptance or rejection of the change requests become challenging for software project managers when these changes are occurred in Software Development Phase. Where in Software Development Phase software artifacts are not in consistent state such as: some of the class artifacts are Fully Developed, some are Half Developed, some are Major Developed, some are Minor Developed and some are Not Developed yet. However, software effort estimation and change impact analysis are the two most common techniques which might help software project managers in accepting or rejecting change requests during Software Development Phase. The aim of this research is to develop a new software change effort estimation model which helps software project manager in estimating the effort for software Requirement Changes during Software Development Phase. Thus, this research has analyzed the existing effort estimation models and change impact analysis techniques for Softwrae Development Phase from the literature and proposed a new software change effort estimation model by combining change impact analysis technique with effort estimation model. Later, the new proposed model has been evaluated by selecting four small size software projects as case selections in applying experimental approch. The experiment results show that the overall Mean Magnitude Relative Error value produced by the new proposed model is under 25%. Hence it is concluded that the new proposed model is applicable in estimating the amount of effort for requirement changes during SDP.

Managing software requirements changes through change specification and classification

Software requirements changes are often inevitable due to the changing nature of running a business and operating the Information Technology (IT) system which supports the business. As such, managing software requirements changes is an important part of software development. Past research has shown that failing to manage software requirements changes effectively is a main contributor to project failure. One of the difficulties in managing requirements changes is the lack of effective methods for communicating changes from the business to the IT professionals. In this paper, we present an approach to managing requirements change by improving the change communication and elicitation through a method of change specification and a method of classification. Change specification provides a way such that communication ambiguities can be avoided between business and IT staff. The change classification mechanism identifies the type of the changes to be made and preliminary identification of the actions to be taken. We illustrate the usefulness of the methods by applying them to a case study of course management system.

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.