A Task Orientated Requirements Ontology for Cloud Computing

Services

Richard Greenwell

, Xiaodong Liu

, Kevin Chalmers

and Claus Pahl

Institute for Informatics and Digital Innovation, Edinburgh Napier University, Colinton Road, Edinburgh, U.K.

School of Computing, Dublin City University, Glasnevin, Dublin, Republic of Ireland

Keywords: Cloud, Service, Description, Semantic, Requirements, Engineering, Ontology.

Abstract: Requirements ontology offers a mechanism to map requirements for cloud computing services to cloud

computing resources. Multiple stakeholders can capture and map knowledge in a flexible and efficient

manner. The major contribution of the paper is the definition and development of an ontology for cloud

computing requirements. The approach views each user requirement as a semantic intelligence task that

maps and delivers it as cloud services. Requirements are modelled as tasks designed to meet specific

requirements, problem domains that the requirements exist in, and problem-solving methods which are

generic mechanisms to solve problems. A meta-ontology for cloud computing is developed and populated

with ontology fragments on to which cloud computing requirements can be mapped. A critical analysis of

the usage of ontologies in the requirements process is made and a case study is described that demonstrates

the approach in a real-world application. The conclusion is that problem-solving ontologies provide a useful

mechanism for the specification and reuse of requirements in the cloud computing environment.

1 INTRODUCTION

Wind and Schrödl (Wind and Schrödl, 2011)

describe a number of approaches to Requirements

Engineering (RE) in cloud computing, which were

found to be unsuitable in a number of key areas,

such as architecture selection, legal issues and

pricing. Cloud services require semantics to express

functionality derived from many service providers.

Semantic web-services have successfully used

ontologies (Fensel et al., 2003), as have a number of

RE approaches (Happel and Seedorf, 2006). An

ontological approach can address some of the

shortcomings seen in the current cloud computing

RE process, such as lack of completeness,

consistency and conflicts between requirements.

Ontologies have been used for modelling

requirements for various aspects of information

systems. Farfeleder et al (Farfeleder et al., 2011)

describe ontologies using natural language for

formalising and verifying requirements in embedded

systems. Jureta et al.(Jureta et al., 2008) discuss the

use of ontologies in stakeholder communication.

A particularly useful ontological RE approach is

described by Bogg et al (Bogg et al., 2011). Bogg

explores the use of Problem-Solving Methods

(PSMs) expressed as an ontology in RE. PSM are

reusable methods or approaches to problems that can

be used across a number of knowledge domains. The

approach is seen as cogent for cloud computing, as

large compute clouds can be seen in a service

brokerage process, which could provide access to a

large number of PSMs instances to solve problems

across a number of knowledge domains.

In this paper, we advocate the view that the cloud

computing environment can be seen as a problem-

solving environment. Users have problems which

can be tackled using a cloud computing, at a given

quality of service and cost. Requirements ontology

is used to support this problem-solving approach.

The requirements are modelled as tasks designed to

meet specific requirements, problem domains that

requirements exist in, and as problem-solving

methods which are generic mechanisms to solve

problems and bridges between the three elements.

The approach enables each user requirement to be

considered as a semantic task, which can be

implemented as a cloud service.

The remaining parts of the paper are organised as

follows: section two presents an overview of the

important work and aspects of ontology usage in RE.

The design of the ontology is defined in section

three. Section four provides a specification of the

Greenwell, R., Liu, X., Chalmers, K. and Pahl, C.

A Task Orientated Requirements Ontology for Cloud Computing Services.

In Proceedings of the 6th International Conference on Cloud Computing and Services Science (CLOSER 2016) - Volume 1, pages 121-128

ISBN: 978-989-758-182-3

121

requirements ontology. A case study is presented in

section five which demonstrates and verifies the

proposed RE approach. Section six provides

discussion of the approach. Conclusions are drawn

in section seven, with future work identified.

2 REQUIREMENTS

ENGINEERING ONTOLOGY

