<!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>A Data-driven Framework to Facilitate Automated Requirements Engineering</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Sachiko Lim</string-name>
          <email>sachiko@dsv.su.se</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>Department of Computer and Systems Sciences, Stockholm University</institution>
          ,
          <addr-line>Stockholm</addr-line>
          ,
          <country country="SE">Sweden</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Supervisors: Jelena Zdravkovic</institution>
          ,
          <addr-line>Aron Henriksson</addr-line>
        </aff>
      </contrib-group>
      <fpage>60</fpage>
      <lpage>68</lpage>
      <abstract>
        <p>Traditionally, requirements engineering has been stakeholder driven. With the advent of digital technologies, unprecedented amounts of data are continuously generated. Although such dynamic data are not created with the intention of eliciting requirements, they may include information about system requirements, including up-to-date user requirements, which would be difficult to obtain with traditional elicitation methods. Thus, in addition to domain knowledge, dynamic data from unintended digital sources can potentially serve as valuable requirements sources and support automated and continuous requirements engineering. However, most previous efforts to automate the requirements engineering process have focused on eliciting requirements from domain knowledge that are relatively static, or partially supporting automation of specific requirements engineering activities. There is, thus, a lack of a holistic framework to automate the requirements engineering process that is driven by dynamic data from unintended digital sources. To address this research gap, the PhD study aims at developing a novel and holistic framework for automating data-driven requirements engineering. A design science approach will be used to develop the envisaged framework. This paper reports on the research progress based on the first six months of the PhD study, which includes explicating research problems, formulating research questions, and presenting an initial overview of the envisaged framework as well as preliminary results of a systematic review on the state-ofthe-art automated methods for eliciting requirements from dynamic data. The framework will support efficient and effective inclusion of important and relevant requirements for improving existing or developing new software systems.</p>
      </abstract>
      <kwd-group>
        <kwd>Requirements engineering</kwd>
        <kwd>Big Data</kwd>
        <kwd>Automation</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Requirements engineering consists of three core activities: elicitation,
documentation, and negotiation [2]. The main aim of the elicitation activity is to identify all the
stakeholder requirements and translate them into functional and non-functional
requirements. Requirements elicitation comprises three sub-activities: 1) identification of
relevant sources of requirements, 2) elicitation of requirements from the identified
sources, and, optionally, 3) elicitation of innovative requirements. The documentation
activity aims to document the results of each requirements engineering activity,
conforming to documentation rules and guidelines. Negotiation aims to achieve agreement
among all stakeholders by resolving conflicts of needs and wishes.</p>
      <p>In addition to the three core activities, two cross-sectional activities are performed
in requirements engineering: validation and management. Validation aims to assess the
quality of the outputs from the core activities in accordance with defined quality
criteria. Management aims to deal with requests of requirements changes, to establish
traceability among requirements, and to prioritize requirements [2].</p>
      <p>
        Traditional requirements engineering has largely depended on domain knowledge
that are obtained from stakeholders. With the capabilities of e- and mobile commerce
as well as the advent of IoT, the digitalization of organizations and societies at large
has been widespread, generating an unprecedented amount of high-velocity and
heterogeneous data, which is often referred to as Big Data [3]. This digital transformation
has spawned new opportunities to consider dynamic data from digital sources as
potentially valuable sources of requirements, in addition to domain knowledge. Crowd-based
requirements engineering (CrowdRE) is a good example that has taken advantages of
such new opportunities. In CrowdRE, large amounts of implicit and explicit feedback
from crowd users are embraced to elicit and mange requirements to facilitate
user-centered and continuous software development and evolution [
        <xref ref-type="bibr" rid="ref3">4</xref>
        ]. The SUPERSEDE
toolsuite supports combined analyses of end-user feedback and contextual data on software
products that are collected using multi-modal feedback gathering techniques [
        <xref ref-type="bibr" rid="ref4">5</xref>
        ].
