<!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>Generation of an OWL Ontology from a Knowledge Domain Extended Lexicon</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Karla Olmos-Sánchez</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Jorge Rodas-Osollo</string-name>
          <email>jorge.rodas@uacj.mx</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
          <xref ref-type="aff" rid="aff3">3</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Universidad Autónoma de Ciudad Juárez Av. Del Charro 450 Nte. Cd. Juárez Chih. Mex</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Universidad Autónoma de Ciudad Juárez Av. Del Charro 450 Nte. Cd. Juárez Chih.</institution>
          <addr-line>Mex. (52) 656 6884841</addr-line>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Universidad Autónoma de Ciudad Juárez Av. Del Charro 450 Nte. Cd. Juárez Chih.</institution>
          <addr-line>Mex. (52) 656 6884841</addr-line>
        </aff>
        <aff id="aff3">
          <label>3</label>
          <institution>Universidad Autónoma de Ciudad Juárez Av. Del Charro 450 Nte. Cd. Juárez Chih.</institution>
          <addr-line>Mex. (52) 656 6884841 m</addr-line>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2015</year>
      </pub-date>
      <abstract>
        <p>Informally Structured Domains (ISD) are characterized by informal and unstructured information that depends on the context for interpretation; thus, the most of the concepts and their relationships are defined by consensus and domain specialists use large amounts of tacit knowledge in order to solve everyday situations. These characteristics cause that modeling this kind of domains becomes a challenging and time-consuming task in which the representations do not reflects correctly the reality. This paper proposes a new approach to the process of understanding and modeling an ISD, by using a process for generating an OWL ontology from a lexicon named KDEL with the aim of supporting a better understanding of the application domain, hence facilitates the development of products or solutions in ISD.</p>
      </abstract>
      <kwd-group>
        <kwd>eol&gt;Informally Structured Domains</kwd>
        <kwd>Ontologies Building Process</kwd>
        <kwd>Knowledge Domain Extended Lexical</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. INTRODUCTION</title>
      <p>The importance of knowledge domain in order to elicit
requirements of a solution or product that fulfill the needs and
expectative of clients and users is widely accepted among the
research community [2][12]; especially when the solution-solvers
or product developers are not immerse in the application domain.
Recently, the use of ontologies as a means to define and make
explicit this knowledge has become seen as a good option [14][6].
Domain ontologies can be used as a way of facilitating the
understanding among stakeholders, detecting of missing and
erroneous information and describing the domain in the way of
domain specialists thinking, hence avoid ambiguous, insufficient
and incomplete requirements. In this work, the term domain
specialists refers to all people involved in the application domain,
which could have partial and different knowledge of it depending
on their role and experience.</p>
      <p>
        In particular, the OWL Web Ontology Language has been designed
