<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Advancing RE Education: Towards a Mapping Scheme for Benchmarking Students' Specification Skills</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Anthea Moravánszky</string-name>
          <email>anthea.moravanszky@fhgr.ch</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Samuel A. Fricker</string-name>
          <email>samuel.fricker@fhnw.ch</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="editor">
          <string-name>Requirements Specification, Specification Skills, Mapping Scheme1</string-name>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>University of Applied Sciences and Arts Northwestern Switzerland</institution>
          ,
          <addr-line>Bahnhofstrasse 5, 5210 Windisch</addr-line>
          ,
          <country country="CH">Switzerland</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>University of Szeged, Doctoral School of Education, Hungary &amp; University of Applied Sciences of the Grisons</institution>
          ,
          <addr-line>Pulvermühlestrasse 57, 7000 Chur</addr-line>
          ,
          <country country="CH">Switzerland</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>In Requirements Engineering (RE) Education, aligning students' requirements engineering skills with industry demands is one of the primary aims for educators. RE curricula vary between higher education institutes, but how they differ is difficult to describe. This paper proposes a novel mapping scheme to determine students' specification skills and, consequently, their industry readiness. This paper describes and motivates the scheme based on established bodies of knowledge in requirements engineering, syllabi for education and certification, and requirements specification standards. A preliminary validation of the scheme is provided by applying it to results produced by students of two RE courses taught at two universities of applied sciences, with the respective lecturer reviewing the accuracy and precision of its application. This paper describes the scheme and its development, outlines the preliminary validation process, and discusses its potential use for mapping RE education practices.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        The significance of preparing students for industry becomes evident in the requirement
