Dependency Link Derivation Process and Theorems of Requirements Traceability Matrix

Transcription

1 2016 International Computer Symposium Dependency Link Derivation Process and Theorems of Requirements Traceability Matrix Wen-Tin Lee Department of Software Engineering National Kaohsiung Normal University Kaohsiung, Taiwan Abstract This work proposes traceability link derivation process and theorems to establish the trace links between system objectives, requirements, design models and system/subsystems/components. The traceability relation definitions and three kinds of traceability links are defined by adopting requirements traceability reference models. Based on the definitions and graph theory, the dependency link derivation theorems are provided to derive traceability relations of requirements traceability matrix in an automatic way. The proposed approach can be served as a basis for requirements management that can deal with the requirements traceability issues, such as degree of satisfaction, strength of dependency, dependency link direction and change impact analysis. Keywords-Requirements traceability matrix, dependency link derivation, traceability relation, requirements management. I. MOTIVATION Several studies have shown the importance of using the requirements traceability techniques to trace the requirements with other work products, such as design, source code and test cases, in the software development life-cycle [1], [2], [3], [4], [5], [6], [7], [8]. Establishing and maintaining requirements traceability usually encounter two major problems: (1) the traceability relations to be maintained are often imprecise and outof-date, and (2) the establishment of traceability relations among requirements and work products is not integrated with the development process. Several investigations have been conducted to address the requirements traceability problems, either by generating and maintaining traceability relations [9], [10], [11], [12], [13], [14], or by defining traceability models and relations [15], [1], [16]. However, two main issues are still remained to be explored: Although current approaches are supportive with the establishment of requirements traceability information, they are not systematically integrated with the development process. Although link strength and direction are crucial factors in the structuring of requirements traceability, few attempts have been made to address such issue. Inspired by the requirements traceability reference model proposed by Ramesh and Jarke [15], this work presents traceability relation definitions and link derivation theorems based on graph theory to formulating the trace relations among requirements and software work products. The proposed approach can be served as a basis of requirements traceability theory that can deal with the requirements traceability issues, such as degree of satisfaction, strength of dependency, and dependency link direction. Background work related closely to this research will be outlined in the next section. Section III describes the definitions of requirements traceability relations. Section IV illustrate the traceability link derivation process. Section V presents related work on requirements traceability. Finally, we use a algorithm to summarize the proposed approach and give a conclusion. II. BACKGROUND WORK In the proposed approach, the evolution, dependency, and satisfaction traceability links presented in the reference models [15] are adopted to establish requirements traceability among higher-level objects and lower-level objects. The traceability links are captured in a matrix that can be used to derive links automatically using the proposed theorem based on graph theory. A. Requirements Traceability Reference Model Ramesh [17] reported the factors that influence the traceability practices of high-end and low-end traceability users. The facilitating and impeding characteristics of the factors can be adopted to determine the success of traceability implementation. Following an empirical study on a wide range of traceability practices with low-end and high-end users of traceability, Ramesh and Jarke [15] presented a requirements traceability reference model comprising four submodels, namely requirements management, rationale, design allocation and compliance verification. The reference model can be tailored according to organization/project needs in order to manage requirements traceability. Their model adopts four types of traceability links, satisfies, depends-on, evolves-to and rationale and discusses issues involved in implementing each type of traceability link /16 $ IEEE DOI /ICS

