Requirements Change Management Practices

Transcription

1 Report on Requirements Change Management Practices Qure Tapani Aaltio Version 1.0 Published on June 28, 2002

2 Table of Contents 1 Introduction 3 2 Why Requirements Change Management? 3 3 Models of Requirements Change Management found in the Literature 4 4 Models developed for the industrial partners of Qure 5 5 Results of the interviews with Qure industrial partners How is the work organized? Do requirements change during implementation? How do the projects prepare for changing requirements? Is there a pre-defined process in use for Requirements Change Management? Is the impact of requirements changes on the product estimated? Is the impact of requirements changes on the project estimated? How are conflicting changes negotiated? How are the risks associated with requirements changes analysed? How are requirements changes measured? How is experience from earlier projects used? 8 6 Experiences in Requirements Change Management Good Practices Antipatterns 10 7 Recommendations Consider Requirements Changes Management a valuable asset Improve the status of the requirements specification Use a systematic approach to requirements changes Use impact on product to drive decisions on requirement changes Measure the impact of requirements changes on the project Install a measurement program to evaluate the RE-process 13

3 Report on Requirements Change Management Practices 3 (3) 1 Introduction This report summarizes the work that has been done during the Qure project in the field of requirements change management and presents a limited evaluation of the current state of practice with four of the five industrial partners. The report is organized as follows: Chapter 2 lists the main reasons, why requirements change management is important Chapter 3 presents some models of requirements change management found in requirements engineering literature Chapter 4 presents shortly the work that has been done in the Qure project in developing requirements change management procedures for industrial partners Chapter 5 presents the results of the interviews with the industrial partners in the spring of 2002 Chapter 6 gives some general recommendations. 2 Why Requirements Change Management? The importance of Requirements Change Management has been presented in the Qurereport Literature Review on Requirements Change Management (version 1.1), released on The main results of that report are the following: Requirements change management procedures are extremely important during product development and during maintenance. Unmanaged change will result in chaos. Requirements will change during development and during maintenance for two reasons: the environment changes and the development process itself is incapable of producing perfect requirements. Yet, it is important to strive for good requirements in the beginning of development, since producing the same functionality and quality later through change is more expensive and sometimes practically impossible. To achieve a high level of requirements change management, two things are necessary: effective and systematic procedures for change management and the tailoring of these procedures to the organisation. There exist no perfect procedures for requirements change management and therefore constant improvement will give the best results

4 Report on Requirements Change Management Practices 4 (4) 3 Models of Requirements Change Management found in the Literature The models found in the literature for Requirements Change Management are based on two principles: creating baselines (or frozen levels) of requirements specifications and changing these frozen specifications only in a controlled fashion. The basic requirements change management procedure as described by Kotonya and Sommerville is shown in Figure 1. According to this procedure, an identified problem with requirements is analysed and the necessary changes are specified on a requirements change request. The impact of the change is analysed, both on the product and on the project. If the change request is accepted, the requirements are changed, producing revised requirements. Figure 1: Stages in the Change Management Process (Kotonya) To give a broader picture of the complex environment of requirements engineering, a picture of partially parallel process inctances introduced by Regnell is shown in Figure 2. This gives a more realistic view: in product creation, many projects must co-operate. Requirements elicitation is a continuous effort (shown in the figure with the triangles 1 and 2). For each project, a set of requirements is selected, analyzed and documented. The requirements specification is frozen (shown with triangle 3 in the figure). During implementation (between triangles 3 and 5 in the figure) all changes to requirements go through predefined requirements change management procedures. Figure 2: Partially parallel process instances

5 Report on Requirements Change Management Practices 5 (5) 4 Models developed for the industrial partners of Qure In the Qure project, Requirements Change Management procedures have been defined for two industrial partners. Both of these are similar to the model given in Figure 1, including stages for change registration, impact analysis, decision and change implementation (Figure 3). Unfortunately, these procedures have not been implemented by the companies yet 1. This is (hopefully) only a question of resources and of doing things in the right order: it sounds logical to implement the procedures for creating good requirements specifications first and the procedures for controlling changes thereafter. Figure 3: Generalisation of the procedure developed in Qure 1 One of the companies has piloted their procedure in the spring of 2002 the results are not reported here because of the very limited amount of changes requested during the pilot.

