<!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>
      <journal-title-group>
        <journal-title>Workshops, OpenRE, Posters and Tools Track, and Doctoral Symposium, Essen, Germany</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Requirements Engineering in Industry: Modular Foundational Online Training to Build Basic Practices</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Sarah Crary Gregory</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Intel Corporation</institution>
          ,
          <addr-line>2200 Mission College Blvd, Santa Clara, California</addr-line>
          ,
          <country country="US">USA</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2020</year>
      </pub-date>
      <volume>1</volume>
      <fpage>2</fpage>
      <lpage>04</lpage>
      <abstract>
        <p>Requirements Engineering is a practice critical to successful product development, but often underdeveloped or underappreciated by practicing engineers. Modular, quickstart training that touches on several key RE activities and practices can demonstrate quick benefit to engineers and product development teams, and even build interest in further RE training to secure additional value from the practice.</p>
      </abstract>
      <kwd-group>
        <kwd>1 Requirements Engineering</kwd>
        <kwd>Requirements</kwd>
        <kwd>Industrial Practice</kwd>
        <kwd>Training</kwd>
        <kwd>Remote Training</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>Industrial Requirements Engineering (RE) practice can be a paradox. When done well, RE activities
should be transparent to the work at hand. Requirements specification – writing natural language
requirements statements that define the product to be developed – is most noticeable when it is poorly
executed. Requirements verification – assessing requirements for defects that could lead to different
interpretations of requirements, resulting in incorrect design – is recognized most when requirements
escapes result in product defects later. Inadequate requirements practice can have catastrophic results
for a project, product, or even a company, while excellent practice may go unrecognized. Rewards are
rarely given for what many may consider to be preventative maintenance.</p>
      <p>Given the criticality of RE in product development practice, it is perhaps surprising that many
engineers have had no formal exposure to the practice, and often aren’t aware that “requirements
engineering” is itself an engineering discipline. Without exposure to good requirements practice during
formal study, “writing requirements” is often a task undertaken as a necessary step during product
planning, but one assumed to need no additional skills or training to accomplish. Indeed, it is not
uncommon for engineers with deep technical expertise in their original discipline to react with surprise
when they learn that additional training may be required for them to adequately specify their work.</p>
      <p>A North Star principle that industrial RE practitioners do well to keep in mind is the following: The
company is not paid to deliver documentation. Every minute spent in work outside of the core product
ideation, planning, development, test, and delivery cycle is either an investment in improving that cycle,
or a liability that detracts from it. While continuous learning is valued, few engineers will commit a
significant amount of time to attending courses outside the scope of their work, especially if they believe
they are already competently writing requirements. The task for our Requirements Engineering
instructors and curriculum is to provide RE training that is both immediately applicable, and that
demonstrates the value to the engineer of continuing to invest in honing their RE skills as well.</p>
      <p>Many RE researchers are used to spending between a few days and a few weeks on RE across the
software engineering or computer science curricula. Within industry, we may be afforded from a few
minutes to a handful of hours to make the case for investment in improving one’s RE practice.</p>
    </sec>
    <sec id="sec-2">
      <title>2. The Intel RE Curriculum</title>
      <p>Intel Corporation has developed a series of short courses and tutorials that address specific topics in
Requirements Engineering, Systems Engineering, and Systems Thinking. Early versions of core courses
were initially developed in 2000, and evolved over time as RE as a discipline, our senior practitioners’
time and interests, and the company’s investment in the work changed as well. The core course around
which much of the RE curriculum itself revolves, Requirements Specification, is in its ninth major
revision, with incremental releases as participant questions or instructor insights suggest minor
additions. As of March 2021, Requirements Specification has been taught to over 18,500 participants.
In addition, an externally-approved version of this course has regularly been offered as a tutorial at the
IEEE International Requirements Engineering Conference, under the name “Writing Good
Requirements.”
2.1.</p>
    </sec>
    <sec id="sec-3">
      <title>Delivering the RE Curriculum</title>
      <p>Despite significant shifts both within Intel and across industry to more just-in-time, web-based
