D1.2

D1.2: Platform Requirements

As described in the proposal, the goal of the SPECS Project is to design a framework to provide security guarantees to cloud customers, by offering specific services to manage security parameters that can be negotiated, enforced and continuously monitored.
This objective will be implemented by exploiting two different innovative approaches: (i) security parameters will be negotiated, dynamically enforced and monitored with dedicated services to manage Service Level Agreements (SLAs) during their whole lifecycle, (ii) security will be provided as-a-Service to augment the security of existing public and private providers.
In particular, SPECS provides security services that act as an intermediary in the provisioning of cloud services, they play an active part in the provisioning of guaranteed services and different usage perspectives must be taken into consideration while designing the framework. The activities reported in this deliverable are related to Task 1.2 (Platform requirements); we first describe the adopted requirement analysis methodology, then we will focus our attention on the analysis of the SPECS Platform, one of the main components of the SPECS framework. Indeed, the requirement analysis of all SPECS components has been split among different tasks and Work Packages, and will be reported in different deliverables. So, to coordinate the overall requirement elicitation process, we defined a methodology that is described in this deliverable.
The methodology is based on well-known standards for software requirements analysis, to (i) collect different requirements from different perspectives and to (ii) merge all contributions, in order to (iii) identify the SPECS requirements that will be needed to provide SPECS services.
We started the analysis from the set of scenarios described in the Project proposal, considered of interest by the scientific community and by industrial partners. From these scenarios, we began to identify example applications (namely macro SPECS functionalities), to identify actors and understand how the main components should interact with one another.
The result of this activity is reported in eight Annexes to this document and has led to the definition of three high-level use case diagrams (cf. Section 4.2) that report the main macro-functionalities that SPECS should provide to its customers. These Use Cases involve all SPECS components and services, and are the basis to share service names, semantics and component interactions; this will enable us to propose a service taxonomy and main SPECS concepts that will be analysed and presented in details in the Tasks related to the SPECS architecture design.
Indeed, this deliverable is conducted in parallel with the architecture design, where the main SPECS concepts have been identified, and involve contribution from all partners actively working in the requirement analysis tasks related to SPECS core services. The methodology illustrated here will clarify how the results of this task will be used as inputs by the other tasks
on requirements.
Since this deliverable is the first one associated to requirement analysis, in Section 1 we provide an overview of the SPECS concepts and goals in order to present the SLA-based approach to security, we describe the main actors that interact with SPECS and different usage scenarios to understand the responsibilities of the SPECS owner in a cloud service supply chain. In Section 2 we clarify the tight relation and dependencies among all tasks and related deliverables dedicated to requirement analysis.
In Section 3 and Section 4 we respectively describe the adopted methodology and illustrate the identified high-level use cases, while Platform requirements are reported in details in Section 5. As illustrated, Platform requirements include specific functionalities and services needed to support the SLA life cycle management, involving Negotiation, Monitoring and Enforcement phases – these services have been named SLA Platform services -, and they also include base functionalities and services needed to manage all SPECS services (e.g., set up service, operate service, terminate service, and so on) – these services have been named Enabling Platform services.
Section 6 provides the taxonomy of all service categories that have been identified and, finally,
Section 7 draws some conclusions.