An Ontology-based Framework for Modelling Security
Joaquín Lasheras, Rafael Valencia-García
Jesualdo Tomás Fernández-Breis and Ambrosio Toval
Department of Informatics and Systems. University of Murcia
30071 Campus de Espinardo, Murcia, Spain
Abstract. In the last years, security in Information Systems (IS) has become an
important issue, so that it has to be taken into account in all the stages of IS
development, including the early phase of Requirements Engineering (RE). One
of the most helpful RE strategies for improving the productivity and quality of
software process and products is the reuse of requirements, and this can be
facilitated by Semantic Web technologies. In this work, we describe a novel
ontology-based framework for representing and reusing security requirements
based on risk analysis. A risk analysis ontology and a requirement ontology
have been developed and combined to represent formally reusable security
requirements and improve security in IS, detecting incompleteness and
inconsistency in requirements and achieving semantic processing in
requirements analysis. These ontologies have been developed according to a
formal method to build and compare ontologies and with a standard language,
OWL. This framework will be the basis to elaborate a “lightweight” method to
elicit security requirements.
1 Introduction
Information confidentiality, security or privacy, issues of interest for Information
System designers, are nowadays critical and vital issues for the society [1]. Hence,
security has to be taken into account in all the stages of the software development
process [2]. These include the early phases related to Requirements Engineering (RE)
[3], where, security has been identified as a research hotspot [4].
Security requirements include the types and levels of protection necessary for
equipment, data, information, applications, and facilities to meet security policy.
Specifically, security requirements are identified by risk analysis -the systematic use
of information to identify sources and to estimate the risk” [5]. Risk analysis is one of
the three sources identified by the security standard ISO 27002 – “Code of Practice
for Information Security Management” [5] – to identify security requirements. The
others two sources are related to legal, regulatory and contractual requirements of an
organization and with the principles, objectives and business requirements for
information processing that an organization have developed to support its operations.
In this context, reuse comes out as an important factor to achieve efficient
requirements management. There is a consensus [6] on the many benefits of reuse,
becoming more important as the abstraction level augments; not only code, but also
Lasheras J., Valencia-García R., Tomás Fernández-Breis J. and Toval A. (2008).
An Ontology-based Framework for Modelling Security Requirements.
In Proceedings of the 6th International Workshop on Security in Information Systems, pages 78-88
DOI: 10.5220/0001743400780088
designs and specifications, are reused [7]. So, methods and technologies for
facilitating requirements reuse are needed, including security requirements [8].
The Semantic Web community has experience in the design and development of
reusable components. Ontologies are its backbone technology [9] and have become
widely used due to their advantages (reusability and shareability) [10]. An ontology
represents a common, reusable and sharable - since it captures knowledge which has
the consensus of the community [11]- view of a particular application domain. The
benefits of using the ontological technology in terms of information systems’ security
is stated in [12] according to three main properties: (1) the ontology organizes and
makes it systematic any phenomenon at any detail level and reduces the diversity of
items to a properties list; (2) many approaches take advantage of the modularity it
induces, for instance, to establish relations among measurements to detect some
properties; and (3) an ontological approach provides mechanisms to forecast security
problems. Several authors [13, 14] consider the definition of a security ontology a
challenge within the community of security engineering.
In this work an ontology-based framework for representing, storing and reusing
security requirements is presented. This framework is based on risk analysis,
permitting a formal representation (intelligible by a machine) of the requirements,
their metainformation, their relationships and the constraints, axioms and rules
derived of their use (semantic relationships). This framework combines a risk
analysis ontology, based on methods of risk analysis and security standards, and a
requirements ontology (based on our RE method SIREN [15] ).
This paper has been structured as follows: Section 2 presents the ontology-based
framework for modelling security requirements. First the risk analysis ontology
(Section 2.1) and the requirements ontology (Section 2.2) are described, and then its
combination (Section 2.3) and its application (Section 2.4) are showed. Section 3
presents related work and, finally, Section 4 shows the conclusions and further work.
2 Ontology-based Framework for Modelling Security
Requirements in Risk Analysis
In this framework, knowledge is represented through ontologies. In this work, the
ontologies have been implemented by using the Ontology Web Language (OWL),
which is the current W3C recommendation for exchanging semantic content on the
Web. OWL has different flavors, being OWL-DL the chosen one since it has the
expressivity needed and allows for complete reasoning. Our framework for modelling
security requirements is based on two ontologies: the risk analysis ontology (Section
2.1) and the requirements ontology (Section 2.2). The first one conceptualizes the risk
analysis domain including concepts such as assets, or threats, and is based on risk
analysis methods and standards of security. On the other hand, the requirements
ontology models reusable requirements, with their metainformation and relationships.
In Section 2.3, the combination of both ontologies is showed, which will permit to
specify security requirements with all its metainformation, relationship and semantic
properties (constraints, axioms and rules). In Section 2.4, the application of the
framework is presented.
2.1 Risk Analysis Ontology
The risk analysis ontology is based on MAGERIT [16], the information systems risk
analysis and management method of the Spanish public administration. It conforms to
the ISO/IEC 15408-1999 [17] and is based in international and national legal
regulations, which are relevant in the analysis and management of risk: administrative
procedure, protection data, electronic signature, classified information and network
and information security (see appendix 3 MAGERIT [16] for details).
MAGERIT defines a document with the elements that must appear in a risk
analysis project. This document, named “catalogue of elements”, has two purposes in
a risk analysis and management project [16]:
To offer a standard item for quick consultation, centred on the specifics of the
system being analysed, to facilitate the work of the people involved in the project.
To provide uniform results of the analysis, promoting terminology and criteria that
allow to compare and even integrate the analyses made by different teams.
In MAGERIT, the relationships between the elements are explained by means of
tables and natural language text. In this work, this information has been formalized in
an ontology (see Fig. 1 for a partial representation of its structure). The current
version of this ontology is available in
Fig. 1. Taxonomy and axioms of the elements of the risk analysis ontology in the Protégé
This ontology identifies five groups of elements:
Asset: anything that provides value to the organization. It is classified within a
hierarchy of types of assets.
Valuation dimension: the features or attributes that make an asset valuable. It is
the measurement of the loss caused by damages in an asset in a certain
dimension: availability, integrity, confidentiality, authenticity and accountability.
Threat: the possible threats to the assets in an information system.
Safeguard: the safeguards that allow threats to be faced.
The risk analysis ontology contains relations, constraints, axioms and rules. For
example, there is a binary relationship between the assets and the threats to represent
which threat can affect to which asset. The semantics of this generic relation is
completed at each concept (of the assets and threats taxonomies) by adding the
corresponding range and domain constraints in OWL (see Fig. 1). For example,
software (asset) cannot be affected by natural disasters (threat), and the errors and
unintentional failures (threat) affect to the software (asset) but not to the personnel
(asset). Moreover, other constraints such as disjointness or cardinality can also be
defined in OWL and have been very useful for the construction of this ontology (and
the followings described above). However, not every type of rule can be directly
formalized in OWL. In this case, rules languages, such as the Semantic Web Rule
Language (SWRL), play an important role in combination with semantic reasoners.
2.2 Requirements Ontology
The concepts, metainformation and relationships included in the requirements
ontology have been mostly taken from our experience in the context of requirements
reuse, specifically in the reuse-based RE method called SIREN [15, 18]. SIREN could
be considered both a document-based and a repository-based approach since it builds
upon a reusable requirements repository organized by catalogs based on RE
standards, specifically IEEE [19, 20]. To date, these requirements are represented
textually (organized in the IEEE documents [19, 20]), with their metainformation
associated to them. Fig. 2 shows a part of the taxonomy of the requirements ontology.
There, requirements are classified according to the IEEE documents standards. Next,
the main metainformation elements (attributes) identified for each requirement, and
their OWL modelling, are described:
Requirements are characterized by a unique identifier
and a textual
description. Both have been defined in OWL as Datatype properties.
: this value must be established by the analyst and shows the order of
development Datatype property {“high”, “medium”, “low”}
why the requirements are considered. Datatype property.
9 states are possible for a requirement. Datatype property {To be
Determined, Determined, To be Revised, To Rule out, Approved, Modelled in
Analysis, Modelled in Design, Implemented or Verify}
: in a requirements document the requirements can appear related to
each other by means of traces. The traceability model includes three types of
relationships: inclusive relationships, parent-children relationships and exclusive
relationships which have been modelled using the following Object properties:
: the inclusive traceability relationships are defined between two
requirements A and B, which means that to satisfy A, B also needs to be
satisfied and, therefore, the reuse of A will imply the reuse of B. This is a
dependence relation and satisfies a set of properties (reflexivity, asymmetry
and transitivity). This relationship has been modeled in OWL using 2 inverse
object properties (trace_to and trace_from), being both transitive.
-Child: They are relationships through which the children
requirements refine the meaning of the parent ones. This relation has been
modeled as the previous relationship.
: the exclusive traceability relationships mean that the
requirements implied are mutually exclusive. This relationship is directly
related to reuse since it indicates those requirements that cannot be selected
from the repository for the same project. This relation has been modeled by
an Object property with the symmetry property of OWL.
Fig. 2. Requirements Taxonomy (an extract).
Source: It is the source of the requirement. Although the client needs are the
main source, others requirements could be derived from the technical solution,
current legislation or standards (i.e., security standards). References, URL, the
name of standards or even the source catalog, if the requirement has been reused,
must be collected. Datatype property.
Verification Method
: This is the method used to verify that the requirement is
satisfied in the final product. Datatype property {“inspection”, “analysis”,
“demonstration”, "test”}
: The document section in which the requirement is situated, if any.
Datatype property.
2.3 Combining Ontologies: The Security Requirements Ontology
As described in the introduction, this work is focused on security requirements
identified by risk analysis, which is one source to elicit security requirements.
identified by the security standard ISO 27002 [5]: “One source is derived from
assessing risks to the organization, taking into account the organization’s overall
business strategy and objectives. Through a risk assessment, threats to assets are
identified …”. These requirements, which meet security policy, can be functional or
non-functional (software or system requirements), supporting some security issues in
the system. Consequently, the requirements ontology described in section above 2.2
has been used to classify the security requirements (Fig.2), extending it with concepts
from the risk analysis ontology (Section 2.1). Then, the metainformation related to
risk analysis (such as assets or threats) and the constraint, axioms and rules that help
to maintain consistency in the security requirements have been modelled.
Although the main basis to identify this new metainformation has been MAGERIT
(Section 2.1), other instructions from the family of security standards ISO 27000,
specifically by the ISO 27002 [5], have been considered, so the results could be
adapted and certified under these standards in the future.
The new properties, and their OWL modelling, are described next:
: Every security requirement has to be related to one asset. So, an
Object property has been added to the concept security requirement to represent
its asset associated. The range of the Object property is the class Asset defined in
the risk analysis ontology. This Object property is inherited and restricted along
the hierarchy. For example a physical system requirement can only be associated
to hardware assets. Furthermore storing the owner, the person and the unit
responsible for the asset are relevant. This information is an objective in ISO
27002 (Section 7 - Asset Management).
It represents possible threats associated to the non-fulfilment of the
requirements. The risk analysis ontology has constraints of which threat can be
occurred to which asset, so the system can infer if a threat associated to a
requirement can be inconsistent with the asset associated to this requirement. For
example the user cannot relate a physical system requirement (which has as asset
hardware system”) to the threat “repudiation”, associated to the asset of
Services”. This property is represented by an Object property over the hierarchy
of threats of the risk analysis ontology. In [16] are described the different kind of
threats. Furthermore, information about the effect of the threat, about its
probability of occurrence and previous record must be stored.
The purpose is to provide relative values of the assets in their
various valuation dimensions. It is a number Datatype property (1-10) that values
the importance of the requirement for the system. MAGERIT describes such
possible values [16]. Besides, the Datatype property
rationale_of_valuation_criteria” includes the rationale for selecting this value.
the features that make an asset valuable. There exist
five valuation dimensions modelled using an Object property: "Availability",
"Integrity", "Confidentiality", “Accountability” and “Authenticity”.
This Object property associates to the safeguard its related
requirement. Information about the efficacy to confront a threat and its state of
implantation must be stored.
With this combination, the Source
of the requirement becomes essential. It
specifies the current legislation or security standards a requirement has been derived
from. This is useful for the application of the framework shown in the next section.
2.4 Application of the Framework
In Security Information, a basic (baseline) protection must be implemented in all
systems except for particular situations. This type of reasoning is frequently applied
and leads to the deployment of a minimum of “purely common sense” safeguards
[16]. There are numerous sources to identify these safeguards, including international
standards (such as ISO 27002 [5] or CCF [17]), national standards or regulations
(such as protection data laws), and sector standards.
In that way, our framework can be used as a source to specify a baseline
protection, by using the security requirements ontology and the properties that it
models. This ontology represents a “catalog” of security requirements that can be a
useful starting point for further refinement in the system. Furthermore, protection by
catalog can be refined somewhat by considering the value of the assets or quantifying
the threats [16]. This is achieved thanks to all the properties, relationships and
semantic properties, of the ontologies, permitting to elicit and specify requirements,
for instance, by assets or by probably threats to the system.
On the other hand, our framework covers a very wide spectrum of interests,
accounting for all types of situations in security. In practice, the user may face
situations in which the analysis is more restricted, for instance, files affected by
legislation regarding personal data or communications security. In this case, the
metainformation related to the requirement through the “attribute” source must be
considered as a layer to search and identify requirements.
The advantages of protection by catalogue are quickness, need for little effort (once
the catalogue has been developed), and standardization, providing uniform results with
other similar organisations. An additional advantage of using this framework is the
possibility of identifying the measurement of percentage of satisfied requirements. In
[21], a catalog of reusable requirements related to Personal Data Protection was applied
to the process of auditing a case study in a Health Information System. Here, the % of
the satisfied requirements from the catalog was presented as a measurement of security.
Application to a Reusable Requirements Repository. In previous work [18], a
reusable requirements catalog related to security with about 350 requirements (with
their metainformation and traceability relationships) was defined. This new
framework allows for verifying the consistency of the associated metainformation,
using the properties - constraint, axioms and rules - identified in Section 2.3
(has_asset, has_threats …). For example, some inconsistencies were identified by the
proper instantiation process, such as checking that the traceability of the requirements
is free of cycles, that a requirement associated to a determined asset has to be related
to a possible threat, or that a safeguard is applicable to this asset. Specifically 27
inconsistencies have been detected: 8 were related to the traceability of the
requirements, and 19 were identified by constraint of risk analysis. In table 1, some
details about the ontologies are showed.
Table 1. Ontology details.
Risk analysis ontology Security Requirements ontology
Classes 266 46
Individuals 280 350
Number of datatype properties 6 21
Number of object properties 6 9
Restrictions 140 52
Disjoint Axioms 30 15
An Example of Security Requirement. Let us suppose that the requirement to model
is a high-level one (closed to the stakeholders and the problem-realm), and it is
defined in natural language:
The installations will be built earthquake-proof”
First, the taxonomic category of the requirement has to be identified. This
requirement has to be inserted into the class "System requirement- Physical -
Construction" (Fig. 2). Each property of this new individual has to be filled in (Fig.
3). The system allows for associating the requirement only with instances of the asset
"Installations", due to the constraints defined in the ontology. Besides, due to the
asset of this requirement (“Installation”), the user cannot relate to it any threat of the
hierarchies (Fig. 1) associated to "Wilful attacks" (deliberate failures caused by
people) or “Error and unintentional failure” (unintentional failures caused by people).
Fig. 3. Properties of the requirement, an extract.
The source attribute allows for identifying that this requirement is associated to the
ISO 27002 control objective - 9.1.4 Protecting against external and environmental
threats. However, this requirement has not a direct correspondence to requirements
extracted by Protection Data Laws. Nevertheless, thanks to the relationships of
traceability between requirements, and the relation between threats-assets-
requirements, it has been detected that, if data regulated by protection laws is stored
in these installations, then the requirement must be considered.
3 Related Work
Several authors consider the definition of security ontology an important investigation
area and a challenge within the community of security engineering [13, 14]. In our
previous works, a systematic review and comparison (based on the formal method
[22]) of Security Ontologies was made [23], which has been the basis for identifying
the contribution of this work.
In security, ontologies concerning dependability domain [24], trust domain [25]
and to other functional issues about security (algorithms Security or Policy security)
[26] have been used to provide an unified conceptualization, but none of them are
associated to risk analysis. In [13] the authors present an ontology of risk analysis
based on standards used in a security management framework for information
systems, and in [27] is centred in small and medium companies. Nevertheless, none of
them has integrated it with RE techniques in order to take care of their benefits and
the used of reuse requirements catalogs. [28] proposes a methodology to elicit and
certify security requirements, although it is particularly adapted to the Department of
Defense, Information Technology Security Certification and Accreditation Process
(DITSCAP). The ontology proposed there is not related to RE techniques, and
catalogs of requirements are not used nor semantics is managed.
has_asset: Installations
Owner: the company
Responsible for: the building of the company
has_valuation_dimensions: availability
valuation_criteria: 7
Rationale: is likely to cause damage to the operational effectiveness or security of the Operations
/ Logistics mission
has_threats: Natural Disaster
Probability of occurrence: probability of earthquake in the city of the company.
Previous record: information about this threat in other branches of the company.
has_safeguards: Certification
State of implantation: we get a certification that the installations are earthquake-proof
Efficacy to confront a threat: % of buildings certified that have recovered from the threat.
Consequently, although several related work has been identified, none of them
combines the use of method of RE, reuse, ontologies and pre-existing catalogs, as the
basis of a “lightweight” method to elicit security requirements following security
standards, as the ISO 27002 [5], with the aim that the results obtain could be adapted
and certified in future under these standards. Besides, none of them have followed a
formal method to the development of the ontologies.
4 Conclusions and Further Work
This work, proposes an ontological representation for reusable requirements, which
allows for detecting incompleteness and inconsistency in requirements and achieving
semantic processing in requirements analysis without rigorous NLP (Natural
Language Processing) techniques. The ontologies have been developed according to a
formal method to build and compare ontologies [22] and implemented in a standard
language, OWL. Besides, their definition is based on requirements [19, 20] and
security standards and regulations [5, 16]. So the results obtained could be adapted
and certified in future under these standards.
This framework will be the basis to elaborate a “lightweight” method to elicit
security requirements which permits us to reduce significantly the impact of risks
without making large investment in software, by arranging the management of the
security. We permit users or developers (without being security experts) to identify
security requirements through reuse, with the advantages of using a method based on
“catalogs” (see Section 2.4). A measurement of security is also offered by identifying
the % of satisfied requirements with respect to standards or regulation.
Furthermore, thanks to the property of shareability and reuse of the ontologies, the
community can benefit from having a shared set of reusable security requirements.
Besides, the framework could be extended with other ontologies related to security.
Work in progress is focused on such issue, considering the ontologies identified [23].
In that way, we are also planning to extend the risk analysis top level ontology using
others wide-accepted standards, such as the family ISO/IEC 27000, the CCTA Risk
Analysis and Management Method (CRAMM) or OCTAVE (Operationally Critical
Threat, Asset and Vulnerability Evaluation by the Carnegie-Mellon). These methods
are used once the architectural design has been defined, allowing only an ”a
posteriori” approach of IT security, resulting in a gap between security requirements
and business security needs. On the other hand, as further work, our ontologies might
be used to perform semantic searches by using Semantic Web oriented languages
such as SPARQL, and we expect to improve the selection of the requirements with
the use expert system to prioritize the requirements.
This work has been partially financed by the Spanish Ministry of Science and
Technology, projects TIC2006-15175-C05-03 and TSI2007-66575-C02-02, by the
Government of Murcia under project TIC-INF 06/01-0002; by the Junta de Castilla-
La Mancha (Spain), project PBC-05-012-3, and by the FEDER and the Junta de
Castilla-La Mancha (Spain), project PBC-05-012-1.
1. Smith, S.W.Spafford, E.H., Grand Challenges in Information Security: Process and
Output. IEEE Security & Privacy, 2(1): (2004). p. 69-71.
2. Devanbu, P.Stubblebine, S., Software engineering for security: a roadmap. ACM Press.
Future of Software Engineering: (2000). p. 227-239.
3. Jürjens, J., Secure Systems Development with UML: Springer (2005).
4. Cheng, B.Atlee, M. Research Directions in Requirements Engineering. in Future of
Software Engineering 2007 (FOSE 2007) Minneapolis, Minnesota (2007).
5. ISO27002, ISO/IEC 17799-27002 Code of Practice for Information Security Managament.
6. Rothenberger, M.A., Dooley, K.J., Kulkarni, U.R., Nada, N., Strategies for Software Reuse:
A Principal Component Analysis of Reuse Practices. IEEE Trans. on Soft. Eng., 29(9):
(2003). p. 825-837.
7. Sommerville, I., Software Engineering (7th edition): Pearson Education Limited (2004).
8. Firesmith, D., Specifying Reusable Security Requirements. Journal of Object Technology,
3(1): (2004). p. 61-75.
9. Berners-Lee, T., Hendler, J., Lassila, O., The Semantic Web, in Scientific American.(2001):
10. Brewster, C.O'Hara, K., Knowledge Representation with Ontologies: The Present and
Future. IEEE Intelligent Systems, 19:1: (2004). p. 72-73.
11. Gruber, T., Towards Principles for the Design of Ontologies used for Knowledge Sharing.
International Journal of Human-Computer Studies, 43(5/6): (1995). p. 907-928.
12. Raskin, V., Hempelmann, C.F., Triezenberg, K.E., Nirenburg, S. Ontology in Information
Security: A Useful Theoretical Foundation and Methodological Tool. in New Paradigms
Security Workshop NSPW'01. ACM Press Clouford, New Mexico, USA (2001).
13. Tsoumas, B.Gritzalis, D., Towards an Ontology-based Security Management. Proceedings
of the 20th International Conference on Advanced Information Networking and
Applications (AINA'06). IEEE Computer Society, 1: (2006).
14. Mouratidis, H.Giorgini, P., Integrating Security and Software Engineering: Advances and
Future Visions: Idea Group Publishing (2007a).
15. Toval, A., Olmos, A., Piattini, M. Legal Requirements Reuse: A Critical Success Factor for
Requirements Quality and Personal Data Protection. in IEEE Joint International
Conference on Requirements Engineering (ICRE'02 and RE'02). Essen, Alemania (2002b).
16. MAGERIT, Methodology for Information Systems Risk Analysis and Management: (2006)
17. ISO15408, ISO/IEC 15408 (Common Criteria v3.0) "Information Technology Security
Techniques-Evaluation Criteria for IT Security".(2005).
18. Toval, A., Nicolás, J., Moros, B., García, F.,Requirements Reuse for Improving Information
Systems Security: A Practicioner's Approach.
Requirements Engineering
19. IEEE, Std 830-1998 Guide to Software Requirements Specifications in Volume 4: Resource
and Technique Standards. The Institute of Electrical and Electronics Engineers, Inc. IEEE
Software Engineering Standards Collection.(1999).
20. IEEE, Std 1233-1998 Guide for Developing System Requirements Specifications, in Volume
1: Customer and Terminology Standards. The Institute of Electrical and Electronics
Engineers, Inc. IEEE Software Engineering Standards Collection(1999).
21. Martínez, M.A., Lasheras, J., Toval, A., Piattini, M. An Audit Method of Personal Data
Based on Requirements Engineering. in The 4th International Workshop on Security In
Information Systems (WOSIS-2006). Paphos, Chipre (2006).
22. Lozano-Tello, A.Gómez-Pérez, A., ONTOMETRIC: A Method to Choose the Appropriate
Ontology. Journal of Database Management. Special Issue on Ontological analysis,
Evaluation, and Engineering of Business Systems Analysis Methods, 15(2): (2004).
23. Blanco, C., Lasheras, J., Valencia-García, R., Fernández-Media, E., Toval, A., Piattini, M.
A Systematic Review and Comparison of Security Ontologies. in International Workshop on
Frontiers in Availability, Reliability and Security (FARES) in conjunction with ARES.
Barcelona (2007).
24. Dobson, G.Sawyer, P., Revisiting Ontology-Based Requirements Engineering in the age of
the Semantic Web. International Seminar on "Dependable Requirements Engineering of
Computerised Systems at NPPs", Institute for Energy Technology (IFE), Halden: (2006).
25. Mouratidis, H., Giorgini, P., Manson, G., An Ontology for Modelling Security: The Tropos
Approach, in Knowledge-Based Intelligent Information and Engineering Systems. Springer
Berlin / Heidelberg. (2003) p. 1387-1394.
26. Kim, A., Luo, J., Kang, M. Security Ontology for Annotating Resources in 4th International
Conference on Ontologies, Databases, and Applications of Semantics (ODBASE'05). Agia
Napa, Cyprus (2005).
27. Fenz, S.Weippl, E.Ontology based IT-security planning. Proceedings of 12th Pacific Rim
International Symposium on Dependable Computing PRDC '06. IEEE Computer Society:
(2006). p. 389-390.
28. Lee, S.W., Gandhi. R.A., Ontology-based Active Requirements Engineering Framework.
APSEC (2005).