<!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>ImProject: Improving RE Training by Combining it with Improvisation Theatre Sessions</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>A Research Proposal</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Anne Hoffmann</string-name>
          <email>a.hoffmann@rug.nl</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Business Department Hamburg University of Applied Sciences (HAW Hamburg) Hamburg</institution>
          ,
          <country country="DE">Germany</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Software Engineering Institute Rijksuniversiteit Groningen Groningen</institution>
          ,
          <country country="NL">The Netherlands</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>-Today factual knowledge training and soft skill training are typically taught as separate disciplines. This approach falls short of the need of the participants to learn, understand and experience the application of typical soft skills such as communication skills within their domain. Requirements engineering (RE) in practice requires for instance excellent communication skills. We propose to use techniques from improvisation theatre to combine factual knowledge and soft skill training into one workshop format, which we call ImProject. We propose to add ImProject as a training element/part of normal RE training. ImProject adopts a typical improvisation theatre training session and trains soft skills such as communication skills in typical RE situations. In this paper, we present our research agenda for investigating how factual knowledge training such as RE and soft skill training can be combined using ImProject and derive further needed research activities. This interdisciplinary research will contribute to improve training within the RE community. Index Terms-Requirements Engineering, Industrial Training, Training Format, Soft Skills, Improvisation.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>I. INTRODUCTION</title>
      <p>Being trainers for several years in requirements
engineering (RE), software engineering as well as project
management (PM) and both in industry and academia, we
experienced a lack between the typical training and some of
our participants needs. Participants typically appreciate the
factual knowledge oriented approach of the training material,
and give more or less positive feedback on how the material is
taught (e.g. see the publication of Brian Berenbach with
respect to a company training [1]). However, generally stated
comments during the training and questions from the
participants towards the trainer indicate, that something more
is needed. Participants ask for advice regarding the integration
of interpersonal aspects in a specific context.</p>
      <p>We decided to use the broader term soft skill to summarize
all the skills and abilities that relate to human behavior,
communication and psychological patterns in human behavior.
For a further discussion on the term’s definition, see [2].</p>
      <p>These statements imply trainings should extend beyond
pure factual knowledge and include some kind of contextual
soft skill training as well. One can argue against an</p>
      <sec id="sec-1-1">
        <title>Rüdiger Weißbach</title>
        <p>integration, that soft skill training is not specific to people
working in the RE domain and so this training could be
offered to diverse professional groups. Additionally, this
separated format is very efficient from the training provider's
point of view and sometimes for the customers too: Slide
presentations offer a low-risk format for the customers as well
as for the providers.</p>
        <p>But there is a demand to integrate factual knowledge and
soft skill training, so the question arises how these two could
be combined into one joint approach, being taught in parallel?</p>
        <p>The need to emphasize on soft skill aspects within the RE
education has been recognized from the RE community (e.g.
[3], [4]). Efforts to respond to this focus on the secondary
education at Universities (e.g. [5]). Little research has been
published how to efficiently train practitioners, or to integrate
soft skill aspects within training in industrial setups (e.g. [1]).</p>
        <p>However, it is insufficient to emphasize on finding a
combined training format that just considers both aspects
separately. Instead, the new format needs to be more efficient
with respect to duration and learning content. It is more than
the sum of its parts as Aristotle once stated. This training
format then needs to be thoroughly investigated in order to
allow us to scientifically and empirically claim success.</p>
        <p>This paper presents a research agenda for validating a new
training format that is capable of improving (industrial)
trainings by combining factual knowledge training (in this
case RE) with soft skill training.</p>
        <p>We introduce our approach of combining a RE training
with a typical training session from an improvisation theatre
course, and outline subsequently derived research agenda,
questions and topics. Thus, we call our approach ImProject
standing for Improvisation Theatre in Projects.</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>The paper is structured as follows:</title>
      <p>Section II illustrates the current situation in RE trainings,
underpins the need for additional training elements with two
examples and summarizes methods that already enrich
classroom trainings. Section III then introduces the general
concepts of improvisation theatre before describing the
concept of our workshop format ImProject. In Section IV, we
present our research agenda together with our research
approach. Finally, Section V summarizes the results of this
paper.</p>
    </sec>
    <sec id="sec-3">
      <title>II. CURRENT SITUATION</title>
      <p>
        Traditionally, research, education and training in RE are
focusing on tools and methods. But it is often neither the
method nor the technique that causes a project to fail, but the
interpersonal relations and miscommunication [
        <xref ref-type="bibr" rid="ref1">6</xref>
        ]. The
approach towards teaching RE and the corresponding topics
such as stakeholder management and requirements elicitation
needs to be less theoretical and needs to include more soft skill
related topics. Therefore, new training concepts are needed.
Only recently, the RE community as well as the PM
community have detected the importance of the so-called
socio-technical or soft skill aspects. This is for instance
reflected in call for papers explicitly requesting submissions
on this topic (e.g. [
        <xref ref-type="bibr" rid="ref2">7</xref>
        ], [
        <xref ref-type="bibr" rid="ref3">8</xref>
        ]).
      </p>
      <p>The question remains how industrial trainings can be
structured in a way, that soft skills are well integrated. The
Workshop on Requirements Engineering Education and
Training (REET, taking place since 2005 in conjunction with
the International IEEE RE Conference) gives a good overview
on existing approaches and new aspects. However, the
majority of papers focusses on education at Universities.</p>
      <p>
        In industrial approaches, it is common to train specialized