for use by computer systems instead of just presenting information
to humans. OWL facilitates greater machine interpretability of Web
content by providing additional vocabulary to XML, RDF and RDF
Scheme, along with a formal semantics. OWL allows us to describe
the semantics of knowledge in a machine-accessible way, therefore
it has promoted the development of multiple and varied software
applications [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>Nevertheless, ontology development is a complex and
timeconsuming activity that seems to be an art rather than a formal
method. Besides, not all domains are equal, there are domains
Yanet Garay</p>
      <p>(52) 656 6884841
sonia.magdiel.269@gm
ail.com
where not all concepts and their relationships can be formally
defined, the solutions of most of their problems are situated and
diverse, not susceptible to be described by an algorithm, and where
domain specialists use large amounts of tacit knowledge in order to
solve problems. In this kind of domains, named Informally
Structured Domains, providing certain structure that synthesizes the
knowledge of domain specialists and make it explicit is fundamental
in order to develop a correct and appropriate solution or product [9].
This structure can be proportionate by an OWL ontology.
The objective of this paper is to present a new approach to generate
an OWL ontology from the Knowledge Domain Extended Lexicon
(KDEL), in order to facilitate the understanding, development and
validation of an ISD. There is a similar approach proposed by [3],
however our work is designed keeping in mind the ISD
characteristics. Thus, our motivations is to provide a tool that
minimize the time to structure and visualize the domain knowledge,
with the further aim of facilitating to discover relationships that
could have hidden to domain specialist awareness.</p>
      <p>The rest of this paper is structured as follows: Section 2 provides a
detailed explication of KDEL, section 3 describes the OWL
ontology language, the OWL building process from KDEL is
introduced in section 4, section 5 reports the results of the
application of the method in ISD real cases, finally section 6
concludes our work with future directions.</p>
    </sec>
    <sec id="sec-2">
      <title>2. KDEL</title>
      <p>The term Universe of Discourse (UofD) generally refers to the
collection of objects being discussed in a specific domain. It is
evident that there is a correlation between the domain knowledge
and the terms used daily by domain specialists. Thus, in order to
assist to solution-solver or product developer in understanding the
terms of the domain specialists, several authors [8][13] propose the
use of a glossary of common terms with the additional aim of
facilitating communication and understanding of all involved in a
project. Despite that natural language is ambiguous and depends on
the context for interpretation, it is the only notation that is
commonly readable and understandable by the domain specialists
and its use encouraging them to participate dynamically in the first
steps of any project [7].</p>
      <p>One of these proposals is the Language Extended Lexical (LEL)
[11], which is a set of terms related to the application domain with
the aim of understanding the language of the problem without
worrying about understanding the problem. In order to give an
initial structure to the knowledge domain, each term in the UofD is
classified as object, subject, verb or state and is described by a
notion (denotation) and a behavioral response (connotation).
by understanding the problem and the structure of the solution.
Figure 1 depicts a scheme of KDEL in an UML class diagram.</p>
    </sec>
    <sec id="sec-3">
      <title>2.1 KDEL Process Building</title>
      <p>In order to deal with the challenges of ISD, the Knowledge of
Domain on an Extended Lexicon (KDEL) evolves LEL by
modifying two aspects of it. The first one is that, besides the
classification of object, subject, verb and state, it incorporates
definitions and NF-Requirements. The rationality behind this is that
in the early stage of any development software project, the domain
specialists do not have a clear idea of what they want. In ISD, even
they do not have a well-defined structure of the application domain
knowledge and a great quantity of it is tacit or implicit. Thus, the
domain specialists interleave in their discourse needs, desires,
domain properties, and current and future processes. To give a
preliminary order to this information, KDEL characterizes the
application domain in terms, which can be concepts, definitions and
Non-Functional (NF) requirements; as it is explained below:</p>
      <p>Concepts. They are equivalents to the terms in LEL and
are described by a notion (denotation) and a behavioral
response (connotation). KDEL classify the concepts as
objects, subjects or verbs. Unlike LEL, state is not
considered as a concept because we consider that it is
inherently attached to subjects or objects.</p>
      <p>Definitions. They are statements that assign a precise or
consensual meaning to terms used in the applications
domain, but that cannot be considered as concepts; thus
they cannot have a behavioral response. Definitions are
necessary in order to understand the context of the
application domain.</p>
      <p>NF Requirements. They refer to concerns not related to
the functionality of the software, such as usability,
flexibility, performance, interoperability and security [5].
One of the objectives of the KDEL is to capture the
NFRequirements introduced in the early discourses of
domain specialists; however, in subsequent stages of the
process, solution-solvers of product developers can
include more of them.</p>
      <p>The second aspect that KDEL modifies is the internal structure of
terms. The application domain will be affected after a solution or
product was deployed in it; hence, the set of terms, as well as its
denotation and connotation, will not be the same. To handle this
issue, a future behavioral response is added to the structure of them,
which is not mandatory; it is only added if it is evident in the early
stages of the project. It allows the requirements engineers to gain
more domain knowledge and explore new possibilities of solution
Handling synonymous is a special issue of any representation of
language. Two or more terms are synonymous if they share the
meaning of a concept. In KDEL, when two or more terms are
synonymous they share the same structure and the two terms are
separated by a diagonal slash.</p>
      <p>Based on the rules to describe terms proposed in [7], a set of
suggestions for description of terms have been proposed for KDEL.
Table 1 gives the rules of description for objects, Table 2 for
subjects, Table 3 for verbs, Table 4 for definitions and Table 5 for
NF-requirements.</p>
      <p>Subject
Besides the rules describes allow, in order to build KDEL the
following task are also necessary:</p>
      <p>Apply techniques of discourse analysis to identify
syntactic constructions that could hide tacit knowledge.
Record, for each term in KDEL, questions or comments
that will be consulted to domain specialists.
The evaluator is a certified neuro
psychologist in the cognitive diagnostic and
rehabilitation of multiple sclerosis patients.
- The evaluator applies the neuro
psychological battery of test for cognitive
diagnostic to multiple sclerosis patients.
- The evaluator proposes the rehabilitations
cognitive training based on the result of the
evaluation.
- The evaluator indicates to patients when
the next test will be applied.</p>
      <p>The concept of evaluator disappears in the
future system; their functionalities will be
carried out by the software system.</p>
    </sec>
    <sec id="sec-4">
      <title>2.2 Limitations of KDEL</title>
      <p>KDEL facilitates to solution-solver or product developers to be
familiar with the language of domain specialist; hence it minimizes
the difficulties involved by describing the domain using a
semiformal or formal method. However, there are some drawbacks such
as the redundancy in the description of terms, which causes a
validation time-rise. In addition, it must be considered the hard and
time-consuming activity of using KDEL to build a graphical
conceptual model, which will be used by solution-solvers or
product developers in two different ways: to facilitate the validation
of the structure of domain and to let bring to light relationships that
were hide to domain specialists.</p>
    </sec>
    <sec id="sec-5">
      <title>3. OWL ONTOLOGIES</title>
      <p>An ontology is an explicit formal specification of how to represent
the entities and relationships that exist in a domain. They describe
the properties of a domain and reasoning about it [4]. Ontologies
have also been used to capture and synthesize knowledge from
diverse domain specialists, especially when their knowledge
depends on their own interests and points of view [6]. Thus, several
authors have raised the use of ontologies to formalize the
application domain.</p>
    </sec>
    <sec id="sec-6">
      <title>3.1 OWL Structure</title>
      <p>
        OWL is a widely used proposal of formal languages for ontologies
[
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] , which is defined using the syntax of RDF/XML. The elements
of an OWL ontology concern classes, properties, instances of
classes, and relationships between these instances. This section
presents the essential components of this language in order to
introduce those elements.
1) Classes are concrete representations of concepts; OWL classes
are interpreted as a set of individual objects with similar features.
The RDF/XML syntax to represent OWL classes is:
&lt;owl:Class rdf:ID="Class_X"/&gt;
&lt;owl:Class rdf:ID="Class_Y"/&gt;
The taxonomic constructor for classes is rdfs:subClassOf. It
relates a more specific class to a more general class. If X is a
subclass of Y, then every instance of X is also an instance of Y.
&lt;owl:Class rdf:ID="Class_X"&gt;
&lt;rdfs:subClassOf
rdf:resource="#Class_Y"/&gt;
...
&lt;/owl:Class&gt;
      </p>
      <p>2) Individuals represent objects in the domain of discourse;
