1 Introduction

Requirements engineering (RE) is concerned with the elicitation, analysis, specification, validation and management of requirements [41]. It is well known that RE contributes to the improvement of the quality of software development decreasing the risk of budget overrun, delays and project failures [58].

In the context of software development, there is a growing interest in the use of ontologies [23, 53], which is an “explicit specification of a conceptualization” [26]. It is “explicit” because of its classes and properties visibility. Conceptualization is understood to be an abstract and simplified version of the world to be represented. Moreover, ontologies can be logically reasoned and shared within a specific domain [28]. Every knowledge base, knowledge-based system, or knowledge-level agent is committed to some conceptualization, explicitly or implicitly [13]. Thus, ontologies are a standard form for representing the concepts within a domain, as well as the relationships between those concepts in a way that allows automated reasoning.

Due to such benefits, the concept of ontology has been used in RE to minimize or resolve different types of problems. It is used, for instance, to specify more complete and unambiguous requirements, to perform consistency analysis in requirements, to explicitly model domain knowledge, to manage requirements knowledge and requirements changes and so on [9, 60].

There are some studies that investigated the use of ontologies in Software Engineering [23, 57] and, specifically, the use of ontologies in RE [9]. However, these studies did not capture all the aspects and evidences that we are interested. Moreover, they did not perform any kind of systematic investigation of the literature covering ontologies in RE.

Hence, the objective of this work is to conduct a systematic review of the literature to find out how ontologies support RE. It is also important to investigate whether there are real evidences of the improvements of using ontologies to support RE activities. Moreover, we also need to understand: (1) which are the main phases of the RE process amenable to the use of ontologies; (2) what types of requirements modelling styles have been supported by ontologies; (3) if ontologies have been used to support both functional and non-functional requirements; (4) what RE problems have been addressed by ontology-driven contributions and the types of these contributions; (5) which languages have been used in the ontology-driven RE process; and (6) if the RE ontologies have been reused and how they have been reused.

In this paper, we use the systematic literature review (SLR) method [39] to identify, evaluate, interpret and synthesize the available studies to answer particular research questions on the symbiosis of ontologies and RE, and to establish the state of evidence with in-depth analysis. The SLR method has already been used in different topics within RE. For instance, RE education [51], use case models [20], transformation between user requirements and analysis models [66], technology transfer decision in RE [35] and stakeholder identification methods in requirements elicitation [52].

Our purpose is to better understand how ontologies support RE and identify in what ways it has being applied to this field. This paper extends a previous SLR that we conducted [14] considering a reduced number of research questions (only five) on the ontology-driven RE topic. We also extend the selection process of the previous SLR by reviewing the references lists of the papers included in it. Additionally, we perform a more detailed and quantitative analysis of the papers’ results.

In this way, this paper presents the results of an extended SLR on studies published from January 2007 to October 2013 and was conducted following a predefined review protocol. Our decision on such period was made to reduce repetitive effort and make use of existing work, since there is a general survey on the use of ontologies in software engineering. Ruiz and Hilera [57] summarize research about the use of ontology to support software engineering/RE until 2006.

This paper is organized as follows. Section 2 describes the SLR method used in this review and the context within it is inserted. Section 3 first presents the results of the quality assessment and an overview of the studies. It then reports the findings of the review along with a detailed analysis and discussion of each research question. Section 4 discusses the scope of this SLR, some related works and threats to the validity of our work and points out further research to be explored on the use of ontologies in RE. Finally, Sect. 5 presents conclusions and future works.

2 Methods

A SLR is a means of identifying, evaluating and interpreting the available research findings related to a research question, topic area, or phenomenon. The main purpose for conducting a systematic review is to gather evidence on which to base conclusions [39].

In order to perform this SLR, the guidelines and the systematic review protocol template proposed by Kitchenham and Charters [39] were used. According to these guidelines, the SLR process includes several activities, which can be grouped in three main phases: planning of the SLR, conducting the SLR and reporting the SLR. It consists of the following steps: (1) identification of the need for a systematic review; (2) formulation of a focused review question; (3) a comprehensive, exhaustive search for primary studies; (4) quality assessment of included studies; (5) identification of the data needed to answer the research question; (6) data extraction; (7) summary and synthesis of study results; (8) interpretation of the results to determine their applicability; and (9) report-writing.

A software tool was used to support the SRL protocol definition. The tool, called StArt (State of the Art through Systematic Reviews) [43], is used to provide support to researchers conducting SLRs. StArt has been empirically evaluated, and it was demonstrated that such tool had positive results in the execution of SLRs [31].

Before describing the research questions of this review, we present the context (RE and ontologies) in which these questions are included.

2.1 Requirements engineering

The RE process is composed by several activities: Requirements Elicitation, Requirements Analysis and Negotiation, Requirements Documentation and Requirements Validation [41].

The requirements elicitation phase involves understanding the application domain, the specific problem to be solved, the organizational needs and constraints and the specific facilities required by the system stakeholders.

Requirements analysis and negotiation are concerned with the high-level statement of requirements elicited from stakeholders. The objective of this activity is to establish an agreed set of requirements which are complete and consistent.

Requirements validation is the final stage of RE. The aim of this phase is to check the final draft of a requirements document to certify it represents an acceptable description of the system to be implemented. The inputs to the validation process are the requirements document, organizational standards and implicit organizational knowledge. The outputs are a list of requirements problems and agreed actions to address these problems.

In addition to these activities, Kotonya and Sommerville [41] also emphasize the need to manage requirements. Requirements management is the process of managing changes in systems’ requirements. Therefore, this process supports others RE and system development activities. Besides, it is carried out in parallel with other RE activities and continues after the first version of the requirements document has been delivered.

2.2 Ontologies

The term ontology comes from a branch of philosophy that deals with the nature of being [12]. The term was introduced in computer science by artificial intelligence researchers who constructed computer models with some kind of automated reasoning. From the 90’s, ontologies began to be treated as an integral part of knowledge-based systems, defined as an explicit specification of conceptualization [26].

In the computer and information science context, an ontology defines a set of representational primitives in a particular knowledge area [49]. The usually adopted representational primitives are classes, attributes and relationships, including their meanings and restrictions. Ontologies are typically specified with languages that allow some kind of abstraction from data structures and from implementation strategies [27].

Ontologies languages are used for domain formalization by defining classes and properties for these classes, individuals (that instantiate the classes), properties of individuals, and statements on these individuals. It also allows to reason about these classes and individuals according to formal semantics defined by the language. On the one hand, the defined models gain a formal representation, which can be useful to support software engineering activities. On the other hand, using ontologies can support the automated reasoning and inference on such models.

Ontologies can be written down in a wide variety of languages and notations, such as Description logics [6], First-order logics, Relational model, UML and so on. However, ontologies are generally represented using one of the variants of the Web Ontology Language (OWL) [48], which is part of the technologies stack defined by the World Wide Web Consortium (W3C) for Semantic Web.

The OWL language has its roots in Description Logics and provides formal and clear semantics for the definition of concepts and their relationships. OWL ontologies are often serialized using an RDF/XML representation—also part of the stack of W3C technologies—which is a triple format that models information using triples in the form of subject-predicate-object expressions. The information represented in RDF format (e.g., OWL ontologies) can be queried using a standard RDF query language called SPARQL [54], which is an SQL-like language. Additionally, the Semantic Web Rule Language (SWRL) [32] proposal extends the set of OWL axioms to include Horn-like rules in order to provide even more inference capabilities to it.

2.3 Research questions

This systematic review’s purpose is to better understand how ontologies support RE and identify to what extent they have been applied to this field. Thus, we intend to answer the main research question:

How are ontologies supporting the Requirements Engineering process?

Based on the main research question, specific questions were raised according to RE aspects that we are interested. These questions, their descriptions and motivations are described in Table 1.

Table 1 Research questions and motivations

2.4 Inclusion and exclusion criteria

The aim of defining a criterion is to identify those primary papers which provide direct evidence about the research questions and also to reduce the likelihood of bias [39]. It is worth noting that we consider as primary papers the studies which present some kind of proposal to the area and/or present some kind of empirical validation of its contributions, whereas secondary papers are studies which only review a topic area, i.e., a SLR.

The studies were eligible for inclusion in the review if they presented a peer-reviewed primary study, published since January 2007 to October 2013 and that presented some contribution on the use of ontology to support RE activities. They should also satisfy the minimum quality threshold (see Sect. 2.6). Our decision on such period was made to reduce repetitive effort and to make use of existing work, since there is a general survey on the use of ontologies in software engineering [57]) published in 2006 covering the ontology-driven RE studies before this period.

Studies were excluded if they were secondary, short papers, non-peer-reviewed, duplicated, non-English written, grey literature papers (e.g., books, theses, dissertations and so on), redundant papers of same authorship and if their focus was not using ontologies to support RE activities. Furthermore, this research is concerned with generic and technology/paradigm independent contributions to software development, for this reason, domain-specific papers, Service-Oriented Architecture (SOA) [34], Agent-Oriented Software Development (AOSE) [65], Business Process Models (BPM) [63] and Information Technology (IT) exclusive papers were also excluded. Ontology engineering [25] papers were also out of the scope of this review. The summarized inclusion and exclusion criteria are presented in Table 2.

Table 2 Inclusion/exclusion criteria

2.5 Sources selection and search

The search strategy included only electronic databases and was validated by experts on the ontology and RE areas. By using a search string and based on [10], the following electronic databases were automatically searched: ScienceDirect,Footnote 1 ISI Web of Science,Footnote 2 Scopus,Footnote 3 SpringerLink,Footnote 4 ACM Digital Library,Footnote 5 IEEE XploreFootnote 6 and Compendex.Footnote 7