6 Report on Requirements Change Management Practices 6 (6) 5 Results of the interviews with Qure industrial partners To get an idea of how requirements changes are processed in practice, eight people from four of the industrial partners of Qure projects were interviewed. The interviewees were product managers, project managers, team managers and software designers. Although the number of people was modest, some patterns were found. These are described in this chapter. It has to be pointed out that as each interview was limited to one hour, the answers were not verified in any way, e.g. through document analysis. Verification would have made this report more reliable. 5.1 How is the work organized? Three of the units interviewed have organized their product development as projects. In the beginning of the project (or even before it), business requirements, user requirements and system requirements are documented and baselined. The requirements baseline acts as a contract between product management and the project. In general, the baseline can only be changed if both the product and the project manager agree on the changes. The fourth unit uses a different approach: product development is seen as a continuous effort and a new version is released every three months that is, a year is devided into four quarters. Before each quarter, the requirements are prioritized and an implementation plan is prepared for that quarter. During implementation the requirements are not changed. 5.2 Do requirements change during implementation? Requirements change during implementation in all of the interviewed units. However, only the most dramatic changes go through a change management process and are documented. Most of the changes are small that is, they are on a detailed level. The most frequent types of changes mentioned were adding new requirements and specifying requirements to a more detailed level. Even deleting requirements was mentioned, although people seem to be more careful with this one. A trace and rational of deleting requirements was found useful so we don t get the same ones over and over again. Most interviewees regardless of the way the work was organized seemed to believe that the requirements should be fixed before their implementation begins. The fact that product development is a learning process and that it is impossible to have (even close to) perfect requirements in the beginning was mentioned only by one interviewee. It is common practice to update the requirements documents at the end of the project or not at all. As a result of this, there is a growing gap between documented requirements and real requirements during the project. The requirements specification is not used as a tool during the development project. 5.3 How do the projects prepare for changing requirements? Anticipating requirements changes was considered a normal procedure by some of the interviewees. It belongs to the know-how of every project manager. Leaving slack in the project schedule was a standard preparation. Others did not prepare for changing requirements, but for very different reasons. In one approach, changes were not anticipated because requirements do not change. In the

7 Report on Requirements Change Management Practices 7 (7) other approach, changes were done very flexibly, just on time during implementation. What is common to these different approaches is that the requirements baseline either formaly frozen or not was on a high level, leaving details unspecified. In fact designers and software engineers are doing a requirements engineering effort they are specifying the detailed requirements during implementation - in both approaches. In both approaches this work is not called changing requirements but it is embedded in implementation. Here the question is: is there something wrong with this? Would it be better to specify the requirements to a more detailed level before implementation and avoid changes later? Is the work properly organized if the detailed requirements are produced during implementation. According to findings in RE-literature the requirements quality has to be good in order to have good quality products. Good quality requirements are created using an RE-cycle consisting of elicitation, analysis, documentation and validation. Each requirement should go through this cycle and also every requirements set should go through this cycle. The RE-cycle can be used in any phase of the project. In my opinion the main point is: are the relevant stakeholders available for RE-activities when they are needed? Usually contacts with stakeholders are not common during implementation. Therefore it is difficult to ensure that changed requirements are properly validated. 5.4 Is there a pre-defined process in use for Requirements Change Management? The interviewees gave the impression that no formal requirements change management process is in use in any of the units. With a formal process I mean a process that includes all or most of the tasks mentioned in literature (see figure 1). Some of these tasks were done but this seems to be more of a personal effort from each project manager. For several of these tasks, the units have formal techniques that they apply to other things, not necessarily in case of requirements change management. Nevertheless, not all interviewees responded negatively to this question. There must be two reasons for this: either there is a lighter not documented process in use or they did not really know if a process is in place. 5.5 Is the impact of requirements changes on the product estimated? The impact of requirements changes to the functionality of the product is not estimated in all the interviewed units at a satisfactory level. Units where usability plays a role in the product development process seemed to find it natural to do this kind of evaluation, but others did not. A great deal of requirements changes especially dropping requirements - happened towards the end of projects where pressures on schedule and budget are the highest. At this late stage only the most crucial things are usually done unfortunately estimating the impact of requirements changes on the product usually seems not to be one of them. 5.6 Is the impact of requirements changes on the project estimated? The impact of requirements changes on the project are evaluated in all interviewed units. Impact on project schedule and budget seem to be important factors although it was also mentioned that in some units quality goes first. The overall impression was nevertheless that once the implementation project had started the strongest driving force was the project not the product.