they can be referred to as being instances of classes. The RDF/XML
syntax to represent OWL individuals where Individual_X is a
member of Class X is:
&lt;owl:Thing rdf:ID="Class_X" /&gt;
&lt;owl:Thing rdf:about="#Class_X"&gt;</p>
      <p>&lt;rdf:type rdf:resource="#Individual_X"/&gt;
&lt;/owl:Thing&gt;
3) Properties are also known as roles in description logic or
relations in UML and other object oriented notations. In brief, they
represent relationships. There are a number of ways to restrict the
relation defined by a property: the domain and range can be
specified and the property can be defined to be a specialization
(subproperty) of an existing property [36]. There are two main
types of properties: object properties and datatype properties.
Object properties are relationships between two individuals. In the
next example X has a link with Y.
&lt;owl:ObjectProperty rdf:ID="</p>
      <p>hasALinkWith"&gt;
&lt;rdfs:domain rdf:resource="#X"/&gt;
&lt;rdfs:range rdf:resource="#Y"/&gt;
&lt;/owl:ObjectProperty&gt;
Datatype properties describe relationships between an individual
and data values. In the next example a Person_X has age and it is a
positive integer.
&lt;owl:DatatypeProperty rdf:ID="hasAge"&gt;
&lt;rdfs:domain rdf:resource="#Person_X" /&gt;
&lt;rdfs:range
rdf:resource="&amp;xsd;positiveInteger"/&gt;
&lt;/owl:DatatypeProperty&gt;</p>
    </sec>
    <sec id="sec-7">
      <title>4. FROM KDEL TO AN OWL ONTOLOGY</title>
      <p>As was mentioned above, KDEL is a glossary of interrelated terms.
