<!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>Prahalad, C.K., Ramaswamy, V.: Co-creation experiences: The next practice in value creation. J. Interact.
Mark.</journal-title>
      </journal-title-group>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>Eliciting Requirements from Citizens - What Can We Learn from Other Disciplines?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Svenja Polst</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Frank Elberzhager</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Fraunhofer IESE</institution>
          ,
          <addr-line>Fraunhofer-Platz 1, 67663 Kaiserslautern</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2020</year>
      </pub-date>
      <volume>14</volume>
      <issue>2004</issue>
      <fpage>5</fpage>
      <lpage>14</lpage>
      <abstract>
        <p>[Context and motivation] The elicitation of requirements is an essential step for requirements engineers to build products and services that fit the needs of users and customers. In environments with connected systems, such as cyber-physical systems or digital ecosystems, several different stakeholders exist that have diverse requirements. One such environment is the smart city district that is the focus of our research project “EnStadt:Pfaff”. [Question/problem] One main question in such a context is how to elicit citizens' requirements and needs and how to motivate them to participate in creating digital services and apps that support their lives. [Principal ideas/results] Traditional requirements engineering and elicitation activities (such as workshops) are also relevant in such contexts, but we are also looking for new formats that may-be are more suitable for citizen crowds. We assume that we can learn from other disciplines about their methods and ways, e.g. to motivate citizens. [Contribution] We identified four disciplines and present their benefits for requirements engineering from our perspective. Our goal is to foster further discussions when presenting the corresponding poster.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>according to these authors, a paradigm shift is also necessary from focusing on software to holistically taking into
consideration people, things and services. Both paradigm shifts are highly relevant in smart city districts, where
software is part of everyday life of very diverse citizens and where software is a means for accessing things and
services, such as bike-sharing. The software is supposed to be used by all citizens, teenagers as well as elderly
people, experienced technology users as well as laypersons. In our research project “EnStadt:Pfaff”, the goal is
to create a climate-neutral city district. One aspect is to provide digital solutions and services to inhabitants or
visitors of this city district. In order to identify those requirements that are relevant for a diverse crowd, we are
looking for new requirements methods. Concretely, we face the following challenges:
1. How to get in touch with all groups of citizens? Citizens use different media. Elderly people still read the
newspaper whereas young people often prefer digital media. It would be helpful to know which media should
be used or combined in order to reach all citizens in the best possible way.
2. Which methods apply to citizens? Classical requirements elicitation methods could be applied, such as
workshops and interviews. However, workshops might exclude some people. They require citizens to visit
a certain location at a predefined time and thereby exclude mobility-impaired persons and citizens working
at that time. Therefore, other methods need to be developed to potentially address everyone.
3. How to motivate citizens to participate? If citizens do not see a personal benefit, it is likely that they will
have no interest in participating.
4. How to document the results? Novel methods might not require the presence of a requirements engineer,
who would normally take care of the documentation. Furthermore, the requirements need be documented in
a way that is accessible to the stakeholders. A typical specification might not be understandable to citizens.</p>
      <p>We assume that it is worth seeking inspiration from other disciplines to support this creative process and
to find inspiration for the other challenges.Our process for identifying new methods and ideas to address the
challenges is as follows: First, we plan to identify disciplines to seek inspiration from. The criteria for such
disciplines will be presented in the third section. Second, we plan to get familiar with the discipline, that we
think has the highest potential for addressing our challenges. While researching this discipline, we might already
find some measures to address our challenges. Third, we plan to conduct workshops to identify more methods
and ways to address our challenges. The workshops could be similar to the workshop format used in “Learning
from Other Disciplines for RE” (D4RE)1. D4RE is a workshop organized by Fraunhofer IESE, which took place
two times at the RE-Conference and one time at the REFSQ. The D4RE workshop consists of three steps: (1)
idea collection, (2) elaborating synergies, and (3) benefits and next steps. Fourth, we want to evaluate the
methods and measures that could be useful for addressing the challenges. Thereafter, the next discipline should
be selected and investigated.</p>
      <p>In this paper and the respective poster, we present criteria for selecting disciplines. Moreover, we present
