Research Directions in Requirements Engineering

Ieee account.

  • Change Username/Password
  • Update Address

Purchase Details

  • Payment Options
  • Order History
  • View Purchased Documents

Profile Information

  • Communications Preferences
  • Profession and Education
  • Technical Interests
  • US & Canada: +1 800 678 4333
  • Worldwide: +1 732 981 0060
  • Contact & Support
  • About IEEE Xplore
  • Accessibility
  • Terms of Use
  • Nondiscrimination Policy
  • Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2024 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

U.S. flag

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

  • Publications
  • Account settings
  • Advanced Search
  • Journal List
  • Springer Nature - PMC COVID-19 Collection

Logo of phenaturepg

A systematic literature review of requirements engineering education

Marian daun.

1 paluno-The Ruhr Institute for Software Technology, University of Duisburg-Essen, 45127 Essen, Germany

Alicia M. Grubb

2 Department of Computer Science, Smith College, Northampton, MA 01063 USA

Viktoria Stenkova

Bastian tenbergen.

3 Department of Computer Science, State University of New York, Oswego, NY 13126 USA

Requirements engineering (RE) has established itself as a core software engineering discipline. It is well acknowledged that good RE leads to higher quality software and considerably reduces the risk of failure or budget-overspending of software development projects. It is of vital importance to train future software engineers in RE and educate future requirements engineers to adequately manage requirements in various projects. To this date, there exists no central concept of what RE education shall comprise. To lay a foundation, we report on a systematic literature review of the field and provide a systematic map describing the current state of RE education. Doing so allows us to describe how the educational landscape has changed over the last decade. Results show that only a few established author collaborations exist and that RE education research is predominantly published in venues other than the top RE research venues (i.e., in venues other than the RE conference and journal). Key trends in RE instruction of the past decade include involvement of real or realistic stakeholders, teaching predominantly elicitation as an RE activity, and increasing student factors such as motivation or communication skills. Finally, we discuss open opportunities in RE education, such as training for security requirements and supply chain risk management, as well as developing a pedagogical foundation grounded in evidence of effective instructional approaches.

Introduction

Requirements engineering (RE) is commonly accepted as the foundation of high-quality software [ 132 ]. Requirements engineering education (REE) must not only deal with teaching students how to specify formal and informal requirements but also how to elicit and negotiate requirements involving multiple sources—particularly human stakeholders. Thus, REE must make students aware of socio-technical challenges and teach human-related aspects, which poses significant challenges for REE in higher education.

Furthermore, students must be adequately prepared to take on industrial challenges [ 172 , 195 ], while incorporating the theoretical concepts underlying RE [ 30 ]. REE is at best an afterthought in many university software engineering curricula [ 179 ], focusing on lecture-style instruction with few or no realistic examples. In many cases [ 64 , 67 ], RE is not instructed in dedicated courses, but instructed as part of a generic software engineering course. The problem with this situation is twofold: on the one hand, graduates only gain a rudimentary understanding of the minimal RE knowledge required by accreditation standards [ 1 ], standard curricula [ 74 , 75 , 90 ], and bodies of knowledge [ 20 ]. On the other hand, the opportunity is lost to give students enough experience to pick the right RE tools for each development project. In consequence, it is left to the industry to adequately train their staff to be effective in RE.

We need a clear understanding of what to teach (i.e., learning objectives), as well as what educational approaches are the most effective, who the learners are, and what learning outcomes to strive for. Herein, we contribute a systematic literature review of the field of Requirements Engineering Education. Our work allows researchers to gain an overview of the current state of the art and provides educators with insights on how to teach which RE technique.

We consider three research goals:

  • Goal 1: develop a systematic map of the current state of REE research;
  • Goal 2: report on current practices and their learning outcomes; and
  • Goal 3: evaluate how REE has changed over the previous decade.

We further elaborate on these goals in Sect.  3 .

This paper is structured as follows. Section  2 discusses meta-studies on the field of REE. Section  3 details our research questions and methodology. In Sects.  4 – 6 , we discuss results pertaining to each of our research goals (goal 1–goal 3). Section  7 concludes this paper.

Background and related work

Challenges in mastering requirements engineering.

Requirements Engineering (RE) is a socio-technical, iterative process to elicit, document, and manage the requirements of a system under development [ 56 ]. RE bridges the gap between human users, developers, and managers, i.e., between people with and without software engineering expertise. RE helps to understand what problem needs to be solved by a (software) system. In addition, it helps to discover who needs to be involved in the engineering process (i.e., stakeholders) and how the problem could be solved by exploring trade-offs and alternatives [ 186 ]. RE requires analysis of both the problem space (i.e., context analysis) and solution space (i.e., the intervention). This is accomplished through a variety of requirements discovery or requirements gathering techniques, including eliciting requirements by interviewing stakeholders or by analyzing existing systems, before documenting the requirements in the form of a specification.

For example, interview techniques alone demand careful selection, as stakeholders may respond differently depending on the mode of inquiry. Imagine a focus group for a new mobile app to allow children to self-monitor health symptoms. A focus group consisting of physicians and children might quickly arrive at decisions about the app’s medical goals, but neglect the children’s perspective because in this setting, the children themselves might be too intimidated to contribute. Documentation techniques require similar careful choice. Storyboards, personas, user interface mock-ups, and natural language requirements (constrained or not), are useful to communicate ideas quickly with a broad audience of non-technical stakeholders, but lack precision for safety-related applications. Formal methods are very precise; however, they require substantial technical expertise and are generally unfit for directly communicating design choices and alternative solutions to stakeholders.

Despite excellent work in the field, elicited and documented requirements artifacts are often incomplete, conflict with one another, and/or suffer from other inadequacies [ 55 , 120 ]. The quality of how the RE process is conducted immediately impacts the quality of the requirements, which in turn, impacts the quality of the system under development. The RE process must be iterative and perpetually monitored with regard to elicitation, documentation, and validation, as well as tracing [ 148 ] requirements from their “source” (e.g., stakeholders, but also laws and standards) to their “destination” (e.g., their refinement into more requirements, analysis results, or their implementation into code). These challenges motivate us to investigate the landscape of RE approaches as it relates to education and training.

Mastering Requirements Engineering is not only a monumental task for the learner, but also for the educator [ 39 ]. On one hand, the theory behind concepts, techniques, and ontologies is quite technical and demands a high amount of rote memorization [ 31 ]. On the other hand, most of the RE process is “learning by doing,” i.e., the learners must to experience it for themselves [ 65 ] before being able to appreciate (and with repeated exposure, eventually master) the RE process and develop a “feeling” when certain techniques are preferable over others. This dichotomy requires a carefully calibrated RE curriculum that balances theory instruction and process exposure.

Studies on the state of requirements engineering education

In a recent REFSQ conference keynote, 1 Martin Glinz provided a survey spanning the past several decades on RE Education literature. Indeed, over the past 20 years, a series of reports have been published into the state of the art of software engineering education that are more or less concerned with aspects of requirements engineering education. One of the earliest ones by Shaw [ 162 ] came at a time, where software engineering education was mostly done at the graduate level, aiming to prepare future PhD students. Shaw picked up the claim made in [ 183 ], where graduate and postgraduate software engineering education starts too late and should begin at the undergraduate level alongside traditional computer science education. To this end, Shaw identified “forces” impacting the software engineering industry and academia, and derived “aspirations” for higher education in software engineering to strive towards. Shaw took a wider view than RE education alone, and she aspires for software engineering education to include the need for novice software engineers to specialize into roles and sub-fields like requirements engineering, testing, and even safety assessment. Moreover, Shaw suggested that software engineering education takes an experience-based stance to allow the learner to put theory into practice and develop an intuition for the application of techniques.

By 2008 [ 105 ], software engineering curricula became relatively wide-spread at the undergraduate level, and with it came an increased focus on RE education. As pointed out by Regev et al. [ 146 ], undergraduate RE education was slow to address Shaw’s aspirations, due to discrepancies between typical project-based learning in higher education and actual industry experiences. According to Regev et al., academic classroom projects translate poorly to the industry because of their “sterile” nature, which inadequately reflect industrial practices. The authors attributed this discrepancy to the fact that academic projects must be narrowly scoped to be completed within one semester, by a few students who do not have prior knowledge of the application domain. Additionally, instructors must provide the same experiential opportunity regardless of student background and possible arising group conflicts. Regev et al.’s observations are consistent with views previously reported by a series of other authors, including [ 27 , 33 , 54 , 68 , 169 ], and later confirmed with an empirical study by Menon et al. [ 112 ].

Three systematic mapping studies were conducted between 2012 and 2020, which consist of the work by Malik and Zafar [ 105 ], the aforementioned work by Idri, Ouhbi, et al. [ 71 , 135 ], and the work by Cico et al. [ 24 ]. While the mapping studies by Malik and Zafar as well as by Cico et al. take a wide aim on software engineering education at large, the work by Idri, Ouhbi et al, focuses particularly on RE education. Interestingly, Malik and Zafar report that while some of the mapped primary studies are concerned with project-based learning, the vast majority are concerned with educational technology and tools. Moreover, none of the 70 studies mapped by Malik and Zafar could be easily classified into the knowledge area “Requirements Engineering” according to the reference curricula available then (i.e., “Knowledge Area A” in [ 2 ] or “Knowledge Area C” in [ 90 ]). This indicates that REE research was incongruent with reference curricula and software engineering education research largely ignored RE as a topic. The more focused mapping study conducted by Ouhbi et al. [ 71 , 135 ] reveals a similar trend: only 19 out of 79 mapped primary studies mention reference curricula. The vast majority of papers (77%, see [ 135 ]) present solution approaches with mostly graduate or undergraduate students, with only a minority describing some evaluation of existing approaches. Only few primary studies concerned with industrial training or industrial case studies were found (i.e., 16% and 6% or selected studies, respectively). Moreover, while Ouhbi et al. found that 16% of selected primary studies were written with industrial training consultants as co-authors, neither  [ 71 ] nor [ 135 ] report on industry-readiness of learners.

In summary, past studies investigating the state of the art of REE have been conducted and published in loose intervals. As the newest REE-specific study conducted by Ouhbi et al. [ 71 , 135 ] stems from 2012, we expect the field to have evolved in light of the strong evolution of the field driven by new technologies (cf. [ 193 ]). Therefore, in this paper we want to provide an up-to-date investigation of the current state of REE. We investigate how the field has changed since the investigation of Ouhbi et al., and whether needs posed by new technologies have already been considered in REE research. In addition, we derive common practices and provide guidelines for REE synthesized from the found studies, which has not been done so far. Thus, we review educational approaches that foster learning objectives suitable to the requirements-related problem to be instructed.

Research method

In this section, we first elaborate on our research goals introduced in Sect.  1 , and introduce the research questions explored in our systematic literature review (SLR). We then describe our SLR methodology in detail, including how we searched for relevant papers, extracted knowledge, and analyzed data.

Goals and research questions

As mentioned in Sect.  1 , this SLR complements the mapping study by Ouhbi et al. [ 135 ]. Ouhbi et al.’s work mainly investigated the type of contribution, without placing a clear focus on learning outcomes. We, therefore, provide an overview of existing research about the state of REE and its impact on students’ learning outcomes with the study at hand.

We define three overall goals for our study:

  • Goal 1: Provide a systematic map of the current state of research in requirements engineering education. Such a systematic map helps researchers in relating their own research to the state of the art and educators in selecting existing approaches for application and adaptation to their own needs.
  • Goal 2: Provide a synthesis of the current practices the studies reported in the systematic map (i.e., goal 1). This helps to identify approaches best suited for specific RE learning outcomes and challenges in teaching RE.
  • Goal 3: Evaluate how the state of REE has changed over the last decade since the investigation by Ouhbi et al. [ 135 ].

To fulfill these goals, we defined ten detailed research questions, that allow us to assess the state of REE research. The research questions are listed in Table  1 .

Research questions

To achieve goal 1, our SLR contains a systematic map that adheres to established research questions for systematic maps as defined by Petersen et al. [ 142 ]. These research questions have been adapted to account for research on REE. As commonly done in systematic mapping studies, we are interested in the researchers involved in REE (RQ1-2), the major publications and venues in the area (RQ3-5), and how do authors conduct and describe their research in this area (RQ6-8). In addition, we defined research questions regarding the educational approaches used, learning outcomes addressed, and the RE techniques taught (RQ9-10).

To achieve goal 2, we relate answers from goal 1 with one another. This allows investigating the instructional theories underlying REE, with a focus on learning outcomes. Taking this as a starting point we synthesize the findings, contributions, benefits, and shortcomings of the papers in the so created sets.

To achieve goal 3, we defined the research questions to be investigated on the basis of the research questions used by Ouhbi et al. [ 135 ]. This allows us a fair comparison of our findings—particularly newer publications—with the findings of Ouhbi et al.. Thereby, it can be investigated whether the state of REE research has changed over the last decade.

Search procedure

The selected search method of an SLR may impact the found results considerably: manual search, database search, and snowball search may result in paper sets with significant disparities [ 21 ]. In order to avoid limiting the scope of investigation to selected venues (like in manual search), or getting “stuck” in local cliques of mutually referencing papers (like in snowball searches), we used a database search to cover the overall spectrum of possible approaches.

In this spirit, we also used broad search terms to lower the risk of missing relevant papers. Our defined search string is as follows:

TITLE-ABS-KEY (“Requirements Engineering” AND “Education”)

For database searches it is common to include synonyms in the search string; however, this was not appropriate in the case of our investigation. We excluded “training” and “learning” from the search string as pilot testing the search string yielded an extra-proportional number of machine learning and artificial intelligence approaches being included in the results, which are beyond the scope of this study. We restrained the string from including the different areas of RE as substitute for the term “requirements engineering.” Doing so would have led to a misrepresentation of the field as many techniques relevant for requirements engineering education are used in other fields. Instead, we wanted to represent what authors believe is requirements engineering education. Thus, we restricted the search to requirements engineering education literature.

In addition, we analyzed the search string using comparison by manual search for selected venues (as suggested as part of the quasi-gold standard, cf. [ 197 ]). Analysis showed high sensitivity of the search string.

We used Scopus for the search because it covers many publishers, including the most common publishers for computer science research (e.g., ACM, IEEE, Elsevier, Springer), and unlike Google Scholar allows filtering non-peer-reviewed publications. The search string was developed based on the literature review’s topic and research questions, as is commonly done in systematic literature reviews [ 89 , 142 ].

Study selection

The search was conducted by three different researchers who evaluated each paper based on the inclusion and exclusion criteria (see Table  2 ) on their own. We considered papers published at any time until December 31, 2020. Papers were included in the set of relevant papers of the respective literature review if all researchers found the paper relevant and excluded if all found the paper irrelevant. In cases of inconsistent perceptions of the paper’s relevance, the paper was discussed among the researchers until consensus was reached.

