Keywords

1 Introduction

Cloud computing is an Internet-based business where service providers offer information and communication technology (ICT) resources by optimizing physical and logical infrastructure, and service consumers pay only those which they use for storing, analyzing, processing, transferring, and managing data in provider’s resources. Cloud computing enables organizations to consume ICT resources as a utility (like gas and electricity), rather than having to invest and maintain on-premise computing infrastructures. Thus, cloud computing is changing the way in which companies are doing business and dealing with information technology.

Even though the success of any software solution depends mostly in the identification of requirements in early stages of software development [1], it is shown that there are not well-known foundations and methodologies for handling cloud requirements in the academic community [2, 3]; and no empirical evidence was found about how to elicit and manage requirements in cloud domain [4]. Therefore, a systematic literature review is necessary to compile all the evidences of requirements engineering activities in this context, to synthesize high-level insights from published studies, and to consider the challenges presented in research results. Individual published studies considered in systematic reviews are called primary studies, so systematic reviews are labeled secondary studies [5].

Primary studies have reported experiences and lessons learned from applying diverse methods and techniques for adopting cloud services. The secondary study presented in this chapter is expected to identify, analyze, and interpret those primary researches, in order to contribute to the existing knowledge bases and to improve the state of the practice in requirements engineering for cloud computing.

It is a fact that cloud environments are stochastic and dynamic, so it is complex to manage cloud requirements in a systematic and repeatable way [3], especially when requirements rapidly change in a non-predictive manner. The main causes why cloud requirements change are: (a) organizational policies change the business priorities, so the requirements have to be aligned with the new scope and goals; (b) environment and marketplace change by the addition of competitors or new business targets; (c) legislation changes may request new forms, features, and security algorithms in cloud applications; and (d) new technology solutions appear. Thus, the main objective of this work is to understand and carefully analyze cloud computing domain, considering published researches in the field of requirements engineering, in order to identify and quantify research topics on requirements engineering in cloud computing.

The NIST introduces a cloud definition framework, where there are five main characteristics (i.e., broad network access, rapid elasticity, measured service, on-demand self-service, and resource pooling), five roles (i.e., consumer, provider, auditor, carrier, and broker), three service models (i.e., Software as a Service , Platform as a Service , and Infrastructure as a Service ), and four deployment models (i.e., public cloud, private cloud, community cloud, and hybrid cloud) [6]. In this contribution, the NIST cloud definition framework is also extended and five cloud dimensions are added (i.e., contractual, financial, compliance, operational, and technical) after conducting a literature review.

The five proposed cloud dimensions link static properties (e.g., contractual aspects) and dynamic requirements (e.g., technical and operational aspects). Some dimensions may be separately analyzed by domain experts (e.g., compliance dimension is analyzed by lawyers in small and medium-sized enterprises). The final purpose is to bind different service perspectives in order to manage cloud service adoption. This chapter aims to consolidate different cloud aspects to fluidly satisfy consumer dynamic requirements. In conclusion, cloud consumers (i.e., organizations and users) are provided with accurate information to address their requirements to service offers and cloud providers are fitted with precise attributes to offer service capabilities. This avoids potentially ambiguous terms.

The rest of this paper is organized as follows. Section 3.2 introduces some insights about cloud computing and requirements engineering. Section 3.3 presents a brief discussion about the findings and some graphs of the literature review. In Sect. 3.4, the proposed dimensions and some models are proposed in order to facilitate cloud requirements specification. Finally, Sect. 3.5 discuses the final remarks and future works.

2 Background

Cloud computing is a paradigm of external arrangement, where third party services are contracted according to Service Level Agreements (SLA) between cloud providers and service consumers, by means of Internet protocols. In this way, cloud providers optimize the usability of their own technology infrastructure offering storage solutions (hosting) and computer services (outsourcing), and cloud consumers pay for cloud services taking into account the type of service charge (i.e., pay per use, subscription, etc.) [6, 7]. The cloud environments are stochastic and dynamic, so it is complex to identify, clarify, and manage cloud requirements in a systematic way [3, 8], especially when services and requirements change in an unpredictable manner.