Figure 1 shows the systematic review process and the number of papers identified at each stage. Before describing these stages, it is worth emphasizing that, although the scope of this paper is reviewing the use of ontologies in RE process, this research is part of an ongoing work which intends to review the use of ontologies in the entire software engineering process. Hence, the search and selection strategy (i.e., the search string and Steps 1–5) aims to capture studies related to the main aspects of software engineering area for instance, software requirements, software design, software implementation, software testing, software management and so on. As such they will be useful for several other studies. The papers related to RE, which are the focus of this review, are only identified and selected in Step 6 of the process, as it will be further described.

Fig. 1
figure 1

Paper selection flowchart

In Step 1, the studies were obtained from electronic databases using the following search terms:

  1. 1.

    ontology OR ontologies

  2. 2.

    “software engineering”

  3. 3.

    “requirements” OR “requirements engineering” OR “software analysis” OR “domain analysis”

  4. 4.

    “software architecture” OR “software design” OR “architectural design”

  5. 5.

    “software testing” OR “software verification” OR “software validation” OR “unit testing”

  6. 6.

    “software maintenance” OR “software evolution”

  7. 7.

    “software configuration management”

  8. 8.

    “software quality”

  9. 9.

    “software metric” OR “software measurement”

  10. 10.

    “software process” OR “process model” OR “software process model”

  11. 11.

    “software management”

  12. 12.

    “software reuse”

  13. 13.

    “software modelling” OR “software modelling”

  14. 14.

    “software programming”

  15. 15.

    “software engineering tool” OR “software engineering method”

  16. 16.

    “ontology-driven software”

These search terms for different types of software engineering articles were combined in the following way:

(1 AND 2 AND (3 OR 4 OR 5 OR 6 OR 7 OR 8 OR 9 OR 10 OR 11 OR 12 OR 13 OR 14 OR 15)) OR 16

The definition of these terms was based on three important references: (1) the taxonomies about the use of ontology in Software Engineering presented by Ruiz and Hilera [57]; (2) the survey authored by Gazevic et al. [24] about the use of ontology in software engineering; and (3) the topics within scope of the Information and Software Technology Journal [21], which encourages the conduction and publication of SLRs. Furthermore, as Ruiz and Hilera and Gazevic et al. summarize research about the use of ontology to support software engineering/RE until 2006, our search only considered the period between January 2007 and October 2013, which is an inclusion criterion, as described in Sect. 2.4.

The search results (12,270 papers) were automatic downloaded and were entered into and organized with the aid of StArt tool. Figure 1 depicts the steps of the selection process showing the number of studies in each one these steps. Besides, the two frames on the right side of Fig. 1 presents the exclusion criteria which were exclusively applied to the studies in Steps 4 and 5.

At Step 2, duplicated papers were automatically detected and removed using the StArt tool, remaining a set of 9,764 papers. Then, in Step 3 authors reviewed the titles, keywords and publication local of each paper and excluded those that were not related to the research questions (−8,501). If there was insufficient data, the paper was left for the next assessment. After finishing the Step 3, 1,263 papers remained in the selection process and reviewers analysed, in Step 4, the papers abstracts and excluded those according to 13 exclusion criteria (−687 papers), as indicated on the right side of Fig. 1. If there was insufficient data, the paper was left for the next step.

In Step 5, the complete texts from the papers selected at Step 4 (576 papers) were retrieved, the introduction and conclusion of each paper was read and each paper was full-screened. Papers were excluded according to 15 exclusion criteria (−279 papers), as also indicated in the bottom frame on the right side of Fig. 1.

Until Step 5, any SE paper supported by the use of ontologies was considered to be included in the review. Recall that this is intentional, as we may use the studies identified so far for several researches under development. Hence, the specific exclusion criterion was only applied, in Step 6, to the 297 remaining studies of Step 5, in order to filter the papers exclusively related to RE (the focus of this paper).

After finishing Step 6, 207 papers that do not use ontology in RE—but use ontology in other software engineering subdomains—were excluded from this review, remaining 90 studies. As an additional search, the reference lists of these RE papers were also reviewed in order to identify studies which satisfy the inclusion criteria and led to the inclusion of 1 (one) study, resulting in a total of 91 RE papers to be assessed in the next step.

At last, in Step 7, it was performed a quality assessment in the included papers (91) and those that do not satisfy a minimum quality score were excluded (see next section), remaining a set of 67 papers to be considered in this review.

2.6 Quality assessment

The quality assessment (QA) of selected studies was achieved by a scoring technique to evaluate the credibility, completeness and relevance of the selected studies. All papers were evaluated against a set of 12 quality criteria. Seven of them were adapted from existing study quality assessment criteria used in the literature, the remaining five questions were proposed according to the scope and research questions of this SLR. The assessment instrument used is presented in Table 3. Q1, Q2, Q3, Q5, Q6, Q11 and Q12 were adopted from the literature, while Q4, Q7, Q8, Q9 and Q10 were proposed.

Table 3 Study quality assessment criteria

We relied on SLRs published in a high reputation venue (i.e., Information and Software Technology Journal) in the context of empirical software engineering research to define seven of the quality assessment criteria. In particular, we adapted some of our criteria following the works by Mahdavi–Hezavehi [47] (Q1 and Q6), Dyba and Dingsyr [17] (Q2, Q3, Q6 and Q12), Achimugu et al. [2] (Q5 and Q12) and Ding et al. [15] (Q11).

The scores of questions Q2, Q4, Q8 and Q9 were determined using a two-grade scale score (Yes/No). If the answer was Yes, the study received 1 point in this question; otherwise, it received 0 point. Besides these alternatives, the questions Q1, Q3, Q5, Q6, Q10, Q11 also allowed a third one. If the contribution was not so strong, the study received 0.5 point, consisting in a three-grade scale score to these questions. Q12 receives 1 point if the study is applied in industry and 0.5 point if its setting is academy.

We also want to ascertain the contribution of the selected studies to RE through its coverage. For this, we used the RE process defined by Kotonya and Sommervile [41]. According to the authors, this process is divided in four phases: requirements elicitation, requirements analysis and negotiation, requirements documentation, and requirements validation. Moreover, the authors also emphasize the requirements managementFootnote 8 as an important activity of the RE process. Thus, the score of Q7 was determined through the following proportion:

\(\frac{{\text{Number}}\,{\text{of}}\,{\text{Phases}}}{{\text{Total}}\,{\text{of}}\,{\text{Phases}}}\), where the numerator is the number of RE phases covered by the study and the denominator is the total of phases considered in the RE process (five).

The study quality score is computed by finding the sum of all its scores of the answers to the questions. Each selected paper was assessed independently by the authors. All discrepancies on the scores were discussed among the authors, and the study was reevaluated in cases of non-agreement with the aim of reaching consensus.

2.7 Data extraction and synthesis

After the definition of the search and the selection processes, the data extraction process was performed by reading the introduction and conclusion; and full-text screening each one of the selected papers. In order to guide this data extraction, the data collection from Kitchenham and Charters [39] was adopted. During this stage, data were extracted from each of the 67 primary studies included in this systematic review according to a predefined extraction form (see Table 14 in “Appendix 1”). This form enabled us to record full details of the papers under review and to be specific about how each of them addressed our research questions. As well the selection process, the data extraction was full aided by the StArt tool.

The data were tabulated to show general information about the studies: identifier, authors, year, paper type, application context, research method and quality assessment scores. Furthermore, we also present a bubble chart considering the application context, research method and publication year information of the studies in order to provide a deeper visualization of these information. Additionally, the data regarding each research question were tabulated. The results of RQ2 and RQ7 are also graphically presented using bubble charts. Particularly, in the discussion of RQ7 (Sect. 3.9), we present a deeper analysis of ontologies benefits in RE with the aid of bubble and bar charts.

3 Results and analysis

A total of 67 studies met the inclusion criteria and their data were extracted. Prior to presenting the results and analysis for each research question, we depict the quality assessment results and give a detailed overview of the general characteristics of the studies.

3.1 Quality assessment results

The quality assessment of the selected studies is useful to increase the accuracy of the data extraction results. This evaluation helped to determine the validity of the inferences proffered and in ascertaining the credibility and coherent synthesis of results.

The quality assessment results are showed in Table 4 according to the assessment questions described in Table 3. The scores of all studies are no less than 50%, and the average score is 7.82. We chose the minimum of 50% quality with the aim to establish an acceptable quality threshold for the articles. Regarding the averages of specific quality criteria, Q2, Q1, Q3 and Q4 received the highest average scores (>0.9). Q6, Q10, Q12 and Q8 received, in average, intermediary scores between 0.57 and 0.62. Q7, Q11, Q9 and Q4 criteria received the lowest average scores (≤0.5). It is worth noting that the lowest average score—of Q4, with 0.37—indicates that the great part of the studies is not concerned with reuse of ontologies developed by other authors.

Table 4 List of papers included in the review along with their quality scores

The overall quality of the selected studies is acceptable. Taken together, these 12 criteria provided a measure of the extent to which we could be confident that a particular study’s findings could make a valuable contribution to this review.

3.2 Overview of the studies

In following, we depict general characteristics of the studies included in the review: year of publication, type of source, research method and application context.

3.2.1 Publication year