Inclusion and exclusion criteria

Figure  1 shows the process of step-wise exclusion of studies to derive the final set of included studies. The studies were selected and excluded at different stages.

In summary, we investigated 671 papers, from which we excluded 519 papers. Resulting in the final set of 152 included publications. 2

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig1_HTML.jpg

Study selection process

Data extraction

The data extraction process is illustrated in Fig.  2 . To answer research questions RQ1-6, we extracted each paper’s meta-data from Scopus. For RQ7-9, each included paper was read carefully by three different researchers to extract data pertinent to the research questions. For RQ10, we grouped selected studies into common themes for synthesis. We used word-tags pertaining to the content of a study (e.g., “industry-centric,” “motivation,” or “completeness”) and discussed our findings. Where there was disagreement between any two researchers, a third researcher evaluated the paper. The final classification was reached through discussions among all three researchers.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig2_HTML.jpg

Data extraction process

Quality assessment

Recently, some SLRs assess the quality of included studies (e.g., [ 135 ]), but these assessments lack a common standard. For example, the application of qualitative quality assessment criteria may be seen as difficult and ambiguous particularly when conducted by researchers of diverse backgrounds (e.g., [ 97 ]), and may, therefore, result in the erroneous exclusion of study results from synthesis. In addition, as is the case with our search, SLRs do not require primary data (i.e., papers) to have been published with sufficient transparency and quality for application of further empirical methods. Thus, we follow a commonly suggested quantitative approach to quality assessment by only including publications that have been peer-reviewed. Hence, we elected to have the quality assessment criteria be reflected in the inclusion and exclusion criteria outlined in Table  2 , instead of conducting an additional subjective quality assessment.

Analysis and classification

In this section, we revisit our research questions RQ1-10 and describe how we applied the classification schemas. Table  3 presents an overview of this information.

Measurements and classifications for each research question (see Table  1 for full descriptions)

For RQ6, we used a commonly accepted classification for research methods provided by Wieringa et al. [ 194 ]. In doing so, we distinguished between evaluation research, proposal of a solution, validation research, philosophical papers, opinion papers, and personal experience papers (see Table  4 ). Each paper was mapped to exactly one category. In some cases, the categorization of papers might not be obvious. For example, it can be difficult to distinguish between a proposal of a solution and validation research because these types differ in terms of completeness and rigor of their evaluation, which may not be fully described. In these cases, the classification was based only on the presentation of the paper. Other evaluation activities that were suggested but not explicitly reported in the paper were not considered. Each paper was then assigned to the category that fit best.

Classification of research methods (RQ6), provided by [ 194 ]

For RQ7, we adapted the scheme proposed by Petersen et al. [ 140 ], which has been reused in other mapping studies (e.g., [ 36 , 52 ]). However, as some papers did not fit well into any of the original categories, we added a category for other contributions. Table  5 lists each contribution type. Each paper was assigned to all categories that apply.

Classification of research contribution (RQ7), adapted from [ 140 ]

Validity evaluation

In this section, we discuss aspects of validity according to the classification scheme in [ 141 ], and the measures taken to mitigate these potential threats.

Descriptive validity

Descriptive validity deals with the accurateness and objectivity of an investigation. As threats to descriptive validity are considered more significant in qualitative investigations than in quantitative investigations, we assume that there are no major threats to descriptive validity. We did not use qualitative quality assessment but favored quantitative quality assessment, which supports descriptive validity. Misclassification of papers may have led to threats to descriptive validity for RQ10 in particular. We built our classification to a large extent on existing and accepted classification schemes. We classify papers as intended by the authors (e.g., type of research contribution, educational approach used), which have been substantiated in the peer review process, to avoid threats from misinterpretation. It cannot be completely ruled out that authors and reviewers of one paper might have accepted an erroneous classification. We assume this was rare enough in occurrence to not impact the descriptive validity (i.e., without misrepresenting the field).

Theoretical validity

Theoretical validity concerns whether the research questions can be answered with the study setup. A major threat in this category typically stems from selection bias. To avoid this bias, we defined objective inclusion and exclusion criteria and applied them rigorously. Inclusion and exclusion criteria were applied independently by two different researchers, with a third researcher validating the choices. Also, the classification was done by two researchers independently, again with a third conducting quality assurance. In case conflicts in the inclusion/exclusion or classification of a paper arose between any two researchers, another researcher was involved, and the conflict was solved by discussion among all researchers, switching roles between “classifier” and “validator” in order to help each individual maintain an objective point of view.

Generalizability

Generalizability of the findings deals with the question, whether the set of papers included into the systematic mapping study are representative and do not miss important aspects. Comparison with previous secondary studies on requirements engineering education (see also Sect.  3.8 ) indicates that we did not miss a considerable number of relevant primary studies to be included.

Interpretive validity

Interpretive validity is concerned with the validity of the conclusions drawn. Hence, researcher biases are a considerable threat. To avoid threats to interpretive validity inclusion and exclusion criteria as well as the classification scheme were not applied by one researcher alone. As outlined above, conflicts were resolved by discussion among at least three researchers that investigated the paper independently. This reduces the threat of researcher bias.

Repeatability

To ensure repeatability, we report the search and selection process as well as the inclusion and exclusion criteria in sufficient detail to enable other researchers to verify our work. Moreover, we make our data available online, particularly with regard to RQ10. Additionally, abstaining from applying qualitative exclusion criteria helps improve repeatability. However, it cannot be ruled out that different researchers might have classified some of the papers in some cases into different categories. This is a common threat in systematic mapping studies and systematic literature reviews. Yet, due to the large number of included publications, we are confident that this would not alter the implications of our findings.

Validity evaluation for goal 3

Regarding goal 3, it is important to ensure that we use common grounds with the study of Ouhbi et al. [ 135 ], since this study serves as a baseline for our comparison of how REE has changed over the past decade.

We identified 36 of the 79 studies selected by Ouhbi et al.. Two of these studies were considered the same contribution in our work (i.e., [ 84 ]) because the two papers were published in the same venue very close to one another. Of the 43 remaining studies reported by Ouhbi et al., we identified 32 that either did not meet our inclusion criteria (e.g., studies with a primary focus on RE education, rather than education at large using RE methods), or meet our exclusion criteria (most commonly studies that are less than four pages long or dealing with RE for engineering education, see Table  2 ). One study was unobtainable to us, but reported in Ouhbi et al. (i.e., [ 139 ], for which, in fact, we were unable to locate any publication record at all). The remaining seven studies identified by Ouhbi et al. were not identified by us using the process described above. These studies are [ 8 , 23 , 42 , 91 , 96 , 199 ] and [ 178 ].

Two of the contributions identified by us are in fact Ouhbi et al.’s work [ 71 , 135 ]. During Step 4 in Sect.  3.3 , we included 50 papers which were published in the time period reported by Ouhbi et al.. Of these, we selected 33 contributions that were not reported by Ouhbi et al.. These papers are [ 3 , 16 , 22 , 28 , 44 , 45 , 49 , 53 , 58 – 60 , 62 , 83 , 85 , 98 , 115 , 116 , 118 , 122 , 127 , 133 , 134 , 143 , 151 – 153 , 156 , 166 , 173 – 175 , 185 , 187 , 188 ] and [ 192 ]. Thus, we have an agreement of 67.19% with the work of Ouhbi et al., which yields a Cohen’s κ of 0.3586 (i.e., fair agreement ) [ 26 ].

When comparing results with Ouhbi et al., search strategy accounts for some of the differences between included studies. We relied on Scopus (as this already covers the established publishers in the field) to search for articles, while Ouhbi et al. used the publishers’ search engines and Google Scholar. We purposefully used a more general search string than Ouhbi et al., as outlined above to investigate what authors believe RE Education shall be concerned with. Additionally, we applied stricter exclusion criteria.

In summary, we found more candidate papers but also excluded more. Like Ouhbi et al., we were interested in metadata about the papers. Yet, they investigated which studies referred to reference curricula, while our investigation focused on educational approaches and learning outcomes regardless of reference curricula, and the change of REE research since Ouhbi et al.’s work. Thus, our work is complementary.

Returning to goal 3, since we have covered sufficient common ground with the work of Ouhbi et al., we can provide valid observations about how the field of REE has evolved over the past decade.

Results for goal 1

In this section, we present our systematic literature map (goal 1) and explore each research question (RQ1-10) in detail.

Most active researchers (RQ1)

We begin by exploring who is most involved in REE activities. Table  6 shows the most prolific authors in the area of REE. A total of sixteen authors contributed at least four published papers. Most prolific is Didar Zowghi from the University of Technology Sydney, Australia with nine published papers. As can further be seen, authors regularly involved in REE stem from around the world with a strong focus on Europe. Nine researchers are affiliated with universities from European Union countries: Germany (5), Spain (2), Portugal (1), and Italy (1). Three authors are affiliated with Malaysia, two with Australia, and one with Chile or the United States. Thus, we can see that while 152 articles were selected in our study, the majority of the contributions do not appear to be the primary scientific focus of the publishing scholars (with the exception of the individuals from Table  6 ), as most authors have fewer than two contributions in this field.

Top 10 of most active researchers

Research networks (RQ2)

Using study metadata, we automatically generated Fig.  3 , which shows the existing networks of authors found in the included studies. This gives a high-level overview of how segmented the efforts are in REE. Rectangles visualize collaborations between individual authors. As can be seen there exists a variety of individual collaborations that are not connected to other authors. Thus, we can assume that the field is rather scattered without collaborations between different author clusters. The coloring indicates the number of collaborations. Most authors participate in only one collaboration (light blue color), the maximum amount of collaborations is four between two authors (dark blue color). To improve readability and further explore existing networks of authors, we isolated networks with more than one collaboration to create a fragment of our map in Fig.  4 . Overall, these findings suggest that most selected studies appear to be separate contributions without a systematic continuation of a research direction. A notable exception is the work by Zowghi, Spoletini, Ferreira, and Bano from recent years, which investigates the use of interviews to practice requirements elicitation [ 13 , 40 , 41 ] and inspections [ 11 ].

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig3_HTML.jpg

Automatically generated map of author networks. Red lines indicate connections between authors, who are part of two collaboration groups. The darker the hue, the more co-authored papers (Color figure online)

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig4_HTML.jpg

Fragment of author networks only including those with more than one collaboration

Top venues (RQ3)

Table ​ Table7 7 shows all venues where multiple papers on REE have been published. We found fourteen venues where researchers regularly publish REE research. Yet, there are only five venues where REE seems to be published on a regular basis (i.e., with more than five total publications). The most established venue for REE is the International Workshop on Requirements Engineering Education and Training (REET) with 32 publications. The most established conferences are the IEEE International Conference on Software Engineering Education and Training (CSEE&T, 16) and the IEEE International Requirements Engineering Conference (RE, 10). The most established journal is Requirements Engineering (REJ), yet carries only five publications (of 152 total selected studies). This indicates that so far many early ideas and problem descriptions are elaborated on, with more mature research on REE being rarely addressed in the three most representative venues of requirements engineering research. According to Daneva et al. [ 29 ], these are REJ, RE, and the Working Conference on Requirements Engineering: Foundations for Software Quality (REFSQ), excluding their workshops. Yet, RE and REJ carry only 15 publications (ca. 9.7% of all 152 selected studies), while REFSQ is not represented in this list at all. Moreover, REJ is merely in sixth place (shared with the iStar workshops). In conclusion, REE research seems to be primarily published in education-related venues that are not specific to requirements engineering as well as the REET workshop. We conclude that there may be a missing connection between non-education research in RE and research specific to RE education.

Venues with multiple publications

Paper per year (RQ4)

We found an increasing trend of publications over the years. Figure  5 shows the distribution of publications by year and type of venue where a paper was published (see also Sect.  4.3 ). As can be seen, research on REE started slowly in the beginning with only four conference papers between 1988 and 1998, and one journal article. This was followed by a phase from 1999 to 2007, where papers were regularly published, however in small numbers each year, and only in conferences. Since 2007, REE-related workshops have appeared and are in part responsible for the increase in publications reaching a maximum of seventeen publications in 2018. Thus far, 2018 was the year with the largest number of published journal papers. These findings suggest that REE has gained more and more interest over the years and its importance is shown in still increasing publication numbers. More than half of the publications selected in our work were published after the work by Ouhbi et al. [ 135 ]. Ouhbi et al.’s work was conducted in 2012 (almost 10 years ago), which coincided with the beginning of a four-year hiatus of REET. The eighth installment of REET was in 2013 and ninth and tenth installments were in 2018 and 2020, respectively. This in turn coincides with a period of slightly decreased frequency of workshop contributions and contributions at the three top venues for RE-specific research [ 29 , 179 ]: the REFSQ conference, the RE conference, and the Requirements Engineering journal (see also Sect.  4.3 ).

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig5_HTML.jpg

Publications and venues per year. Each bar represents one year, with cumulative counts of publications per year (RQ4) listed at the top of each bar. Bars are sub-divided by type of publication venue (RQ3) to illustrate changes in venue over time

Top cited publications (RQ5)

We generated a citation network to analyze citation cycles. Figure  6 shows an excerpt of the citation network, i.e., the set of papers that cite other papers from all included studies. Arrow heads point to papers citing another paper (i.e., can be thought of as an “import” relationship). First, it can be seen that only about a third of all selected studies cite any papers within our set of 152 selected papers at all; the two-thirds of papers not citing any other papers have been omitted from Fig.  6 . Second, no paper is cited more than four times (see outgoing arrows in Fig.  6 ). Most papers cite merely one or two other papers and only five papers cites at least as many other papers (see ID 1001, 1005, 1058, 1008, and 1043 in Fig.  6 ). These are typically review papers. For example, the paper with the ID 1001 is the review paper by Ouhbi et al. [ 135 ]. Thus, we can conclude that no considerable citation cycles do exist. This means that neither is there as standard reference for REE accepted by the community. Thus, we found that most (i.e., at least two-thirds of our selected studies) REE research happens in “a vacuum,” without relying heavily on other findings in the field.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig6_HTML.jpg

Citation network of articles (dots) being cited by other articles (edges, head pointing to cited article). As can be seen, only six articles are cited four or more times, suggesting no common foundation of RE education literature

Research methods (RQ6)

We evaluated the papers based on the presented type of research, i.e., its underlying research method. Table  8 (left-hand side) shows the results separated by year. As can be seen the vast majority of papers are either solution proposals or experience reports. In contrast, evaluation research and validation research are only sparsely conducted. This means that while there exists a plethora of approaches aiming at improving REE and a variety of personal experience reports, more thorough empirical investigations of the field either by exploratory evaluation studies or by thoroughly validated solutions are missing. We conclude from this that the maturity of the field must be considered rather low. This is in line with our findings from RQ5, as indications of high overall maturity would be indicated by common, frequently cited references.