practitioners using the experience-based learning model [
        <xref ref-type="bibr" rid="ref4">9</xref>
        ],
[
        <xref ref-type="bibr" rid="ref5">10</xref>
        ].
      </p>
      <p>In this paper we focus on industrial trainings including
both on-site trainings, executed at the company's site, and
open training at the training company's location. These
trainings last one to several days.</p>
      <p>
        Other methods than traditional classroom training exist,
and have been presented to the RE community at multiple
occasions (e.g. [5]). But screening teaching material, we
noticed that in industrial RE trainings nevertheless 'old'
training styles seem to dominate: Slide presentations enriched
with some small (more or less interactive) exercises. These
exercises last 10-20 minutes and enforce the participants to
apply the method exactly as it had just been introduced before
[
        <xref ref-type="bibr" rid="ref6">11</xref>
        ].
      </p>
      <p>This kind of training is not sufficient to train soft skill
aspects in projects.</p>
      <p>Due to the gap between the content of current training
sessions and the really important topics to be addressed,
current approaches do not seem to be sufficient. We thus
conclude, that it will not be useful to train factual knowledge
and soft skills separately. Furthermore, this implies directly
that the offer should be a combined training of factual
knowledge and soft skills in the corresponding situations. This
approach is closer to what the participants experience in their
daily work. Consequently, this kind of training might be more
efficient as well.</p>
      <p>Following, we present two examples from the daily life of
a requirements engineer. These illustrate common situations
where the requirements engineer uses his factual knowledge
while at the same time needs to apply soft skills. These soft
skills include for example tense communication and active
listening. He does not distinguish whether he applies factual
knowledge, such as a method, or a soft skill.</p>
      <sec id="sec-3-1">
        <title>A. Kano Analysis and AMUSE - Two Requirements Engineering Methods that Require Soft Skills</title>
        <p>As part of the requirements engineering, requirements need
to be prioritized. Otherwise the team which implements them
would not have a clear understanding of what to implement
first.</p>
        <p>
          In RE for products, there is a well-known method for
prioritization of user requirements to decide which one to
implement in which version of the product. This is called the
Kano Model or Kano Modeling [
          <xref ref-type="bibr" rid="ref7">12</xref>
          ].
        </p>
        <p>For each iteration the requirements engineers need to prioritize
the users’ requirements into the categories:
”Basic” - These requirements are the fundamentals of the
product. They are often not even mentioned by the user, but
are nevertheless expected.
”Performance” - These requirements are the new features, and
often those the user has asked for.
”Excitement” - Requirements the user often has not asked for
directly, but which are the reasons he is going to buy or to use
the product.</p>
        <p>For example, an MP3-player needs to play music. This is a
“basic” functionality. Some years ago, having a wheel as the
only ’button’ to steer the MP3-player was exciting, it was new
and only Apple products had it. This was clearly an exciting
requirement: Something the users have not asked for, but
because of its existence they bought the product.</p>
        <p>
          Another prioritization approach explicitly analyses the user
satisfaction with each requirement. This approach is called
AMUSE (Appraisal and Measurement of User Satisfaction
[
          <xref ref-type="bibr" rid="ref8">13</xref>
          ]). AMUSE supports the requirements engineer to detect
the requirements which will lead to the highest user
satisfaction. Amongst other things AMUSE is used to analyze
the hedonic satisfaction of the user.
        </p>
        <p>What does a requirements engineer need to successfully
prioritize the requirements together with the user? Of course,
he needs to have a clear understanding of the method he uses.</p>
        <p>On the other hand, the results of a successful prioritization
are prioritized requirements which reflect the real users’
priorities. It is thus up to the requirements engineer’s
communication skills, his intuition and his ability to put
himself in the position of the user and empathize with him to
understand the user’s real priorities.</p>
      </sec>
      <sec id="sec-3-2">
        <title>B. Expectation Management in Long Term Projects</title>
        <p>One of the authors participated in an IT infrastructure
project, where a new IT system should be customized and
rolled-out to several sites of a company. The roll-out was
executed site after site. The requirements for customization
were implemented in iterations. Each iteration focused on that
site where the system was rolled-out to.</p>
        <p>Requirements engineers needed to build up trust with the
users of a system.</p>
        <p>At a certain point, the system was rolled-out to some site
while to other sites it was not yet rolled-out. However, the
users at the already rolled-out sites had new requirements or
change requests to the system whereas the users at not-yet
rolled-out sites were still expecting to receive the system
initially. Being the requirements engineer in that situation the
author needed to maintain the trust from the users having a
rolled-out version of the system. At the same time these users
were disappointed by the project management’s decision to
focus on the roll-out sites and to postpone further requirements
or change requests from rolled-out sites. Thus, the
requirements engineer was in need to thoroughly manage
expectations while eliciting the new requirements or change
requests. Doing this successfully, he maintained a good
relationship with the users, avoided conflicts, and remained a
trusted person from the user’s viewpoint – even though the
principal anger by the users of not being supported by the
project management remained.</p>
        <p>This real live example illustrates well that the daily work
of the requirements engineer includes situations, where the
successful application of requirement elicitation methods only,
does not result in positive feedback on the requirements
engineer’s work.</p>
        <p>First, the requirements engineer needs to understand highly