disciplines we already identified and the reasons why we consider this discipline a potential source of inspiration.
However, we might misjudge the potential of these disciplines and there might be disciplines we have not thought
about yet. We invite the readers of this paper and the visitors of the poster session to discuss the potential of
the identified disciplines with us and share their ideas regarding other disciplines and what we could learn from
them.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Background and Related Work</title>
      <p>
        In the field of requirements engineering, the topic involving citizens (which hereafter we will call Citizen RE)
is discussed from different perspectives. In [9], different ways of involving citizens according to their roles are
discussed. According to the authors, citizens have the role of democratic participants, co-creators, and ICT-users.
In their role as co-creators, they could be involved through interviews and focus groups. In [
        <xref ref-type="bibr" rid="ref5">6</xref>
        ], the challenges
of mass participants are discussed. One challenge is how to motivate citizens. This challenge is also mentioned
in a paper presenting the landscape and challenges of Crowd-based Requirements Engineering (CrowdRE) [
        <xref ref-type="bibr" rid="ref3">4</xref>
        ].
In [
        <xref ref-type="bibr" rid="ref6">10</xref>
        ], it is discussed how citizen participation could benefit from systems engineering, for instance, by applying
SCRUM. However, no methods are mentioned for eliciting requirements from citizens. Furthermore, the discipline
’participation’ is explained. In [
        <xref ref-type="bibr" rid="ref1">2</xref>
        ], a suggestion for how to create new methods is presented. The authors suggest
combining different characteristics of methods (e.g., location: public buildings; presence of moderator:remote)
and creating a new method based on these characteristics. This creation process requires creativity. Inspiration
from other disciplines could enhance this creativity process. To sum up, motivating citizens to engage in Citizen
RE activities is a challenge. Furthermore, there is not much literature about elicitation methods that require
only little effort from citizens.
3
      </p>
    </sec>
    <sec id="sec-3">
      <title>Criteria for Disciplines</title>
      <p>First, we defined criteria that other disciplines should fulfill to be acceptable in our context. The disciplines
should use methods that
aim at obtaining data from citizens, such as their opinions, ideas, or usage data
address various groups of citizens
are applicable to a high number of persons
should not be a central event, but give citizens the freedom to decide how and when to participate.
Unsing these criteria, we want to find disciplines that inspire new methods and provide solutions to the challenges
mentioned above.
4</p>
    </sec>
    <sec id="sec-4">
      <title>Disciplines and What We can Learn from them</title>
      <p>So far, we identified the following disciplines and approaches: (1) ‘citizen science’, (2) ‘opinion polling’, (3)
‘co-creation’, and (4) ‘public participation’. In this section, we describe the disciplines and provide an example
of what RE could learn from them when working with citizens.
4.1</p>
      <sec id="sec-4-1">
        <title>Citizen science</title>
        <p>
          Citizen Science is defined as “a series of activities that link the general public with scientific research.
Volunteers and non-professionals contribute collectively in a diverse range of scientific projects to answer real-world
questions”. [
          <xref ref-type="bibr" rid="ref2">3</xref>
          ]. Citizens provide data they elicit, for instance, data about sea water for analyses of its color and
transparency in the project “citclops” 2. We assume that requirement engineers can learn from citizen scientists
about tools for documenting and transmitting data, how to address and motivate citizens. One lesson learned
from this discipline is the principle “Both the professional scientists and the citizen scientists benefit from taking
part” [
          <xref ref-type="bibr" rid="ref4">5</xref>
          ]. Citizen scientists could be motivated by learning from professional scientists and by influencing national
issues and policy. We assume that this principle could be transferred to requirements engineering. During the
elicitation process, requirement engineers could teach the citizens about RE or software engineering.
Furthermore, requirement engineers should give citizens feedback about what they have achieved in local issues, such as
digital services in smart city districts. So far, we consider citizen science a discipline worth further investigation
since it addresses our third challenge.
4.2
        </p>
      </sec>
      <sec id="sec-4-2">
        <title>Opinion Polling</title>
        <p>Opinion polling is the discipline of gathering opinions from a particular sample. The outcome is designed to
