A method of requirements change analysis

Abstract

Software requirements are often not set in concrete at the start of a software development project; and requirement changes become necessary and sometimes inevitable due to changes in customer requirements and changes in business rules and operating environment; hence, requirements development, which includes requirements changes, is a part of a software process. Previous research reports that correcting requirements errors late costs many times more than correcting them during the requirements development phase. There is, hence, a need to manage them well and to analyse them in order to identify the impacts, difficulties and potential conflicts with existing requirements. Most studies on requirements change analysis are done at the source code level while paying less attention to the initiation of changes at a higher level. In this paper, we present a method of requirements change analysis based on the changes themselves which are initiated at higher levels. This method consists of three steps: namely (1) analysing the change using functions, (2) identifying the change difficulty and (3) identifying the dependencies using a matrix. We illustrate the usefulness of our method by applying it to a course management system of a university.

1 Introduction

Currently, software systems are becoming increasingly complex with system requirements being inherently changeable during all stages of the development life cycle. According to Bohem [1], “correcting requirements errors late can cost up to 200 times as much as correcting the errors during the requirements phase”. The size and complexity of software systems make change management costly and time-consuming. The application of change management at the earliest possible point in the software development cycle has the potential to improve cost control. The complexity of the system further hinders the process of identifying the impact of changes on the existing system [2].

When addressing a change, most requirements cannot be treated as independent as very complex relationships can exist between them. As a result, an action performed on one requirement may have unexpected impacts on another [3,4,5,6,7]. Therefore, there is a need to identify requirement interdependencies. One of the most popular mechanisms for dealing with this is requirements traceability. Traceability is the ability to describe and follow the life of software artefacts [8] and is largely achieved by manually documenting different aspects of transformations of software development artefacts. As in any manual process, it is difficult, expensive and error-prone. There are tools and approaches that automate change impact analysis, such as IBM Rational RequisitePro and DOORS, and change impact analysis is implicit in model-driven development. In most of these, traces produced by these tools are only simple relations and their semantics is not considered. As a result, all requirements and architectural elements directly traced from the changed requirement are considered to be impacted. The requirements engineer then has to inspect all these candidate impacted requirements and architectural elements to identify changes, if there are any.

Although traceability is one of the best ways to identify the impact of change on the system, the greatest challenge of maintaining traceability is that the artefacts under consideration continue to change as the system evolves [2, 9,10,11]. A study conducted by Gotel and Finkelstein [2, 12] further elaborates on the difficulties of maintaining a traceability scheme. Among these difficulties (see [12]) are informal development methods, insufficient resources, time and cost for traceability, lack of coordination between people responsible for different traceable artefacts, lack of training in requirement traceability practices, imbalance between benefits obtained and effort spent implementing traceability practices, and failure to follow standards. Further, studies have also confirmed that the construction and maintenance of a traceability scheme proves to be costly for various reasons and commonly considered non-feasible from a financial point of view [13,14,15].

Based on the above findings, we are motivated to research into a more efficient way of analysing the impact of requirement changes at the initial phase of the software development process. One aspect of analysing changes would be to understand the dependencies between the system functions and the changes. Given the drawbacks of using requirement traceability mentioned above, we are of the opinion that requirements changes themselves could be used to form a part of the solution. The requirements changes can be mapped to the multiple activities of a system, and as a result, dependencies and/or conflicts between these changes can be obtained. This analysis enables system developers to better manage requirements changes.

In this paper, we present a method of requirements change analysis based on the changes themselves which are initiated at higher levels. It consists of three steps: namely (1) analysing the change using functions, (2) identifying the change difficulty and (3) identifying the dependencies using a matrix. These three steps give system analysts a better insight into which part(s) of the existing design will be affected. In step 1, with the use of a function, the requested changes will be expanded to give more detailed information, enabling system analysts to identify which part(s) of the existing design will be affected. Step 2 makes uses of the result(s) of step 1 for identifying the difficulty of the implementation of the change(s). Finally in step 3, the result(s) from steps 1 and 2 will be mapped to a matrix which enables practitioners to identify the dependencies and/or the conflicts between the changes. When making a decision on the changes from the viewpoints of approval, setting priorities and understanding the implications, the results of all three steps will be taken into consideration. We demonstrate the usefulness of our method by applying it to a course management system of a university.