8 Report on Requirements Change Management Practices 8 (8) Despite the fact that - according to requirements engineering literature - traceability is considered extremely useful in requirements change impact analysis, none of the interviewed units documented any traceability information, although some experiments were underway. All interviewees regarded documenting traceability information a demotivating task and questioned its cost-effectiveness although the benefit seemed to be evident to most interviewees. None of the units kept track of the time spent on requirements change impact analysis. 5.7 How are conflicting changes negotiated? Changes are not negotiated with all project and product stakeholders in any of the units interviewed. There are several reasons for this: it is a real drag to try to get answers from all of them or it is not necessary since different stakeholders don t really have that different needs. However, some interviewees expressed the need to negotiate with at least the most important stakeholders and to document these negotiations so we don t have to keep talking for years afterwards why something was done the way it was done. 5.8 How are the risks associated with requirements changes analysed? Several units reported that they are trained or use a formal method for risk analysis in their projects. In some business areas public authorities require an analysis of project risks. However, the interviews left the impression that most - if not all interviewed units do not use a formal method in analysing risks caused by requirement changes. Some units analyse risks, but this is done mainly using the method sleeve. 5.9 How are requirements changes measured? You cannot control what you do not measure is common slogan in software engineering literature. The very basic indicators in requirements change management suggested in lilterature are the number of requirements specified and the number of changes to requirements. Only one on the interviewed units seemed to have any interest in these kind of precise indicators. Others measured neither the number of requirements nor the number of changes to requirements. The one exceptional unit quite amazingly had a graphical representation of the number of requirements changes during the project and according to the project manager the number of requirements changes is even a factor in calculating the success of the project How is experience from earlier projects used? None of the units interviewed reported any attempt to document experiences and use them in the next projects. According to some interviewees, there is a thing called Project Postmortem Report but it is not common practice to write them and even less to read or use them in any way. The main reason for this seems to be the pressure to start a new project as soon as the preceding one is done or even in parallel with it. Experience is thus collected only as tacit knowledge.

9 Report on Requirements Change Management Practices 9 (9) 6 Experiences in Requirements Change Management 6.1 Good Practices The interviewees were asked to mention things about requirements change management that in their experience have been done well in some project and have contributed to the project in a positive way. Three themes emerged clearly to be important for effective requirements management: The quality of initial (frozen) requirements must be good All necessary stakeholders must participate Systematic procedures must be applied All the answers are listed below, organized by theme. Not all answers are directly part of requirements change management. Specification of Initial Requirements Doing a good pre-study We have a baselined requirements specification A great amount of change requests were analysed before the requirements specification was frozen. Original schedule estimation was very close to the actual one Basic requirements were very clear from the beginning Stakeholder participation Using all necessary stakeholders in impact analysis Product manager, project manager and software engineer analyzed impact of changes together Using a pilot customer Everybody involved must be informed of what has to be done (mentioned twice) More people participated in requirements elicitation and validation than before Procedures for Requirements Change Management Systematic process for requirements change management Clear documentation of change proposals and decisions (mentioned twice) Impact analysis we have to understand what the changes really mean (also financially) (mentioned twice) Estimates have to be realistic and not too optimistic The project team does not do its own changes everything has to go through the formal process Change request do not come to just anyone in the project but through a single point of contact the product manager The changes were prioritized although not using a formal method The project has done a very good job although the requirements were not documented on a detailed level in the beginning

10 Report on Requirements Change Management Practices 10 (10) 6.2 Antipatterns The interviewees were asked to mention things about requirements change management that in their experience have been done poorly in some project and have contributed to the project in a negative way. Two of the three themes that emerged from good practices (above) appeared here also, reinforcing their status as real corner stones of effective requirements management: the quality of initial requirements and systematic procedures for requirements change management. In addition, poor communication, inadequate project management and nonexisting requirements meta management were the themes that seem to cause the most harm. All the answers are listed below, organized by theme. Not all answers are directly part of requirements change management. Note that some of the listed issues are expressed as wishes for the future. Specification of the initial requirements Some of the requirements are not very thoroughly analyzed before the implementation project starts. These are mainly wishes that would cost a lot to implement. The requirements specification is not used as a tool. It hasn t been really in use after it was frozen. The structure of the specification is not very good, it is difficult to find anything in it. In an ideal world the requirements would be specified to a detailed level before implementation project. Requirements changes were not documented in the requirements specification during the project but instead at the end of the project. Procedures for Requirements Change Management It is really hard to get all stakeholders around the same table to decide on requirements changes this is required by the process Not all requirements changes come to the project through the formal requirements change management process. An unofficial process is in use in parallel all the time. The formal procedure for requirements change management is not used things are done unofficially and not documented All changes should go through a defined requirements change management process. This would make me feel more secure about being present when the decisions are made. There is no defined process for requirements change management. Better tools and better processes. Something important is left out because of the new requirements coming in all the time. The impact of a change proves to be much smaller than estimated Poor Communication / Documentation of requirements The business background of changes is not known to project managers and the project team. There are too many interfaces between the user initiating the change and the software engineer implementing it. The software engineer has a hard time knowing what is really needed. There are no direct links between the two parties.