Harnessing both traditional and new data sources can complement each other to improve
the quality of existing, or facilitate development of new, software systems [
        <xref ref-type="bibr" rid="ref5">6</xref>
        ].
      </p>
      <p>In this study, dynamic data is defined as raw data available in a digital form that
changes frequently and has not already been analyzed. Dynamic data certainly includes
but is not limited to Big Data. However, it excludes static domain knowledge that is
less frequently created or modified. Domain knowledge can be derived from internal
(e.g., intellectual property, business documents, existing system’s specifications, and
goals) or external sources (e.g., standards, conferences, and knowledge from customers
or external providers). Unintended digital sources are defined as sources of data
generated via digital technologies that are unintended with respect to requirements
elicitation. Thus, dynamic data from unintended digital sources are the changeable digital
data pulled from data sources that are created without the intention of eliciting
requirements. Of note is that the two terms “dynamic data” and “unintended digital source”
together define the scope of this research. For example, although domain documents
are often created without the intention of performing requirements engineering, they
are not considered as dynamic data, thus are excluded.</p>
      <p>
        Dynamic data from unintended digital sources can be classified into three data types:
human-sourced information data (e.g., social networks, blogs, internet searches on
search engines, contents from mobile phones), process-mediated data (e.g., electronic
health records, commercial transactions, credit card payments) and machine-generated
sources (e.g., sensor readings, mobile phone locations, Web logs) [
        <xref ref-type="bibr" rid="ref6">7</xref>
        ]. They, thus,
comprise a broader range of data sources than explicit and implicit user feedback.
      </p>
      <p>
        Unintended digital sources can include data relevant for new system requirements
which otherwise could not be discovered from other sources. Including such
requirements, which a current software system is not supporting, can bring business values in
the form of improved customer satisfaction, cost and time reduction, and optimized
operations [
        <xref ref-type="bibr" rid="ref7">8</xref>
        ]. Focusing on dynamic data also allows for capturing up-to-date user
requirements, which in turn enables timely and effective operational decision-making.
Moreover, dynamic data from unintended digital sources are machine-readable. Thus,
they serve as a good basis for paving new ways for automated and continuous
requirements engineering. A fitting requirements engineering approach can provide new
opportunities and competitive advantages in a fast-growing market by extracting real-time
business insights and knowledge from variety of digital sources.
2
      </p>
    </sec>
    <sec id="sec-2">
      <title>Research Problem and Research Questions</title>
      <p>
        Much effort has been made to facilitate automation of the requirements engineering
process in which requirements are primarily derived from domain knowledge that are
created by stakeholders. Arguably, either of the following aims have driven the
majority of such aforementioned efforts:
1) to elicit requirements from existing domain knowledge which are derived from
stakeholders (e.g., natural language (NL) documents [
        <xref ref-type="bibr" rid="ref8">9</xref>
        ] and models [
        <xref ref-type="bibr" rid="ref9">10</xref>
        ]),
2) to perform specific requirements engineering activities based on existing
requirements (e.g., requirements prioritization [
        <xref ref-type="bibr" rid="ref10">11</xref>
        ], classification of NL requirements [
        <xref ref-type="bibr" rid="ref11">12</xref>
        ],
and requirements validation [
        <xref ref-type="bibr" rid="ref12">13</xref>
        ]), and
3) to develop support tools to enhance stakeholders’ ability or engagement to perform
requirements engineering activities based on domain knowledge or existing
requirements (e.g., tool-support for collaborative requirements prioritization [
        <xref ref-type="bibr" rid="ref13">14</xref>
        ] and
requirements negotiation with rule-based reasoning [
        <xref ref-type="bibr" rid="ref14">15</xref>
        ]).
      </p>
      <p>Nevertheless, there is a paucity of research on utilizing dynamic data from