2 Rationale of the research approach

In order to establish a baseline for the current work, it is important that this is effectively an extension of the work done in [16]. It is important to correctly identify a change before analysing it. To do so, it needs to be clearly communicated and its type to be identified. This is the reason why this piece of work is based on [16], which describes a technique to specify and classify requirement changes. The use of this specification and classification technique results in a clearer communication of changes between business and IT professionals and the changes to be identified. This technique [16] provides the initial phase of change requirement analysis. It is thus natural to extend this technique to further analyse the impact of the changes, and the identification of changes is a necessary preliminary step for our current method.

We designed our work based on previous work done in the same area [16,17,18,19,20,21]. Our method takes a decision-maker point of view in analysing changes and is based on past research conducted using the same concept where the importance of this point of view has been established [16,17,18]. Our method establishes both direct and indirect impact analysis which is where the concept originated [19, 21]. As described in the following section, the proposed method employs a number of steps to analyse impact due to the ease of both applying the method and understanding the outcome, which is a similar concept to that used in [21]. The method itself takes into consideration several different techniques that stem from other research. Work done in [17, 20, 22,23,24,25,26] inspired us to use a matrix to represent the change conflicts in a more visual capacity, while further analysis was carried out using change analysis functions, which is similar to parts of the work done in [21]. The initiation of further analysis is based on identifying the changes correctly using a change taxonomy that is adopted from [16, 19]. The method also attempts to prioritize changes based on an identification of the impact caused by the change.¹ The basis for this identification and prioritization was formed using [19, 21]. A summary of how previous work was used in our method is given in Table 1.

In short, the preliminary concepts for the requirements analysis method are based on our previous work [16], traceability techniques, dependency/change functions and the dependency matrix. How these elements correspond with each other and provide an analysis of the changes is discussed in the following sections.

Table 1 Use of literature in creating analysis method

3 The method

3.1 An overview

Change impact analysis techniques can be divided into two categories: those based on traceability analysis and those based on dependency analysis [21]. In most of these methods, we observe that conflicts and dependencies between the changes themselves have not been identified. Furthermore, the prioritization of these changes is either not undertaken or occurs at a separate level. To overcome these limitations, we propose the following:

• 1. A way of identifying dependencies between changes.

• 2. A way of assigning priority through difficulty identification.

An overview of the method is given in Fig. 1. Using this method, change practitioners will be able to achieve the following:

• 1. Identify conflicts and/or dependencies between multiple changes.

• 2. Identify which system activities (herein after referred to as activities) are most affected by the changes and therefore determine the suitability of the changes.

• 3. Calculate the difficulty level of each change.

• 4. Depending on the difficulty level, assign an implementation priority to each of the changes.

Fig. 1

Change analysis method

Once a change has been identified through the Change Event Manager (CEM), the method follows three steps:

According to Fig. 1, the CEM is the main system needed for the initiation of step 1 of the change analysis process. The CEM is responsible for the identification of the nature of the requested change which will be accomplished through the specification and classification method [16]. As explained in Sect. 2 (above), further analysis of the change is difficult without this identification. The change analysis process is implemented using three steps for better clarity and ease of use. For each change identified by the CEM;

• Step 1 (S1) is for expanding the identified changes and for discovering the more detailed information for the implementation due to the changes. As shown in Fig. 2, the two categories of change analysis functions described in Sect. 3.2 are employed for carrying out this step.

  Fig. 2

  

  Three-step analysis process

• Step 2 (S2) identifies the difficulty of implementing the changes. The result of this will be used later for assigning a priority to each of the changes requested.

• Step 3 (S3) identifies the conflicts and/or dependencies between the changes. As shown in Fig. 2, the key elements involved are the change dependency matrix (CDM) and the system design diagram (SDD). The conflicts and/or dependencies between the changes are identified once the changes have been mapped to the matrix. The dependencies which have been identified can be between the changes themselves and/or between the changes and the activities of the system. The matrix will also be used for identifying the activities of SDD which have been most affected by the changes.

