Requirements Instability in Cost Estimation Abiha Batool Sabika Batool Karachi Institute of Economics and Technology Pafkiet University Karachi, Pakistan Email: naqvi.batool@hotmail.com Karachi Institute of Economics and Technology Pafkiet University Karachi, Pakistan Email: sabikanaqvi786@gmail.com Mohammad Ayub Latif College of Computing and Information Systems Pafkiet University Karachi, Pakistan Email: malatif@pafkiet.edu.pk Abstract—Requirements instability is one of the biggest issues that brings project to the referent point. These changes in requirements create estimation problems in a software project. Many times the project failure is due to the instability in software project requirements. This requirements volatility is not always from client side but due to enhancement in technologies. Requirement changes is a common source of estimation problem in software industry. This paper highlight the problems occur in cost estimation due to requirements instability and also outline how to overcome or manage the software requirement volatility. I. I NTRODUCTION In Software development phase, the requirement change is also known as Requirement Volatility. This cause major change in cost estimation of software project. Requirements instability can’t be remove fully but we can minimize its cause. Gathering requirements for a software project is a very essential and critical phase of software development life cycle. Because of their basis we calculate project cost/effect estimations. So the variability factor in requirements can change the success of the project. Developing a software is a dynamic process so we can’t avoid requirement changes but we can deal and manage their impacts on our estimates. Nowadays business and technology requirements are rapidly changing this is also impact on software development process. Many project fail due to the poor and unstable requirements, factor that lead software project to failure are: • Ambiguous objective and functionality for certain requirements • Client added new feature/requirement in the development phase • Incomplete requirement Requirements volatility represents the tendency of requirements to change over time. The rate of RV is measured as a ratio of the total number of requirements changes (add, delete, and modify) to the total number of requirements in the system over a period of time. Software Requirements can be change at any phase of the development process. These changes can be on collecting the requirement phase, analysis phase or maybe on implementation phase i.e from initial phase to the final phase. Depending upon the phase we can classified requirement changes in two categories. A. Pre Releas e Requirements Changes Pre Release Requirement changes have two categories 1)Requirement changes refer changes is the early stage of the development phase i.e elaboration, analysis, modelling. These changes occur before the functional specification has been completed. 2) Requirement changes refer changes in the later phase of software development life cycle i.e design, coding, and testing. These changes occur after the functional specification has been completely signed-off. B. Post Release Requirements Changes Post Release Requirement changes refer the changes occur once the system has been deployed. These changes goes to the maintenance phase of the development life cycle. Requirement instability has a profound affect on software development life cycle. Mainly software project schedule, cost and performance are affected by the requirement instability. Project cost is negatively associated with the requirements volatility. The software face two major challenges because of these requirement changes. 1) The variability factor will be on high side till the end of the project i.e the Cone of Uncertainty can’t be narrowed and software project will go towards the referent point. 2) Second biggest issue of unstable requirement is when the instability factor raise in our software project these changes are not tracked even the project is not re-estimated. II. R ELATED W ORK Its says that 11% projects fails due to requirement instability. As we said above, Instability not just from client side there are lots of many ways that influence requirement stability. A. Causes of Instability in Requirements There are some External and Internal factor that are given below 1) External Factors 2) a) Market competitors b) Government Regulations Internal Factors a) Product constraints b) Changes in Business Environment c) Fluctuation in user requirements d) Requirements Diversity e) Poor communication between users and development team f) Client irresponsibility g) Lack of experience to the project development team professionals In 1994/95,the Standish group surveyed over 8000 software projects, and identified that the project failures is caused by poor requirements activities, More specifically: Lack of user involvement (13%), requirements incompleteness (13%), change requirements (9%), unrealistic expectations (10%), lack of planning (8%) Fig. 2. The level of requirements volatility from the respondent’s perspective 1) Project Performance: There is a huge impact of requirements volatility on development life cycle. All stages are influenced by it.There is a significant fluctuation of user’s requirements in the later phases of the development. Whenever there is a fluctuation in requirements the performance of project is also fluctuate. Performance is influenced if change is requested for a dependent feature. Stability is also influenced by conflicts among users of requirements. Figure 2 shows a study that the level of changes during the requirement analysis is high. Requirements are fluctuated in prototyping stage. Fig. 1. % of causes of Poor Requirement Instability Some of the requirement can not be avoided and some can be avoided or manage by taking decisions. External Factors can not be avoided because they influence our business constraints. We can minimize instability in requirements but can not remove them fully. B. Impact of Unstable Requirements There is a huge impact on software development process because of requirement instability. The development of large, complex systems presents many challenges. The most important ones among those are the ability of the system to ensure that the final product satisfies the needs of the customers and the capability of it for easy maintenance and enhancement during their deployed lifetime. While systems frequently change and evolve throughout their life cycle, it makes it difficult to ensure that the implemented system validates the original user requirements. A project that has a PM who manages requirements effectively, and uses a well defined software development methodology that is appropriate for the project and that has estimates of effort and schedule made with appropriate requirements information is likely to be successful. Good estimates of effort and schedule have a huge effect on project success. As mentioned above that it affects whole life cycle of software development, now we discuss the impact on performance, schedule and cost. 2) Project schedule: Most of the customer wants to know the time, cost with internal activities and milestones. A project schedule describes how much effort(staff-month) will require to complete a project, and how much it will cost. It shows the interactions among activities and estimates the time each activity will take. The project schedule is the very first task when developing the software product. It consists of design documents, source code,meeting with stakeholders to collect the requirements, and to approve the intermediate work. As requirements changes requested, the changes can affect design, code, and testing. Deadlines can be missed due to this requirements volatility. If one deadline missed you need to postpone all subsequent deliverables deadlines. Sometimes there is a need to reschedule the total project schedule. 3) Project Cost: Cost of a project normally depends upon project duration, number of resource you need to complete a project, other expenses and also including requirement instability if occur. If there is a change in baseline requirement the developer and the technical lead should make an agreement and revised the cost of the software project they are going to build. When a developer commit an estimate, that project will face more instability in requirements. At the first stage of development they quote small price and after that they will charge more for additional requirements changes. So to decide the cost of the project, developers, stakeholder and parties have to be involved. C. Managing the impact of Unstable Requirements Managing requirements change has been a major challenge. Requirements management is the process of managing changing requirements during whole development life cycle. Often requirements are incomplete and inconsistent and of course new requirements emerge during the process as the business needs change and a better understanding of the system is developed. Requirement instability increases development cost and time, its need to be managed carefully. If volatility not handled carefully it may lead to more volatility and higher cost. project is on the right path and whether or not to continue or discard the project. A change management system is essential to identify the impact of a requirement change on cost and schedule as well as on other requirements. A committee of senior managers is need to be approve the changes that have a big impact. Top management support is essential to resolve the conflicts. The technique ”prediction by analogy” can be use if there is a similar software product exists. This technique can minimize some volatility of requirements. If several historical products are analysed the chance of requirements volatility decrease. Fig. 4. Waterfall Model of software process There is some advantage and disadvantage of waterfall model. Advantages: • Simple and easy to understand and use • Easy to manage due to the rigidity of the model each phase has specific deliverables and a review process. • Works well for smaller projects where requirements are very well understood. Disadvantages: Fig. 3. Methods to manage Requirements Volatility Requirements instability cam also be manage by the appropriate selection of software process model. Selection of a process model depends on many factor, size of the project, customer nature, nature of the project and also team’s capability. So if we are lacking in the selection of a model we would come up with the more inaccuracy in software project requirements. Many model are available to perform software development and they all have details on establishing requirements. Like we have prototyping model which is used when potential users can provide general set of objectives but are unable to provide detailed inputs. Rapid application development(RAD) model is used when requirements are well understood. Most of the process model don’t have the ability to cope with changing in requirements for this some of evolutionary model have been proposed. 1) Waterfall Model: The rst publication on the waterfall model is credited to Walter Royces article in 1970. In literature there seems to be an agreement on problems connected to the use of the waterfall model. Problems are (among others) that the model does not cope well with change, generates a lot of rework, and leads to unpredictable software quality due to late testing. The Waterfall Model was first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed fully before the next phase can begin. Before the coding phase, design phase has to be completed. In waterfall model phases do not overlap. At the end of each phase, a review takes place to determine if the • Once an application is in the testing stage, it is very difficult to go back and change something. • High amounts of risk and uncertainty. • Not a good model for complex and object-oriented projects. • Not suitable for the projects where requirements are at a moderate to high risk of changing. The main disadvantage of waterfall model is that it is not for those software project where requirements fluctuate. So not to use waterfall model for developing software project when requirement are not well defined and understood otherwise it will increase the impact of requirements instability. 2) Incremental Model: Software development should be done incrementally, in stages with continuous user participation and replanning and with design-to-cost programming within each stage. Advantages: • Some working functionality can be developed quickly and early in the life cycle. • Results are obtained early and periodically. • Parallel development can be planned. • Less costly to change the scope/requirements. • With every increment operational product is delivered. Disadvantages: • Allows for extensive use of prototypes • Requirements can be captured more accurately. Disadvantages: • Management is more complex. • Not suitable for small or low risk projects (expensive for small projects). • Spiral may go indefinitely if there is continuous change in requirements This process is much suitable for requirements changing environment because it is an iterative nature process. Fig. 5. Incremental Model of software process III. • More resources may be required. • Although cost of change is lesser but it is not very suitable for changing requirements. • System architecture or design issues may arise because not all requirements are gathered. up front for the entire life cycle. • More management attention is required. This model is more suitable than the water fall model to new requirements and changing requirements. 3) Spiral Model: The spiral development model is a risk driven process model generator that is used to guide multistakeholder concurrent engineering of software-intensive systems. It has two main distinguishing features. One is a cyclic approach for incrementally growing a system’s degree of definition and implementation while decreasing its degree of risk. The other is a set of anchor point milestones for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions. Fig. 6. Incremental Model of software process Advantages: • Changing requirements can be accommodated. C ONCLUSION In this research paper, we have described several aspects of requirements instability. Causes and impacts of requirements volatility on software development process are also discussed. Also introduce techniques to handle requirements instability. Using an appropriate process model can also minimize the affect of instability. Gathering requirements is the more essential phase of software development life cycle and chances of instability occurrence in requirements is very high. Requirements volatility can not be remove fully but can be minimize by using requirement management methods and techniques. This paper include some of the causes of instability in requirements. Instability has impact on cost, schedule and performance. Paper includes three model having their pros and cons for managing or overcome the affect of volatility. IV. ACKNOWLEDGEMENT We would like to thank our Professor Sir Ayub Latif for his valuable guidance.