unintended digital sources to facilitate automation of the requirements engineering process.
Moreover, although there are pioneering works enabling automated requirements
engineering that are driven by dynamic data from unintended digital sources, by taking the
focus on specific activities, such works have only partially supported the automation of
the requirements engineering process. There is, thus, a lack of a holistic framework for
automating requirements engineering driven by dynamic data from unintended digital
sources.</p>
      <p>Therefore, the aim of this PhD study is to develop a novel and holistic framework
for automated and continuous requirements engineering of dynamic data from
unintended digital sources, hereinafter referred to as dynamic data. The following main and
sub-research questions were formulated to fill the knowledge gap:
How could the entire requirements engineering activities be efficiently and effectively
automated when the requirements sources are dynamic data?
• How can requirements be elicited from dynamic data?
• With the given elicitation approach, how can documentation, negotiation,
management and validation be supported through automation?
• How can machine learning techniques be applied to elicit innovative system
requirements from dynamic data?</p>
      <p>The envisaged framework will contribute to 1) utilizing the IoT and other digital
technologies for eliciting system requirements, 2) facilitating efficient and effective
inclusion of important and relevant requirements to develop new software systems, or
continuously improving existing systems, and 3) alleviating the workload and human
errors of requirements engineering by increasing the level of automation.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Overview of Research Framework</title>
      <p>
        data are unstructured and include a significant proportion of non-informative data for
requirements elicitation. Process-mediated data comprise quality issues such as
incompleteness and errors as well as non-representativeness due to non-random sampling,
which could produce misleading results and subsequent decisions [
        <xref ref-type="bibr" rid="ref15">16</xref>
        ]. Furthermore, it
is challenging to combine data from different sources that use different data types,
definitions, and periodicities [
        <xref ref-type="bibr" rid="ref15">16</xref>
        ]. Machine-generated data are subject to missing data,
noise, and errors. It is also hard to choose the frequency of data collection that is
sufficient to elicit “good-enough” requirements to control the cost of storing and analyzing
data.
      </p>
      <p>
        Elicit requirements: From the identified digital stakeholders, requirements will be
extracted automatically, using different algorithms depending on the type of data
sources. Eliciting requirements from data expressed in NL is a challenge due to the
ambiguous and unstructured nature. There are pioneering studies which elicited
requirements from human-sourced information sources such as twitter and app reviews
[
        <xref ref-type="bibr" rid="ref16">17</xref>
        ] [
        <xref ref-type="bibr" rid="ref17">18</xref>
        ]. Another challenge is to investigate methods to elicit system requirements
from process-mediated and machine-generated data that are not expressed in NL.
Regardless of data source types, it is difficult to elicit requirements while achieving an
optimal trade-off between completeness and correctness. Furthermore, it needs to be
considered how to integrate requirements from different types of sources.
      </p>
      <p>
        Requirements documentation: This step aims to automatically document the elicited
requirements and assess their quality. A challenge of this step is to identify appropriate
quality assessment criteria for each data source. For human-sourced information data,
disambiguation of NL requirements is an issue to be solved. Previous studies applied
natural language processing and machine learning techniques to tackle with the
ambiguity issues in NL [
        <xref ref-type="bibr" rid="ref18">19</xref>
        ] [
        <xref ref-type="bibr" rid="ref19">20</xref>
        ]. Likewise, a challenge of using process-mediated and
machine-generated data is to determine an optimal set of source-specific quality
dimensions such as accuracy, consistency, completeness, and freshness [
        <xref ref-type="bibr" rid="ref20 ref21 ref22">21–23</xref>
        ]. At the end
of this step, only the requirements that meet a given quality criteria should be saved,
while the others are further analyzed or discarded. However, in what form those
“quality” requirements are saved remains to be investigated.
      </p>
      <p>Requirements elicitation and documentation from existing software systems: If
domain knowledge is available and accessible, requirements are mined and specified
automatically. (Part B in Fig.1). Note that having existing requirements is not a
prerequisite for Part A.</p>
      <p>Negotiation: The “documented” requirements within and across different sources
