<!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>Use of Domain Ontologies to Improve Requirements Quality</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Christian Kücherer</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Institute of Computer Science, University of Heidelberg Im Neuenheimer Feld 205</institution>
          ,
          <addr-line>69120 Heidelberg</addr-line>
          ,
          <country country="DE">Germany</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>[Context and motivation] Requirements are of great importance for the development of software systems to document and meet stakeholder needs. Software requirements can be affected by several quality defects during the Requirements Engineering (RE) process, for example ambiguity, inconsistency, and incompleteness. These quality defects lead to incorrect systems, unnecessary system functions, and thus to additional costs and effort. [Question/problem] Domain ontologies (DOs) contain formalized and conceptualized knowledge of real world domains. Existing works show how DOs can be used in RE to improve the quality of requirements wrt. specific quality attributes. During system specification, different specification levels allow explicit decisions about all aspects of the system to be built. It has not been studied so far, how DOs can be used comprehensively on the different levels of system specification and for different quality attributes. [Principal ideas/results] The thesis will provide a conceptual framework for utilizing DOs on different levels of system specification. Throughout all DO-based approaches, several implicit DO utilization patterns exist. The framework relates three dimensions: (i) quality attributes, (ii) DO utilization patterns, and (iii) their impact on the specification level. The framework will be evaluated in combination with a task-oriented RE method and a real project. [Contribution] This paper describes the problem, related work, main solution ideas, the research methodology, and progress so far.</p>
      </abstract>
      <kwd-group>
        <kwd>RE quality defects</kwd>
        <kwd>Requirements Quality Attributes</kwd>
        <kwd>Ontologies</kwd>
        <kwd>Domain Ontologies</kwd>
        <kwd>Task-oriented Requirements Engineering</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        Software requirements capture the stakeholder needs wrt. a software system.
These requirements are documented in a software requirements specification
(SRS) that contains many individual requirements (IRs). During the
requirements engineering (RE) activities [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] elicitation and documentation, IRs and
SRSs can be affected by quality defects. The ISO/IEC 29148 standard [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ]
defines that IR must have several characteristics, such as unambiguity, consistency,
      </p>
      <p>Copyright 2017 for this paper by its authors. Copying permitted for private and academic purposes
completeness, traceability, and verifiability. Characteristics that must be
considered for SRSs are, among others, completeness, and consistency. We call these
characteristics quality attributes for IRs and SRSs. IRs and SRSs cover different
levels of system specification, such as supported tasks, user interaction, or the
system architecture. Such levels allows to document the decisions from different
perspectives onto the system to be developed explicitly.</p>
      <p>
        One way to improve the quality of IRs and SRSs wrt. various quality
attributes is the use of ontologies [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ]. Ontologies conceptualize real world
knowledge in the form of machine interpretable concepts, their relations to each other,
and their rules [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ]. Each concept might be represented by a 3-tuple subject,
predicate, object describing the relations (predicate) between real world subjects and
objects, e.g. (SRS, consistsOf, IRs). An ontology can be queried by a formal
language such as SPARQL [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ] to access its concepts and relations. With reasoning,
logical inference is supported based on rules inside the ontology. Ontologies are
used in Software Engineering (SE) throughout the whole SE process, respectively
in all RE-activities for a broad range of problems (cf. Happel and Seedorf [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ]).
Ontologies can describe SRSs and formal RE knowledge [
        <xref ref-type="bibr" rid="ref2 ref5">5,2</xref>
        ]. In particular, a
domain ontology (DO) describes specific knowledge of a domain. A DO comprise
among other things, typical stakeholder roles, functions or tasks, common
application components, or entities. An example of a DO is the Semantical Network of
Information Management in Hospitals (SNIK) [
        <xref ref-type="bibr" rid="ref10">10</xref>
        ], showing concepts and their
relations of the information management domain in hospitals1.
      </p>
      <p>Several works show how RE can be improved with DOs. The utilization of
DOs depends on the quality attributes addressed, differs in their prerequisites,
and focuses on certain system aspects. However, it has not been studied so far,
how DOs can be used comprehensively on different levels of system specification
to improve a SRS wrt. multiple quality attributes.</p>
      <p>Section 2 of this paper describes the research problem treated in the thesis.