They are classified as object, subject or verb and have a description.
In particular, objects and subjects represent an entity in the domain
and have relationships with other terms, which are described in the
current behavioral. Thus, there is a correlation of them with OWL
classes. Likewise, the relationships between concepts are
equivalent with OWL properties.</p>
      <p>A set of heuristics, rules or methods that helps to solve problems
faster than it would if all the computing were done, have been
proposed in order to facilitate the conversion of KDEL to OWL,
which are listed follows:
1)
2)
3)
4)
5)
6)
1)
2)
3)
4)
5)
6)</p>
      <p>Each subject or object of KDEL becomes an OWL class.
For each KDEL construction with the structure X is
synonym of Y/Z the following OWL properties are
created:</p>
      <p>X Is_Synonym of Y and</p>
      <p>X Is_Synonym of Z.</p>
      <p>Descriptions of the terms (notion, current and future
behavior) become OWL comments.</p>
      <p>Relationships in KDEL with the syntactic structure Term
+ verb phrase + term are turned into OWL properties.
Definitions in KDEL are converted into OWL classes.
NF-Requirements are currently not part of the ontology;
their handling is considered to be future work.</p>
    </sec>
    <sec id="sec-8">
      <title>4.1 OWL Ontology Building Process</title>
      <p>In order to build an OWL ontology from a KDEL lexicon, the
following process is proposed. The process works together with the
heuristics proposed above.
Perform a pre-processing of KDEL based in the rules of
description (Section 2.1).</p>
      <p>Convert KDEL terms into OWL classes (Heuristics 1, 3,
5).</p>
      <p>Convert KDEL relationships into OWL properties
(Heuristic 4).</p>
      <p>Convert KDEL synonymous into OWL classes by creating
the OWL property between them: Is_Synonym_of
(Heuristic 2).</p>
      <p>Create an OWL file following the format of RDF/XML
by integrating classes, properties and individuals, as
identified in the previous steps.</p>
      <p>Name the file created in the last step with the name
selected for the OWL ontology including the file
extension for OWL.</p>
    </sec>
    <sec id="sec-9">
      <title>4.2 Software Tool</title>
      <p>The solution-solvers or product developers must learn the domain
terms in a short period of time in order to reduce the symmetry of
ignorance, improve the cognitive dialogue and find, with the
domain specialists, the set of solution or product requirements.
However, in Informally Structured Domains, the universe of
discourse is frequently too large and specialized. In addition, the
process of validation of the terms is generally a boring and stressful
task. Thus, a software system has been developed to support the
handle of KDEL with the aims to facilitate the building,
maintenance and validation of the KDEL. The system is designed
to be used by the design team and it is able to manage several
projects. The terms of KDEL are recorded in a relational database,
following the structure showed in Figure 1.</p>
      <p>This database is the input of another software system that executes
the OWL ontology building process described in the previous
section. The software also has the functionality of represent in a
graphical format the RDF/XML file. Thus, it allows the
visualization of KDEL with the aim of facilitating the validation
process by domain specialists. In addition, if domain specialists
realize that the description of a term must be improved, the software
allows this change and automatically reconstructs the KDEL and
the OWL file.</p>
      <p>Figure 3 depicts a screen with the graphical representation of
KDEL of the domain of cognitive diagnosis for multiple sclerosis
patients. This project was developed for a Mexican real
organization; thus the KDEL was developed in Spanish. However,
it is not our intention to give a detail description of the lexical, but
demonstrate the utility of the software tool in order to facilitate the
validation of the domain terms and their relationships. The
visualization also allows domain specialists to discover
relationships that were hidden to them. Therefore, the software
system is also appropriate for discovery knowledge issues.</p>
    </sec>
    <sec id="sec-10">
      <title>5. APPLICATION IN ISD REAL CASES</title>
      <p>Our proposal has been applied to generate OWL ontologies as a
part of the process for diverse solution in ISD real cases, which are
listed below:</p>
      <p>Software Development of a Cognitive Rehabilitation
System for Sclerosis Multiple Patients [10].</p>
      <p>Case-based Reasoning System to Support Heating
