[Team Overview] The  Software  and  Service  Engineering  Group
(GESSI) of UPC has traditionally conducted research in many fields
of  software  engineering. [Research Plan on NLP] As  a  result  of
our participation in the OpenReq project, natural language processing
(NLP) has become one of our highest priority research fields.  We are
using NLP for interdependency detection and requirements reuse, being the center piece of both tasks the identification of similar requirements.Peer ReviewedPostprint (published version

Borrull Baraut, Ricard

Costal Costa, Dolors

Franch Gutiérrez, Javier

Quer, Carme

Information Technology and Nanotechnology

UPCommons. Portal del coneixement obert de la UPC

Research on NLP for RE at UPC: a ReportRicard BorrullUniversitat Politecnicade Catalunya (UPC)Barcelona, Spainrborrull@essi.upc.eduDolors CostalUniversitat Politecnicade Catalunya (UPC)Barcelona, Spaindolors@essi.upc.eduXavier FranchUniversitat Politecnicade Catalunya (UPC)Barcelona, Spainfranch@essi.upc.eduCarme QuerUniversitat Politecnicade Catalunya (UPC)Barcelona, Spaincquer@essi.upc.eduAbstract[Team Overview] The Software and Service Engineering Group(GESSI) of UPC has traditionally conducted research in many fieldsof software engineering. [Research Plan on NLP] As a result ofour participation in the OpenReq project, natural language processing(NLP) has become one of our highest priority research fields. We areusing NLP for interdependency detection and requirements reuse, beingthe center piece of both tasks the identification of similar requirements.1 Team OverviewThe Software and Service Engineering Group (GESSI, https://gessi.upc.edu/) of the Universitat Politecnica deCatalunya (UPC) conducts research in many fields of software engineering, with particular emphasis on require-ments engineering, software quality, software architecture, service-oriented computing, open source software,software modelling and empirical research.Lately, this research has focused on the topics of three H2020 research projects in which we are participating:SUPERSEDE (on software evolution and self-adaptation), Q-Rapids (on the management of quality require-ments in agile projects) and OpenReq (on applying intelligent recommendation and decision technologies forrequirements engineering).In the last year, as a result of our participation in the OpenReq project [Open], we began to study the ap-plication of natural language processing (NLP) techniques for the specification of natural language requirementsand for the improvement of the quality of requirements. In the following section we outline the directions ofresearch in the NLP field that we plan to explore.2 Research Plan on NLP for REThe overall goal of the OpenReq project [Open] is to develop intelligent recommendation and decision technologiesthat support different phases of RE, specifically elicitation, specification, analysis, management and negotiation.Copyright c© 2018 by the paper’s authors. Copying permitted for private and academic purposes.The project focuses on using artificial intelligence-based techniques that proactively support stakeholders, bothas individuals and as groups, within the scope of RE.Inside OpenReq, UPC is working, among others, in the interdependency detection and requirements reusepart. We envisage using NLP for both tasks. In particular, this is of special importance for two of the trials of theproject. One of them deals with bid projects of thousands of requirements, where they want to identify similarand dependent requirements in the same bid and from previous bids, and to reuse requirements knowledge ofprevious bids in the bit at hand; it is expected that this will reduce the cost of the bid phase and the requirementsanalysis phase by 10%. The other trial has a database with almost a hundred thousand requests (containingrequirements and bugs). They have not that much interest in the reuse functionality, but in the identificationof similar and dependent requests. It is estimated that at least 1000 requests (annually) could improve theirmanagement or be avoided.2.1 Interdependency DetectionInterdependency detection will combine the identification of explicit and non-explicit interdependencies in therequirements. By explicit interdependencies, we mean explicit references in a requirement to other requirements,while by non-explicit interdependencies we mean those ones that are not explicitly stated in the requirementsbut that can be identified by analyzing the requirements both from a syntactic and semantic point of view.For the detection of explicit interdependencies, we aim at following the approaches used in the well-known areaof cross-references detection and resolution. In the first approach, we will identify natural language patterns thatare used in requirements text to refer to other requirements and use them to propose new interdependencies.This approach will be based on works such as those of [Bre08] and [Pal03]. In the future, though, we will considera second approach that consists in the possibility to extract these patterns automatically as done in [San17].Although [San17] extract patterns used for cross-referencing in legal texts, we believe that a similar approachfor automatic extraction of such patterns can be extrapolated to requirements specifications.Regarding the detection of non-explicit interdependencies, the first step will be the identification of pairs ofsimilar requirements (both from a syntactic and semantic point of view). Similarity detection (i.e., syntacticsimilarity) and paraphrase detection (i.e., semantic similarity) are approaches closely related to detection ofinterdependencies between requirements.The relationship between similarity and paraphrase detection and interdependency detection is evident in thecase where two requirements have almost exactly the same formulation. Imagine the requirements ”The userinterface should use the letter type Arial letter type.” and ”The user interface should use the letter type Calibriletter type.”. It is clear that these two requirements cannot be used in the same system (since it is not possibleto use two letter types for the whole user interface), so these requirements are related by an OR interdependency(using the terminology proposed by Carlshamre [Car01]). However, even in other cases there are commonalities.As an example, if requirement R1 states that ”It shall be possible to filter personal data by name and address”and requirements R2 states that ”The system shall allow to filter personal data by age”, it would probably beconvenient to treat these two requirements at the same time to save development resources. This example canbe considered as an ICOST interdependency, according again to the terminology described in [Car01]. Otherexamples of interdependencies that can trigger a similarity analysis at a lexical level can be, e.g., the conflictingrequirements ”The button shall be blue.” and ”The button shall be red.”.Therefore, identifying syntactically and semantically similar requirements could be used as a basis to identifyrelated requirements. As there are several well-known components already developed to detect similar texts inEnglish, our aim is to select one of these components to be integrated and expanded in OpenReq. At the timebeing, we envision adding some pre-processing, such as clustering or classification techniques, to the use of thecomponent to reduce the set of requirements for which the component will run: if we reduce the set to which arequirement is compared to just the group of requirements it pertains according to a clustering algorithm, thepossibilities to achieve better matches will improve. The components we are currently evaluating are:• Cortical (http://cortical.io/). Among its functionalities, it provides a method to measure the similarityusing the Cosine metric between two given texts. In this case, the method is not parameterizable.• DKPro (https://dkpro.github.io/). DKPro provides, among others, a comprehensive repository of textsimilarity measures ranging from ones based on simple n-grams and common subsequences to more complexones based on high-dimensional vector comparisons and structural, stylistic, and phonetic measures.• Gensim (https://radimrehurek.com/gensim/tutorial.html). It includes implementations for popular algo-rithms such as LSA, LDA and RP. Gensim allows loading a corpus of texts to which a sentence can becompared. The calls to the algorithms are parameterizable.• Semilar (http://www.semanticsimilarity.org/). The methods offered by Semilar, which are completelyparameterizable, range from simple lexical overlap methods to methods that rely on word-to-word similaritymetrics to more sophisticated fully unsupervised methods that derive the meaning of words and sentencessuch as LSA and LDA to kernel-based methods for assessing similarity. In addition, one can select thetokenizer, tagger, stemmer and parser to be used as pre-processing (having as options, for instance, thelibraries OpenNLP, Stanford parser and WordNet).• Scikit-learn (http://scikit-learn.org/stable/documentation.html). It allows the transformation of texts intovectors, using TF-IDF among other algorithms, and the measurement of the similarity over them using theCosine metric.However, we do not discard to add new components to this list if the results of our evaluations are not goodenough or if other researchers know of other components that give better results.The second step of non-explicit interdependencies section is to improve and expand the requirements similaritydetection with further features, such as:• Creating a specific list of synonyms that are domain dependent, so that the similarity algorithms can knowwhen two words that in principle are not synonyms are actually synonyms in a specific domain.• Constructing models that can help to detect interdependencies by relating concepts on this model. Thisis similar to the ontology used in [Zhu05], but in our model, relationships will broaden the scope of theprevious work, which is focused on inconsistencies. For instance, if we know that technologies A and B areincompatible, A and B will be related in this model as conflicting. Therefore, when these two technologiesare used at the same time in a single project, we can extrapolate that the requirements stating technologiesA and B are actually conflicting and a new interdependency of this type will be created among them.2.2 Requirements ReuseTo achieve requirements reuse, we plan to adapt the PABRE framework [Fra13] [Ren09], which stands forPAtterns-Based Requirement Elicitation, to OpenReq. The core asset in the PABRE framework are SoftwareRequirement Patterns (SRPs). In a nutshell, an SRP is a set of Templates that pursue the same goal in a systemto be developed. Each template corresponds to the text to be used as a requirement and, if necessary, someoptional Parameters (with a set of possible values: range of numbers to be used, possible strings, etc.) that needto be instantiated when applying the pattern. As a goal can be achieved in different ways, an SRP consists ofseveral Forms, each one representing a different solution for achieving the goal. In additon, Forms are organizedinto Parts, each of them being a template: a Fixed Part, which is always applied if the form is chosen, and someExtended Parts, which may be applied or not. Finally, SRPs are classified using Classification Schemas, whichare hierarchies of classifiers that facilitate the organization of SRPs.In OpenReq, we will adapt the structure of SRP defined in the PABRE framework to the needs of the project.Additionally, we will need to define a catalogue of SRPs for OpenReq (possibly one per trial). Therefore, it isimportant that the population of this catalogue will combine automatic extraction with expert assessment. Theautomatic extraction will need some type of NLP processing, and probably machine learning. For instance, webelieve topic modelling could be used to extract the common topics found in requirements specifications, cluster-ing techniques to group requirements, and syntactic and semantic similarity identification to find requirementsthat are repeated along the different specifications. These techniques might help to populate the SRP catalogue.Finally, we envisage different ways in which this catalogue of patterns could be used in OpenReq. Here, wepresent the ones that will need the support of NLP:1. Propose SRP that are dependent. Given a requirement, using a similarity algorithm it will be possible torecover similar SRP (by analyzing the templates in the SRPs with the given requirement). Then, once weknow the similar SRPs to a given requirement, if they are dependent to other SRPs, we can propose thesedependent SRP so they can be reused. For instance, R1 is similar to a template in the requirement patternSRP2, which is dependent on the requirement pattern SRP3. In that case, SRP3 could be proposed to bereused for R1.2. Propose SRP the are related. Again, given a requirement, using a similarity algorithm it will be possibleto recover similar SRP (by analyzing the templates in the SRPs with the given requirement) (e.g., R1 issimilar to a template of SRP1 ). Then, if SRP1 is in classifier C1 other SRPs in the same classifier couldbe proposed for reuse (e.g., SRP2 ). So, for R1, SRP2 will be proposed since they both under the sameclassifier. A similar approach could be used for the keywords. If SRP1 has keyword K1, we can look in thecatalogue for other SRPs that have keyword K1 (e.g., SRP3 ), and these SRPs could be proposed for reuse.So, in that case, for R1, SRP3 will be proposed for reuse since they both are both about keyword K1.2.3 Further IssuesIt is important to highlight here the fact that OpenReq will deal not only with English language, but also withItalian and German, since one of the trials deals with requirements written in Italian, and another trial deals withrequirements (partially) written in German. This diversity of languages used to write the text analyzed supposesa challenge for the project. The majority of the existing NLP approaches target the English language, as theyare trained and validated using English text corpora. Although NLP approaches and software libraries existfor both languages [Bas15] [Reh12], we have to check that their performances (e.g., precision) are not inferiorcompared to the well-established, English-based ones (specially when used for parsing and similarity detection).AcknowledgementsThe 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.References[Bas15] Basili R., Bosco C., Delmonte R., Moschitti A.; Simi M. Harmonization and development of resourcesand tools for Italian natural language processing within the PARLI Project Springer, 2015.[Bre08] Breaux, T.; Anton, A. Analyzing regulatory rules for privacy and security requirements IEEE Transactionon Software Engineering, 34(1), 520, 2008.[Car01] Carlshamre, P.; Sandahl, K.; Lindvall, M.; Regnell, B.; och Dag, J. N. An industrial survey of require-ments interdependencies in software product release planning 5th IEEE International Symposium onRequirements Engineering, 84-91 2001.[Fra13] Franch, X.; Quer, C.; Renault, S.; Guerlain, C.; Palomares, C. Constructing and using software require-ment patterns Managing requirements knowledge Springer, 2013.[Pal03] Palmirani, M.; Brighi, R.; Massini M. Automated extraction of normative references in legal texts 9thinternational conference on artificial intelligence and law (ICAIL03), 105106, 2003.[Open] OpenReq: Intelligent Recommendation and Decision Technologies for Community-Driven RequirementsEngineering (Horizon 2020 Project, https://www.openreq.org).[Reh12] Rehbein I., Ruppenhofer J., Sporleder C.; Pinkal M. Adding nominal spice to SALSA - frame-semanticannotation of German nouns and verbs Conference on Natural Language Processing (KONVENS), 2012.[Ren09] Renault, S.; Mndez, O.; Franch, X.; Quer, C. A Pattern-based Method for building Requirements Docu-ments in Call-for-tender Processes Int J Comput Sci Appl, 6(5), 175202, 2009.[San17] Sannier, N.; Adedjouma, M.; Sabetzadeh, M.; Briand, L.C. An automated framework for detection andresolution of cross references in legal texts Requirements Engineering, 22(2), 215-237, 2017.[Zhu05] Zhu, X.; Jin, Z. Inconsistency measurement of software requirements specifications: an ontology-basedapproach 10th IEEE International Conference on Engineering of Complex Computer Systems (ICECCS),402-410, 2005.

Research on NLP for RE at UPC: a report

[Team Overview] The  Software  and  Service  Engineering  Group

(GESSI) of UPC has traditionally conducted research in many fields

of  software  engineering. [Research Plan on NLP] As  a  result  of

our participation in the OpenReq project, natural language processing

(NLP) has become one of our highest priority research fields.  We are

using NLP for interdependency detection and requirements reuse, being the center piece of both tasks the identification of similar requirements.Peer Reviewe

UPCommons

https://upcommons.upc.edu/bitstream/2117/123922/1/NLP4RE_paper13.pdf

Research on NLP for RE at UPC: a report

Abstract

Similar works

Full text

Available Versions

UPCommons. Portal del coneixement obert de la UPC

UPCommons