Evaluation of RE Tools Suitability for Continuous Requirements Engineering Anita Finke Riga Technical University, Latvia, Riga anita.finke@rtu.lv Abstract. Requirements engineering process usually is supported by certain tools. The choice of the tools may depend on several organizational and personal factors and can result in a large set of tools and the necessity to move require- ments engineering artifacts from one tool to others continuously. In this paper the hypothesis that it is preferable to limit the number of the tools in use is discussed. The discussion is based on the Requirements Engineering Artifact Distribution method that has been developed for requirements engineering in multi project environment. Keywords: Continuous Requirements Engineering, Requirements Engineering tools, Evaluation of RE tools 1 Introduction Requirements Engineering (RE) consists of different elements, tasks, phases, and meth- ods. We can look at RE from different perspectives such as requirements analysis, de- sign, realization, and management. There are many different methods that can guide processing of specific tasks in requirements engineering. So, the requirements engi- neering process is composed of many different components. This versatility of compo- nents requires a systemic approach to identify which combination of possible compo- nents can provide the highest value of RE in achieving Enterprise or project goals. Also, it refers to RE continuity – more appropriate combination with respect of requirements use in future and requirements management, more likely Continuous RE will be pro- vided. When performing RE activities, in many cases, we usually use more than one tool in a single RE task [1], e.g. we may use e-mail, chats, Skype and even some special tools for communication. For instance, the author of the paper herself uses 4 tools for communication. All those tools capture the history of conversation. This means that the documented decisions, questions, answers and corrections are stored in 4 places. And, as a result, document collection and change management process is complex. It takes time and causes loss of some information and problems to find necessary artifacts in future. Copyright 2018 for this paper by its authors. Copying permitted for private and academic purposes. 2 In this paper the term “RE artifact” will be used to denote explicit and tacit knowledge and requirements used in requirements engineering that can be created, transferred via or stored in tools. The goal is to focus on complex sets of RE activities what needs to be performed in RE tool to support CRE. The paper proposes a hypothesis that in continuous requirements engineering the number of tools in use should be limited; and investigates the theoretical issues related to this hypothesis. Additionally, a survey on tool usage to collect data from professionals all over the world is under the development. The first version of the survey has already been re- leased, and data collection is started. The discussion on the tool usage will be based on the RE artifacts management and distribution method, which will be noted as READ (Requirements Engineering Arti- facts Distribution) method in the remainder of the paper. This paper consists of 4 sections: 1 – introduction, 2 – related work, 3 – RE artifacts distribution approach in Continuous Requirements Engineering, and 4 – conclusions. 2 Related work Tool usage in continuous requirements engineering is rarely discussed in RE literature. For instance, [5] is a bi-yearly research called NaPiReE with a goal to identify the prob- lems in RE. The questions used in surveys are closed questions and include answers like “Requirements remain too abstract”, “Changing business needs”, “Missing direct communication to customer” etc. But there are no questions and answers related to used tools and the effectiveness of them. Also, there are no clues about the problems in tool usage. However, this research shows other very important problems and tendencies in RE that can be applied in research on RE tools. Sarah Thew and Alistair Sutcliffe [6] describe a method for RE evaluation that is focused on stakeholder’s values, motivations and emotions. It is based on the social aspect rather than the practical tool aspects. This research illustrates RE problem situa- tions from a specific perspective related to communication or social, or psychological factors. These perspectives are very important in the context of RE and can also help in in research on RE tools. The author of this paper focuses on tool perspective and evaluation of RE tools sus- tainability for continuity in RE. In this regard, the preliminary research has been done and is reflected in [2, 3, 4]. The research papers contain the first ideas and models rel- evant for analysis of tool usage in continuous requirements engineering and consider requirements management specifics in continuous requirements engineering. 3 Requirements Engineering artifacts distribution approach To discuss the usage of tools in requirements engineering, it is essential to have a par- ticular insight on how different artifacts of requirements engineering can be distributed among the employees and tools involved in RE. Therefore, first, the method of artifact 3 distribution is discussed, and only then the approach for evaluation of tool suitability is proposed. The goal of this method is to provide guideline to evaluate RE tools suitability for Continuous Requirements Engineering in other words – how to evaluate the practical RE process to identify the tools who is used for the same RE activity and to provide guideline for tools evaluation with a goal to specialist to detect the tool which supports CRE (Continuous Requirements Engineering). 3.1 Requirements Engineering artifact distribution method In previous papers [2, 3, 4] the author describes the idea of the READ method. In this paper the READ method will be described from tree perspectives: the content (concep- tual architecture of this method) and the provisional results of the use of the method. In Figure 1 we can see a graphic representation of sequential blocks of requirements engineering artifact maintenance and distribution method that comply with the READ. Below the description of the method is provided. • Sequential Block 1 • Activity 1. The first activity is the preparation of the artifact management tool – we need to choose a tool that will provide all possibilities to store and share artifacts and manage them during the project and during the information technol- ogy solution life cycle. The issues what we need to consider are described in au- thors papers before [2, 3, 4]. Fig.1. Sequential blocks of artifact maintenance and distribution method • Sequential Block 2. The next 4 activities are represented in the circle that can in- volve several iterations. Activity 3 (Artifact communication) appears twice in the cycle to emphasize that the changes in the artifacts must be communicated. • Activity 2. Documentation of artifacts – it is a necessary condition for completion of further activities and providing necessary availability of the artifacts. • Activity 3. Communicate artifacts – requirements communication is a mandatory activity. It allows ensuring whether the artifacts are documented correctly and 4 facilitates getting necessary approvals. It also helps to provide documented infor- mation about projects progress and to keep track of artifacts. There are two basic types of artifact communication: communication via tool(s) and communication via socialization. o Communication via tool(s). The possibility to use one tool for artifact storage and communication can minimize necessary time for artifact management in several tools. Therefore, having just one tool is preferable. o Communication via socialization. Communication via socialization does not exclude tool usage. • Activity 4. Manage changes and document them – during the project and during the information technology solution life cycle, there will be changes in artifacts and there will also be new artifacts. It is very important to manage them and to document them. It allows us to provide actual information during all phases. • Activity 5. All results must be stored in the tool and shared, i.e. all artifacts must be available to all stakeholders according to their access rights. • Sequential Block 3 • Activity 6. The last activity is old artifact archiving – during the project end phase or when the information technology solution is retired, it is necessary to decide where to store the “old” artifacts. At the current stage of development, the method is complete to the extent that it can be applied in information technology projects. 3.2 Approach for evaluation of RE tool suitability for Continuous Requirements Engineering in RE practice The approach suitable for RE practice must be designed for two purposes. The READ method is designed based of practical example, but it is still theoretical; it means that this method needs to be tested on its applicability for supporting tool evaluation. The second purpose is to evaluate the practical (not theoretical) situation in RE. The READ method is partly implemented in the author’s work company. The com- pany has chosen a tool Jira and has created automated information (issues) synchroni- zation to other Jira instance (developer’s tool). This provides accessibility to all stake- holders, many functional possibilities for users and artifacts management. But there still are shortcomings – the process and practice require improvement. There are cases when analysts use more than one tool (e.g. Lotus Notes) and are dealing with artifacts management in all tools. This means that the method is imple- mented partly. In order to understand what tools or tasks are redundant, we need to analyze the current situation. A checklist is chosen as the first version of this approach (READ evaluation approach) format – to evaluate the tasks, used tools and needed ef- forts to manage RE artifact in mentioned tools. In this paper, the author will describe in detail only the first part of the checklist and its use in practice (see Fig. 4). The checklist contains of 4 parts. The first part of the checklist contains the follow- ing steps: 5 • identifying tasks which are the most important but not the only tasks in daily work; • identifying the number of used tools for each task; • listing the identified tools; • evaluating the effort needed to complete a single activity – in this example, finding information in said tools. Fig. 2. Example of filled first part of the checklist The author of the paper tested these steps on in daily practice and received the results shown in Fig. 4. Moments when the number of used tools exceed 2 is shown in red. Number 2 is chosen because the work procedure strictly asks to use a system when, according to IT project management, the analysts briefly document the most important activities in Lotus Notes Project management module and JIRA. As we see, during RE artifacts documentation, for communication and protocol cre- ation we use 3 and even 4 tools. These moments are chosen to evaluate the necessary time effort to find the documented information in said tools. According to collected results, further analysis will be performed to identify the pos- sibilities of improvements: for instance, the company might decide to exclude the use of some tools. The second part of the checklist contains the following steps: • evaluating the tool compliance to the READ method (see Fig.1); • naming the tool’s provided functionality; • checking the existence of recommended functionalities; • evaluating the usage frequency of available functionality. The third part of the checklist contains the following steps: • evaluating the artifacts management according to the READ management method (see Figure 2); • including the random artifacts selection; • evaluation according to the READ method and identified tool functionality. The fourth part of the checklist contains the following steps: 6 • analysis of documented findings and results; • recommendation provision according to the READ method. Described checklist is developed partly and will be elaborated on the basis of the toll usage survey results. The survey will be performed in several stages – the first one of which is already released. The survey will help to collect data on statistics of number of tools used in specific tasks. 4 Conclusion This paper discusses RE artifacts distribution and management from technical support perspective taking into account continuity of RE processes. The author proposes an approach of evaluating the existing technical support (tool usage) of RE processes ac- cording to the requirements engineering artifact distribution method. The proposed ap- proach is intended to be implemented as an electronic checklist. The results of the first survey and discussions with professionals from different countries show that there are tendencies of multi tool usage. The proof of these tenden- cies will be collected in surveys and analyzed in further researches. Based on existing information and developed hypothesis, a full concept of the checklist will be developed for practical evaluation as well as the models will be created in order to implement this checklist in existing tools or implement a separate software for tool usage evaluation in continuous requirements engineering. References 1. International Institute of Business Analysis, “A Guide to the Business Analysis Body of Knowledge v3” (2015) 2. A. Finke: Requirements Inheritance in Continuous Requirements Engineering: a Position Paper”. In: CRE’17 (2016) 3. A. Finke: Socialization aspect in Requirements Engineering. REFSQ 2017 Joint Proceed- ings of the Co-Located Events (2017) 4. A. Finke: Continuous Requirements Engineering Support Environment Model in Methodo- logically Heterogeneous Projects. In: BIS 2017 International Workshops Poznan, Poland, Business Information Systems Workshops Revised Papers, Springer, pp. 207 – 216 (2017) 5. D. Mendez Fernandez, S. Wagner, M. Kalinowski, M. Felderer, P. Mafra, A. Vetr`o , T. Conte, M.-T. Christiansson, D. Greer, C. Lassenius, T. Mannisto, M. Nayebi, M. Oivo, B. Penzenstadler, D. Pfahl, R. Prikladnicki , G. Ruhe, A. Schekelmann, S. Sen, R. Spinola, A. Tuzcu, J. L. de la Vara, R. Wieringa: Naming the Pain in Requirements Engineering Contemporary Problems, Causes, and Effects in Practice, In: Empirical Software Engineer- ing Journal, Volume 22, Issue 5, pp 2298–2338 (2017) 6. S. Thew, A. Sutcliffe: Value-based requirements engineering: method and experience. In: Requirements Engineering Journal, Volume 22, Springer London, pp. 1-22 (2017)