Requirements engineering is the field of software engineering dedicated to identify, analyze, specify, and validate software requirements [9]. The software requirements represent the needs and constraints considered in the software solution of a real problem.

Requirements engineering is related to software design, software testing, software maintenance, configurations management, quality assurance, and other processes of software engineering. Pohl in his book [10] considers elicitation, analysis, specification, validation/verification, and management of requirements, as requirements engineering processes. In addition, Flores et al. assume that requirements engineering process for general services involve the next activities [11]:

  1. 1.

    Requirements Specification : service requirements are identified.

  2. 2.

    Requirements Analysis : requirements are analyzed in detail and possible conflicts between them are examined.

  3. 3.

    Requirements Validation : requirements consistency and completeness must be evaluated.

  4. 4.

    Requirements Management : it supports all activities and solutions during RE process.

Wieger in [1] classifies requirements engineering artifacts in: business requirements, scenarios and uses cases, business rules, functional requirements, quality attributes, external interface requirements, constraints, data definitions, and potential software solutions. Moreover, Pohl specifies goals, scenarios, and requirements oriented to the software solutions, as part of the RE artifacts [10].

In cloud computing, requirements engineering approaches are mostly concentrated in object-oriented artifacts and service-oriented tools. Thus, some authors adjusted existing tools, languages, and methodologies to this paradigm. The biggest challenge in cloud computing is the lack of standard, that help meet the objectives covering many different aspects of cloud services [12]. Existing requirements engineering processes for cloud computing are generally about a limited number of nonfunctional requirements. Moreover, most of the approaches about cloud requirements are focused on particular characteristics, as security [8], privacy [13], availability, and other performance aspects [14, 15].

However, cloud business paradigm is still growing popularity, because cloud offers and cloud demands are rising at the marketplace. Cloud providers optimize their physical infrastructure offering IT resources as cloud services, and consumers outsource solutions adopting cloud models (i.e., Software as a Service , Platform as a Service , and Infrastructure as a Service ). In consequence, cloud computing is very complex to administrate because of the dynamism imposed by the context, i.e., elastic resources (released, turned off/on, resized, scaled up/down), stochastic requirements depending of business changes (peak/nonpeak times), heterogeneous consumers from different places and jurisdictions, distributed systems, and remote manage.

Some authors propose frameworks and methods, but there is no available empirical evidence on the elicitation methods utilized by cloud providers [4]. For instance, Repschlaeger et al. [2] present a framework that includes evaluation criteria to adopt cloud services, and Schrödl and Wind [16] propose a framework to validate established process models for RE in regards to the implementation for cloud computing. Schrödl and Wind conclude that none of the common models (V-model, Volere, Extreme Programming, and Rational Unified Process) is suitable to cover the needs of requirements engineering under cloud computing.

Small and medium-sized enterprises also develop projects for adopting cloud services and migrating legacy systems to cloud environments. Besides cloud projects are a major trend in IT solutions [17], little information about frameworks and methods for supporting projects during system development life cycle for this domain is given [18]. In addition, the lack of requirements engineering methods promotes the occurrence of unpredictable risks related with incorrect or unjustified decisions which can be made during project plan developments. There are no standardized processes to manage requirements engineering activities or to decide how they should be performed, and organizations try to adapt existing techniques or create new one for supporting cloud projects, missing suitable, and systematic guidance [3, 4]. Thus, this chapter aims to provide a comprehensive and systematic literature review of the academic research done in requirements engineering for cloud computing, and introduces the main concerns in this area. Having an overview about methods and techniques for handling cloud requirements , providers and consumers can implement existing approaches taking into account different dimensions for cloud services. Regarding this background, different aspects of requirements are considered for cloud computing by identifying and classifying core concepts within existing academia literature. Security is one of the most relevant issues in cloud computing community [18, 19]. Moreover, IT governance, legal, laws, ethical, standards, and managerial issues are not completely considered in the researches done in this area [20, 21].

