Literature Review on Requirements Change … 1. INTRODUCTION Writing a literature review on...

1

Literature Review on

Requirements Change Management

QURE Project:

Tapani Aaltio

Version: 1.1

18.4.2001

File: Literature Review RCM v1.1 Printed: 04.05.2001

2

Table of Contents 1. Introduction.......................................................................................................................3 2. Background .......................................................................................................................5 3. The requirements change management process ............................................................7 4. The Change Control Board............................................................................................12 5. Co-operation with other processes ................................................................................14 6. Social Issues .....................................................................................................................15 7. Reuse ................................................................................................................................16 8. Product Families .............................................................................................................17 9. Tool support.....................................................................................................................18 APPENDIX A: Definitions .....................................................................................................20 APPENDIX B: References .....................................................................................................23

List of Tables Table 1: Correlating requirements changes and quality features____________________________ 8 Table 2: Using the software cost matrix to change estimation ____________________________ 10 Table 3: Summary of change management issues ______________________________________ 11

List of Figures Figure 1: Generic Requirements Change Management Process ____________________________ 7


3

1. INTRODUCTION Writing a literature review on requirements change management is not an easy task. There are no books dedicated to the subject. Basic books on requirements engineering treat the subject only briefly. Fortunately, there is other material available: research papers, magazine articles, experience reports, studies etc.

The subject is, however multi-dimensional. As the name “requirements change management” suggests, there are three things involved: requirements, change and management. There are many ideas around on what requirements are and how they should be treated during software development. It would seem logical that to be able to manage changes to requirements, requirements should be documented and frozen at some point during development to create a point of reference – a baseline - for the change management process. It is hard to manage change if what you are changing is not documented. Change itself is a topic that has been vastly explored and it is well known that making changes is sometimes harder than doing things the first time – there is always a psychological dimension involved with change. Change resistance can be hard to overcome, if people have committed strongly to the decisions made earlier. Finally, managing anything systematically in an organization with many groups with differing goals involved is not an easy task.

The bottom line of this study can be stated as follows:

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

This literature review is organized in the following manner:

In chapter 2, the role and background of requirements change management is described

In chapter 3, the change management process is discussed in detail. Process steps are described and goals and metrics proposed.

In chapter 4, the change control board is discussed in detail

In chapter 5, the co-operation of the change management process with other processes and tasks in the system development life cycle is discussed

In chapter 6, an introduction to social issues to be considered with requirements engineering and requirements management is given.


4

In chapter 7, requirements reuse is discussed.

In chapter 8, requirements reuse through product families is discussed.

In chapter 9, tool support for requirements change management is discussed.

In appendix A, central terms are defined. The definitions should not be taken as scientific ones. They are provided to help the reader to understand the text.

Appendix B is the list of references.


5

2. BACKGROUND

2.1 Doing requirements right the first time The importance of proper requirements engineering in the beginning of system development is a widely accepted fact. According to empirical research [Blackburn 2000], more time and effort (in person-hours) invested in the early stages of a software project yields faster cycle times and higher productivity. Further, it is important to find the most important requirements in the beginning, since they will be used as architecture drivers and basis for design decisions in the later phases in the software development life cycle. Also, the cost of changing a requirement (and its implementation) costs more when it is noticed later in the develoment life cycle. Some changes are even impossible to make after architectural design. Thus, there are good reasons to try to minimize the chance of change after the requirements have been specified, in other words, to keep requirements volatility low.

2.2 Requirements change is inevitable However, the idea of fixed requirements is not valid. It is not possible to specify requirements which will never change during the life time of the system or even the course of the development project. There are several reasons for the requirements to change. First, the changing environment creates needs to change. Requirements are said to be mutable, if they change in response to demands outside the system and its development process. Second, understanding of the requirements grows after a baseline has been set. Changes that have to be made because of this are called emergent. Third, after the experience of using the system but also after using pilot systems, prototypes, demonstrations, scenarios etc, new requirements are generated. These are called consequential requirements. Fourth, sometimes requirements have to be adapted or localized to different countries, different user profiles etc. Such requirements are called adaptive requirements. Migration requirements provide migration paths when revolutionary changes in organisation are not possible or advisable. (Classification [Harker 1993]).

2.3 Anticipating change