Detailed explanation of the three steps is given in the following sections.

3.2 The steps

3.2.1 Step 1 (S1): analysing the changes

As shown in Fig. 3, change initiated through a change request form is subject to the change specification and classification process [16], which completes the change type identification.² All change events that are identified are stored in a change event log. The change event log will have the dual role of being a repository for identified changes and a storage facility for unresolved changes. In this step, the changes that are stored in the change event log will be expanded using the functions. Once expanded, each change will have the detailed information as to how it is to be implemented. This will provide an idea for practitioners to partially understand which parts of the system will be affected. Any change that cannot be evaluated using the functions is stored in the change event log for later resolution.

Fig. 3

Step 1

In [16], the change focuses—add, delete, modify and relocation—are reported. Our functions are based on these change focuses, due to the fact that, each change identified using the CEM will be described using one of these change focuses. There are two categories of functions, namely primary and secondary;

• The category of primary functions can be used for building a block of more complex functions. The need to do this is due to the facts that it is hard to project every possible way of implementing the changes and that practitioners can use this type of block to help them facilitate the changes.

• The category of secondary functions consists of more complex functions built by using a block of primary functions. These functions represent the change focuses and the types described in [16].

The following terminologies are used for the functions:

A_N—New activity, A_O—Old activity, V—Value, A_T—Target activity, A_S—Input Sender, L—Link, Pt—Pointer, A_R—Relocating activity, A_C—Connected activity.

The primary category consists of the following set of functions:

• 1. Function to create a new activity

  CreateFunc(String, V) → A_N

• 2. Function to link a new activity with existing activities

  CreateLink(A_N, A_O, V)

• 3. Function to link existing activities

  CreateLink(A_X-O, A_Y-O, V)

• 4. Function to delete an activity

  DeleteFunc(A_O)

• 5. Function to delete links between activities

  DeleteLink(A_X-O, A_Y-O)

• 6. Function to modify inner property of an activity

  ModifyInner(A_T,V)

• 7. Function to modify input data of an activity

  ModifyIn(A_S, A_T, V)

• 8. Function to modify output data of an activity

  ModifyOut(A_S, A_T, V)

• 9. Function to create a pointer to an existing activity

  CreatePointer(Pt, A_T)

• 10. Function to delete a pointer

  DeletePointer(Pt)

The secondary category consists of the following set of functions:

The secondary functions are explained in Table 2. A function diagram is used for aiding the explanation of a secondary function. In each diagram, the roman numbers refer to the step numbers of the function. Each diagram is placed next to its corresponding function. In most diagrams, the function before the implementation of the change (left of the equal sign) and the function after the implementation of the change (right of the equal sign) are illustrated.

Table 2 Description of secondary functions

Note: Matched interfaced means that whatever the changes being made, the connected function interfaces do not have to be modified. With mismatched interfaces, the connected function interfaces need to be modified to implement the change. It is explained in detail in [16].

3.2.2 Step 2: Identifying the change difficulty

The function has a secondary purpose of assisting with the identification of the difficulty of the change. The difficulty here refers to an identification of how complex the implementation of the change will be. The expanded steps of each change are assigned a weight according to the rules given below. The total of these weights together with the number of activities affected by the change (also obtained from the functions) is used to determine the difficulty of the change. The activities affected directly are identified by expanding the changes through the functions. Indirectly affected activities are those connected to the directly affected activities. This can be identified through the SDD. It is also important to consider other artefacts such as databases which are affected by the administration of changes [27, 28]. The databases can be identified in the SDD. The rule would be if an activity is identified to be affected either directly or indirectly by a change, then check whether the activity is associated with a database in terms of populating, updating and/or receiving information. If this condition is true, then the associated database is also deemed affected. The weights for the change categories are assigned based on [17, 29]. In both these academic works, assigning change weight is based on their experience and in both studies, the change weights are incorporated into calculations that calculate change complexity.

The rules of allocating weights for the steps in the function are as follows:

• All create functions will have the add weight of 3

• All delete functions will have the delete weight of 2

• All modify functions will have the modify weight of 1

• All other functions are the combination of the main three functions, i.e. create, modify and delete.

Table 3 is populated with the above information in order to identify the change difficulty. The population of Table 3 is carried out as follows:

• 1. Identify the change focus for each step of the function of the change action.

• 2. Assign weight according to above rule for each identified change focus and the total of these weights for each change action.

• 3. Identify the activities affected (both directly and indirectly) by each change action based on the function steps using the SDD.

• 4. Identify the connected databases for each activity identified in the above step using the SDD.

Table 3 Change difficulty identification

When identifying the difficulty of the calculation, the following needs to be considered:

• 1. For each change action and its possibility, the change weight total, number of activities affected and the number of databases affected need to be considered.

• 2. When considering the activities, the number of directly affected activities take precedence over the indirectly affected activities.

• 3. Considering the databases, from experience we know that there are two main interactions between activities and databases, population of database and retrieval of information from a database.

• 4. When an activity is connected to the database in terms of population, the implications are higher as the activity can alter the data in the database. With retrieval alone, the consequences on the database is not as high due to the fact that in most cases, the data manipulation occurs within the activity and does not update the database.

• 5. The difficulty of implementation of the change is a combination of the above four elements.

It is noteworthy that estimation of time to implement the change will also a play an important role in the decision of identifying change implementation difficulty. However, this estimation is outside the scope of this paper.

3.2.3 Step 3: Identifying the dependencies using a matrix

Dependency matrices have been used in several research work [22,23,24,25,26, 30] to identify conflicts and overlaps between requirements [31]. According to [31], this dependency identification technique is especially effective when there is a relatively small number of requirements. When this is not the case, the technique can still be applied by grouping requirements into smaller categories. Although this technique may be relatively simple, it is still quite versatile. The versatility of this concept allows the matrix method to be applied to many areas of analysis. In [22], the dependency matrix is applied to understand the evolution of web services. In [23], it is used to detect quality of service violations and to identify the cause of failures at the process level in service-oriented architecture. In [30], the technique is used to identify the interdependencies between projects, so that an organization can select the optimal projects to upgrade their technology. These various uses of dependency matrices prove that they are not only able to be used in many different areas but also for varying purposes.

Dependency can be represented as a graph or matrix-based model [24]. In our approach, we use the latter. The dependencies considered are between the changes and the activities. We established above that dependency matrices can be utilized in many ways. Therefore, in our method, the matrix is used to understand the dependencies and conflicts between changes. In addition, the matrix is used to visualize the impact of changes on activities.

As shown in Fig. 3, the main element used to create the CDM is the SDD. A requirement for the SDD is a design diagram, typically a UML [32] diagram which shows the relationships between different objects and activities. These relationships will assist in identifying the activities which are impacted by the requested changes. A dependency matrix (source × target) represents the dependency relation between source elements and target elements (inter-level relationship) [25]. Adopting the same concept, source elements (rows) are made up of the change focus [16] and the target elements (columns) are made up of all the activities affected directly and indirectly as identified in Table 2. In this matrix, a cell with a value denotes that the source element is mapped to the target element. Reciprocally, this means that the target element is impacted by the source element. Therefore, as mentioned earlier, the dependencies identified can be between the activities due to changes and/or between changes themselves.

The result of application of functions will be applied to the CDM. As shown in Fig. 4, any unresolved dependency events will be stored in a dependency log for later human-supported resolution. A change step identified though the function will be displayed in the matrix using the following rule:

• Change Focus Weight_{(Change No., Possibility No).}

  • Change Focus Weight—numerical value assigned to each change focus as described in step 2.

  • Change No.—A number given to each change that has been classified at the very beginning of the process.

  • Possibility No.—If there is more than one possibility for the change to be implemented.

• e.g.: Assuming this is the first change identified by the CEM with only one possibility and the change step considered is add, then the change focus weight is 3. The change step therefore is represented in the matrix as 3_(1,1).

Fig. 4

Step 3