In order to conduct this review, several reviews and mapping studies about cloud computing were first consulted, because they compile all the evidence about contributions and synthesize high-level insights from primary studies during past years. In fact, there was not found any general peer-reviewed paper on requirements engineering for cloud computing specifically, while secondary researches found showed that academic community is mainly focused on only specific characteristics of cloud services, i.e., security [19, 21–24], technological aspects [17], accounting models [25], quality of services [26, 27], and service composition [28]. The proposed cloud dimensions for requirements engineering are derived from those characteristics.

3 Literature Review

Selecting digital libraries and relevant databases was crucial for this secondary research (literature review). Four popular digital libraries were chosen: IEEE Xplore Digital Library, ACM Digital Library, Elsevier ScienceDirect, and SpringerLink. Those libraries covered important works in requirements engineering and cloud computing. However, some considerations were made on the research scope and strategy of this research. First, Google Scholar engine was taken out of the scope, because it returned the largest number of duplicate articles during the search simulations. Second, ACM Digital Library returned similar results offered by IEEE and Springer engines, but it also returned some relevant studies. Third, it was not found relevant evidence of related works about cloud requirements before 2009 during the pilot searches, so the manual search of primary studies in digital libraries published between 2009 and 2015 was planned. Finally, the basic query string was searched within titles and calibrated regarding each engine. Data extraction and selection process was undertaken using the steps described in Fig. 3.1.

Fig. 3.1
figure 1

Selection process of the literature review

Full size image

Advanced search options for each database source were used that allowed to improve the inclusion of articles related to the study. Even though some articles were first picked by title and abstract, they were no precisely about requirements engineering for cloud computing. Thus, some articles were excluded from the set of relevant primary studies after considering the inclusion and exclusion criteria. The inclusion and exclusion criteria which were applied in this literature reviews are listed in Table 3.1. Search engines previously mentioned returned a list of studies as result of the research protocol which also were considered in three phases of manual inspection. First, each paper was scanned to ensure that its contributions were related to the scope of this review. Then, some studies were selected after applying the criteria on each title, abstract, keywords, and conclusion. Finally, each full-text was analyzed considering the criteria in order to decide whether or not a study should be involved in this review.

Table 3.1 Selection criteria of primary studies
Full size table

From the list of selected articles, the tendency of publication date was evaluated, and it is showed in Fig. 3.2. The interest in the topic has changed over time, and half of the selected studies put attention to security and privacy aspects of cloud computing. Most of the articles were published in 2013, but only two articles were written by the same authors and two articles were published in the same journal. It seems that cloud computing fundamentals and processes are occasionally considered by researchers in different journals and scientific events. However, several organizations and workgroups were found to be working on standards and processes, such as National Institute of Standards and Technology (NIST),Footnote 1 Cloud Standard Customer Council (CSCC),Footnote 2 IEEE Cloud Computing Standard Study Group (IEEE CCSSG),Footnote 3 and Open Cloud Consortium (OCC).Footnote 4

Fig. 3.2
figure 2

Number of studies per year

Full size image

To conduct the literature review, eight research questions were formulated. The research questions and the findings are graphically evaluated below.

RQ1: What are the main requirements engineering approaches investigated in cloud computing?

From the selected primary studies, it can be noted that frameworks and methodologies motivated research activities on the field of cloud computing. Recently, contributions proposed frameworks to evaluate and to handle requirements for cloud computing projects, however there are not well-known tools and automatic techniques supporting cloud adoption. The answer of this question is summarized in Fig. 3.3.

Fig. 3.3
figure 3

Main requirements engineering approaches (RQ1)

Full size image

RQ2: What phases and activities of requirements engineering do the approaches support?