Since change is inevitable, it is a good idea to prepare for it. Eliciting, analysing, prioritising and documenting requirements are tasks that need to be done very systematically not only in the requirements engineering phase, but also in the requirements management phase. Doing changes to accepted documents is not very motivating. Things that have been carefully prepared are now going to be changed. A lot of effort has been put into keeping everything concise. Every change made could degrade the system structure. The risk of not keeping all documents up-to-date grows as the number of changes grows. Changes are going to affect the project schedule and budget negatively. It is practically impossible to analyse the impact of changed requirements as carefully during requirements management as it is to check the impact in the requirements engineering phase. There are well-documented examples of catastrophes caused by changes made to systems [Ariane 1996].

The risk of introducing errors to systems can be substantially reduced by using systematic requirements management procedures. At the same time, the problems related to schedule and budget problems are reported to diminish as proper project management becomes possible.


6

2.4 Change management procedures There are two important things to the management of requirements changes: the process and its implementation – people involved and how it is organized. The process has in fact very strict requirements: many times the changes have to be made in relatively or even very tight schedules, analysing the impact of the changes on the system, its usability, on project schedule and budget is not an easy task. There are – depending on which phase the development is in – many different documents to update and things review, new versions have to be created and the changes have to be scheduled to be implemented. If system is in the maintenance phase – and is thus used in production – the disturbance to production must be minimized.

The people involved and the organization of the process also play key roles. The people making decisions must have good overall understanding of the system and of course the business, they must have access to people who can give them detailed information and they must be empowered to make the decisions that have to be made.

2.5 Tool-support Tools support is in fact one of the central themes that should be discussed when requirements management procedures are planned to be implemented. Requirements management is, in fact, a clerically intensive task [Emmerich]. Tools enable tracking and reporting of requirements related things [Davis 1999]. Tools are also necessary because the increase in procedures and documentation is important [LANHOBEK].


7

3. THE REQUIREMENTS CHANGE MANAGEMENT PROCESS

3.1 The generic requirements change management process A generic process proposed by Kotonya and Sommerville [Kotonya 1998] is shown in figure 1. The process begins with the identification of a problem concerning requirements. Any stakeholder could identify a problem. The problem is analyzed and if a change is desired, a change specification is made. Based on the change specification, the impact of the change on the system and the costs (in both time and money) are estimated. If the change still seems to be feasible, it will be implemented, giving changed requirements as the output of the process.

Figure 1: Generic Requirements Change Management Process

3.2 Process Implementation Issues Although a sophisticated process could be the final goal of process improvement, small steps are reported to be advisable in the beginning: Only simple and easy processes will be successfully introduced. After this, in the future, the processes can be enlarged and detailed. There is also need of training and adaptation to the new processes. This is more significant in the side of the client where more resistance can be found [LANHOBEK].

3.3 Requirements change metrics Metrics can give detailed information on development efforts [Wiegers 1994 II]. However, they can cause harm when used the wrong way. Care should be taken to choose the right metrics to use [Wiegers 1997], [Grady 1992]. The trick is to find a small and balanced set of metrics [Wiegers 1999].

3.4 The tasks in requirements change management This section introduces a work breakdown structure of the requirements change management process and discusses the important issues of every task presented. The work breakdown structure is adopted from [Lam Dis].

For each task, the following components are discussed:

• Goal. The objective that the issue seeks to achieve or promote; the rationale for a management issue.

• Failure mode. Project scenarios that indicate when a requirements change problem has arisen.

• Management strategies. Generic strategies that a project manager might undertake to avoid, rectify or recover from the failure mode. Such strategies need to be sensibly tailored for a specific project context.


8

• Metrics. Example metrics that support a management strategy either by measuring the extent of a problem or the effectiveness of the management strategy undertaken. Again, the appropriate choice of metrics is dependent upon the project context; sample metrics, however, might help a project manager derive suitable analogous metrics.

The tasks and related information are summarized in table 3.

3.4.1 Change identification There is always a gap between documented requirements and actual requirements. When this gap is disturbing enough, an effort has to be done to close it. If the gap continues to grow, the perceived value of the system is eroded. The system becomes outdated.

There are many ways to analyze the perceived value of the system and the need to make changes to it. Ethnographic studies can be carried out to monitor how users actually use the system to achieve work objectives. At the same time, new ways to use the system can also be invented. Customer and user surveys can be used to determine stakeholder satisfaction. Also system reviews, user workshops and benchmarking can be used.

The right method should be used – the important thing is to somehow collect feedback information to keep the gap from growing. In other words, an effective feedback loop should be created. The feedback loop feeds useful information from the stakeholders of the system to the development process.

