Comparison of Requirement Items based on the Requirements Change Management System of QONE

Size: px

Start display at page:

Download "Comparison of Requirement Items based on the Requirements Change Management System of QONE"

Daisy Spencer
6 years ago
Views:

1 2010 Second WRI World Congress on Software Engineering Comparison of Requirement Items based on the Requirements Change Management System of QONE Gang Lu Institute of Computing Technology Chinese Academy of Sciences Beijing, China Feng Yuan NFS-CHINA Institute of Software, Chinese Academy of Sciences Beijing, China Abstract Requirements changes are difficult to avoid in software development processes, and how to manage requirements change is still an open issue. This paper proposes an innovative algorithm, named LCS-NP++, for comparing different versions of requirement specifications to decide requirement changes. We have integrated this algorithm into a production software process management platform-- Qone, which is developed by Institute of Software Chinese Academy of Sciences. Our practices have shown it is effective and efficient in comparing requirement items. Keywords- Requirements change management, Comparison of requirement items, HTML text comparison I. INTRODUCTION According to the definition in CMMI [1], requirements change management refers to managing the changes that arise in the development process. It consists of five major steps, including (1) requirement change proposals, (2) impact analysis of changes, which is often performed by the Change Control Board, (3) decisions on if changes should be implemented, (4) confirmation of the affected modules (which is decided by the software architect), (5) code modification by developers and testers according to the requirements changes and so on. In a software process, efficient change management can minimize the adverse effect brought by requirements changes, which directly impact the success of the project. If an automated tool can perform this important work efficiently, it can save the cost, and hence improve the efficiency of requirements management to a large extent. However, how to automatically identify changed or newly added requirements among different versions of requirement specifications is still an open issue. We have built an automated tool. In this paper, we focus on the algorithm and practice of comparing different versions of requirement specifications written in HTML. After comparing and analyzing functions of state-of-the-practice and state-of-the-art automated tools, we propose a LCS- NP++ algorithm for comparing requirement specifications. The core of comparing requirement specifications is how to get the longest common subsequence out of two sequences, which is called the Longest Common Subsequence (LCS) problem. The algorithm consists of three important parts, which are solving the LCS problem, comparison of plain text and comparison of HTML text. On a basis of the algorithm proposed in [6], we have implemented the function of comparing requirement items in the specification. In near future, we will consider how to comparing tables and pictures. The rest of this paper is organized as follows. Section 2 compares several state-of-the-practice platforms with respect to features, pros and cons. For requirements specification written in HTML format, Section 3 propose sa HTML comparison algorithm based on the LCS problem, that is the LCS-NP++ algorithm. Section 4 introduces the algorithm s implementation in Qone, gives an example of the comparison of requirement items, and evaluates the performance of the algorithm. Finally, we draw a conclusion and discuss the future work. II. RELATED WORK Since requirements change management is usually integrated into requirements management tools, there are some well-known management tools, such as RequisitePro, DOORS and CaliberRM. As shown in Table 1, they have different characteristics in the functionality of comparing requirement items. RequisitePro s requirement descriptions are displayed as plain texts, which does not support editing or storing information with rich formats, like tables or pictures. And it does not have the functionality of comparing requirements in different versions. Requirement descriptions in DOORS consist of plain text, tables, graphics and other formats. DOORS conducts individual comparison for every part, which to some extent ensures the correctness of the comparison and clearly display of the differences between requirements content in different versions. However, it only supports comparing the requirement items to their previous versions. CaliberRM s requirement descriptions also have tables, pictures and other formats of information, and it supports comparing requirement items in different versions. But the comparison is so little that it just lists the requirement descriptions in sections around the page, from which users can not directly access the specific information of requirements change, particularly the subtle differences between different descriptions. Domestic developing and research work on requirements management tools are currently in the phase of rapid development. The software company NFS-CHINA has developed a software process management platform which is excellent compared with other software. Its requirement descriptions are edited and stored in HTML format. It s /10 $ IEEE DOI /WCSE