11 Report on Requirements Change Management Practices 11 (11) Project Management No time or resources has been allocated to changes which inevitably leads to problems with schedule There should be slack for unexpected events in project schedules. Experience information was not collected systematically or used. More resources are needed in requirements elicitation, analysis, documentation and validation. Requirements Meta Management Projects are dependent on many external factors, e.g. other projects, which change constantly. This causes many (unnecessary?) changes.

12 Report on Requirements Change Management Practices 12 (12) 7 Recommendations Some recommendations are given in this last chapter. It is impossible to give concrete and detailed suggestions since every unit and every company is different. These recommendations should be thought of as food for thought: is this something for us? These recommendations are based on my own experience as a practitioner and a researcher. 7.1 Consider Requirements Changes Management a valuable asset All units should admit that perfect requirements do not exist and that creating requirements specifications is a learning process. Therefore, changes are inevitable. Procedures should be created and implemented to handle these changes quickly and cost-effectively pretending that no changes happen is not an option. Requirements change management should be seen as an asset: a mechanism that enables projects to do whatever changes are needed in any phase of the project it should not be seen as something we have to do if we have to change something a threat. 7.2 Improve the status of the requirements specification The requirements specification should be used as a tool in product development projects. As long as there are two different truths - the official one (the requirements specification) and the unofficial one (the way things really are) there will always be nasty surprises at the end of each project. It is very important to analyze, document and validate the initial requirements carefully. This gives a good starting point for implementation, as the number of potential requirements changes is minimized. During implementation, the requirements specification should be updated when requirements change and when they are specified at a more detailed level. 7.3 Use a systematic approach to requirements changes All requirements changes should be handled in a controlled fashion. This ensures that the impact of changes both on the product and the project are analysed and all necessary stakeholders have their word on deciding on the changes. The decisions should be made at the most local possible level but always according the pre-defined procedures. The procedures must be as light as possible but they must be documented and they must produce sufficient documentation on each change. 7.4 Use impact on product to drive decisions on requirement changes A development project is a means to produce a product. The project causes expenses, the product brings income. If a project does not produce a good product, it has failed. Projects come and go, products remain at least for some time. Decisions on requirements changes should be driven by the product. The impact on the product should be evaluated as carefully as possible from the points of view of the different stakeholders. No decisions should be based solely on the impact on the project.

13 Report on Requirements Change Management Practices 13 (13) 7.5 Measure the impact of requirements changes on the project It is generally considered demotivating to collect information on how much time was spent on each task in a project. However, the most important indicators shoul be collected. One of these is the amount of time spent on requirements changes during implementation. With this information, the real impact of requirements changes on the project can be understood. This results in more reliable estimates and less risk for the project. This information should be collected systematically and shared across projects. 7.6 Install a measurement program to evaluate the RE-process Measuring simple things of requirements engineering activities can bring valuable and many times surprising information. Each company should find the most important things to measure the things that suit there goals the best. Let us look at a simple example: counting the number of requirements changes. The number on requirements changes is an important indicator in looking for the right moment to freeze the requirements specification: it indicates if the requirements specification was frozen at the right moment, too early or too late (see Figure 4). The idea behind Figure 4 is as follows: in the beginning of a project the gap between real requirements and documented requirements is wide up to 100%. As requirements are specified, this gap is closing. In the beginning this happens faster and later more slowly. At a certain point (t2) it is no more cost-effective to specify requirements this is the moment that they should be frozen. The rest of the gap is left to requirements change management. If the requirements are frozen too early (t1), there will be too many change requests slowing down the project. This information should be collected systematically and shared across projects. Figure 4: When is the right moment to freeze?