With good change management procedures are used, change is always initiated with a change request. A change request could be electronic or on paper, the important thing is that the need to change is documented. There are several generic templates available, and again the problem is to tailor the form to your own needs.

3.4.2 Impact Analysis The impact of proposed changes on the system must be carefully analyzed. Functional impact analysis in concerned with the impact on existing functionality and quality impact analysis on the quality of the system.

Impact analysis can be carried out by applying a matrix structure to correlate requirements changes against the system’s existing functionality and quality features. Table 1 shows an example of analyzing the impact of a change on some quality attributes. Traceability information can be used to set up the matrix.

Requirements Change Usability Response time Security

Use new SET protocol Low impact Low-medium impact Medium-high impact

…

Table 1: Correlating requirements changes and quality features


9

Metrics associated with impact analysis also include dependency count, which means the number of requirements dependent on the changing requirement.

3.4.3 Identifying Conflicts Proposed changes usually have conflicts among them or result in conflicting requirements. These conflicts have to be identified and worked out as early as possible in the change management process. Discovering conflicts late in the process leads inevitably to iteration of tasks and to higher costs. In the worst case, conflicts give rise disturbance to production.

Here, much of the same methods can be used as in identifying conflicts in the requirements engineering process: requirements inspections, viewpoint analysis, trade-off analysis and even prototyping and simulation.

3.4.4 Prioritizing Changes Change proposals have different levels of importance to different stakeholders. In planning the changes to actually be implemented, the changes must be prioritized, much in the same way that requirements are prioritized in the requirements engineering phase. There are, of course many different ways to do this and many different criteria to follow in different situations. In reality, not just one criterion is used but a combination of several. Some criteria according to [Lam]:

How important it is to the customer

How it affects quality

How high is the risk

When can it be delivered

What is the total effort

Is the change dependent of other changes

What is the perceived value

What is the cost

3.4.5 Negotiation Potential conflicts have been identified to the proposed changes. These conflicts must be resolved to be able to plan their implementation. This requires reaching a consensus with all stakeholders. The same methods can be used as in the requirements engineering phase.

3.4.6 Risk Assessment Making changes to an existing system is always risky. This is why such procedures have to be followed. However, not all changes have the same risk level. Proper risk analysis should be conducted - at least high-risk changes should be identified - in order to take appropriate risk management actions.

3.4.7 Change Measurement Change management is in a central role in software development projects – many times they decide in reality whether the project will succeed or fail. Therefore, change management practices should be constantly monitored and measured to be able to control and improve them. Historical data should be collected to be able to benchmark the changed procedures.


10

3.4.8 Change Estimation The costs, schedule and resource needs must be estimated. Requirements are often under-estimated – and sometimes over-estimated. Under-estimation is a typical cause for project over runs and quality distortion.

A practical approach to change estimation is using the software cost matrix. The idea is to identify common categories of change within a domain, and to associate a typical effort estimate to each category. As historical data is gathered, the typical effort estimations can be refined. Table 2 shows an example of categories.

Change Element

Change Type Description Effort

Layout/detail Changes to the design of a single form 1 hr

Style Changes to the style of a form that will affect many of all forms. 0.5-2 hrs

Screen

New form The addition of a form 0.5-5 hrs Report layout Changes to the layout of a report 0.5-3 hrs Query Changes to the query mechanism used to generate reports 0.2-4 days

Report

New field The addition of one of more fields to a report 0.2-2 days New field The addition of a new field 0.5-2 hrs Data Re-format The re-formatting of an existing field 0.5-4 hrs

Table 2: Using the software cost matrix to change estimation

3.4.9 Requirements Planning The implementation of changes must be planned to optimize project schedule and costs and minimize system disruption.

3.4.10 Change Learning The change management process should be constantly improved. As the process is in use, new knowledge is captured. This knowledge must be used to streamline the process.


11

Issue Goal Failure Mode Management Strategies Metrics

Change Identification

To identify and capture changes that affect requirements

Changing user and customer needs are neglected. Users become frustrated. Perceived value of system is eroded. System becomes outdated.

System reviews User workshops Ethnographic studies Satisfaction questionnaires Benchmarking

Customer satisfaction rating Change volatility Requirements gap

Impact Analysis

To assess the impact that a requirements change is likely to have on existing functionality and quality (e.g. performance, safety, reliability, usability) of a system.

