One of the most critical branches in software engineering is Requirements Engineering (RE) [1]. There are many different problems related to this area, one of them being requirements traceability (RT). This is known as the "ability to describe and follow the life of a requirement, in both forwards and backwards direction" [2]. Traceability allows to identify dependencies between these relations, and how changes in the requirements may affect others that are related to them. Identifying dependencies between requirements, usually specified in Natural Language (NL) is considered a difficult, expensive and long process [3] [4].
In order to provide an automated solution for the dependency detection step, we introduce OpenReq-DD, a requirements Dependency-Detection tool addressed to apply NL and Machine Learning (ML) techniques to analyze requirements and extract dependencies between them. This tool has been developed inside OpenReq [5], an EU Horizon 2020 project that aims to provide advanced innovative tools for community-driven RE.
In this context we present a use case based on data provided by Siemens (Austria), one of the industrial partners of OpenReq. This data is a set of several documents called Request for Proposals (RFP) in the railway systems domain, which comprise NL requirements and can be several hundred pages long. Furthermore, stakeholders do not keep track of current dependencies. Therefore, it would be a large task to extract these dependencies in a manual way. For a better comprehension of the tool action, an example of these requirements is used for the description of the steps carried out by the tool.
OpenReq-DD architecture is composed by a RESTful service as the main component, which exposes an API to provide the required data and perform the dependency detection algorithm. This is intended to match a microservice architecture and define an isolated, decoupled component that can be used in different contexts. This component exports and integrates as internal dependencies all required toolkits and frameworks for the different algorithm steps (see Fig. 1). For demonstrations, a simple GUI is provided (see Sec. 3). The OpenReq-DD project is available at GitHub (https://github.com/OpenReqEU/dependency-detection), including a README file with all required information to deploy and run the tool.
Figure 1 shows the sequence of steps that OpenReq-DD performs to extract requirement dependencies. In the following, we describe the needed input data (Sec. 2.1), and a a brief description of each stage (Sec. 2.2). The dependency detection algorithm designed and developed in OpenReq-DD requires two types of data to perform the dependency extraction. The format of this data has been defined and discussed with the stakeholders of the OpenReq project.
• Requirements list. A list of requirements from which to extract dependencies is provided. The JSON Schema used for input and output response is available at https://goo.gl/Gx8vpJ
• Ontology. The ontology provides the tool the required knowledge about the general patterns and dependency types that are potential dependencies between requirements. This is the result of an study performed by stakeholders of the project. The ontology knowledge is structured in a dependency relations tree, where each node is a topic and each edge a dependency relation type (see Fig. 2). An example of this ontology is available at https://goo.gl/Hx6GS2
The output of the RESTful service is a JSON response using the same format that the input data, but with the set of detected dependencies included.
In order to reduce deficiencies in the data set, two preprocessing methods are applied to the requirements.
• Sentence Boundary Disambiguation (SBD). Sentence detection is applied to extract isolated sentences from each requirement, by deciding where are the beginning and the end of each sentence. The Apache toolkit OpenNLP [6] is used for this purpose.
• Noisy Text Cleaning. After SBD, a total of 14 rules are applied to clean the text of each sentence. The cleaning includes, between others: removal of character, numeric and roman numerals list pointers; removal of acronyms that may appear at the beginning of a requirement; removal of escape sequence characters; addition of white spaces to prevent PoS tagger faults (e.g., between parenthesis or question marks).
Given the preprocessed requirements, a syntax analysis is executed in order to extract words that can be potential candidates of a match with concepts of the ontology.
• Tokenization. The input sentence is split into single words using the OpenNLP toolkit.
Sentence: "The parameters for OBU must be given by RBC." Tokens: "The", "parameters", "for", "OBU", "must", "be", "given", "by", "RBC", "."
• PoS tagging. Each token of the sentence is marked with a part-of-speech tag using the NLP4J toolkit [7].
The parameters for OBU must be given by RBC .
IN NP MD VB VBN IN NNP .
• Dependency Parser. Using the NLP4J toolkit, a dependency tree is generated where each node is a token of the input sentence and edges are the relations between parent words and child words.
• Information Extraction. In this step, the words to categorize each requirement into the ontology are detected. For doing so, patterns that take into account the position in the sentence and PoS tag of the word are used. To extract these patterns, a study was performed with existing datasets: the most representative words for each requirement were detected and afterwards patterns were extracted according to the position in the sentences of these representative words. • N-Grams Generation. The matched patterns inside the dependency tree are analyzed in order to generate n-grams of nodes directly connected within the tree that are composed by a set of keywords encapsulating a big concept, a general idea superior to the individual meaning of each keyword. See Fig. 4 for an example.
Semantic analysis is the process that interprets the language meaning (i.e., the topic concept) of the whole text. The main goal is to obtain the meaning of each word of the n-gram, and join them to get a unique meaning that can be matched with the concepts of the ontology.
• Lemmatization. The morphological analyzer included in the NLP4J framework is used to apply several rules (based on a large dictionary and several advanced heuristics) to extract the lemmas of each token. These lemmas allow us to compare different words with the same lexeme.
• Semantic similarity. The DKPro-Similarity framework [8] is used as a word pair similarity detection in order to improve the lemmatization process, by identifying those tokens with a high similarity score that are not identified as part of the same lexeme. This step is potentially interesting for synonyms and similar meanings, which are analyzed using the lexical database WordNet [9].
OpenReq-DD uses conceptual clustering to classify requirements into the different concepts of the input ontology by similar features. For each n-gram obtained in the semantic analysis, the following rules are applied.
• First, find equal matches between words combinations of the n-gram and the n-grams of the ontology.
• If there is no match, find equal matches between combinations of the extracted lemmas from the n-gram and the extracted lemmas of the input ontology.
• If there is no match, calculate the semantic relatedness between lemmas from the n-gram and the input ontology. The requirement is matched if the value is greater than a provided threshold.
• If none of the previous conditions are satisfied, the requirement is discarded as an individual in the ontology.
The result of this step is the ontology filled by requirement individuals.
Finally, each pair of classes in the ontology that are linked with a dependency relation are analyzed extracting their instances (i.e., the requirements individuals) to find the existing dependencies.
In this section we provide details about a demo plan of the dependency detection analysis using OpenReq-DD.
For a demo execution, it is necessary to run both the OpenReq-DD web service and the Java GUI application. The GUI component is a presentation layer that simplifies the communication with the Dependency-Detection RESTful service. It allows the user to execute a dependency detection analysis in a simplified way, decoupling HTTP communication requirements and output data interpretation on the client side.
As input data we need a list of requirements and an ontology. Examples of both files are referenced in Sec. 2.1.
Figures 5a and 5b show the main views of the OpenReq-DD GUI application. The user is asked to upload two files: the ontology structure file (*.owl file) and the requirements list file (*.json file). Once these files have been uploaded, the user can initiate the dependency analysis by clicking on the "Extract dependencies" button. After this interaction, the whole process of dependency detection starts: the back-end of the tool applies the steps explained in Sec. 2.2 . The RESTful service returns a JSON format response including the requirements and the list of dependencies detected. Through the GUI component, the list of dependencies is shown in a table including, for each dependency, three items: the source of the dependency; the dependency type; and the target of the dependency.
We use the 6 RFP documents of the Siemens' use case to validate OpenReq-DD and the achievement of objectives in terms of efficiency and efficacy of the requirements' dependencies detection.
Tables 1 and 2 present a summary of both the automatic generated results of the OpenReq-DD tool and the stakeholder's manual validation. On the left side, we introduce the RFPs used for the Siemens use case, the number of total requirements of each RFP, and the number of dependencies extracted by our tool. These results were manually analyzed by stakeholders' experts, using three statistic measures: the precision of true positive detected dependencies, the precision with a refinement possibility (Precision-R) of true positive detected dependencies, and the imprecision of the detected dependencies, which is related to false positives outcomes. The results are good, but there is still room for improvement. We consider as future work exploring dependencies beyond semantic similarity, using other natural language criteria, and the extraction of relevant words from requirements using ML techniques (e.g., topic modelling).
The work presented in this paper has been conducted within the scope of the Horizon 2020 project OpenReq, which is supported by the European Union under the Grant Nr. 732463.