Section 3 gives an overview of related work, in particular of existing approaches
to utilize ontologies to improve the quality of IRs and SRSs. Section 4 presents
the proposed solution. Section 5 discusses the applied research methods. Finally,
the paper is concluded with a progress report in Section 6.
2</p>
    </sec>
    <sec id="sec-2">
      <title>Problem</title>
      <p>
        A SRS documents various aspects of the system to be developed, such as user
tasks/goals, domain data, user interaction, features, data-structures, and
software architecture. Existing RE frameworks often group these aspects into
specification levels. For example, the task-oriented RE framework TORE [
        <xref ref-type="bibr" rid="ref1 ref12">1,12</xref>
        ] aims
to deliver software that satisfies user needs and therefore focuses on stakeholder
tasks. TORE encompasses four specification levels: The goal &amp; task level focuses
on stakeholders, their goals and tasks. The domain level accommodates as-is
and to-be activities, refining the tasks into subtasks, system features, and domain
1 A visualization of the ontology is available at http://www.snik.eu/graph
data. The interaction level determines how users will be supported in their
to-beactivities by the system through use cases, workspaces, user interface-structure,
and system functions. Finally, the system level determines user interface details
and internal system details such as infrastructure and system architecture.
      </p>
      <p>Quality defects can emerge on any specification level. E.g. the task
description might miss crucial tasks (incompleteness) or the domain data model might
contain redundancies coming from synonyms (ambiguity). DOs can be used
during the specification to support the required quality attributes of IRs and the
SRS. The DO utilization depends on the required IR/SRS quality attributes,
the type of RE-artifacts, and the required level of detail of IRs/SRSs. In
consequence, a great variety of DO utilization methods at different specification levels
are available. The thesis will provide a framework of the various ways of using
DOs on different specification levels to address RE quality attributes. We want
to define this framework and evaluate it with the existing RE method TORE.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Related Work</title>
      <p>
        There are a several works that deal with RE quality attributes systematically.
Wagner et al. proposes the Quamoco Product Quality Modelling and
Assessment Approach to close the gap between abstract quality definitions and
concrete quality assessment techniques [
        <xref ref-type="bibr" rid="ref16">16</xref>
        ]. They relate general quality concepts
from existing quality standards, such as ISO/IEC 25010 [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ], to specific
quality assessment methods. In a mapping study, Pekar et al. [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] investigate the
frequency of researched SRS defects and improvement methods in current
research. To avoid SRS quality defects, they found several improvement methods,
such as correctness- and completeness checking, ambiguity solving, and glossary.
Saavedra et al. [
        <xref ref-type="bibr" rid="ref15">15</xref>
        ] provide an extensive overview of SRS quality attributes and
investigate existing studies to analyze and evaluate quality attributes of IRs and
SRSs. They systematically map 15 existing approaches wrt. their impact on 23
quality attributes and show potential influences between quality attributes.
      </p>
      <p>None of the presented works focuses on DO and none investigates the relation
to specification levels. We will build on the provided systematics for quality
attributes, assessment and improvement methods.</p>
      <p>
        A recent systematic literature review (SLR) by Dermeval et al. [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]
investigates the use of ontologies in RE based on 67 studies. The overview shows
that ontologies are used manifold in RE, ranging from formalized RE
knowledge in ontologies to automatic specification improvement techniques based on
reasoning. However, Dermeval et al. do not investigate details on how the RE
quality defects are addressed by the ontology utilization exactly. We therefore
are revisiting the 67 studies to go into more detail. In 27 studies we have seen
so far that 44 % (12) of the approaches address a single quality attribute only,
followed by 25 % (7) which address two. Fifteen percent (4) contribute to three
resp. four quality attributes, whilst no approach at all contributes to more than
four quality attributes. So far there is no study that relates different ways of DO
utilization to comprehensively support various quality attributes.
      </p>
      <sec id="sec-3-1">
        <title>Quality</title>
      </sec>
      <sec id="sec-3-2">
        <title>Attribute</title>
        <p>Legend</p>
        <p>Relation in framework