Ventilation and Air Conditioning (HVAC) Design
Decisions.</p>
      <p>Method to develop Bayesian Networks for evaluation in
Intelligent Tutoring System for complex domains.</p>
      <p>Analysis of the requirements elicitation process of a
HVAC company.</p>
      <p>The generation of the ontology in each project allowed the
extraction of relevant information from KDEL, which led to a view
of the information in a synthesized way. This process also
facilitated the correction of the following errors committed in
KDEL: 1) repeated information, 2) ideas vaguely described, 3)
ideas mixed or unfinished and 4) typing errors. In summary, the
OWL ontology building process improves KDEL, which facilitates
the validation of it. In addition, the automatic generation of the
OWL ontology significantly shortens the time and effort required
to generate a graphical representation of the domain and contributes
to the understanding of the ISD.</p>
    </sec>
    <sec id="sec-11">
      <title>6. CONCLUSIONS AND FUTURE WORK</title>
      <p>The application of KDEL and the generation of an OWL ontology
from it in order to provide certain structure and facilitate the
understanding of the domain to the solution-solvers or product
developers in ISD real cases showed that the process minimizes the
time of understanding the domain. It also minimizes the time it
would take the domain specialists to validate the domain structure
due to the graphical domain visualization. Finally, the graphical
domain visualization also facilitates the discovery or relationships
that were hidden to the domain specialist; allowing the detection
and correction of errors in KDEL.</p>
      <p>As future work it is necessary to apply the process in others ISD
real cases in order to verify their effectiveness and improved it, if
necessary.</p>
    </sec>
    <sec id="sec-12">
      <title>7. ACKNOWLEDGMENTS</title>
      <p>Our thanks to the Unity for Health Research UIS for its acronym in