2 Figure 1. Requirements Traceability Reference Model Adopted Figure 1 shows the adopted requirements traceability model which includes three kinds of traceability links, evolution, dependency, and satisfaction links, from the reference models proposed by Ramesh [15]. In figure 1, system objectives can generate requirements which means there exist generate evolution links from system objectives to requirements. In this context, system objectives are higher-level objects and requirements are lower-level objects. The requirements can satisfy system objectives in some degrees which means there exist satisfaction links from requirements to system objectives. The requirements can drive design models which can drive system/subsystems/components. In this case, the drive evolution links are identified from requirements to design models and from design models to system/subsystems/components. The design models, which can be satisfied by system/subsystems/components, can also satisfy requirements in some degree. A system objective can depend on another system objective which means there exist a dependency link between them. The requirement/design model/system/subsystem/component can also has dependency links to its related peer objects. III. DEFINITIONS OF THE REQUIREMENTS TRACEABILITY RELATIONS To capture the links between higher-level objects and lower-level objects, the three link types of traceability relations between higher-level objects and lower-level objects are in need for further evaluation. We first treat traceability links as a kind of impact relation to reflect its applicability to performing impact analysis of requirements change (see Figure 2. Link Types between Higher-level Object and Lower-level Object Definition 1). We then define the evolution, dependency, satisfaction and rationale links as a kind of impact relation between higher-level objects and lower-level objects in Definition 2. Definition 1. Let traceability relations R be the impact relations on the set of work products W defined by x R y if and only if change x may affect y for every x, y W 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 Definition 2. Let evolution link, satisfaction link and dependency link R be a kind of traceability relation. The relations between higher-level objects to lower-level objects are defined by 1) An evolution link from a higher-level object to a lowerlevel object is an impact relation. 2) A dependency link between higher-level objects/lowerlevel objects is an impact relation. 3) A satisfaction link from a lower-level object to a higher-level object is an impact relation. Figure 2 illustrates the traceability links between higherlevel objects and lower-level objects. In Figure 2-(a), a higher-level object evolves to a lower-level object. For example, a requirement has an evolution link to its derived design model, by changing the requirement may affect its derived design model. In Figure 2-(b), a higher-level/lower-level object depends on another higher-level/lower-level object. For example, a requirement has a dependency link to its dependent requirement, by changing the requirement may affect its dependent requirement(s). In Figure 2-(c), a lowerlevel object satisfies its related higher-level object to some degree, i.e. a requirement has a satisfaction link to its related system objective, by changing the requirement may affect its related system objective(s) IV. TRACEABILITY LINK DERIVATION PROCESS In this work, a systematic process is presented to evaluate the relations between higher-level objects and lower-level objects. Four steps are proposed to identify and evaluate 562