emotional situations and see or even better feel them from the
user’s perspective. Second, he needs to use his communication
skills, as well as convincing skills to achieve understanding
from the users. Third, the requirements engineer is seen as a
communication channel towards the project, especially to the
project management. It is the requirement engineer’s task to
create awareness of the current user situation, especially when
emotionally tense and to ask for understanding. So, the
requirements engineer needs to appropriately communicate
with the project management to make them aware of this
situation. All this requires high soft skill competence.</p>
      </sec>
      <sec id="sec-3-3">
        <title>C. Methods to enrich classroom trainings</title>
        <p>
          Other methods have been used to enrich traditional
classroom training and enforce learning by creating experience
such as the adaptation of board games like “Monopoly” (see
“RE-O-Poly” [
          <xref ref-type="bibr" rid="ref9">14</xref>
          ]), role plays (e.g. [
          <xref ref-type="bibr" rid="ref10">15</xref>
          ]), project simulations
[
          <xref ref-type="bibr" rid="ref11">16</xref>
          ] or other interactive formats [
          <xref ref-type="bibr" rid="ref12">17</xref>
          ].
        </p>
      </sec>
      <sec id="sec-3-4">
        <title>1) Role Play</title>
        <p>One common approach for training social skills is the
usage of role plays. Role play has been particularly often used
for educational purpose and is often used for behavioral
oriented training within company trainings too.</p>
        <p>However, to the authors’ understanding role play has some
disadvantages that especially hinder advanced practitioners to
participate with their full attention and gain the most learning
possible out of these types of interaction.</p>
        <p>Role play enforces the participants to make a certain
mistake that is often pre-described by the role play instruction.
In training, there are participants who cannot distinguish role
from emotion associated with the mistake. When participants
of this type are enforced to play a project manager making a
certain mistake, they might end up being emotionally
negatively affected. Thus learning is hindered if not even
completely blocked.</p>
        <p>Second, role plays consume a lot of time and have the
drawback of only a few participants acting, while the other
participants are sitting and observing those who act out their
role play.</p>
        <p>
          To our experience, role plays often neither bring up the
really challenging situations nor foster intuitive reactions. In
our trainings we often see participants not taking the situation
serious or feeling “observed” by the other participants. This is
especially the case for in-house trainings, where the
participants sitting in the audience are (direct) colleagues or
might even be directing managers (see [
          <xref ref-type="bibr" rid="ref6">11</xref>
          ] for a discussion on
this topic).
        </p>
        <p>Conclusion: Role play is difficult when participants are
enforced into certain error prone situation. The participants
might truly believe to act differently in real life situations, thus
disconnecting from the learning provided by the role play.</p>
      </sec>
      <sec id="sec-3-5">
        <title>2) RE-O-Poly</title>
        <p>
          Smith and Gotel ([
          <xref ref-type="bibr" rid="ref9">14</xref>
          ]) identified eight RE practices to “create
a lightweight set of RE practices [..] to improve RE processes”
and developed the board game RE-O-Poly based on the
wellknown “Monopoly” game. RE-O-Poly is created to support
education of undergraduates (beginners) in RE to e.g. “get a
broad overview of typical RE problems” and “respond
appropriately to unanticipated situations that impact projects”.
Using “Monopoly” as a base, the authors expect to “encourage
face-to-face communication which is useful for learning about
a discursive activity.”
        </p>
        <p>
          These interactive methods are based on the approach, that
participants need to have fun during the training to activate
their learning. However, the willingness to learn depends on
each participant himself. This has been extensively studied in
the so-called subject-scientific foundation of Holzkamp [
          <xref ref-type="bibr" rid="ref13">18</xref>
          ].
        </p>
        <p>
          And from learning theory it is well known that “theory is
not enough, because knowledge does not substitutes
experience” ([
          <xref ref-type="bibr" rid="ref14">19</xref>
          ] translated by author). Additionally, Daniel
Goleman cites Howard Gardner in his well-known book on
emotional intelligence: “The best way to learn something is to
be interested in it, and enjoy the activity of doing so” ([
          <xref ref-type="bibr" rid="ref15">20</xref>
          ]
translated by author).
        </p>
        <p>
          We believe that the situation in current trainings cannot
c r e a t e t h i s w e l l - k n o w n “ f l o w ” a s d e s c r i b e d b y
Csikszentmihalyi [
          <xref ref-type="bibr" rid="ref16">21</xref>
          ]. However, as flow is the person’s state
where learning is easiest, this should be the state a person
wanting to learn should aim for. Studies show, that “aiming for
flow situations leads to success” (e.g. [
          <xref ref-type="bibr" rid="ref17">22</xref>
          ]).
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>III. IMPROVISATION THEATRE</title>
      <sec id="sec-4-1">
        <title>A. General Concepts of Improvisation Theatre</title>
        <p>Improvisation theatre consists of so-called improvisation
theatre games, also called “improv games” or simply “games”.
Each improvisation theatre show is divided into several
games. Each game has some base rules. Before the game
starts, additional rules are defined by the audience of the show
with help from the facilitator.</p>
        <p>
          Originally, improvisation theatre was invented by Keith
Johnstone in the late 1950s. He was teaching acting and drama
at the Royal Court Theatre in London and thought his students
were trying to be “original” and “giving their best”, which
according to him resulted in bad acting [
          <xref ref-type="bibr" rid="ref18">23</xref>
          ], [
          <xref ref-type="bibr" rid="ref19">24</xref>
          ]. (For further
information on improvisation theatre we refer to [
          <xref ref-type="bibr" rid="ref20">25</xref>
          ].)
        </p>
        <p>Using improvisation theatre games allow us to come up