The reviewed papers were published between 2007 and 2013. From a temporal point of view (Fig. 2), an increasing number of publications in the context of this review is observed since 2007. 2010 (19.4 %) is the year with most publications, followed by 2009 (17.91 %), 2012 (16.42 %), 2011 (14.93 %), 2013 (11.94 %), 2008 (10.45 %) and 2007 (8.96 %).

Fig. 2
figure 2

Temporal view of the studies

Although the apparent increasing of the number of studies on the use of ontologies in RE, it is difficult to point out that there is a trend in such topic. Indeed, we can observe that researchers are currently concerned with the topic, but we can not state that there is some kind of tendency. It is also worth noting that, as the search process of this review was performed in October 2013, a slight decrease in the number of publications would be expected in 2013 because some papers might be in press.

3.2.2 Application context

The study settings were categorized either as an industry or academic context. The majority of the papers (77.6 %; 52 studies) are considered academic. However, it is worth noting that a considerable amount of the studies were conducted in an industrial setting (22.4 %; 15 studies), indicating that, even though the concept of ontology is not widespread within the RE community, its use has also been significantly investigated in industry, as it will be further discussed in Sect. 3.8.

3.2.3 Research method

The classification of publications was based on the categories (controlled experiment, quasi-experiment, case study, survey research, ethnography and action research) defined by Easterbrook et al. [19]. However, we have defined two extra categories: illustrative scenario and not applicable. The first one is appropriate for papers that just evaluate their contributions using small examples. The second one refers to the papers that do not present any kind of research method in the study.

Illustrative scenarios (55.22 %; 37 studies) constitute majority of the studies, followed by controlled experiments (20.19 %; 14 studies), case studies (16.42 %; 11 studies), not applicable (5.97 %; 4 studies) and quasi-experiment (1.49 %; 1 study). There were no survey research, ethnography and action research papers in our classification.

Figure 3 presents a bubbleplot distributed over three dimensions regarding three characteristics of the studies: year of publication, application context and research method. The left part in Fig. 3 denotes the relationship between studies and year of publication. The number in a bubble represents the number of studies on a specific type of research method published in a certain year. Similarly, in the right part of Fig. 3, the number in a bubble represents the number on a specific research method in a certain application context.

Fig. 3
figure 3

Bubble plot with year of publication, application context and research method dimensions

An interesting aspect that we might note in Fig. 3, is that studies are significantly concerned in conducting empirical researches (e.g., case study, quasi-experiment and controlled experiment) on the topic been investigated, i.e., using ontologies in RE, specially in the last five years.

3.2.4 Type of source

The studies included in this review may be of journal, conference, workshop or book chapter publications. The majority of studies are conference papers (56.72 %; 38 studies), followed by journal publications (23.88 %; 16 studies), workshop papers (11.94 %; 8 studies) and book chapter publications (7.46 %; 5 studies).

Table 15 (in “Appendix 2”) presents the distribution of selected studies over publication sources, including the publication name, type, count (i.e.,the number of selected studies from each source), and the percentage of selected studies. The 67 selected studies are distributed over 56 publication sources, suggesting that the use of ontologies in RE have been a widespread concern in the research community. As shown in Table 15, the leading venues in this study topic are APSEC, ER, ER workshops, ENASE, RCIS, ICSC, IJSEKE, Managing Requirements Knowledge (MARK) book and OTM workshops. These venues indicate the presence of sources of software engineering, information systems and artificial intelligence areas.

3.3 RQ1: Phases of RE process supported by ontologies

3.3.1 Results

The purpose of this research question was to identify the main phases of the RE process that have been supported by the use of ontologies. We categorized these phases according to the RE process defined by Kotonya and Sommervile [41]: elicitation, analysis and negotiation, specification, validation and management (see Table 5). The predominant phase that we identified was Specification (83.6 %), followed by Analysis and Negotiation (58.2 %), Management (35.8 %), Elicitation (25.4 %) and Validation (6 %). It is worth noting that a study could have met more than one phase of the RE process, thus the sum of percentages can be greater than 100 %.

3.3.2 Analysis and discussion

In summary, the results shown in Table 5 indicate that all RE phases are covered by the studies. The Specification phase is addressed by more than 80 % of the studies. In fact, to some extent, this result was expected, since ontologies may be used as means to formally specify RE artefacts and activities. Analysis and Negotiation phase also encompasses a great number of the studies (more than 50 %). This result is also interesting because it shows that a great part of the studies relied on ontologies to perform some formal requirements analysis, taking advantage of reasoning capabilities provided by ontologies. Furthermore, 26 studies (almost 40 % of papers included) met both Specification and Analysis and Negotiation phases in the same paper, indicating the interest of using ontology not only to specify some RE artefact or activity but also to conduct some analysis or reasoning.

Table 5 Use of ontologies in RE phases

The Management phase is also significantly representative in the included studies. This result was somewhat expected, since ontologies aim to provide explicit conceptualization within a domain knowledge (e.g., requirements knowledge) and allows to automatic reason in such knowledge, thus been potentially useful in the proper management of different kinds of requirements changes.

There is also an interest in the use of ontologies in the Elicitation phase aiming to provide some guidance to requirements elicitation realization. For instance, by representing domain knowledge with the aid of ontologies in order to guide the elicitation activity. It is worth noting that most of the papers which met Elicitation phase also addressed Specification phase, except for S03 and S28.

On the other hand, the use of ontologies in the Validation phase is not significant (6 %; four studies). This result may also indicate that the RE researches are less concerned with the research in requirements validation in comparison with other RE research aspects and, hence, also in the use of ontologies in such phase.

Among all 67 studies, only two papers (S01 and S02) addresses all phases of RE process and only two studies met at least four phases of RE process (S50 and S61). In view of the potentials of using ontologies in many phases of RE (as shown in Table 5), this results suggest that the use of ontologies to support the entire RE process needs to be further investigated (see Sect. 4.4).

3.4 RQ2: Software requirements modelling styles

3.4.1 Results

The purpose of this research question was to identify the types of software requirements modelling styles used together with ontologies. The classification of the styles was made after the data extraction of the studies, i.e., during the extraction, plain text data about the software requirements modelling styles used in the study was captured. Next, in the syntheses step of this review, the categories presented in Table 6 were defined according to the distribution of the studies.

Table 6 Software requirements modelling styles

Figure 4 depicts the number of studies considering the requirements modelling styles over the RE phases. Note that, the sum of the numbers of studies on specific phases or styles exceeds the total number of studies within a specific category, because one study can use several requirements modelling styles and a study could also have addressed several RE phases.

Fig. 4
figure 4

Requirements modelling styles over RE phases

As shown in Table 6, the predominant style that we identified was Textual requirements (49.3 %; 33 studies), followed by UML (23.9 %; 16 studies), Scenario-based (19.4 %; 13 studies) and Goal-oriented (17.9 %; 12 studies). Features models category has 6.0% (4 studies), followed by Non-specific (4.5 %; 3 studies), Formal language (3.0 %; 2 studies), Aspects and Problem frames, each one with 1.5 % (1 study).

3.4.2 Analysis and discussion

The results of this research question show that we identified a great variety of software requirements modelling styles which are been supported in some extent by ontologies.

Textual requirements category is the most frequent type of RE modelling style addressed by the studies; this category included studies on all RE phases, but the majority of studies are concerned with requirements specification, analysis of textual requirements and management of requirements, as can be seen in Fig. 4. It also encompasses studies that specify requirements documents using a requirements document template (e.g., Software Requirements Specification—SRS). The studies identified in this category frequently involve the use of artificial intelligence techniques, for instance, Information Retrieval (IR), Machine Learning (ML) and Natural Language Processing (NLP).

The UML category encompasses studies that use ontology to support the modelling of, for instance, use case models (S07, S14, S22, S44 and S53), activity models (S14, S27, S30, S31 and S43), sequence diagrams (S18, S27 and S31), statecharts models (S23, S27 and S31) and class diagrams (S14, S18 and S54). Furthermore, this category includes studies which address the use of ontologies in four RE phases (see Fig. 4), with an emphasis on specification and analysis phases.

Scenario-based category is also expressive in the studies, it encompasses 13 papers and includes requirements styles such as use case diagrams, misuse cases models (e.g., S18)—for security-specific modelling—and ScenarioML models (e.g., S15). The studies within this category were used in all five RE phases, but with greater frequencies in specification and analysis phases.

Goal-oriented models category also contains 12 studies and includes papers which use, for instance, the i* framework (e.g., S07, S18, S20, S24, S62 and S65), the KAOS approach (e.g., S50) and the NFR framework (e.g., S45). The studies within this category addressed, in total, all five RE phases, but with more frequency in the elicitation, analysis and specification phases.

Feature models category is represented by four studies, using ontologies in the context of software reuse (e.g., software product lines). These studies may include the specification, analysis and management of feature models, as shown in Fig. 4. Non-specific category includes the studies where we could not identify any specific requirements modelling style. Business process models Footnote 9 were also addressed by the use of ontologies in two studies which use it in conjunction with use cases in analysis and management of requirements. The use of ontologies also appeared in the included studies along with Formal languages (e.g., Z language and EB3), using ontologies to support specification and management of requirements. Lastly, Aspects and Problem frames modelling styles were also identified within the studies, but with a single study in each category in order to specify and analyse requirements by the use of ontologies.

