OpenReq: Recommender Systems in Requirements Engineering Alexander Felfernig Martin Stettinger Andreas Falkner Institute for Software Technology Institute for Software Technology Siemens AG Austria Inffeldgasse 16b/2 Inffeldgasse 16b/2 Siemensstrasse 90 Graz A-8010 Graz A-8010 Vienna A-1210 afelfernig@ist.tugraz.at mstettinger@ist.tugraz.at andreas.a.falkner@siemens.com Müslüm Atas Stefan Reiterer Xavier Franch Institute for Software Technology Institute for Software Technology Department of Service and Inffeldgasse 16b/2 Inffeldgasse 16b/2 Information System Engineering Graz A-8010 Graz A-8010 Calle Jordi Girona, 1-3 muatas@ist.tugraz.at reiterer@ist.tugraz.at Barcelona ESP-08034 franch@essi.upc.edu Cristina Palomares Department of Service and Information System Engineering Calle Jordi Girona, 1-3 Barcelona ESP-08034 cpalomares@essi.upc.edu ABSTRACT from the bid management (identification and feasibility estimation The major focus of OpenReq is the development of recommendation of requirements in large-scale industrial development projects), and decision technologies that efficiently support requirements community-driven cross-platform requirements engineering, and engineering processes in large and distributed software projects. requirements engineering scenarios in telecommunication-related Example scenarios thereof are the bid management in industrial large user communities. systems, requirements engineering in cross-plattform open source The bid management scenario (see also Section 5) focuses on software development, and requirements management in large user Request For Proposals (RFPs) management for railway safety sys- communities (telecommunications sector). The aim of this paper is tems. These RFPs are issued by national railway providers and to provide an overview of OpenReq and to provide insights into comprise natural language documents of several hundred pages related application scenarios and research issues. with requirements of different levels of detail and of different types (domain specific, physical, non-functional, references to standards CCS CONCEPTS and regulations, etc.). At present, most of this management is done manually using an RE system, making most of the tasks time •Information Storage and Retrieval → Information Search consuming. OpenReq will help in this scenario mainly to: 1) au- and Retrieval; •Information Systems Applications → Decision tomatically extract requirements from RFPs, differentiating the Support Systems; •Information Interfaces and Presentation → information included in these RFPs that are not requirements; 2) User Interfaces; reuse technical decisions made in previous projects; 3) automati- cally assign requirements to stakeholders; and 4) support group KEYWORDS decision making. Recommender Systems, Requirements Engineering In the case of the cross-platform open source scenario, the com- munity consists of individuals contributing in their free time and professional developers working on projects. Here, OpenReq will 1 INTRODUCTION help with advanced user engagement (e.g., by identifying users who High-quality requirements engineering (RE) is among the most potentially could contribute to issues related to topics of interest critical factors for successful software projects [14]. The overall for other users), with internal release planning (e.g., by detecting goal of OpenReq1 is to develop intelligent recommendation and ”urgent” requirements using community information such as nu- decision technologies that support different phases of requirements merous complaints about the same issue or by supporting group engineering [1, 3, 4, 10, 20]. Based on existing work [11, 20, 21], decision making by, for example, highlighting relevant stakeholders the project focuses on AI-based techniques that pro-actively sup- who should be included in a discussion), with the management of port stakeholders within the scope of requirements engineering. requirements knowledge (e.g., by detecting requirements dependen- OpenReq entails different industrial RE scenarios (trials) that range cies or by supporting the assessment of feature compatibilities and 1 Intelligent Recommendation and Decision Technologies for Community-Driven Re- their relationships), and with the detection of new requests based on quirements Engineering (Horizon 2020 Project, www.openreq.org). discussions identified in community sites. The main goal of the telecommunication scenario, apart from 2 RECOMMENDATIONS FOR SINGLE USERS improving the RE process, is to react as fast as possible to the opin- All of the recommendation approaches mentioned so far can be ions of customers (stated in user communities). With this in mind, applied in the context of single-user recommendation scenarios, OpenReq will be used in this scenario to: 1) identify and extract i.e., scenarios were a single user (stakeholder) interacts with a requirements from user requests; 2) monitor the communities to recommender application. identify acute issues to enable early risk assessment; 3) propose prior- An example of a RE-related scenario where collaborative filtering itization indicators for requirements derived from user discussions [17] can be applied is the following: when trying to understand and/or usage behavior; and 4) support stakeholders in the prepara- a given set of requirements (a requirements model), collaborative tion for a group decision (e.g., highlighting relevant topics/artifacts recommendation can recommend requirements that have already and relevant stakeholders). been analyzed by stakeholders with similar interests, i.e., stake- In addition to the three mentioned trial scenarios, the OpenReq holders who analyzed similar sets of requirements. Furthermore, ShowCase will be developed which will integrate the core fea- collaborative filtering can be applied in the context of identifying tures (recommendation and decision technologies) of the OpenReq discussion forums for stakeholders, i.e., depending on the interests software components. We will provide these features in terms of of the current stakeholder, further forums / discussion topics can an open-source component (HTML-5 application) with the goal be identified that might be of relevance for the stakeholder [5–7]. to enable quality improvements in RE processes on a large scale. When defining requirements, content-based recommenders [22] This component will consist of functionalities that support the au- can recommend requirements that have already been defined in pre- tomated identification of requirements from different knowledge vious projects and could be of relevance for the current project, i.e., sources (e.g., communities or natural language text documents), the support requirements reuse. Similarly, content-based recommenda- recommendation of requirements and stakeholders in different RE tion can be used to support the recommendation of stakeholders phases, the support of group decision making in release planning, relevant for a new software project. Depending on the requirements and the automated identification of (hidden) dependencies between defined for a software project, content-based recommendations can requirements. Especially dependencies detection and (formal) re- indicate persons who could be engaged as stakeholders in a software lease planning strongly depend on each other since release plans project due to their tasks already completed in previous projects. have to take into account existing dependencies. The later such Finally, content-based recommendation technologies can be applied dependencies are detected the higher the corresponding follow-up in the context of new requirements development, for example, to costs in a software project. filter requirements of high relevance due to the fact that these cover Major recommendation paradigms that will be integrated into issues/topics included in many discussion threads. OpenReq are the the following. First, collaborative filtering based Constraint-based recommendation [9] is applied in scenarios where recommendation [17] simulates word-of-mouth promotion of items constraints are used to define restrictions on the possible outcomes where the opinion of family members and friends (also denoted as of a decision process. An example of the application of constraint- nearest neighbors) has an impact on choices taken by a person. In based recommendation technologies in RE is release planning [24], the context of recommender systems, nearest neighbors are system i.e., the decision making on when (in which software release) to im- users with similar preferences often expressed in terms of item plement a specific requirement. In this scenario, requirements have evaluations. Second, content-based filtering [22] focuses on the to be assigned to releases. Existing dependencies between require- analysis of item descriptions, for example, news items which are ments have to be taken into account by the search component (e.g., content-wise similar to those already ”consumed” by a person are constraint solver [26]) in charge of identifying/proposing solutions recommendation candidates. Third, constraint-based recommen- for a release planning task. A major issue in this context is to as- dation is based on explicitly defined recommendation knowledge sure that all existing dependencies between requirements are taken often represented in terms of constraints or rules – see [9]. Finally, into account. This requires the integration with corresponding group recommender algorithms [19, 25] focus on recommending dependency detection functionalities (see Section 4). items to groups of users. In this context, basic recommendation Integrations of basic recommendation approaches into require- technologies such as collaborative filtering and content-based fil- ments engineering environments already exist – for an overview tering are combined with social choice functions [19] that help to see, for example, [11, 20, 21]. A major goal of OpenReq in this aggregate the preferences of individual users (stakeholders). context is to focus on a more in-depth integration of these technolo- In the following, we will provide an overview of RE-related ac- gies with related social factors, for example, by taking into account tivities that can be supported by recommendation and decision decision styles of stakeholders [8] and exploiting recommenders for technologies. In Section 2 we show in which way recommender achieving persuasive effects to increase the amount of information algorithms for single users (stakeholders) can be applied in RE con- exchange [18]. texts. Section 3 focuses on scenarios where groups of stakeholders All the examples mentioned so far are related to single stake- have to be supported in their decision processes. Section 4 is related holder (user) scenarios, i.e., scenarios where single stakeholders to issues in the context of identifying and managing dependencies are in charge of taking a decision (e.g., which stakeholders should between requirements and resolve inconsistencies. Thereafter, we be invited to join the project or which requirements should be present one of the application scenarios of OpenReq (Section 5). reused). In the following sections, we will focus on scenarios where Finally, we conclude the paper with Section 6. groups of stakeholder have to be supported by recommendation technologies. 2 3 RECOMMENDATIONS FOR GROUPS of a requirement to a release) but also different perceptions re- In contrast to single user scenarios, many choice tasks are defined garding the meta-properties of a requirements (e.g., effort, risk, in group contexts. One example thereof is the already mentioned etc.). If available in an explicit fashion, for example, in terms of release planning scenario. Very often, decisions regarding the as- stakeholder-specific evaluations or explicit assignments of require- signment of requirements to releases are taken in groups, i.e., a ments to releases, related conflicts can be resolved on the basis of group as a whole has to develop agreement regarding the planned conflict detection and diagnosis algorithms [12, 16, 23]. However, a releases. In such scenarios, inconsistencies between the preferences major issue in this context is also to identify (hidden) dependencies of individual stakeholders can occur. For example, two stakehold- between requirements, i.e., relationships (constraints) between re- ers have different opinions regarding the assignment of a specific quirements that are not represented in an explicit fashion, i.e., they requirement to a release. Another related example is requirement are not contained in the requirement model due to the fact that the evaluation where a group of stakeholders is in charge of evaluating constraints/restrictions are simply not known to stakeholders. a requirement with regard to different dimensions such as effort in Approaches to the automated detection of dependencies between MMs, risk level, potential turnover, and importance of implementa- requirements already exist [10, 21]. Existing approaches focus on tion. The group (of stakeholders) as a whole has to decide on how to the detection of dependencies using content-based recommenda- further proceed with this requirement. Since different stakeholders tion based on similarity measures. A major focus of OpenReq is to often evaluate requirements differently, a major task in this con- advance the state of the art in dependency detection and to come text is to achieve consensus regarding the overall evaluation. In up with new solutions (e.g., based on techniques from natural lan- this context, diagnosis techniques [12, 23] play a major role since guage processing) that help to significantly increase the overall they are able to indicate possible (minimal) changes of the current quality of dependency detection. For example, existing content- stakeholder preferences in order to identify a solution (e.g., a re- based approaches provide indications of dependencies in terms of lease plan). In the context of group recommendation scenarios, similarities between requirements. OpenReq will go beyond that social choice functions play a major role [19]. These functions (also a.o. in terms of approaches that also point out semantic properties denoted as aggregation functions) help to identify recommenda- of dependencies. tions acceptable for the whole group. For example, least misery prefers recommendations that do not ignore negative evaluations 5 SCENARIO: BID MANAGEMENT of stakeholders, i.e., if a requirement has been evaluated negatively From the three OpenReq trial scenarios, we decided to discuss the by ”only” one member of a group of stakeholders, this requirement Siemens trial in more detail. The corresponding use-case (trial) in has to be evaluated further (and discussed in the group) before the OpenReq project involves bid projects for large-scale industrial being acceptable as a release candidate. systems related to the Siemens Mobility division. Integrations of group recommendation technologies into RE RFPs (Request For Proposal) for railway safety systems are is- processes already exist [10, 21]. A major focus of OpenReq is sued by different national railway providers and comprise natural to gain in-depth insights into RE related decision processes and language documents (represented in MS Word format) consisting of how (group) recommendation technologies best help to improve the several hundred pages with requirements of various kind (domain overall quality of decision processes. For example, different types of specific, physical, non-functional, references to standards and regu- decision biases will be analyzed with regard to their occurrence and lations, etc.) and level of detail. Typically, a complete bid (proposal) possibilities to counteract. An example thereof is GroupThink [15] comprises several subsystems, such as signaling hardware, track in a discussion forum [7] where strong influences of opinion makers indication, interlocking software, ETCS, SCADA, etc. can result in suboptimal outcomes of related decision processes. Proposals are delivered by the national sales departments of large Furthermore, existing theories of group dynamics [13] and re- enterprises such as Siemens. Typically, a bid project with a duration lated social choice functions [19] are evaluated with regard to their of a few months is necessary to answer a RFP. The team comprises applicability and new variants will be developed to optimize rec- several stakeholders such as a project manager, a requirements ommendation support in RE related group decisions. We are also administrator, a system architect, and technical experts. working on extending the application of group recommendation Requirements engineering is an important part of the bid pro- technologies to scenarios where recommendations are used to per- cess. Its main purpose is to ensure the technical compliance of the suade users to change their behavior, for example, in terms of offer. After importing the (unstructured) natural language text into increasing their personal engagement in requirements engineering requirements management tool such as Polarion ALM and cutting processes a.o. in terms of an increased frequency of knowledge it up into requirement candidates, recommendation technologies sharing (see, for example, [2]). can support a.o. the following sub-tasks: • Deciding which of the candidates are real requirements and which are just explanatory text. This classification is 4 DEPENDENCY DETECTION AND CONFLICT based on domain knowledge and experience from past bid MANAGEMENT projects. A major issue in group decision making is how to deal with con- • Assigning the requirements to one or more stakeholders flicting preferences of group members. Related examples in RE are (internal departments, external subcontractors) who shall group decisions in the context of release planning where stake- evaluate them. Recommendation can suggest the corre- holders have conflicting preferences (e.g., regarding the assignment sponding stakeholder roles (not physical persons). 3 • Evaluating the requirements for technical compliance (yes, [12] A. Felfernig, M. Schubert, and C. Zehentner. 2012. An Efficient Diagnosis Al- conditionally, no). Recommendation is based on similar gorithm for Inconsistent Constraint Sets. Artificial Intelligence for Engineering Design, Analysis, and Manufacturing (AIEDAM) 26, 1 (2012), 175–184. requirements. [13] D. Forsyth. 2006. Group Dynamics. Thomson Higher Education. • Suggesting solution approaches to satisfy the requirement [14] H. Hofmann and F. Lehner. 2001. Requirements Engineering as a Success Factor in Software Projects. IEEE Software 18, 4 (2001), 58–66. and deciding which approach should be supported in the [15] I. Janis. 1972. Victims of Groupthink. Houghton-Mifflin. given context. [16] U. Junker. 2004. QUICKXPLAIN: Preferred Explanations and Relaxations for Over-Constrained Problems. In 19th National Conference on AI (AAAI04). San Jose, CA, 167–172. 6 CONCLUSIONS [17] J. Konstan, B. Miller, D. Maltz, J. Herlocker, L. Gordon, and J. Riedl. 1997. Grou- pLens: applying collaborative filtering to Usenet news Full text. Comm. of the In this paper, we provided a short overview of scenarios where rec- ACM 40, 3 (1997), 77–87. ommendation and decision technologies can support requirements [18] M. Stettinger M. Atas, A. Felfernig and TNT. Tran. 2017. Beyond Item Recommen- engineering processes. Within the scope of OpenReq, we will focus dation: Using Recommendations to Stimulate Information Exchange in Group Decisions. In 9th International Conference on Social Informatics (SocInfo 2017). on the development of corresponding technologies that can be used Oxford, UK, 1–10. as an extension for existing requirements engineering tools but also [19] J. Masthoff. 2011. Group Recommender Systems. Recommender Systems Handbook (2011), 677–702. as a basis for the development of a new generation of requirements [20] B. Mobasher and J. Cleland-Huang. 2011. Recommender Systems in Requirements engineering solutions that focus on a systematic improvement of Engineering. AI Magazine 32, 3 (2011), 81–89. related development, maintenance, quality assurance, and decision [21] G. Ninaus, A. Felfernig, M. Stettinger, S. Reiterer, G. Leitner, L. Weninger, and W. Schanil. 2014. IntelliReq: Intelligent Techniques for Software Requirements Engi- processes. Finally, a basic version of OpenReq will be provided neering. In European Conference on Artificial Intelligence, Prestigious Applications that acts as a showcase for demonstrating the basic capabilities of of Intelligent Systems (PAIS). 1161–1166. the OpenReq components. [22] M. Pazzani and D. Billsus. 1997. Learning and Revising User Profiles: The Identification of Interesting Web Sites. Machine Learning 27 (1997), 313–331. [23] R. Reiter. 1987. A theory of diagnosis from first principles. AI Journal 23, 1 (1987), 57–95. ACKNOWLEDGMENTS [24] G. Ruhe and M. Saliu. 2005. The Art and Science of Software Release Planning. The work presented in this paper has been conducted within the IEEE Software 22, 6 (2005), 47–53. [25] M. Stettinger, A. Felfernig, G. Leitner, S. Reiterer, and M. Jeran. 2015. Counteract- scope of the Horizon 2020 project OpenReq (Intelligent Recommen- ing Serial Position Effects in the CHOICLA Group Decision Support Environment. dation and Decision Technologies for Community-Driven Require- In 20th ACM Conference on Intelligent User Interfaces (IUI2015). Atlanta, Georgia, ments Engineering) which is supported by the European Union USA, 148–157. [26] E. Tsang. 1993. Foundations of Constraint Satisfaction. Academic Press, London. under the Grant Nr. 732463. REFERENCES [1] B. Alenljung and A. Persson. 2005. Decision-making activities in the requirements engineering decision processes: A case study. In ISD 2005. Karlstad, Sweden, 707–718. [2] M. Atas, A. Felfernig, M. Stettinger, and TNT. Tran. 2017. Beyond Item Recom- mendation: Using Recommendations to Stimulate Knowledge Sharing in Group Decisions. In 9th International Conference on Social Informatics (SocInfo 2017). Oxford, UK, 1–10. [3] A. Aurum and C. Wohlin. 2003. The fundamental nature of requirements en- gineering activities as a decision-making process. Information and Software Technology 45, 14 (2003), 945–954. [4] R. Burke, A. Felfernig, and M. Goeker. 2011. Recommender Systems - An Overview. AI Magazine 32, 3 (2011), 13–18. [5] C. Castro-Herrera, C. Duan, J. Cleland-Huang, and B. Mobasher. 2008. Using Data Mining and Recommender Systems to Facilitate Large-Scale, Open, and Inclusive Requirements Elicitation Processes. In 16th IEEE Intl. Conf. on Req. Engineering (RE’08). Barcelona, Spain, 165–168. [6] J. Cleland-Huang, H. Dumitru, C. Duan, and C. Castro-Herrara. 2009. Automated support for managing feature requests in open forums. Commun. ACM (2009), 68–74. [7] J. Cleland-Huang and B. Mobasher. 2008. Using data mining and recommender systems to scale up the requirements process. In 2nd International Workshop on Ultra-large-scale Software-intensive Systems. Leipzig, Germany, 3–6. [8] A. Felfernig, M. Atas, TNT. Tran, M. Stettinger, S. Polat-Erdeniz, and G. Leitner. 2017. An Analysis of Group Recommendation Heuristics for High- and Low- Involvement Items. In 30th International Conference on Industrial Engineering and Other Applications of Applied Intelligent Systems (IEA/AIE 2017). Arras, France, 335–344. [9] A. Felfernig and R. Burke. 2008. Constraint-based Recommender Systems: Tech- nologies and Research Issues. In ACM International Conference on Electronic Commerce (ICEC08). Innsbruck, Austria, 17–26. [10] A. Felfernig, W. Maalej, M. Mandl, M. Schubert, and F. Ricci. 2010. Recommen- dation and Decision Technologies For Requirements Engineering. In ICSE 2010 Workshop on Recommender Systems in Software Engineering. Cape Town, South Africa, 1–5. [11] A. Felfernig, G. Ninaus, H. Grabner, F. Reinfrank, L. Weninger, D. Pagano, and W. Maalej. 2013. Managing Requirements Knowledge Book (1st ed.). Springer, Berlin Heidelberg, Chapter An Overview of Recommender Systems in Requirements Engineering, 315–332. 4