Data for RQ6: research methods and RQ7: contributions by year

a Method includes methods, techniques, and approaches

Contributions (RQ7)

For the contributions of the included studies, we mapped the publications according to the classification scheme proposed by Petersen et al. [ 140 ]. Table  8 (right-hand side) shows the results separated by year. Most publications propose a method, followed by tools to be introduced in REE. This is in line with findings by Malik and Zafar [ 105 ] (see also Sect.  2.2 ). In addition, we found a large number of papers classified as “other” . These mostly result from the large number of experience reports, which typically do not propose any kind of contribution in the sense of the categories in [ 140 ]. Nevertheless, we classified them according to their common theme, as shown in Fig.  7 . As can be seen, many papers classified as “other” in Table  8 report on limitations, pitfalls, or constraints, yet without specifying concrete solutions (17 in total). A total of 12 papers are concerned with involving real or realistic stakeholders (e.g., through role playing), while six papers propose a course design (without explicitly proposing it as a solution to a specific problem). Six more papers propose education research case studies and/or examples (often conflating the two terms), while again six studies report on empirical studies with students, surveys, or other types of investigations, yet without validating or evaluating a proposed solution (see Table  8 ). We infer from this that unlike non-education fields of software engineering, REE is fairly diverse, yet centers around proposing specific methods or approaches, or involving specific tools. This is in-line with our finding that most contributions are solution proposals (see RQ6). Although this further indicates low maturity of the field, it also means that a diverse set of contributions and solution avenues exist to teach RE, thereby suggesting a rich (albeit unsystematic) “toolbox” of educational approaches.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig7_HTML.jpg

“Other” contributions from Table  8

Keywords (RQ8)

Table ​ Table9 9 shows the ten most frequently used keywords. As can be seen most keywords are basic terms. Beside these keywords, other keywords are used five times or less often. Thus, this indicates that—beside the topic of requirements elicitation—there seems to be no specific area of interest in requirements engineering that education research particularly focuses on. The frequent use of the term “requirements elicitation” indicates that for this specific area of RE there may be a particular interest in how to teach this topic. Yet, other areas of RE may not receive as much attention. This may make it difficult for educators interested in the field to find a solution to an instructional problem they are faced with, without being intimately familiar with the many solution proposals that exist in the field (see RQ6 and RQ7).

Top 10 of most frequent keywords

Learners (RQ9)

Figure  8 shows the distribution of the emphasized audience of teaching approaches as stated by the included publications. The vast majority of papers (120) clearly address university students. Of these, three papers consider postgraduate students, 21 focus on graduate students, 44 on undergraduates, and 52 do not further specify the level of the learner. Only 17 papers address teaching industry professionals. Thirteen papers omit the audience (“not mentioned” in Fig.  8 ) or generically speak of “students” (“unknown” in Fig.  8 ). We assume some of these address university education and find this sufficiently obvious that authors do not deem it important to specify this further. One paper places emphasis on RE education at the high-school level and another one investigates RE knowledge in alumni. This seems to show that Shaw’s “aspiration” [ 162 ] was in part answered, as a substantial number of approaches target aspiring software engineers in very early stages (i.e., at the undergraduate level) to instruct role-specific skills related to requirements engineering. Yet, by comparison, industry training is currently not a key focus in REE research.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig8_HTML.jpg

Type of learners addressed

Learning outcomes (RQ10)

To gain insights into what the included studies propose or investigate—and thus on the question what the current state of research in REE deals with from a content-related point of view—we identified broad recurring themes. Figure  9 shows these themes and their frequency.

  • Teaching requirements engineering activities. Most papers (i.e., 73) are concerned with teaching different RE activities. Recurring activities are elicitation, negotiation, specification, requirements validation, management, and modeling. In addition, specific activities as safety analyses or requirements tracing are concern of some publications.
  • Teaching soft skills. Forty-nine included studies focus on teaching soft skills when teaching RE. Targeted soft skills are typically closely related to the work profile of a requirements engineer. Papers commonly focus on communication skills, teamwork and collaboration skills, conflict resolution skills, interviewing techniques, or technical writing.
  • Improving student-related factors. In this category, 32 papers aim at improving the learning of students by increasing student motivation, enthusiasm for the subject matter, coping with overwhelmed students, or aim to improve students’ ability to explore problems and deal with solution uncertainty.
  • Improving industry readiness. A total of 29 publications aim at improving industry readiness of the students to cope with real RE problems. This is typically done by involving real stakeholders in a course, using or investigating real requirements specifications, or applying industry-realistic examples in the classroom.
  • Teaching requirements quality. In total 20 papers, focus on improving students’ sensitivity to high-quality requirements. Requirements quality properties mainly include consistency and correctness of requirements and requirements specification documents, but also ambiguity, and completeness.
  • Raising awareness for integrated RE processes. Although these eleven papers were included as they place particular emphasis on teaching RE, their focus lies on doing so as part of a broader development context, e.g., dealing with real customers’ needs.
  • Adaptability to professional environments. Nine papers propose specific educational settings to foster professional RE skills. For instance, this includes distributed global settings to mimic spatial separation of teams or teaching computer science students together with students from other disciplines to raise awareness of multidisciplinary issues.

This list shows that teaching requirements engineering activities is only part of what REE is concerned with, as about half of the papers deal with non-core requirements engineering theory.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig9_HTML.jpg

Topics of interest

In summary, the results presented in this section constitute our systematic map, which addresses goal 1. It is notable that since Mary Shaw’s aspiration (i.e., to include more role-specific undergraduate software engineering education, see [ 162 ]) has been answered by the REE community. A vast plethora of approaches have been proposed, especially since 2012 and beyond. Yet, the field suffers from low overall maturity. Most research appears to be solution proposals, without suggesting a continuing research avenue, and without producing a core area of expertise, neither surrounding scholars, nor surrounding methods, nor surrounding specific contributions. Nevertheless, we found that successful requirements engineering instruction encompasses more than theory, i.e., student factors and soft skills, as well as industry-readiness. Therein lie core themes in the papers we have discussed. In the next section, we address goal 2 and discuss the most significant trends pertaining to learning outcomes, as well as the educational approaches to achieve them.

Results for goal 2

Next, we explore goal 2 of this paper, which investigates the current practices regarding pedagogical techniques and the learning outcomes they seek to achieve. We initially hoped to distill these practices based on data from validated approaches. However, as can be seen by the results of RQ6 and RQ7 (see Sects.  4.6 and 4.7 , respectively), research contributions are overwhelmingly solution proposals or experience reports, with only 21.7% being evaluation or validation research. While several proposed solutions provide at least minimal quantitative or qualitative evidence as to their efficacy, a systematic replication and investigation of their pedagogical benefits is (unsurprisingly [ 25 , 163 ]) largely missing.

Nevertheless, as can be seen by the results from RQ10 (see Sect.  4.10 ), there are some clear and promising trends. These trends can be summarized into the following topics:

Authenticity and industry-readiness

Teaching re activities and requirements quality, student factors and soft skill development.

To give further context to our discussion of learning outcomes, we tagged the papers in our mapping based on their educational approach, as explained in Sect.  3.4 shown in Fig.  10 .

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig10_HTML.jpg

Type of educational approach

The first trend that we observed is the prominence of work that focuses on industry-readiness and giving students an authentic RE experience. We found that 32 papers (see Fig.  10 ) used an industry-centric educational approach (e.g., by involving external stakeholders from real companies), and 29 papers (see Fig.  9 ) explicitly mention industry-readiness as a learning outcome. Figure  11 shows these studies over time. From this timeline, we can see that this research focus is comparatively young, as half of these approaches have been published in the past 10 years alone.

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig11_HTML.jpg

Publications per year proposing an industry-centric learning outcomes and educational approaches