Relation to ontology</p>
      </sec>
      <sec id="sec-3-3">
        <title>Ontology</title>
      </sec>
      <sec id="sec-3-4">
        <title>Utilization Pattern</title>
      </sec>
      <sec id="sec-3-5">
        <title>Domain</title>
      </sec>
      <sec id="sec-3-6">
        <title>Ontology</title>
      </sec>
      <sec id="sec-3-7">
        <title>Specification</title>
      </sec>
      <sec id="sec-3-8">
        <title>Level</title>
        <p>The solution idea is to provide a framework that relates quality attributes, DO
utilization, and specification level. The benefit of this framework is twofold. First,
it supports requirements engineers (ReqEngs) and researchers in the
development and customization of RE-methods. Second, it supports ReqEngs in the
selection of appropriate methods to match predefined quality attributes in a
SRS. This three-dimensional relation is shown schematically in Fig. 1. Thick
lines indicate the relations emphasized in the framework, the thin line indicate
the relation of the DO utilization to the DO.</p>
        <p>
          In the thesis the details of DO utilization as described in existing studies
(selected in Dermevals SLR) will be investigated and synthesized into DO utilization
patterns. The reason for defining DO utilization patterns is that although existing
approaches utilize a DO differently, they share several common characteristics.
A DO utilization pattern is similar to a software design pattern [
          <xref ref-type="bibr" rid="ref3">3</xref>
          ] and shows a
usage scenario of a DO in combination with RE-artifacts, the information flow
to a ReqEng, and automatic activities to achieve quality attributes of IRs and
SRSs. Such patterns are described graphically. Ellipses indicate ontologies, an
actor indicates the ReqEng, a document symbol indicates rules or templates, and
boxes indicate automatic activities. Directed arrows between symbols indicate
an information flow, non-directional lines indicate an involved-in relation.
        </p>
        <p>There is no catalog of DO utilization patterns so far. Four examples of DO
utilization patterns that have been identified so far are shown in Fig. 2. The
glossary pattern shows a DO that is used by an ReqEng to create a new or to
improve an existing RE-artifact, using standard terms of the domain contained in
the DO, acting as a glossary. The template type-mapping pattern shows that DOs
are used in combination with typed templates by the ReqEng to create an
REartifact. Typed templates can be both, boiler plates that are sentence templates
with predefined attributes, or templates such as use-case or subtask-templates.
The formalization pattern uses a language ontology (containing synonyms),
utilize natural language processing (NLP) techniques to create an ontology from
existing RE-artifacts and recreate or modify the RE-artifact from this
intermediate ontology. Approaches that follow the reasoning pattern formalize existing
Glossary pattern
&lt;&lt;OgDlnootmsoslaoaigrnyy&gt;&gt; gltoesrsmarsy</p>
        <p>gltoesrsmarsy RE-artifact
attribute
Template type-mapping pattern</p>
        <p>meta model Domain Attribute instances
mapping Ontology
template</p>
        <p>RE-artifact</p>
        <p>Reasoning pattern</p>
        <p>terms
FRoErm-aarlitzsieafnatticoentnces, modelsODnotCmoolaonignsyistreulnescreyarusloensing
defect
report
review
RE</p>
        <p>artifacts
Formalization pattern</p>
        <p>Language
Ontology</p>
        <p>REN-aLrtPtiefarmctssettarmndsardizOeDdsntoatnmodlaaordtigenizryemdsrerecrvReieawEte-artifact
Legend: Ontology IR or SRS automatic activity Rules or Templates
Requirements Engineer
uses
Information flow
RE-artifacts into a DO (based on the formalization pattern). With consistency
rules and reasoning they identify missing or incorrect requirements collected in
a defect report.</p>
        <p>The following example illustrates the concrete usage of a DO utilization