The results for this question are shown in Fig. 3.4. Requirements engineering activities were listed and answer “All” were considered when the contribution was generic and represented all activities in its process. The most studied activities were requirements elicitation and requirements specification, and some authors considered both activities in the same step in requirements engineering process. Requirements validation was not considered in the primary studies, and it was concluded that this activity was difficult to carry on especially because stakeholders have limited control over the services.

Fig. 3.4
figure 4

Phases and activities of requirements engineering (RQ2)

Full size image

RQ3: Who are the actors/stakeholders or roles considered in the approaches?

For this question, the roles presented by NIST [29] were considered, i.e., consumer, provider, broker, carrier, and auditor. The results are presented in Fig. 3.5. Most of the selected papers had consumers as main actors during requirements engineering activities. Carrier that supports transportation of service and auditor that evaluates the service provided were explicitly out of the primary study scopes. Developer role was considered in several studies, but analyst, consultant, and manager were not implicitly considered. During the research, answer “stakeholder” was selected when the contribution was general, unclear about who were the target actors, or focused on several actors.

Fig. 3.5
figure 5

Actors/stakeholders/roles considered in the approaches (RQ3)

Full size image

RQ4: What are the cloud requirements and attributes covered in the studied literature?

Most of the studies were focused on specific attributes and requirements, and the results are shown in Fig. 3.6. Security is the most studied aspect of cloud computing in the field of requirements engineering. Cloud security is a trend topic and many research groups try to find a way for guaranteeing security in cloud services. Privacy , trust, and access control can be considered as part of security aspects.

Fig. 3.6
figure 6

Cloud requirements attributes covered in the studies (RQ4)

Full size image

RQ5: What are the domains involved in the primary studies?

Figure 3.7 presents the different domains announced in the studies. The selected approaches were mainly general and with little information about domains and supported areas. Several primary studies considered banking, healthcare, and enterprise scenarios. However, there was strong tendency to integrate many domains in the same solution, “General” in Fig. 3.7, so it is concluded that general and generic approaches are needed for handling cloud requirements suitable to all domains.

Fig. 3.7
figure 7

Domains involved in the studies (RQ5)

Full size image

RQ6: What are the cloud computing models considered in the proposals?

Deployment models were not taken into account in the selected papers and most studies did not specify any service model as study scope. Figure 3.8 shows the final results. Only one article [30] considered Platform as a Service and Software as a Service in the same approach. Software as Service is the most studied model, because cloud service adoption was mainly related to application development and programs in the primary studies. “General” in Fig. 3.8 indicates that authors did not specify the models and the proposal is generic.

Fig. 3.8
figure 8

Cloud computing models considered in the studies (RQ6)

Full size image

RQ7: How automatable are the approaches?

For this question, there were three possible answers and semiautomatic approaches were often presented in the primary studies. There were many contributions that presented some manual activities supported by tools or programs, but only three studies [31–33] presented automatic and automatable approaches for requirements engineering in cloud computing. The results are shown in the pie chart presented in Fig. 3.9.

Fig. 3.9
figure 9

Automated approaches in cloud computing

Full size image

RQ8: What are the open issues and publication trends in requirements engineering for cloud computing?

Cloud services are deployed in multiple resources shared by many different stakeholders [34, 35], and the main challenge is how to elicit commonalities and variances of numerous consumer requirements [36]. So far, there was identified a large amount of issues towards legal constraints [37–40], privacy , access control , and security requirements [13, 31–34, 41–46]. However, several approaches were also focused on functional aspects [36, 47], nonfunctional requirements [48], trust and reputation characteristics [35], and other requirements [3]. In the same manner, specific primary studies considered important to analyze separately billing attributes [49], architectural aspects [12], autonomic requirements [50], brokerage regulations [30], and contractual ruling [51].