Ontologies provide a structured framework for

modelling the concepts and relationships of a

domain of expertise. Ontologies support the creation

of repositories of domain-specific reference

knowledge (Crubézy and Musen, 2003). Ontologies

have been used for requirements engineering for a

number of years. Zave and Jackson (Zave and

Jackson, 1997) described “core” ontology as solving

the “requirements problem”. The core ontology

established the minimum set of information required

for engineering requirements as:

S, W ├R

Given:

R are given requirements

S is a complete specification

W are domain assumptions

Proof of Obligation requires that the

specification and domain assumptions to be satisfied

by the requirements (Classen, 2007). This points to a

“pure” but simplistic approach to RE that only

specification and domain assumptions are required

in the RE process. The approach is criticised, by

Jureta et al (Jureta et al., 2008), who state that partial

requirements cannot be described in Zave and

Jackson’s model, and only a complete specifications

can be created. The requirements specifications

cannot be ranked in terms of better or worse

requirements for a given specification. Non-core

requirements cannot be defined and, nice to have

requirements may be lost.

Castanada et al (Castaneda et al., 2010) identify

a number of benefits in using ontology in the RE

process. A requirements model is imposed enabling

the structuring of requirements and the knowledge

domain in question. The Interrelationships between

requirements can be defined.

A number of attempts have been made to specify

an ontology to describe the components of cloud

computing, a typical example being Youseff et al

(Youseff et al., 2008). These ontological approaches

suffer from viewing cloud computing as a

continuation of Software as a Service and

concentrate on low level virtualisation.

A cloud computing ontology has been developed

and enhanced for cloud computing using the work of

Norton et al (Norton et al., 2008). The ontology

development is the major contribution of this paper,

along with ontology ‘Fragments’. The ontology can

be seen as a meta-ontology for RE in cloud

computing environments, building on more generic

ontologies for problem-solving.

Each user requirement can be defined as a

semantic task, this facilitates enhanced capability in

the validation of specification, the discovery of

services and composition of cloud services. Cloud

computing can be seen as more complex than

traditional Information (IT) environments. User

requirements are expressed at a high level, a

brokerage layer or service will find and price these

requirements from a number of cloud computing

resources. Cloud computing resources will then

execute tasks for these brokered requirements.

Expressing requirements using a problem-

solving ontology allows the requirements engineer

to utilise an approach that is well suited to the cloud

computing environment. Tasks can be seen as a unit

of work that is well understood by users. Problem

Solving Methods (PSMs) can be seen as reusable

specifications for solving the problems posed by

tasks. Domain models can be built as an ontology so

it can be understood by users and verified using

ontological reasoning tools. The requirements

ontology can be seen as a specialisation of more

generalised problem-solving ontology such as the

Unified Problem-solving Method Development

Language (UPML) which will be described.

Fensel et al (Fensel et al., 2003) describe

(UPML) which is a framework for developing

knowledge-intensive reasoning systems based on

libraries of generic problem-solving components.

They go onto describe the UPML architecture as

tasks that defines the requirements for the problem

that is to be solved. Problem-solving methods (PSM)

define the reasoning process and, domain models

that describe domain knowledge. Bridges are used to

map and define the relationship and transformation

between the task and PSM.

Crubézy and Musen (Crubézy and Musen, 2003)

describe how Problems Solving Methods (PSMs)

and domain ontologies are combined to produce

knowledge systems. Musen (Musen, 2001) describes

domain ontologies as a “Characterisation of

concepts and relationships in an application area,

providing a domain of discourse”. Domain

ontologies define problem specific knowledge.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

122

3 REQUIREMENTS ONTOLOGY

DESIGN

A detailed requirement ontology can be mapped to a

number of ‘knowledge components’ for

implementation within ontology modelling tools.

The knowledge component provides a base selection

of properties such as description and requirement

pragmatics. Elements of the ontology then inherit

properties from the knowledge component.

Specialist PSMs such as problem decomposers

(PSMs that can split a task into subtasks) can be