3 Figure 3. Traceability Link Derivation Process the relations between them, and a matrix, called traceability matrix, is divided into four sub-matrices to capture the traceability links (see Figure 3): 1) Identify Relation from Higher-level Object to Lowerlevel Object: The higher-level object to lower-level Object evolution links are identified and kept in the HL sub-matrix. 2) Identify Relation between Lower-level Objects: The dependency links between lower-level objects are identified and kept in the LL sub-matrix. 3) Evaluate Relation from Lower-level Object to Higherlevel Object: Users will be engaged to identify the satisfaction links related to lower-level object to higherlevel object 4) Analyze Relation between Higher-level Object: The dependency links between higher-level objects are derived automatically by using matrix multiplication based on the notion of graph theory. A. Identify Relation from Higher-level Object to Lower-level Object In the first phase of the traceability relation evaluation process, we begin with identifying the evolution links from higher-level object to lower-level object after they have been modelled. Since each higher-level object is evolved to its associated lower-level objects, the evolution links between are one-to-one or one-to-many relations, and are kept in the HL sub-matrix of the traceability matrix (see HL matrix in Figure 3). The (H i, L j ) entries (for i = 1,..., m, j = 1,...,n; m = number of higher-level objects, n = number of lower-level object) in traceability matrix are marked as 1 to indicate the evolution links between them. B. Identify Relation between Lower-Level Objects When there exists traceability relations between lowerlevel objects, the corresponding entries of LL sub-matrix are marked as 1 based on the dependency links between them (see LL sub-matrix in Figure 3). C. Evaluate Relation from Lower-Level Object to Higher- Level Object Traceability link strength and direction are crucial factors in the structuring of requirements traceability. The satisfaction degree of satisfaction links from lower-level object to higher-level object are evaluated to result in LH matrix. The evaluation process involves measuring the satisfaction degree of LH satisfaction links which are kept in the LH sub-matrix of the traceability matrix (see LH sub-matrix in Figure 3). To analyze the satisfaction links from lower-level to higher-level objects in the third phase of the evaluation process, we examine the relationships among higher-level objects and lower-level objects in a pairwise manner by utilizing Table I, which results in the satisfaction links in LH sub-matrix. The gauge of satisfaction values is from 1 to -1. 1/-1 means that the goal is fully satisfied/fully denied after the use case is performed. 0.2/-0.2 means that the goal is partially satisfied/partially denied after the use case is performed. 0 means that the goal is not affected after the use cases is performed. Others represent the degrees between scores listed above. Detail explanation of the rating of satisfaction degree can be found in Table I. Table I RATINGS DEFINITION OF SATISFACTION VALUES Score Explanation 1 The higher-level object is fully satisfied after the lowerlevel 0.6 The higher-level object is largely satisfied after the lowerlevel 0.2 The higher-level object is partially satisfied after the lower-level 0 The higher-level object is not affected after the lower-level -0.2 The higher-level object is partially denied after the lowerlevel -0.6 The higher-level object is largely denied after the lowerlevel -1 The higher-level object is fully denied after the lower-level 0.4, 0.8, Represent the degrees between scores listed above -0.4, -0.8 D. Analyze Relation between Higher-Level Objects In the final phase of the traceability relation evaluation process (see HH sub-matrix in Figure 3), the HH dependency links between higher-level objects are analyzed to produce HH sub-matrix. In order to derive the dependency links between higher-level objects, we formulate higher-level objects and lower-level objects as a vertex set and traceability links as edges between higher-level objects and lower-level objects in a graph. The HL, LL and LH links identified in previous sections can be captured in the HL, LL and LH sub-matrices. The dependency links between higher-level objects can be generated in the HH sub-matrix automatically using the theorems 1 and 2 based on the notion of graph 563