The representation of the dependency matrix used for this step is given in Fig. 5. The conventional appearance of the matrix has been slightly modified to suit the needs of our method. The triangular section in Fig. 5 is used to visualize the conflicts and/or dependencies between changes. The dependencies are identified through observing activities that are affected by multiple changes to the system. If an activity is affected by more than one change, then the corresponding triangle is marked by a “+” symbol (see example in blue in Fig. 5). The process of identifying the dependency is further explained in an application of the method to a case study. The total change weight produces a number that identifies (numerically) how each activity is impacted by the changes (see example in blue in Fig. 5). The purpose of calculating this value is to give change practitioners an idea of which activities in the system are most impacted by the changes and as a result, the need to give prioritized attention to such activities. The following rules are applied when calculating the total change weight:

• (a) If there is only one possibility of change, add all.

• (b) If there are changes with multiple possibilities, add each change with the same possibility number individually and then pick the possibility with the highest value.

• (c) If there are different changes, add all.

• (d) If there is a combination of the above two, first apply (a) followed by (b) and then (c).

Fig. 5

Change dependency matrix

4 A case study

We demonstrate the usefulness of our method in the following case study. Figure 6 represents a partial system design diagram of a course management system adopted from [33]. The diagram illustrates the relationships and some dependencies the activities have with each other. The relationships denoted in the diagram can be defined as follows:

• Requires (Req): An activity A₁ requires an activity A₂ if A₁ is fulfilled only when A₂ is fulfilled. A₂ can be treated as a pre-condition for A₁ [33].

• Refines (Ref): An activity A ₁ refines an activity A₂ if A₂ is derived from A₁ by adding more details to it [33].

• Contains (Con): An activity A ₁ contains information from A₂…A _n if A₁ is the conjunction of the contained information from A₂…A _n [33].

Fig. 6

Partial system design diagram of a course management system

One of the main reasons for using this case study is the identification of the relationships. This identification is beneficial in determining the impact of change when applying our method to the case study. We have also included a table (Table 4) to describe the association of databases of this system to the activities given in the diagram.

Table 4 Databases associated with the activities

The detailed purpose of each activity is described as follows:

• 1. The system allows end-users to provide profile and context information for registration.

• 2. The system provides functionality to search for other people registered in the system.

• 3. The system provides functionality to allow end-users to log into the system with their password.

• 4. The system supports three types of end-users (administrator, lecturer and student).

• 5. The system allows lecturers to set an alert on an event.

• 6. The system maintains a list of events about which the students can be notified.

• 7. The system notifies the students about the occurrence of an event as soon as the event occurs.

• 8. The system actively monitors all events.

• 9. The system notifies students about the events in the lectures in which they are enrolled.

• 10. The system allows students to enrol in lecturers.

• 11. The system allows lecturers to send e-mail to students enrolled in the lecture given by that lecturer.

• 12. The system allows students to be assigned to teams for each lecture.

• 13. The system allows lecturers to send e-mail to students in the same group.

• 14. The system allows lecturers to modify the content of the lectures.

• 15. The system gives different access rights to different types of end-users.

• 16. The system supports two types of end-users (lecturer and student), and it will provide functionality to allow end-users to log into the system with their password.

5 Application of the method to the case study

The example consists of two scenarios, where we use the result from the specification and classification method [16] to obtain the output required for implementation of functions and the change dependency matrix. These scenarios are based on our observations as university academics who use similar course management systems. The following hypothetical new requirements are identified:

• 1. In an emergency, it would be more effective to send an SMS notification to students as well as an e-mail.

• 2. Marking attendance manually tends to be rather ineffective, especially when a census needs to be carried out. It would be better to mark attendance electronically.

The change identification of the change analysis method yields the following specification and classification for the changes mentioned above.

The results given in Figs. 7 and 8 are stored in the change event log and are then subjected to the three steps of the change analysis method.

Fig. 7

Specification and classification of change 01

Fig. 8

Specification and classification of change 02

5.1 Step 1

5.2 Step 2