In summary, we can note that there is a great diversity of RE modelling styles associated with the use of ontologies. We identified ten modelling styles, in which four of them, i.e., the top four frequent studies, are more expressively addressed by the use of ontologies. By contrast, the last categories (non-including the Non-specific category) were much less satisfied by the included studies. Additionally, as presented in Fig. 4, the specification phase was addressed by almost all modelling styles, except for Business process models category. Similarly, the analysis phase was met by almost all styles, except for Formal languages. The management phase was also addressed by the great majority of modelling styles, except for Aspects and Problem Frames. The elicitation phase was only met by the top four styles, especially by the Textual requirements and Goal-oriented styles. Note that, the validation phase was much less met by the studies (as already discussed in Sect. 3.3), only the Textual Requirements, Scenario-based and Goal-oriented styles addressed such phase.

It is well known in the RE community that natural language requirements are much more prone to inconsistencies and ambiguities. However, even though such fact, the Textual Requirements style is the most frequent one used along with ontologies. We may speculate a reason for it. This style is much more used in the Specification phase (see Fig. 4); thus, we can note (Table 6) that the great part of the studies relied exclusively on the capabilities of ontologies to specify requirements, without needing to use a well-defined requirements style. Anyway, this result must be further investigated. In Sect. 4.4, we present some research directions on this topic.

3.5 RQ3: Use of ontologies to describe functional and non-functional requirements

3.5.1 Results

The purpose of this research question was to identify how the use of ontologies is distributed concerning the type of requirement, i.e., functional or non-functional. Thus, we created three categories: (1) functional requirements; (2) non-functional requirements (NFRs); and (3) both types. Table 7 presents the distribution of the studies within these categories.

Table 7 Functional and non-functional requirements distribution

As seen in Table 7, nearly half of the studies only deal with functional requirements (52.24 %), followed by the studies which deal with both functional and non-functional requirements (44.78 %) and by the studies which only consider non-functional requirement (2.99 %).

3.5.2 Analysis and discussion

The results presented in Table 7 indicate that, in general, functional and non-functional requirements are addressed by the studies. As expected, the great majority of the papers addressed functional requirements (almost 97 %). It is also worth noting that a great number of studies (44.78 %) consider both functional and non-functional requirements (in the same study) on the use of ontologies, showing their concern with a more complete requirements specification. However, 55.23 % of the studies only address one type of requirement, in which 2.99 % are of NFR type.

In fact, even though the considerable amount of papers addressing both types of requirements, the results suggest that the use of ontologies along with non-functional requirements is still underexplored. It is well known that improving NFRs activities contributes to the success development of software systems, leading to software with better quality. Thus, in Sect. 4.4, we present an open question on this topic that might be further investigated.

3.6 RQ4: Existing contributions in ontology-driven RE

3.6.1 RQ4: Results

The purpose of this research question was to identify the existing approaches in ontology-driven RE. The classification of such approaches was based on the analysis of RE problems addressed by the studies. The main RE problems that were identified are depicted in Table 8. The majority of studies addressed the ambiguity, inconsistency and/or incompleteness requirements problem (56.72 %; 38 studies), followed by the requirements management or evolution problem (35.82 %; 24 studies), domain knowledge representation (26.87 %; 18 studies), integration between requirements and software architecture (4.48 %; three studies). The requirements communication, requirements interoperability, distributed requirements elicitation and goal decomposition problems equally appear with two studies (2.99 %). The goal decomposition (related to Goal-oriented approaches) and selection of elicitation techniques categories are equally represented by 1 study (1.49 %) each. Note that a study could have met more than one RE problem.

Table 8 Existing contributions in ontology-driven RE

In sequel, we briefly depict the objective of each one of the studies within the categories identified in this research question. These RE problems are discussed in RQ7 (Sect. 3.9) along with a discussion about the empirical and non-empirical benefits of using ontologies in RE problems.

  • P1: Ambiguity, inconsistency and/or incompleteness

As shown in Table 8, this RE problem includes 37 studies which are discussed in the sequel.

S02 proposes an unified Goal-oriented RE (GORE) process, based on a GORE ontology. Such process aims to standardize roles, activities, artefacts and their relationships. This study also addresses the requirements management problem. S04 presents the MUPRET framework (Multiperspective Requirements Traceability) which deploys ontology as a knowledge management (P2) mechanism to intervene mutual understanding without restricting the freedom in expressing requirements differently. S05 proposed a Semantic Web-oriented language, called Semantic Annotations for Feature Modelling Description Language that provides the means to semantically describe feature models. This framework uses ontology to provide a standard terminology (i.e., a shared conceptualization) of feature models.

S07 proposes a conceptual ontology-driven approach to reduce the heterogeneities between user requirements formalisms, i.e., specifying a common terminology and also to facilitate the interoperability (P6). S08 describes a methodology for requirements specification that aims to produce models for functional requirements that can be automatically validated for completeness and consistency. This methodology is part of the Requirements Driven Design Automation framework (RDDA). The contribution of the S09 paper is an ontology-based approach for defining a good Software Requirement Specification (SRS). The main component of this approach is an ontology for conceptualizing the SRS called OntoSRS whose main objective is to guide stakeholders in the definition of a SRS with the following properties: consistency, unambiguity, correctness, organization and traceability. By contrast, the goal of the S10 work is to integrate (defining a common terminology) AOSD concepts, classic RE notions, and the new standard ISO/IEC 25030 on software quality requirements. The main result of this study is the REASQ (REquirements, Aspects and Software Quality) conceptual model, expressed in UML.

The S12 paper proposes a tool-based framework that is capable of supporting the security requirements specification process. The aim of such study is to assist the requirements engineer in the process of security specifications so that their quality can be enhanced and the effort reduced. S13 presents an approach for hazard identification (HazId) based on requirements and reuse-oriented safety analysis. The approach offers a starting point for the identification of potential system safety concerns from the RE phase of development, to facilitate communication of requirements (P5) and also to manage such requirements (P2). S16 presents a checking method of elicited software requirements using requirements ontology. In the S17 paper, the authors use a requirements ontology as domain knowledge (addressing the P3 problem) for requirements elicitation. They introduce a checking method using requirements ontology to detect errors in requirements. S18 proposes a vulnerability-centric modelling ontology, which aims to integrate empirical knowledge of vulnerabilities into the system development process.

S19 presents the prototype of a semantic guidance system used to assist requirements engineers with capturing requirements using a semi-formal representation. The semantic guidance system uses concepts, relations and axioms of a domain ontology to provide a list of suggestions; the requirements engineer can build on to define requirements. Such study addresses the P1, P2 and P3 problems. The S21 paper outlines a stepwise methodology to discover and understand the multidimensional correlations among regulatory security requirements and relies on a RE framework to explain regulatory requirements and related domain concepts from natural language documents and represent them using ontological domain modelling techniques. The resulting Problem Domain Ontology (PDO) establishes the semantics of each requirement through its relationships with domain concepts in a socio-technical environment. S22 developed a Knowledge-assisted Ontology-based Requirements Evolution (K-RE) method and tool which combine the social software principles and semantic web concepts to enable a knowledge-assisted RE (also addressing the P2 problem).

S24 proposes the use of UFO (Unified Foundational Ontology) to provide an ontological foundation to the i* framework. In such paper, one particular construct, means-end links, is taken as subject of research. The S25 paper presents an approach to deal with inconsistencies in feature models (FM) evolution scenarios reducing the impact of change to the smallest part of an FM that changes. Such study formalizes FMs from an ontological perspective and define constraints that must be satisfied in FMs to be consistent. S27 introduces a method of ontology-based semantic verification of UML behavioural models. The S30 paper proposes a hybrid method which aims to detect behavioural requirement interactions in order to improve the quality of software system. The proposed method includes two main parts: an ontological modelling process for requirement specification and a set of conflict detection rules derived from behavioural analysis.

The aim of the S31 paper is to develop an ontology that diminishes the complexity, difficulty and ambiguity of understanding the different concepts of modelling notations used in software RE. S32 uses the concept of projection from relational algebra and combines it with concepts from the problem frames (PF) and scenario-based approaches to present a conceptual model for conducting problem projection in RE. S37 introduces means of requirements validation, extracting domain-specific abstractions (also addressing P3 problem) and relationships between requirements from documents which are assembled into an ontology that acts as a conceptual model of the problem domain. Then, such descriptions are taken, in the form of scenarios or use case descriptions, and used to construct a set of Message Sequence Charts (MSCs). The S39 paper designed and implemented an approach as an ontology-based component in a requirements specification tool, named TESSI, that helps an analyst to write a UML model and, hence, to improve it and to reduce misunderstandings.

In the S40 paper, an ontology-based framework for representing, storing and reusing security requirements is presented. This framework combines a risk analysis ontology, based on methods of risk analysis and security standards, and a requirements ontology. By contrast, the objective of S42 is to propose the use of a basic ontology based on the artefacts to standardize and manage (also addressing P2) software requirements that can be used on any project developed in any organization. The S43 paper presents the CDADE tool, which can help designers to detect conflicts in activity diagram evolution (also addressing P2 problem). The CDADE tool is composed of ontologies, metadata, and conflict detection rules. S45 proposes to address fragment identification as a problem best served with interactive aids and presents a faceted exploration approach to explore NFR solutions and identify reusable model fragments where NFRs and trade-offs are represented as ontologies. Such paper is also concerned with the integration between requirements and software architecture (P4).

In the S47 paper, its proposed the OntRep, an automated ontology-based reporting approach for requirements categorization, conflict analysis and tracing (P2) based on ontologies and semantic reasoning mechanisms. The S48 paper introduces an approach to systematically extract knowledge from system requirements to construct different views of ontologies for the system as a part of a comprehensive framework to analyse and validate software requirements and design. Such study also addresses the requirements management problem (P2). S49 proposes a multi-representation ontology to solve conflicts and problems of the multi-context requirements specification. Such study also uses ontologies for domain knowledge representation (P3). The S50 paper proposes a goal-directed RE process, named KBRE model, that centralizes domain knowledge and semantics of requirements. Using such model, requirements can be elicited, elaborated, and inconsistencies and other related requirements problems can be detected.

