Requirements Intelligence Clause Samples

Requirements Intelligence. This component will encapsulate an analytics backend and include text-mining algorithms that allow the analysis of natural language in text-based documents or user feedback (user feedback can be either explicit or implicit - see Figure 2). In addition to that also interactive visualization will be supported by this component. In particular, interactive visualization supports stakeholders in visualizing descriptive and predictive analytics data. An example of such a visualization is shown in Figure 3. Figure presents the trend of different app review types (e.g., a user requests a new feature or a bug to be fixed) over time, for a specific app and over its different versions. Figure 2: Example for explicit and implicit feedback Figure 3: Example trend of different app review types

Requirements Intelligence role in the architecture Figure 1: OpenReq overall architecture. The OpenReq Prototype and the industry trials exploit the basic functionalities provided by the OpenReq services. Furthermore, services themselves exploit and integrate the services of other components. For example, release planning uses functionalities of dependency detection, recommendation, and group decision making (for simplicity, this is not considered in the architecture figure). In the following, we give a short overview on the different services, knowledge infrastructure, and interfaces shown in Figure 1 (for more details we refer to the DoA).

Requirements Intelligence. In OpenReq, we define requirements intelligence (RI) similar to business intelligence (BI). For BI, we use the definition of [▇▇▇▇▇▇ 2004]: “BI systems combine data gathering, data storage, and knowledge management with analytical tools to present complex internal and competitive information to planners and decision makers.” RI follows the same definition but focuses on requirements of software products. RI is the systematic collection, analysis, processing, and visualization of requirements and user feedback coming from natural text such as issue trackers, app reviews, or legacy requirements. The goal of RI is to provide new insights about software products based on diverse data sources of natural language and metadata. In order to describe the state of the art, we separate RI into the topics mining, classification, clustering, and visualization of requirements (a deeper literature analysis can be found in D2. 1). With text mining, we are able to retrieve requirements or related information to those in natural text. A survey by ▇▇▇▇ et al. [2004] found that 79% of companies use unstructured natural language in their requirements documents; 16% use structured natural language (e.g., using templates); 5% use formal approaches. Therefore, the application of natural language processing (NLP) to requirements engineering has attracted a lot of attention from software engineering researchers and practitioners [▇▇▇▇▇ 1995]. Already in the late 1990s, NASA built a tool that leverages NLP for requirement engineering (Automated Requirements Measurement, or ARM) [▇▇▇▇▇▇▇ and ▇▇▇▇▇▇▇▇ 2014]. In the area of software engineering, several approaches have been developed in the recent years with many focusing on app stores as shown in [Harman et al. 2012], [▇▇▇▇▇▇ et al. 2017], [▇▇▇▇▇▇ and ▇▇▇▇▇▇ 2013]. An interesting source of information can be found in user reviews, comments, and social media in general, as people use these platforms to describe their desires and issues online [▇▇▇▇▇▇ and ▇▇▇▇▇▇ 2014], [▇▇▇▇▇▇▇▇ and ▇▇▇▇▇▇▇ 2017], [▇▇▇▇▇▇ et al. 2017]. The next step is the classification of requirements, which deals, among others, with the classification of requirements into functional (FR) and non-functional (NFR) as shown by the authors [▇▇▇▇▇▇▇▇ et al. 2016], [▇▇▇▇▇▇▇▇▇▇▇ and ▇▇▇▇▇▇ 1997], and [▇▇▇▇▇▇▇▇▇▇ and ▇▇▇▇▇▇ 2017]. In addition, RI will take advantage of the research done in the identification of bug reports, feature requests, and non-informative text in user ...