be representative of the group of people from which the sample is taken. The most common and popular form
of opinion polling are surveys political issues, conducted for example by institutes like Forsa or YouGov. In
opinion polling, the sample has to be representative, so all kinds of sub-groups of the target group have to be
identified. In the context of requirements elicitation, we assume that requirement engineers can learn how to
identify sub-groups of stakeholders. Furthermore, we could learn from opinion polling how to address the public.
For instance, the company ‘civey’ cooperates with online media companies. These companies have short polls on
their websites, so the participants participate take part in them on a website they are already visiting anyway.
In our opinion, requirement engineers should also try to get in touch with citizens on locations or on websites
they are visiting anyway, instead of requiring them to spend extra effort on visiting another place. So far, we
consider opinion polling a discipline worth further investigation since it addresses our first challenge.</p>
        <p>2http://www.citclops.eu/the-project/overview
Co-Creation, in the context of business, is a design process, where the focus lies on joint creation of value by
the company and the customer. It involves customers in a joint problem definition and problem-solving process
and lets them “co-construct the service experience to suit [their] context” [8]. We assume that we can learn from
co-creation how to motivate people and how to address them. For ‘co-creation’, the innovation lab ‘josephs’
could be a source of inspiration. Josephs is located at a central place in downtown Nuremberg. Everyone can
walk in, test services and prototypes, and provide feedback and ideas. Thus, no invitation or appointment is
necessary. The lab has similar opening hours as the surrounding shops. The feedback on the products and
services is forwarded to the companies, which pay to present their product or service. Such a central, physical
place for eliciting requirements and feedback might be valuable for a smart city district. We consider Co-Creation
a discipline worth further investigation since it addresses our first challenge.
4.4</p>
      </sec>
      <sec id="sec-4-3">
        <title>Public Participation</title>
        <p>Public participation processes are processes in which persons who are not entitled to participate in collective
decisions by virtue of their office or mandate are given the opportunity to communicate their knowledge,
preferences, assessments, and recommendations [7]. The involvement of citizens in the planning and decision-making
processes in the public sector can be legally required but may also follow informal processes [7]. This description
refers to the latter kind of processes in Germany. In these processes, representatives of a municipality,
communication experts, architects, or city planners commissioned by a municipality might take charge of the process.
We assume that we can learn from such public participation processes about how to involve diverse groups of
citizens and large numbers of persons and how to document the findings in a way that is comprehensible for the
citizens. We found inspiration in a tool used in a project in the town of Herrenberg (Germany). There, citizens
can mark spots for improvement (e.g. a dangerous intersection) in an app, add a picture, and assign an emoji
via an app [1]. This information is then displayed in a digital representation of the town. The 3D visualization
of the town and all marked spots provide a lot of contextual information, so people who do not know the marked
spot can still understand the issue. We assume that in RE, the use of an app for communicating requirements
and the as-is-situation, expressing the respective emotions via emojis, and visualizing the summarized findings in
an interesting way is beneficial when working with citizens. We consider public participation a discipline worth
further investigation since it addresses our fourth challenge.
5</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>Discussion</title>
      <p>Our research project is in the area of a smart city, currently focusing on a concrete district that is being built.
In such a district, several different stakeholders will live, work, and stay for various reasons. Therefore, it is
necessary to consider all these different stakeholders in order to be able to develop digital solutions that fit
their needs. We do not claim that our work is only applicable to citizens in a smart city district. However,
one characteristic of smart city districts is that the citizens whose requirements we want to obtain are located
within a limited physical space. This allows methods and procedures that might not be applicable to a wider
area such a whole city or region. Our selection of disciplines is not complete by far, but this was also not our
intention. We started with some initial disciplines where we see learning potential. We plan to take a closer look
at these disciplines and adapt the methods and lessons learned to our project “EnStadt:Pfaff”. Of course, one
relevant step is to test such methods and explore the benefits as well as the limitations. Moreover, it should be
considered which method fits which citizen sub-group and which methods could be combined to reach a wider
range of citizens. We plan to identify even more disciplines to learn about requirement elicitation with citizens.
6</p>
    </sec>
    <sec id="sec-6">
      <title>Conclusion and Outlook</title>
      <p>In this poster paper, we discussed the need for new requirements elicitation methods for environments such as