The results of step 1 can now be used to identify the change difficulty using the rules mentioned in the description of step 2. Table 5 shows the total change weight for each change and the number of activities affected (directly and indirectly) by each change.

Table 5 Change difficulty identify

It would also be beneficial to identify how each database is affected. Figure 9 illustrates the connectivity and relationship between the identified activities and the databases in Table 4. Based on the rules introduced in step 2 on determining the difficulty, the connection between A₁₀ and D₃ has a higher implication as oppose to all the other connections, because A₁₀ is connected to D₃ in terms of both population and retrieval. These implications will be discussed in Sect. 6.

Fig. 9

Activity–database connectivity

5.3 Step 3

The final step of the method is to apply the results of the functions for each change into the CDM. In this step, the change focus mentioned in Table 5 for each change (and possibility) can be mapped into the dependency matrix easily. The rules mentioned in the description of step 3 in Sect. 4 are incorporated in the change focus and the function steps when completing the matrix. Only the activities identified in the functions are mapped to the matrix. Table 6 shows how the matrix representations are obtained. The steps marked N/A correspond to the fact that it has no affiliation to the existing activities in the system and are therefore not represented in the matrix.

Table 6 Matrix representation

The finalized matrix is given as follows:

6 Discussion of the results

The following section provides an explanation of the use of the results of the CDM (Fig. 10) and the change difficulty identification (Table 5 and Fig. 9) obtained above to further analyse the requirements change.

Fig. 10

CDM

As shown in Fig. 10,

• 1. For A₁₀ change No. 2 has a possible conflict or dependency with the first possibility of change No. 1, therefore the + mark on the dependency section for both ‘add’ and ‘modification’ functions. The realization of this conflict is such that when applying these two changes, the change implementers need to be mindful of the possible ripple effect it might have on the activity and connecting activities.

• 2. A₁₁ is not identified as impacted (with a + sign) as the steps are for the same change. Therefore, there are no dependency conflicts in applying this change.

• 3. Change weights in the dependency matrix are calculated (using rules of step 3) as follows:

  • A₁₀: Follows rule (b)

  • A₁₁: Follows rule (a)

  • A₁₀ has the highest change weight due to the changes and requires special consideration at the implementation level. This further clarifies the impact identified in the first finding.

As shown in Table 5 and Fig. 9,

• 4. To identify the difficulty of change, the total change weight, the number of affected activities and databases need to be considered in unison. Therefore,

  • (a) Change 1—pos 1 and change 2 have similar change weights and affect the same number of activities and databases both directly and indirectly.

  • (b) Referring to Fig. 9, A₁₀ is connected to D₃ in terms of population. Therefore, the implication is higher. This condition is same in both change 1—pos 1 and change 2 and therefore will have similar implementation difficulty levels.

  • (c) A secondary observation is that out of the databases affected, D₃ has the highest connectivity level as well as the highest implication and therefore will need prioritized attention.

  • (d) Given that change 1—pos 1 and change 2 have similar high difficulty levels, the same priority can be assigned. In addition, it should be kept in mind that these two changes have a conflict as demonstrated through the matrix. The second priority can be assigned to change 1—pos 2.

  • (e) Change 1 has two possibilities of which possibility 1 has a higher difficulty level than possibility 2 and also possibility 1 has a conflict with change 2. Based on these conditions, if possibility 2 of change 1 is selected for implementation along with change 2, the conflict can be avoided and the implementation becomes less difficult.

In the overview of the research (Sect. 3), we introduced four benefits that can be achieved by change practitioners using this method. As such, through our case study application outcome, we can demonstrate that we have achieved these benefits as follows:

• 1. Visual representation of the conflict that can occur between changes through the conflict inflicted on A₁₀ activity by two different changes.

• 2. The most affected activity due to these changes (A₁₀) is identified through the change weight calculation in the matrix.

• 3. The difficulty level of each change is realized through the difficulty identification table, which used the total change weights, number of activities and databases affected by the change. We are able to determine the difficulty level of both changes, including the different possibilities.

• 4. The difficulty level is then used to compare the changes to determine the priority level of implementation as well as recommendations on choosing different possibilities of changes.

