Improving the Requirements Process by Visualizing End-User Documents as Tag Clouds

Transcription

1 Improving the Requirements Process by Visualizing End-User Documents as Tag Clouds Felienne Hermans Delft Martin Pinzger Delft Arie van Deursen Delft ABSTRACT The process of requirements gathering has been a muchdiscussed subject in computer science for years. It seems difficult to incorporate end-users in this process. Although there have been numerous papers devoted to this subject, it remains unsolved. We propose to ease this process by describing tools and methods to extract information from end-user documents, bringing their knowledge into the requirements and design phase of software systems. We do so by analyzing two different types of end-user documents: spreadsheets and text documents. Furthermore we introduce a novel way of representing the extracted domain information, in structured tag cloud diagrams. We present results of the extraction processes and describe avenues for future research. Categories and Subject Descriptors D.2.1 [Software]: Software Engineering Requirements and Specifications; H.3.3 [Information Systems]: Information Storage and Retrieval Information Search and Retrieval General Terms Design, Experimentation, Human Factors, Languages, Verification Keywords Content Summarization, Natural Language Processing, Tag Cloud, Tagging, Text Mining, Visualization 1. INTRODUCTION Requirements analysis is an important phase of a software project. In this phase a software project is described in terms of objects, actions and relationships between them. These domain concepts are usually revealed and classified by conducting stakeholders interviews and creating use cases and scenarios [7]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Flexitools 2010 Cape Town Copyright 200X ACM X-XXXXX-XX-X/XX/XX...$ Because end-user documents render a significant part of the knowledge base stored on local desktops [17], documents describing these domain concepts are probably available in some digital form. Most likely there exist text documents, presentations and s describing the context of the domain and spreadsheets used for some of the tasks the new software system is going to perform. All these end-user documents can be used to aid the software engineer in understanding the domain. The use of existing user documents as inspiration for domain information however is not common practice in requirements engineering. It is often very difficult to localize the end-user documents, which may be scattered over many different desktops and servers. In most companies there exist documents in different types and formats, complicating analysis by humans even more. Besides that, software engineers consider end-user documents to be imprecise and believe that they cannot contribute much to the requirements phase. End-users on the other hand usually have problems understanding the assets that are created by software engineers. Requirements documents or use case descriptions for instance, are lengthy and use formal language. Class or sequence diagrams are difficult to understand for users with no background in computer science. In our opinion there is currently a lack of methods and tools adhering to the wishes and needs of both end-users and software engineers. It is important that these two groups of people are able to understand each other, as communication problems between users and developers contribute greatly to all problems in requirements engineering [9]. We conjecture the increased involvement of end-user documents in the requirements process can aid in bringing endusers and software engineers closer together, thus improving the quality of the requirements and the resulting software. Therefore we propose the technique of reverse modeling. Reverse modeling is defined as the automated transformation of existing user documents to models, more information can be found in [12]. Reverse modeling attempts to bridge the gap between end-users and software engineers by translating documents from the language of users, spreadsheets and natural language, to the language of software engineers, for instance class diagrams and requirements documents. The current approach consists of three steps. First a preliminary class diagram is extracted from existing spreadsheets using pattern matching techniques. Secondly a topic model is generated from text documents by using known algorithms from the field of information retrieval. The topic model is represented as a tag cloud. The class diagram and the topic model are combined to create a complete view of