training, the majority of Intel’s Requirements Engineering courses remain instructor-led. We contend
that Requirements Engineering proficiency is a dialectial process, furthered both through discussions
among participants and instructors in a live classroom setting, and through the work itself of eliciting,
analyzing and validating, specifying, verifying, and managing requirements work products. Limited
volunteer instructor availability, geographically-dispersed teams, and – as of 2020 – the COVID-19
pandemic – have led to the development of modular versions of several of the Intel RE courses, but at
present they remain instructor-led and continue to be highly participatory. Consistent Net Promoter
scores and other feedback from participants suggests that we must maintain live sessions, whether
remote or once again colocated after the pandemic.</p>
      <p>Although course materials are available for many activities of Requirements Engineering, the
primacy of the Requirements Specification/Writing Good Requirements course reflects the “just in
time” constraints that we work under with our practitioners. Development, maintenance, and even
delivery of this content is not formally resourced, but continues thanks to the support of organizations
that respect its value and permit “extracurricular” work among a core few of their employees.</p>
    </sec>
    <sec id="sec-4">
      <title>3. 2020 Requirements Quickstart</title>
      <p>The Intel RE Training course materials in this OpenRE submission were delivered to approximately
100 employees in November, 2020. Travel limitations due to COVID-19 abruptly ended sessions
delivered in our preferred, face-to-face instructor-led format. Participants attended the session from
their homes in multiple countries across three continents. Additional participants opted to watch
recordings of the live sessions. In order to combat the ills of online meeting fatigue and in recognition
of the breadth of time zones represented, eight hours of training were delivered over four two-hour
sessions, two each in two consecutive weeks.</p>
      <p>The training delivered during this Quickstart was comprised of excerpts from three courses from
Intel’s Requirements Engineering curriculum.</p>
      <p>The first two sessions were derived from our core Requirements Specification course. Topics
covered include Problems with Natural Language, Detail Level and Timing Issues, Specification
Basics, Specifying Functional Requirements and Constraints, and Specifying Quality Requirements.
The third session was a brief overview of Requirements Verification, including the introduction of a
checklist to assess objective requirements quality, and a specific review practice targeted toward
assessing subjective quality of requirements through producer-consumer exchanges. The fourth session
covered topics related to Requirements Management. Natural Language Processing tools as a means of
assessing quality of requirements statements were also briefly introduced and discussed. Taught as
designed, each of these courses covers a standard business day. The size of the audience, urgency
expressed by the requestors for these particular personnel to receive training, and limited instructor
availability to deliver additional sessions led to this shortened modular training series.
3.1.</p>
    </sec>
    <sec id="sec-5">
      <title>Delivering the Quickstart</title>
      <p>Despite significant shifts both within Intel Unlike many RE classes at Intel, which are offered open
enrollment and that participants enroll in by choice, the ~100 participants in this course session were
obliged to attend by their organizations’ management in pursuit of raising the bar for RE practice within
those teams and for the product development teams that they support. Participants were encouraged to
listen to recordings of the sessions if conflicting meetings or time zone challenges made it desirable or
necessary to do so. Despite this flexibility, live attendance and participation both held steady through
the four sessions, easily comprising a majority of the class. Eleven participants registered after the first
session and attended the remaining three classes, including some who were not part of the targeted
audience, but who had heard of the training from colleagues and friends who attended.
The 2020 Quickstart training was well-received by participants, many of whom participated quite
actively in the online sessions. More significantly, however, has been the degree of interest shown
subsequent to the online session. By providing a handful of techniques that could be applied
immediately in the attendees’ work context, value was delivered immediately. In particular, although
each session was a pared-down version of the standard training (which itself is a very abstracted version
of the topics as they would be taught in academia!), each two-hour block contained one or two very
specific tasks that could be practiced to the benefit of the attendees’ programs, with little to no additional
training or coaching required. Each session also points out that more training, coaching, and support is
required to truly execute each RE activity with proficiency. By leading with actionable content and
encouraging experiments and feedback, participants develop trust in both the materials and the
instructors. In the first session, a statement is made to the effect that taking eight hours away from work
or family time is a major commitment, and that our expectation is that applying at least one learning
from the course will result in at least eight hours’ return on that investment within the quarter, regardless
of any learning curve needed. To date, no participant has returned to claim otherwise, while several
have reported gains from the practices, and have requested additional training or coaching.</p>
    </sec>
    <sec id="sec-6">
      <title>4. Alternate Uses or Audiences</title>
      <p>An earlier version of the Requirements Specification class was recorded in 2015 by the Institute for
