Requirements Change Management

                                       Requirements Change Management                                                                    

Abstract:

Requirements change is an inevitable activity and may occur thanks to changes in user demands, increased understanding of the stakeholders, customer organization, project vision, requirements specification and availability of technological solutions. User requirements for software development are becoming more complicated and are changing all the time. Not only should the wants engineering process be well-organized but requirements change management should even be effective, especially for complex systems. However, the software engineering methodology employed also can make requirements change difficult to manage.  Although requirements change management (RCM) is not a straightforward process in collocated software development, the presence of geographical, social, cultural and temporal variations makes the process more difficult for software teams in Global Software Development (GSD). Existing methods do not adequately address many of the GSD issues and challenges. In this paper, we present a graph-based method for RCM.

Introduction:

A large amount of existing research on conventional software development is predicated on the idea of fixed requirements, that is, requirements won't be changed or affected after making decisions about it. thanks to this impression, stakeholders usually believe that they will freeze requirements before the project begins. regardless of this fact, often requirements are changed by the stakeholders during the software development life cycle (SDLC). within the early stages of software development, usually requirements are incomplete thanks to an unclear vision of desired business goals and objectives. With the passage of your time and communication between the stakeholders, a far better understanding of the potential system is gained and new issues are discovered which require to be incorporated within the existing set of requirements to form requirements more complete and consistent. Consequently, changes in requirements appear repeatedly due to the changes in user demands, increased understanding of the stakeholders, customer organization, project vision, requirements specification and availability of technological solutions.

Many software development paradigms are introduced so as to seek out better solutions for software products and software engineering processes. Among these paradigms, object-oriented software development (OOSD) has been gaining popularity for several years. Unified modeling language (UML) has been proposed as a general-purpose modeling language for describing software systems, especially object-oriented software systems. UML introduces several views and lots of diagrams since it's intended to be comprehensive for several software models. So, although developers can choose suitable diagrams to model their system, modeling a software using UML are often complicated. This makes requirements change harder to manage, especially for complex systems. Therefore, we propose a requirements change management model for object-oriented software engineering (OOSE) with UML.

RELATED RESEARCH METHODOLGY:

        I.      1.        Object-Oriented Software Engineering with Unified Modeling Language

Ob     When OOSD was first introduced, it changed the mindsets of developers who were using familiar methodologies like waterfall models and spiral models within the software engineering process. Traditional methodologies are mostly supported structured and process-centered concepts and consider a software as a group of interacting functions while object-oriented methods view a software as a group of interacting objects. Although object-oriented methodology still includes some good practice of structured analysis, structured design and programming, it introduces many basic characteristics of object orientation like classes and objects, methods and messages, encapsulation and knowledge hiding, inheritance reflecting hierarchy and modulation, polymorphism and dynamic binding. Moreover, software developers must also understand the concepts of object-oriented analysis and style, and object oriented programming. These have introduced many notations, techniques and tools also as specific computer languages for object-oriented programming like Objective C, C++, Eiffel and Java. UML emerged from attempts to unify several object oriented methods and propose a typical notation which will be utilized in most object-oriented methods. Furthermore, some new software engineering processes supported UML were also introduced, for instance the unified process.

The functional view depicts the functionality of a system while the structural view depicts the structure of a system and therefore the dynamic view depicts the behavior of a system. Version 2.4 of the UML, released by the thing Management Group (OMG) in January 2011, defines fourteen diagramming techniques for modeling a system. There are two major groupings of diagrams: structure diagrams and behavioral diagrams. The structure diagrams are wont to represent the info and static relationships during a system, including class, object, package, deployment, component, and composite structure design diagrams. The behavioral diagrams are wont to represent the dynamic relationships among objects during a system, including activity, sequence, communication, interaction, state machine, and use-case diagrams.

        I.         

   2.        REQUIRMENT CHANGE MANAGEMENT 

Requirements change is inevitable since a software has got to satisfy user and customer needs. It is often expensive, especially when a change is formed after the software package delivery. Any change in requirements are often a serious source of risk and affect the value and schedule of a software development project also because the quality of a system. Requirements change can occur during the running of a software development project or after a system is installed and operating. it's important to determine a transparent understanding about the change in requirements and its impact on the general system. Requirements management, consisting of three stages change understanding change analysis, and alter finalization. The impact analysis in our study focuses on identifying impacted artifacts in existing software regarding the change in requirements requested from users. To manually identify such relations and report their impacts is tough work and may be time consuming and susceptible to error, especially when managing requirements change for domain specific systems that need domain experts. The dependencies between individual requirements affect many activities within the software engineering process like requirements engineering, design, implementation, and project management.     

   3.            OUR METHOD OF REQUIREMENT CHANGE MANAGEMENT (RCM)

The overall method of RCM is composed of three stages: (i) change understanding at different GSD sites; (ii) change analysis at different GSD sites; and (iii) change finalization between different GSD sites (refer to Figure 1). Our method begins by establishing an understanding of the requested change between different GSD sites in stage 1. For this reason, a complete set of project requirements, obtained from a requirements repository, will be represented in a graphical structure to generate a detailed requirements graph for them. The required changes will then be made in the requirements graph, that is, the addition, deletion or modification of requirements. Based on the information available in the requirements graph, the scope and extent of the changes will be identified and understood by the members of different GSD sites. Once the scope and extent of changes are determined, change analysis will be performed in stage 2 with respect to the development work, carried out at different GSD sites, which could be affected by the potential changes in requirements. Considering the outcomes of change analysis, decisions regarding change finalization will be made in stage 3 and later recorded in the requirements repository for future correspondence. In the following, we present the technical details on the underlying phases of RCM.

                     

                             Table 4: Contents of Change Request Document 

                                 
Conclusions

This paper has provided information about the present state-of-the-art techniques and practices for RCM and therefore the research gaps in existing work. Benefits, risks and difficulties related to RCM also are made available to software practitioners who are going to be during a position of creating better decisions on activities regarding RCM. Better decisions will cause better planning which can increase the prospect of project success.

References:

1.    AZ-Model of software requirements change management in global software development by Muhammad Azeem Akbar, Muhammad Shafiq, Nasrullah, Jawad Ahmad

2.  Reflections on Requirements Change Management in Global Software Development: A Multiple Case Study by Waqar Hussain

3.    Managing Requirements Change in Global Software Development by Naveed Ali, Richard Lai

4.    Requirements Change Management Based on Object Oriented Software Engineering with Unified Modeling Language by Jessada Tomyim and Amnart Pohthong

Effect of project management in requirements engineering and requirements change management processes for global software development by Muhammad Shafiq, Qinghua Zhang, Muhammad Azeem Akbar