2 the domain. When working on this combination of both diagrams we found that there did not exists a perfect diagram combining the structure of a class diagram and the flexibility of a tag cloud. Hence we decided to introduce a new way of visualizing domain information, being a tag cloud diagram. A tag cloud diagram consists of one of more tag clouds that are connected by relations. These relations are not formal multiplicity or inheritance relations as in a class diagram, but represent any kind of relation between two tag clouds. This combined model unites the structure of a class diagram with the understandability of a tag cloud. 2. MOTIVATION Requirements engineering is a notoriously hard problem within the computer science discipline, as has been described in numerous books and papers since the seventies [4, 6, 19]. More recently Knauss and el Boustani [13] provided empirical evidence that the quality of requirements is strongly correlated to the quality and success of the end product, stressing the importance of requirements engineering. Hall et al. [9] show almost 50% of the problems occurring in software development stem from requirements. Of these problems, almost half is related to poor initial requirements capture and requirements growth during the development process. These numbers indicate huge improvements could be made by focussing on gathering better and more requirements at the start of the requirements phase. Hall et al. furthermore assess developer communication as one of the main reasons for the requirement problems. In general developers tend to view the end product in technical terms, like classes and entities, where users described their domain in terms of users and functionality of the endproduct. Although numerous approaches to bridge this gap have been tried, both in practice and academia, the problem remains difficult to solve. 3. APPROACH As mentioned in the introduction we consider end-user documents as an unexplored source of domain information. Because there are many types of end-user documents we choose to divide them into two categories that will be treated differently. On the one hand there are spreadsheets, having a clear structure, containing calculations and data where on the other hand there are free form text documents providing background information on for instance stakeholders, objects and relations between them. Because of the different characteristics of these documentation types, we extract information from each type in a different fashion. Extracting information from spreadsheets is done by exploiting use of the structured way in which information is represented, as explained in Section 3.1 and in more detail in [12]. The output of this extraction algorithm is a UML class diagram [3]. Text documents usually lack the structure that spreadsheets have, therefore they require a different type of analysis. We propose to apply topic finding algorithms to these documents to group domain concepts in topics. More information on topics can be found in Section 3.2. Figure 1: A common spreadsheet pattern Figure 2: The class diagram representing the spreadsheet in Figure 1 To combine the results of both analyzes, we use the tag cloud diagram, a combination of a class diagram and a tag cloud that will be presented in Section 3.3. We believe this representation is the golden mean between the technical class diagram and the easy-to-understand tag cloud. 3.1 Analyzing spreadsheets When investigating spreadsheets used within companies we noticed there exists a small set of patterns that occur within spreadsheets frequently, across different business domains. Figure 1 shows one of these patterns, [12] presents a bigger set. Each of these spreadsheet patterns can be mapped to a basic class diagram. The spreadsheet in Figure 1 for instance maps to the class diagram in Figure 2. By looking for these patterns in spreadsheets, they can be transformed into class diagrams. Hermans et al [12] presents a case study showing some promising results of this transformation. This paper describes an experiment where 50 extracted class diagrams are compared to class diagrams created by software engineers. In the majority of the cases (33) the extracted diagrams correlate perfectly (20) or good (13) with the hand-created class diagrams. 3.2 Analyzing free-text documents While the class diagrams extracted from spreadsheets provide a good overview of the domain at hand, the lack contextual information. They for instance do not show how the extracted classes are related to other objects in the domain. To overcome this deficiency we enrich these class diagrams with domain information gathered from text documents by applying Latent Dirichlet Allocation. Latent Dirichet Allocation(LDA) [5] is an algorithm that analyzes text documents and represents them in topics. A

3 Figure 3: A cloud diagram for the fruit domain topic is a group of words that frequently occur together. We assume such a topic as a whole represents a domain concept, and the words in topic are objects related to that concept. Research where LDA was applied to source code shows this algorithm is able to reveal domain concepts very well [15]. The current approach is as follows, we apply LDA on all documents concerning the project, resulting in a set of topics. These topic will be represented as tag clouds, a way of visualizing a group of words where more important words are depicted in a larger fonts size than less important words, see further [14]. The measure of importance is usually the frequency with which words occur, other measures however are also possible, e.g. the degree of relatedness to other words in the topic. Of the extracted topics our main interest lies with the topics containing words that coincide with names of classes in the class diagram extracted from the spreadsheet. 3.3 Results combined: the tag cloud diagram The two extraction processes described above result in two diagrams, a class diagram extracted from the spreadsheets and a group of tag clouds stemming from the text documents. Those two diagrams are combined into one by finding words occurring both in a class diagram and in a tag cloud. For those words, their corresponding class in the class diagram is replaced by the containing tag cloud as shown in Figure 3. Classes without a corresponding tag cloud are removed from the diagram. We call the resulting diagram a tag cloud diagram. 4. PRELIMINARY RESULTS Our first paper concerning spreadsheet analysis [12] contained a case study investigating the quality of the extracted class diagrams. We randomly selected 50 spreadsheets from the Euses Spreadsheet corpus [8]. For those spreadsheet we compared hand crafted class diagrams to class diagrams generated by Gyro, our extraction tool. Out of the 50 generated class diagrams, 20 coincided exactly with the hand created class diagrams, and 13 contained minor flaws. These re- Figure 4: The process of splitting a tag cloud diagram. Selecting an entity, dragging it out of its current tag cloud, and the regeneration of both tag clouds sults show that is it indeed possible to extracted meaningful information from spreadsheets. 5. THE NEXT STEP: TAG CLOUD DIAGRAM INTERACTION Although reverse modeling is a great start in revealing domain concepts, the benefits can be even larger if users can interact with the generated tag cloud diagrams. We propose to create an editor that allows the user to visually manipulate the tag cloud diagrams. Simple editing operations like renaming the topics, rearranging them, adding, moving, merging and removing words could already improve the user experience in working with the tag cloud diagrams. In our believe, even better results can be improved by adding the possibility to split tag clouds. The generated tag clouds can be quite large and in fact represent more than one domain object. In that case user should be allowed to split the tag clouds into smaller ones. We imagine the process of splitting the tag clouds in the following three steps, as depicted in Figure 4. In the first step, the user selects a word from the tag cloud that represents an entity that should have its own tag cloud. In Figure 4, this is indicated by the word Flower, depicted in