developed for specific purposes. Requirements

engineers can develop their own specialist tasks,

PSMs and domain models for a specific

requirements problem using powerful mechanisms

such as inheritance and set operations. The usage of

tasks, PSMs and domain models will lead to greater

reuse as a generic method PSM.

Figure 1 (below) describes a model into which

requirements can be tailored. This machine readable

model is used directly in cloud computing

environments.

The ontology provides a checklist of ‘what’

requirements are needed and is specified in terms of

tasks, PSMs and Domain Models. The model

provides representation for elements of

requirements. Requirements are expressed in terms

of semantics and, concepts such as tasks can be

expressed in terms of rich semantics, as can

relationships between tasks, PSMs and Domain

Models. This allows the requirements engineers’

greater expressive power, and the ability to carry out

fuzzy searches and to map new knowledge and

requirements via the reasoning tools seen in

ontology management tools.

Knowledge

Component

Problem

Solving

Method

Domain

Model

Problem

Decomposer

Reasoning

Resource

Task

is_a

is_a is_a

produces_subtasks

is_a

Figure 1: Requirements Ontology Implementation.

The architecture of the ontology is described in

Figure 2 (below). The highest layer deals with

problem-solving for cloud computing. Users will

have tasks which use the PSMs and domain

ontology. The brokerage layer defines elements in

terms of ontology, tasks will be executed at a

strategic level across the cloud environment dealing

with issues such as cost and quality of service. The

low level layer deals with operational requirements.

UPML Brokerage

Ontology

Discovery Adaptation Comparison

Mediation Grounding Fault Handling

Choreography Monitoring Pricing

Brokerage

Mapping

UPML Problem

Solving Ontology

User Interface for

Problem Solving

Ontology Manipulation

Tools

Problem Solving

UPML Ontology for

Low Level Resources

Resource

Description

Pricing

Low Level

Mapping

Cloud Interface

Adapters and Bridges

Mapping

Distributed Cloud

Resources

Figure 2: The hierarchical Stricture of Ontology.

The details of each element of the requirements

ontology from figure 2 (above) will now be

described.

3.1 Problem Solving

The problem-solving layer relates to the high level

requirements of users expressed as ontology and,

they describe ‘what’ is required; which may be full

requirements or partial requirements expressed as

ontology fragments. The requirements must be

matched to low level requirements through the

brokerage process via semantic or fuzzy matching.

The separation of requirements into tasks, PSMs

and domain knowledge and representation as UPML

provides ease of mapping to low level requirements

through the brokerage process.

3.2 Brokerage

The brokerage of requirements map high level

A Task Orientated Requirements Ontology for Cloud Computing Services

123

requirements to lower level requirements. This is

carried out by semantic searching, fuzzy matching

and negotiated processes. Discovery can be driven

by the Quality of Service (QOS) requirements.

These requirements are carried forward from user

requirements expressed in the high level layers of

the requirements ontology. Monitoring can use the

QOS requirements to define the requirements for

service failure. Pricing requirements can also be

related to QOS.

Discovery requirements describe what and how

cloud services are found across a set of cloud

resources. Adaptation requirements relate to how

defined requirements can be adapted to meet new

user requirements. The adaptation process is made

easier by the use of ontology as sets of requirements

that that can be adapted by recombination through

semantic relationships provided in the UPML

ontology. Closely related to adaptation, composition

requirements describe how sets of cloud resources

are combined to meet high level user requirements.

Mediation requirements define how high level

problem-solving requirements will be translated into

low level requirements by a process of iteration.

Many of the mediation requirements are concerned

with QOS, Rimal et al (Rimal et al., 2011) describe

the need for quality of service requirements in cloud

computing. Quality of service provides a guarantee

of the availability and performance of tasks inside

the cloud. Requirements are supported by service

elements such as security, reliability and

dependability. Stakeholder groups will place value

on service elements, for example low latency short

burst resources will be required by some users,

whereas other users will require long running