The S55 paper proposes a method for simplifying ambiguity of requirement specification documents through two concepts of ontology-based probabilistic text processing: Text classification and Text Filtering. Such study also address the P2 problem. S56 proposes an automated analysis of SRS (Software Requirements Specification) documents for different NFR types and contains two significant contributions towards this goal: a corpus containing annotations for different NFR types, based on a requirements ontology and a support vector machine (SVM) classifier to automatically categorize requirements sentences into different ontology classes. In the S57 paper, a framework for classifying external variability types based on ontological principles is introduced. The framework defines the external view of software in terms of the behaviour of the application domain. Behaviour is formalized as state changes in response to external stimuli.

The S63 paper presents an approach for modelling and verifying feature diagrams using Semantic Web OWL ontologies. In the S65 paper, the authors argue that a social ontology at the core of a RE process can be the basis for integrating security into a requirements driven software engineering process. For this, they describe the i* framework and show how it can be used to model and reason about security concerns and responses. Similarly to other studies in the P1 category, the S66 paper also proposes to represent a requirement specification through a requirement ontology that is described by Description Logics. Last but not least, S67 suggests a formal approach to precisely describe ontology using Description Logics, and then model the integrity rules and derivation rules which restrict the business behaviour. This study also met the P3 problem.

  • P2: Requirements management/evolution

This RE problem includes 24 studies which are described hereafter.

In the S01 paper, a quality-driven RE framework and a tool that applies knowledge management techniques and quality ontologies to support RE activities are presented. The ontology implements the quality characteristics and metrics prescribed by the ISO/9126 quality model, providing a common vocabulary to address quality concerns/aspects across RE activities. The S02 also addresses the requirements management problem through the proposal of an unified GORE process, as it was explained in the previous section. In the S04 paper, the MUPRET framework explained in P1, is used to trace requirements, i.e., been useful to manage requirements. S06 presents an approach for manipulation of data involved in the SW-FMEA (Software—Failure Modes and Effects Analysis) process, introducing an ontological model which formalizes concepts involved in the analysis.

In the S08 paper, the RDDA framework (explained in the previous section) is to used to manage the consistency of requirements. S11 address the difficulty for end-users in finding documentation related to software requirements. Thus, an architecture is proposed for enhanced resources search, combining the strengths of the social (social annotations) and semantic (semantic metadata) technologies. The S13 paper, as already explained in P1, proposes an approach to manage requirements related to security requirements. S14 developed a software development process support tool, using ontologies, to promote the discovery of software artefacts relationships, mixing the knowledge offered by the business ontology and the software engineering ontology.

The S19 paper, as already explained in the previous section, assists the management of requirements by the use of a semantic guidance system. Also explained in previous section, the S22 paper uses the knowledge-assisted ontology-based requirements evolution (K-RE) method and tool to address requirements management. S26 specifies the domain knowledge as ontologies (also meeting P3) capturing concepts and relations of the problem domains. Such study uses these ontologies to detect code fragments corresponding to the requirements sentences, providing traceability between requirements and code. The goals of S29 paper are: to recover high-level artefacts such as requirements and design models; to simplify modification of those models; to reuse software design and domain knowledge contained within models; and to integrate those models with enhancements via a novel combination of ontological and model weaving concepts.

The S34 paper presents a conceptualization of a requirement management system. The system (referenced as the CARM—Computer Aided Requirements Management framework) makes use of semantic networks by expressing requirements through ontologies. In the S35 paper, the authors extend previous work on NFR ontology by proposing a change management mechanism for tracing the impact of NFRs on the other constructs in the ontology such as FR or NFR operationalization and vice versa, and providing a traceability mechanism. The S38 paper applies the ontology-driven RE methodology (OntoREM) to a case study within the aerospace context in order to evaluate the potential of such ontology-driven approach in knowledge-driven RE.

As explained in the previous section, the S42 paper uses a basic RE ontology that can be used to manage requirements in an organization. The S43 paper, as also previously explained, uses the CDADE tool, to detect conflicts in activity diagram management/evolution. S44 study proposes an ontology-based blog to detect and to manage the conflicts using extended use case models between change requests and the existing system requirements. In the S46 paper, the Infrastructure for semantic document management (ISDM) is used to support requirements evolution.

The OntRep, proposed in the S47 paper and already explained in previous section, also aims at lowering the effort for requirements management, while keeping high requirements consistency by using ontologies. The S51 paper aids the NFR requirements management by allowing to define metrics for quality attributes as ontologies, to specify execution qualities as profiles according to a quality variability model and ontologies, and to model quality properties as an integrated part of software architecture. Such study also relates requirements and software architecture (P4). In the S54 work, the authors propose the use of an iterative and incremental model-driven RE process (maintaining traceability of models) combined with the employment of different notations such as controlled natural language and ontology in several activities of RE process.

In the S60 research, the authors focus on assessing non-functional quality requirements, specifically evolvability, through semantic modelling of relevant software artefacts and introduce the SE-Advisor that supports the integration of knowledge resources typically found in software ecosystems by providing a unified ontological representation. Finally, in the S64 paper, a methodology with tool support is proposed, aiming to manage requirements, for automatically deriving ontological metadata from formal software models and semantically describe them.

  • P3: Domain knowledge representation

As shown in Table 8, this RE problem includes 18 studies which are described hereafter.

As previously explained, the S17 paper uses a requirements ontology as domain knowledge to aid requirements elicitation. Similarly, the S19 paper—also explained in P1—uses concepts, relations and axioms of a domain ontology to provide a list of suggestions the requirements engineer can build on to define requirements. In the S20 paper, a mechanism which integrates domain knowledge in domain-independent RE languages is proposed.

The S26 paper proposes a technique for recovering the links using domain ontologies and uses such knowledge to manage requirements, as already explained. The S29 paper, which also addresses the P1 problem, reuse software design and domain knowledge contained within models via combination of ontological and model weaving concepts. S33 proposes a method and a tool to enhance an ontology of domain knowledge for requirements elicitation by using Web mining. Similarly, the S36 paper proposes the usage of a domain ontology as domain knowledge during the requirements elicitation process and a supporting tool based on this technique.

The S37 paper, as explained above, uses domain-specific abstractions and relationships between them extracted from a document or documents that are representative of the application domain that are assembled in ontologies. In the S41 paper, the authors propose an ontology-based approach for requirement elicitation in process centred problem domain. In this method, based on upper level requirement representation ontology, the study merges the ontology acquiring process and the requirement elicitation process together. The S49 paper, which addresses the P1 problem, makes use of a multi-representation domain ontologies.

In the S50 paper, domain knowledge is represented by the use of ontologies in a goal-directed RE process, as described in P2. The S52 work also investigates an approach for building domain ontologies suitable for guiding requirements elicitation. S53 proposes to analyse use cases by means of natural language processing (NLP) and rules can be defined for validating use cases against a given domain ontology. In the S59 study, a method for goal-oriented security requirements analysis using security domain knowledge ontologies which is derived from several security targets compliant to common criteria is presented. Such study also uses ontologies to support goal decomposition, i.e., the P8 problem. In a similar way, the S61 paper proposes a method called GOORE where a domain knowledge ontology is utilized to support goal decomposition.

The S62 proposes a method that exploits security and domain ontologies dynamically through a collection of heuristic production rules. In the S64 paper, a methodology is proposed to automatically derive domain ontological metadata from formal software models and semantically describe them, which is also used for requirements management, as explained previously. The S67 paper suggests an approach to describe domain ontology to be used for consistency checking, as explained in the P1 section.

  • P4: Integration between requirements and architecture

This kind of RE problem was addressed by three studies, two of them were already explained, S45 and S51, which met, respectively, the P1 problem and P2 problem. S45 presents an ontology-based search approach to identify valuable NFR knowledge fragments. The search outputs can be organized by valuable knowledge fragments. Architects can choose which kind of classification criteria and knowledge fragments they are interested in. S51 allows to define metrics for quality attributes as ontologies, to specify execution qualities as quality profiles according to a variability model and ontologies, and to model quality properties as an integrated part of software architecture. By contrast, the S15 paper proposes an approach that maps domain events, classes, and individuals used in requirements scenarios (described using ScenarioML) to architectural components (described using xADL).

  • P5: Requirements communication

This RE problem category was met by two studies: S13 and S54. Both studies were explained previously, whereas S13 addresses the P1 and P2 RE problems and the S54 work meet the P2 problem. Particularly, the approach proposed in S13 captures the knowledge contained in both the requirements document and previously documented HazOp projects in order to attain a reduction in the cost of safety analysis by using established technologies such as ontology, case-based reasoning and natural language processing. The S54 also adopts ontologies and controlled natural language to aid activities of knowledge acquisition and knowledge representation. It provides a notation close to the client native language, which is fully understandable by both requirements engineer and client, thus facilitating the comprehension of and validation of the requirements specification.

  • P6: Requirements models interoperability

This RE problem category was met by two studies: S07 and S23. The S07 proposes a conceptual ontology-driven approach to facilitate interoperability and to reduce the heterogeneities between user requirements formalisms. It uses a pivot model allowing the integration of different semi-formal models. This work also addresses the P1 problem. In the S23 paper, the authors use OWL to represent statechart models which must be interoperated with other statechart models.

  • P7: Distributed requirements elicitation