4 of length 2 from H i to H j with a path H i L i H j.if the (i, j)-entry > 0, then H i has a dependency link to H j, i.e. change H i may affect H j. Proof: If the (i, j)-entry of A 2 > 0, it means that there exist at least one edge sequence through the path H i L i H j. Thus H i has a evolution link to L i, and L i has a satisfaction link to H j. According to Definitions 1 and 2, evolution link and satisfaction link are a kind of impact relation which is transitive, then H i has a impact relation to H j. From Definition 2, the impact relation between higherlevel object is a dependency link, thus Hi has a dependency link to Hj which means that change H i may affect H j. Figure 4. Graph and its Adjacency Matrix theory. After the HH sub-matrix is generated, the four submatrices (HL, LL, LH and HH matrices) are all included in the traceability matrix that can be used for requirements management and change impact anlaysis. Figure 4 illustrates how the concept works behind this formulation. In Figure 4-(a), higher-level object H 1 is evolved to lower-level object L 1, which satisfies higher-level object H 2 to some degree. The adjacency matrix A of graph (a) is identified and the entries (H 1, L 1 ) and (L 1, H 2 ) are marked as 1 to indicate the evolution and satisfaction links, respectively. The entry (H 1,H 2 )ina 2, the square of matrix A, is 1, which means that there exists an edge sequence of length 2 from H 1 to H 2. This edge sequence is a path through H 1 L 1 H 2, an evolution link from H 1 L 1 and a satisfaction link from L 1 H 2, which implies a dependency link from H 1 to H 2, according to the Definitions 1 and 2. In Figure 4-(b), higher-level object H 3 is evolved to lowerlevel object L 3, and L 3 has a dependency link to lower-level object L 4, i.e. L 3 depends on L 3. L 4 has a satisfaction link with its original goal H 4. The adjacency matrix B of graph (b) is identified and the (H 4,L 4 ), (L 4,L 4 ) and (L 4,H 4 ) entries are marked as 1 to indicate the evolution, dependency and satisfaction links, respectively. The (H 3,H 4 )inb 3, the cube of matrix B, is 1, which means that there exists an edge sequence of length 3 from H 3 to H 4. This edge sequence is a path through H 3 L 3 L 4 H 4 that implies a dependency link from H 3 to H 4. Theorem 1 and 2 are given below to summarize the formulation to derive the higher-level objects to higher-level objects (HH) dependency links, which is based on the graph theory 10.1 in [18]. Dependency Link Derivation Theorem 1. Let T be a graph with vertex set H 1,..., H m,l 1,..., L n and adjacency matrix A with HL, LL and LH traceability links (m=number of higherlevel objects, n=number of lower level objects). The (i, j)- entry of A 2 (i, j = 1...m) is the number of edge sequences Dependency Link Derivation Theorem 2. Let T be a graph with vertex set H 1,..., H m,l 1,..., L n and adjacency matrix A with HL, LL and LH traceability links (m=number of higherlevel objects, n=number of lower level objects). The (i,j)- entry of A 3 (i, j = 1...n) is the number of edge sequences of length 3 from H i to H j. If the (i, j)-entry of A 3 > 0 and the (i, j)-entry of A 2 = 0, then there exists a path H i L i L j H j. Thus, H i has a dependency link to H j, i.e. change H i may affect H j. Proof: If the (i, j)-entry of A 3 > 0 and the (i, j)-entry of A 2 = 0, it means that there exists at least one edge sequence through the path H i L i L j H j. Thus H i has a evolution link to L i, L i has a dependency link to L j, and L j has a satisfaction link to H j. Since evolution link, dependency link and satisfaction link are a kind of impact relation which is transitive, H i has a impact relation to H j. From definition 2, the impact relation between higher-level object is a dependency link, thus Hi has a dependency link to Hj which means that change H i may affect H j. V. RELATED WORK Gotel and Finkelstein [2] investigated 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 specification. Dómges [16] proposed a framework of adaptable traceability environments to support the definition and usage of projectspecific trace data and strategies. The organizational learning about project-specific requirements traceability should be empowered to guide stakeholders in trace capture and usage, and support continuous process improvement. Spanoudakis et al. [9] developed 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 (RTOM) and inter-requirement rules (IREQ). 564