pattern in combination with TORE to reduce ambiguity. Given a DO with the
meta model &lt;role&gt;, &lt;function&gt;, &lt;relation&gt; and the 3-tuple (CIO,
StrategicPlanning, isResponsibleFor), where CIO is a role and StrategicPlanning is a
function. Further, a subtask (ST) template stn:(STName, Actor,
Description, ...) allowing any free text, can be mapped to the DO meta model (STName
! function, Actor ! role). For the specification of a concrete subtask, DO
concepts as glossary entries can be retrieved by an requirements engineer. The
subtask st1 could be instantiated retrieving the glossary entries CIO as Actor
and StrategicPlanning as STName that is a function in the DO. Then the fields
STName and Actor of the subtask are filled with glossary entries
(StrategicPlanning, CIO, ...). The reasoning pattern can be used to identify other subtasks of
the actor improving SRS completeness.</p>
        <p>Obviously, DO utilization on various specification levels requires tool support.
This tool support may comprise CASE or requirements management tools, an
issue tracker, or the ontology editor protégé2. The use of these tools in relation
to the DO utilization patterns is to be investigated in the thesis.
2 Protégé ontology editor and framework. http://protege.stanford.edu/
start</p>
        <p>Ontologies supporting quality attributes in RE</p>
        <p>KLiittcehreantuhraemRe&amp;viCehwaratcecr.s tDheefvDreaOlmoupetmwilieoznrakttioofn</p>
        <p>Definition of
TORE Extension
and tool support</p>
        <p>Retrospective
evaluation of
Ontology usage</p>
        <p>Apply in
other
project
end
Publish extended SLR</p>
        <p>Publish DO utilization
framework</p>
        <p>Publish case study
The general research method of the thesis is to define the framework based on the
extensive analysis of the existing approaches that utilize DOs in order to
improve IRs and SRSs wrt. their quality attributes, to instantiate the framework
for TORE and to evaluate the usefulness of this instance (see also Fig. 3). We
plan the application of the framework in a project as far as possible.</p>
        <p>
          First, a systematic literature review according to Kitchenham and
Charters [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] is performed to extend Dermeval’s SLR to answer the RQ: How can
domain ontologies be utilized on different system specification levels in an RE
method to improve the quality of IRs and SRSs? To achieve this, all referenced
studies of Dermeval et al. are revisited to find quality attribute-related patterns
in the ontology utilization and understand the principles of existing approaches.
        </p>
        <p>Based on this SLR, the framework is defined by considering related work on
quality attributes and improvement or assessment methods. Then, the framework
is instantiated for TORE and its different specification levels resulting in different
extensions for TORE. They will partly be supported by a tool. As a first step,
a JIRA3 plugin for task and persona description is currently developed in an
ongoing B.Sc.-thesis that uses a DO as glossary.</p>
        <p>
          This instantiation will be evaluated in a case study using a retrospective
evaluation on real RE data of an existing project. In parallel with the previously
mentioned SNIK-Ontology, a dashboard-like tool called CIO-Navigator (CION)
was developed based on TORE. This software supports the CIO in strategic,
tactical, and operational information management decision making. Based on
the performed development process and TORE-artifacts and the SNIK-Ontology,
the usage of different TORE extensions will be explored. The case study will be
organized according to Runeson and Höst [
          <xref ref-type="bibr" rid="ref14">14</xref>
          ].
6
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>Progress</title>
      <p>Only the work on the two left activities in Fig. 3 has already started.