specification skills discourse [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ]. Given the diverse expectations on RE skills across various
industries and ever-new challenges addressed by changing technologies for designing solutions,
educators must continuously update their RE curricula [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. Benchmarking is a strategic
approach to describing and comparing such practices and discussing the evolution of these
practices. A scheme for benchmarking is an instrument for structured and repeatable
documentation.
      </p>
      <p>
        In RE education, there is a scarcity of schemes for benchmarking. There are syllabi, such as
[
        <xref ref-type="bibr" rid="ref13">13</xref>
        ], that could be used for such benchmarking. While the intent of teaching such practices is
easy to determine in course descriptions, it is unclear how evidence about the students’ learned
ability to apply these practices would be documented so that these abilities can be identified
and compared between education providers. Today, there is only a limited understanding of the
RE practices being learned, and discussions between education providers regarding best
teaching practices and their improvement hardly occur.
      </p>
      <p>This paper aims to narrow this gap by proposing an evidence-based scheme for mapping
students' demonstrated specification skills. While specification skills are only a subset of the
requirement engineering practices being taught, they can be evaluated based on concrete results
that are created by the students.</p>
    </sec>
    <sec id="sec-2">
      <title>2. Background</title>
      <p>
        In software engineering, requirements specification documents are created to document the
results of RE activities. These documents contain software requirements and supplementary
details such as a vision, solution concept, reference documents, context, acceptance criteria, and
glossaries [
        <xref ref-type="bibr" rid="ref15 ref3">3, 15</xref>
        ]. Several works have addressed requirements specification and benchmarking
specification skills in the educational context. Fricker et al. [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] surveyed industry projects,
focusing on specification techniques. Their findings revealed diversity in the techniques and
methods employed, with natural language emerging as the predominant notation, often
complemented by integrating UML diagrams. Virodula and Fortino [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] assessed students'
requirement specification skills based on an Industry Body of Knowledge within a STEM
graduate program, aligning the curriculum with the International Institute of Business Analysts
(IIBA) standards. While successfully assessing theoretical knowledge, the study did not evaluate
students' practical application of requirements engineering (RE) specification skills. Anil and
Moiz [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ] introduced a comprehensive rubric for evaluating students' software requirements
specifications. While providing a foundational tool for educators to assess Software
Requirements Specifications (SRS), this rubric may require substantial modifications for
universal application across different universities, diverse SRS templates, or a combination of
single specification artefacts. The Requirements Engineering Ontology (REO) by Saito, Iimura,
and Aoyama [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] maps requirements engineering techniques based on three RE Bodies of
Knowledge (SWEBOK, BABOK, and REBoK). However, it lacks sufficient depth in outlining
recommended specification techniques for benchmarking students' specification skills.
      </p>
      <p>The primary goal of this work is to promote comparability between higher education
institutions. We do so here by assessing the specification skills of RE students. To achieve this,
we propose a mapping scheme for application across higher education RE courses. The scheme
focuses on mapping specification skills of students because it showcases their proficiency in
generating distinct requirements-related artefacts and applying techniques suitable for various
aspects of requirement specifications. We believe these specifications demonstrate that students
possess a robust understanding of RE, comprehend the interconnections between different RE
artefacts, and are capable of performing specific specification techniques, rendering them
'industry-ready.'</p>
    </sec>
    <sec id="sec-3">
      <title>3. Methodological Approach</title>
      <p>
        Addressing this gap involves a comprehensive examination encompassing Bodies of
Knowledge, model curricula, syllabi, and standards for identifying relevant RE specification
practices and requirements specification document templates. Our methodological approach is
based on the systematic mapping process outlined by Petersen et al. [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
      </p>
      <p>
        We selected our knowledge sources based on REE literature recommendations [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. We
included the Software Engineering Body of Knowledge SWEBOK [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] (version 3.0, 2014, since
SWEBOK 4.0 is still under review) and the guide to the Business Analysis Body of Knowledge
(BABOK) [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ]. Furthermore, we also included the RE Body of Knowledge (REBoK) [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ].
However, as the REBoK itself is only available in Japanese, we utilised a descriptive presentation
of the REBoK authored in English instead. We also included standards such as IEEE 29148:2018
[
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], which replaced earlier specifications. Additionally, the International Requirements
Engineering Board (IREB) syllabus [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] is a valuable resource, particularly the syllabus of the
CPRE FL certification. To address agile specification types, we incorporate Requirements
Artifacts of the Rational Unified Process [
        <xref ref-type="bibr" rid="ref14">14</xref>
        ], enhancing our mapping to encompass a
comprehensive range of RE specification practices. The screening process began with keywords
acquired from requirement types and specification techniques and structures in the
'specification' section of Fricker et al.'s [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] work on 'common requirements engineering
practices. From there, we mapped all our findings in the scheme and enhanced it with additional
findings from the screened sources. In each of the mentioned works, the respective chapters
were first read by one author, and then the entire work was subsequently searched again for
keywords by the same author. A second author reviewed the results and conducted random
checks via keyword searching.
      </p>
    </sec>
    <sec id="sec-4">
      <title>4. Mapping Scheme for RE Specification Practices</title>
      <p>
        The foundation of our mapping scheme was derived from Fricker et al.'s specification section
[
        <xref ref-type="bibr" rid="ref4">4</xref>
        ], which included "Requirement Types" and "Notations" as subparts. While we retained the
subsection on requirement types, our mapping results led us to separate notations to distinguish
specification techniques. Additionally, we introduced a new subsection, 'Requirements-related
Artefacts and Document Structures,' to provide a more nuanced and detailed section. The
decision not to include Storage was based on the understanding that it does not lend itself to
direct mapping from a student's specification.
      </p>
      <p>Fig. 1 shows the developed mapping scheme. It is designed to comprehensively address
various aspects of Requirements Engineering (RE) specifications, offering versatility in its
applications. A key feature is its ability to capture specification variations, encompassing not
only the count of specific elements but also their percentage representation to illustrate
different class sizes of students.</p>
      <p>The intended use of our mapping scheme is versatile and can serve multiple purposes: 1) For
Characterization of a Single Specification: Educators can employ the scheme to
comprehensively characterise and understand the nuances of individual students' specification
artifacts or entire specification documents. 2) For Characterization of Demonstrated Learning
Outcomes: The mapping scheme can be applied to assess and articulate the demonstrated
learning outcomes of a course in RE. 3) For Comparison Between Courses or Institutes:
Educators should be able to compare the demonstrated learning outcomes between different
courses or institutes of higher education, providing valuable insights for curriculum
development and improvement.</p>
    </sec>
    <sec id="sec-5">
      <title>5. Early Validation with two Universities of Applied Sciences</title>
      <p>Our mapping scheme underwent validation in two RE modules at different universities of