resource pools. Grounding requirements link the

execution of the requirements with how the

requirement is to be executed at a low level. Fault

handling requirements provide actions that are

necessary when errors occur at low levels in cloud

resources.

Choreography requirements provide the

approach required for coordinating higher level

requirements so they are performed correctly at a

low level. Monitoring requirements specify the

information required as tasks are executed and

choreographed. Pricing requirements at the

brokerage level deal with pricing estimation for a

given high level tasks and aggregate pricing for

packages of low level tasks.

The requirements ontology can draw upon many

leading research concepts seen in the literature to

represent concepts in the requirements ontology as a

complete ontology or ontology fragments. Robinson

(Robinson, 2003) describes service monitoring,

which is a brokerage component within the

requirements ontology. The high level requirements

for monitoring can be represented as a PSM:

1. Define the design-time model

a. Define goals and requirements

b. Define obstacles and monitors

2. Define the run-time model

3. Monitor the running program

It should be noted that this PSM can be used by a

number of tasks as the PSM can act on a number of

problem domains. The requirements are represented

in the brokerage layer. A primary goal can be

decomposed by a specialist PSM called a problem

decomposer. Tasks such as monitor will have inputs,

outputs, competencies and formal definitions seen in

Figure 2 (above). Lower level representation can

also be represented as ontology.

The discovery and monitoring processes can use

a similar service discovery and monitoring approach

in cloud computing. High level requirements are

used to drive the service discovery of web-services.

Users can then select cloud services that match their

QOS requirements.

Service adaptation can be seen in the

requirements ontology. Higher level requirements

goals and services categories can be represented as

domain models; these are measured using a

‘measure’ PSM. In the brokerage layer service

definitions are domain models used by a monitor

definition PSM. The lower service domain models

are monitored by PSM.

Ontological representation could provide many

of the features required by researchers, such as fuzzy

searching and the matching and representation of

partial requirements using ontological fragments.

3.3 Low Level Requirements

Resource description requirements of each low level

cloud resource are required so that they can be

brokered. Examples of a resource description could

be maximum CPU capacity, storage capacity,

response time and spare CPU capacity.

Sun et al (Sun et al., 2012) point out that cloud

computing has seen vendors offering a number of

cloud computing platforms. Ontology can be used to

describe vendors’ offerings and can be used to

abstract models from the integration of disparate

offerings. Pricing requirements at a low level deal

with areas such as the cost of CPU capacity and

storage capacity. The requirements of cloud adaptors

and bridges provide information for brokerage

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

124

requirements.

4 SPECIFICATION OF THE

REQUIREMENTS ONTOLOGY

The three levels of the requirements ontology

(problem-solving, brokerage and low level) are all

described in terms of UPML. This allows mapping,

stepwise refinement, interaction and reasoning to be

carried out between the layers. The usage and

processing of ontology fragments has been described

by a number of researchers (Nebot and Berlanga,

2009), (Kalfoglou et al., 2008) and (Packer et al.,

2010).

The high level problem-solving requirements are

specific to each individual requirements domain or

process. They are still defined and structured in a

UPML and the example of high level problem-

solving is shown in the case study (below). The

requirements ontology concentrates on the brokerage

and low level aspects of RE. Brokerage fragments

will take the problem-solving requirements and

consider the requirements for their fulfilment. An

example of a brokerage fragment will be given for

discovery. Discovery is the process of finding

resources for the fulfilment of a high level

requirement. In Figure 3 (below), the RE ontology

fragment for discovery is shown. The UPML

ontology provides the framework for ontology

fragments, which in turn guide the subsequent RE

process. The discovery process is driven by two

tasks, the discover resources search the cloud

resource model and the cloud technology to build a

catalog of resources and will search the catalog with

a query string to allow the resources to be

discovered.

Table 1 (below) shows how properties can be

defined for the “Discover Resources” task.

Table 1: Discover Resources Task.

Input/Output

Class

Cardinality Type

Input Exactly 1 Cloud Resource