5 Egyed proposed a scenario-driven approach [10], [19] to generate and validate trace dependencies among model elements that are related to code. A test scenario or usage scenario are 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 inconsistencies and incompletenesses. To address the human source issue of requirement traceability, Gotel and Finkelsten [12] 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 personnelbased requirements traceability. Cleland-Huang et al. [14] developed an event-based traceability (EBT) approach, based on event notification, to trace and maintain the artifacts and their related links during the software lifecycle. The EBT s architecture has the following three main parts: Requirements Manager handles requirements evolution with identified 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 notifications into a specific update directive, and forwards it to the subscriber manager. Subscriber Manager receives and resolves event notifications and restores an artifact and related traceability links to a current state if necessary. Cleland-Huang [13], [20] also presented a goalcentric approach to manage non-function requirements in four steps. First, nonfunctional requirements are modeled by a softgoal interdependency graph (SIG). Second, when the changes occur, the trace links are dynamically generated using probabilistic network model, and filtered 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 satisfied after the changes. Finally, the decision on whether to implement changes is made, and risk mitigation strategies are identified before performing the changes. VI. SUMMARY In a nutshell, the proposed approach can be summarized in Algorithm 1 which outlines the process involved in establishing a requirements traceability matrix and deriving traceability links. The higher-level objects and lower-level objects are denoted as vertex set in Theorem 1 and 2, and adjacency matrix A is used to capture the relations between higher-level objects and lower-level objects. The steps in the algorithm are described in detail below. In Step 1 of Algorithm 1, a square matrix A is created with m+n elements for m higher-level objects and n lowerlevel objects. All the entries in the matrix are initialized to 0, signifying no relation between the higher-level objects and lower-level objects. For phases 1-3 of the higher-level objects and lower-level objects evaluation process, the corresponding traceability matrix are established. The evolution links from higher-level objects to lower-level objects are identified in HL sub-matrix in Step 2. The dependency links between lower-level objects are identified in LL sub-matrix in Step 3. The satisfaction degrees S degree of LH satisfaction links are identified and normalized in LH sub-matrix in step 4. After Steps 2-4 are complete, the HH dependency links can be generated by steps 5-7 of Algorithm 1. From Theorem 1, matrix A is squared to calculate the number of links from H i to H j through the path H i L i H j in the HH submatrix of the HHSquareMatrix in Step 5. Matrix A is then cubed to obtain the number of links from H i to H j through the path H i L i L j H j in Step 6. The HH matrix is evaluated to obtain the dependency links between higherlevel objects from the HHSquareMatrix and HHCubeMatrix. In step 7, the links in the HHSquareMatrix are added first into matrix A. If no relation is found in the entries of the HHSquareMatrix, but one exists in the same entry of the HHCubeMatrix, then the links in the HHCubeMatrix are added into matrix A. The HH dependency links are established in the HH sub-matrix of matrix A. Matrix A can be further analyzed using matrix analysis methods, such as DSM partition algorithm [21], [22] to partition the matrix into blocks which include the coupled higher-level and lower-level objects, which bi-directionally influence each other owing to the loop relations among them. The matrix A can also be used to derive traceability trees [23] which can help developers to perform change impact analysis. Algorithm 1. Traceability Link Derivation Algorithm Let G be a graph with vertex set H 1,..., H m,l 1,..., L n and adjacency matrix A. 1. Establish (1) a square matrix A with m+n elements H 1,..., H m,l 1,..., L n, initialize (i, j)-entry = 0 for i = 1,..., m+n, j = 1,...,m+n (2) HHSquareMatrix and HHCubeMatrix with m elements H 1,..., H n 2. Let (i, j)-entry =1ifH i has a evolution link to L j for i=1,..., m, j=m+1,..., m+n 3. Let (i, j)-entry =1ifL i has a dependency link with L j for i = m+1,..., m+n, j = m+1,..., m+n 4. Let (i, j)-entry = S degree,ifl j satisfy H i in S degree value (for i = m+1,..., m+n, j = 1,..., n) 5. Squaring the matrix A, save the (i, j)-entry (i, j = 1...n) of the result matrix ra to HHSquareMatrix 6. Cubing the matrix A, save the (i, j)-entry (i, j = 1...n) of the result matrix ra to HHCubeMatrix 7. for each (i, j)-entry of (i, j = 1...n) of HHSquareMatrix and HHCubeMatrix do if (i, j)-entry of HHSquareMatrix > 0 add the (i, j)-entry in HHSquareMatrix to the matrix A else if (i, j)-entry of HHCubeMatrix > 0 add the (i, j)-entry in HHCubeMatrix to the matrix A end if VII. CONCLUSION To manage requirements change and analyze the impacted work products, establishing requirements traceability 565