Electrical and Electronics Engineers (IEEE) Digital Library. Because the training is tool-agnostic and
not context-specific, practitioners in a range of software, hardware, process, and systems (and
systemof-systems) contexts can use the materials.</p>
      <p>Additionally, the materials may be relevant in academic contexts. Students preparing for careers in
industry will gain exposure to real-world practical training. Researchers will have a body of material to
use for Capstone or other practicum sessions where simulating industrial experience may be helpful.
Researchers will also gain insight into a not-uncommon starting point for engineers, which could inform
subseqent research into other rapidly-applicable RE techniques suitable for tech transfer.</p>
    </sec>
    <sec id="sec-7">
      <title>5. License</title>
      <p>Materials are released under Creative Commons – Attribution 4.0 International Public License.</p>
    </sec>
    <sec id="sec-8">
      <title>6. Acknowledgements</title>
      <p>The initial version of the Intel Corporation Requirements Engineering content was developed by
Erik Simmons. Other current and former colleagues in instances of the Intel RE program, at times
officially-chartered but more often volunteer-driven, and several thousand Intel employees who have
taken the training and provided feedback have been instrumental in its ongoing development.</p>
      <p>We also acknowledge the support of the Intel Internet of Things Group (IOTG) Business
Acceleration Systems Engineering and Requirements team. Continued evolution of the materials and
delivery across the corporation, not just in the IOTG business unit, is enabled through their recognition
of its overall importance.</p>
      <p>Of course, our curriculum is also immeasurably improved through our two decades of involvement
in the global RE research and practitioner community. We are grateful to have the community as a
wealth of opportunities for our ongoing education. Our RE practice is all the better for it.</p>
    </sec>
    <sec id="sec-9">
      <title>7. References</title>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>T.</given-names>
            <surname>Gilb</surname>
          </string-name>
          , Competitive Engineering:
          <article-title>A Handbook for Systems Engineering</article-title>
          , Requirements Engineering, and Software Engineering Using Planguage,
          <string-name>
            <surname>Butterworth-Heinemann</surname>
          </string-name>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>D.</given-names>
            <surname>Cabrera</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Cabrera</surname>
          </string-name>
          , Systems Thinking:
          <article-title>New Hope for Solving Wicked Problems</article-title>
          , Odyssean Press,
          <year>2015</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>A.</given-names>
            <surname>Mavin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Wilkinson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Harwood</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Novak</surname>
          </string-name>
          ,
          <article-title>"Easy Approach to Requirements Syntax (EARS</article-title>
          ),
          <year>" 2009</year>
          17th IEEE International Requirements Engineering Conference, Atlanta,
          <string-name>
            <surname>GA</surname>
          </string-name>
          , USA,
          <year>2009</year>
          , pp.
          <fpage>317</fpage>
          -
          <lpage>322</lpage>
          , doi: 10.1109/RE.
          <year>2009</year>
          .
          <volume>9</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>A.</given-names>
            <surname>Mavin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Wilksinson</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Gregory</surname>
          </string-name>
          and
          <string-name>
            <given-names>E.</given-names>
            <surname>Uusitalo</surname>
          </string-name>
          ,
          <article-title>"Listens Learned (8 Lessons Learned Applying EARS</article-title>
          ),
          <article-title>"</article-title>
          2016 IEEE 24th International Requirements Engineering Conference (RE), Beijing, China,
          <year>2016</year>
          , pp.
          <fpage>276</fpage>
          -
          <lpage>282</lpage>
          , doi: 10.1109/RE.
          <year>2016</year>
          .
          <volume>38</volume>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>