Model

Input Exactly 1 Cloud

Topology

Output Exactly 1 Catalog

Now the requirements ontology has been

described in detail a case study will demonstrate

how the requirements can be defined for each

requirements ontology element.

Concept

Competence

Available Resources

Formula

Similarity Algorithm

Knowledge Component

Domain Model

Catalog

Query

Cloud Resource Model

Cloud Tolopology

Problem Solving Method

Reasoning Resource

Build Catalog of low

Level Resources

Parse Query String

Task

Search Catalog

Discover Resources

Figure 3: Discovery Element Ontology Fragment.

5 CASE STUDY

The case study shows how RE can utilise a UPML

based ontology using the concepts described in the

requirements ontology. The case study describes the

requirements for a document similarity framework,

which allows documents such as academic texts to

be compared to the papers they reference. Manning

et al (Manning et al., 2008) outline an approach for

document similarity.

• Collect the documents to be indexed

• Tokenise the text

• Carry out linguistic pre-processing of tokens

• Index the documents that each term occurs in

• Use similarity measures based on mathematical

measures, such as Cosine Similarity

A Task Orientated Requirements Ontology for Cloud Computing Services

125

• Report or carry out further processing such as

clustering

The case study is particularly suited to cloud

computing as large amounts of parallel processing

are required to process documents. In single

processor machines finding and comparing

thousands of documents can take several hours.

There is also scope to expand the application to

recursively find referenced documents from the

documents referenced from a study text.

5.1 High Level Problem-solving

Requirements Ontology.

The high level tasks required for the case study are

described Table 2 (below). The requirements

describe a workflow of tasks which need to be

executed to carry out document similarity for a

document from a student course.

Table 2: Case Study: High Level Requirements.

Task Requirements Description

Find academic references

in course Documents

Parsing to find

document references.

Create structured

references and import

into reference

management system

Format references so

they are machine

readable.

Find academic papers for

references

Find references

automatically using

cloud-services

Extract plain text from

the PDF files, break into

pages and tokenise text

Use off-the-shelf

cloud software

libraries

Pre-process tasks

and indexation

Use off-the-shelf

software libraries

Create similarity

measures and match

documents

Suited to Cloud

computing Burst of

processor bound tasks

Reporting Report document

similarity

These task requirements are then converted into

UPML ontology. The requirements are split into

tasks, PSM and Domain Models.

5.2 Brokerage

The brokerage ontology matches the high level

requirements to the low level requirements ontology.

Each aspect of the ontology will now be discussed.

Discovery can be seen as requirements which use

a ‘find low level requirement for a high level

requirement’ PSM. The high level requirement task

‘evaluate_corpus’ requires the low level formulas

such as ‘Ratio Distance’ and will discover

‘match_papers_to_study_text_papers’.

Adaptation is the process of adapting low level

requirements to meet a new or existing high level

requirement. Composition defines the ordering of

requirements tasks to complete the goal of producing

document similarity for a corpus of documents. The

tasks in the case study are self-organising as output

from one low level resource feeds the input of

another low level resource.

Mediation is driven by the high level

requirements specification to find the most

appropriate low level resource by stepwise

refinement.

Grounding is a simple mapping of high level

tasks requirements to individual software modules.

Fault handling requirements deal with actions

that occur in low level programming language

modules, virtual machines and physical machines.

An off the shelf chorography model was used.

Yazir et al (Yazir et al., 2010) describe the

PROMETHEE methodology for chorography across

multiple cloud resources where a number of physical

machines (PM) are allocated including Virtual

Machines (VM) across a set of cloud resources.

Monitoring requirements concern the information

required being used to review the progress of the

low level execution of tasks.

An existing pricing model was used in this case

study. Henzinger et al. (Henzinger et al., 2010)

discuss the Flexprice model for pricing across

multiple cloud resources. In a commercial

implementation of a document similarity framework

high level task requirements will be priced across a

number of cloud providers and the most cost

effective solution will be selected