with a new interactive format to train the combination of
factual knowledge and soft skills.</p>
        <p>The characteristics of improvisation theatre techniques all
seem to cover our goals as stated in Section II. These
characteristics are
1. Improvisation theatre is interactive.
2. Improvisation theatre is about being spontaneous.</p>
        <p>Improvisers do not know the scene they will play
until they actually start playing it and do not have
scripts. They act spontaneously, improvising the
scene from what comes into their minds. Thus, they
are acting in the moment and need to be very
selfaware, as well as aware of their co-players.
3. Improvisation theatre is about having fun. As there is
no script, curious situations occur. This creates fun.
4. Announcing improvisation theatre for a training
session is new, sounds interesting and channels
excitement. - This is a prerequisite for flow while
learning.</p>
        <p>Improvisation theatre can create realistic setups and
immediate feedback.</p>
        <p>
          The usage of improvisation theatre in RE training is
unusual. To our knowledge there exist two approaches,
ImProject [
          <xref ref-type="bibr" rid="ref21">26</xref>
          ] and the (untitled) approach of Mahaux [
          <xref ref-type="bibr" rid="ref22">27</xref>
          ],
[
          <xref ref-type="bibr" rid="ref23">28</xref>
          ].
        </p>
        <p>In our approach, we utilize an improvisation theatre
training session which has further advantages:
1. A training session and its games focus on trying out
new things, thus is constructed for failure. Thus,
making mistakes is the goal for most of these games.
2. Some games, do not distinguish participants (e.g. by
role). Thus, an error is made by the group, not by the
individual.
3. Training games last between 10 to 20 minutes, each
focuses on different things. Thus, to the authors'
understanding, this approach is faster than using role
play.</p>
        <p>Especially, the second item frees the participants to try things
out. Participants tend to feel safer, as individual activities
cannot be as clearly separated as when using different roles
such as in role play.</p>
      </sec>
      <sec id="sec-4-2">
        <title>B. The ImProject Format</title>
        <p>
          ImProject [
          <xref ref-type="bibr" rid="ref21">26</xref>
          ] was initially called REIM (Requirements
Engineering and Improvisation Theatre) and initially
introduced to the (RE) research community in 2008 [
          <xref ref-type="bibr" rid="ref13">18</xref>
          ], [
          <xref ref-type="bibr" rid="ref14">19</xref>
          ].
        </p>
        <p>The format has been further developed, and now serves as
a workshop format for training situations related to (software)
projects. It focuses on the training of soft skills, especially
communicational skills together with hard facts. We initially
focus our research on RE, because RE is considered to be a
highly communicative job within the software engineering
discipline (e.g. [3]).</p>
        <p>The following summarizes the overarching principles of
ImProject:</p>
        <p>
          ImProject is based on a typical improvisation theatre
training session and uses storytelling to map to elements of the
domain under consideration (here: RE). It is structured in three
sections: Warm up, Training and Closure. For each section,
games from the corresponding improvisation theatre training
sections are being used. All games used in the ImProject
format are being described using a pattern language, called
Game Language (see [
          <xref ref-type="bibr" rid="ref24">29</xref>
          ] for details).
        </p>
        <p>Then, each training game creates the same experience flow:
1. The game forces all participants to make mistakes.
2. The trainer highlights that these types of mistakes
happen in real projects as well, regardless how
“good”, “well prepared” [..] one is.
3. A negative effect of reflection is reduced, because
there is no emotional relationship between the actor
and the mistake (dissociation; reflection without
emotion). Learning takes place efficiently and
blockers or blockades are avoided.
4. ImProject makes it impossible for participants not to
engage in the exercise.
5. It creates an atmosphere where failure means
learning.
6. Additionally, ImProject enables learning by/through
having a lot of fun.</p>
        <p>
          For each game, learning objectives have been defined as part
of the pattern language. For instance the game “The Company
Game” uses the improvisation theatre game called “Pattern
Game” and trains learning objectives such as “The participants
understand that they are adding an implicit prioritization to their
tasks.”. For details, the reader is referred to Game Language
([
          <xref ref-type="bibr" rid="ref24">29</xref>
          ]). As the concept of ImProject is quite complex, a train
the trainer guideline has been published as well. This train the
trainer guideline is published in a pattern format as well (see
[
          <xref ref-type="bibr" rid="ref21">26</xref>
          ] for details).
        </p>
      </sec>
      <sec id="sec-4-3">
        <title>C. Other Approaches using Improvisation Theatre</title>
        <p>At a first look, the research from Martin Mahaux
(University of Namur, Belgium) looks similar to our approach.</p>
        <p>
          Indeed, he is using improvisation theatre as a technique,
too. However, in his research Mahaux uses improvisation
theatre as a technique to drive innovation and collaboration
within the (software) development process [
          <xref ref-type="bibr" rid="ref22">27</xref>
          ]. His approach
aims at involving stakeholders to gather and elicit
requirements using improvisation theatre games. We utilize
games that are used during improvisation theatre training
sessions, and are called improvisation theatre training games:
“Analysts and stakeholders can benefit from using these
techniques in their requirements project and workshops” [
          <xref ref-type="bibr" rid="ref22">27</xref>
          ].
Even though Mahaux emphasizes the aspect of improvisation
theatre, his focus on improvisation theatre is to use it as a tool
to enhance stakeholder communication, and reach better
creative, innovative and collaborative processes during the
activity of requirements gathering[
          <xref ref-type="bibr" rid="ref23">28</xref>
          ]. Thus, in his approach