This category is represented by the S03 and S29 studies. S03 proposes an ontology-based framework for global requirements elicitation aiming to reduce misunderstandings among stakeholders, and therefore helps to achieve more committed requirements. Conversely, the S58 paper presents a classification of Wiki-based approaches to RE and introduces the ontology of an approach that aims at supporting the collaboration of stakeholders in order to enable large stakeholder groups to elicit, semantically structure and classify requirements.

  • P8: Goal decomposition

This category was addressed by two studies: S59 and S61. Both studies also met the P3 problem and were explained in the P3 section. The S59 paper uses ontology to suppport goal decomposition in the context of goal-oriented security requirements analysis. The S61 proposes the GOORE method which is also used to support goal decomposition.

  • P9: Selection of elicitation technique

This RE problem category is only met by the S28 study. This study developed an ontology and explored how well it supports requirements elicitation and elicitation techniques selection.

3.6.2 RQ4.1: Types of contributions results

The purpose of this research question was to identify the types of existing contributions which were explained above. The classification of such approaches was based on the work by Petersen et al. [55] and includes the method, model, tool and process categories (see Table 9). We only consider as process contributions, papers that use ontology in all five RE phases (elicitation, analysis and negotiation, specification, validation and management). Whereas the method contributions include the papers that presented some ontology-based approach. Note that, similarly to other research questions, this question also allows a study to be included in more than one category. The predominant contribution that we identified was Method (88.1 %; 59 studies), followed by Model (76.1 %; 51 studies), Tool (56.7 %; 38 studies) and Process (3.0 %; 2 studies).

Table 9 Type of contributions on ontology-driven RE

3.6.3 RQ4.1: Analysis and discussion

The results shown in Table 9 indicate that the four types of contributions considered in this research question are contemplated by the studies. Different kinds of Method contributions of using ontologies in some RE activity are proposed by more than 80 % of the studies. A Model contribution is proposed by more than 75 % of the studies, showing that the great majority of studies model some RE activity by the use of ontologies. Furthermore, 56.7 % of the studies provide some kind of Tool support for their contributions; this finding was somewhat positively surprising since it demonstrates the concern of studies with the automatization of their contributions and also to be effectively used by potential users. Only two studies (S01 e S02) presented Process contributions, this information is complementary to the fact that only the same studies met all phases of RE process, as stated in RQ1 (see Sect. 3.3).

It is worth highlighting that 29 studies propose in the same paper the three main types of contribution: model, method and tool; it indicates that these studies use ontologies to model some RE aspect and to also perform some manipulation in such model aided by a tool support. Moreover, the S01 paper proposes in the same study a model, a process and a tool to meet the entire RE process.

3.7 RQ5: Ontology-related languages used in RE

3.7.1 Results

The purpose of this research question was to identify the main ontology-related languages that have been used to support RE activities. The initial set of categories was defined according to the semantic web technology recommendations of the World Wide Web Consortium (W3C) [61] (e.g., OWL, XML, RDF, SPARQL and so on). However, during the data extraction of the studies, others languages were found and inserted as categories to help to answer this research question. The distribution of studies within these categories is presented in Table 10.

Table 10 Ontology-related languages

OWL (Web Ontology Language) is used by the majority of studies (49.3 %; 33 studies) in the included papers, followed by SPARQL query language (10.4 %; 7 studies), Description Logics (7.5%; 5 studies) and SWRL rule language (4.5 %; 3 studies). RDF, Foundational Ontology and UML Footnote 10 have, each one, two studies (3 %). Whereas, XML, XSPARQL, First-order Logic and Relational model-based categories have 1 study (1.5 %) each one. We encountered also papers where we could not identify a specific ontology-related language (37.3 %; 25 studies) or they did not use any language (i.e., propose some kind of taxonomy), the so-called Non-specific category. They were, however, included in the review as they provided data points relevant to the other research questions. Note that, in this research question, a study could also have used more than one ontology language.

3.7.2 Analysis and discussion

The results of this research question are analysed and discussed from the viewpoint of adopting the languages to specify and handle ontologies recommended by the consortium that administers the Web (W3C). Among the categories used to classify the studies (see Table 10), OWL, SPARQL, XSPARQL, SWRL, RDF, XML are recommended by the stack of web semantic technologies of the W3C, whereas Description logics, Foundational ontology, UML, First-order logic and Relational model-based are not. The Non-specific category is also inserted as a not recommended technology, since each paper classified in this category used arbitrary ways to handle ontologies within the study.

Concerning the use of W3C recommended technologies, it can be observed that 34 studies used one or more of these recommended languages. By contrast, 35 studies used at least one non-recommended language. It is worth noting that two studies (S27 and S50) used languages of both categories, i.e., used languages of the W3C recommended languages and one language of the set of non-recommended categories in the same study. Specifically, S27 used OWL and SWRL together with Description logics and S50 used OWL also together with Description logics.

It can be noted that there is a great concern in the studies to use W3C recommended languages to specify and manipulate ontologies. However, we stress that although OWL is the most expressive and broadly accepted ontology language, it was only used by almost half of the included studies in this review. Thus, one can state that many studies which propose to use ontologies in RE process are not following the proper guidelines and standard technologies to specify and handle formal ontologies.

3.8 RQ6: Reuse of ontologies

3.8.1 Results

The purpose of this research question was to identify the studies which reused ontologies developed in others studies in the context of RE. The distribution of studies within these categories is presented in Table 11. It is worth noting that the answer to this question was also considered as a quality criterion (see Sect. 3.1).

Table 11 Reuse of ontologies

As shown in Table 11, the great part of the studies (66 %; 44 papers) did not reuse any ontologies, i.e., they specified their own ontology. By contrast, several papers (34 %; 23 studies) reused ontologies in their contributions. In the following, we depict the ontologies which were reused by the studies (within the Yes category).

3.8.2 Analysis and discussion

A wide variety of ontologies is reused by the 23 studies identified in Table 11. We grouped these ontologies according to their purposes (Table 12).

We identified six studies which reuse generic requirements engineering ontologies, i.e., which represent general aspects within RE. The S04 study reuses the ontology for RE and software development [5]. S29 uses the Ontology for Software Specification and Design (OSSD) [33]. S39 uses the ontology of requirements [36]. The S46 study reuses the Software Requirements Ontology [22]. S58 uses the SWORE (SoftWiki Ontology for RE) [42] and S66 reused the requirements ontology proposed by [1].

Furthermore, five studies used domain knowledge ontologies for RE purposes. In the S21 paper, the Problem Domain Ontology (PDO) [44] is reused. S33 and S36 uses the ORE (Ontology-based Requirements Elicitation) [37]. The S39 paper reuses the domain ontology (besides reusing an ontology of requirements) proposed by [36] and S59 reuses the Security Ontology in an Application Domain (SOAD) [59].

Four of the twenty-three studies reuse some type of foundational ontology within their contribution. In the S24 paper, the UFO ontology [29] is reused. Besides reusing a generic ontology, the S29 paper also uses the Standard Upper Merged Ontology (SUMO) [50]. The S62 paper reuses an upper ontology proposed in [7] and, lastly, the S57 paper reuses the Bunge’s ontology [62].

In addition to these groups, two studies focused on the reuse of security ontologies: S06 and S59. The first reuses the ontology specified in [16] and the last reuses the SOAD ontology [59]. By contrast, one single study reused a functional requirements ontology, S16. Such paper reuses the functional requirements ontology for an Education Management System (EMS) [18].

Moreover, S02 reuses the Goal-oriented requirements engineering (GORE) ontology [4]. S11 reuses open educational resources (OER)-CC ontology [56]. S14 reuses the Business ontology [8]. S32 reuses the scenario-extended problem ontology [11]. In the S35 paper, the NFRs ontology [38] is reused. The S38 paper reuses the ontology-driven RE methodology (OntoREM) [40]. S43 reuses the speech act ontology [45]. Finally, S45 reuses the design rationale (NDR) ontology [46].

Table 12 Groups of ontologies reused

3.9 RQ7: Ontologies benefits to the RE process

In order to answer this research question, we firstly synthesize (Sect. 3.9.1) and analyse (Sect. 3.9.2) the research method of the studies along with the studies’ indication of positive or negative results of the use of ontologies. Then, we discuss the empirical and non-empirical benefits (Sect. 3.9.3) identified in this review.

3.9.1 Results

The purpose of this research question was to gather and classify evidences to state how the use of ontologies benefits requirements engineering. The classification of the studies was defined according to the presence or absence of empirical evaluation in the study and by the positive or negative indication that using ontologies benefits RE activities. The defined categories are as follows: positive with empirical evaluation, positive without empirical evaluation, negative with empirical evaluation and negative without empirical evaluation (see Table 13). No study was included in the Negative without empirical evaluation category.

Table 13 Evidences of ontologies benefits to the RE process

Positive without empirical evaluation (61.2 %; 41 studies) constitutes majority of the studies, i.e., studies that did not empirically evaluated their contributions. This category is followed by Positive with empirical evaluation (37.3 %; 25 studies) and Negative with empirical evaluation (1.5 %; 1 study).

3.9.2 Analysis and discussion

The results of this research question are of outmost importance to verify whether there are evidences to state that the use of ontologies effectively benefits RE process. These results show that the majority of the studies provide only a positive argumentation about the benefits of the use of ontology in the RE process, i.e., they did not present any empirical evidence, but rather presented some line of argumentation and/or illustrated their contributions using small examples. However, there was a significant amount of studies that presented empirical evidences of such benefits. In the following, we analyse and discuss these specific studies from two dimensions: (1) type of empirical evidence, determined by the research method used in the study and (2) context on which the study was conducted, academic or industry.

