Change Impact Analysis with a Goal-Driven Traceability-Based Approach
Wen-Tin Lee,∗ Whan-Yo Deng,†Jonathan Lee,‡Shin-Jie Lee§
Software Engineering Lab., Department of Computer Science and Information Engineering, National Central University, Jhongli, Taiwan 320
Recently, the growing popularity of requirements engineering attracts an increasing attention on requirements traceability and change impact analysis, which also imposes a great demand for a systematic approach in developing software systems to handling traceability relations and requirements changes in an automatic manner. In this work, a goal-driven requirements traceability approach is proposed to develop and manage requirements changes along three dimensions: (1) to develop software and manage requirements based on the goal-driven use case (GDUC) approach, (2) to establish and maintain the traceability relation with a design structure matrix (DSM) to derive the traceability tree, and (3) to analyze requirements change impacts through the partitioning of DSM into blocks to serve as a basis for calculating use case points. The proposed approach is illustrated by a benchmark problem domain of a meeting scheduler system. C 2010 Wiley Periodicals, Inc.
1. INTRODUCTION
A major challenge in requirements management is that creeping requirements, namely, changes in current requirements are not controlled or analyzed, affect all downstream deliverables.1 Consequently, projects with such creeping requirements are likely to fail. Recent progress in requirements traceability has demonstrated its applicability to performing impact analysis of requirements changes and to ensuring all source requirements being fully addressed.2
Analyzing change impacts with requirements traceability usually encounter three main problems:3 (1) the traceability relations to be maintained are often imprecise and out of date, (2) the establishment of traceability relations among requirements and work products is not integrated with the development process, and (3) the manual impact analysis is tedious and time consuming.
∗Author to whom all correspondence should be addressed: e-mail: wtlee@selab.csie.ncu .edu.tw.
†e-mails: deng@selab.csie.ncu.edu.tw.
‡e-mail: yjlee@selab.csie.ncu.edu.tw.
§e-mail: jielee@selab.csie.ncu.edu.tw.
INTERNATIONAL JOURNAL OF INTELLIGENT SYSTEMS, VOL. 25, 878–908 (2010)
C 2010 Wiley Periodicals, Inc. Published online in Wiley InterScience (www.interscience.wiley.com).• DOI 10.1002/int.20443
Several investigations have been conducted to address the requirements trace- ability problems, either by generating and maintaining traceability relations,4−9or by deÞning and adapting traceability models.10−12 Inspired by the requirements traceability reference model proposed by Ramesh and Jarke,10and as a continuous endeavor of our previous work on goal-driven requirements engineering to analyze the interactions among requirements,13−17this work presents a goal-driven approach with two key features to establishing the trace relations of goals and use cases:
• to identify the three types of links proposed in the reference model: evolution, dependency, and satisfaction, to serve as a basis for formulating the trace relations among goals and use cases; and
• to establish and maintain the traceability relation with design structure matrix (DSM),18−22 and to utilize the DSM partition mechanism to perform change impact analysis.
The meeting scheduler problem,23a widely used benchmark problem domain in requirements engineering community, is adopted throughout this work as an example to illustrate the proposed approach. In the sequel, we give an outline of our goal-driven use case model as a background information in Section 2.1, detail the main features of the proposed approach in Section 3, compare related work on requirements traceability and change impact analysis in Section 4, and Þnally summarize the beneÞts of the fusion of goal-driven approach and DSM in Section 5.
2. BACKGROUND WORK
In this session, we introduce background information on work that have signif- icant impacts on this work, especially, researches on goal-driven use case13,14and design structure matrix.18,20−22
2.1. Goal-Driven Use Case Method
A brief summary of our goal-driven use case model13to construct a use case model with goals is outlined below for the readers’ reference. To identify goals from domain descriptions and system requirements, we propose a faceted classiÞcation scheme so that each goal can be classiÞed with three facets: competence, view, and content. The competence describes whether a requirement is satisÞed completely or only to a degree. A rigid type of goal describes a minimum requirement that a target system must satisfy utterly. A soft goal describes properties or concerns that stakeholder care about for a target system and can be satisÞed to a degree. The view facet concerns whether a goal is actor speciÞc or system speciÞc. Actor-speciÞc goals are actors objectives in using a system; system-speciÞc goals are requirements on services that the system provides. A goal can be further distinguished based on its content and can be either related to a systems functional aspects or associated with the systems nonfunctional aspect.
A goal can be achieved, optimized, or maintained by its associated use case.
The use cases of the meeting scheduler system are established for actors meeting initiator and meeting participant (see Figure 1). For the actor meeting initiator, the use case Plan a meeting covers the scenario for an initiator to achieve an original goal
Figure 1. Use case model for meeting scheduler system template.
MeetingPlanned, which is a goal of rigid, actor speciÞc, and functional. Meanwhile, in the case of the actor meeting participant, the use case Register a meeting covers the case for a participant to achieve an original goal MeetingRegistered, which is a goal that is rigid, actor speciÞc, and functional.
To achieve a system-speciÞc goal, an extension use case may be created.
Referring to our example, the original use case Plan a meeting describes the process to create a meeting from the view of the actor initiator. The extension use cases Handle meetings in parallel and Resolve conßicts extends it to take all initiators into account, that is, to achieve the system-speciÞc goals MeetingHandleInParallel and SupportConßictResolution. The extension use cases Accommodate evolving data and Enforce privacy rules extend the original use case Register a meeting to achieve the soft, system-speciÞc, and functional goals EvolvingDataAccommondated and PrivacyRulesEnforced, respectively.
To achieve a nonfunctional goal, an extension use case serves as a constraint to qualify its original use case. In our example, several constraints (may be rigid or soft) on a meeting are considered as extension use cases to extend or constrain the behavior of the original use case Plan a meeting, which is a direct course to create a meeting, including Minimize Interactions, Keep Appropriate Performance, Support Reusability, and Maximize Usability. To enhance reusability, the use case models are further elaborated by extracting the common fragments among various use cases into an included use case by using “include” relationships. For example, the use cases Maintain constraints and Authorize users are included by the use case Plan a meeting and use case Register a meeting.
2.2. Design Structure Matrix
The design structure matrix (DSM) developed by Steward18is a square matrix with identical row and column labels to identify the dependencies between tasks and to sequence the engineering design processes. DSM is a complexity manage- ment tool to design and optimize complex systems, project tasks, and organization structures. There are three basic conÞgurations in a DSM: parallel, sequential, and coupled, to describe the relationships among the system elements (see Figure 2).
The parallel conÞguration is a conÞguration of no interaction between the two elements A and B, and the DSM entries between these two elements contain no marking. The sequential conÞguration shows that if element A sends information to or inßuences the behavior of element B, then the (Column A, Row B) entry contains a mark. The coupled conÞguration indicates that if two elements A and B require information from each other or inßuence each other, then each entry of (A,B) and (B,A) in the DSM contains a mark.
In Ref. 20, Browning reviewed four DSM applications to demonstrate their usefulness for product and process development, project planning and management, system engineering, and organization design. The four DSM applications, includ- ing component-based, team-based, activity-based, and parameter-based DSM, are categorized into Static DSM and Time-based DSM.
Figure 2. DSM conÞgurations.
• Static DSM: representing system elements existing at the same time, including component- based and team-based DSM.
1. Component-based or Architecture DSM: A system architecture can be modeled in terms of the relations among its components/elements. The potential reintegration of the elements can be further analyzed via clustering.
2. Team-based or Organization DSM: An organization can be decomposed into teams, and modeled as a system by documenting the interactions between the teams. The integration analysis can be applied to cluster teams into metateams and to minimize the interactions among clusters.
• Time-based DSM: representing system elements in a ßow through time, including activity- based and parameter-based DSM.
1. Activity-based or Schedule DSM: A process can be modeled through its consti- tuted activities by documenting the information ßow among the activities. The iterations/feedbacks in the processes can then be minimized by analyzing the DSM using sequence analysis methods, such as partitioning, tearing, banding, simulation, and eigenvalue analysis.
2. Parameter-based DSM: The low-level activities, design variables, system pa- rameters can be modeled by documenting the interrelationships between the parameters. The sequencing analysis methods can be utilized to reduce process duration and enhance design quality.
DSM employs several analysis methods to optimize complex systems and project tasks, such as partitioning, clustering, and simulation.21,22
3. GOAL-DRIVEN TRACEABILITY-BASED APPROACH TO CHANGE IMPACT ANALYSIS
There are four main features involved in this work to establish the traceability relations among goals and use cases and to evaluate the change impacts (see Figure 3 for an overview):
1. G2U and U2U relation identiÞcation: Goal to use case (G2U) evolution links and use case to use case (U2U) dependency links are identiÞed and maintained in the DSM.
2. U2G and G2G relation evaluation: Users are engaged to identify the satisfaction links related to use case to goal (U2G), and the goal-to-goal (G2G) dependency links are then established automatically in the DSM based on graph theory.
3. DSM partitioning and traceability tree derivation: The DSM, with four submatrices: G2U, U2U, U2G, and G2G, is partitioned into blocks to derive the traceability tree from the DSM.
4. Change impact analysis: When user proposes changes during software evolution, change impacts are analyzed to Þnd affected requirements as well as affected use cases and their corresponding use case points.24
3.1. G2U and U2G Relation IdentiÞcation
Although DSM is a powerful complexity management tool to design and op- timize the complex system with various DSM techniques, it is still limited in sys- tematically identifying and capturing the interactions/relations among the system
Figure 3. Overview of GART
elements. This work presents a systematic way to evaluate the relations between goals and use cases. A DSM is divided into four submatrices: G2U, U2U, U2G, and G2G matrices, to capture the traceability links (see Figure 4). Detail discussions are as follows.
3.1.1. Identify Relation from Goal to Use Case
To capture the links between goals and use cases, the three link types of traceability relations: evolution, dependency and satisfaction, between goals and use cases are required to be elaborated. Traceability link is deemed as an impact relation to reßect its applicability to performing impact analysis of the requirement changes.
The impact relation can be applied to work products as a result of performing a process, such as goals, use cases, designs, test cases, etc. An impact relation from a work product x to a work product y indicates that by changing work product x, work product y may be affected, which is formally deÞned below.
DEFINITION1. Let R be the impact relation on a set of work products W. For every x, y ∈ W, x R y if and only if change x may affect y. R is transitive because if x impact y and y impact z then it follows that x impact z for every x, y, z∈ W.
Figure 5 illustrates the three types of traceability links between goals and use cases. In Figure 5a, a goal evolves to a use case, namely, a goal has an evolution link
Figure 4. Traceability links between goals and use cases in DSM.
to its derived use case, by changing the goal, its derived use case may be affected.
Therefore, we can view evolution link as a kind of impact relation. In Figure 5b, a goal/use case depends on another goal/use case, that is, a goal/use case has a dependency link to its dependent goal/use case, changing the goal/use case may affect its dependent goal(s)/use case(s). Thus, we can treat dependency link as a kind of impact relation. In Figure 5c, a use case satisÞes its related goals to some
Figure 5. Link types between goal and use case.
Figure 6. Use case to use case dependency link.
degree, i.e. a use case has a satisfaction link to its related goal, changing the use case may affect its related goal(s). The deÞnition of these three types of traceability links is formally given below.
DEFINITION2. Let evolution link, satisfaction link, and dependency link∈ R be a kind of impact relation. The relations between goal and use case are deÞned by
1. an impact relation from a goal to a use case is an evolution link.
2. an impact relation between goals/use cases is a dependency link.
3. an impact relation from a use case to a goal is a satisfaction link.
We begin with identifying the evolution links from goals to use cases after the goals and use cases have been modeled. Since each goal is evolved to its associated use case, the goal to use case evolution links is one-to-one relations and is kept in the G2U submatrix of the DSM (see G2U matrix in Figure 4). The (Gi, Ui) entries (for i= 1, . . . , n) in DSM are marked as “1” to indicate the evolution links between them.
Referring to our example, the goal to use case evolution links—a one-to-one relation, of the meeting scheduler system are identiÞed in G2U matrix in Figure 4.
The evolution link from goal GMPto use case UPAMis identiÞed since use case UPAM
is discovered with respect to goal GMP. The (GMP, UPAM) entry in G2U matrix is marked as “1” to indicate the evolution link from goal GMPto use case UPAM. As a result, G2U Matrix in Figure 4 is a diagonal matrix since goals {GMP, . . . , GMU} have an evolution link to use case{UPAM, . . . , UMU}, respectively.
3.1.2. Identify Relation between Use Cases
The use case dependency links are illustrated in Figure 6. Use case U1includes use case U2and is extended by use case U3. Use case U5generalizes use case U4. U1 depends on U2through the “include” relation between U1and U2, which implies that a change in U2 may inßuence U1. U3 depends on U1 through the “extend”
relation between U1and U3, that is, a change in U1may inßuence U3. Owing to the semantics of the “generalize” relation, U5 depends on U4, since changing U4 may inßuence U5but not being inßuenced by any changes in U5.
When include, extend or generalize relation occurs between use cases, the corresponding DSM entries are marked as “1” based on the dependency links between them in the U2U submatrix of the DSM (see U2U matrix in Figure 4).
The use case to use case dependency links extracted from the use case model of meeting scheduler system is identiÞed in U2U matrix in Figure 4. Use cases URAM, URC, UMI, UFMT, and UKAPdepend on UPAMthrough the “extend” relations between them, that is, a change in UPAMmay inßuence URAM, URC, UMI, UFMT, and UKAP. To indicate the dependency links between these use cases, the entries (UPAM, URAM), (UPAM, URC), (UPAM, UMI), (UPAM, UFMT), and (UPAM, UKAP) are marked as “1” in the U2U matrix.
Use cases UPAMand URMdepend on UMC through the “include” relations be- tween them, namely, a change in UMCmay inßuence UPAMand URM. The correspond- ing DSM entries (UMC, UPAM) and (UMC, URM) in U2U matrix are marked as “1”
based on the dependency links between them. The diagonal entries in U2U matrix are marked as “1” to specify that each use case has a dependency link to itself.
3.2. U2G and G2G Relation Evaluation
Traceability link strength and direction are crucial factors in structuring require- ments traceability. The satisfaction degree of U2G satisfaction links are evaluated and resulted in U2G matrix in the “Evaluate Relations from Use Case to Goal”
section. The G2G dependency links between goals are analyzed to produce G2G matrix in the “Analyze Relations between Goals” section.
3.2.1. Evaluate Relation from Use Case to Goal
Goal and use case evaluation process involves measuring the satisfaction degree of U2G satisfaction links, which are maintained in the U2G submatrix of the DSM (see U2G matrix in Figure 4). In GDUC,13 each goal Gi, where{Gi| 1 ≤ i ≤ n, nis the total number of goals}, is achieved/optimized/maintained by its directly associated use case Um, where{Um| 1 ≤ m ≤ n, n is the total number of use cases}. In addition to the directly achieved/optimized/maintained relationships, we further examine the relationships between goals and use cases caused by side effects. The side effects to a goal Gi, where {Gi| 1 ≤ i ≤ n}, are analyzed by considering the effects of a use case Um to the goal Gi, where {Um| 1 ≤ m ≤ n, i = m}. By investigating all the effects, including the side effects among goals and use cases, the relationships between goals and use cases—the satisfaction degree, can be determined. In the evaluation, the satisfaction degree (Sdegree) of a goal is rated from−5 to 5 to represent the satisfaction degree to the goal while performing the use case. The score can be assigned by domain experts based on a rating table (see Table I as suggested in Ref. 25). In Table I, Þve means the goal can be fully satisÞed by the use case;−5 means the goal will be fully denied by the use case; and 0 means
Table I. DeÞne ratings of satisfaction links.
Score Explanation
5 The goal is fully satisÞed after the use case is performed 3 The goal is largely satisÞed after the use case is performed 1 The goal is partially satisÞed after the use case is performed 0 The goal is not affected after the use cases is performed
−1 The goal is partially denied after the use case is performed
−3 The goal is largely denied after the use case is performed
−5 The goal is fully denied after the use case is performed 2,4,−2, −4 Represent the degrees between scores listed above
the use case does not have any effect on the goal. Detail explanation of the rating of satisfaction degree can be found in Table I.
We further normalize the satisfaction degree to Sdegree/5 (−1 ≤ Sdegree/5≤ 1) to obtain the link strength of U2G satisfaction link. A fuzzy threshold T1 is introduced to provide the ßexibility that the satisfaction link can be Þltered out if|Sdegree/5| <
T1. The default value of fuzzy threshold T1 is 0 to keep all the satisfaction links identiÞed by users.
To analyze the satisfaction links from use cases to goals, we examine the relationships among goals and use cases in a pairwise manner by means of Table I, which results in the satisfaction links in U2G matrix in Figure 4. For example, the effect of performing use case UPAM is evaluated with respect to all goals in the system. GMP is rated as 5 since performing UPAM can fully satisfy the goal. GSF
is rated as 3 to indicate that performing UPAM can largely satisfy the goal. The effect of performing use case URCwith respect to goal GMIis rated as−2 to show that performing URC can partially to largely deny the goal. The link strength of satisfaction links (UPAM, GMP), (UPAM, GSF), and (URC, GMI) are normalized to 1, 0.6, and−0.4 in U2G matrix, respectively.
3.2.2. Analyze Relation between Goals
To derive the dependency links between goals, we formulate goals and use cases as a vertex set and traceability links as edges between goals and use cases in a graph. The G2U, U2U, and U2G links identiÞed in previous sections can be captured in the adjacency matrix of goals and use cases. Figure 7 illustrates how the concept works behind this formulation.
In Figure 7, goal G1 is evolved to use case U1, which satisÞes goal G2 to some degree. The adjacency matrix A of graph (a) is identiÞed and the entries (G1, U1) and (U1, G2) are marked as 1 to indicate the evolution and satisfaction links, respectively. The entry (G1, G2) in A2, the square of matrix A, is 1, which means that there exists an edge sequence of length 2 from G1to G2. This edge sequence is a path through G1→ U1 → G2, an evolution link from G1 → U1and a satisfaction link from U1 → G2, which implies there exists a dependency link from G1 to G2, according to the DeÞnitions 1 and 2.
Theorem 1 summarizes the formulation to derive goal-to-goal (G2G) depen- dency links based on graph theory (see Ref. 26 for a reference.)
Figure 7. Graph and its adjacency matrix.
THEOREM1. Let T be a graph with vertex set {G1, . . . , Gn},{U1, . . . , Un} and adjacency matrix A with G2U, U2U and U2G traceability links (n = number of goals/use cases).
If the (i, j )-entry of A2>0 where i, j = 1 . . . n, then Gihas a dependency link to Gj.
Proof. The (i, j )-entry of A2 is the number of edge sequences of length 2 from Gi to Gj with a path Gi → Ui → Gj. Suppose the (i, j )-entry of A2>0, that is, there exists at least one edge sequence through the path Gi → Ui → Gj. Therefore, Gi has an evolution link to Ui and Ui has a satisfaction link to Gj. According to DeÞnitions 1 and 2, evolution link and satisfaction link are a kind of impact relation that is transitive, Gi has an impact relation to Gj. From DeÞnition 2, the impact relation between goals is a dependency link. Thus, Gihas a dependency link
to Gj.
Referring to our meeting scheduler system, we obtain a G2G matrix in Figure 4 with the dependency links between goals. For example, the values 0.6 and 0.4 of the entries (GMP, GSF) and (GMP, GRC) in G2G matrix in Figure 4 are added from the same entries in the A2matrix created by applying Theorem 1, which means that there exist two dependency links from GMPto GSFand from GMP to GRC, respectively.
The two dependency links are generated through the paths GMP→ UPAM→ GSF
and GMP→ UPAM→ GRC. This indicates that to change GMPmay affect GSFand GRC, and therefore, GSFand GRCdepend on GMP.
Figure 4 presents the DSM with G2U, U2U, U2G, and G2G submatrices to show all the traceability links between goals and use cases. The entries in the G2U matrix containing the evolution links from goal to use case are kept in the (i,j )- entry (where i= 16, . . . , 30, and j = 1, . . . , 15) of the DSM. The entries in the U2U matrix, which contains the dependency links between use cases, are kept in the (i,j )-entry (where i= 16, . . . , 30, and j = 16, . . . , 30). The satisfaction degree Sdegree of U2G satisfaction links are established and normalized in the (i,j )-entry
(for i = 1, . . . , 15, j = 16, . . . , 30). The entries in the G2G matrix containing the dependency links between goals are kept in the (i,j )-entry (where i = 1, . . . , 15, and j = 1, . . . , 15).
3.3. DSM Partitioning and Traceability Tree Derivation
DSM partitioning is adopted here to group the goals and use cases into blocks to assist project managers to manage the requirements and plan the successive project tasks. The traceability tree can be derived from the DSM partition blocks to facilitate impact analysis in the case of any requirement change occurs.
3.3.1. Perform DSM Partitioning
According to Steward,27DSM partitioning is an algorithmic process of Þnding the blocks and ordering them such that all the predecessors of a block appear somewhere before that block. A block is the largest set of interdependent system elements involved in the iteration cycle. In our work—GART, DSM partitioning is to group the coupled system elements (goals and use cases) into blocks that can help project managers plan the successive project tasks and analyze the impacts of requirements changes.
Figure 8 shows the DSM partition result of our meeting schedule system, in which the traceability links are grouped into Þve blocks. Each block includes all the coupled goals and use cases that bidirectionally inßuence each other owing to the
Figure 8. DSM partition result of meeting scheduler system.
loop relations between these couples. That is, if an element in one block changes, all the elements in the same block may be affected.
Block 1, including goal GDRHand UAU, has links with blocks 3, 4, and 5, which means to change goal GDRH or use case UAUin block 1 may affect the other goals and use cases in blocks 3, 4, and 5. Because use case UAUis included by use cases UPAM and URM, by changing UAU may affect use cases UPAMand URM, as well as those use cases that extend UPAMand URM, and goals satisÞed by those use cases.
Block 2, including goal GKPC and use case UMC, has the same links as goal GDRHand UAUin block 1 to blocks 3, 4, and 5. Since use case UAUis also included by use cases UPAMand URM, by changing UMC may affect the same goals and use cases as changing the use case UAUin block 1.
The goals and use cases in blocks 3 and 4 can be viewed as goals and use cases for actor meeting initiator and meeting participant, respectively. There is no link between the elements in block 3 and block 4, hence changes in block 3 will not affect elements in block 4, and not being affected by any changes in block 3. Each block can be divided into four submatrices (see block 4 in Figure 8), which shows the G2U, U2U, U2G, and G2G relations between goals and use cases in each block.
Block 5 includes goals GAP, GSR, and GMU, which are soft, system speciÞc, and nonfunctional, and use cases UKAP, USR, and UMU, which are extension use cases with respect to use cases UPAMand URM. Changes in these goals and use cases in block 5 will not affect goals and use cases in blocks 1–4 since there is no link from the elements in block 5 to the elements in blocks from 1 to 4.
3.3.2. Derive Traceability Tree
Representing the system elements in a tree structure facilitates impact analysis of changes. From the DSM partition result, we can represent the traceability trees in terms of blocks or system elements. Figure 9 represents the DSM blocks in tree structure, which provides a higher level view to understand the relations among DSM blocks. Blocks 1 and 2 have no traceability relations between each other but have the traceability relation to blocks 3, 4, and 5, respectively. Blocks 3 and 4 have the traceability relations to block 5 but have no relation between each other. Block 5 has no traceability relation to other blocks.
Figure 10 shows the traceability tree T1 whose root is goal GDRHand contains the use case UAU in block 1 and related goals and use cases in blocks 3, 4, and 5.
From the tree structure, it is easy to identify the relations between elements in blocks. If the goal GDRHchanges, the related goals and use cases can be traversed and regarded as affected work products. GDRHtraverses the use case UAU in block 1 and related goals GMP, GMHP, GMI, GRC, and GSF,which further discover the use cases UPAM, UHMP, UMI, URC, and URAM in block 3. In block 4, GDRH traverses the related goals GEPR, GWM, GAED, GDP, and GRM, which further discover the use cases UEPR, UWM, UAED, UDP, and URM. In block 5, GMP also traverses the related goals GMU, GSR, and GAP, which further discover the use cases UMU, USR, and UKAP. DSM partition blocks together with traceability trees provide a visual way for project managers to organize project tasks, facilitate team communication, and perform change impact analysis.
Figure 9. Tree representation of DSM blocks.
Figure 10. Traceability tree T1 of goals and use cases.
Figure 11. Change impact analysis.
3.4. Change Impact Analysis
To successfully manage requirements change, change impacts should be cor- rectly analyzed to determine what would be modiÞed for the changes and to avoid the unforeseen ripple effects that frequently result in failures of a project.
When a user requests for a change, the traceability relations between work products can be utilized to analyze the affected work products to implement the changes. The proposed change impact analysis approach to analyzing the affected work products and the effort required to make the changes (see Figure 11).
• Step 1, the traversed change request with change items and the changed work products are grouped based on the DSM blocks where they reside.
• Step 2, the effect of the grouped change work products in the DSM blocks are analyzed to trace the impacted work products of each change work product and get the impact value by summed the results of the multiplication of each impacted use case’s use case points and the normalization value of the evolution, dependency and satisfaction links between goals and use cases in a rippled way.
• Step 3, the effects of the changes to related DSM blocks are analyzed, and the total affected work products, system size and effort required to make the changes are generated by utilizing use case point analysis method.
In order to show the practicability of our method with different conditions of requirements change, three changes, Change A, B and C are proposed and illustrated below.
Figure 12. Traversal result to change A.
3.4.1. Change A: Modify an Existing Requirement
We take Change A: Modify an existing requirement GRC and URC to support conßicts resolution with additional knowledge, as an example in meeting scheduler system to illustrate how change impact analysis together with use case point analysis can be applied to analyze change impacts.
Figure 12 shows the ripple traversal results of Change A. Starting with GRC
in Block 3, there are three dependency links from GRC to GSF , GMI and GMP, which will lead us to{URAM, UMIand UPAM}, respectively. By following the links originating from GMP, GMHP and UHMP can be further reached in block 3. Again, by tracing the dependency links from GMP to block 5, three sets of nodes can be found: goals {GSR, GAP, GMU}, and use cases{USR, UKAP, UMU}. Figure 12 also shows two important information: (1) the result after normalizing the dependency links between goals, for example 0.18 between GRC and GSF; and (2) the use case points of each affected use case, such as 15 points for UPAM.
Figure 13 presents the detail speciÞcation of use case URC. The original use case transactions, T1–T8, describe the scenario to solve the date conßict problem.
The new added use case transactions, T9–T12, describe the scenario to solve the problem when no allowable location available. We deÞne the change impact ratio (CIR) of a changed use case as
CIR= Transaction Added+ ModiÞed
Base Use Case Transaction (1)
Figure 13. Use case speciÞcation of URC.
Referring to Change A, we can obtain its CIR as 4/8= 0.5.
The impact metric V of a change with the changed use cases Ui is deÞned in Equation 2, where UCPj are the use case points of impacted use cases Ujof Ui in the same block, and Linksij are all the traversed links from Ui to Uj. UCPkare the use case points of impacted use cases Ukof Ui in other blocks, and Linksik are all
the traversed links from Ui to Uk. The fuzzy threshold T 2 is introduced to provide the ßexibility that the traceability links from Uito Ukcan be Þltered out if
Linksik(normalized value of Linksik) < T2.
V = CIR ×
⎛
⎝UCPi +
n j=1
Linksij
(normalized value of Linksij)× UCPj
+
m k=1
Linksik
(normalized value of Linksik)× UCPk
⎞
⎠ (2)
where n is the number of impacted use cases in the same block of Ui, m is the number of impacted use cases in other blocks, and
Linksik(normalized value of Linksik)≥ T2= 0.002.
Impact metric V of Change A can be derived as follows:
V= 0.5 × (15 + 0.2 × 1 × 10 + 0.18 × 1 × 5 + 0.07 × 1 × 15 + 0.07 × 0.29
×1 × 5 + 0.07 × (0.1 × 1 × 5 + 0.07 × 1 × 5 + 0.11 × 1 × 5)) = 9.57 To obtain the value of V, UCP of URC is added with the result of the sum of the use case points of the normalized value of the traversed links from GRC. For example, the impacted UCP of the use case UMI is added from the result of 0.2× 1× 10, where 0.2 is the normalized value of the dependency link from GRCto GMI, 1 is the value of evolution link from GMIto UMIand 10 is the UCP of use case UMI, respectively.
The technical complexity factor (TCF) and the environment factor (EF) of the meeting scheduler system are set to 0.85 and 0.8 based on the use case point approach to deriving impacted UCP, respectively.
Impacted Use Case Points (UCP) of Change A
= TCF × EF × V of Change A (3)
We then calculate the impacted use case points by Equation 3 after the change as follows:
0.85× 0.8 × 9.57 = 6.5 UCP
Suppose we use a factor of 20 person-hours per UCP, then the effort required to implement Change A can be obtained below:
Effort required to implement Change A= 6.5 × 20 = 130 person-hours
To further verify our estimation, a second estimate effort in person-months based on COCOMO228is also adopted as follows:
Code Size= 9.57 Unadjusted UCP × 0.8 × 50 = 383 LOC Person-month required to implement Change A
PMN S = A × SizeE×
n i=1
EMi
= 2.94 × (0.383)1.15× 0.85 = 0.83 person-month
= 132.8 person-hours
The way the code size is calculated is followed by the conversion ratios given in Ref. 29. The conversion ratios from unadjusted UCP to IFPUG function points and from IFPUG function points to java statement per function point are 0.8 and 50, respectively. As an average project, the effort multipliers of meeting scheduler system are all equal to 1.0 except the ACAP is 0.85 (analyst capability is high) to comply with the setting of UCP environment factors. A and E are set to 2.94 and 1.15, respectively. The result to implement the change is 131.2 person-hours by taking 1 person-month= 20 person-days. As a result, the two estimates end up with a 2.8 person-hours difference.
3.4.2. Change B: Add a New Requirement
We take Change B: Add a new requirement GEN and UEN to notify meeting initiator and participants by e-mail, as an example in meeting scheduler system to illustrate how to analyze change impacts of a new requirement (see Figure 14 for the traversal results of Change B). Since Change B is a new requirement, the CIR of Change B is 1 and the UCP of UEN is 5 obtained by analyzing its use case speciÞcation in Figure 15.
To obtain the value of V, UCP of UEN is added with the result of the sum of the use case points of the normalized value of the traversed links from GEN. For example, the impacted UCP of the use case URAMis added from the result of 0.07× 0.15× 1 × 5, where 0.07 is the normalized value of the dependency link from GEN
to GMP, 0.15 is the normalized value of the dependency link from GMPto GSF, 1 is the value of evolution link from GSFto URAM, and 5 is the UCP of use case URAM, respectively.
Impact metric V of Change B can be derived as follows:
V= 1 × (5 + 0.07 × 1 × 15 + 0.07 × (0.15 × 1 × 5 + 0.12 × 1 × 15 + 0.13
×1 × 10 + 0.15 × 1 × 5) + 0.07 × (0.1 × 1 × 5 + 0.07 × 1 × 5 + 0.11
Figure 14. Ripple traversal to change B.
Figure 15. Ripple traversal to change B.
×1 × 5) + 0.08 × 1 × 15 + 0.08 × (0.14 × 1 × 10 + 0.14 × 1 × 10 + 0.15
×1 × 5 + 0.12 × 1 × 5) + 0.08 × (0.1 × 1 × 5 + 0.07 × 1 × 5 + 0.11
×1 × 5)) = 8.11
We then calculate the impacted use case points by Equation 3 after the change as follows:
0.85× 0.8 × 8.11 = 5.5 UCP.
The effort required to implement Change B can be obtained by using a factor of 20 person-hours per UCP below:
Effort required to implement Change B
= 5.5 × 20 = 110 person-hours
Based on COCOMO2, a second estimate effort in person-months is also adopted as follows:
Code Size= 8.11 Unadjusted UCP × 0.8 × 50 = 324 LOC Person-month required to implement Change B
PMN S = A × SizeE×
n i=1
EMi = 2.94 × (0.324)1.15× 0.85
= 0.68 person-month = 108.8 person-hours
The result to implement the change is 108.8 person-hours by taking 1 person- month= 20 person-days. As a result, the two estimates of Change B end up with only a 1.2 person-hours difference.
3.4.3. Change C: Modify Two Requirements
We take Change C: Modify two requirements GAED and UAED to support the meeting customization, and GDPand UDPto support partial meeting participation.
Figure 16 show the traversal results of Change C. Referring to Change C on the use case speciÞcations of UDPand UAED (see Figures 17 and 18), both the CIR of UDP
and UAEDare 1/4= 0.25.
To obtain the value of V, UCP of UDP and UAED are added with the result of the sum of the use case points of the normalized value of the traversed links from GDP and GAED. For example, the impacted UCP of the use case URM is added from the result of 0.08× 1 × 15, where 0.08 is the normalized value of the
Figure 16. Ripple traversal to change C.
dependency link from GDP to GRM, 1 is the value of evolution link from GRM to URM, and 15 is the UCP of use case URM, respectively. The traceability links from GDP→ GAED → GRM→ GSR, GAPand GMU, and from GAED→ GGDP → GRM→ GSR, GAP, and GMUcan be Þltered out by Equation 2, since the results of
Linksik
(normalized value of Linksik) < T 2.
Impact metric V of Change C can be derived as follows:
V= 0.25 × (10 + 0.08 × 1 × 15 + 0.08 × (0.15 × 1 × 5 + 0.12 × 1 × 5 + 0.1
× 1 × 5 + 0.07 × 1 × 5 + 0.11 × 1 × 5) + 0.13 × 1 × 10 + 0.13 × 0.08
× (1 × 15 + 0.15 × 1 × 5 + 0.12 × 1 × 5)) + 0.25 × (10 + 0.08 × 1 × 15 + 0.08 × (0.15 × 1 × 5 + 0.12 × 1 × 5 + 0.1 × 1 × 5 + 0.07 × 1 × 5 + 0.11 × 1 × 5) + 0.13 × 1 × 10 + 0.13 × 0.08 × (1 × 15 + 0.15 × 1 × 5 + 0.12 × 1 × 5)) = 6.44
Figure 17. Use case speciÞcation of UDP.
We then calculate the impacted use case points by Equation 3 after the change as follows:
0.85× 0.8 × 6.44 = 4.38 UCP
Suppose we use a factor of 20 person-hours per UCP, then the effort required to implement Change C can be obtained below:
Effort required to implement Change B
= 4.38 × 20 = 87.6 person-hours
A second estimate effort in person-months based on COCOMO2 is adopted as follows:
Code Size= 6.45 × 0.8 × 50 = 258 LOC
Figure 18. Use case speciÞcation of UAED.
Person-month required to implement Change C
PMN S = A × SizeE×
n i=1
EMi
= 2.94 × (0.258)1.15× 0.85 = 0.53 person-month
= 84.8 person-hours
The result to implement the change is 84.8 person-hours by taking 1 person- month= 20 person-days. As a result, the two estimates of Change C end up with a 2.8 person-hours difference.
4. RELATED WORK
Work in a number of Þelds has made its mark on our research. Our approach has drawn upon several ideas from requirements traceability techniques and change impact analysis methods.
4.1. Requirements Traceability
Several studies11,30−32have shown the importance and issues of using the re- quirements traceability techniques to trace the requirements with other work prod- ucts, such as design, source code, and test cases, in the software development life-cycle.
Gotel and Finkelstein30investigated and reported the requirements traceability problems and recommended several solutions. They observed a lack of “pre-RS traceability,” meaning that no traceability information was available before inclusion in the requirements speciÞcation. D’omges and Pohl12 proposed a framework of adaptable traceability environments to support the deÞnition and usage of project- speciÞc trace data and strategies. The organizational learning about project-speciÞc requirements traceability should be empowered to guide stakeholder in trace capture and usage, and support continuous process improvement.
Spanoudakis et al.4developed a rule-based approach to automatically generate four traceability relations between requirement statement documents, use cases documents, and analysis object models of a software system by using two different traceability rules, the requirements-to-object-model and interrequirement rules.
Egyed proposed a scenario-driven approach5to generating and validating trace dependencies among model elements that are related to code. A test scenario or usage scenario is tested to generate observed traces for further trace analysis with other hypothesized traces. The new trace dependencies among model elements and code are then yielded and validated to solve the inconsistency and incompleteness.
To address the human source issue of requirement traceability, Gotel and Finkelsten7 presented contribution structure to locate people with their contributed artifacts in the contribution format. The social roles, role relations, and commitments can be further inferred to form the personnel-based requirements traceability.
Cleland-Huang et al.9developed an event-based traceability (EBT) approach, based on event notiÞcation, to tracing and maintaining the artifacts and their related links during the software life cycle. The EBT’s architecture has the following three main parts: Requirements Manager handles requirements evolution with identiÞed change events and triggers the events by publishing an event message when a change occurs. Event Server manages subscriptions and receives event messages from the requirement manager. It then customizes event notiÞcations into a speciÞc update directive, and forwards it to the subscriber manager. Subscriber Manager receives and resolves event notiÞcations and restores an artifact and related traceability links to a current state if necessary. Cleland-Huang et al.8 also presented a goal-centric approach to manage nonfunction requirements in four steps. First, nonfunctional requirements are modeled by a soft goal interdependency graph (SIG). Second,
when the changes occur, the trace links are dynamically generated using probabilistic network model and Þltered by users to remove the irrelevant ones. Third, the affected SIG elements are analyzed and evaluated to determine whether other goals are affected and still satisÞed after the changes. Finally, the decision on whether to implement changes is made, and risk mitigation strategies are identiÞed before performing the changes.
These requirements traceability work can be characterized with criteria listed below, which are then served as a basis for making the comparison for the pros and cons of the above-mentioned work (see Table II).
• Traceability Techniques: the traceability technique/method proposed or adopted,
• Requirements Types: the requirements that the approaches can handle, in particular, whether the approaches can handle nonfunctional requirements,
• Vertical Traceability: whether the approaches can manage the traceability relation from
“a requirements to its derived requirements and allocation to functions, interface, objects, people, process and work products,”33
• Horizontal Traceability: whether the approaches handle relations across requirements or interfaces,33and
• Traceability Visualization: how the traceability relations are presented.
4.2. Change Impact Analysis
Managing changes to a software system is critical to the success of the system, since software undergoes change during the whole life cycle of software. Change impact analysis is deÞned as “identifying the potential consequences of a change, or estimating what needs to be modiÞed to accomplish a change”.34To successfully manage requirements changes, change impacts should be correctly analyzed to determine what should be modiÞed for the changes and to avoid the unforeseen ripple effects that frequently result in failures.
Bohner35 has proposed a basic software change impact analysis process to iteratively discover impacted “software life-cycle objects (SLOs)”. The fan-in/out relations of the SLOs are identiÞed in the connectivity matrix. The reachability matrix using the notion of distance indicators can then be used to indicate potential impacts to a SLO. The semantics of the relations are employed to increase the accuracy of Þnding the impacted elements. Three key challenges of impact analysis:
huge information sources, semantics of software artifacts relationships, and work product dependency analysis methods are discussed, and the change effect on the middleware and COTS components are addressed to solve the change problem through interoperability dependency relationships.
In Ref. 36 and 37, an impact analysis method was presented to evaluate re- quirements change based on traceability relations between the work products. For each change, the impacted work products are traced to compute the impact metrics, the changes are then categorized into groups (compatibility class) from low to high based on the computed impact values using the compatibility relation.
To analyze the change impact on UML models, Briand et al.38has proposed an impact analysis approach to analyze and prioritize the impacted model elements in the UML models using the impact analysis rules and distance measure for each
TableII.Comparisonofworkonrequirementstraceability. OurWorkCleland-Huangetal.Egyedetal.Zismanetal.GotelandFinkelstein TraceabilityTechniquesGoal-DrivenandDSMEvent-Basedand ProbabilityInference Model
Scenario-BasedRule-BasedContributionStructures RequirementsTypesGDUCcanhandle functionaland non-functional requirements
UseSoftgoal Interdependency Graph(SIG)to modelnon-functional requirements Non-functionalrequirements canbeaddressedNon-functional requirementsarenot explicitlyaddressed
Requirementstypesare notexplicitly speciÞed VerticalTraceabilitySupportbyevolution andsatisfactionlinksFromgoalstolow-level artifactsRequirements/model elementsrelatedtocode canbetraced
Fromrequirements/use casestoobject models
ExtendArtifact-based traceabilitywith Personal-based traceability HorizontalTraceabilityStrengthanddirection ofdependencylink aresupported
UseSIGforgoals dependenciesTracedependenciescanbe generatedamongany elementsthatrelateto code Fromrequirementsto requirements/ requirementstouse cases
Notexplicitly addressed Traceability VisualizationDSMblocksand traceabilitytreeTableandmatrixviewFootprintgraphisproposedTableviewContributionformat WeaknessUserevaluationisstill requiredfortrace relationanalysis
Therecallandprecision ratesoftheretrieved linksarethemajor concern Completetraceability coveragemaynotbe provided Therecallandprecision ratesofthe generatedtracelinks arethemajor concern
Theworkinvolvedto establishandutilize thecontribution structures StrengthSystematicwayto identifytrace relationsanduse DSMtopartition andvisualizethe tracerelations
Dynamicallyretrievethe linkstoreducethe overheadof traceability establishment Tracelinkscanbegenerated byanalyzingthescenario, codeandmodelelements Automaticgeneration oftraceability relationsusingrule inference Thetraceabilityto humansourcesof requirementsis provided
change. The impact analysis of changed model elements can be automated using the OCL rules deÞned for each change type. In their approach, very detailed UML model information should be used and the method to perform automatic impact analysis is not clearly stated.
In Ref. 39, a traceability-based approach to analyze change impacts between requirements, test cases, design (packages and classes), and code (methods) is presented. The traceability model and code parser with structure relationships in C++
are illustrated to support the top-down and button-up analysis of change impacted artifacts. However, how to establish the trace links between software artifacts is not clearly addressed and the required effort and schedule for a change are not analyzed.
Based on use case map (UCM) technique, Hassine et al.40use requirement de- pendencies with forwarded slicing algorithm to analyze ripple effect of the changes at the requirement level. The requirement dependencies include scenario dependen- cies and component-based dependencies. The scenario dependencies are classiÞed in three types: functional, containment, and temporal. The component dependen- cies include forward and backward dependence to identify the relations between components using the scenario execution sequence.
Lock and Kotonya41provide an integrated approach that integrates traceability extraction methods to determine impactables affected by the change in the impact propagation structures using propagation probability. The traceability analysis then be conducted to produce a single impact propagation structure using vertical com- position, lateral composition, duplication resolution, and probability decay. In their approach, how to solve the loop problem is not addressed in the analysis process.
To predict software change impact, a study had conducted to investigate the correlations between standard diagrams (UML diagrams and dataßow diagram) and the change request characteristics (type, scope, estimated, and actual effort).42The analysis results of three change requests are presented to show the relationship between actual implementation effort and impacted diagrams. However, it is lack the systematic analysis approaches to analyze the affected software artifacts and to predict the required effort.
In Ref. 43, a model called Architecture Rationale and Element Linkage (AREL) is proposed to model the relations between architecture elements and decisions.
The Bayesian Belief Network (BBN) is used to capture the probabilistic relations between the elements in the AREL model and to predict the change impacts when the requirement changes occur.
In Ref. 44, a framework for comparison of the impact analysis (IA) approaches is proposed. It includes three parts: “IA application” to examine how the approach is used to perform IA, “IA parts” to examine the internal elements and methods used by the IA approach and “IA effectiveness” to examine how well and accuracy the approach does. The IA approaches they compared include the dependence analysis techniques among program entities. We summarize the comparison between these change impact analysis approaches with a list of criteria in Table III. The detailed descriptions of these criteria are as follows:
• Impact analysis methods: What technique the impact analysis approaches proposed or used to performed change analysis?