improvisation theatre is used to create better outcomes with
respect to user stories and scenarios within the process of RE
not while training RE and related soft-skill.
        </p>
        <p>In contrast to Mahaux, we use structure and content of an
improvisation theatre training session to improve the RE
training by adding ImProject to train soft skills specific to RE
and within RE situations. Thus, we consider improvisation
theatre as a tool to train communicational and other soft skill
related aspects.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>IV. RESEARCH AGENDA AND RESEARCH QUESTIONS</title>
      <p>As trainers, we constantly aim at improving our training
sessions. As we have outlined in the former sections, there is a
need to improve RE trainings with regard to efficiently
combining factual RE knowledge training with training of soft
skills within RE situations.</p>
      <p>The development of the introduced workshop format in the
ImProject was driven by one main question, which we call our
main research question:
RQ0: How can improvisation theatre be used effectively in
RE trainings?</p>
      <p>We believe, ImProject could be a good answer to this
question, but are of course aware that we need to evaluate our
assumption.</p>
      <p>Thus, we split this research question into two disjunct
research questions that focus on what is to be learned using
improvisation theatre.</p>
      <p>
        We want to focus on communication skills, because
excellent communication skills are seen to be a key
competence (see e.g. Klendauer et al. [
        <xref ref-type="bibr" rid="ref26">31</xref>
        ]); the format needs
to efficiently provide the possibility to train communication
skills. Therefore, RQ1 focuses specifically on these soft skill
aspects.
      </p>
      <p>RQ1: How can improvisation theatre be used to introduce an
effective way to successfully train communication skills
involving RE situations?</p>
      <p>
        Improvisation theatre also is seen to be an effective
instrument for team building, awareness training on trust and
other aspects in social life. This is reflected by numerous
c o m p a n i e s o ff e r i n g b u s i n e s s c o n s u l t i n g b a s e d o n
improvisation theatre, e.g. called Business Theatre (e.g. [
        <xref ref-type="bibr" rid="ref27">32</xref>
        ]).
We thus believe that our format trains other social aspects than
communication, even though we might not foresee exactly
which ones. To analyze this, we will interpret the research data
in the context of the Grounded Theory [
        <xref ref-type="bibr" rid="ref28">33</xref>
        ].
      </p>
      <p>This is reflected in our RQ2.</p>
      <p>RQ2: How can improvisation theatre be used within RE
training to train other social aspects than communication?</p>
      <p>In order to identify if and how RQ1 and RQ2 can be
answered using our ImProject format we further detail each
research question into research tasks.</p>
      <sec id="sec-5-1">
        <title>A. Examining RQ1</title>
        <p>We want to use our format ImProject for the training of
communication skills. Thus, we need to identify situations for
which ImProject is suited well. Consequently, our first
research task states:</p>
        <sec id="sec-5-1-1">
          <title>RT1: In which situations is ImProject working well?</title>
          <p>To provide the empirical evidence for the following
questions, we are planning an extended evaluation design,
using qualitative as well as quantitative evaluation of feedback
questionnaires, structured interviews and repetition over time.</p>
          <p>The exact evaluation design will need to be developed, and
will contribute to answer
RT2: How do we relate a soft skill aspect in an improvisation
theatre game to RE situations?</p>
          <p>All games used within ImProject are constructed using the
following mechanism: A training game from improvisation
theatre is taken as foundation and a desired soft skill artifact
(called anticipated learning object) is attached to the game
using storytelling. While playing for instance a game which
involves throwing balls, in the context of RE these balls
become requirements and the catchers become requirement
engineers. Even though, these main principles have been
documented, further documentation is required here.</p>
          <p>One possibility to verify communicational aspects trained
by improvisation theatre would be to ask participants to
allocate certain learning outcomes to the games played.</p>
          <p>
            Participants will notice learning outcomes by games not by
stories. We know this effect from psychotherapy (in
psychotherapy stories are known as metaphors [
            <xref ref-type="bibr" rid="ref29">34</xref>
            ]). It might
be worth to study this effect, but this is beyond the scope of
our research.
          </p>
          <p>We further ask:
[4] L. Scheinholtz, “What are employers really looking for?,”
presented at the first Workshop for Requirements Engineering
for Education and Training, 2005.
[5] D. Zowghi, N. Yusop, and Z. Mehboob, “The role of conducting
stakeholder meeting in requirements engineering techniques,”
presented at the second Workshop for Requirements Engineering
for Education and Training, 2007.</p>
        </sec>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>J.</given-names>
            <surname>Mack</surname>
          </string-name>
          , “
          <article-title>Was Projektmanager von Expeditionen lernen können</article-title>
          ...” in Net.
          <source>Objectdays</source>
          <year>2001</year>
          :
          <article-title>Offizielle NachfolgeVe r a n s t a l t u n g d e r J a v a D a y s , S T J A</article-title>
          ,
          <string-name>
            <surname>J I T</surname>
            ,
            <given-names>D J E K</given-names>
          </string-name>
          <article-title>i n Zusammenarbeit mit der GCSE</article-title>
          , J. e. a. Bosch, Ed.,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>GPM e.V.</given-names>
            ,
            <surname>“</surname>
          </string-name>
          PM-forum
          <source>call for paper</source>
          <year>2014</year>
          ,”
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          <article-title>[8] REET2012 “Call for papers</article-title>
          ,
          <source>” in 7th International Workshop on Requirements Engineering Education and Training</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>L.</given-names>
            <surname>Andresen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Boud</surname>
          </string-name>
          , and
          <string-name>
            <given-names>R.</given-names>
            <surname>Cohen</surname>
          </string-name>
          , “
          <article-title>Experience-based learning,” Understanding adult education and training</article-title>
          , vol.
          <volume>2</volume>
          , pp.
          <fpage>225</fpage>
          -
          <lpage>239</lpage>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [10]
          <string-name>
            <given-names>F.</given-names>
            <surname>Paulisch</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Zimmerer</surname>
          </string-name>
          , “
          <article-title>A role-based qualification and certification program for software architects: an experience report from siemens</article-title>
          ,” in Software Engineering,
          <year>2010</year>
          ACM/IEEE 32nd International Conference on, vol.
          <volume>2</volume>
          , pp.
          <fpage>21</fpage>
          -
          <lpage>27</lpage>
          , May
          <year>2010</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [11]
          <string-name>
            <given-names>B.</given-names>
            <surname>Berenbach</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Konrad</surname>
          </string-name>
          , “
          <article-title>The reinforcement pedagogical pattern for industrial training,” in Requirements Engineering Education</article-title>
          and Training,
          <year>2008</year>
          . REET'08. IEEE,
          <year>2008</year>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>5</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [12]
          <string-name>
            <given-names>N.</given-names>
            <surname>Kano</surname>
          </string-name>
          , “
          <article-title>Attractive quality and must-be quality</article-title>
          ,
          <source>” Journal of the Japanese Society for Quality Control, no. 4</source>
          , pp.
          <fpage>39</fpage>
          -
          <lpage>48</lpage>
          ,
          <year>1984</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [13]
          <string-name>
            <given-names>J.</given-names>
            <surname>Doerr</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Hartkopf</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Kerkow</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Landmann</surname>
          </string-name>
          , and
          <string-name>
            <given-names>P.</given-names>
            <surname>Amthor</surname>
          </string-name>
          , “
          <article-title>Builtin user satisfaction-feature appraisal and prioritization with amuse</article-title>
          ,” in Requirements Engineering Conference,
          <year>2007</year>
          . RE'
          <volume>07</volume>
          . 15th IEEE International. IEEE,
          <year>2007</year>
          , pp.
          <fpage>101</fpage>
          -
          <lpage>110</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [14]
          <string-name>
            <given-names>R.</given-names>
            <surname>Smith</surname>
          </string-name>
          and
          <string-name>
            <given-names>O.</given-names>
            <surname>Gotel</surname>
          </string-name>
          .
          <article-title>Gameplay to introduce and reinforce requirements engineering practices</article-title>
          . In International Requirements Engineering,
          <year>2008</year>
          . RE '
          <volume>08</volume>
          .
          <string-name>
            <surname>16th</surname>
            <given-names>IEEE</given-names>
          </string-name>
          , pages
          <fpage>95</fpage>
          -
          <lpage>104</lpage>
          , sept.
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          [15]
          <string-name>
            <given-names>D.</given-names>
            <surname>Zowghi</surname>
          </string-name>
          and
          <string-name>
            <given-names>S.</given-names>
            <surname>Paryani</surname>
          </string-name>
          , “
          <article-title>Teaching requirements engineering through role playing: lessons learnt</article-title>
          ,” in Requirements Engineering Conference,
          <year>2003</year>
          . Proceedings. 11th IEEE International, pp.
          <fpage>233</fpage>
          -
          <lpage>241</lpage>
          ,
          <year>Sept 2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          [16]
          <string-name>
            <given-names>D.</given-names>
            <surname>Damian</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Hadwin</surname>
          </string-name>
          , and
          <string-name>
            <given-names>B.</given-names>
            <surname>Al-Ani</surname>
          </string-name>
          , “
          <article-title>Instructional design and assessment strategies for teaching global software development: a framework,”</article-title>
          <source>in Proceedings of the 28th international conference on Software engineering</source>
          , pp.
          <fpage>685</fpage>
          -
          <lpage>690</lpage>
          , ACM,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          [17]
          <string-name>
            <given-names>L.</given-names>
            <surname>Beus-Dukic</surname>
          </string-name>
          and
          <string-name>
            <given-names>C.</given-names>
            <surname>Myers</surname>
          </string-name>
          , “
          <article-title>Use and abuse cases</article-title>
          ,
          <source>” in 1st International Workshop on Requirements Education and Training</source>
          , Paris, France, Citeseer,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          [18]
          <string-name>
            <given-names>K.</given-names>
            <surname>Holzkamp</surname>
          </string-name>
          , Lernen - Subjektwissenschaftliche
          <string-name>
            <surname>Grundlegung</surname>
          </string-name>
          . Campus,
          <year>1995</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          [19]
          <string-name>
            <given-names>V.</given-names>
            <surname>Zotz</surname>
          </string-name>
          ,
          <article-title>Mit Buddha das Leben meistern: Buddhismus fr Praktiker</article-title>
          . rororo,
          <year>1999</year>
          , vol.
          <volume>11</volume>
          , no.
          <volume>3499605864</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          [20]
          <string-name>
            <given-names>D.</given-names>
            <surname>Goleman</surname>
          </string-name>
          ,
          <article-title>Emotional intelligence</article-title>
          .
          <source>Bantam Books</source>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          [21]
          <string-name>
            <given-names>M.</given-names>
            <surname>Csikszentmihalyi</surname>
          </string-name>
          ,
          <article-title>Finding flow: The psychology of engagement with everyday life</article-title>
          .
          <source>Basic Books (AZ)</source>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          [22]
          <string-name>
            <given-names>J.</given-names>
            <surname>Hamilton</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Haier</surname>
          </string-name>
          , and
          <string-name>
            <given-names>M.</given-names>
            <surname>Buchsbaum</surname>
          </string-name>
          , “
          <article-title>Intrinsic enjoyment and boredom coping scales: Validation with personality, evoked potential and attention measures,” Personality and individual differences</article-title>
          , vol.
          <volume>5</volume>
          , no.
          <issue>2</issue>
          , pp.
          <fpage>183</fpage>
          -
          <lpage>193</lpage>
          ,
          <year>1984</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          [23]
          <string-name>
            <given-names>K.</given-names>
            <surname>Johnstone</surname>
          </string-name>
          ,
          <year>February 2008</year>
          , stated at Improvisation Theater Workshop in Cologne, Germany,
          <year>February 2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          [24]
          <string-name>
            <surname>--</surname>
          </string-name>
          , Theaterspiele. Spontanität, Improvisation und Theatersport. Alexander Verlag Berlin, Berlin,
          <year>1998</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          [25]
          <string-name>
            <surname>--</surname>
          </string-name>
          , Improvisation - Improvisation und Theater. Alexander Verlag Berlin,
          <year>2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          [26]
          <string-name>
            <given-names>A.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          , “
          <article-title>A trainer's guideline to teaching soft skills using improvisation theater: a workshop format exemplified on a requirements engineering game</article-title>
          ,”
          <source>in Proceedings of the 16th European Conference on Pattern Languages of Programs</source>
          , p.
          <fpage>4</fpage>
          ,
          <issue>ACM</issue>
          ,
          <year>2011</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          [27]
          <string-name>
            <given-names>M.</given-names>
            <surname>Mahaux</surname>
          </string-name>
          and
          <string-name>
            <given-names>N. A.</given-names>
            <surname>Maiden</surname>
          </string-name>
          .
          <article-title>Theater improvisers know the requirements game</article-title>
          .
          <source>IEEE software</source>
          ,
          <volume>25</volume>
          (
          <issue>5</issue>
          ):
          <fpage>68</fpage>
          -
          <lpage>69</lpage>
          ,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          [28]
          <string-name>
            <given-names>M.</given-names>
            <surname>Mahaux</surname>
          </string-name>
          and
          <string-name>
            <given-names>P.</given-names>
            <surname>Heymans</surname>
          </string-name>
          .
          <article-title>Improvisational theater for information systems: an agile, experience- based, prototyping technique</article-title>
          .
          <source>In Advanced Information Systems Engineering</source>
          , pages
          <fpage>699</fpage>
          -
          <lpage>700</lpage>
          . Springer,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          [29]
          <string-name>
            <given-names>A.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          , “Game language,” in press Publication
          <source>EuroPLoP 2012: 17th European Conference on Pattern Languages of Programs</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          [30]
          <string-name>
            <given-names>M.</given-names>
            <surname>Mahaux</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Nguyen</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Gotel</surname>
          </string-name>
          ,
          <string-name>
            <given-names>L.</given-names>
            <surname>Mich</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Mavin</surname>
          </string-name>
          , and
          <string-name>
            <given-names>K.</given-names>
            <surname>Schmid</surname>
          </string-name>
          , “
          <article-title>Collaborative creativity in requirements engineering: Analysis and practical advice</article-title>
          ,
          <source>” in Research Challenges in Information Science (RCIS)</source>
          ,
          <year>2013</year>
          IEEE Seventh International Conference on, pp.
          <fpage>1</fpage>
          -
          <lpage>10</lpage>
          , IEEE,
          <year>2013</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          [31]
          <string-name>
            <given-names>R.</given-names>
            <surname>Klendauer</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Berkovich</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Gelvin</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. M.</given-names>
            <surname>Leimeister</surname>
          </string-name>
          , and
          <string-name>
            <given-names>H.</given-names>
            <surname>Krcmar</surname>
          </string-name>
          , “
          <article-title>Towards a competency model for requirements analysts</article-title>
          ,
          <source>” Information Systems Journal</source>
          , vol.
          <volume>22</volume>
          , no.
          <issue>6</issue>
          , pp.
          <fpage>475</fpage>
          -
          <lpage>503</lpage>
          ,
          <year>2012</year>
          . EXT13.
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          [32] http://www.die-businessclass.de,
          <volume>08</volume>
          .
          <fpage>03</fpage>
          .
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          [33]
          <string-name>
            <given-names>A.</given-names>
            <surname>Strauss</surname>
          </string-name>
          and
          <string-name>
            <given-names>J.</given-names>
            <surname>Corbin</surname>
          </string-name>
          , “Grounded Theory:
          <article-title>Grundlagen qualitativer Sozialforschung”</article-title>
          ,
          <source>Weinheim: Beltz</source>
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          [34]
          <string-name>
            <given-names>D.</given-names>
            <surname>Gordon</surname>
          </string-name>
          , Therapeutic Metaphors:
          <article-title>Helping Others Through the Looking Glass</article-title>
          .
          <source>META Publications</source>
          , 1st ed.,
          <year>1978</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          [35]
          <string-name>
            <given-names>A.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          , “
          <article-title>Teaching soft facts in requirements engineering using improvisation theatre techniques</article-title>
          ,” in Third International Workshop on Multimedia and
          <article-title>Enjoyable Requirements Engineering (MERE'08) in conjunction with 16th</article-title>
          <source>IEEE International Requirements Engineering Conference</source>
          <year>2008</year>
          , Barcelona,
          <year>2008</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          [36] --, “
          <article-title>REIM - an improvisation workshop format to train soft skill awareness,” Cooperative and Human Aspects of Software Engineering (CHASE</article-title>
          ),
          <year>2012</year>
          5th International Workshop on, pp.
          <fpage>56</fpage>
          -
          <lpage>62</lpage>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          [37]
          <string-name>
            <given-names>IPMA</given-names>
            <surname>Young Crew</surname>
          </string-name>
          , “
          <article-title>Global young crew workshop (gycw),” in conjunction with the Project Management World Congress</article-title>
          , IPMA - International
          <source>Project Management Association</source>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref33">
        <mixed-citation>
          [38]
          <string-name>
            <given-names>A.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          , “
          <article-title>ImProject: Improvisation Techniques in Projects” presented as Focus Group at 16th European Conference on Pattern Languages of Programs, HYPERLINK "</article-title>
          http://www.hillside.net/europlop/europlop2011/focusgroups.html"http://www.hillside.net/europlop/europlop2011/foc us-groups.html,
          <year>2011</year>
        </mixed-citation>
      </ref>
      <ref id="ref34">
        <mixed-citation>
          [39]
          <string-name>
            <given-names>A.</given-names>
            <surname>Herrmann</surname>
          </string-name>
          ,
          <string-name>
            <given-names>R.</given-names>
            <surname>Fahney</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Rückert</surname>
          </string-name>
          , and
          <string-name>
            <given-names>R.</given-names>
            <surname>Weißbach</surname>
          </string-name>
          , “
          <article-title>Clear role and process definitions as a means to analyze and understand conflicts between project management and requirements engineering</article-title>
          ,” in
          <source>Beitrag zum `Workshop on the Interplay of Requirements Engineering and Project Management in Software Projects` der 13th IEEE Requirements Engineering conference</source>
          ,
          <year>2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref35">
        <mixed-citation>
          [40] G. e. a. Caupin, Ed.,
          <source>IPMA Competence Baseline, icb version 3</source>
          .0 ed. International Project Management Organization,
          <year>June 2006</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref36">
        <mixed-citation>
          [41]
          <string-name>
            <given-names>M.</given-names>
            <surname>Csikszentmihalyi</surname>
          </string-name>
          , “
          <article-title>Flow and education</article-title>
          ,”
          <source>NAMTA Journal</source>
          , vol.
          <volume>22</volume>
          , no.
          <issue>2</issue>
          , pp.
          <fpage>2</fpage>
          -
          <lpage>35</lpage>
          ,
          <year>1997</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref37">
        <mixed-citation>
          [42]
          <string-name>
            <given-names>D.</given-names>
            <surname>Snowden</surname>
          </string-name>
          , “
          <article-title>Story telling: an old skill in a new context,” Business Information Review</article-title>
          , vol.
          <volume>16</volume>
          , no.
          <issue>1</issue>
          , pp.
          <fpage>30</fpage>
          -
          <lpage>37</lpage>
          ,
          <year>1999</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref38">
        <mixed-citation>
          [43]
          <string-name>
            <given-names>S.</given-names>
            <surname>Jovchelovitch</surname>
          </string-name>
          and
          <string-name>
            <given-names>M.</given-names>
            <surname>Bauer</surname>
          </string-name>
          , “Narrative interviewing,”
          <article-title>Qualitative researching with text, image and sound</article-title>
          , pp.
          <fpage>57</fpage>
          -
          <lpage>74</lpage>
          ,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref39">
        <mixed-citation>
          [44]
          <string-name>
            <surname>R. B. Tobias</surname>
          </string-name>
          , 20 Master Plots and
          <article-title>how to build them</article-title>
          .
          <source>Writer's Digest Books</source>
          ,
          <year>2003</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref40">
        <mixed-citation>
          [45]
          <string-name>
            <given-names>N.</given-names>
            <surname>Iuppa</surname>
          </string-name>
          ,
          <string-name>
            <surname>G.</surname>
          </string-name>
          <article-title>Weltman, and</article-title>
          <string-name>
            <given-names>A.</given-names>
            <surname>Gordon</surname>
          </string-name>
          , “
          <article-title>Bringing hollywood storytelling techniques to branching storylines for training applications</article-title>
          ,”
          <source>in Proceedings of Narrative and Interactive Learning Environments NILE</source>
          ,
          <year>2004</year>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>8</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref41">
        <mixed-citation>
          [46]
          <string-name>
            <given-names>M.</given-names>
            <surname>Mahaux</surname>
          </string-name>
          and
          <string-name>
            <given-names>A.</given-names>
            <surname>Hoffmann</surname>
          </string-name>
          . Research preview:
          <article-title>Using improvisational theatre to invent and represent scenarios for designing innovative systems</article-title>
          .
          <source>In 18th International Working Conference on Requirements Engineering: Foundation for Software Quality</source>
          , pages
          <fpage>124</fpage>
          -
          <lpage>128</lpage>
          ,
          <year>2012</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>