Requirements Engineering for Service and Cloud Computing

Information system requirements are meant to communicate the relevant needs and intention to a wide range of stakeholders. The requirements form the basis on which the tenders are issued, projects are agreed upon, and service-level agreements are made. However, as the requirements state what the system owners—or the ones who are willing to pay for the system—want the system to achieve, they reflect the owners’ views and understanding. This setup is plagued by many weaknesses. First, the system owners are seldom experts in the information system design and therefore they may be unable to state all the relevant requirements comprehensively. Second, no matter how much energy and time is invested in the requirement definition and elicitation, many aspects of the requirements are only revealed during the development and deployment, and remain unforeseen until later on, when the development is well under way. Finally, the required system architecture cannot be appropriately designed, if we do not know the requirements at a sufficient level. In this chapter we reflect our experiences from participating in a number of large, commercial information system development projects in both public and private sectors in which the traditional way of handling the requirements has proven to be insufficient. With the software as a service (SaaS) business model, where the goal is frequent releases and continuous delivery of ever-improved services, the associated weaknesses become even more prominent. We propose better practices for specifying systems and suggest concentrating a lot more on the true communication and discussion, focusing always on the most important issues and most important stakeholders only and keeping the vision updated and clear for the whole duration of a system development project and also the system maintenance period.

Cloud computing is a business paradigm that changes the way to evaluate information systems and computing resources. Cloud requirements can rapidly change and new service capabilities are often requested in order to adapt to new business scenarios. The existing works are generally focused in a limited number of requirements and capabilities. The aim of this contribution is to understand the multifaceted components of a service and to give guidelines towards requirements engineering for cloud computing. Thus, cloud services are analyzed by different aspects called dimensions and five dimensions are proposed (i.e., Contractual, Financial, Compliance, Operation, and Technical). Cloud dimensions are graphically presented in conceptual models, because each dimension has specific entities, properties, and relationships. Different specialists and experts may be requested to evaluate particular dimensions in the service level agreement and cloud service adoption, and this approach can guide those activities, support requirements specification, and guide system analysis for cloud computing.

Cloud computing is a business paradigm, where cloud providers offer resources (e.g., storage, computing, network) and cloud consumers use them after accepting a specific service level agreement. Cloud requirements can rapidly change over time, so organizations need to count with rapid methods to elicit, analyze, specify, verify, and manage dynamic requirements in a systematic and repeatable way. The existing works of this field are generally focused in a limited number of requirements and capabilities for cloud services. This chapter aims to provide a comprehensive and systematic literature review of academic researches done in requirements engineering for cloud computing area. During this study, some approaches for cloud computing were found that considered a limited number of characteristics (e.g., security, privacy, performance) and few activities involving diverse stakeholders. Generally, cloud stakeholders have got neither guidelines nor standards to manage multiple aspects of services in cloud environments. Thus, a literature review was first conducted and five dimensions are discussed (i.e., Contractual, Compliance, Financial, Operational, and Technical) in order to classify cloud characteristics, specify requirements, and support cloud contracts. Different specialists and experts may be requested to evaluate particular dimensions in the service level agreement and cloud service adoption. Finally, a simple sample is given to illustrate how to identify the cloud dimensions.

With the rapid growth of functionally identical web services, Quality of Service (QoS) plays vital role for deciding the most suitable services for consumers. Although, QoS for web services has gained extensive attention in the literature, most of the existing efforts are unable to consider the multiperspective QoS of web services. Unlike conventional software paradigms, web services are provided, developed and used by different users such as provider, consumer and broker. As a result, QoS requirements vary from user to user. Existing researches are unable to provide standard solution, which can deal with what service providers, consumers and broker should expose in service description as QoS parameters. Therefore, in this book chapter, a multiperspective PCB-QoS classification of non-functional parameters along with new QoS parameters, i.e. access rate and Overall Aggregated Effective Quality of Service (OAEQoS) is presented. Due to the extensible nature of PCB-QoS classification, it can be extended to accommodate more number of QoS parameters. This QoS classification is based on the idea of partitioning the generic QoS parameters according to multi-user’s perspective. An Average Real Value Sum Method (ARSM) based on default priority constraints is also proposed for ranking of web services that uses the presented QoS classification. With the help of proposed approach, the user can specify the service requirements without taking the hurdle of specifying the weights for each QoS parameter during web service operations. It also prevents the services from malicious service provider to publish the incorrect and inaccurate QoS information. Experimental evaluation shows the effectiveness of proposed approach over the existing approach.