Further, this trend suggests that the community is moving away from instructor-centric approaches, which focus on rote memorization of theory and individual high-stakes problem solving. Instead, nearly two-thirds (61.84%) of the studies shown in Fig.  10 propose a non-instructor-centric approach to instruct RE. Note that in Fig.  10 , approaches could pertain to more than one category. Nevertheless, we found 94 individual studies. These include the 32 aforementioned industry-centric approaches, as well as student collaboration (29 studies), project-based (13 studies), problem-based (9 studies), and other inquiry-based paradigms (20 studies (e.g., games [ 5 , 50 ] or case studies [ 110 , 182 ]). Of the 32 industry-centric studies, seven studies do so by fostering student collaboration (i.e., [ 27 , 38 , 123 , 125 , 167 , 177 , 180 ]), four do so through project-based instruction (i.e., [ 9 , 16 , 32 , 180 ]), and four through some other form of inquiry-based instruction (i.e., [ 27 , 53 , 168 , 177 ]). Within these 32 studies, two paradigms around stakeholder involvement can be differentiated: on one hand, approaches involve external stakeholders in realistic projects (e.g., [ 48 , 61 , 103 , 137 , 138 ]); while on the other hand, approaches involve the instructor (or some other non-industry representative, e.g., [ 47 , 177 ]) to engage in role-playing to create an industry-realistic project experience (e.g., [ 98 , 125 , 130 , 168 , 176 ]). In both of these paradigms, stakeholders serve as a partner to help students with requirements activities to some degree (see Sect.  5.3 ).

However, achieving industry authenticity is not necessarily done by involving real or mimicked stakeholders alone. Other approaches include using industry-realistic case examples (e.g., [ 30 – 32 ]) or using geographically distributed teams working on the same project (e.g., [ 9 , 16 , 149 , 152 , 198 ]). These approaches are interesting because they address soft skills in addition to industry-readiness (also see Sect.  5.3 ).

Evidence on the effectiveness of improving industry-authenticity relies on experience reports (e.g., [ 98 , 138 , 171 ]). Quantitative data are mostly available by means of students’ course evaluations (see [ 147 ]), or exam results (see [ 32 ]). Perhaps this is because student evaluations, assignment sheets, and exams are the typical means of assessment of student performance; however, another way of assessing learning outcomes is to measure student performance against industry needs, such as through a graduate alumni surveys of preparedness. This was done in [ 184 ], where researchers found that perceived usefulness of instructed documentation formats (e.g., use cases or glossaries) seem to increase with graduates’ work service and project experience.

In summary, we consider it a positive development that educational approaches have taken a keen focus on improving students’ industry-readiness and are moving away from rote memorization in favor of formative learning. However, many of these approaches aim at doing so without consideration of industry needs. Few approaches report on providing requirements engineering training to practitioners, with the notable exception of Morales-Ramirez et. al’s work in [ 123 ]. For both, more studies providing evidence are desirable.

Next, we investigate trends in selecting topics to include in RE training. About half of the investigated studies focus on specific RE activities (73 studies in total, see Fig.  9 ). We visualize our selected categories of this breakdown in Fig.  12 . Among the most common are elicitation (39.72% of studies, e.g., [ 53 , 69 , 86 , 102 , 150 , 174 , 176 ]), modeling (28.77% of studies, which includes “modeling syntax” [ 17 , 34 , 66 ] and “process modeling” [ 107 , 159 ]). Eleven studies (15.07%) explicitly aim to instruct the whole RE process, while validation, verification, or quality assurance are a topic in only eight studies (10.96%, e.g., [ 41 , 69 ]), and management in only five studies (6.85%, including “time management,” “project management,” or “process management,” i.e., [ 14 , 38 , 100 , 114 , 121 ]). Surprisingly rarely do studies investigate more rigorous RE activities. For example, we found only three studies that look at security requirements engineering (from a process perspective, not quality perspective, i.e., [ 110 , 111 , 143 ]), three studies investigating formal methods (i.e., [ 44 , 188 , 191 ]), and two studies on requirements tracing (i.e., [ 19 , 116 ]). Safety requirements engineering was merely the elementary instructional focus of a single study (i.e., [ 180 ]).

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig12_HTML.jpg

Studies explicitly instructing RE activities

Looking closer at the most investigated RE activity, elicitation, the vast majority of included studies (i.e., 19 out of 29) do so by means of using interviews as the predominant technique (see Table  10 ). Of the remaining ten papers, six studies did not specifically emphasize any particular elicitation technique, while three used specific technique (e.g., workshops) and one used various elicitation techniques including interviews.

Techniques used by “elicitation” studies in Fig.  12

Additionally, we considered which instructional approaches were used in elicitation activities. As shown in Table  11 , papers that used role playing were the most predominant approach. Other approaches included using real stakeholders, games, and tools. The contribution by Sedelmaier and Landes [ 161 ] was particularly noteworthy in this respect, not only because it is one of the few studies that employ a specific pedagogical paradigm (i.e., “competence-oriented didactics” in Table  11 ). While two papers did not specify any approach, we did not find any papers that studied the use of competitor or market analyses.

Instructional approaches used by “elicitation” studies in Fig.  12

It is also noteworthy that some requirements engineering activities that could be considered essential (e.g., negotiation or prioritization) are not specifically targeted by RE education at all, as shown in Fig.  12 . While these activities may be subsumed in those studies targeting the “whole process,” the respective authors did not explicitly list all activities they included.

We observed a mismatch between teaching requirements quality properties (i.e., completeness, consistency, and traceability) and work advocating for a project-based learning environment. We found a total of 20 studies that explicitly mention teaching students to be sensitive to requirements quality. Of these, only two also pertain to those included in Sect.  5.1 (i.e., [ 58 , 180 ]). Figure  13 shows the breakdown of quality requirements publications, where studies may target more than one quality. Of the remaining 18 studies (see Fig.  13 ), the predominant focus is on requirements “consistency” (i.e., [ 49 , 62 , 69 , 166 , 174 , 188 , 190 , 191 ]). “Correctness” is targeted by five studies (i.e., [ 7 , 49 , 58 , 87 , 188 ]); however in doing so, studies often conflate formal provability of requirements and the sense of adequacy with regard to stakeholder needs (see [ 55 , 57 ] for a discussion of the difference). Only one included study explicitly mentions “adequacy,” but this is specifically in the context of security requirements [ 131 ]. Similarly, “completeness” is only explicitly targeted by Westphal in [ 191 ], albeit in the context of formal modeling of requirements. Four studies do not limit the educational focus on individual qualities, but rather mention “quality as a whole.” These studies are [ 11 , 41 , 53 ] and [ 59 ]. A total of six studies implicitly target requirements quality (“others” in Fig.  13 ). While they explicitly state the need to instruct sensitivity to high-quality requirements, the educational approach therein is not specifically targeted to requirements artifacts, but rather activities to improve quality in requirements. In this sense, “complexity” or “abstraction” are mentioned by three studies (i.e., [ 37 , 93 , 114 ]). The remaining studies each mention one quality property: traceability [ 60 ], ambiguity [ 174 ], and understandability [ 175 ].

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig13_HTML.jpg

Studies explicitly instructing requirements quality

As outlined in Sect.  4.6 , many of the studies we surveyed are “solution proposals” (see Table  8 ). Of these, most advocate for project-centric collaborative approaches and a minority advocate for instructor-centric, theory-heavy instruction. This is consistent with our earlier finding (see Sect.  5.1 ) that most approaches advocating industry-readiness do so in a project-based setting, requiring students to experience the whole RE process, from elicitation to documentation, to management. However, only ten of 73 studies mention a specific RE activity in an industry-realistic setting as opposed to targeting the whole RE process or not mentioning RE activities at all (i.e., [ 28 , 32 , 48 , 50 , 100 , 106 , 126 , 128 , 180 , 184 ]).

In summary, we found very little overlap between studies mentioned in Sect.  5.1 with studies aiming to teach RE activities and a focus on requirements quality. This seems to suggest that by increasing industry-readiness comes at the expense of teaching specific RE activities and requirements quality. However, we do not believe this to be the case. Many of the studies mentioned in Sect.  5.1 aim to convey a feeling of the intricacies of the whole RE process to students, not just individual activities. Moreover, it is the whole process experience which highlights issues such as completeness of requirements through elicitation and documentation, adequacy/correctness of requirements through validation and verification, requirements consistency and the like. However, while not ignored, it seems that these intricacies are at best conveyed implicitly. We did not find any study explicitly investigating how industry-readiness may also foster requirements activity proficiency and sensitivity to requirements quality, and recommend this as an area for future research.

A third theme we found in our analysis is that many of the included studies emphasize student factors and soft skill development. This means that the focus is on “how” to conduct requirements activities effectively, thereby increasing soft-skills such as communication (as in [ 177 ]) or customer-orientation (as in [ 174 ]) rather than solely teaching “that” requirements elicitation is necessary. We tagged the publications emphasizing soft skills and visualize our results in Fig.  14 . The most frequently addressed soft skills are teamwork, collaboration, or social interaction (30.61% of studies pertaining to soft skills, e.g., [ 16 , 31 , 32 , 66 , 118 , 138 , 147 , 153 , 180 , 187 ]), interviewing skills (24.49%, e.g., [ 12 , 13 , 28 , 35 , 156 , 176 , 198 ]), customer interaction or client-orientation (16.33%, e.g., [ 69 , 118 , 125 , 127 , 157 , 174 ]), and communication (also 16.33% of soft skill studies, e.g., [ 27 , 149 , 152 , 153 , 159 , 168 , 177 ]). Only two studies focused on agile development as a soft skill (namely, [ 67 , 102 ]); however, most studies focusing on collaboration and communication applied a project-centric and industry-realistic (see Sect.  5.1 ) learning environment in conjunction with agile methods. Like in Sect.  5.2 , the overlap to those studies in Sect.  5.1 is fairly low, as only four studies appear to explicitly involve authentic industrial settings to improve students’ soft skills, i.e.,  [ 28 , 67 , 118 , 180 ].

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig14_HTML.jpg

Studies explicitly improving soft skills

However, as introduced above, most of the contributions whose primary focus is on soft skill development do so in a collaborative and/or project-based setting. Of the studies that apply a formative instruction paradigm (i.e., project-based, problem-based, and/or collaboration-based instruction in Fig.  10 ) and of the 49 studies that aim to improve students’ soft skills (see Fig.  9 ) as their primary learning outcome, the overlap consists of 19 studies (i.e., 30.65% of formative methods studies from Fig.  10 ). These studies mainly focus on communication, interviewing, and team collaboration in project-based settings.

The overlap between the same formative instructional approaches from Fig.  10 and studies specifically aiming to improve student factors is much lower. We identified a total of 12 studies that employ a project-, problem-, or collaboration-based instructional method in combination with the explicit aim of improving student factors. These factors include enthusiasm and motivation (e.g.,  [ 31 , 98 , 108 ]), comprehension and understanding (e.g.,  [ 103 , 117 , 181 ]), learning and retention (e.g.,  [ 16 ]), and introspection (e.g.,  [ 43 , 94 ]), which is a 19.35% overlap with formative approaches.

In total, we found 32 studies that propose a diverse set of pedagogical strategies to improve student factors, which we show in Fig.  15 (note, studies may pertain to more than one student factor). The most commonly addressed student factors are motivation/enthusiasm (11 studies in total i.e.,  [ 5 , 31 , 32 , 34 , 50 , 51 , 94 , 98 , 117 , 138 , 180 ]), understanding/comprehension (8 studies, i.e., [ 44 , 63 , 103 , 117 , 159 , 170 , 181 , 188 ]), retention/learning (7 studies, i.e.,  [ 6 , 15 , 16 , 34 , 66 , 122 , 187 ]), and engagement/ interest (also 7 studies, i.e.,  [ 5 , 31 , 32 , 94 , 117 , 138 , 180 ]). The remaining six studies target a diverse, yet more abstract set of student factors, i.e., “combating students being overwhelmed” [ 190 ], “effort and aggravation” [ 58 ], “review effectiveness” [ 134 ], “acceptance of uncertainty” [ 14 ], “process competency” [ 129 ], and “introspection” into the validation process (i.e.,  [ 11 , 13 , 41 ], which for the purpose of this discussion, we consider one contribution).

An external file that holds a picture, illustration, etc.
Object name is 766_2022_381_Fig15_HTML.jpg

Studies explicitly improving student factors

Besides formative and industry-centric approaches as outlined above, studies aiming to improve student factors and soft skills propose a diverse set of strategies to fulfill their aim. In particular, the use of games or gamification (e.g., [ 5 , 6 , 34 , 50 , 99 , 156 , 170 , 187 , 196 ]), engaging case examples (e.g., [ 3 , 9 , 30 ]), or using low-stakes assignments (e.g., [ 18 , 28 , 196 ]) are promising approaches that emerge from the literature.

In summary, while proposals for teaching specific RE activities are separate from improving student factors and soft skills (see Sect.  5.2 ), we found that student factors and soft skills are a tangential learning outcome of this work. By comparison, industry-authenticity specifically adopts external stakeholders or role playing as an instructional mechanism in order to improve student motivation and enthusiasm (see Sect.  5.1 ). The REE literature recognizes that soft skills are critical for students’ success in future employment and that student factors are critical in improving student success in requirements engineering. Nevertheless, more work on how to successfully and holistically integrate theory instruction and student success is desirable.

Results for goal 3

In this section, we address goal 3 by evaluating how REE has changed over the last decade. To accomplish this goal, we compare our findings to those from Ouhbi et al. [ 71 , 135 ]. In Sect.  3.8 , we compared our literature search methodology and results to those from Ouhbi et al. to contextualize our analysis. In the following subsections, we compare to Ouhbi et al.’s “implications and advice for instructors” and what REE research has contributed since the study concluded. Finally, we identify additional gaps in current REE literature and offer our own conclusions.

How literature addresses Ouhbi et al.’s “implications”

Following a detailed map of the REE field, Ouhbi et al. provide advice to REE instructors in the form of seven implications derived from their selected studies. In this section, we discuss these implications and contrast them with studies published after the period of investigation reported by Ouhbi et al., which allows us to consider the progress in the field since 2012. Furthermore, we expand on these implications with our own observations and recommendations for REE instructors.

Combating vague requirements

Ouhbi et al. recommend that instructors teach proper problem scoping in order to avoid vague requirements. The authors assert that certain personality traits improve team performance in this respect. Indeed, such a relationship exists [ 164 , 165 , 189 ] and as we have outlined above, student factors such as comprehension, effort, and enthusiasm are explicitly mentioned learning outcomes in 32 of our 152 selected studies. Eighteen of these studies fall into a time frame after Ouhbi et al.’s search completed. While none of these studies mention “vagueness” or “attention to detail” explicitly, several mention “introspection” (e.g., [ 13 ]) or “comprehension” (e.g., [ 117 ]). Unfortunately, “vagueness” or “level of detail” was not mentioned as a learning outcome in any of our selected studies. We conclude from this that instructors have recognized that student factors are crucial in educating students to become effective requirements engineers, yet student factors alone do not yield effective requirements specifications. We recommend instructors consider pedagogical techniques aimed to increase the level of detail and thereby combat vagueness in requirements specifications.

RE tool instruction

With hundreds of RE tools available on the market, Ouhbi et al. make a strong argument for the need to educate students into using these tools effectively. Indeed, 27 of our selected studies deal with tools or advocate using technology to improve learning and instruction. However, the overwhelming majority of these studies propose games (e.g., [ 5 , 50 , 51 , 70 , 156 , 170 , 187 , 196 ]) or simulation tools (e.g., [ 10 , 150 , 154 ]) to teach RE. They do not outline how to use tools during the RE process. A notable exception is [ 87 ], where requirements modeling using tools is taught as well as [ 106 ], which in part investigates the use of tools to conduct validation and verification of requirements. Our results show that RE tool instruction is still lacking, nearly 10 years after the conclusion of Ouhbi et al.’s survey. A focus here should be on industry-typical tools and tools that are likely to produce a tangible benefit to the RE process, for which current industry needs are unknown and must be assessed (see also Sect.  5.1 ). Nevertheless, using the right tools during RE also depends on the company-specific tool chains and may therefore be “on the job training,” rather than something that can (or should) be instructed at university level. Again, an industry perspective is required to answer this question.

Promote requirements modeling, validation and verification, and prototyping

Our results in Sect.  5.2 show that next to elicitation and RE process instruction, the most commonly addressed RE activities are modeling of any kind as well as quality assurance at large (a total of 29 studies, see Fig.  12 ). Most of these studies occurred before 2012 (i.e., when Ouhbi et al. concluded) with the exception of [ 17 , 66 , 87 , 117 , 125 , 184 ] and [ 190 ]. Ouhbi et al. were correct to point out that more instructional focus was required, as these 29 studies made up a mere 19.1% of all our selected studies (compared to 18.4% for “elicitation” alone). We agree that these activities (i.e., modeling and prototyping) should be promoted during RE instruction. Modeling and requirements validation have proven to be a key asset in the requirements engineer’s toolbox to bridge the gap between non-technical and technical stakeholders. Teaching non-technical skills has thus far mostly taken the form of soft skills (see Sect.  5.3 ), but even in this regard, the focus is on communication and interviewing due to the strong overlap with studies that focus on “elicitation” (see Fig.  14 ). Prototyping of requirements specifications has not been emphasized or made a key learning outcome in any of our selected studies. An opportunity here is lost in that students do not benefit from seeing the relationship between “theoretic” requirements specifications and their implementation. While we have reported an activity involving requirements prototyping in one of our selected studies [ 180 ], this was only a minor milestone in a RE project, burdened by other constraints in the timeline of the semester. We recommend practitioners to develop approaches such as [ 108 ] and incorporate requirements implementation as well.

Using industry-realistic projects

As outlined in Sect.  5.1 , delivering an authentic, industry realistic educational experience has consistently been a focus of REE literature since roughly 2005 (see Fig.  11 ). In Ouhbi et al.’s study, the focus was on REE approaches and their relationship to standard curricula, many which require industry-readiness as a student outcome (e.g., [ 1 ]). While this is a positive trend in the past, we concur with Ouhbi et al. that this remains an important educational outcome for future work in REE.

Promote global software development

Ouhbi et al. emphasize the need for REE approaches to meet the demands placed on software development through a consistent move toward distributed teams. In particular, in light of the recent events (i.e., the COVID-19 pandemic), we agree that video conferencing and distributed teamwork have become necessary skills for students, educators, and industry professionals to master, and will likely shape the landscape of software development for the coming years. Teaching effective RE in such a context may be easier going forward because learners may be accustomed to social distancing and working remotely. Nevertheless, only a minority of our selected studies consider distance learning or geographically separated teams, only one of which was published after 2012 (i.e., [ 16 , 108 , 149 , 152 , 198 ]). This must be a focus of REE approaches going forward, and these approaches could build off of the experiences from forced distancing during the COVID-19 pandemic.

Familiarize students with problem solving

Ouhbi et al. highlight the importance of problem solving skills to become effective requirements engineers and recommend REE literature to take a game-based approach to problem solving. While “problem solving” was only explicitly mentioned in one of our included studies (i.e., [ 17 ]) and while games-based instruction or gamification is the focus of several of our selected studies (e.g., [ 5 , 101 , 109 , 187 ]), we argue that these approaches are not the only strategies to teach effective problem solving. In fact, peer-learning [ 27 ], role-playing [ 4 , 98 , 168 ], fostering analytical thinking [ 64 ], and client-orientation [ 157 , 174 ] have been successfully applied to aspects of RE instruction. Problem solving is at the heart of RE. The key caveat seems to be to create a low-stakes environment, where students can “safely fail” (i.e., explore solution alternatives without grade penalty for being wrong or without threatening project success). Approaches that offer low-stakes learning experiences are quite common, both in individual-centered instruction (e.g., [ 113 , 158 ]) and collaborative instruction (e.g., [ 28 , 31 , 119 ]). In fact, 24 of our selected studies can be roughly categorized as employing some form of low-stakes problem solving experience; a trend that should continue in the future.

Use mobile devices as teaching tools

Ouhbi et al. made an argument to use mobile devices and online tools as a vehicle to teach RE. However, Ouhbi et al. did not articulate in what way REE, in particular, benefits from m-learning or e-learning. When examining our selected studies, only three mention some type of online platform or the use of mobile devices to teach RE (i.e., [ 88 , 124 , 144 ]). We conclude from this that the benefits of m-learning and e-learning to REE may still be largely unexplored, beyond the opportunity to prepare students for the challenges of global software development (see Sect.  6.1.5 ).

Gaps in current RE education literature

While industry-readiness, authenticity, and student soft skill development are important and encouraging trends in REE literature, in the following sections, we highlight the areas that have not received sufficient attention.

Safety and security requirements

Shockingly few studies (i.e., only three: [ 110 , 111 , 143 ]) deal with security requirements and only one study considers safety requirements explicitly [ 180 ]. Since software systems are increasingly entrusted with sensitive information and playing a mission-critical role, it is vital that students are exposed to these considerations at the earliest possible stage during their undergraduate curriculum. Further work is required to understand how to effectively instruct learners on the intricate notions of security requirements and their impact on the system under development. While some studies may incidentally involve safety and security requirements, a systematic educational approach is required.

Supply chain risk management and supplier/integrator relation

Most project-based approaches involving real or realistic stakeholders aim to convey the difficulty of managing conflicting requirements. However, these approaches may prime students towards an attitude of “document and forget” [ 32 ]. Requirements are rarely seen through to their implementation (see “prototyping” in Sect.  6.1 ). Moreover, typical software engineering projects emphasize software construction. The current literature largely ignores the need to systematically explore reuse of off-the-shelf components, the need to critically reflect on adopting components (e.g., libraries), or risk involved when adopting possible security-critical technologies. The decision to adopt a technology and risk its successful integration are inherently RE-related and must be systematically assessed on the basis of requirements. At present, students do not achieve this learning outcome with the approaches reported herein.

Pedagogy in RE education

Systematic application of pedagogy is largely ignored by contemporary REE literature. Merely two approaches make explicit use of Bloom’s taxonomy to guide their instruction [ 19 , 124 ] and only 10.5% of approaches (i.e., [ 4 , 7 , 11 , 19 , 40 , 41 , 53 , 92 , 104 , 112 , 127 , 145 , 155 , 158 , 160 , 161 , 176 ]) consider systematic pedagogy. Yet, with the exception of closely related studies such as [ 11 , 40 , 41 ], there seems to be no common pedagogical framework nor is there a common basis of systematically gathered evidence as to the effectiveness of teaching approaches given learning outcomes. In fact, to the best of our knowledge, the manuscript at hand is the first and thus far only systematic investigation into REE literature and students’ learning outcomes. We therefore declare a call to action for the REE community (and perhaps the software engineering education community at large) to produce a common, evidence-based pedagogical framework. We hope that the work at hand lays a suitable foundation for such an effort.

Discussion, conclusions, and future work

In this paper, we presented the results of a systematic literature review into learning outcomes portrayed in Requirements Engineering Education (REE) literature. We have selected 152 primary studies from 1988 to 2020, to provide three contributions: (goal 1) We provide a systematic map of the current state of REE research. (Goal 2) We review the current practices and educational approaches to achieve learning outcomes. (Goal 3) We show how REE has changed in the last decade and which topics remain unexplored in the literature.

Our main findings include the recent trend towards authentic and industry-realistic learning experiences to improve students’ knowledge, predominantly on topics such as requirements elicitation and modeling, but also with regards to students’ soft skills, collaboration, teamwork, and industry-readiness. To accomplish this, current trends involve real or realistic stakeholders and role playing in low-stakes collaborative project-based instruction scenarios. Theory-based instruction plays a subordinate role in REE, suggesting that knowing about theory is less emphasized than effectively applying theory in industry-realistic settings, ideally spanning all parts of the RE process.

Our findings further suggest that areas where REE approaches are currently lacking include instruction of safety and security requirements engineering, as well as supply chain risk management. Moreover, REE presently suffers from a lack of a common pedagogical basis and systematically gathered evidence. While a plethora of successful teaching methods have been proposed (e.g., game-based learning, new frameworks, and educational tools), for the most part, these contributions are in isolation and not part of a systematic attempt to propose methods that are tailored to student outcomes.

We contrast and complement findings from a previous mapping study by Ouhbi et al. [ 135 ]. While Ouhbi et al.’s work focuses on REE approaches and their consideration of standardized curricula, we place emphasis on synthesizing learning outcomes and educational approaches reported in the literature. We also highlight developments in the field since Ouhbi et al.’s study concluded in 2012. In part, we were able to replicate Ouhbi et al.’s results, differ in some findings, and provide additional findings not previously reported.

To our knowledge, a replication of a systematic literature review or mapping study has thus far not yet been completed in the discipline of software engineering. While it was not our aim to replicate Ouhbi et al.’s work, we believe that the work at hand sufficiently highlights areas of overlap. This produces a secondary outcome of our work, i.e., that differences between our findings can be explained by differences in search methodology and as well as rigor in inclusion and exclusion criteria.

In this paper, we lay a foundation for the REE community to produce a rich evidence-based understanding of effective pedagogical approaches. Given the vastness of our data set, we envision future work focusing on qualitative analysis of previous studies to uncover new insights. For example, we found that interviews for elicitation is well studied in the literature. Future work could look at which other elicitation techniques are taught (e.g., questionnaires, analyzing competitors). Similarly, other studies could investigate how requirements quality metrics (e.g., correctness, consistency) are instructed.

In addition to studying the level of learners (see Sect.  4.9 ), future work could study these educational approaches with respect to which approaches are taught as part of introductory, intermediate, or advanced courses in RE and SE, at both the bachelors and master levels. This would give greater insight into the depth of RE curriculum, and would be complementary to initial efforts  [ 64 , 67 ]. Supporting this line of inquiry, we also intend to survey educators to identify best practices and examine whether there are any instructional approaches that could be of relevance for RE education but have not been published.

As already introduced in Sect.  5 , we found 33 papers (i.e., 21.7% of selected studies) with validated approaches, which was insufficient for our intended analysis. Given the importance of evidence as to the effectiveness of pedagogy, we seek to complete an in-depth qualitative analysis of these papers as part of future work in order to provide insights to what works and what does not work. By looking more deeply at RE activities, we can assist new educators in understanding what is recommended.

In addition, as already discussed in the paper (see Sects.  5.1 ,  5.2 , and  6.1.4 ), we found the further research is required to explicitly investigate the relationship between industry-readiness and requirements proficiency among students. Finally, as proposed in Sect.  6.2.1 , we need a systematic educational approach to instruct students on the development and importance of security requirements.

Open Access funding enabled and organized by Projekt DEAL.

1 Available at https://2021.refsq.org/details/refsq-2021-papers/3/The-Challenge-s-of-Teaching-Requirements-Engineering .

2 The data set is available here: 10.35482/csc.003.2021

Publisher's Note

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Contributor Information

Marian Daun, Email: [email protected] .

Alicia M. Grubb, Email: ude.htims@bburgma .

Viktoria Stenkova, Email: [email protected] .

Bastian Tenbergen, Email: [email protected] .

  • Complete Program
  • Your Program
  • Research Papers
  • Posters and Tools
  • Doctoral Symposium
  • Industry Track
  • Journal Early Feedback
  • Registration
  • Steering Committee Meeting
  • Venue: Barcelona, Catalunya, Spain
  • Registration: REFSQ 2023
  • Accomodation
  • Event format
  • Sponsor REFSQ
  • REFSQ 2023 - Steering Committee
  • REFSQ Charter
  • REFSQ 2023 Committees
  • Organizing Committee
  • Track Committees
  • Posters and Tools Co-Chairs
  • Programme Committee
  • Doctoral Symposium Co-Chairs
  • Panel of Experts
  • Contributors
  • People Index

Research Papers REFSQ 2023

Accepted papers, review criteria, call for papers.

Requirements Engineering (RE) is a critical factor in developing high-quality and successful software, systems, and services. The REFSQ working conference series is an established international forum for discussing current and state-of-the-art RE practices, celebrating its 29th edition.

Please check the CfP here: https://2023.refsq.org/track/refsq-2023-papers#Call-for-Papers

Universitat Politècnica de Catalunya

Program Display Configuration

Tue 18 apr displayed time zone: brussels, copenhagen, madrid, paris change, thu 20 apr displayed time zone: brussels, copenhagen, madrid, paris change.

In response to the Call for Papers, we received 84 abstracts, which resulted in 78 full papers, which reviewed by three program committee members, extensively discussed among the reviewers, and then brought for additional discussion if needed and final decision at the plenary program committee meeting that was held (online) on January 17 and 18, 2023. Nine papers for which no consensus had been reached were discussed in special depth, with nine of them accepted on the condition that certain improvements be made (those underwent an additional check by a PC member before final acceptance).

Overall, 25 papers were finally accepted for publication. In particular, based on paper category, the acceptance ratios are as follows:

Scientific Evaluation (15 pages) : 20 submissions, 7 accepted (35%)

Technical Design (15 pages) : 22 submissions, 5 accepted (23%)

Experience report papers (12 pages) : 14 submissions, 5 accepted (36%)

Vision (8 pages) : 3 submissions, 2 accepted (67%)

Research Preview (8 pages) : 14 submissions, 6 accepted (43%)

The acceptance rate of full contributions was thus 29% (12/42).

List of accepted papers

IMPORTANT NEWS: Submission of new papers is allowed until Nov. 18th, 2022 also for authors who did not submit a preliminary abstract by the abstract deadline (Nov. 11th, 2022). Updates of papers submitted by the deadline of Nov. 18th, 2022 are allowed until Nov. 23rd, 2022

We invite original submissions in the following categories:

  • Technical design papers (15 pages incl. references) describe the design of new artifacts, i.e., novel solutions for requirements-related problems or significant improvements of existing solutions. A preliminary evaluation of the artifacts is also expected.
  • Scientific evaluation papers (15 pages incl. references) investigate existing real-world problems, evaluate existing real-world implemented artifacts, or validate newly designed artifacts, e.g., by means such as case studies, experiments, simulation, surveys, systematic literature reviews, mapping studies, or action research. Check the Empirical Standards for guidelines and review criteria for each research type: https://github.com/acmsigsoft/EmpiricalStandards
  • (NEW this year) Experience report papers (12 pages incl. references) describe retrospective reports on experiences in applying RE techniques in practice, or addressing RE problems in real-world contexts. These papers focus on reporting the experience in a narrative form, and give prominence to the lessons learned by the authors and/or by the participants. Experience reports include also studies in which academics interview practitioners about the application of specific RE techniques, or about RE problems in practice.

Vision papers (8 pages incl. references) state where research in the field should be heading.

  • Research previews (8 pages incl. references) describe well-defined research ideas at an early stage of investigation which may not be fully developed.

Each type of paper has its own review criteria , which are listed here: https://2023.refsq.org/track/refsq-2023-papers#Review-Criteria

Submission, Reviewing, and Publication

Contributions must be submitted to: https://easychair.org/conferences/?conf=refsq2023

Each submission in the scope of REFSQ will undergo a single-blind review process that will involve at least three members of the program committee.

The REFSQ 2023 proceedings will be published in Springer’s LNCS series.

The best papers will be invited to submit an extended version of their contribution to a Special Issue of the Requirements Engineering Journal

All submissions must be formatted according to the Springer LNCS/LNBIP conference proceedings template (for LaTeX and Word): https://www.springer.com/gp/computer-science/lncs/conference-proceedings-guidelines . As per the guidelines, please remember to include keywords after your abstract.

Furthermore, to facilitate accurate bidding and a better understanding of the papers, each paper submitted to REFSQ 2023 is required to have a structured abstract . The imposed structure demands each abstract have exactly 4 paragraphs with the following content:

  • Context and motivation : Situate and motivate your research.
  • Question/problem : Formulate the specific question/problem addressed by the paper.
  • Principal ideas/results : Summarize the ideas and results described in your paper. State, where appropriate, your research approach and methodology.
  • Contribution : State the main contribution of your paper. What’s the value you add (to theory, to practice, or to whatever you think that the paper adds value). Also, state the limitations of your results.

Three examples of structured abstracts are given here .

Each paper category has its own review criteria. We invite authors and reviewers to check the criteria and consider their order of relevance.

Technical design papers (15 pages incl. references) describe the design of new artifacts, i.e., novel solutions for requirements-related problems or significant improvements of existing solutions. A preliminary evaluation of the artifacts is also expected.

Review Criteria (in order of relevance) :

  • Novelty : to what extent is the proposed solution novel with respect to the state-of-the-art? To what extent is related literature considered? To what extent did the authors clarify their contribution?
  • Potential Impact : is the potential impact on research and practice clearly stated? Is the potential impact convincing? Has the proposed solution been preliminarily evaluated in a representative setting?
  • Soundness : has the novel solution been developed according to recognised research methods? Is the preliminary evaluation of the solution sound? Did the authors clearly state the research questions? Are the conclusions of the preliminary evaluation logically derived from the data? Did the authors discuss the limitations of the proposal?
  • Verifiability : did the authors share their software? Did the authors share their data? Did the authors provide guidelines on how to reuse their artfiacts and replicate their results? [ NOTE: sharing data and software is NOT mandatory, but papers that make an effort in this direction should be adequately rewarded]
  • Presentation : is the paper clearly presented? To what extent can the content of the paper be understood by the general RE public? If highly technical content is presented, did the authors make an effort to also summarise their proposal in an intuitive way?

Scientific evaluation papers (15 pages incl. references) investigate existing real-world problems, evaluate existing real-world implemented artifacts, or validate newly designed artifacts, e.g., by means such as case studies, experiments, simulation, surveys, systematic literature reviews, mapping studies, or action research. Check the Empirical Standards for guidelines and review criteria for each research stretegy: https://github.com/acmsigsoft/EmpiricalStandards

  • Soundness : has the novel solution been developed according to recognised research methods? Is the research method justified? Is the research method adequate for the problem at hand? Did the authors clearly state the research questions, data collection, and analysis? Are the conclusions of the evaluation logically derived from the data? Did the authors discuss the threats to validity?
  • Potential Impact : is the potential impact on research and practice clearly stated? Is the potential impact convincing? Was the study carried out in a representative setting?
  • Novelty : to what extent is the study novel with respect to the related literature? To what extent is related literature considered? To what extent did the authors clarify their contribution? To what extent does the study contribute to extend the body of knowledge in requirements engineering?
  • Presentation : is the paper clearly presented? To what extent can the content of the paper be understood by the general RE public? If highly technical content is presented, did the authors make an effort to also summarise their study in an intuitive way?

Experience report papers (12 pages incl. references) describe retrospective reports on experiences in applying RE techniques in practice, or addressing RE problems in real-world contexts. These papers focus on reporting the experience in a narrative form, and give prominence to the lessons learned by the authors and/or by the participants. Experience reports include also studies in which academics interview practitioners about the application of specific RE techniques, or about RE problems in practice.

  • Relevance of the Application : is the application context in which the experience is carried out interesting for the RE public? Is the application context sufficiently representative? To what extent is the paper reporting a real-world experience involving practitioners? Is the experience credible?
  • Relevance of Lessons Learned : are the lessons learned sufficiently insightful? Did the authors report convincing evidence, also anecdotal, to justify the lessons learned?
  • Potential for Discussion : will the presentation of the paper raise discussion at the REFSQ conference? To what extent can REFSQ participants take inspiration to develop novel solutions based on the reported experience? To what extent can REFSQ participants take inspiration to perform sound empirical evaluations based on the reported experience?
  • Novelty : is the context of the study in line with the current RE practice? Does the study report on a contemporary problem that RE practitioners and researchers typically face?
  • Presentation : is the application context clearly presented? Are the lessons learned clearly described? To what extent can the content of the paper be understood by the general RE public?
  • Potential Impact : will the vision impact the future research and practice in RE? Is a roadmap discussed? Is the vision sufficiently broad to affect different subfields of RE? Do the authors discuss both short-term and long-term impacts of their vision?
  • Potential for Discussion : will the presentation of the vision raise the interest of the REFSQ audience? Will the vision raise discussion? Can the vision raise controversial opinions in the audience?
  • Novelty : is the vision sufficiently novel with respect to existing reflections within the REFSQ community? Do the authors clarify the novelty of their vision?
  • Soundness of Arguments : is the vision supported by logical arguments? Are the implications convincing?
  • Presentation : is the vision presented in a compelling way? Is the vision presented in a way that can elicit reflections in the RE community?

Research previews (8 pages incl. references) describe well-defined research ideas at an early stage of investigation which may not be fully developed.

  • Novelty : did the research preview make you say “I heard it first at REFSQ!”? Is the idea sufficiently novel with respect to the state-of-the-art? Do the authors discuss related work and the contribution of their study?
  • Soundness of the Research Plan : do the authors present a convincing research plan? Did the authors discuss the limitations and risks of their plan? Is the plan referring to sound research methods? Do the authors clarify their research questions, planned data collection, and data analysis? Did the authors perform a convincing proof-of-concept or preliminary research step?
  • Potential for Discussion : will the presentation of the preview raise the interest of the REFSQ audience? Will the preview raise discussion? Will the audience be able to provide useful feedback to the authors, given the typical background of the REFSQ audience? Can the preview raise controversial opinions in the audience?
  • Presentation : is the paper clearly presented? To what extent can the content of the paper be understood by the general RE public?

Alessio Ferrari

Alessio Ferrari Program Co-Chair

Birgit Penzenstadler

Birgit Penzenstadler Program Co-Chair

Sallam Abualhaija

Sallam Abualhaija

University of luxembourg.

Carina Alves

Carina Alves

Universidade federal de pernambuco.

Daniel Amyot

Daniel Amyot

University of ottawa.

Chetan Arora

Chetan Arora

Monash university.

Fatma Başak Aydemir

Fatma Başak Aydemir

Boğaziçi university.

Nelly Bencomo

Nelly Bencomo

Durham university, united kingdom.

Dan Berry

University of Waterloo

Sjaak Brinkkemper

Sjaak Brinkkemper

Utrecht university, netherlands.

Nelly Condori-Fernández

Nelly Condori-Fernández

Universidad de santiago de compostela.

Fabiano Dalpiaz

Fabiano Dalpiaz

Maya Daneva

Maya Daneva

University of twente.

Joerg Doerr

Joerg Doerr

Fraunhofer iese.

Xavier Franch

Xavier Franch

Universitat politècnica de catalunya.

Samuel Fricker

Samuel Fricker

Switzerland.

Davide Fucci

Davide Fucci

Blekinge institute of technology.

Matthias Galster

Matthias Galster

University of canterbury, new zealand.

Vincenzo Gervasi

Vincenzo Gervasi

University of pisa.

Martin Glinz

Martin Glinz

University of zurich.

Michael Goedicke

Michael Goedicke

Paluno – the ruhr institute for software technology, university of duisburg-essen, essen.

Eduard C. Groen

Eduard C. Groen

Paul Grünbacher

Paul Grünbacher

Johannes kepler university linz, austria.

Renata Guizzardi

Renata Guizzardi

University of twente, the netherlands.

Andrea Herrmann

Andrea Herrmann

Herrmann & ehrlich.

Anne Hess

Jennifer Horkoff

Chalmers and the university of gothenburg.

micro-avatar

Erik Kamsties

Fh dortmund.

Eric Knauss

Eric Knauss

Chalmers | university of gothenburg.

Sylwia Kopczyńska

Sylwia Kopczyńska

Poznan university of technology.

Kim Lauenroth

Kim Lauenroth

Emmanuel Letier

Emmanuel Letier

University college london.

Grischa Liebel

Grischa Liebel

Reykjavik university.

Nazim Madhavji

Nazim Madhavji

Western university.

Daniel Mendez

Daniel Mendez

Luisa Mich

University of Trento

Lloyd Montgomery

Lloyd Montgomery

Universität hamburg.

Gunter Mussbacher

Gunter Mussbacher

Mcgill university.

John Mylopoulos

John Mylopoulos

Nan Niu

University of Cincinnati

United states.

Andreas L Opdahl

Andreas L Opdahl

University of bergen.

Shola Oyedeji

Shola Oyedeji

Lut university.

Barbara Paech

Barbara Paech

Heidelberg university.

Elda Paja

IT University of Copenhagen

Liliana Pasquale

Liliana Pasquale

University college dublin & lero.

Oscar Pastor

Oscar Pastor

Universitat politecnica de valencia.

Anna Perini

Anna Perini

Fondazione bruno kessler.

Björn Regnell

Björn Regnell

Lund university.

Marcela Ruiz

Marcela Ruiz

Zurich university of applied sciences (zhaw).

Mehrdad Sabetzadeh

Mehrdad Sabetzadeh

Klaus Schmid

Klaus Schmid

Stiftung university hildesheim.

Kurt Schneider

Kurt Schneider

Leibniz universität hannover, software engineering group.

Laura Semini

Laura Semini

Università di pisa - dipartimento di informatica.

Norbert Seyff

Norbert Seyff

University of applied sciences and arts northwestern switzerland fhnw.

Paola Spoletini

Paola Spoletini

Kennesaw state university, betz stefanie, hs furtwangen.

Jan-Philipp Steghöfer

Jan-Philipp Steghöfer

Xitaso gmbh it & software solutions.

Angelo Susi

Angelo Susi

Michael Unterkalmsteiner

Michael Unterkalmsteiner

Colin C. Venter

Colin C. Venter

University of huddersfield.

Michael Vierhauser

Michael Vierhauser

Johannes kepler university linz.

Andreas Vogelsang

Andreas Vogelsang

University of cologne.

Liping Zhao

Liping Zhao

University fo manchester.

Didar Zowghi

Didar Zowghi

Csiro's data61.

requirement engineering research papers

Volumes and issues

Volume 28 march - december 2023 mar - dec 2023.

  • Issue 4 December 2023
  • Issue 3 September 2023
  • Issue 2 June 2023

Special Issue of the REFSQ 2021 conference

Volume 27 March - December 2022 Mar - Dec 2022

Special Issue of the International Requirements Engineering Conference (RE’21)

Special Issue of the best papers of Requirements Engineering 2020

  • Issue 2 June 2022
  • Issue 1 March 2022

Volume 26 March - December 2021 Mar - Dec 2021

  • Issue 4 December 2021
  • Issue 3 September 2021
  • Issue 2 June 2021
  • Issue 1 March 2021

Volume 25 March - December 2020 Mar - Dec 2020

Special Issue: RE 19

  • Issue 3 September 2020
  • Issue 2 June 2020
  • Issue 1 March 2020

Volume 24 March - December 2019 Mar - Dec 2019

  • Issue 4 December 2019

Special Issue: RE 2018

  • Issue 2 June 2019
  • Issue 1 March 2019

Volume 23 March - November 2018 Mar - Nov 2018

  • Issue 4 November 2018

Special Issue: RE 2017

  • Issue 2 June 2018
  • Issue 1 March 2018

Volume 22 March - November 2017 Mar - Nov 2017

  • Issue 4 November 2017

Special Issue on RE 2016

  • Issue 2 June 2017
  • Issue 1 March 2017

Volume 21 March - November 2016 Mar - Nov 2016

  • Issue 4 November 2016

Special Issue on RE 2015

  • Issue 2 June 2016
  • Issue 1 March 2016

Volume 20 March - November 2015 Mar - Nov 2015

  • Issue 4 November 2015

Special Issue on RE 2014 (pp 213-280)

  • Issue 2 June 2015
  • Issue 1 March 2015

Volume 19 March - November 2014 Mar - Nov 2014

Special Issue on Requirements Engineering in Software Product Line Engineering

Special Issue on RE 2013

  • Issue 2 June 2014
  • Issue 1 March 2014

Volume 18 March - November 2013 Mar - Nov 2013

Special Issue on Requirements Engineering for Security, Privacy and Services in Cloud Environments

  • Issue 3 September 2013

SI: RE 2012

  • Issue 1 March 2013

Volume 17 March - November 2012 Mar - Nov 2012

Special Issue on Quality Requirement Engineering for Systems & Architecting

  • Issue 3 September 2012

Special Issue: RE'11 Best Papers

Special Issue on REFSQ 2011

Volume 16 March - November 2011 Mar - Nov 2011

  • Issue 4 November 2011

Special Issue on Best Papers of RE'10: Requirements Engineering in a Multi-faceted World

  • Issue 2 June 2011

Special Issue on Digital privacy: theory, policies and technologies

Volume 15 March - November 2010 Mar - Nov 2010

  • Issue 4 November 2010
  • Issue 3 September 2010

RE’09 Special Issue; Guest Editor:Kevin T Ryan

Special Issue on RE'09: Security Requirements Engineering; Guest Editors: Eric Dubois and Haralambos Mouratidis

Volume 14 February - December 2009 Feb - Dec 2009

Special Issue on RE'08: Requirements Engineering for a Sustainable World; Guest Editor: T. Tamai

  • Issue 3 July 2009
  • Issue 2 June 2009
  • Issue 1 February 2009

Volume 13 January - November 2008 Jan - Nov 2008

  • Issue 4 November 2008
  • Issue 3 September 2008
  • Issue 2 June 2008
  • Issue 1 January 2008

Volume 12 January - October 2007 Jan - Oct 2007

  • Issue 4 October 2007
  • Issue 3 July 2007
  • Issue 2 April 2007
  • Issue 1 January 2007

Volume 11 March - September 2006 Mar - Sept 2006

  • Issue 4 September 2006
  • Issue 3 June 2006
  • Issue 2 April 2006
  • Issue 1 March 2006

Volume 10 January - November 2005 Jan - Nov 2005

  • Issue 4 November 2005
  • Issue 3 August 2005
  • Issue 2 May 2005
  • Issue 1 January 2005

Volume 9 February - November 2004 Feb - Nov 2004

  • Issue 4 November 2004
  • Issue 3 August 2004
  • Issue 2 May 2004
  • Issue 1 February 2004

Volume 8 February - November 2003 Feb - Nov 2003

  • Issue 4 November 2003
  • Issue 3 August 2003
  • Issue 2 July 2003
  • Issue 1 February 2003

Volume 7 April - December 2002 Apr - Dec 2002

  • Issue 4 December 2002
  • Issue 3 September 2002
  • Issue 2 June 2002
  • Issue 1 April 2002

Volume 6 February 2001 - January 2002 Feb 2001 - Jan 2002

  • Issue 4 January 2002
  • Issue 3 October 2001
  • Issue 2 June 2001
  • Issue 1 February 2001

Volume 5 July - December 2000 Jul - Dec 2000

  • Issue 4 December 2000
  • Issue 3 October 2000
  • Issue 2 September 2000
  • Issue 1 July 2000

Volume 4 May - December 1999 May - Dec 1999

  • Issue 4 December 1999
  • Issue 3 September 1999
  • Issue 2 July 1999
  • Issue 1 May 1999

Volume 3 March - June 1998 Mar - Jun 1998

  • Issue 2 June 1998
  • Issue 3-4 March 1998
  • Issue 1 March 1998

Volume 2 March - December 1997 Mar - Dec 1997

  • Issue 4 December 1997
  • Issue 3 September 1997
  • Issue 2 June 1997
  • Issue 1 March 1997

Volume 1 March - December 1996 Mar - Dec 1996

  • Issue 4 December 1996
  • Issue 3 September 1996
  • Issue 2 June 1996
  • Issue 1 March 1996
  • Find a journal
  • Publish with us
  • Track your research

iMessage with PQ3: The new state of the art in quantum-secure messaging at scale

Today we are announcing the most significant cryptographic security upgrade in iMessage history with the introduction of PQ3, a groundbreaking post-quantum cryptographic protocol that advances the state of the art of end-to-end secure messaging. With compromise-resilient encryption and extensive defenses against even highly sophisticated quantum attacks, PQ3 is the first messaging protocol to reach what we call Level 3 security — providing protocol protections that surpass those in all other widely deployed messaging apps. To our knowledge, PQ3 has the strongest security properties of any at-scale messaging protocol in the world.

When iMessage launched in 2011, it was the first widely available messaging app to provide end-to-end encryption by default, and we have significantly upgraded its cryptography over the years. We most recently strengthened the iMessage cryptographic protocol in 2019 by switching from RSA to Elliptic Curve cryptography (ECC), and by protecting encryption keys on device with the Secure Enclave, making them significantly harder to extract from a device even for the most sophisticated adversaries. That protocol update went even further with an additional layer of defense: a periodic rekey mechanism to provide cryptographic self-healing even in the extremely unlikely case that a key ever became compromised. Each of these advances were formally verified by symbolic evaluation, a best practice that provides strong assurances of the security of cryptographic protocols.

Historically, messaging platforms have used classical public key cryptography, such as RSA, Elliptic Curve signatures, and Diffie-Hellman key exchange, to establish secure end-to-end encrypted connections between devices. All these algorithms are based on difficult mathematical problems that have long been considered too computationally intensive for computers to solve, even when accounting for Moore’s law. However, the rise of quantum computing threatens to change the equation. A sufficiently powerful quantum computer could solve these classical mathematical problems in fundamentally different ways, and therefore — in theory — do so fast enough to threaten the security of end-to-end encrypted communications.

Although quantum computers with this capability don’t exist yet, extremely well-resourced attackers can already prepare for their possible arrival by taking advantage of the steep decrease in modern data storage costs. The premise is simple: such attackers can collect large amounts of today’s encrypted data and file it all away for future reference. Even though they can’t decrypt any of this data today, they can retain it until they acquire a quantum computer that can decrypt it in the future, an attack scenario known as Harvest Now, Decrypt Later .

To mitigate risks from future quantum computers, the cryptographic community has been working on post-quantum cryptography (PQC): new public key algorithms that provide the building blocks for quantum-secure protocols but don’t require a quantum computer to run — that is, protocols that can run on the classical, non-quantum computers we’re all using today, but that will remain secure from known threats posed by future quantum computers.

To reason through how various messaging applications mitigate attacks, it’s helpful to place them along a spectrum of security properties. There’s no standard comparison to employ for this purpose, so we lay out our own simple, coarse-grained progression of messaging security levels in the image at the top of this post: we start on the left with classical cryptography and progress towards quantum security, which addresses current and future threats from quantum computers. Most existing messaging apps fall either into Level 0 — no end-to-end encryption by default and no quantum security — or Level 1 — with end-to-end encryption by default, but with no quantum security. A few months ago, Signal added support for the PQXDH protocol, becoming the first large-scale messaging app to introduce post-quantum security in the initial key establishment. This is a welcome and critical step that, by our scale, elevated Signal from Level 1 to Level 2 security.

At Level 2, the application of post-quantum cryptography is limited to the initial key establishment, providing quantum security only if the conversation key material is never compromised. But today’s sophisticated adversaries already have incentives to compromise encryption keys, because doing so gives them the ability to decrypt messages protected by those keys for as long as the keys don’t change. To best protect end-to-end encrypted messaging, the post-quantum keys need to change on an ongoing basis to place an upper bound on how much of a conversation can be exposed by any single, point-in-time key compromise — both now and with future quantum computers. Therefore, we believe messaging protocols should go even further and attain Level 3 security, where post-quantum cryptography is used to secure both the initial key establishment and the ongoing message exchange, with the ability to rapidly and automatically restore the cryptographic security of a conversation even if a given key becomes compromised.

iMessage now meets this goal with a new cryptographic protocol that we call PQ3, offering the strongest protection against quantum attacks and becoming the only widely available messaging service to reach Level 3 security. Support for PQ3 will start to roll out with the public releases of iOS 17.4, iPadOS 17.4, macOS 14.4, and watchOS 10.4, and is already in the corresponding developer preview and beta releases. iMessage conversations between devices that support PQ3 are automatically ramping up to the post-quantum encryption protocol. As we gain operational experience with PQ3 at the massive global scale of iMessage, it will fully replace the existing protocol within all supported conversations this year.

Designing PQ3

More than simply replacing an existing algorithm with a new one, we rebuilt the iMessage cryptographic protocol from the ground up to advance the state of the art in end-to-end encryption, and to deliver on the following requirements:

  • Introduce post-quantum cryptography from the start of a conversation, so that all communication is protected from current and future adversaries.
  • Mitigate the impact of key compromises by limiting how many past and future messages can be decrypted with a single compromised key.
  • Use a hybrid design to combine new post-quantum algorithms with current Elliptic Curve algorithms, ensuring that PQ3 can can never be less safe than the existing classical protocol.
  • Amortize message size to avoid excessive additional overhead from the added security.
  • Use formal verification methods to provide strong security assurances for the new protocol.

PQ3 introduces a new post-quantum encryption key in the set of public keys each device generates locally and transmits to Apple servers as part of iMessage registration. For this application, we chose to use Kyber post-quantum public keys, an algorithm that received close scrutiny from the global cryptography community, and was selected by NIST as the Module Lattice-based Key Encapsulation Mechanism standard, or ML-KEM . This enables sender devices to obtain a receiver’s public keys and generate post-quantum encryption keys for the very first message, even if the receiver is offline. We refer to this as initial key establishment.

We then include — within conversations — a periodic post-quantum rekeying mechanism that has the ability to self-heal from key compromise and protect future messages. In PQ3, the new keys sent along with the conversation are used to create fresh message encryption keys that can’t be computed from past ones, thereby bringing the conversation back to a secure state even if previous keys were extracted or compromised by an adversary. PQ3 is the first large scale cryptographic messaging protocol to introduce this novel post-quantum rekeying property.

PQ3 employs a hybrid design that combines Elliptic Curve cryptography with post-quantum encryption both during the initial key establishment and during rekeying. Thus, the new cryptography is purely additive, and defeating PQ3 security requires defeating both the existing, classical ECC cryptography and the new post-quantum primitives. It also means the protocol benefits from all the experience we accumulated from deploying the ECC protocol and its implementations.

Rekeying in PQ3 involves transmitting fresh public key material in-band with the encrypted messages that devices are exchanging. A new public key based on Elliptic Curve Diffie-Hellman (ECDH) is transmitted inline with every response. The post-quantum key used by PQ3 has a significantly larger wire size than the existing protocol, so to meet our message size requirement we designed the quantum-secure rekeying to happen periodically rather than with every message. To determine whether a new post-quantum key is transmitted, PQ3 uses a rekeying condition that aims to balance the average size of messages on the wire, preserve the user experience in limited connectivity scenarios, and keep the global volume of messages within the capacity of our server infrastructure. Should the need arise, future software updates can increase the rekeying frequency in a way that’s backward-compatible with all devices that support PQ3.

With PQ3, iMessage continues to rely on classical cryptographic algorithms to authenticate the sender and verify the Contact Key Verification account key, because these mechanisms can’t be attacked retroactively with future quantum computers. To attempt to insert themselves in the middle of an iMessage conversation, an adversary would require a quantum computer capable of breaking one of the authentication keys before or at the time the communication takes place. In other words, these attacks cannot be performed in a Harvest Now, Decrypt Later scenario — they require the existence of a quantum computer capable of performing the attacks contemporaneously with the communication being attacked. We believe any such capability is still many years away, but as the threat of quantum computers evolves, we will continue to assess the need for post-quantum authentication to thwart such attacks.

A formally proven protocol

Our final requirement for iMessage PQ3 is formal verification — a mathematical proof of the intended security properties of the protocol. PQ3 received extensive review from Apple’s own multi-disciplinary teams in Security Engineering and Architecture (SEAR) as well as from some of the world’s foremost experts in cryptography. This includes a team led by Professor David Basin, head of the Information Security Group at ETH Zürich and one of the inventors of Tamarin — a leading security protocol verification tool that was also used to evaluate PQ3 — as well as Professor Douglas Stebila from the University of Waterloo, who has performed extensive research on post-quantum security for internet protocols. Each took a different but complementary approach, using different mathematical models to demonstrate that as long as the underlying cryptographic algorithms remain secure, so does PQ3. Finally, a leading third-party security consultancy supplemented our internal implementation review with an independent assessment of the PQ3 source code, which found no security issues.

In the first mathematical analysis, Security analysis of the iMessage PQ3 protocol , Professor Douglas Stebila focused on so-called game-based proofs. This technique, also known as reduction, defines a series of “games“ or logical statements to show that the protocol is at least as strong as the algorithms that underpin it. Stebila’s analysis shows that PQ3 provides confidentiality even in the presence of some key compromises against both classical and quantum adversaries, in both the initial key establishment and the ongoing rekeying phase of the protocol. The analysis decomposes the many layers of key derivations down to the message keys and proves that, for an attacker, they are indistinguishable from random noise. Through an extensive demonstration that considers different attack paths for classical and quantum attackers in the proofs, Stebila shows that the keys used for PQ3 are secure as long as either the Elliptic Curve Diffie-Hellman problem remains hard or the Kyber post-quantum KEM remains secure.

The iMessage PQ3 protocol is a well-designed cryptographic protocol for secure messaging that uses state-of-the-art techniques for end-to-end encrypted communication. In my analysis using the reductionist security methodology, I confirmed that the PQ3 protocol provides post-quantum confidentiality, which can give users confidence in the privacy of their communication even in the face of potential improvements in quantum computing technology. —Professor Douglas Stebila

In the second evaluation, A Formal Analysis of the iMessage PQ3 Messaging Protocol , Prof. David Basin, Felix Linker, and Dr. Ralf Sasse at ETH Zürich use a method called symbolic evaluation. As highlighted in the paper’s abstract, this analysis includes a detailed formal model of the iMessage PQ3 protocol, a precise specification of its fine-grained security properties, and machine-checked proofs using the state-of-the-art symbolic Tamarin prover . The evaluation yielded a fine-grained analysis of the secrecy properties of PQ3, proving that “in the absence of the sender or recipient being compromised, all keys and messages transmitted are secret” and that “compromises can be tolerated in a well-defined sense where the effect of the compromise on the secrecy of data is limited in time and effect,” which confirms that PQ3 meets our goals.

We provide a mathematical model of PQ3 as well as prove its secrecy and authenticity properties using a verification tool for machine-checked security proofs. We prove the properties even when the protocol operates in the presence of very strong adversaries who can corrupt parties or possess quantum computers and therefore defeat classical cryptography. PQ3 goes beyond Signal with regards to post-quantum defenses. In PQ3, a post-quantum secure algorithm is part of the ratcheting and used repeatedly, rather than only once in the initialization as in Signal. Our verification provides a very high degree of assurance that the protocol as designed functions securely, even in the post-quantum world. —Professor David Basin

Diving into the details

Because we know PQ3 will be of intense interest to security researchers and engineers as well as the cryptographic community, this blog post is really two posts in one. Up to now, we laid out our design goals, outlined how PQ3 meets them, and explained how we verified our confidence in the protocol with independent assessments. If you’d like to understand more detail about the cryptographic underpinnings, the remainder of the post is a deeper dive into how we constructed the PQ3 protocol.

Post-quantum key establishment

iMessage allows a user to register multiple devices on the same account. Each device generates its own set of encryption keys, and the private keys are never exported to any external system. The associated public keys are registered with Apple’s Identity Directory Service (IDS) to enable users to message each other using a simple identifier: email address or phone number. When a user sends a message from one of their devices, all of their other devices and all of the recipient’s devices receive the message. The messages are exchanged through pair-wise sessions established between the sending device and each receiving device. The same message is encrypted successively to each receiving device, with keys uniquely derived for each session. For the rest of this description, we will focus on a single device-to-device session.

Because the receiving device might not be online when the conversation is established, the first message in a session is encrypted using the public encryption keys registered with the IDS server.

Each device with PQ3 registers two public encryption keys and replaces them regularly with fresh ones:

  • A post-quantum Kyber-1024 key encapsulation public key
  • A classical P-256 Elliptic Curve key agreement public key

These encryption keys are signed with ECDSA using a P-256 authentication key generated by the device’s Secure Enclave, along with a timestamp used to limit their validity. The device authentication public key is itself signed by the Contact Key Verification account key, along with some attributes such as the supported cryptographic protocol version. This process allows the sender to verify that the recipient device’s public encryption keys were uploaded by the intended recipient, and it guards against downgrade attacks.

When Alice’s device instantiates a new session with Bob’s device, her device queries the IDS server for the key bundle associated with Bob’s device. The subset of the key bundle that contains the device’s authentication key and versioning information is validated using Contact Key Verification. The device then validates the signature covering the encryption keys and timestamps, which attests that the keys are valid and have not expired.

Alice’s device can then use the two public encryption keys to share two symmetric keys with Bob. The first symmetric key is computed through an ECDH key exchange that combines an ephemeral encryption key from Alice with Bob’s registered P-256 public key. The second symmetric key is obtained from a Kyber key encapsulation with Bob’s post-quantum public key.

To combine these two symmetric keys, we first extract their entropy by invoking HKDF-SHA384-Extract twice — once for each of the keys. The resulting 48-byte secret is further combined with a domain separation string and session information — which includes the user’s identifiers, the public keys used in the key exchange, and the encapsulated secret — by invoking HKDF-SHA384-Extract again to derive the session’s initial keying state. This combination ensures that the initial session state cannot be derived without knowing both of the shared secrets, meaning an attacker would need to break both algorithms to recover the resulting secret, thus satisfying our hybrid security requirement.

Post-quantum rekeying

Ongoing rekeying of the cryptographic session is designed such that keys used to encrypt past and future messages cannot be recomputed even by a powerful hypothetical attacker who is able to extract the cryptographic state of the device at a given point in time. The protocol generates a new unique key for each message, which periodically includes new entropy that is not deterministically derived from the current state of the conversation, effectively providing self-healing properties to the protocol. Our rekeying approach is modeled after ratcheting, a technique that consists of deriving a new session key from other keys and ensuring the cryptographic state always moves forward in one direction. PQ3 combines three ratchets to achieve post-quantum encryption.

The first ratchet, called the symmetric ratchet, protects older messages in a conversation to achieve forward secrecy. For every message, we derive a per-message encryption key from the current session key. The current session key itself is then further derived into a new session key, ratcheting the state forward. Each message key is deleted as soon as a corresponding message is decrypted, which prevents older harvested ciphertexts from being decrypted by an adversary who is able to compromise the device at a later time, and provides protection against replayed messages. This process uses 256-bit keys and intermediate values, and HKDF-SHA384 as a derivation function, which provides protection against both classical and quantum computers.

The second ratchet, called the ECDH ratchet, protects future messages by updating the session with fresh entropy from an Elliptic Curve key agreement, ensuring that an adversary loses the ability to decrypt new messages even if they had compromised past session keys — a property called post-compromise security. The ECDH-based ratchet has a symmetrical flow: the private key of the outgoing ratchet public key from the sender is used with the last public key received from the recipient to establish a new shared secret between sender and receiver, which is then mixed into the session’s key material. The new PQ3 protocol for iMessage uses NIST P-256 Elliptic Curve keys to perform this ratchet, which imposes only a small 32-byte overhead on each message.

Because the second ratchet uses classical cryptography, PQ3 also adds a conditionally executed Kyber KEM-based ratchet. This third ratchet complements the ECDH-based ratchet to provide post-compromise security against Harvest Now, Decrypt Later quantum attacks as well.

The use of a post-quantum ratchet can cause significant network overhead compared to an ECDH-based ratchet at the same security level. The post-quantum KEM requires sending both a public key and an encapsulated secret instead of a single outgoing public key. In addition, the underlying mathematical structure for quantum security requires significantly larger parameter sizes for public keys and encapsulated keys compared to Elliptic Curves.

To limit the size overhead incurred by frequent rekeying while preserving a high level of security, the post-quantum KEM is instantiated with Kyber-768. Unlike the IDS-registered public keys used for the initial key establishment, ratcheting public keys are used only once to encapsulate a shared secret to the receiver, significantly limiting the impact of the compromise of a single key. However, while a 32-byte ECDH-based ratchet overhead is acceptable on every message, the post-quantum KEM ratchet increases the message size by more than 2 kilobytes. To avoid visible delays in message delivery when device connectivity is limited, this ratchet needs to be amortized over multiple messages.

We therefore implemented an adaptive post-quantum rekeying criterion that takes into account the number of outgoing messages, the time elapsed since last rekeying, and current connectivity conditions. At launch, this means the post-quantum ratchet is performed approximately every 50 messages, but the criterion is bounded such that rekeying is always guaranteed to occur at least once every 7 days. And as we mentioned earlier, as the threat of quantum computers and infrastructure capacity evolves over time, future software updates can increase the rekeying frequency while preserving full backward compatibility.

Completing the public key ratchets, whether based on ECDH or Kyber, requires sending and receiving a message. Although users may not immediately reply to a message, iMessage includes encrypted delivery receipts that allow devices to rapidly complete the ratchet even without a reply from the recipient, as long as the device is online. This technique avoids delays in the rekeying process and helps support strong post-compromise recovery.

Similar to the initial session key establishment, the secrets established through the three ratchets are all combined with an evolving session key using HKDF-SHA384 through sequential calls to the Extract function. At the end of this process, we obtain a final message key, which can now be used to encrypt the payload.

Padding and encryption

To avoid leaking information about the message size, PQ3 adds padding to the message before encryption. This padding is implemented with the Padmé heuristic, which specifically limits the information leakage of ciphertexts with maximum length M to a practical optimum of O(log log M) bits. This is comparable to padding to a power of two but results in a lower overhead of at most 12 percent and even lower for larger payloads. This approach strikes an excellent balance between privacy and efficiency, and preserves the user experience in limited device connectivity scenarios.

The padded payload is encrypted with AES-CTR using a 256-bit encryption key and initialization vector, both derived from the message key. While public key algorithms require fundamental changes to achieve quantum security, symmetric cryptography algorithms like the AES block cipher only require doubling the key size to maintain their level of security against quantum computers.

Authentication

Each message is individually signed with ECDSA using the elliptic curve P-256 device authentication key protected by the Secure Enclave. The receiving device verifies the mapping between the sender’s identifier (email address or phone number) and the public key used for signature verification. If both users have enabled Contact Key Verification and verified each other’s account key, the device verifies that the device authentication keys are present in the Key Transparency log and that the corresponding account key matches the account key stored in the user’s iCloud Keychain.

The device’s authentication key is generated by the Secure Enclave and never exposed to the rest of the device, which helps prevent extraction of the private key even if the Application Processor is completely compromised. If an attacker were to compromise the Application Processor, they might be able to use the Secure Enclave to sign arbitrary messages. But after the device recovers from the compromise through a reboot or a software update, they would no longer be able to impersonate the user. This approach offers stronger guarantees than other messaging protocols where the authentication key is sometimes shared between devices or where the authentication takes place only at the beginning of the session.

The message signature covers a wide range of fields, including the unique identifiers of the users and their push notification tokens, the encrypted payload, authenticated data, a ratchet-derived message key indicator that binds the signature to a unique location in the ratchet, and any public key information used in the protocol. The inclusion of these fields in the signature guarantees that the message can only be used in the context intended by the sender, and all the fields are exhaustively documented in the research papers from Stebila, Basin, and collaborators.

End-to-end encrypted messaging has seen a tremendous amount of innovation in recent years, including significant advances in post-quantum cryptography from Signal’s PQXDH protocol and in key transparency from WhatsApp’s Auditable Key Directory. Building on its pioneering legacy as the first widely available messaging app to provide end-to-end encryption by default, iMessage has continued to deliver advanced protections that surpass existing systems. iMessage Contact Key Verification is the most sophisticated key transparency system for messaging deployed at scale, and is the current global state of the art for automatic key verification. And the new PQ3 cryptographic protocol for iMessage combines post-quantum initial key establishment with three ongoing ratchets for self-healing against key compromise, defining the global state of the art for protecting messages against Harvest Now, Decrypt Later attacks and future quantum computers.

  • Venue: Leibniz Universität Hannover
  • Registration
  • Visa Support
  • Instructions for Authors
  • Explore Hannover
  • How to get there
  • Accomodation
  • Promote RE'23
  • Complete Program
  • Your Program
  • Requirements Engineering 2023
  • Research Papers
  • RE@Next! Papers
  • Industrial Innovation Papers
  • Posters and Tool Demos
  • Doctoral Symposium
  • Journal-First
  • Student Volunteers
  • Requirements Engineering 2023 Committees
  • Organizing Committee
  • Track Committees
  • Contributors
  • People Index
  • Requirements Engineering 2024
  • Requirements Engineering 2022
  • Requirements Engineering 2021

RE@Next! Papers Requirements Engineering 2023

Accepted papers, submission instructions, re@next call for papers.

Please find the review criteria for RE@Next paper here .

Program Display Configuration

Mon 4 sep displayed time zone: amsterdam, berlin, bern, rome, stockholm, vienna change, wed 6 sep displayed time zone: amsterdam, berlin, bern, rome, stockholm, vienna change, thu 7 sep displayed time zone: amsterdam, berlin, bern, rome, stockholm, vienna change, fri 8 sep displayed time zone: amsterdam, berlin, bern, rome, stockholm, vienna change.

A good RE@Next! contribution will:

  • provide in succinct form the information that you would convey in a seminar about your ongoing research work to a fellow academic visiting your department;
  • compare your novel idea to existing work and clearly show how your ongoing work is going to extend the state-of-the-art;
  • include the targeted research questions and the research methodology you propose to address them;
  • show the feasibility of your work by presenting preliminary results, such as a convincing review of well-established prior work, a pilot study based on a reasonably sophisticated example problem, or early results from an exploratory qualitative or quantitative study;
  • present the long-term directions and prospects of your research endeavour.

For further information and Word/Latex templates please check the main call for papers

Submission Link

Please submit your paper in PDF format via EasyChair . Select the RE’23 RE@Next! Track for your submission.

Neil Ernst

Neil Ernst RE@Next! Co-Chair

University of victoria.

Marcela Ruiz

Marcela Ruiz RE@Next! Co-Chair

Zurich university of applied sciences (zhaw), switzerland.

Dalal Alrajeh

Dalal Alrajeh

Imperial college london, united kingdom.

micro-avatar

João Araújo

Universidade nova de lisboa - portugal, eya ben charrada, university of zurich.

Stefanie Betz

Stefanie Betz

Furtwangen university & lut university.

Jean-Michel Bruel

Jean-Michel Bruel

Université de toulouse, france.

Ruzanna Chitchyan

Ruzanna Chitchyan

University of bristol.

Nelly Condori-Fernández

Nelly Condori-Fernández

Universidad de santiago de compostela, letícia duboc, universidade do estado do río de janeiro.

Vincenzo Gervasi

Vincenzo Gervasi

University of pisa.

Eduard C. Groen

Eduard C. Groen

Fraunhofer iese.

Iris Groher

Iris Groher

Johannes kepler university, linz.

Renata Guizzardi

Renata Guizzardi

University of twente, the netherlands, netherlands.

Hans-Martin Heyn

Hans-Martin Heyn

University of gothenburg & chalmers university of technology.

Zhi Jin

Peking University

Blagovesta Kostova

Blagovesta Kostova

Epfl, switzerland.

Roxana L. Q. Portugal

Roxana L. Q. Portugal

Maria lencastre, universidade de pernambuco.

Gunter Mussbacher

Gunter Mussbacher

Mcgill university.

Oscar Pastor

Oscar Pastor

Universitat politecnica de valencia.

Mona Rahimi

Mona Rahimi

Northern illinois university, united states.

Jolita Ralyté

Jolita Ralyté

University of geneva.

Nicolas Sannier

Nicolas Sannier

University of luxembourg, snt.

Isabel Sofia Sousa Brito

Isabel Sofia Sousa Brito

Instituto politécnico de beja.

Jan-Philipp Steghöfer

Jan-Philipp Steghöfer

Xitaso gmbh it & software solutions.

Kenji Tei

Waseda University

James Tizard

James Tizard

University of auckland, new zealand.

Michael Wahler

Michael Wahler

University of toronto.

Andrea Zisman

Andrea Zisman

The open university.

Jose Luis de la Vara

Jose Luis de la Vara

Universidad de castilla - la mancha.

IMAGES

  1. (PDF) Requirement Engineering Research

    requirement engineering research papers

  2. (PDF) Published Research on Engineering Work

    requirement engineering research papers

  3. Draft For Research Paper Example : How to Write an APA Research Paper

    requirement engineering research papers

  4. (PDF) Requirement Engineering Practices

    requirement engineering research papers

  5. (PDF) A Review of Requirement Engineering Issues and Challenges in

    requirement engineering research papers

  6. (PDF) Improving the Requirement Engineering Process with Speed-Reviews

    requirement engineering research papers

VIDEO

  1. Final Research Project

  2. Requirement Engineering Process: Elicitation, Analysis, Documentation

  3. Tutorial class of Research (step 1)

  4. Goals of Requirement engineering || Software Engineering

  5. Step-by-step approach to starting and completing a good research paper

  6. BCS Requirements Engineering: Question 4 Sample Paper 1 Walkthrough

COMMENTS

  1. Empirical research in requirements engineering: trends and opportunities:

    Empirical research in requirements engineering: trends and opportunities: DOI: Authors: Talat Ambreen International Islamic University, Islamabad Naveed Ikram Riphah International University...

  2. (PDF) Requirement Engineering Research

    Requirement Engineering Research development processes. House, New Delhi, 2004. pp 35-46. 449 Citations (5) ... They termed Requirement Engineering as "a systematic approach through which...

  3. Home

    Requirements Engineering is a multi-disciplinary journal focusing on the elicitation, representation, and validation of software-intensive information systems or applications. Includes theories and models relevant to requirements engineering. Explores the intersection of requirements engineering with business engineering.

  4. Requirement Engineering Challenges: A Systematic Mapping ...

    1 Introduction Requirement engineering (RE) is the most important phase of the software development life cycle (SDLC) [ 1 ]. RE is the process of discovering stakeholders' requirements and needs and documenting them in such a way that they can serve as the basis for all other system development activities [ 1 ].

  5. A systematic literature review of requirements engineering education

    8 Citations Explore all metrics Abstract Requirements engineering (RE) has established itself as a core software engineering discipline. It is well acknowledged that good RE leads to higher quality software and considerably reduces the risk of failure or budget-overspending of software development projects.

  6. Requirements Engineering 2023

    Fri 10 Mar 2023 Abstract Submission Submission Link https://easychair.org/conferences/?conf=re23 Program Committee Jennifer Horkoff PC Chair Chalmers and the University of Gothenburg Sweden Fabiano Dalpiaz PC Chair Utrecht University Netherlands Raian Ali HBKU

  7. Research Directions in Requirements Engineering

    Abstract: In this paper, we review current requirements engineering (RE) research and identify future research directions suggested by emerging software needs. First, we overview the state of the art in RE research.

  8. Requirements Engineering 2021

    Research Papers Requirements Engineering 2021. The IEEE International Requirements Engineering Conference (RE) is the premier requirements engineering conference where researchers, practitioners, students, and educators meet, present and discuss the most recent innovations, trends, experiences and issues in the field of requirements engineering.

  9. Requirements Engineering: Practice and Research

    Requirements engineering (RE) is a multidisciplinary and human-centered process that is integrated with both systems engineering and software engineering and provides a shared vision and understanding of complex systems throughout their life-cycles.

  10. PDF Requirements Engineering for Artificial Intelligence Systems: A

    guidelines for conducting systematic mapping studies in software engineering to answer the following research questions(RQs): ... and the first author read through each paper and used an open-coding procedure on each transcript to ... Which Requirements Engineering Frameworks, Notations, Modeling Languages, and Tools have been Proposed to ...

  11. Special Issue on Requirements Engineering, Practice and Research

    Topics of interest considered relevant were the following: RE control natural languages (CNLs); RE visual and modeling languages; RE for specific domains, such as cyber-physical systems, big data, or AI applications; automatic analysis of requirement specifications; RE and natural language processing (NLP) techniques; software tools and platform...

  12. Requirements Engineering 2022

    The IEEE International Requirements Engineering Conference (RE) is the premier requirements engineering conference where researchers, practitioners, students, and educators meet, present, and discuss the most recent innovations, trends, experiences, and issues in the field of requirements engineering.

  13. Empirical research on requirements quality: a systematic ...

    Requirements Engineering Article Empirical research on requirements quality: a systematic mapping study Original Article Open access Published: 15 February 2022 Volume 27 , pages 183-209, ( 2022 ) Cite this article Download PDF You have full access to this open access article Requirements Engineering Aims and scope Submit manuscript

  14. Scientific Approaches to Requirements Engineering: Research ...

    Feature papers represent the most advanced research with significant potential for high impact in the field. A Feature Paper should be a substantial original Article that involves several techniques or approaches, provides an outlook for future research directions and describes possible research applications. ... Requirements engineering is a ...

  15. (PDF) Research Directions in Requirements Engineering

    In this paper, we review current requirements engineering (RE) research and identify future research directions suggested by emerging software needs. First, we overview the state of the...

  16. A systematic literature review of requirements engineering education

    Studies on the state of requirements engineering education. In a recent REFSQ conference keynote, 1 Martin Glinz provided a survey spanning the past several decades on RE Education literature. Indeed, over the past 20 years, a series of reports have been published into the state of the art of software engineering education that are more or less concerned with aspects of requirements ...

  17. [PDF] Requirement Engineering Research

    In this presented article, some quality research approaches are cited for the software engineering researchers and software professionals about the validation of requirements. The requirement validation is vital for every successful software development. In this process, the requirements from the users are checks and analyzed with its consistency, completeness and correctness.

  18. REFSQ 2023

    Research Papers. Requirements Engineering (RE) is a critical factor in developing high-quality and successful software, systems, and services. The REFSQ working conference series is an established international forum for discussing current and state-of-the-art RE practices, celebrating its 29th edition.

  19. Requirements engineering for sustainable software systems: a ...

    1 Altmetric Explore all metrics Abstract Various approaches toward the development of sustainable software systems have been proposed by the requirements engineering community over the last decade. We conducted a systematic mapping study, analyzed 55 publications, and identified 29 approaches that have been published since the year 2000.

  20. (PDF) Requirements engineering paper classification and evaluation

    Requirements engineering paper classification and evaluation criteria: a proposal and a discussion Received: 29 July 2005 / Accepted: 18 October 2005 / Published online: 24 November 2005

  21. Volumes and issues

    Special Issue of the best papers of Requirements Engineering 2020 Issue 2 June 2022 Issue 1 March 2022 Volume 26 March - December 2021 Issue 4 December 2021 Issue 3 September 2021 Issue 2 June 2021 Issue 1 March 2021 Volume 25 March - December 2020 Issue 4 December 2020 Special Issue: RE 19 Issue 3 September 2020 Issue 2 June 2020

  22. Blog

    We are introducing PQ3, a groundbreaking cryptographic protocol for iMessage that advances the state of the art of end-to-end secure messaging. With compromise-resilient encryption and extensive defenses against even highly sophisticated quantum attacks, PQ3 provides protocol protections that surpass those in all other widely deployed messaging apps.

  23. RE@Next! Papers Requirements Engineering 2023

    The 31st IEEE International Requirements Engineering Conference (RE'23) will host the track RE@Next! to present in-progress research. The RE@Next! track is a venue to present ongoing work that has generated early or preliminary results. The goal is to trigger new collaborations with like-minded colleagues and potential industrial partners and to receive early feedback which can help you to ...

  24. Call For Paper-Requirements Engineering Bridging Theory, Research and

    Requirements engineering (RE) is a human-centered process seamlessly integrated into systems and software engineering. It aids our understanding of complex systems throughout their lifecycle ...