city districts, where several different stakeholders should be involved in creating ideas and requirements for digital
services and solutions. Such crowds are typically very diverse, and various methods are needed to cope with the
different needs of citizens. In the “EnStadt:Pfaff” research project, we want to apply lessons learned from other
disciplines, explore how to gather requirements from different stakeholders, and find out which methods are most
suitable best for whom. In addition, we plan to perform workshops with requirements experts and potentially
other experts to identify new ways of including many different stakeholders. The results will also help us also
identifying new requirements, especially for our context in the “EnStadt:Pfaff” project. We plan to include the
results from such workshops on the poster, as well.</p>
      <sec id="sec-6-1">
        <title>Acknowledgements</title>
        <p>Parts of this work have been funded by the “EnStadt: Pfaff” project (grants no. 03SBE112D and 03SBE112G) of
the German Federal Ministry for Economic Affairs and Energy (BMWi) and the Federal Ministry of Education
and Research (BMBF).
[9] Simonofski, A., Asensio, E.S., De Smedt, J., Snoeck, M.: Citizen participation in smart cities: Evaluation
framework proposal. In: 2017 IEEE 19th conference on business informatics (CBI). vol. 1, pp. 227–236.</p>
        <p>IEEE (2017)</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [2]
          <string-name>
            <surname>Doerr</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hess</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Koch</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Re and society - a perspective on re in times of smart cities and smart rural areas</article-title>
          .
          <source>In: 2018 IEEE 26th International Requirements Engineering Conference (RE)</source>
          . pp.
          <fpage>100</fpage>
          -
          <lpage>111</lpage>
          (
          <year>Aug 2018</year>
          ). https://doi.org/10.1109/RE.
          <year>2018</year>
          .00020
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>European</given-names>
            <surname>Union</surname>
          </string-name>
          :
          <source>Green Paper on Citizen Science</source>
          (
          <year>2014</year>
          ), https://ec.europa.eu/digital-single-market/ en/news/green-paper
          <article-title>-citizen-science-europe-towards-society-empowered-citizens-and-enhancedresearch</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [4]
          <string-name>
            <surname>Groen</surname>
            ,
            <given-names>E.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seyff</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ali</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dalpiaz</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Doerr</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Guzman</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hosseini</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Marco</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oriol</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perini</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          , et al.:
          <article-title>The crowd in requirements engineering: The landscape and challenges</article-title>
          .
          <source>IEEE software 34(2)</source>
          ,
          <fpage>44</fpage>
          -
          <lpage>52</lpage>
          (
          <year>2017</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Hecker</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Haklay</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bowser</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Makuch</surname>
            ,
            <given-names>Z.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vogel</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bonn</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Citzen Science</article-title>
          . UCL Press, London (
          <year>2018</year>
          ). https://doi.org/10.14324/111.9781787352339
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Johann</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maalej</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Democratic mass participation of users in requirements engineering</article-title>
          ? In: 2015 IEEE 23rd International Requirements Engineering Conference (RE). pp.
          <fpage>256</fpage>
          -
          <lpage>261</lpage>
          (
          <year>Aug 2015</year>
          ). https://doi.org/10.1109/RE.
          <year>2015</year>
          .7320433
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [10]
          <string-name>
            <surname>Vácha</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Přibyl</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lom</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bacúrová</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Involving citizens in smart city projects: systems engineering meets participation. 2016 smart cities symp prague</article-title>
          , scsp
          <year>2016</year>
          (
          <year>2016</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [11]
          <string-name>
            <surname>Villela</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Groen</surname>
            ,
            <given-names>E.C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Doerr</surname>
          </string-name>
          , J.:
          <article-title>Ubiquitous requirements engineering: A paradigm shift that affects everyone</article-title>
          .
          <source>IEEE Softw</source>
          .
          <volume>36</volume>
          (
          <issue>2</issue>
          ),
          <fpage>8</fpage>
          -
          <lpage>12</lpage>
          (
          <year>Mar 2019</year>
          ). https://doi.org/10.1109/MS.
          <year>2018</year>
          .
          <volume>2883876</volume>
          , https://doi.org/10.1109/MS.
          <year>2018</year>
          .2883876
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>