7 Comparison with the related work

Most research in requirement change management focuses on full-scale solutions that encompass requirements identification, impact analysis, change prioritization and change measurement. According to Kilpinen [34], there are three main groups of impact analysis relative to the technique used, i.e. traceability impact analysis, dependency impact analysis and experimental impact analysis. Following is a brief overview of the related work and a comparison to our work.

Li [17] elaborated the importance of understanding the impact of change from a decision-maker’s point of view. The traceability techniques used in [17] involve an interdependency graph and traceability matrix. According to Goknil [33], the lack of semantics in trace links causes imprecise results in change impact analysis and further derails the impact problem. As a solution, the method proposed in [33] deals with a requirements metamodel with well-defined types of requirements relations. These relations are formalized and are then used to define change impact rules for requirements. In both of these studies, change prioritization and an understanding of the difficulty of applying the change is missing.

Ali and Lai [21] proposed a method for impact analysis for a global software development (GSD) environment. The method consists of three stages, starting with understanding change, analysing these changes against different GSD sites and finally making decisions regarding the change based on the analysis. Understanding the change is carried out with respect to the requirements. The impact is calculated as an estimate of the extent of changes that either could directly or indirectly affect development work at different GSD sites. The method, however, lacks a mechanism to prioritize changes.

The method in [18] uses slicing and dependency analysis at the use case map specification level to identify the potential impact of requirement changes on the overall system. The approach establishes the importance of understanding the impact of change at a higher level of abstraction given the disadvantages of code-level analysis. Similar to [17, 33], the method lacks prioritization and has difficulty measuring the changes. Similar to [18], the work done by Briand et al. [19] uses a UML model-based approach where the UML diagrams are first checked for consistency. The consistancy check ensures any impact analysis carried out using the UML diagrams do not have any issues. The impact analysis is carried out using a change taxonomy and model elements that are directly or indirectly impacted by the changes. Though this method provides a prioritization technique, an understanding of the difficulty in applying the change is missing.

Analysing the above methods of analysing requirements change, the following conclusions can be made:

• Most, if not all, methods mentioned with the exception of [19] focus predominantly on understanding which requirements are impacted by a change.

• Mechanisms for prioritizing the requested changes depending on their impact in order to facilitate better decision-making are not presented.

• The level of difficulty in applying the change has not been discussed in any of these methods, which can be a major deciding factor in choosing to accept or reject the change and also possibly leading to cost and effort calculation.

8 Conclusions and future work

In this paper, we have presented a method of requirements change analysis based on changes initiated at higher levels. It consists of three steps: namely (1) analysing the change using functions, (2) identifying the change difficulty and (3) identifying the dependencies using a matrix, and we illustrate the usefulness of our method by applying it to a university course management system. In order to explore the requirement change in greater depth, the method introduces two set of functions. These functions can be used to further expand changes identified through the method developed in [16]. The expanded changes provide an initial means of identifying which activities of the existing system may be affected by the change. In terms of understanding the impact on the system due to these changes, the method introduces two steps, namely the identification of the difficulty level of the change and the CDM. The difficulty level of the change corresponds to the complexities involved in applying the change, while the CDM provides a visual representation showing how each change affects the existing activities.

Through the application of our method to a case study as well as comparing our work with others, it can be concluded that the merits of our method include: (i) identification of conflicts and dependencies between requirement changes, (ii) allocation of priority to changes so that change practitioners are able to make informed decisions and (iii) understanding the difficulty of change so that early decisions can be made on the suitability of carrying out the change.

Though our method has only been applied to a university system, we believe that it still can be applied to a more complex system. Given that most commercial systems are complex, one possible way of applying our method and still achieving satisfactory results would be to categorize a complex system into smaller functional areas. Categorization of complex systems into smaller functional areas when analysing dependencies is supported by [31].

In future work, we plan to extend this approach in order to identify the effort that is needed to implement a requirement change and to apply it to a more complex case study. The current work can be extended to look in depth at the databases to identify exactly which database objects are impacted by the change. It would also be beneficial for the decision-making process to estimate the time required to implement the change.