4 red. In step two the user drags this word out of the tag cloud. Finally, we generate two new tags clouds, by rerunning the LDA algorithm over the gathered text documents. The words that correlate to the selected word the most are moved to the new tag cloud, words less related to the selected word remain in their original tag cloud. It is still a challenge to determine how the tag cloud interaction should be implemented exactly. Figure 5: case Generated tag cloud diagram for Clnts 6. EVALUATION PLANS Some of the ideas presented in this paper have not been evaluated thoroughly enough to make any claims on the applicability in practice. More research is needed to determine whether the use of tag cloud diagrams can really improve the requirements analysis process. We suggest empirical studies answering the following research questions, 1) Is it possible to generate meaningful tag cloud diagrams from existing end-user documents? 2) What is the best start size for a tag cloud? 3) What measure should be used for the size of the words? 4) Are both software engineers and end-users able to understand tag cloud diagrams? 5) Is is possible to split tag clouds and present the results to the user quick enough to provide a good user experience? 7. RELATED WORK The idea to apply natural language processing to improve the requirements gathering phase has been addressed before. Overmyer et al. [18] created a tool called LIDA that assists developers in creating UML models by performing linguistic analysis on user documents. In this analysis LIDA selects candidate words for this UML model by part-of-speech tagging, the division of words into categories such as nouns, verbs or adjectives. The user itself has to mark the right words and link them to corresponding model elements. More recent approaches mainly focus on analyzing requirements like as Sharma et al [20] and Hasegawa et al. [10]. Both papers describe techniques to generate a structured overview of a domain by analyzing only requirements documentation, and both propose to exploit the structure of requirements documents, although both in a different fashion. [20] restricts requirements documents to a given format, whereas [10] focuses on specific words, such as requires or contradicts. Since their introduction on the photo site flicker [1], tag clouds, sometimes also called word clouds or data clouds attracted the attention of many. Initially used to present popular categories on a single web site, they are now used broadly to analyze all kinds of text documents, ranging for PhD theses to presidential speeches [2]. According to Hassan-Montero and Herrero-Solana [11], a tag cloud is a visual list of words arranges to transmit information and meaning through the use of different font sizes, styles and colors. The more important a word is, the larger the font size is and therefore it is more prominently present in the tag cloud. As such tag clouds provide a visual summary, or semantic view of the concepts most important to represent an object. Tag clouds have appeared in several papers, in particular the empirically evaluation of the use of tag clouds. Lohmann et al. [16] present a very complete study of several different types of tag clouds by tracking the eye movement of participants. There results surprisingly shows that although the participants are not able to perform their assigned tasks better or quicker by using tag clouds, they do prefer them over other forms of visualization. Feedback of the participants indicated that fun and aesthetic aspects contributed largely to that decision. Kuo et al [14] compared two search interfaces of the same information system, one using a cloud representation and one with an ordinary list representation and report on similar findings. Although participants spent more time and found the cloud interface less helpful, the users ranked the cloud interface with higher level of satisfaction. These results indicate users tag clouds are attractive to end-users and give credibility to the claim that tag clouds cloud aid in involving end-users in the requirements phase. 8. CONCLUDING REMARKS In this paper we stated end-user documents provide a good source of domain information, hence starting point for the gathering of requirements. We explained methods to extract information from two different types of end-user documents, spreadsheets and text documents and presented preliminary results of the extraction process. Furthermore we introduced a novel way of representing domain information, namely in structured tag cloud diagrams. A typical scenario using the proposed methods and tools is the following. A software engineer is asked by the company Clnts to create a software system for their client and order registration system. By using our methods he generates the tag cloud diagram in Figure 5. By showing this diagram to the domain experts, he discovers client-number and ID are in fact synonyms and merges them. Furthermore he drags orderlist out of the client-cloud, because according to the users it is a separate entity. Further investigation into the amount word in the order-cloud shows this is the amount of orders per client, so it should go with orderlist. The edited tag cloud diagram, as shown in Figure 6 is a good start for modeling the domain in a more formal way and will help the software engineer in understanding the domain because using our methods he can benefit optimally from existing knowledge. We imagine the class diagram the engineer will create for this software system, probably similar to the one shown in Figure 7, will resemble the modified tag cloud diagram. Although much more empirical evidence of the application of both the extraction technique and the visualization methods is needed, we are confident both will improve the requirements process, by bridging the gap between the languages of software engineers and end-users and ultimately by creating a language well understood by both. 9. REFERENCES [1] Flickr. [2] Preztags; US Presidential Speeches Tag Clouds.