Approx. 40 % of the SLR-studies have been evaluated wrt. their DO utilization,
resulting in four DO utilization pattern identified so far. First ideas for
application of the identified patterns for TORE extensions have been developed.
3 Atlassian issue- and project tracker. https://atlassian.com/software/jira
Acknowledgments I thank my advisor Barbara Paech for her excellent support.
This work was supported by the DFG (German Research Foundation) in the Project
SNIK, Grant no. 1605/7-1 and 1387/8-1.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Adam</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Doerr</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Eisenbarth</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Gross</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Using Task-oriented Requirements Engineering in Different Domains - Experience of Application in Research and Industry</article-title>
          . RE'09 pp.
          <fpage>267</fpage>
          -
          <lpage>272</lpage>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Dermeval</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vilela</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bittencourt</surname>
            ,
            <given-names>I.I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Castro</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Isotani</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Brito</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Silva</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Applications of ontologies in requirements engineering: a systematic review of the literature</article-title>
          .
          <source>Requirements Eng</source>
          <volume>21</volume>
          ,
          <fpage>405</fpage>
          -
          <lpage>437</lpage>
          (
          <year>2015</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Gamma</surname>
          </string-name>
          , E.:
          <article-title>Design patterns. Addison-Wesley professional computing series</article-title>
          , Addison-Wesley, Boston, Mass. ; Munich [u.a.],
          <volume>36</volume>
          . print. edn. (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Guarino</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Oberle</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Staab</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          : What Is an Ontology? In: Handbook on Ontologies, pp.
          <fpage>1</fpage>
          -
          <lpage>17</lpage>
          . Springer-Verlag Berlin Heidelberg (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Happel</surname>
            ,
            <given-names>H.J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seedorf</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Applications of Ontologies in Software Engineering</article-title>
          . In: SWESE'06. pp.
          <fpage>1</fpage>
          -
          <lpage>14</lpage>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Hertel</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Broekstra</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Stuckenschmidt</surname>
          </string-name>
          , H.:
          <article-title>RDF Storage and Retrieval Systems</article-title>
          . In: Handbook on Ontologies, pp.
          <fpage>489</fpage>
          -
          <lpage>508</lpage>
          . Springer-Verlag Berlin Heidelberg (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Hitzler</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Parsia</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>Ontologies and Rules</article-title>
          . In: Handbook on Ontologies, pp.
          <fpage>111</fpage>
          -
          <lpage>132</lpage>
          . Springer-Verlag Berlin Heidelberg (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8. ISO;
          <article-title>IEC: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models (ISO</article-title>
          /IEC 25010:
          <string-name>
            <surname>2011(E))</surname>
          </string-name>
          (
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. ISO;
          <article-title>IEC; IEEE: Systems and software engineering - Life cycle processes - Requirements engineering</article-title>
          (ISO/IEC/IEEE 29148)
          <article-title>(</article-title>
          <year>2011</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Jahn</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schaaf</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Paech</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Winter</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Ein semantisches Netz des Informationsmanagements im Krankenhaus</article-title>
          .
          <source>In: Informatik</source>
          <year>2014</year>
          . vol. LNI P-
          <volume>232</volume>
          , pp.
          <fpage>1491</fpage>
          -
          <lpage>1498</lpage>
          . Gesellschaft für Informatik e.V., Stuttgart, Germany (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Kitchenham</surname>
            ,
            <given-names>B.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Charters</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Guidelines for performing systematic literature reviews in software engineering</article-title>
          .
          <source>Tech. rep., Keele Univ.; Univ. of Durham</source>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Paech</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kohler</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Task-driven requirements in object-oriented development</article-title>
          .
          <source>In: Perspectives on Softw. Requirem.</source>
          , vol.
          <volume>753</volume>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>25</lpage>
          . Kluwer Academic (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Pekar</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Felderer</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Breu</surname>
          </string-name>
          , R.:
          <article-title>Improvement methods for software requirement specifications: A mapping study</article-title>
          .
          <source>QUATIC</source>
          <year>2014</year>
          pp.
          <fpage>242</fpage>
          -
          <lpage>245</lpage>
          (
          <year>2014</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Runeson</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Höst</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <source>Guidelines for Conducting and Reporting Case Study Research in Software Engineering. Empirical Softw. Eng</source>
          .
          <volume>14</volume>
          (
          <issue>2</issue>
          ),
          <fpage>131</fpage>
          -
          <lpage>164</lpage>
          (dec
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Saavedra</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ballejos</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ale</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Quality properties evaluation for software requirements specifications: An exploratory analysis</article-title>
          .
          <source>In: WER 2013</source>
          . pp.
          <fpage>6</fpage>
          -
          <lpage>19</lpage>
          (
          <year>2013</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Wagner</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lochmann</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Heinemann</surname>
            ,
            <given-names>L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kläs</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Seidl</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Goeb</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Streit</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>The Quamoco Product Quality Modelling and Assessment Approach</article-title>
          . In: ICSE'12. pp.
          <fpage>1133</fpage>
          -
          <lpage>1142</lpage>
          . IEEE Press, Zurich, Switzerland (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>