5.3 Low Level Requirements Ontology

A number of formulas are required to calculate

document similarity. UPML allows individual

software components to be described. Tasks describe

the operations required to meet requirements high

level requirements. UPML can describe both high

and low level requirements in a structured way.

6 DISCUSSION

Requirements engineering ontology provides a three

layer framework for RE in the cloud computing

environment built on UPML.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

126

The ontology can be checked for correctness and

reasoning and can map new knowledge from the

ontology that can be relayed to users. Requirements

can be inserted into the ontology and used at a later

date. Requirements can be found using semantic or

fuzzy searching as well as syntactical searching.

The requirements ontology environment can be

used to develop meta-services. These meta-services

support two key features that are new to cloud

computing self-service and on-demand provision.

The high level and brokerage requirements seen in

the requirements ontology allow customers to access

on-demand self-service via meta-services.

The case study has demonstrated the

requirements ontology built on UPML. The three

layers of the requirements ontology provide

guidance for the definition of a document similarity

framework for study texts and the papers referenced

from the study text. High level requirements,

brokerage and low level requirements are expressed

as textual requirements and, then as a UPML

ontology. Ontology mapping and reasoning tools can

be used to match each layer of the model, so that

high level requirements can be executed by

appropriate resources in the cloud. The use of

ontology leads to a greater reuse of requirements and

the generation of new requirements by reasoning.

The reuse of requirements is a key advantage of

using a UPML based ontology. A PSM can be used

in many knowledge domains and knowledge

domains can be re-used for new requirements.

Problem-solving ontologies are seen as useful for

cloud computing as it can be seen as a problem-

solving paradigm, as opposed to an extension of

SaaS or virtualisation of existing applications.

7 CONCLUSIONS AND FUTURE

WORK

This paper has described an ontology driven

approach to requirements engineering for cloud

computing. This is embodied in the requirements

ontology which was built on a specialised form of

ontology based on a UPML, which is well suited to

service specification. A key aspect of the approach is

the examination of the brokerage requirements,

which bridge high level and low level requirements

specifications.

The requirements engineering problem is broken

down into three sets of concepts: tasks which

describe the work that is to be done, problem-

solving methods which describe the solutions to

problems, and a problem domain which describes

concepts for a given requirements scenario. The

requirements ontology builds on a UPML structured

ontology approach across the three distinct levels in

cloud computing RE. Ontology mapping is seen as a

key tool for linking requirements at different levels

in the requirements ontology.

Future work will see the implementation being

expanded to allow for a simpler specification of

knowledge components such as tasks, domain

knowledge, problem-solving methods and bridges.

In future case studies, more complex brokerage will

be used. Security will be included in the future

version of the requirements ontology as it is a major

emerging area in cloud computing.

REFERENCES

Bogg, P., Beydoun, G., Low, G., 2011. Problem-solving

methods in agent-oriented software engineering.

Information Systems Development, Springer New

York} 4, 243–254.

Castaneda, V., Ballejos, L., Caliusco, M.L., Galli, M.R.,

2010. The Use of Ontologies in Requirements

Engineering. Global Journal of Research Engineering

10.

Classen, A., 2007. Problem-Oriented Feature Interaction

Detection in Software Product Lines.

Crubézy, M., Musen, M.A., 2003. Ontologies in Support

of Problem Solving, in: Handbook on Ontologies.

Springer, pp. 321–342.

Farfeleder, S., Moser, T., Krall, A., Stalhane, T., Zojer, H.,

Panis, C., 2011. DODT: Increasing requirements

formalism using domain ontologies for improved

embedded systems development, proceedings of the

14th IEEE International Symposium on Design and

Diagnostics of Electronic Circuits & Systems

(DDECS). IEEE, pp. 271–274.

Fensel, D., Motta, E., Benjamins, V.R., Crubezy, M.,

Decker, S., Gaspari, M., Groenboom, R., Grosso, W.,

Harmelen, F. van, Musen, M., Plaza, E., Schreiber, G.,