2 worth mention that its latest 5.0 version has not yet been able to support comparing requirement items of HTML format, while a large number of users expressed their desires for easily viewing comparison results of different requirement descriptions. TABLE I. COMPARISON OF SOME PLATFORMS IN THE FUNCTIONALITY OF COMPARING REQUIREMENT ITEMS Formats of basic req properties Formats of requirement descriptions Comparison of requirement items Display of comparison results Evaluation Requisite Pro Plain text Plain text Not support Not support Invisible and inconvenient DOORS Caliber RM Plain text Plain text Very rich styles with tables and pictures Rich styles, including different fonts and pictures Can be compared with former versions Can be compared with its former version Implement individual comparison and display; Comparison based on Simply list descriptions on the left and right plates of the Web page Visible and convenient; But differences inside lines are not shown Invisible; It doesn t display detailed differences III. COMPARISON OF REQUIREMENT ITEMS A. Brief introduction of the comparison Requirement items in Qone have the following basic information: the form of the basic properties, requirement descriptions, associated configuration files and the document library. The basic properties form (includes the version number, requirement names, etc.) and the associated documents are in simple format and could be easily compared, while requirement descriptions edited and saved in HTML editor are difficult to compare. Considering that the most important information is contained in requirement descriptions, the key of comparing requirement items is to compare different requirement descriptions and make the differences visually displayed on the page for users viewing and easily analyzing. Methods of comparing requirement descriptions vary in the format in which the information is stored. For example, DOORS keeps text messages, tables and pictures separately saved and compared independently. However, requirement descriptions in Qone are of HTML format, which is suitable for comparison as a whole, as is noted in the next section. B. The LCS-NP++ algorithm To compare text in HTML format, this section presents a simple HTML comparison algorithm. Figure 1 shows the flow chart of HTML comparing work based on the LCS- NP++ algorithm. It mainly includes solving the LCS problem, plain text comparison algorithm and comparison aiming of HTML texts, which are combined to solve the problems of comparing HTML format texts and showing the differences. The rest of this section consists of three parts which will respectively introduce the process. 1) Solving the LCS problem The HTML comparison in this paper is based on ordinary text comparison. The core issue of the comparison is the LCS (Longest Common Subsequence) problem [2], whose objective is to get the longest common subsequence out of all common sequences of two sequences. There are many algorithms can be applied to solve the LCS problem: HIRSCHBERG algorithm [2], NKY algorithm [3], improved NKY algorithm [4] and algorithms mentioned in [5] and [6]. This paper chooses the algorithm proposed in [6] whose time complexity is O (NP) in Figure 1. Flow chart of HTML comparing procedure comparing the plain texts. The algorithm uses the edit graph model. As is shown in Figure 2, in the process of editing one sequence a = CBABAC into another sequence b = ABCABBA, "increasing" and "deleting" a node are represented by the short horizontal and vertical lines, while nodes that do not need to be changed are represented by a short diagonal. As a result, the process of generating the lcs= CABA of sequence a and b is equal to the path form (0, 0) to (7, 6) which is made up of thick arrows in the graph, known as the "shortest edit path". In other words, LCS problem is transformed into obtaining the shortest edit path. Compared with other algorithms [5] this algorithm has a smaller searchbandwidth, which makes its time complexity O (NP) smaller

than the time complexity O (ND) of the algorithm mentioned in [5] (N stands for the larger of two sequences length, and P is the number of deletions in the shortest edit path, while D is the length

3 than the time complexity O (ND) of the algorithm mentioned in [5] (N stands for the larger of two sequences length, and P is the number of deletions in the shortest edit path, while D is the length of a shortest edit path). For more details, please refer to [6]. Figure 3. To obtain the nodes in the shortest edit path using the divide and conquer strategy Figure 2. The model of edit graph 2) Comparison of plain text The algorithm mentioned in [6] has just solved the problem of getting the fast access to the length of the LCS for two sequences. Based on this effort, a lot of auxiliary work for accurate and efficient plain text comparison is introduced in the below. a) Improve the LCS algorithm to make it access nodes in the shortest edit path besides the length of LCS. In this paper, the divide and conquer strategy is used to reduce the time complexity and make conditions for access to the nodes in the shortest edit path. As is shown in Figure 3, the search from the top left and bottom right corner of editor graph begin at the same time. When searches in the opposite directions meet with certain conditions, it can be determined that a shortest path on the edit graph is created. Notice that the path search is carried out with the increasing of the edit path s length, so at this time we can only get the length of the shortest edit path. In this paper, with the point where the searches with opposite directions meet, the original edit graph can be divided into two sub-edit graphs, which are the upper left part and the lower right part. After that, it uses the recursive manner to get shortest edit paths of the two subedit graphs, and then splices the two together in the right order, constituting the shortest edit path of the original edit graph. b) Establish comparisons in line sequence layer and character sequence layer; the former is to obtain the shortest edit path in the line edit graph, while the latter is to obtain the longest common substring of two lines. To convert comparison of the plain text to comparison of the line sequences, line sequences are established on units of line. This paper utilizes the method introduced by the Swiss efg laboratory, which is to generate CRC32 checksum for each line of strings mainly by looking up a table [8]. Tests showed that the time needed when using the look-up table to obtain CRC32 value of a string was half of that when using java.util.zip.crc32 to achieve the same goal. So it could well avoid the time overhead caused by string comparison. Moreover, the character sequence comparison within the line can obtain the specific changes of the line, which will be mentioned in the next paragraph. Compared with DOORS, this comparison of lines with edit type of modify makes the final results of the whole comparison even more detailed, from which users can more easily understand how characters in a certain line are modified. c) Identify and record the "Edit Type" ("add", "delete", "modify" and "match") between nodes according to the shortest edit path. This paper classifies nodes in the process of generating the shortest edit path and "match" type is treated as boundaries. As shown in Figure 4-a, nodes with other types may arise between nodes with "match" type where the "modify" type is given priority. The final result is somewhat different from the actual situation, because the "modify" type can be divided into "absolute changes", and "relative changes"; the former refers to that the length of LCS between two lines is small, while the latter refers to that the LCS is relatively large or the number of modified characters is relatively small. To ensure line nodes of "relative changes" type can match in the priority, the paper corrects the nodes matches of the Figure 4-a, and the eventual result is shown in Figure 4-b. In addition, the character sequence comparison will be carried out within line nodes with "modify" type. Figure 4. An example of correcting edit types