Quality Assessment. Finally, a quality assessment considering a scale from 0 to 1 was conducted. The goal was to detect those primary studies with low quality or irrelevant contribution. Quality assessment of the studies considered was a significant part into the research protocol, because it helped reviewers to evaluate whether the contribution of each study was relevant for this review or not. In order to detect the level of significance of each study, six quality assessment questions and possible scores based on [52] were defined, and the final checklist was built, as follow:

  • QA1: How clear was the approach presented in the study?

  • QA2: How relevant and mature was the approach for cloud computing?

  • QA3: How detailed were the activities explained in the approach?

  • QA4: How clear was the approach applied in the application domain?

  • QA5: How complete was the list of goals and requirements considered in the approach?

  • QA6: How flexible and extensible was the approach presented in the study?

In Table 3.2, the number of papers that present high, medium, and low values for each of the qualitative questions is summarized. In conclusion, most of the studies were over the medium values.

Table 3.2 Qualitative summary of the studies
Full size table

Finally, it can be concluded that cloud computing is a traversal field and it can be studied in different domains (i.e., health, insurance, financial, etc.). However, cloud computing processes are occasionally considered by researchers in different journals and scientific events. The literature failed to provide a systematic approach to identify requirements and select the most suitable cloud service provider based on such requirements [13]. Nowadays, consumers have to trust providers taking into account functional attributes, price, and provider’s reputation and market share [13, 35, 41].

4 Discussions

From a set of 187 documents, only 26 relevant works have been selected and some terms were extracted to define the vocabulary of cloud computing. The terms are classified into five cloud dimensions. Each proposed dimension represents a specific aspect of cloud computing, and cloud adoption process should consider those dimensions in order to completely satisfy service requirements. For each dimension, service consumers should also follow the most suitable requirements engineering methods considering the nature of their requirements. The NIST cloud definition framework [6] is presented in Fig. 3.10 and the five dimensions are added.

Fig. 3.10
figure 10

Extension of the NIST cloud definition framework [6]

Full size image

The proposed dimensions show the semantic connections among such terms, and the cloud domain knowledge can be inferred from it. The dimensions are related to cloud services and SLA, and they can also be used to identify cloud requirements and constraints in natural language documents, such as request for proposal and software specification template. Organizations may also consider having experts in diverse fields (such as accounting manager, lawyer for legal terms, etc.) to elicit specific requirements for each dimension, especially for billing and law regulation.

The idea of cloud computing as a multidimensional paradigm is not new. For instance, Repschlaeger et al. [53] presented six target dimensions based on general objective which stakeholders pursue: (1) service and cloud management; (2) IT security and compliance; (3) reliability and trustworthiness; (4) scope and performance; (5) costs; and (6) flexibility. Pichan et al. [54] considered three dimensions to analyze services in cloud computing: (1) technical; (2) organizational; and (3) legal. However, practitioners also deal with other requirements and capabilities that research question four (RQ4) has showed. For example, IT contracts include terms regarding technical properties, financial factors, compliance restrictions, operational responsibilities, and contractual aspects in cloud computing.

In this contribution, cloud service dimensions are considered the basis for specifying cloud requirements and capabilities. The cloud dimensions are explained below.

Contractual Dimension . Contract trails specify stakeholders, disclaims, and general agreements between parties (i.e., “Supporting Party” and “Signatory Party”). This dimension covers all organizational aspects of cloud service level agreement. It includes actors (i.e., “Provider”, “Consumer”, “Broker”, “Carrier”, and “Auditor”), time periods and contract duration (i.e., attributes of “Contract”), and objects like binding in “Service Level Agreements” (SLA), similar to the information of business contractual headlines. Communication between actors is very important, thus contractual dimension also specifies roles, responsibilities, and relations between actors (i.e., “Term of Service”). “Umbrella Agreement” specifies all agreements and contracts with similar provider and characteristics. For the requirements elicitation of contractual dimensions, Bochicchi et al. [51] proposed an approach based on contract management process modeling and information modeling to extend the current generation of open contract management tools.