A requirement change is implemented which, after release, affects the existing functionality of the system or degrades an aspect of software quality.

Functional impact analysis Quality impact analysis

Quality deviation Defect count Dependency count

Change Conflict

To identify potential conflicts and trade-offs within a set of requirement changes as early as possible in the software process.

A set of requirement changes is simply accepted without any analysis of possible conflict or trade-offs. Conflicts are discovered only after requirements have been implemented or late in the development process, when they are inevitably more expensive to rectify.

Requirements inspection. Viewpoint analysis. Trade-off analysis. Prototyping and simulation.

Conflict detection period. Time taken to detect conflicts. Trade-off sensitivity. Trade-off frequency.

Change Prioritization

To prioritize requirements changes so that they are distinguished in terms of their relative level of importance.

Requirements that are of a higher priority are not explicitly recognized as so, and are compromised against requirement changes of a lesser priority. Consequently, though a system might be acceptable to the customer, it may not be the most acceptable.

Prioritize requirement changes Re-prioritize requirements for the system as a whole.

Requirements importance Requirement urgency Requirement effort. Cost-value ratio

Negotiation To reach a consensus amongst stakeholders on a set of requirement changes.

Identified conflicts and trade-offs are left unresolved, or are inadequately resolved. Tensions between stakeholders escalate, and the scenario that a system will only be partially accepted becomes a distinct reality.

Averaging. Optimization. Requirements relaxation. Compensation. Re-prioritization.

See Change Prioritization (above).

Risk Assessment

To assess the risk associated with a requirement change as a basis for taking appropriate risk management actions.

High-risk requirements are not identified, identified but not assessed, or unsuccessfully undertaken. The failure to manage high-risk changes is a major contribution to project overruns.

Identify high-risk requirements (high volatility and high significance) Develop risk mitigation plans

Volatility-significance factor. Risk severity. Risk loss.

Change Measurement

To base, as far as possible, decision making in the management of requirement change on factual data rather than subjective opinion and ‘gut’ feeling.

Problem areas are difficult to identify, and process improvement efforts are difficult to implement and justify.

Create a measurement program and use metrics systematically

Change effort Change volatility Change completeness Change error rate Change density

Change Estimation

To formulate realistic project plans and maintenance agreements with clients, organizations must have a capability to estimate the cost of requirement changes and the effort and time needed to carry them out.

Requirement changes are frequently under and over-estimated. Under-estimated changes cause project overruns. Increased deadline pressures lead to lapses in quality procedures, resulting in higher defect levels than normal.

COCOMO FPA (Function Point Analysis) Software cost matrix

Change effort. Change time. Requirements cost.

Requirements Planning

To plan requirements in a way that minimizes system disruption but optimizes the project schedule.

No consideration is given to requirements planning. Changes are dealt with on an ad-hoc basis that frequently leads to long periods of system disruption and delays because of a lack of resources.

Minimize disturbance. Critical-first. Changeability. Customer importance. First in first out. Resource-availability.

Change Learning

To capture knowledge about specific kinds of change, and to exploit this knowledge to facilitate the requirements change process.

The organization encounters many similar kinds of change, but no attempt is made to formalize this knowledge. Opportunities to improve and streamline the change process are ignored.

Identifying new categories of change, and refining existing categories.

Table 3: Summary of change management issues


12

4. THE CHANGE CONTROL BOARD The requirements change management process itself is not sufficient; someone has to make it happen. This is the task of the change control board (CCB).

The change control board is not discussed extensively in the literature. Wiegers [Wiegers 1999] gives a compact description on the composition and tasks of the CCB.

The CCB is the body of people that makes binding decisions about which proposed requirements changes and suggested new product features to approve. It also typically decides which reported defects to correct and in which software release. These decisions have to be made somehow in every project, but establishing a change control board formalizes this group’s authority and defines its operating procedures.

To some people the term change control board conjures an image of wasteful bureaucratic overhead. However, an effective change control board will consider all proposed changes at regular intervals and make timely decisions based on the potential impacts and benefits of each proposed change. It should be no larger and no more formal than necessary to ensure that the right people make good business decisions.

The change control board should represent the various stakeholders and it must have the authority to make binding decisions. It might include representatives from the following areas [Wiegers 1999]:

Product of program management

Project management

Development

Testing or quality assurance

Marketing or customer representatives

User documentation

Technical support