Without an iota of doubt, the overwhelming domain of requirements elicitation and engineering has been continuously and consistently evolving in order to catch up and match with the tricky and terrific expectations of producing and sustaining next-generation systems, solutions, and services. Especially in the hot and happening IT space and considering the growing complications of systems of engagements (SoE)-like applications, the aspect of requirements engineering is garnering a lot of attention and attraction. IT industry professionals and academic professors are working in unison in charting out easy-to-implement and use methods toward simplified requirements-gathering platforms, procedures, and practices. In this chapter, we would like to dig deeper and deal with the concept of software-defined clouds. Further on, the readers can read how requirements are being solicited and subjected to a variety of investigations before getting selected as sound and rewarding requirements for the right formation of software-defined clouds. We will also register the proven and promising approaches and articulations to speed up the process of simplifying and streamlining up the tasks associated with the requirements engineering activity.

The chapter focuses on an abstraction layer of SaaS architecture for multi-agent-based inter-cloud environment, called Enterprise Cloud Bus System (ECBS) to conceptualize the different behavioral facets of such system in service and cloud computing paradigm. The model is formalized using a set of high level Petri-net-based formal constructs called High Level Enterprise Cloud Bus Petri-net (HECBP) with varieties of relationship types among participation cloud bus components. It is accompanied with a rich set of Petri-net graphical notations and those are used to specify the effective toward modeling interactions among the heterogeneous agent present within the cloud bus of ECBS at conceptual level design of multi cloud system. The approach facilitates to analyze the behavioral features of inter-cloud architecture and modeled its dynamics at the conceptual level. The HECBP is also able to ensure correctness and performance of the system at design time by focusing on meeting the increasing demands for distributed software as a service and making the system functionality more scalable, configurable, and shareable. This chapter includes modeling of several behavioral facets like, fairness, boundedness, liveliness, safeness, etc., in a dead lock-free way. Moreover, this chapter provides a discussion on state-space analysis study, which further validates the theoretical analysis of HECBP model and future research scope in this area.

As the software industry is gradually moving toward the cloud computing in a fast pace, Service oriented architecture (SOA) is increasingly becoming more and more important, as far as the Software As a Service (SAAS) is concerned. As SOA applications are maturing, it becomes imperative to maintain the various versions of services published in the Enterprise Service Bus (ESB). However, for implementing a particular requirement, it may not always be cost-efficient, to use the latest version of the services. If a previous version matches the requirement, then that might be a cost-effective solution and enabling “reuse” to a larger extent can be a very useful method in cloud computing domain where pay per use is the accepted norm. In this chapter, we devise a comprehensive framework that models requirements in a formal manner and automatically extracts verbs to generate an activity model, which is then translated into BPMN notation based on a set of transformation rules. The BPMN nodes are mapped to services and an algorithm for dynamic discovery of appropriate service version is conceived. Thereafter we also verify the entire transformation process and ensure correctness by developing a traceability model and generate trace table to trace from requirements till services and apply it for a case study for substantiation of our approach.

Involvement of numerous stakeholders in cloud-based systems’ design and usage with varying degrees of nonfunctional requirements makes Architecturally Significant Requirements (ASRs) identification and management a challenge undertaking. The aim of the research presented in this chapter is to identify different types of design-time and run-time ASRs of the cloud-based systems, provide an ASRs classification scheme and present a framework to manage the requirements’ variability during life cycle of the cloud-based systems. We have used a multifaceted research approach to address the ASRs identification, classification, and change management challenges. We have explored findings from systematic as well as structured reviews of the literature on quality requirements of the cloud-based systems including but not limited to security, availability, scalability, privacy, and multi-tenancy. We have presented a framework for requirements classification and change management focusing on distributed Platform as a Service (PaaS) and Software as a Service (SaaS) systems as well as complex software ecosystems that are built using PaaS and SaaS, such as Tools as a Service (TaaS). We have demonstrated applicability of the framework on a selected set of the requirements for the cloud-based systems. The results of the research presented in this chapter show that key quality requirements of the cloud-based systems, for example, multi-tenancy and security, have a significant impact on how other quality requirements (such as scalability, reliability, and interoperability) are handled in the overall architecture design of a cloud-based system. It is important to distinguish tenant-specific run-time architecturally significant quality requirements and corresponding cloud-based systems’ components so that run-time status of the tenant-specific architecture quality requirements can be monitored and system configurations can be adjusted accordingly. For the systems that can be used by multiple tenants, the requirements change management framework should consider if the addition or modification (triggered by a specific tenant) of a quality requirement can impact quality requirements of other tenants, and whether or not a trade-off point should be introduced in the architecture (corresponding to the requirements). The trade-off point can also be referred as a variability point, that is, a compromise has to be made among the number of quality requirements and only some of the requirements can be satisfied. System analysts and software architects can use the proposed taxonomy and the management framework for identifying relevant quality requirements for multi-tenant cloud-based systems, for analyzing impact of changes in the requirements on the overall system architecture, and for managing variability of the architecturally significant requirements.