6 relations is an inevitable feature during software development life-cycle. This work adopts requirements traceability reference models to define traceability relation definitions and three types of traceability links. The link derivation theorems are provided based on the proposed definitions and graph theory to establish the traceability links between system objectives/requirements/design models/subsystems/components in an automatic way. The proposed approach can be served as basis for a requirements traceability theory that can deal with the requirements traceability issues, such as degree of satisfaction, strength of dependency, and dependency link direction. ACKNOWLEDGMENT This study is conducted under the grant MOST E which is subsidized by the Ministry of Science and Technology REFERENCES [1] B. Ramesh and M. Edwards, Issues in the development of a requirements traceability model, in Proceedings of the International Conference on Requirements Engineering, Jan 1993, pp [2] O. C. Z. Gotel and A. C. W. Finkelstein, An analysis of the requirements traceability problem, in Proceedings of the International Conference on Requirements Engineering, Appril 1994, pp [3] B. Ramesh, T. Powers, C. Stubbs, and M. Edwards, Implementing requirements traceability: a case study, in Proceedings of the Second IEEE International Symposium on Requirements Engineering, March 1995, pp [4] R. Watkins and M. Neal, Why and how of requirements tracing, IEEE Software, vol. 11, no. 4, pp , Jul [5] J.-P. Corriveau, Traceability process for large oo projects, IEEE Computer, vol. 29, no. 9, pp , September [6] M. Jarke, Requirements tracing, Communications of the ACM, vol. 41, no. 12, pp , December [7] P. Arkley and S. Riddle, Overcoming the traceability benefit problem, in Proceedings of the th IEEE International Conference on Requirements Engineering (RE05), 2005, pp [8] J. Dick, Design traceability, IEEE Software, vol. 22, no. 6, pp , November/December [9] G. Spanoudakis, A. Zisman, E. Pe rez-minana, and P. Krause, Rule-based generation of requirements traceability relations, Journal of Systems and Software, vol. 72, no. 2, pp , [11] G. Antoniol, G. Canfora, G. Casazza, A. D. Lucia, and E. Merlo, Recovering traceability links between code and documentation, IEEE Transactions on Software Engineering, vol. 28, no. 10, pp , October [12] O. Gotel and A. Finkelstein, Extended requirements traceability: results of an industrial case study, in Proceedings of the 3rd IEEE International Symposium on Requirements Engineering, Jan 1993, pp [13] J. Cleland-Huang, R. Settimi, O. BenKhadra, E. Berezhanskaya, and S. Christina, Goal-centric traceability for managing non-functional requirements, in Proceedings of the International Conference on Software Engineering, May 2005, pp [14] J. Cleland-Huang, C. K. Chang, and M. Christensen., Eventbased traceability for managing evolutionary change, IEEE Transactions on Software Engineering, vol. 29, no. 9, pp , Septmember [15] B. Ramesh and M. Jarke, Toward reference models for requirements traceability, IEEE Transactions on Software Engineering, vol. 27, no. 1, pp , January [16] R. Dómges and K. Pohl, Adapting traceability environments to project-specific needs, Communications of the ACM, vol. 41, no. 12, pp , December [17] B. Ramesh, Factors influencing requirements traceability practice, Communications of the ACM, vol. 41, no. 12, pp , December [18] R. Garnier and J. Taylor, Discrete Mathematics for New Technology, 2nd edition. Taylor and Francis. [19] A. Egyed, Resolving uncertainties during trace analysis, in Proceedings of the 12th ACM SIGSOFT Symposium on Foundations of Software Engineering (FSE), 2004, pp [20] J. Cleland-Huang, Toward improved traceability of nonfunctional requirements, in Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering, Nomember 2005, pp [21] S.-H. Cho and S. D. Eppinger, A simulation-based process model for managing complex design projects, IEEE Transactions on Engineering Management, vol. 52, no. 3, pp , August [22] M. Danilovic and T. R. Browning, Managing complex product development projects with design structure matrices and domain mapping matrices, International Journal of Project Management, vol. 25, no. 3, pp , April [23] W.-T. Lee, W.-Y. Deng, J. Lee, and S.-J. Lee, Change impact analysis with a goal-driven traceability-based approach, Int. J. Intell. Syst., vol. 25, no. 8, pp , Aug [10] A. Egyed, A scenario-driven approach to trace dependency analysis, IEEE Transactions on Software Engineering, vol. 29, no. 2, pp , February