Help desk of user support line

Configuration management

The list is not complete, e.g. a usability expert should be included in the board.

In small projects a handful of people could fill all the necessary roles in the change control board. The board should be as small as possible, as large groups can have difficulty in convening meetings and making decisions.


13

The change control board should make its decisions on the balance between the anticipated benefit and the estimated impact of accepting the proposed change. In large projects, some proposed changes could be referred to a higher-level change control board.

The change control board should communicate its decisions to all people involved: the initiator of the change, the development team etc. Some tools will do this automatically.


14

5. CO-OPERATION WITH OTHER PROCESSES The requirements change management process has an important role in systems development. This is a fact, but it is still just one process among many. Co-operation – communication and synchronisation - with other processes is vital to be able to do the right things the right time. Synchronising the different processes has been reported to require a lot of work [ImproveTCR].

The requirements change management process requires input from other processes: change must be anticipated. Pre-PS traceability information must be entered during the requirements engineering phase. Entering this information – mainly rational and source - is sometimes hard to justify to analysts with tight schedules, since the benefits are not directly apparent. Post-PS traceability information must be created and updated during design and implementation. The benefits of traceability information in handling requirements changes is remarkable during impact analysis, change estimation and change planning – helping project management. Further, entering an estimate of the volatility of requirements early in the development life cycle would help in choosing enduring requirements as design drivers.

Feedback from users can be collected in various ways: through service requests, field studies, user workshops, satisfaction questionnaires etc. Some of this feedback can generate change requests to be input to the requirements change management process. Creating an active feedback loop is essential to being able to constantly respond to evolving user requirements [active feedback loop].

Testing against requirements would seem like a reasonable way to operate. The requirements engineering process produces input to the testing process. Also changes in requirements have to be taken into account when planning test cases.

Finally, configuration management, software release management and version management are areas that benefit from a proper requirements management. Requirements – and even change requests – can be put under configuration management [Crnkovic]. Different versions of requirements must be traced to different software releases – that consist of different software component versions – to have a clear view on what features have been implemented in different releases.


15

6. SOCIAL ISSUES This chapter is intended to stimulate awareness of social issues in requirements engineering. Problems with social issues can create serious communication barriers – either intentional or unintentional – in requirements elicitation. This can lead to high volatility of requirements.

Some of the most vexing difficulties in requirements engineering are social, political and / or cultural. Social issues are inherent to the requirements process, because the needs that drive that process are necessarily embedded in the social, cultural and political world of those who want the system, and hope to benefit once it is built [Goguen 1993].

The requirements process involves extensive interaction between different groups with different values and backgrounds. In this chapter the situation is simplified to three major groups: the client organisation, the requirements team and the development team.

The key point to consider with the client organisation is to make sure who the “client” is and to find the “right users”. Further, the requirements process may reveal or highlight difficulties in the client organisation. Burying these difficulties would be short sighted. It can be useful to discuss the value system of the client organisation, or even do some empirical work to discover what it is.

Open communication between the requirements team and the client organisation is vital. It is not uncommon for the client organisation to hide some information or to deny the requirements engineers access to certain individuals of groups. Another common problem is dealing with changes in the client’s view of what is needed. Unfortunately, the work statement for requirements efforts often does not allow for change.

The development team can often benefit from direct contact with the requirements team, to discover the reasons behind choices, to resolve inconsistencies, to get more details etc. Unfortunately, many system development processes do not allow this.


16

7. REUSE Reuse in widely suggested to be a key to improving software productivity and quality. It has been further argued that reuse at the requirements level can significantly increase reuse at the later stages of development and lead to the reuse of whole collections of related artefacts [Barber et al.]. Therefore, the notion of reuse at the requirements level is accepted by many as a desirable aim [Lam et al. 1997]. However, there is little evidence in the literature of requirements reuse as part of the normal systems development process.

It would be logical to think that the reuse of requirements in functionally similar systems will bring economic savings. It can also be argued that by using the same set of requirements again and again, one is likely to “trust” them more than requirements written “from scratch”.

Requirements reuse has been examined in the literature from a number of different perspectives: e.g. analogy, case-based reasoning and generic modelling. Unfortunately, these ideas have been restricted to small-scale academic examples, and remain largely untested in a genuine industrial or commercial capacity. However, success has been reported in the use of domain-specific approaches. Central to these domain-specific approaches to reuse is the use of domain analysis, “a process by which information used in developing software systems is identified, captured, and organized with the purpose of making it reusable when creating new systems”.