should be matched to check for redundancy and/or conflicts. Identified redundant
and/or conflicting requirements should be harmonized. A main challenge is to
determine methods to automate the matching process and investigate how to match
requirements from different data sources.</p>
      <p>
        Management: This step aims to prioritize requirements, manage requirements
changes, and establish requirements traceability. Main concerns for prioritizations
include how to identify factors influencing the priority of requirements, how to optimally
reflect different stakeholders’ perspectives, and how to perform prioritization while
taking into account dependencies among requirements [
        <xref ref-type="bibr" rid="ref23 ref24">24, 25</xref>
        ]. Main challenges for
establishing traceability are: (i) to identify appropriate information retrieval techniques
to link requirements, (ii) to maintain traceability, while managing changes, and (iii) to
define a suitable trace granularity [
        <xref ref-type="bibr" rid="ref25 ref26 ref27">26–28</xref>
        ]. Requirements change includes three core
processes; change identification, change analysis, and change cost/effort estimation
[
        <xref ref-type="bibr" rid="ref28">29</xref>
        ]. A major challenge is to develop methods to automate those processes.
      </p>
      <p>Validation: The quality of requirements will be assessed in terms of consistency,
completeness, and correctness (3Cs). Challenges include when to validate
requirements, how to automate the validation process, and how to characterize properties of
3Cs for each data source.</p>
      <p>Documentation of validated requirements: The validated “document” will be stored
in a pool of existing requirements. In what form validated requirements should be saved
remains to be considered.
4</p>
    </sec>
    <sec id="sec-4">
      <title>Research Methodology</title>
      <p>
        The PhD study will use design science approach, because it aims at solving a practical
problem by creating a framework for dynamic data driven requirements engineering as
an artefact. To address our research questions, we will follow the five activities of the
design science research process as described in detail below [
        <xref ref-type="bibr" rid="ref29">30</xref>
        ]. Each activity will be
performed iteratively to refine the design of the framework.
      </p>
      <p>Explicate problem: Since the requirements engineering process starts with
requirements elicitation and the activity is a key driver for successful development of
information systems [2], a systematic literature review is ongoing, focusing on automated
requirements elicitation. The specific aims of the review are two-fold: 1) to understand
the state-of-the-art automated methods to elicit requirements from dynamic data, and
2) to identify gaps in existing methods and requirements for the elicitation process in
our envisaged framework.</p>
      <p>
        A comprehensive query-based search was performed in six electronic databases:
Scopus, Web of Science, ACM Digital Library, IEEE Xplore, EBSCOhost and
ProQuest. Those databases were selected because they together cover the top ten
information system journals and conferences [
        <xref ref-type="bibr" rid="ref30">31</xref>
        ]. In total, 1390 non-duplicate articles were
identified, among which 40 met our inclusion criteria to proceed to full-text screening.
We will also conduct literature reviews on existing methods to automate other
requirements engineering activities.
      </p>
      <p>Outline artefact and define requirements: The artefact type of the PhD study is a
holistic framework to automate dynamic data driven requirements engineering that are
outlined in Fig. 1. Functional and quality requirements on the outlined framework will
be elicited.</p>
      <p>Design and develop artefact: We will first get a number of ideas to be part of the
outlined artefact based on critical analysis of existing automated requirements
engineering methods. We will then decide which methods should be part of the design and
development of the envisaged framework by conducting small-scale experiments that
compare the performance of several candidate methods. This will aid evidence-based
selection of the methods that best meets our requirements. We will then design and
develop a set of automated methods for each requirements engineering activity.</p>
      <p>Demonstrate artefact: We will perform an illustrative or real-life case study to show
to what extent our designed framework can address the explicated problems as
intended. The framework will be further refined and finalized based on the results of the
case study.</p>
      <p>
        Evaluate artefact: The proposed framework will be evaluated quantitatively for