As shown in Table 13, most of these empirical studies used controlled experiments (14 papers), followed by case studies (11 papers) and a quasi-experiment (1 study). Moreover, looking up in the studies which performed controlled experiments, we can observe that 3 of them (S13, S22 and S52) reported evidences from industry, whereas 10 studies report evidences from an academic context. By analysing the empirical evidences through the use of case studies, it can be observed that six studies are from industry and five studies academic. The quasi-experiment study was also conducted in industry settings.

The empirical studies can also be analysed over the RE phases that they met. Figure 5 presents a bubbleplot chart distributed over three dimensions: study settings, research method and RE phases. The left part in Fig. 5 denotes the relationship between empirical studies’ settings and the phase that they met. The number in a bubble represents the number of studies on a specific setting addressing a certain phase. By contrast, the right part of Fig. 5 denotes the relationship between studies’ research methods and RE phases. The number in a bubble represents the number of studies on a specific empirical research method in a certain RE phase. Note that, the sum of the numbers of studies on a specific research method or settings category exceeds the total number of studies within a specific category, because a same study could meet more than one RE phase.

Fig. 5
figure 5

Research method and context of empirical studies over RE phases

By analysing Fig. 5, we can draw some important information about the empirical studies identified in this review: (1) the elicitation phase is only and equally addressed by case studies and controlled experiments, with more emphasis on academic studies; (2) the analysis phase is slightly more addressed by case studies than by controlled experiments and is not met by quasi-experiment studies. Moreover, the majority of studies within this phase are academic; (3) the specification phase is the top addressed phase by empirical studies, with a greater contribution from controlled experiment studies than from case studies papers, no quasi-experiment studies met this phase. In addition, the settings of the papers in this phase are in great part academic, but with significant presence of industrial papers; (4) the validation phase is only addressed by two academic case studies; and (5) the majority of studies in management phase are case studies, followed by controlled experiments and a single quasi-experiment study. Furthermore, the great part of studies was conducted in industrial settings.

On the other hand, it was found only one study that presented negative results about the use of ontologies in RE. S03 proposed a framework for global requirements elicitation (P7 problem; RQ4) in the context of Global Software development (GSD). However, after the conduction of a controlled experiment, the results did not present a significant increase in the quality of elicited requirements by the use of ontologies in comparison with other approaches without the use of ontology. These results did not coincide with the paper author’s expectations which may have been caused by the planning and conduction of the experiment, as explained by the authors.

In the following subsection, we analyse and discuss the main benefits, according to the RE problems explained in Sect. 3.6, that are been supported by the use of ontologies in the empirical and non-empirical studies included in this review.

3.9.3 Empirical and non-empirical benefits

Positive results reported in the studies are classified according to the research method that was conducted in the study. Figure 6 illustrates the empirical benefits (i.e., the results presented by the studies which used some empirical evaluation) and the non-empirical benefits, i.e., the results reported by the studies which did not conduct any empirical evaluation in the study.

Figure 6 presents the group of benefits which were categorized according to the RE problems categories presented in Sect. 3.6. Analysing Fig. 6, we can note that the “Reduce ambiguity, inconsistency and/or incompleteness” (B1), “Aid requirements management” (B2), “Domain knowledge representation for guiding requirements elicitation” (B3), “Facilitate requirements communication” (B5) and “Support goal decomposition” (B8) are the empirical benefits that we identified. By contrast, the non-empirical benefits include these benefits (except for B5) and also encompass the “Integration between requirements and software architecture” (B4), “Distributed requirements elicitation” (B7) and “Aid selection of elicitation technique” (B9). In the cases where the benefit is reported by both empirical and non-empirical studies (e.g., B1, B2, B3 and B8), the distribution of the studies is very similar; the more expressive difference appears in the B1 benefit which contains 24 non-empirical studies and 14 empirical studies. Note that, such benefit is reported by the majority of studies, followed by B2, B3, B4, B5, B6, B8, B7 and B9.

Fig. 6
figure 6

Empirical and non-empirical benefits of using ontologies in RE

Concerning the empirical studies—which, in fact, characterize evidences that the use of ontologies benefits RE—we identified five groups: B1, B2, B3, B5 and B8. The first group refers to the studies S04, S12, S13, S16, S21, S22, S25, S37, S42, S50, S55 and S56 and suggests that ontologies may be very useful for standardization and understanding of requirements (reducing ambiguity), for automatic error checking and conflict analysis of requirements (verifying inconsistency and incompleteness of requirements with less effort) and so on. The second group (S17, S33, S36, S52, S61 and S62 studies) presented evidences that ontologies are good to represent domain knowledge for guiding requirements elicitation and hence to produce requirements specifications with better quality. The studies (S04, S13, S26, S38, S42, S44, S47) in the third group showed that using ontologies is effective for managing requirements changes in general and NFR in specific (e.g., S01 and S35 studies). The fourth grouped is represented by the S13 and S54 studies which shows that the use of ontology may facilitate the communication between stakeholders (e.g., customer, development team, etc) during the RE process. The last group is specific to the S61 study and uses ontologies to support the goal decomposition in the context of goal-oriented models.

Additionally, we also analyse these empirical benefits according to their application context: industry and academic. Figure 7 presents a bubbleplot chart distributed over the empirical benefits and evidence/context dimensions. The number in a bubble represents the number of studies on a specific empirical benefit in a certain pair of research method and application context. As shown in Fig. 7, the B1 benefit is mostly reported by academic controlled experiments (six papers) and by industrial case studies (four papers). Moreover, the B2 benefit is addressed by case study, controlled experiment and quasi-experiment research methods in both industrial and academic settings. The B3 benefit is mainly met by academic controlled experiments (four papers) and academic case studies (three papers). The B5 benefit is reported by studies which conducted controlled experiments in academy and industry. Finally, the B8 benefit was met by a single academic case study.

Fig. 7
figure 7

Empirical benefits over evidence/context

In summary, we can highlight that, despite the concept of ontology is not widespread in the RE community, the results found in this study suggest that there are empirical evidences to state that ontologies benefit RE activities in both academic and industrial settings. However, the strength of these evidences is somewhat limited to the context (for instance, artefact used, activity addressed by the study, ontology language used, RE phase(s) addressed and so on) on which the studies were performed.

4 Discussion

This section starts with a discussion about the scope of this review. Next, we summarize and discuss some related works and depict the threats to validity of this work. Then, we finish discussing further research on the use of ontologies in RE.

4.1 Scope of this systematic review

This SLR focuses on how ontologies are employed in RE, in terms of their use in the RE process, the software requirements modelling styles been used, the types of requirements, the existing contributions and their types, the ontology-related languages, reuse of RE ontologies and empirical and non-empirical benefits. When conducting this SLR, we use jointly the terms “ontology” and “requirements engineering” as part of the search terms to maximize coverage of potentially-relevant studies retrieval and consequently ensure that the results of this SLR can cover all studies that use ontologies in RE activities.

This paper focuses exclusively on the use of ontologies in RE. The “ontology” term has a special meaning in computer science, since it carries with it a whole body of knowledge that is different, for instance, from conceptual model. For this reason, we do not consider synonyms for ontologies in the paper. Furthermore, as explained in Sect. 2.4, this SLR focuses on ontology-driven RE studies in the context of software engineering with generic and technology/paradigm independent contributions, thus we did not consider contributions for specific domains and also for SOA, AOSE, BPM and IT areas.

4.2 Related works

There are some studies that investigate the use of ontologies in Software Engineering [3, 23, 30, 57] and the use of ontologies in RE [9].

Ruiz and Hilera [57] presents a taxonomy in order to assist Software Engineering and Technology (SET) professionals and researchers on the use of ontologies in software development. They present an overview of ontology’s use in many fields of software engineering such as software maintenance, software quality, software measurement, system modelling, component-based software engineering, requirement engineering and so on. Some proposals of the use of ontologies at development time and at runtime are also described in their work.

Hapel and Seedorf [30] present some examples of ontology applications throughout the Software Engineering lifecycle. They discuss the advantages of ontologies in each case and provide a framework for classifying the usage of ontologies in Software Engineering. In a similar way, Ahmed [3] describes some ontology-based approaches in software engineering (ordered by their position in the development life cycle). Examples of techniques from the entire software engineering life cycle (e.g., analysis and design, deployment and run-time, and maintenance) are presented in his work.

Gasevic et al. [23] define a framework that identifies places in software lifecycle where ontologies can contribute to improve software engineering practices. They apply the framework to analyse the use of ontologies in different phases of software life cycle.

Regarding the use of ontologies in RE, Castañeda et al. [9] presents a classification of approaches that include ontologies within RE and describes the expected benefits and challenges that must be faced when using ontologies in RE activities.

As explained previously, despite the existence of some works that surveyed works jointly using ontologies in RE and software engineering, to the best of our knowledge, there is no previous systematic investigation of the literature on the topic. In fact, we have presented a systematic review on the use of ontologies in RE [ref. omitted for blind review] before, but that review considered a limited number of research questions (five) and provided a shallow analysis of the results. Thus, the surveys that were identified and our first review on the topic do not capture all the aspects and evidences that we are interested, for instance, types of requirements been covered, RE problems been addressed, reused ontologies, empirical benefits of using ontologies in RE and so on.

4.3 Threats to validity

This section describes concerns that must be improved in future replications of this study and other aspects that must be taken into account in order to generalize the results of the SLR performed in this work. In order to organize this section, the threats to validity were classified using the Internal, External, Construct and Conclusion categories [64].