Lam et al. describe ”ten steps toward systematic requirements reuse” in an article based on experiences in institutionalising reuse within RoSec between 1993 and 1997. According to the report, a figure of 50% reuse of requirements has been achieved between products of a certain product family. Although most of the steps described in the report have a distinct technical focus, the importance of organizational and management factors is strongly emphasized. According to this article “an increase in the level of requirements reuse can be achieved using a number of relatively cheap and simple measures which do not require radical organisational changes.” Further, “each of these steps can stand alone in its own right, it is the synergy between steps working in parallel which is likely to bring the most significant benefits of reuse.”

The steps given by Lam et al. include clear steps to promote reuse, but also things to beware for:

Identify system families to maximize reuse

Use road maps to organize and structure reuse products and processes

Encourage reuse by creating template requirements

Look for requirements patterns

Reuse parts of the requirements engineering process

Evaluate reuse in terms of Process Change, not just in terms of reuse potential

Assess beforehand the impact of requirements reuse later in the development life cycle


17

8. PRODUCT FAMILIES Another issue which deals with requirements evolution, and also not supported by current requirements engineering practices, is product families. Actually, product families are a special case of reuse.

Global markets for some products are coarsely segmented by different national standards, cultural differences and separate customer profiles. Many of these segments are not large enough to support independent product development. Within a product family, products with common architecture are tailored to the needs of limited market segments, thus reducing development costs.

The family architecture is based on a few primary requirements, also called architectural drivers. Architectural drivers are the same for the whole product family and they must be carefully chosen, since any change in them is likely to affect the entire architecture. [Kuusela et al.2000].

Creating a requirements document for a product family is more complicated than creating one for a single product. A product family is always a compromise of requirements shared by its members.


18

9. TOOL SUPPORT To meet the special needs of requirements management, specialist tools have been developed. Requirements management tools is one of the most dynamic areas of the software tools development market. It is difficult to do a survey with long term value on the tools, since new tools and new versions of old tools are constantly brought to market [Emmerich].

Key features of requirements management tools include tracing requirements to their origins, change impact analysis, completeness and consistency checking, management functions, change control [INCOSE97].

Traceability information to be used during impact analysis is one of the important benefits of tools. The problem with traceability seems to be that usually many different tools are used in systems development and sharing traceability information across these different platforms is not always possible [Ramesh].

The reporting features of these tools speed up certain operations: in one project [RMATIN] the use of a requirements engineering tool “reduced the effort of making a report with an overview of the status of all requirements from a two day meeting with all major project participants to a five-minute job for the project manager”.

Requirements management tools are generic, they need to be configured to support specific requirements engineering and system development processes. Also tool integration with other tools used in system development must be planned. Integration with other tools is an important issue to be considered when evaluating tools: this might lead to not choosing a “better” tool that cannot be integrated with other tools [RMATIN]. Several experience report underestimation of the time and effort involved in the tool evaluation and introduction [ImproveTCR], [RMATIN].

Experience reports and technical papers document successful usage of configuration management tools for change request management [SOCCOMA], [Crnkovic 1999]. Using configuration management tools, requirements specification items can be associated with change requests and different versions of requirements specifications can be generated.

The use of configuration management has the following advantages [Crnkovic 1999]:

It provides support in controlling how and when requirements are changed, if they are under implementation or if they have already been implemented.

It provides designers and programmers with direct and easy access to related requirements information

It simplifies keeping of requirements consistent with implementation and free of redundancy

It simplifies reuse of requirements previously used and implemented

However, some tailoring is required to be able to use cm tools to requirements management.


19

To make good use of a tool, the requirements change management process should be planned first on a high level and then customized in detail to the organization and the tool. Good experiences have been reported by companies that have implemented new change management practices and started to use a tool at the same time.


20

APPENDIX A: Definitions

Change Control Board In order to manage the change control process in a fair and stable manner, a Change Control Board (CCB) is established [VBRMJ], [Wiegers 1999]. The CCB is the body of people that makes binding decisions about which proposed changes and suggested new product features to approve. All the relevant groups should be represented in the CCB. It might include representatives from several of the following areas: product or program manager, project management, development, testing, quality insurance, marketing, user documentation, technical support, help desk, user support line, configuration management.

Enduring Requirements Requirements, which derive from the core activity of the organization. These are not likely to change. [Sommerville], [Harker 1993]