Virtually every connected system will be attacked sooner or later. This holds specifically for cloud-based services and systems. A 100% secure solution is not feasible. Therefore, advanced risk assessment and mitigation is the order of the day. Risk-oriented security engineering helps in both designing for robust systems as well as effective mitigation upon attacks or exploits of vulnerabilities. Security must be integrated early in the design phase to understand the threats and risks to expected functionality. The security analysis provides requirements and respective test vectors so that adequate measures can be derived for balancing security costs and efforts. This book chapter provides experience and guidance concerning how information security can be successfully achieved with a security requirements engineering perspective. Our experiences from embedded security in critical IT systems show that security is only successful with a systematic understanding and handling of security requirements and their interaction with functional requirements. Four requirements engineering-related levers for achieving security are addressed: security requirements elicitation, security analysis, security design, and security validation. We will show for each of these levers how security is analyzed and implemented. A case study from automotive systems will highlight concrete best practices. Only systematic and disciplined security requirements engineering will ensure that security needs are met end to end from concept to architecture to verification and test and—most relevant—operations, service, and maintenance.

Service-Oriented Requirements Engineering (SORE) plays a significant role in eliciting, specifying, and validating service requirements that will be developed by Web service technology. With the increasing complexity of users’ requirements, Web services need to be combined together to fulfill them. The process of building new value-added services by integrating sets of existing Web services to satisfy users’ requirements is called Web Service Composition (WSC). The main objective of WSC is to develop composite services to satisfy users’ requirements, which does not only include Functional Requirements (FR), but also Non-Functional Requirements (NFR). One of the main challenges of WSC is how it deals with dynamic environments. Since the Web service properties and composition requirements are frequently changeable, this demands that SORE activities must be equipped with a self-adaptation mechanism to provide the most appropriate composite services and satisfy users’ requirements emerged. Self-adaptation occurs in either a proactive or reactive manner. In this chapter, we appraise and analyze existing reactive adaptation research that deals with the problem of WSC in a dynamic environment in order to identify the research gaps in this field. These approaches are classified into three categories: used of variability models, context-awareness, and multi-agent approaches. Most of these approaches are not able to deal with continuous and unanticipated changes in complex uncertain contexts because they need to define the contexts in design time. It is usually difficult to predict all of the possible situations that might arise in an uncertain environment.

Specifying functional requirements brings many difficulties namely when regarding the cloud services. During the analysis phase, the alignment between the process-level requirements (information systems) with the product-level requirements (service-based software) may not be properly achieved or even understood. In this chapter, we describe an approach that supports the creation of the intended requirements, beginning in a process-level and evolving to a product-level perspective, to elicit requirements for specifying services that execute in a cloud computing environment. The transition between perspectives are supported by UML model transformations, encompassing a set of transition rules using QVT, from one perspective to the other, in order to assure that process- and product-level requirements are aligned.

Quality of Service (QoS)-aware web service composition is based on nonfunctional properties of component (or partner) web services. In a dynamic environment, these properties of partner web services change on the fly. There exist several research proposals that take into account QoS degradation of partner web services at run-time, and propose solutions to maintain the optimality of the service composition in such circumstances. In this paper, we focus on the problem from a different perspective. We take into account the situation when quality (QoS values) of some of the partner web services improves, but for some others it remains the same. With the passage of time, if the quality of these web services does not improve, they act as bottlenecks or the weakest links in an otherwise efficient process. We simulate a framework which identifies such web services, and expands the search domain by sending a selective query to remote/premium service registries/brokers for finding better alternatives of such services. The proposed approach is effective, efficient, and scalable as well.

This chapter discusses the challenges practitioners face while choosing to develop their projects at offshore locations. As offshore development introduces new challenges in the software development process such as trust, socio-cultural, communication and coordination and knowledge transfer issues, it has been observed that these challenges affect how requirements are defined and managed while using agile practices in offshore software development. Using the notions of Distributed Agile Patterns we discuss how they can facilitate the requirements engineering process in offshore software development. We present a catalogue of the complete set of patterns, but only gave details of selective patterns from the catalogue that are related to the requirements engineering process. The whole catalogue is available online for anyone interested in it. At the end we developed a process flow showing the distributed agile patterns mapped onto the traditional requirements engineering process to show how these patterns address and improve the requirements engineering process for agile offshore projects.