Construct validity: The main constructs in this review are the two concepts “ontologies” and “requirements engineering”. For the first concept, we use the term “ontology” and its synonym “ontologies” to make sure that all selected studies are related to ontology approaches. For the second concept, the terms “requirements”, “requirements engineering”, “software analysis” and “domain analysis” are used to ensure high coverage of potentially-relevant studies on the influence to RE activities from database search. A complementary manual search was not performed in the SLR due to the fact there are no conferences and journals specifically focused on the joint use of these concepts. This threat is mitigated by including the general intervention term “ontologies” along with “requirements” in the terms for the search in seven reputable database.

As a threat to the internal validity, some subjective decisions may have occurred during paper selection and data extraction since some primary studies did not provide a clear description or proper objectives and results, making difficult the objective application of the inclusion/exclusion criteria or the impartial data extraction. In order to minimize selection and extraction mistakes, the selection process was performed in an iterative way and the data extraction was realized collaboratively by reviewers, and any conflicts were discussed and resolved by all the authors. In this way, we tried to mitigate the threats due to personal bias on study understanding. It is also worth noting that the first and second authors are, respectively, PhD and MSc students in RE and the remaining four authors are experienced researchers with expertise in RE, Ontology or Software Engineering.

External validity is concerned with establishing the generalizability of the SLR results, which is related to the degree to which the primary studies are representative for the review topic. In order to mitigate external threats, the search process described in Sect. 2.5 was defined after several trial searches and validated with the consensus of all authors. We tested the coverage and representativeness of retrieved studies, including automatic database search and references scan.

Conclusion validity: It is possible that some studies excluded in this review should have been included. To mitigate this threat, the selection process and the inclusion and exclusion criteria were carefully designed and discussed by authors to minimize the risk of exclusion of relevant studies. Furthermore, in the final round of study selection, reviewers conducted the selection process in parallel and independently, and then harmonized their selection results to mitigate the personal bias in study selection caused by individual reviewers. It is worth highlighting that we specified the time period of published studies for this SLR from January 2007 to October 2013, when we started this SLR. As mentioned in Sect. 2, for the best of our knowledge, there is currently no SLR on the use of ontologies in RE. Ruiz and Hilera made a general survey about the use of ontologies in software engineering published before 2007 [57]. In order to reduce repetitive effort and make use of existing work, we set the starting time of the published studies included in this SLR to January 2007.

4.4 Further research

This SLR has generated several promising research directions that are very important but underexplored in current research and practice:

  1. 1.

    How can we employ ontologies to improve the entire RE process (RQ1)? This research has not received much attention and the claims lack evidence support. In fact, only two studies address all five phases of the RE process. Moreover, only one (S01) was empirically evaluated by the conduction of an academic case study.

  2. 2.

    Why ontologies have not been much used along with the validation phase (RQ1)? This research includes the investigation about for the lack of use of ontologies in the validation phase, since such RE phase was rarely addressed by the studies. We suspect that might be some resistance on the use of ontologies when it is need to deal with stakeholders. However, some empirical investigation (e.g., survey) on the topic is encouraged in order to understand why it occurs.

  3. 3.

    How can ontologies be better used in requirements modelling (RQ2)? This SLR showed that ontologies are much more used along with textual requirements. In fact, textual requirements are inherently more prone to inconsistencies and ambiguities than well-structured requirements modelling languages, such scenario-based and GORE approaches. The effort required to reason with textual requirements is greater – generally involving the use of AI techniques. Thus, the use of ontologies can be also further explored along with non-textual requirements modelling styles.

  4. 4.

    How can ontologies be more used with NFRs (RQ3)? This research has not received sufficient attention by the studies. It is well known in the RE community that NFRs are specially important to the success of software systems, but it was addressed by less than half of the studies included in this review. The use of ontologies may be further explored in the elicitation, specification, analysis, validation and management of non-functional requirements both in academic and industrial settings.

  5. 5.

    How can ontologies improve the integration between requirements and architecture (RQ4)? This research has not received much attention by the studies and the claims lack evidence. Only three studies addressed this RE problem and none of them empirically evaluated their contributions. The use of ontologies in such problem appears to be potentially useful, because it can support different aspects which can favour the interplay between requirements and architecture. For instance, ontologies could be used to represent requirements and architectural knowledge and to establish traceability links between these knowledge as well as to support reasoning.

  6. 6.

    How can ontologies facilitate the communication during the RE process (RQ4)? This research has also received insufficient attention by the studies. In fact, only two studies addressed the RE communication problem and were also empirically evaluated (reporting positive claims). The knowledge conceptualization and sharing capabilities inherent to ontologies (especially when it is used some implementation language, for example OWL) suggest that the communication problem between RE players can be better explored with the aid of ontologies.

  7. 7.

    How can ontologies improve requirements models interoperability (RQ4)? As explained in RQ4 (Sect. 3.6), this research was addressed by only two studies. However, since ontologies provide a shared conceptualization in a specific domain, it can also be further explored to promote the interoperability between requirements models. The use of ontologies can also be explored to interoperate requirement models and to help to generate code in the context of model-driven development (MDD).

  8. 8.

    How can ontologies improve distributed requirements elicitation (RQ4 and RQ7)? This research involves requirements elicitation in distributed settings, i.e., where the RE actors are geographically distant. Similarly to items (4), (5) and (6), this research has not received much attention by the studies included in this review. Besides that, as explained in Sect. 3.9.2, one paper found a non-expected empirical negative result on the use of ontologies in distributed requirements elicitation. In this sense, additional empirical evaluations are also required in this kind of RE research problem in order to verify whether such result remains valid.

  9. 9.

    How can W3C ontology-related technologies be better used in RE (RQ5)? The RQ5 results presented in Sect. 3.7 showed that nearly half of the studies have not been supported by W3C ontology-related technologies. In fact, the use of these technologies to support different activities of the RE process still needs to be further explored. For instance, the OWL and RDF languages can be used to guide requirements elicitation. Furthermore, with the use of SWRL and SPARQL languages, some analysis, validation and management could also be performed.

  10. 10.

    How can we promote wider reuse of RE ontologies (RQ6)? As shown in Table 11 (Sect. 3.8), few works have reused ontologies specified by other authors. Thus, more researches are required in order to define agreed conceptualizations within the RE community regarding several RE aspects (e.g., NFRs ontology, GORE ontology and so on) aiming to promote the effective reuse of RE ontologies and avoiding the construction of redundant ontologies.

  11. 11.

    How to measure the costs and benefits of using ontologies in RE in a qualitative or quantitative way (RQ7)? The benefit identified in this SLR is classified without qualitative or quantitative information. Hence, we need more research on the qualitative or quantitative measurement of the benefits of using ontologies in RE. Regarding the costs of using ontologies in RE, we could not explicitly identify metrics to assess the impact that the use of ontologies brings to the RE process. Thus, there is also necessary to conduct more researches on the qualitative and quantitative measurement of the costs of using ontologies in RE.

5 Conclusions

In this work, we conducted a SLR to investigate the use of ontologies in RE. Our goal was to improve the understanding of how ontologies support RE as well as to identify evidences of its use in this field.

Sixty-seven studies were finally included, in which five main RE process phases, nine requirements modelling styles, nine main RE problems, eleven ontology-related languages, twenty-five ontologies have been reused by the studies, five groups of empirical benefits from twenty-six empirical studies and seven groups of non-empirical benefits from forty-two non-empirical studies were identified.

Three categories of benefits out of nine distinct groups deserve special attention, since they were present in the majority of evidences found in the empirical studies: (1) reduction of ambiguity, inconsistency and/or incompleteness of requirements; (2) support for domain knowledge representation to guide requirements elicitation; and (3) assistance in requirements management/evolution. The review results also suggest that ontologies can potentially be useful to deal with several RE problems such as, integration between requirements and software architecture, requirements communication, requirements models interoperability, distributed requirements elicitation and goal decomposition in the context of GORE approaches.

Among the five RE phases, the validation phase is the one which was less addressed by the use of ontologies. Moreover, the majority of studies only partially addresses the RE process. In fact only two papers considered all five phases. There is a great diversity of RE styles that have been supported by ontologies, highlighting the top four frequent categories. Furthermore, even though being much more prone to inconsistencies and ambiguities, textual requirements category is the top frequent modelling style found in this review. Majority of contributions also addressed functional requirements, but there is also a significant number of papers that covers both functional and non-functional requirements. In general, papers mainly addressed ambiguity, inconsistency and incompleteness of requirements, management/evolution of requirements as well as domain knowledge representation.

Additionally, a great number of contributions are supported by a tool, indicating the studies’ concerns with automated support for potential users. Moreover, half of the studies followed W3C recommendations on ontology-related languages, in which the use of OWL was much more significant. Regarding the reuse of ontologies, despite the existence of a great variety of RE ontologies, none was identified as being broadly adopted. Finally, it was observed that the empirical benefits are mainly focused on the top three RE problems highlighted above. However, it is worth noting that the requirements communication and goal decomposition problems are also considered in the set of studies.

The results presented in this systematic review can be very useful to the RE community, since it gathers evidences from the primary studies included in the review, forming a body of knowledge regarding the use of ontologies in RE. As future work we intend to further investigate some of the research directions presented in this paper, with an emphasis on the integration between requirements and software architecture through the use of ontologies with the aid of W3C ontology-related languages. Moreover, we intend to continue this systematic review to explore how ontologies have been supporting the entire software development process.