Studer, R., Wielinga, B., 2003. The Unified Problem-

solving Method Development Language UPML.

Knowledge and Information Systems, Springer-Verlag

London Limited 5, 83–131.

Happel, H.J., Seedorf, S., 2006. Applications of ontologies

in software engineering. Presented at the Proc. of

Workshop on Sematic Web Enabled Software

Engineering"(SWESE) on the ISWC, Citeseer, pp. 5–

Henzinger, T.A., Singh, A.V., Singh, V., Wies, T.,

Zufferey, D., 2010. FlexPRICE: Flexible Provisioning

of Resources in a Cloud Environment, in: Cloud

Computing (CLOUD), 2010 IEEE 3rd International

Conference on. Presented at the Cloud Computing

(CLOUD), 2010 IEEE 3rd International Conference

on, pp. 83–90. doi:10.1109/CLOUD.2010.71.

A Task Orientated Requirements Ontology for Cloud Computing Services

127

Jureta, I.J., Mylopoulos, J., Faulkner, S., 2008. Revisiting

the core ontology and problem in requirements

engineering. Presented at the Proceedings of the 16th

IEEE International Conference on Requirements

Engineering (RE’08), 2008, IEEE, pp. 71–80.

Kalfoglou, Y., Smart, P.R., Braines, D., Shadbolt, N.,

2008. POAF: Portable ontology aligned fragments.

Manning, C., Raghavan, P., Schutze, 2008. Introduction to

Information Retrieval. Cambridge University Press.

Musen, M., 2001. Building Systems with Ontologies and

Problem-Solving Methods.

Nebot, V., Berlanga, R., 2009. Efficient retrieval of

ontology fragments using an interval labeling scheme.

Information Sciences 179, 4151 – 4173. doi:10.1016/j

.ins.2009.08.012.

Norton, C., Domingue, J., Zaremba, M., 2008. Semantic

Execution Environments for Semantics-Enabled SOA,

in: IT - Methods and Applications of Informatics and

Information Technology. Presented at the Special

Issue in Service-Oriented Architectures, pp. 118–121.

Packer, H.S., Gibbins, N., Jennings, N.R., 2010.

Collaborative learning of ontology fragments by

cooperating agents.

Rimal, B., Jukan, A., Katsaros, D., Goeleven, Y., 2011.

Architectural Requirements for Cloud Computing

Systems: An Enterprise Cloud Approach. Journal of

Grid Computing 9, 3–26.

Robinson, W.N., 8. Monitoring Web service requirements.

Requirements Engineering Conference, 2003.

Proceedings. 11th IEEE International 65–74.

doi:10.1109/ICRE.2003.1232738.

Sun, Y., Harmer, T., Stewart, A., Wright, P., 2012.

Mapping application requirements to cloud resources,

in: Euro-Par 2011: Parallel Processing Workshops.

pp. 104–112.

Wind, S., Schrödl, H., 2011. Requirements engineering for

cloud computing: a comparison framework, in:

Proceedings of the International Conference on Web

Information Systems Engineering, WISS’10.

Springer-Verlag, Berlin, Heidelberg, pp. 404–415.

Yazir, Y.O., Matthews, C., Farahbod, R., Neville, S.,

Guitouni, A., Ganti, S., Coady, Y., 2010. Dynamic

resource allocation in computing clouds using

distributed multiple criteria decision analysis, in:

Cloud Computing (CLOUD), 2010 IEEE 3rd

International Conference on. pp. 91–98.

Youseff, L., Butrico, M., Silva, D.D., 2008. Towards a

unified ontology of cloud computing, in: In Proc. of

the Grid Computing Environments Workshop

(GCE08). IEEE, Austin, Texas.

Zave, P., Jackson, M., 1997. Four dark corners of

requirements engineering. ACM Transactions on

Software Engineering and Methodology (TOSEM) 6,

1–30.

CLOSER 2016 - 6th International Conference on Cloud Computing and Services Science

128