Management of Changes in Software Requirements during Development Phases

Abstract

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.

The Effect of Requirements Quality and Requirements Volatility on the Success of Information Systems Projects

“…This paper analyzes the volatility of requirements along with the development phases after the requirements phase freeze. According to Mohammad D., (2016) study; maintenance phase has the maximum number of changes requests while design phase has the least number of changes requests [38]. Although agile development is known for its flexibility with requirements volatility but it also has an impact on the continuous change of requirements [39].…”

Comparative Study of Software Estimation Techniques

“…Table 3 shows the equation and parameters used in this method. Function point can be converted into the effort by the first convert it to lines of code for particular language being used which is based on experiences [26]. Function point produces the same volume of code on average based on industrial experiences.…”

“…Therefore, FPA focus on the use case and class diagram in order to estimate any software project, FPA can be applied by first counting number use cases connected to actors or extend in the first set that connected to an actor and secondly counting the number of classes with no exception. Moreover, FPA adjustments factors are used to get actual weight which normally ranges around 4 to 7 for use scenario and 7 to 15 for classes [26]. These valued depends on one's opinion of the technicality of adjustments factors.…”

Empirical and Theoretical Validation of a Use Case Diagram Complexity Metric

“…A metric called use case point given by Karner [46] classified the use cases into groups based on subjectively determined size or complexity and then used for other kind of estimations. Use case metrics proposed by Aljohani and Qureshi [47] based on counting modified use cases and classes were used to assess, manage and mitigate risks occurring due to changing requirements.…”