5 Figure 6: Modified tag cloud diagram for Clnts case Figure 7: Class diagram for the Clnts case results. In WWW, pages , [15] Erik Linstead, Cristina Videira Lopes, and Pierre Baldi. An application of latent dirichlet allocation to analyzing software evolution. In ICMLA, pages , [16] S. Lohmann, J. Ziegler, and L. Tetzlaff. Comparison of tag cloud layouts: Task-related performance and visual exploration. In INTERACT (1), pages , [17] S. Nesic, D. Gasevic, and M. Jazayeri. Extending ms office for sharing document content units over the semantic web. In ICWE, pages , [18] S. Overmyer, B. Lavoie, and O. Rambow. Conceptual modeling through linguistic analysis using lida. In ICSE, pages , [19] G. Roman. A taxonomy of current issues in requirements engineering. IEEE Computer, 18(4):14 23, [20] V. Saujanya Sharma, S. Sarkar, K. Verma, A. Panayappan, and A. Kass. Extracting high-level functional design from software requirements. Asia-Pacific Software Engineering Conference, 0:35 42, [3] UML 2.2 specification. [4] T. Bell and T. Thayer. Software requirements: Are they really a problem? In ICSE, pages 61 68, [5] D. Blei, A. Ng, and M. Jordan. Latent dirichlet allocation. In NIPS, pages , [6] B. Boehm. Verifying and validating software requirements and design specifications. IEEE Software, 1(1):75 88, [7] C.Neill and P. Laplante. Requirements engineering: The state of the practice. IEEE Software, 20(6):40 45, [8] M. Fisher and G. Rothermel. The EUSES spreadsheet corpus: A shared resource for supporting experimentation with spreadsheet dependability mechanisms. In In 1st Workshop on End-User Software Engineering, pages 47 51, [9] T. Hall, S. Beecham, and A. Rainer. Requirements problems in twelve software companies: an empirical analysis. IEE Proceedings - Software, 149(5): , [10] R. Hasegawa, M. Kitamura, H. Kaiya, and M. Saeki. Extracting conceptual graphs from japanese documents for software requirements modeling. In APCCM, pages 87 96, [11] Y. Hassan-Montero and V. Herrero-Solana. Improving Tag-Clouds as Visual Information Retrieval Interfaces. In Proceedings of Multidisciplinary Information Sciences and Technologies, InSciT2006, Merida, Spain, [12] F. Hermans, M. Pinzger, and A. van Deursen. Extracting class diagrams from spreadsheets. Submitted, [13] E. Knauss and C. El Boustani. Assessing the quality of software requirements specifications. In International Requirements Engineering, RE th IEEE, pages , Sept [14] B. Yu-Lin Kuo, T. Hentrich, B. Good, and M. Wilkinson. Tag clouds for summarizing web search