Financial Dimension . Economic aspects of cloud services are involved in “Billing”, “Pricing”, “Account” and “Credit”. This dimension is defined considering cloud computing as a utility [15], where economic and financial capabilities play a central role in cloud adoption [55]. Cloud service provider employs pricing plan (i.e., renting, usage-based pricing), in which cloud service consumers pay proportionally to the amount of time or resource they use [14]. This dimension involves all aspects of cloud agreements for billing, such as pay methods, credit management, and cost variables. Klems et al. [18] presented a framework to estimate cloud computing costs. For analyzing requirements of billing management, Iwashita et al. [49] represented some approaches based on the Soft Systems Methodology (SSM) with Unified Modeling Language (UML). Finally, “Penalty” is also part of this dimension, because it has always an economic impact.

Compliance Dimension . Regulations (i.e., “Guarantee” and “Remedy”) that restrict cloud services such as legal, standards, and proceedings. They describe all legal and regulatory restrictions for cloud service adoption [56], and it also specifies government regulation, business standards, security policy, and privacy certifications which cloud service should be compliant with [57]. The restrictions are part of “Policy” strictly imposed in order to respect laws and regulations in the place where data resides or is collected (i.e., “ Jurisdiction ”). “Remedy” involves “Penalty” when a “Policy” is violated. The consumer should pay attention to all requirement dimensions at a given time and describe in details some specifications about security, privacy, data manipulation, performance, and availability under “Policy” class. For instances, several approaches may be suitable for analyzing Compliance Dimensions. Mouratidis et al. [13] present a methodology that supports just elicitation and security of privacy requirements in cloud computing, by the understanding of the organizational context (i.e., goals, actors, tasks, resources, and plan) and the analysis of constraints, threats, and vulnerabilities [58]. Beckers et al. [41] contribute a catalog of security and privacy requirement patterns that support engineers in eliciting compliance requirements [31, 37]. Ficco et al. [42] present the development of a methodology that considers security concerns as an integral part of cloud-based applications design and implementation. Humberg et al. [39] developed an approach to represent regulations in the form of ontologies, which can then be used to examine a given system for compliance requirements in cloud computing.

Operational Dimension. All characteristics that cover specifications about service management, deployment, and access control . Operational Dimension is related to “Service Description”, “Virtual Resource” and “Physical Resource”. It is based on usual events (such as restore, maintain, configuration, and backups) and unusual events (such as incident management and recovery). By considering operational aspects, the cloud providers must have efficient means to support resource allocation and scheduling decisions to remain competitive [59]. Bao et al. [60] proposed a measurement method, which mainly measures availability and performance of cloud services and it supports operational decisions. Simultaneously, it is important to ensure the confidentiality of co-tenants who share the same infrastructure by auditing virtual behavior. Operative Dimension explains all aspects to keep the service running and meet the changes in runtime. In requirements engineering, Rimal et al. [12] classified architectural features according to the requirements of end users and provided key guidelines to software architects and cloud computing application developers for creating future architectures.

Technical Dimension . It encompasses functional properties and measurable aspects of cloud service. Some key performance indicators are measured using a set of measureable properties. Technical aspects are specified in SLA to understand, compare, and control SLA. Measurable and technical factors that need “Indicator”, “Metric”, “Measure”, “Unit”, “Collection Method”, and “Function”. “Service Level Objective” is used to compare “Current Value” audited by the “Monitor”. All technical aspects are requested to defined cloud services. For Technical Dimension and application requirements, Sun et al. [47] provided a framework for searching the cloud market for a set of products that meet those requirements, using ontologies. Zardari and Bahsoon [36] also proposed a process for cloud adoption considering cloud requirements and Goal Oriented Requirements Engineering (GORE).

There are a number of overlapping properties and classes within the five dimensions, such as “Monitor”, “Account”, and “Penalty”. “Monitor” is requested to ensure that cloud services do not break the laws and regulations in the jurisdiction where data resides or is collected, simultaneously ensuring the confidentiality of co-tenants who share the same infrastructure [54]. Thus, frequent audits should be performed on the dimensional properties to monitor compliance with security terms and to ensure adherence to agreements terms, performance standards, procedure, and regulations [61, 62]. Most of the time services are like “black boxes” to cloud consumers, so services are evaluated by their behavior (i.e., comparing its inputs, outputs, and performance level) with the expected results [58].