verification, using a combination of formative and summative evaluations. They focus on
the effectiveness and efficiency of the framework. Effectiveness will be assessed in
terms of completeness and correctness of algorithms to automate each requirements
engineering activity, using standard metrics such as recall and precision, respectively
[
        <xref ref-type="bibr" rid="ref30">31</xref>
        ]. Efficiency can be assessed by measuring the time that is required for the
framework to perform the entire requirements engineering process. The performance of
proposed framework will be compared to that of the state-of-the-art artefacts, whenever
possible.
5
      </p>
    </sec>
    <sec id="sec-5">
      <title>Conclusion</title>
      <p>In addition to conventional domain knowledge, widespread digitalization of
organizations and societies at large has created new opportunities to automate requirements
engineering activities that are driven by dynamic data. There is, thus, a growing need of
a framework to harness such fast-growing and large amounts of data for requirements
engineering and gain near real-time insights and knowledge out of them. Nevertheless,
previous studies have disproportionately focused on eliciting requirements from static
domain knowledge, or on supporting automation of specific activities of requirements
engineering. There is a paucity of research on automating the entire requirements
engineering process that are driven by dynamic data. Therefore, the ultimate aim of the PhD
study is to develop a novel and holistic framework to address the research gap, using
design science methodology. As the progress of the first six months of the study, this
paper explicated research problems, formulated research questions, and presented an
initial overview of the envisaged framework with associated challenges as well as
preliminary results of the systematic review on automated requirements elicitation from
dynamic data. The framework will help requirements engineers leverage dynamic data
to elicit innovative system requirements, facilitate efficient and effective inclusion of
important and relevant requirements to develop new software systems, or continuously
improve existing systems, and alleviate the workload and human errors of requirements
engineering by increasing the level of automation.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <string-name>
            <surname>Pohl</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Requirements engineering: fundamentals, principles, and techniques</article-title>
          . Springer, Heidelberg ; New York (
          <year>2010</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chiang</surname>
            ,
            <given-names>R.H.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Storey</surname>
            ,
            <given-names>V.C.</given-names>
          </string-name>
          :
          <article-title>Business Intelligence and Analytics: From Big Data to Big Impact</article-title>
          .
          <source>MIS Quarterly</source>
          .
          <volume>36</volume>
          ,
          <fpage>1165</fpage>
          -
          <lpage>1188</lpage>
          (
          <year>2012</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          4.
          <string-name>
            <surname>Maalej</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nayebi</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Johann</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruhe</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          :
          <article-title>Toward data-driven requirements engineering</article-title>
          .
          <source>IEEE Software</source>
          .
          <volume>33</volume>
          ,
          <fpage>48</fpage>
          -
          <lpage>54</lpage>
          (
          <year>2016</year>
          ). https://doi.org/10.1109/MS.
          <year>2015</year>
          .
          <volume>153</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          5.
          <string-name>
            <surname>Perini</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Data-Driven Requirements Engineering. The SUPERSEDE Way</article-title>
          . In: LossioVentura,
          <string-name>
            <given-names>J.A.</given-names>
            ,
            <surname>Muñante</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            , and
            <surname>Alatrista-Salas</surname>
          </string-name>
          , H. (eds.)
          <source>Information Management and Big Data</source>
          . pp.
          <fpage>13</fpage>
          -
          <lpage>18</lpage>
          . Springer International Publishing (
          <year>2019</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          6.
          <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>
          ,
          <string-name>
            <surname>Stade</surname>
            ,
            <given-names>M.:</given-names>
          </string-name>
          <article-title>The Crowd in Requirements Engineering The Landscape and Challenges</article-title>
          . Ieee Software.
          <volume>34</volume>
          ,
          <fpage>44</fpage>
          -
          <lpage>52</lpage>
          (
          <year>2017</year>
          ). https://doi.org/10.1109/MS.
          <year>2017</year>
          .
          <volume>33</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          7.
          <string-name>
            <surname>Firmani</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Mecella</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Scannapieco</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Batini</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>On the Meaningfulness of “Big Data Quality” (Invited Paper)</article-title>
          .
          <source>Data Science and Engineering. 1</source>
          ,
          <fpage>6</fpage>
          -
          <lpage>20</lpage>
          (
          <year>2016</year>
          ). https://doi.org/10.1007/s41019-015-0004-7.
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          8.
          <string-name>
            <surname>Ferguson</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Big Data-Why Transaction Data is Mission Critical To Success</article-title>
          . Intelligence Business Strategies Limited. https://public. dhe. ibm. com/common/ssi/ecm/im/en/iml14442usen/IML14442USEN. PDF. (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          9.
          <string-name>
            <surname>Slankas</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Williams</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Automated extraction of non-functional requirements in available documentation</article-title>
          .
          <source>In: 2013 1st International Workshop on Natural Language Analysis in Software Engineering (NaturaLiSE)</source>
          . pp.
          <fpage>9</fpage>
          -
          <lpage>16</lpage>
          (
          <year>2013</year>
          ). https://doi.org/10.1109/NAturaLiSE.
          <year>2013</year>
          .
          <volume>6611715</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          10.
          <string-name>
            <surname>Nogueira</surname>
            ,
            <given-names>F.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>De Oliveira</surname>
            ,
            <given-names>H.C.</given-names>
          </string-name>
          :
          <article-title>Application of heuristics in business process models to support software requirements specification</article-title>
          .
          <source>Presented at the ICEIS 2017 - Proceedings of the 19th International Conference on Enterprise Information Systems</source>
          (
          <year>2017</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          11.
          <string-name>
            <surname>Shao</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peng</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lai</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wang</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>DRank: A semi-automated requirements prioritization method based on preferences and dependencies</article-title>
          .
          <source>Journal of Systems and Software</source>
          .
          <volume>126</volume>
          ,
          <fpage>141</fpage>
          -
          <lpage>156</lpage>
          (
          <year>2017</year>
          ). https://doi.org/10.1016/j.jss.
          <year>2016</year>
          .
          <volume>09</volume>
          .043.
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          12.
          <string-name>
            <surname>Abad</surname>
            ,
            <given-names>Z.S.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karras</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ghazi</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Glinz</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ruhe</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schneider</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>What Works Better? A Study of Classifying Requirements</article-title>
          .
          <source>Presented at the Proceedings - 2017 IEEE 25th International Requirements Engineering Conference</source>
          ,
          <string-name>
            <surname>RE</surname>
          </string-name>
          <year>2017</year>
          (
          <year>2017</year>
          ). https://doi.org/10.1109/RE.
          <year>2017</year>
          .
          <volume>36</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          13.
          <string-name>
            <surname>Kamalrudin</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hosking</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grundy</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>MaramaAIC: tool support for consistency management and validation of requirements</article-title>
          .
          <source>Automated Software Engineering</source>
          .
          <volume>24</volume>
          , (
          <year>2017</year>
          ). https://doi.org/10.1007/s10515-016-0192-z.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          14.
          <string-name>
            <given-names>F.</given-names>
            <surname>Kifetew</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Munante</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Perini</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Susi</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Siena</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Busetta: DMGame: A Gamified Collaborative</surname>
          </string-name>
          <article-title>Requirements Prioritisation Tool</article-title>
          . In: 2017 IEEE 25th International Requirements Engineering Conference (RE). pp.
          <fpage>468</fpage>
          -
          <lpage>469</lpage>
          (
          <year>2017</year>
          ). https://doi.org/10.1109/RE.
          <year>2017</year>
          .
          <volume>46</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          15.
          <string-name>
            <surname>Ahmad</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jalil</surname>
            ,
            <given-names>I.E.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ahmad</surname>
            ,
            <given-names>S.S.S.:</given-names>
          </string-name>
          <article-title>An Enhancement of Software Requirements Negotiation with Rule-based Reasoning: A Conceptual Model</article-title>
          .
          <source>Journal of Telecommunication</source>
          , Electronic and Computer Engineering (JTEC).
          <volume>8</volume>
          ,
          <fpage>193</fpage>
          -
          <lpage>198</lpage>
          (
          <year>2016</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          16.
          <string-name>
            <surname>Hand</surname>
            ,
            <given-names>D.J.:</given-names>
          </string-name>
          <article-title>Statistical challenges of administrative and transaction data</article-title>
          .
          <source>Journal of the Royal Statistical Society: Series A (Statistics in Society)</source>
          .
          <volume>181</volume>
          ,
          <fpage>555</fpage>
          -
          <lpage>605</lpage>
          (
          <year>2018</year>
          ). https://doi.org/10.1111/rssa.12315.
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          17.
          <string-name>
            <surname>Guzman</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ibrahim</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Glinz</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <string-name>
            <given-names>A Little</given-names>
            <surname>Bird Told</surname>
          </string-name>
          <article-title>Me: Mining Tweets for Requirements and Software Evolution</article-title>
          .
          <source>In: 2017 IEEE 25th International Requirements Engineering Conference (RE)</source>
          . pp.
          <fpage>11</fpage>
          -
          <lpage>20</lpage>
          (
          <year>2017</year>
          ). https://doi.org/10.1109/RE.
          <year>2017</year>
          .
          <volume>88</volume>
          .
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          18.
          <string-name>
            <surname>Chen</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Hoi</surname>
            ,
            <given-names>S.C.H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Xiao</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zhang</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>AR-miner: Mining Informative Reviews for Developers from Mobile App Marketplace</article-title>
          .
          <source>In: Proceedings of the 36th International Conference on Software Engineering</source>
          . pp.
          <fpage>767</fpage>
          -
          <lpage>778</lpage>
          . ACM, New York, NY, USA (
          <year>2014</year>
          ). https://doi.org/10.1145/2568225.2568263.
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          19.
          <string-name>
            <surname>Gleich</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Creighton</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kof</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          :
          <article-title>Ambiguity detection: Towards a tool explaining ambiguity sources</article-title>
          .
          <source>Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)</source>
          .
          <source>6182 LNCS</source>
          ,
          <fpage>218</fpage>
          -
          <lpage>232</lpage>
          (
          <year>2010</year>
          ). https://doi.org/10.1007/978-3-
          <fpage>642</fpage>
          -14192-8_
          <fpage>20</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          20.
          <string-name>
            <surname>Yang</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Willis</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>De Roeck</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nuseibeh</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Automatic detection of nocuous coordination ambiguities in natural language requirements</article-title>
          .
          <source>In: Proceedings of the IEEE/ACM international conference on Automated software engineering</source>
          . pp.
          <fpage>53</fpage>
          -
          <lpage>62</lpage>
          . ACM (
          <year>2010</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          21.
          <string-name>
            <surname>Li</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dong</surname>
            ,
            <given-names>X.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lyons</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Meng</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Srivastava</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Truth finding on the deep web: is the problem solved?</article-title>
          <source>Proceedings of the VLDB Endowment</source>
          .
          <volume>6</volume>
          ,
          <fpage>97</fpage>
          -
          <lpage>108</lpage>
          (
          <year>2012</year>
          ). https://doi.org/10.14778/2535568.2448943.
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          22.
          <string-name>
            <surname>Manzoor</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Truong</surname>
          </string-name>
          , H.-L.,
          <string-name>
            <surname>Dustdar</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>On the evaluation of quality of context</article-title>
          .
          <source>In: European Conference on Smart Sensing and Context</source>
          . pp.
          <fpage>140</fpage>
          -
          <lpage>153</lpage>
          . Springer (
          <year>2008</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          23.
          <string-name>
            <surname>Sha</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Shi</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Consistency-driven data quality management of networked sensor systems</article-title>
          .
          <source>Journal of Parallel and Distributed Computing</source>
          .
          <volume>68</volume>
          ,
          <fpage>1207</fpage>
          -
          <lpage>1221</lpage>
          (
          <year>2008</year>
          ). https://doi.org/10.1016/j.jpdc.
          <year>2008</year>
          .
          <volume>06</volume>
          .004.
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          24.
          <string-name>
            <surname>Lehtola</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kauppinen</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kujala</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Requirements prioritization challenges in practice</article-title>
          .
          <source>In: International Conference on Product Focused Software Process Improvement</source>
          . pp.
          <fpage>497</fpage>
          -
          <lpage>508</lpage>
          . Springer (
          <year>2004</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          25.
          <string-name>
            <surname>Gupta</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gupta</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>CDBR: A semi-automated collaborative execute-before-after dependency-based requirement prioritization approach</article-title>
          , https://www.scopus.com/inward/record.uri?eid=
          <fpage>2</fpage>
          -
          <lpage>s2</lpage>
          .
          <fpage>0</fpage>
          -
          <lpage>85054588910</lpage>
          &amp;doi=10.1016%2fj.jksuci.
          <year>2018</year>
          .
          <volume>10</volume>
          .004&amp;partnerID=
          <volume>40</volume>
          &amp;md5=
          <fpage>50e9d383e341cb178e68c1ab401a1efe</fpage>
          , (
          <year>2018</year>
          ). https://doi.org/10.1016/j.jksuci.
          <year>2018</year>
          .
          <volume>10</volume>
          .004.
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          26.
          <string-name>
            <surname>Cleland-Huang</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Settimi</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zou</surname>
            ,
            <given-names>X.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Solc</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <source>Automated classification of non-functional requirements. Requirements Eng</source>
          .
          <volume>12</volume>
          ,
          <fpage>103</fpage>
          -
          <lpage>120</lpage>
          (
          <year>2007</year>
          ). https://doi.org/10.1007/s00766-007- 0045-1.
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          27.
          <string-name>
            <surname>Egyed</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Grunbacher</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Automating requirements traceability: Beyond the record &amp; replay paradigm</article-title>
          .
          <source>In: Proceedings 17th IEEE International Conference on Automated Software Engineering</source>
          ,. pp.
          <fpage>163</fpage>
          -
          <lpage>171</lpage>
          . IEEE (
          <year>2002</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          28.
          <string-name>
            <surname>Kannenberg</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Saiedian</surname>
          </string-name>
          , H.:
          <article-title>Why software requirements traceability remains a challenge</article-title>
          .
          <source>CrossTalk The Journal of Defense Software Engineering</source>
          .
          <volume>22</volume>
          ,
          <fpage>14</fpage>
          -
          <lpage>19</lpage>
          (
          <year>2009</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          29.
          <string-name>
            <surname>Jayatilleke</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lai</surname>
            ,
            <given-names>R.:</given-names>
          </string-name>
          <article-title>A systematic review of requirements change management</article-title>
          .
          <source>Information and Software Technology</source>
          .
          <volume>93</volume>
          ,
          <fpage>163</fpage>
          -
          <lpage>185</lpage>
          (
          <year>2018</year>
          ). https://doi.org/10.1016/j.infsof.
          <year>2017</year>
          .
          <volume>09</volume>
          .004.
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          30.
          <string-name>
            <surname>Johannesson</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Perjons</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>An introduction to design science</article-title>
          . Springer (
          <year>2014</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          31.
          <string-name>
            <surname>Meth</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brhel</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Maedche</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The state of the art in automated requirements elicitation</article-title>
          .
          <source>Information and Software Technology</source>
          .
          <volume>55</volume>
          ,
          <fpage>1695</fpage>
          -
          <lpage>1709</lpage>
          (
          <year>2013</year>
          ). https://doi.org/10.1016/j.infsof.
          <year>2013</year>
          .
          <volume>03</volume>
          .008.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>