3) Comparison of HTML text On the basis of the plain text comparison, the comparison of HTML text still needs to solve the problems of extracting effective information and problems of showing results

To extract useful information from the HTML text, it is necessary to accurately judge where a logical line of text information begins and ends according to the markers of the logical line.

4 3) Comparison of HTML text On the basis of the plain text comparison, the comparison of HTML text still needs to solve the problems of extracting effective information and problems of showing results of a comparison. The following are useful methods to solve those problems. To extract useful information from the HTML text, it is necessary to accurately judge where a logical line of text information begins and ends according to the markers of the logical line. It is important to note that logical lines are usually constituted by many segments of string between the HTML tags (the strings between ">" and "<"), which is called "string segment". What has to be ensured is that characters in the logical lines must be correct in their original positions after the comparison. The LCS-NP++ algorithm records what the logical lines consist of and the offset location of each string segment which is very important to aftermost work. The main work to show the comparison results is to display lines, string segments and characters in the different highlight formats. As the specific location of string segments and characters are recorded when extracting useful information, the highlighted labels can be added around the location of string segments and characters to stress information with "delete", "add" or "modify" types. When displaying lines of "delete" and "add" type, an empty row is added in the appropriate place to ensure the displayed lines maintain alignment with user-friendly view. After accomplishing the procedures above, a complete comparison of HTML formatted text can be established based on plain text comparison. In the next section, an example will be given. C. An example Based on the foregoing LCS-NP++ algorithm, the contrast functionality of the requirement items in the software process management platform Qone has been implemented. Figure 5 shows an example of requirement items comparison. In the figure, characters with different edit types are highlighted in different formats: "add" and "delete" types shown in red font and underlined, "modify" type displayed with a yellow background color and underlined, and the "match" type shown in accordance with the original format. Figure 5. An example of comparing requirement items in Chinese version Qone Figure 5 directly shows the subtle differences between the requirement items in different versions and the two plates are almost aligned, which is convenient for users analyzing. However, in order to avoid the errors that may occur in such comparisons, there are other two methods actually provided for comparison in Qone to show multiple results for users. They are comparison based on the string segments and comparison of plain text. The former mainly reserved the

5 original HTML format and it will not add any additional spaces or blank lines, while the latter completely ignores the HTML format and only shows a plain text with some necessary highlights. It is worth mention that this implementation of HTML text comparison is not completely applicable to very complex HTML text. It mainly focuses on the common HTML text generated by HTML text editors (for example, the HTML editor for requirement descriptions in Qone), but the comparison of HTML text with JavaScript or other unusual script tags is not always good enough. IV. CONCLUSION Requirements change management system provides an efficient management platform for the frequent changes occurs in the project. The result of comparison of requirement items can visually display detailed differences of requirements change, which is convenient for users to judge the impacts timely and accurately. This paper implements the comparison of requirement items on the basis of requirements change management of Qone, especially the comparison of HTML format requirement descriptions, which meets the need of users on the comparison results. However, the comparison of requirement descriptions in this paper still cannot support the comparison of some complex information like tables and images. Future research will focus on detailed comparison of tables and images to establish a more functional and powerful requirements change management system. ACKNOWLEDGMENT The author would like to thank Dr. Jianfeng Zhan and Chenxin Jiang for their help and support in making this work possible. REFERENCES [1] CMMI Product Team, CMMI for Development Version 1.2, CMU/SEI-2006-TR-008, August [2] D.S.Hirschberg and L.L.Larmor, The Set-Set LCS Problem, Alogrithmica, 1989, vol. 4, pp , doi: /BF [3] Nakatsu, Narao & Kambayashi, Yahiko & Yajima, Shuzo, A Longest Common Subsequence Suitable for Similar Text Strings, Acta Informatica, 1982, vol. 18, pp , doi: /BF [4] Lasse Bergroth, Harri Hakonen and Juri Väisänen, New Refinement Techniques for Longest Common Subsequence Algorithms, Lecture Notes in Computer Science, 2003, vol. 2857/2003, pp , doi: / _22. [5] E.W.Myers, An O(ND) difference algorithm and its variations, Algorithmica, 1986, vol. 1, pp , doi: /BF [6] Wu, Sun & Manber, Udi & Myers, Gene & Miller, Webb, An O(NP) Sequence Comparison Algorithm, Information Processing Letter, 1990, vol. 35, issue. 6, pp [7] Qin Zhong-sen and Li Juan, Process of requirements change management and analysis of requirements management tools, Computer Engineering and Design, November [8] Efg s Computer Lab, Cyclic Redundancy Code Filecheck, URL: [accessed September 17, 2010]. [9] Qone,

Using Microsoft Word. Working With Objects

Using Microsoft Word. Working With Objects Using Microsoft Word Many Word documents will require elements that were created in programs other than Word, such as the picture to the right. Nontext elements in a document are referred to as Objects