applied sciences offering bachelor's degree courses. Course A focuses on fundamental RE
practices such as requirements elicitation, analysis, validation, and management in software
development projects. It covers terminology, vision development, business analysis, prototype
workshops, and reviews of requirements specifications. Students explore requirements
specification languages and templates like Shall-, User Story-, and Use Case templates. Learning
objectives include understanding RE concepts, creating visions and requirements for software
systems, and quantifying quality requirements. The course emphasises developing release plans
within staged and agile software development lifecycles and includes group projects for
practical application. Course B is aligned with the syllabus of IREB CPRE FL and should prepare
students to pass the certification. Agile methods are excluded as they are part of a subsequent
course.</p>
      <p>Evaluating students' assignments reveals differences and commonalities. Most students use
Use Case Diagrams and Specifications, with familiarity with activity and class diagrams.
Functional and quality requirements are present and expressed through various methods. While
elements like vision and goals are recognised, other document structures, except for the product
backlog, were not recognised clearly.</p>
      <p>Lecturer A agreed with the mapping scheme's assessment, recognising its reflection of
taught requirements specification techniques and student choices. However, Lecturer A
suggested enhancing the scheme's sensitivity to detect more techniques in student documents
by establishing more explicit links between scheme categories and providing precise detection
guidelines for stakeholder descriptions.</p>
      <p>Regarding the assessment of Course B, Lecturer B noted that students were assigned three
specific tasks: 1.) writing functional and non-functional requirements; 2.) modeling a use case
diagram and writing a use case specification for one of the use cases of the diagram; 3.) modeling
an activity diagram and class diagram based on a description) instead of creating a coherent
requirement specification document, as for Course A. This resulted in a limited view and
detected coverage of specification skills and the demonstrated variety.</p>
    </sec>
    <sec id="sec-6">
      <title>6. Discussion</title>
      <p>Our work builds upon established knowledge frameworks to develop a mapping scheme to
assess students' specification skills in REE. Leveraging these frameworks, we aimed to create a
universal tool for mapping individual specification artefacts, thereby enabling the
benchmarking of courses or institutes by comparing students' specification skills demonstrated
in course assignments. The practical application of our mapping scheme uncovered its
effectiveness in characterising specification documents. However, it also revealed limitations,
particularly in supporting additional artefacts like implemented functional prototypes.
Challenges persisted in identifying specific templates, especially phrase-based and
documenttemplate-based approaches. The flexibility and adaptability of students' expression of
requirements were evident, but the nuanced task of differentiating between templates
necessitated further consideration. One potential threat to the validity of our evaluation was
the reliance on our works for testing the mapping scheme, introducing the risk of bias. To
mitigate this, further validations on a diverse set of works are imperative to ensure the
independence and generalizability of the mapping scheme.</p>
      <p>Our mapping scheme primarily reflects students' performance based on given assignments,