The service consumer, as a requirements engineer, may compare different methodologies (BPMN, UML, GoRE, SecureUML, Secure i*, Tropos, KAOS, and SQUARE) and present a conceptual framework with a strong focus on security and compliance for cloud computing. The consumer may also combine the approaches to come to the definition of the requirements, because some approaches may be focused on just few requirements engineering activities and different dimensions.

5 Sample Scenario: Sales Company

In this section, there is a sample about how to identify cloud dimensions. For example, a sales company (i.e., “Consumer” in Contractual Dimension ) has recently shown consistent growth, so it aims to reduce the workload of the organization by migrating the purchase and sales module to cloud computing. The goal is to let suppliers and customers interoperate through this module after exchanging security certificates. The module allows visualizing the available stock and book new orders in real time, without overloading the company infrastructure. This company expects to reduce its total costs by paying a service subscription price (“Pricing”) and to gain flexibility considering unlimited storage and network resources (i.e., “Service Description”). The requirements engineer uses a natural language description (e.g., something similar to the description just provided) as an input to specify the basic needs of his/her system. The engineer maps the terms of the expressed needs to the proposed conceptual model. Then, the conceptual model shows relationships with other concepts, which can be associated to additional dimensions that were not considered in the needs expressed by the requirements engineer at the beginning. For example, “Subscription Price” from the initial description is related to Financial Dimension . “Storage” and “Network” are related to Operational Dimension.

Other classes are implicit in the initial description, such as “Data Security”, “Ethical”, and “Law Regulation” that are linked to “Policy” in Compliance Dimension . At this stage, the requirements engineer can realize that other concepts (e.g., “Measure”, “Unit”, “Current Value”, etc.) in the model are related to his/her needs, and those concepts may have a relevant impact during the cloud service adoption, so he/she should pay considerable attention to them.

Finally, the company relies on the requirements engineering deliverable (e.g., supporting documents and descriptions) produced as a result of the proposed conceptual model. This deliverable helps the company to document initial requirements, to understand cloud services, to manage its dynamic requirements , to find inconsistency and risks, to compare cloud offers of different providers, and to contract the best cloud solution according to the company business goals and mission.

6 Conclusions

Summarizing, requirements engineering for cloud computing was investigated. Some primary studies were selected between 2009 and 2015, and only 26 filtered studies answered the proposed research questions. The literature review presented an overview about the topic and created new concerns about cloud requirements .

Cloud computing may be considered as a multidimensional paradigm, where different activities (i.e., elicitation, analysis, specification, validation/verification, and management), roles (i.e., consumer, provider, broker, auditor, carrier, user, analyst, consultant, manager, engineer, developer), and service dimensions (i.e., contractual, operational, technical, compliance, and financial) are integrated.

The cloud dimensions are explained in this chapter and a conceptual model integrated all of them. It is considered that the service consumer still needs to do some initial modeling and specification, because requirements have to be documented to ensure that the service provider offers exactly what is needed by the consumer. The service consumer should describe the required services, components, or applications using the dimensions. The dimensions are very complete and flexible for adding new features, so they can be the bases for future proposals, models, and ontologies.

Because the requirements change frequently, a streamline is needed. They should be monitored and traced using some traceability mechanisms (i.e., backward-from, forward-from, backward-to, or forward-to). Consequently, the requirements can undergo changes over the time and are normally covered under change management. A simple change in a requirement implies modifications in the parameters, configuration, and components, and the solution may no longer support the necessary functionality. In our future work, the objective is to give support to the complete requirement engineering process for cloud computing, by offering a framework to manage requirements in all dimensions and also support cloud adoption.