The endurance of requirements can be estimated already in the requirements engineering phase. This information can be used in the later phases on the system development life cycle, e.g. system architecture should be base on enduring and not on volatile requirements.

Endurance can also be measured during the lifetime of a requirement, see Requirements Volatility.

Requirements Baseline Requirements baselines are used in phased development to group together accepted requirements that will be used as input to the subsequent phases of development.

Requirements Creep Requirements creep refers to the requirements that enter the specification after the requirements process is supposed to be finished [Robertson 1999].

Requirements Evolution Changes to requirements are inevitable and natural [Lehman 1998]. To emphasis this, the term Requirements Evolution is used.

Requirements Leakage Requirements leakage refers to those requirements that somehow “leak” into the specification. Nobody knows where they came from; nobody is responsible for them. Nobody wants to own them [Robertson 1999].


21

Requirements Completeness Requirements are said to be complete, when the full set of requirements have been identified. This is seldom the case in the early phases of requirements engineering. During development, new requirements typically emerge.

Verifying the completeness of requirements is not an easy task. Some methods have been proposed for it in the literature, e.g. Function Point Analysis [Dekkers 2001].

Requirements Traceability Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction [Gotel].

Requirements traceability is of two basic types: Pre-PS traceability and Post-RS traceability.

Requirements traceability is a compulsory pre-requisite for effective requirements management. The current requirements management tools provide facilities to import and group together representations of the various project artifacts. This is only of limited use. To fully exploit the potential knowledge embedded in requirements traceability, more sophisticated models are needed.

Requirements Volatility This is the key concept: how volatile are requirements. If requirements where not volatile at all – if they remained constant – there would be no need for requirements change management. High volatility causes problems with project schedules and costs. Extremely low volatility could be an indication that the system is not adapted to changing requirements [Buren 1998].

The volatility of a requirement can be measured by change density: how many times it has been changed in a period of time, e.g. a month, six months, the development project, during maintenance.

In addition to the volatility of single requirements, the volatility of a set of requirements can be measured.

Stakeholder Anyone who may have some direct or indirect influence on the system requirements [Sommerville]

Volatile Requirements Requirements, which are more likely to change than enduring ones. Volatile requirements can be further divided into several sub-classes, to give an idea on what causes requirements to change [Sommerville], [Harker 1993]:


22

Mutable requirements arise in response to demands outside the system and its development process.

Emergent requirements emerge during the development process in response to growth in understanding and experience.

Consequential requirements are usually identified after the experience of using the system but also after using pilot systems, prototypes, demonstrations, scenarios etc. The cause for consequential requirements is the fact that the delivery of a system inevitably leads to the discovery of new ways of working, new tasks to attempt and new insights to individual capabilities.

Adaptive requirements permit local customization and personalization for the purpose of different users.

Migration requirements provide migration paths when revolutionary changes in organization are not possible or advisable.

Compatibility requirements depend on a particular system or business process within an organization. As these change, the system must be adapted.


23

APPENDIX B: References [Ariane 1996] Flight 501 Failure, Report by the Inquiry Board, 1996

[Barber et al.] Requirements Evolution and Reuse Using the Systems Engineering Process Activities (SEPA), K. Suzanne Barber, Thomas J. Graser, Paul S. Grisman, Stephan R. Jernigan, The Laboratory for Intelligent Processes and Systems, The University of Texas at Austin.

[Barber et al. 2] Increasing Opportunities for Reuse through Tool and Methodology Support for Enterprise-Wide Requirements Reuse and Evolution, K. Suzanne Barber, Thomas J. Graser, Paul S. Grisman, Stephan R. Jernigan, The Laboratory for Intelligent Processes and Systems, The University of Texas at Austin, Col. John Silva, Defence Advanced Research Projects Agency

[Blackburn 2000] Concurrent Software Development, J. Blackburn, G. Scudder, L.N. van Wassenhove; Communications of the ACM, 2000

[Butzen 1998] Experiences in the Adoption of Requirements Engineering Technologies; Crosstalk December 1998

[Claus] Implementing Systematic Requirements Management in a Large Software Development Programme; C. Claus, M. Freund, M. Kaiser, R. Kneuper; TLC GmbH

[Crnkovic 1999]: Processing Requirements by Software Configuration Management, I. Crnkovic, P. Funk, M. Larsson, IEEE 1999