potentially limiting its ability to entirely capture acquired specification skills from the course.
The nature of the task assignment constrained the scope of skills showcased by the students,
underscoring the importance of considering the broader curriculum context when interpreting
the results. By providing insights into the nuances of students' performance and assignment
tasks, the paper contributes not only to the benchmarking of RE education but also offers a
pathway for continuous improvement in curriculum development. It encourages educators to
consider the broader implications of the mapping scheme, fostering further exploration and
adaptation to meet the industry's evolving demands and the diverse landscape of Requirements
Engineering education.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>T.</given-names>
            <surname>Virodula</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Fortino</surname>
          </string-name>
          ,
          <article-title>"</article-title>
          <source>Assessment of Systems Requirements Specification Skills Based on an Industry Body of Knowledge," IEEE Integrated STEM Education Conference (ISEC)</source>
          , Princeton, US,
          <year>2021</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>M.</given-names>
            <surname>Daun</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A. M.</given-names>
            <surname>Grubb</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Stenkova</surname>
          </string-name>
          , and
          <string-name>
            <given-names>B.</given-names>
            <surname>Tenbergen</surname>
          </string-name>
          ,
          <article-title>"A systematic literature review of requirements engineering education,"</article-title>
          <source>Requirements Engineering</source>
          , vol.
          <volume>28</volume>
          .2 (
          <year>2023</year>
          )
          <fpage>145</fpage>
          -
          <lpage>175</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>C.</given-names>
            <surname>Rupp</surname>
          </string-name>
          ,
          <string-name>
            <surname>Requirements-Engineering</surname>
          </string-name>
          und-Management:
          <article-title>Das Handbuch für Anforderungen in jeder Situation</article-title>
          , Carl Hanser Verlag,
          <year>2020</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>S. A.</given-names>
            <surname>Fricker</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Grau</surname>
          </string-name>
          ,
          <article-title>and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Zwingli</surname>
          </string-name>
          ,
          <article-title>"Requirements engineering: best practice," in Requirements Engineering for Digital Health</article-title>
          , Springer,
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>G. R.</given-names>
            <surname>Anil</surname>
          </string-name>
          and
          <string-name>
            <given-names>S. A.</given-names>
            <surname>Moiz</surname>
          </string-name>
          ,
          <article-title>"A holistic rubric for assessment of software requirements specification," 5th National Conference on E-Learning &amp;</article-title>
          <string-name>
            <surname>E-Learning</surname>
            <given-names>Technologies</given-names>
          </string-name>
          (ELELTECH), Hyderabad, India,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>S.</given-names>
            <surname>Saito</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Y.</given-names>
            <surname>Iimura</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Aoyama</surname>
          </string-name>
          ,
          <article-title>"REO: Requirements Engineering Ontology Spectrum Analysis of Requirements Engineering Knowledge and Its Practical Application,"</article-title>
          <source>IEEE 39th Annual Computer Software and Applications Conference</source>
          , Taichung, Taiwan,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>K.</given-names>
            <surname>Petersen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Vakkalanka</surname>
          </string-name>
          , and
          <string-name>
            <given-names>L.</given-names>
            <surname>Kuzniarz</surname>
          </string-name>
          ,
          <article-title>"Guidelines for conducting systematic mapping studies in software engineering: An update</article-title>
          ,
          <source>" Information and Software Technology</source>
          ,
          <volume>64</volume>
          (
          <year>2015</year>
          )
          <fpage>1</fpage>
          -
          <lpage>18</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>S.</given-names>
            <surname>Ouhbi</surname>
          </string-name>
          et al.,
          <article-title>"Requirements engineering education: a systematic mapping study,"</article-title>
          <source>Requirements Engineering</source>
          ,
          <volume>20</volume>
          .2 (
          <year>2015</year>
          )
          <fpage>119</fpage>
          -
          <lpage>138</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <source>[9] The Software Engineering Body of Knowledge</source>
          ,
          <year>2024</year>
          -
          <volume>02</volume>
          -06, URL: https://www.computer.org/education/bodies-of
          <article-title>-knowledge/software-engine.</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [10]
          <string-name>
            <surname>IIBA</surname>
            <given-names>BABOK</given-names>
          </string-name>
          ,
          <source>Leitfaden zur Business Analyse Version 3</source>
          .0,
          <string-name>
            <surname>Götz</surname>
            <given-names>Schmidt</given-names>
          </string-name>
          ,
          <year>2017</year>
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>M.</given-names>
            <surname>Aoyama</surname>
          </string-name>
          ,
          <article-title>"Requirements Engineering Based on REBoK (Requirements Engineering Body Of Knowledge)," 2011</article-title>
          , URL: http://www.nise.org/eng/REBoK/REBoK-APSEC2011
          <string-name>
            <surname>- Tutorial-</surname>
          </string-name>
          2011
          <string-name>
            <surname>-</surname>
          </string-name>
          12-05.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [12] ISO/IEC/IEEE 29148:
          <article-title>2018 Systems and software engineering. Life cycle processes</article-title>
          .
          <source>Requirements Engineering</source>
          ,
          <year>2018</year>
          , URL: https://ieeexplore.ieee.org/document/8559686.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [13]
          <string-name>
            <surname>IREB CPRE FL Syllabus</surname>
          </string-name>
          ,
          <year>2021</year>
          , URL: https://www.ireb.org/content/downloads/21-cpreadvanced
          <article-title>-level-re-agile-syllabus/syllabus_cpre_al_re%40agile_en_v2.0</article-title>
          .pdf.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>P.</given-names>
            <surname>Kruchten</surname>
          </string-name>
          ,
          <source>The Rational Unified Process: An Introduction</source>
          ,
          <string-name>
            <surname>Addison-Wesley Professional</surname>
          </string-name>
          ,
          <year>2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>H.</given-names>
            <surname>Kittlaus</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S. A.</given-names>
            <surname>Fricker</surname>
          </string-name>
          ,
          <source>Software Product Management</source>
          , Springer,
          <year>2017</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>