Spanish (Unidad de Investigación en Salud) for allowing us to work
with them in the development of the rehabilitation system for
multiple sclerosis patients.
Shivani Goel. 2012. Transformation from LEL to UML.
International Journal of Computer Applications 48, 12:
975–888.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>Dean</given-names>
            <surname>Allemang</surname>
          </string-name>
          and
          <string-name>
            <given-names>James</given-names>
            <surname>Hendler</surname>
          </string-name>
          .
          <year>2008</year>
          .
          <article-title>Semantic Web for the Working Ontologist: Effective Modeling in RDFS and OWL</article-title>
          . Morgan Kaufmann Publishers Inc.
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          <string-name>
            <given-names>Dines</given-names>
            <surname>Bjørner</surname>
          </string-name>
          .
          <year>2010</year>
          .
          <article-title>Rôle of domain engineering in software development : Why current requirements engineering is flawed</article-title>
          .
          <source>In Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)</source>
          ,
          <fpage>2</fpage>
          -
          <lpage>34</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          http://doi.org/10.1007/978-3-
          <fpage>642</fpage>
          -11486-
          <issue>1</issue>
          _
          <article-title>2 Karen Koogan Breitman and Julio Cesar Sampaio do Prado Leite</article-title>
          .
          <year>2003</year>
          .
          <article-title>Ontology as a requirements engineering product</article-title>
          .
          <source>In Proceedings of the 11th IEEE International Requirements Engineering Conference</source>
          ,
          <year>2003</year>
          ,
          <fpage>309</fpage>
          -
          <lpage>319</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          <string-name>
            <given-names>Verónica</given-names>
            <surname>Castañeda</surname>
          </string-name>
          , Luciana Ballejos, Ma. Laura Caliusco, and Ma. Rosa Galli.
          <year>2010</year>
          .
          <article-title>The Use of Ontologies in Requirements Engineering</article-title>
          .
          <source>Global Journal of Research In Engineering 10</source>
          ,
          <fpage>6</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          <source>Luiz Marcio Cysneiros and Julio Cesar Sampaio do Prado Leite</source>
          .
          <year>2004</year>
          .
          <article-title>Nonfunctional requirements: From elicitation to conceptual models</article-title>
          .
          <source>IEEE Transactions on Software Engineering</source>
          <volume>30</volume>
          ,
          <issue>5</issue>
          :
          <fpage>328</fpage>
          -
          <lpage>350</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <string-name>
            <given-names>Julio</given-names>
            <surname>Cesar Sampario do Leite</surname>
          </string-name>
          ,
          <string-name>
            <surname>Ana P M Franco</surname>
          </string-name>
          , and others.
          <year>1993</year>
          .
          <article-title>A strategy for conceptual model acquisition</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          <source>In Proceedings of IEEE International Symposium on Requirements Engineering</source>
          <year>1993</year>
          ,
          <fpage>243</fpage>
          -
          <lpage>246</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          <string-name>
            <given-names>Karla</given-names>
            <surname>Olmos</surname>
          </string-name>
          and
          <string-name>
            <given-names>Jorge</given-names>
            <surname>Rodas</surname>
          </string-name>
          .
          <year>2013</year>
          .
          <article-title>Requirements engineering process model for informal structural domains</article-title>
          .
          <source>International Journal of Computer and Communication Engineering</source>
          <volume>2</volume>
          ,
          <issue>1</issue>
          :
          <fpage>75</fpage>
          -
          <lpage>77</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          <string-name>
            <given-names>Karla</given-names>
            <surname>Olmos</surname>
          </string-name>
          and
          <string-name>
            <given-names>Jorge</given-names>
            <surname>Rodas</surname>
          </string-name>
          .
          <year>2014</year>
          .
          <article-title>KMoS-RE Knowledge Management on a Strategy to Requirements Engineering</article-title>
          . Special Issue on Requirements Engineering in Software Product Line Engineering, Requirements
          <source>Engineering Journal</source>
          <volume>19</volume>
          ,
          <issue>4</issue>
          :
          <fpage>421</fpage>
          -
          <lpage>440</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          <string-name>
            <given-names>Julio</given-names>
            <surname>Cesar Sampaio do Prado Leite</surname>
          </string-name>
          , Jorge Horacio Doorn,
          <string-name>
            <surname>Graciela D S Hadad</surname>
          </string-name>
          , and
          <string-name>
            <surname>Gladys N Kaplan</surname>
          </string-name>
          .
          <year>2005</year>
          .
          <article-title>Scenario inspections</article-title>
          .
          <source>Requirements Engineering</source>
          <volume>10</volume>
          ,
          <issue>1</issue>
          :
          <fpage>1</fpage>
          -
          <lpage>21</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          <string-name>
            <surname>Pedro O Rossel</surname>
            , María Cecilia Bastarrica, Nancy Hitschfeld-Kahler,
            <given-names>Violeta</given-names>
          </string-name>
          <string-name>
            <surname>Díaz</surname>
            , and
            <given-names>Mario</given-names>
          </string-name>
          <string-name>
            <surname>Medina</surname>
          </string-name>
          .
          <year>2014</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          <article-title>Domain modeling as a basis for building a meshing tool software product line</article-title>
          .
          <source>ADVANCES IN ENGINEERING SOFTWARE</source>
          <volume>70</volume>
          :
          <fpage>77</fpage>
          -
          <lpage>89</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          http://doi.org/10.1016/j.advengsoft.
          <year>2014</year>
          .
          <volume>01</volume>
          .011
          <string-name>
            <given-names>Matt</given-names>
            <surname>Selway</surname>
          </string-name>
          , Wolfgang Mayer, and Markus Stumptner.
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          2014.
          <article-title>Semantic interpretation of requirements through cognitive grammar and configuration</article-title>
          .
          <source>Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)</source>
          <volume>8862</volume>
          :
          <fpage>496</fpage>
          -
          <lpage>510</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          http://doi.org/10.1007/978-3-
          <fpage>319</fpage>
          -13560-1
          <string-name>
            <given-names>Katja</given-names>
            <surname>Siegemund</surname>
          </string-name>
          , Edward J Thomas,
          <string-name>
            <given-names>Yuting</given-names>
            <surname>Zhao</surname>
          </string-name>
          ,
          <string-name>
            <given-names>Jeff</given-names>
            <surname>Pan</surname>
          </string-name>
          , and
          <string-name>
            <given-names>Uwe</given-names>
            <surname>Assmann</surname>
          </string-name>
          .
          <year>2011</year>
          .
          <article-title>Towards ontology-driven requirements engineering</article-title>
          .
          <source>In Proceedings of the Workshop Semantic Web Enabled Software Engineering at 10th International Semantic Web Conference (ISWC)</source>
          ,
          <year>Bonn</year>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>