[Davis 1999] Making Requirements Work for You; Alan M. Davis, Dean A. Leffingwell, Crosstalk April 1999

[Dekkers 2001] Applying Function Point Analysis to Requirements Completeness; Crosstalk Feb 2001

[Emmerich] The Future of Requirements Management Tools; A. Finkelstein, W. Emmerich

[Goguen 1993] Social issues in requirements engineering; Goguen, J.A., 1993, Proceedings of IEEE International Symposium on Requirements Engineering, 1992, Page(s): 194 –195

[Gotel] An Analysis of the Requirements Traceability Problem; O. Gotel, A. Finkelstein; 1994 IEEE


24

[Harker 1993] The Change and Evolution of Requirements as a Challenge to the Practice of Software Engineering, S D P Harker and K D Eason, IEEE 1992

[ImproveTCR] Process Improvement Experiment, Final Report (version 1.1, 22.9.2000): Improvement of development process through enhanced test procedure and change request management, ESSI Project No 27352.

[Kotonya, Sommerville] Requirements Engineering – Processes and Techniques, G. Kotonya, I. Sommerville; Wiley 1998

[Kuusela et al. 2000] Requirements Engineering for Product Families, Juha Kuusela and Juha Savolainen, ICSE 2000, Limerick, Ireland

[Lam et al. 1997] Ten Steps Towards Systematic Requirements Reuse, W. Lam, J. A. McDermid and A. J. Vickers, IEEE 1997

[Lam 1999] Managing Requirements Change Using Metrics and Action Planning; W. Lam, M. Loomes and V. Shankararaman, 1999 IEEE

[Lam] Requirements Change: A Dissection of Management Issues; W. Lam, V. Shankararaman, G. Saward

[LANTIK] LANTIK – Client Relationships and Requirements Management Improvement; ESSI Project 24155; Version 2.0, 20.1.1999

[Lavazza 2000] Enhancing Requirements and Change Management through Process Modelling and Measurement; L. Lavazza, G. Valetto, 2000 IEEE

[Leite 1997] Enhancing a Requirements Baseline with Scenarios; J. C. do Prado Leite, G. Rossi, F. Balaguer, V. Maiorana; IEEE 1997

[Ogren 2000] Requirements Management as a Matter of Communication; I. Ogren; Crosstalk Apr 2000

[Ramesh 1995] Lessons Learned from Implementing Requirements Traceability; B. Ramesh, C. Stubbs, T. Powers and M. Edwards; Crosstalk April 1995


25

[RMATIN] RMATIN – Requirements Management in Alcatel Telecom Norway Defence Communications Division; ESSI-Project. Final Report version 1.0, 26.8.1999

[Robertson] Requirements Testing – Creating an Effective Feedback Loop; Suzanne Robertson; www.systemsguild.com/GuildSite/SQR/testingloop.html

[Sommerville] Software Engineering, 6th edition; Ian Sommerville; 1996

[Lehman 1998] Software’s Future: Managing Evolution, IEEE Software January-February 1998

[Rational 2000] Unified Change Management from Rational Software: An Activity-Based Process for Managing Change, Rational Software White Paper, Rational 2000

[SOCCOMA] Process Improvement Experiment, Final Report (version 2.0, 23.10.1998): Software Change and Configuration management, ESSI Project No 21269.

[VBRMJ] Change Control Procedure, Visual Basic Project Management Journal; www.vbpmj.com

[Wiegers 1994] Creating a Software Engineering Culture; Karl E. Wiegers; www.processimpact.com

[Wiegers 1994 II] Lessons from Software Work Effort Metrics; Karl E. Wiegers; www.processimpact.com

[Wiegers 1997] Software Metrics: Ten Traps to avoid; Karl E. Wiegers; www.processimpact.com

[Wiegers 1999]: A Software Metrics Primer, Karl E. Wiegers, www.processimpact.com

[Wiegers 1999] Software requirements, Karl E. Wiegers, Microsoft Press, 1999

[Wiels] Formal Modelling of Space Shuttle Software Change Requests using SCR; V. Wiels, S. Easterbrook;


http://www.systemsguild.com/GuildSite/SQR/testingloop.html

http://www.vbpmj.com/

http://www.processimpact.com/




Literature Review on Requirements Change … 1. INTRODUCTION Writing a literature review on...

Documents

Transcript of Literature Review on Requirements Change … 1. INTRODUCTION Writing a literature review on...