Requirements Engineering for Cloud Computing

Journal of Communication and Computer 8 (2011) 707-715 Holger Schrödl and Stefan Wind Chair of Business Informatics and Systems Engineering, University of Augsburg, Augsburg 86159, Germany Received: March 24, 2011 / Accepted: May 10 2011 / Published: September 30, 2011. Abstract: Cloud computing gets increasingly established in industrial practice as an option for modeling cost-efficient and demand-oriented information systems. Despite the increasing acceptance of cloud computing within the industry many important questions remain unanswered. Issues related to the best architectures, legal issues and pricing models, suppliers of cloud-based solutions are faced with the question of appropriate engineering. This means eliciting optimum understanding of the customer s and implementing this into appropriate of the solution to be realized. This contribution evaluates selected engineering methods in terms of their applicability to the specific of cloud-based solutions. Therefore a comparison framework containing the features of cloud computing is developed suitable for a structured comparison of different engineering methods. This comparison framework is applied to four established process models for engineering followed by recommendations for a engineering system adapted to cloud computing. Key words: Requirements engineering, cloud computing, V-model, volere, XP, RUP. 1. Introduction While cloud computing has already found its way into industrial practice, there continue to be considerable deficits in the scientific basis [1]. One such shortfall is engineering for cloud computing. While some initial research initiatives have been carried out under the sub-domain of Software as a Service (SaaS) [2, 3], none has yet been carried out for cloud computing overall. Because of its specific characteristics and the various fields, it is necessary to make a distinction between specific and traditional. Forrester Research Consultants has investigated eleven different cloud computing vendor offers with regard to fields of application, costs and commercial benefits, and has drawn as conclusion: Many offers do not meet-or only partially meet-customers [4]. The success of cloud computing therefore depends on how Stefan Wind, research assistant, research fields: cloud computing, engineering, E-mail: Stefan.wind@wiwi.uni-augsburg.de. Corresponding author: Holger Schrödl, research assistant, research fields: value chain management, cloud computing. E-mail: holger.schroedl@wiwi.uni-augsburg.de. well customers and other stakeholders and wishes are met. The basis for developing successful offers is a engineering system adapted to cloud computing. The success of development processes and projects essentially depends on whether the results meet the of stakeholders (such as the customer, executive management, legislators, etc.). A central factor here is the implementation of an appropriate and professional engineering tool [5-7]. Errors concerning the are one of the main reasons why development projects fail [8]. Evidence of this is provided on a regular basis by the CHAOS study carried out by the American consultancy company, the Standish Group. In a recent study carried out in 2009 almost 48% of the problems or shortcomings in software development could be traced back to poor engineering [9]. Moreover, studies carried out in a wide variety of domains (product development, software engineering, etc.) show that errors made while determining have a major influence on the development process [10]. And the work and costs involved in eliminating the errors

708 increase disproportionately to the time at which they occur [11]. The reason for this is the early point in time within the process at which the are defined. It means than any errors occurring at that early stage will affect all the future phases (such as design, implementation etc.) [7]. In his error pyramid Leffingwell works on the basis that fixing an error at the implementation stage is up to 100 times more difficult, and at the maintenance stage, up to 1000 times more difficult than at the start of development stage [12]. Cloud computing is a subject in which, in general, company IT managers are showing a great deal of interest. According to the latest survey carried out by Sterling Commerce GmbH, a software supplier in Dusseldorf, 87% of all senior IT managers in Germany are planning to move to cloud-based information systems in the B2B sector [13]. The main driver of such considerations is the survey on cost pressures: most companies intend to reduce costs by implementing cloud-based IT structures, caused by services accounting dependent on utilisation. Other aspects are: improved deployment of in-house IT staff, a reduction in manual processes, and improvement to transparency of processes. However, when considering cloud-based systems, the most important feature is to be found in the areas of security and trust [14]. The paper is organized as follows: Section 2 discusses different engineering models. In section 3, a comparison framework for engineering in cloud computing is developed. In section 4, the comparison framework is applied to different engineering models to conduct a structured comparison. Section 5 concludes the paper and gives an outlook to future research. 2. Requirements Engineering Models Various process models were investigated within a broad literature research framework to find out the extent to which they are suitable to provide general support for engineering. To this end basically differing groups of models and approaches were identified, which have come about on the basis of different philosophies, traditions and viewpoints. This included a consideration of monumental and agile process models [15]. Added to these models are approaches developed especially for engineering purposes [6]. These claim to avoid the weaknesses of existing process models. 2.1 V Model The V model produced by the German Federal Ministry of Internal Affairs (BMI) is intended to support the execution of (software)- projects in every size [16]. The model is one of the most well known system development models in Germany [6]. It follows the concept of successively dividing the overall system, refining it down from the rough to the fine detail, until realizable components emerge. Requirements engineering is one of the fourteen activities included in the V model, each of which provides a recommendation for handling the execution of the various project management processes. The model distinguishes depending on the type of project certain decision points need to be met. The V model provides the following steps in the engineering process: description of initial situation and objectives, drawing up functional, drawing up non-functional, establishing risk acceptance, drawing up draft of life cycle and overall system architecture, analyzing quality of, drawing up scope of supply and acceptance criteria. The name given to this component is fairly misleading because not all activities are combined here in connection with. Rather, only some of the are considered, and the contracting client then summarizes these into a set of specifications. In this regard the component dealing with setting up the system is much more comprehensive, because in this case documents and activities for continued handling are made available to the contractor [16].

709 2.2 Rational Unified Process (RUP) The Rational Unified Process (RUP) is a software development process model and it consists of two process dimensions [17]. The time dimension indicates a sub-division into a rough structure (phases) and a refined structure (iterations). The second dimension is concerned with the technical side and divides these into disciplines, of which there are six primary process disciplines (including requirement) and three infrastructure disciplines. Each discipline has its own defined workflow. The engineering discipline pursues the objective of enabling reliable specifications and development, as well as modifications to a system. For example this means drawing up a uniform picture about the functionality that the system is to perform for all stakeholders, and creating a basis for estimating costs and time parameters [17]. Essentially, engineering in the RUP consists of the six following principle activities [18]: analyzing the problem, understanding the stakeholders needs, defining the system, managing the scope of the system, changing, refining the system definition. These activities are logically connected to one another and should not be viewed as being purely sequential. 2.3 Volere The Volere approach was developed by Atlantic Systems Guild and is derived from the Italian verb volere (to want, wish) [17]. The process was developed especially for engineering and, besides techniques for determining, also provide templates for structuring specifications [19]. The approach is organized as follows: Motivation (the purpose of the project or product); Restrictions and specifications for the project (conditions and assumptions); Functional (such as Use Case models); Non-functional (usability etc.); Project information (e.g., risks, costs, task lists). Volere provides users with a systematic, structured and very comprehensive engineering template. All the information in the template is held in a single document (monolithic), conversely to RUP. In order to develop, Volere prefers a template. Quality assurance is an intermediate step (so-called gateway) which is used between specification and analysis [19]. The process should also be considered as being iterative. 2.4 Extreme Programming (XP) XP was developed by Kent Beck, Ward Cunningham and Ron Jeffries and was launched in 1999 with the publication of their book: extreme Programming ex-plained [15]. Extreme Programming is a lightly-weighted development method which was positioned as a counter-movement to heavily-weighted methods such as the V-model [20]. XP pursued the objective of formulating software development projects more efficiently by slimming them down greatly and aligning them to the customer as well as to quality issues [21]. As with RUP, XP has an iterative and incremental character. At first glance XP and a fundamental analysis seem to contradict one another, but XP is concerned with getting an implementable system onto the market [15, 21]. However in this model too there are approaches that are well supplemented by analysis. These are User Stories, the Planning Game and the System Metaphor. For example, User Stories are short reports made by users, which are initially gathered together in an informal manner; details are gradually added and they are then evaluated. It is possible to consider these in comparison with. 3. A Comparison Framework for Requirements Engineering in Cloud Computing A classification system has been drawn up in cloud

710 computing in order to develop a comparison framework for engineering models, to provide optimum support in this area. In general we speak of a classification system if an object under consideration is first categorized according to certain characteristics, and the relevant specifications are determined for these characteristics [22]. No link is made between the various criteria [23]. Cloud computing makes use of a four-part conceptual model for the classification developed here (Fig. 1). 3.1 Characteristics Relating to the Cloud Offer, from the Customer s Viewpoint The topmost level of developing a Cloud offer from the customer s viewpoint does not differ greatly from the traditional software engineering field. For this reason, to develop a cloud offer, the following established characteristics from the software domain are significant. The first characteristic is understood to be the specification for the entire cloud offer, which is often subsumed under the term Requirements Elicitation [24]. This is important firstly in order to understand the background and motivation of the stakeholders, and secondly to understand the objectives that the cloud solution has to meet. The requirement specification must be supported by means of efficient techniques such as interviews, workshops, scenarios, as well as transaction analyses, and must be able to take into consideration several stakeholders at once [6, 8]. A crucial characteristic is the analysis and agreement. During this phase the need to be firmed and consensus obtained from all stake-holders. The model must therefore be in a position to deal with conflicts between the different types of requirement, to help to find the solution, and then to contribute towards producing a base supported by all stakeholders [8, 24]. This is particularly important due to the special situation in cloud computing, with many different stakeholders and, to an extent, competing. The third characteristic is the formal documentation Fig. 1 Conceptual cloud architecture.

711 and description of the, and this represents the basis of all further activities [7]. Only once the have been described is it possible to assign them to their various sources and monitor them. The documentation can be implemented in various ways, including essays, use cases or style guides [6]. 3.2 Characteristics Relating to the Cloud Offer, from Supplier s Viewpoint Suppliers of Cloud offers record the customer s offered within the Cloud, using them to implement a solution. For this reason the supplier must be able to formulate appropriately the of the individual components to be used. The first characteristic is considered to be the possibility of validating. This is intended to check whether the documentation actually expresses the stakeholders [25]. The validation process can be helped by using techniques such as reviews, check-lists, prototypes and walkthroughs. A further important characteristic is the capacity to take account of non-functional. Rupp stresses that this type of requirement is often forgotten, and is awarded less value than functional properties [6]. Meeting such criteria opens up many opportunities, such as satisfied customers, increased legal security, and more complete specifications. It is precisely in such complex structures as cloud computing that this is given great importance [24]. 3.3 Characteristics Relating to Orchestration Orchestration is of central importance when the Cloud offer is implemented [26]. It represents the connecting element between the individual application components, and can therefore be described as the implementation of the solution architecture. The first characteristic in this area is the architectural capacity of engineering. It must be possible to elicit the of complete information sys-tem architecture. In particular this includes support for formal modeling forms for information system architectures such as ARIS or UML [27]. A second characteristic is identified as being the structured elicitation of infrastructure. These infra-structure must be allocated into areas of service quality, security, and economic dimension [14]. 3.4 Characteristics Relating to SaaS and Applications Components Within the framework of developing SaaS it is necessary to take into account specific characteristics such as the integration of multi-discipline components from different domains, or different sources, which affect the engineering process [3]. From this can be derived the following characteristics for engineering models. The first characteristic is a coordinated and integrated engineering process for individual components such as software and services, which are mutually dependent upon one another during and after development [3, 6-7]. A crucial characteristic for the comparison framework is the comprehensive inclusion of the customer into the entire development process during every phase. Even where this can be difficult [28, 29], due to different language bases and differing levels of understanding by developers, this must not be abandoned. Third, in the framework of SaaS it is crucial to prepare an optimally functioning change management system for the phase following delivery, in order to be able to implement any modifications in the service area [3]. A clear traceability system for the when implemented is of special importance here in order to avoid undesirable counter-effects. A further important characteristic is the capacity to be able to elicit the source of the requirement when it is recorded. A more detailed differentiation is necessary be-cause not every elicitation method (workshops,

712 interviews, scenario techniques, etc.) [7] is appropriate in equal extent for every type of source (customer, provider, etc.). In particular, when ascertaining in the sense of a comprehensive view, it is necessary to consider every possible source, in order, as already mentioned, to assure traceability, validation and a functioning change management system. The above-mentioned capability is equally important within the change management framework. The reason for this is the two-way dependency of the system components, which can have an effect on software and services. These must therefore be considered carefully before making any changes. 4. Applying the Comparison Framework The characteristics deduced from the above paragraphs are set out in Table 1. It can be seen from the comparison that, at the current state of development, there is no universal and ideal support for engineering in the development of cloud computing solutions. 4.1 V-Model The V-model does not offer universal engineering support in the development of cloud computing solutions. A basic criticism here is that it is seen as the task of the contracting client to establish the [15]. Since the model is kept very general and is intended to cover any type of project [16], it fails to a large extent to provide support in SaaS. One of the indications of this is that there is no supra-disciplinary coordination of emanating from the software and service areas. Furthermore no support whatsoever is offered for change management in the phase following delivery; the core process of problem and change management is applied only while the project is in progress. The customer is partially included into the development process because it has to accept documents issued at the various phases of the project. A better picture emerges in the area of the total solution. On one hand the model aids the process of Table 1 Comparison framework. Area Characteristic V-Model RUP XP Volere Support with ascertaining ( ) Support with analysing and agreeing Validating Taking account of non-functional Cloud offering (Customer viewpoint) Cloud offering (Supplier viewpoint) Orchestration SaaS / Application Components Management methods and change ( ) management Architectural capability ( ) Structured elicitation of infrastructure ( ) Coordinated and integrated RE for all single components of SaaS Better customer integration into the ( ) ( ) RE-process Consideration of changes of ( ) ( ) after/during delivery Consideration of the source of ( ) during elicitation Consideration of the source of during ( ) ( ) change management Key: Characteristic met, ( ) Characteristic partially met, Characteristic not met. determining non-functional as a separate process step. Since the V-model is based on documentation [16], it also offers good support for documentation. 4.2 Rational Unified Process (RUP) Since RUP was originally designed for software development, it indicates system problems in other areas, such as in the service environment [18]. For this reason it is unable to offer universally optimum support for SaaS. For example, it lacks a coordinated and

713 integrated engineering process for individual components, a change management process for the phase after delivery, and support for managing after the development process is completed in full. It offers only partial support for the inclusion of the customer into the entire development process (this tending to be at the start of the project). In general, the model offers good support in the traditional areas of engineering, including the consideration of non-functional [17]. Nevertheless it cannot help in the SaaS framework, and particularly not in ascertaining the source of. RUP is also lacking orchestration characteristics, particularly in its description of the agility of architecture. 4.3 Extreme Programming (XP) The XP model, one of the most well-known representatives of agile methods [20], was originally used for software development. However, as opposed to RUP it offers better support for SaaS which can be traced back to the agile values on which it is based (e.g. strong weighting on customer). There is partial support for customer choices that go outside the boundaries of the domain, because XP provides for various roles such as customer, contracting Client etc.. Customer integration throughout the entire development process is one of XP s strengths and is supported by the On-site customer practice [21]. Because of XP s objective of delivering executable increments as fast as possible and then to consider the customer s feedback when planning the next increment, a rudimentary change management does take place after delivery. But this only applies up until the project has been concluded. For this reason it provides no management process for after final delivery (e.g., in the form of a library). The capability to ascertain the source of exists in principle, because the are often ascertained in a joint planning game. It offers the option of going into the source in explicit detail. However, in the change management process, consideration of the source is provided only partial. In the total solution area the defined characteristics are met only partially as a result of XP s properties. The elicitation of is assisted by means of the planning game [21]. There is no support for validation or for change management. Adaptations to the product are made only until the customer is satisfied. However, due to the specific characteristics of cloud computing, this appears to be difficult. Nor is considering the relevant architectural one of XP s strengths. It is due to this shortfall in its options for offering opportunities to elicit agile architecture, along with a structured elicitation of infrastructure, that XP indicates unsatisfactory possibilities for implementing RE for cloud computing. 4.4 Volere Compared with those described above, the Volere model was developed especially to handle engineering [19]. However, it has weaknesses in the area of SaaS. It does not support a coordinated and integrated engineering system beyond the domains, because this is not provided within the model. After delivery the model also offers partial support for change management by means of an active feedback system between customer and supplier. The, together with their sources, are collected into a library, and are also subject to rudimentary management after the development work is completed. But there is a lack of specific methods for efficient application. Other lacking areas are in the architecture capacity and in architecture agility. As expected, it fully supports the traditional tasks of engineering such as eliciting, coordinating, prioritising and documentating, validating and managing, and also considering the non-functional. 5. Conclusions The objective of this article was to validate

714 established process models for engineering in terms to their suitability for cloud computing. A comparison framework was developed on a broad literature study. This comparison framework covers 12 characteristics in four categories and represents an opportunity to compare process models in a structured manner. The V-model, RUP, XP and Volere process models were evaluated and discussed in more detail. The results enabled us to show that none of the established models is suitable to cover the needs of a specific engineering for cloud computing. Existing shortfalls were identified, and, building on these, recommendations have been derived for cloud computing engineering. Within the context of this article cloud computing is understood to be component-based applications development. Since the term cloud computing includes other aspects, the results are seen as limited. If the term cloud computing is extended to include the provision of infrastructure and application, the result could be that the comparison framework be expanded. A second limitation consists in the choice of the models under consideration. This might be extended to compare not only typical representatives of a particular type of engineering models but also more specific models. This article represents a first step for engineering in cloud computing. It is intended to set the foundation for a reference model for engineering for cloud-based solutions, which in practice will result in a considerable improvement in the development of customer-specific information systems based on cloud architecture. References [1] S. Leimeister, C. Riedl, M. Böhm, H. Krcmar, The business perspective of cloud computing: actors, roles, and value networks, 18th European Conference on Information Systems (ECIS), 2010. [2] M. Berkovich, S. Esch, J.M. Leimeister, H. Krcmar, Requirements engineering for hybrid products as bundles of hardware, software and service elements: a literature review, Internationale Tagung Wirtschaftsinformatik, Wien, Österreich, 2009. [3] M. Berkovich, S. Esch, J.M. Leimeister, H. Krcmar, Torwards Requirements Engineering for, Software as a Service, MKWI Göttingen, 2010. [4] Forrester, TechRadar for infrastructure & operations professionals, Cloud Computing, Forrester (2009). [5] U. Lindemann, Methodische Entwicklung Technischer Produkte: Methoden Flexibel UND Situationsgerecht Anwenden. 2. Aufl., Springer Verlag, Berlin, 2006. [6] C. Rupp, Requirements-Engineering UND Management, 4. Aufl., Carl Hanser Verlag, München, Wien, 2007. [7] K. Pohl, Requirements Engineering, 2. Aufl., dpunkt Verlag, Heidelberg, 2008. [8] A. Aurum, C. Wohlin, Engineering and Managing Software Requirements, Springer Verlag, Berlin, 2005. [9] Standish Group: CHAOS Report, available online at: http://www.standishgroup.com/, 2010. [10] T. Hall, S. Beecham, A. Rainer, Requirements problems in twelve software companies: an empirical analysis, IEE Proceedings Software 149 (2002) 153-160. [11] M. Berkovich, J.M. Leimeister, H. Krcmar, Ein Bezugsrahmen für Requirements Engineering hybrider Produkte, Multikonferenz Wirtschaftsinformatik, Göttingen, 2010. [12] H. Dörnemann, R. Meyer, Anforderung Management Kompakt Mit Checklisten, Spektrum Akademischer Verlag, Heidelberg, Berlin, 2003. [13] Sterling Commerce: 87 Prozent Deutscher Unternehmen Planen Investitionen in Cloud-Services, available online at: http://www.sterlingcommerce.de, 2010. [14] C. Weinhardt, A. Anandasivam, B. Blau, N. Borissov, Th. Meinl, W. Michalk, J. Stößer, Cloud-Computing-Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete, in: Wirtschaftsinformatik, 2009, pp. 453-462. [15] H. Balzert, Lehrbuch der Softwaretechnik: Softwaremanagement, 2. Aufl., Spektrum Akademischer Verlag, Heidelberg, 2008. [16] M. Reinhold, V-modell XT und anforderungen, in: Rupp, Chris (Hrsg.): Requirements-Engineering und Management, 4. Aufl., Carl Hanser Verlag, München, Wien, 2007. [17] H. Dörnemann, R. Meyer, Anforderungs Management Kompakt-mit Checklisten, Spektrum Akademischer Verlag, Heidelberg, Berlin, 2003. [18] G. Versteegen, A. Heßeler, C. Hood, C. Missling, R. Stücka, Anforderungs Management, Springer Verlag, Berlin u. a., 2004. [19] S. Robertson, J. Robertson, Mastering the Requirements Process, 2. Aufl., ACM Press Inc., 2006. [20] H. Wolf, S. Roock, M. Lippert, extreme Programming, 2. Aufl., dpunkt Verlag, Heidelberg, 2005.

715 [21] K. Beck, Extreme Programming Explained, Embrace Change, Addison-Wesley Reading, MA, 2000. [22] G. Engelien, Der Begriff der Klassifikation, Buske Verlag, Hamburg, 1971. [23] H. Knoblich, Die typologische Methode in der Betriebswirtschaftslehre, Wirtschaftswissenschaftliches Studium 1, 1972, pp.141-147. [24] I. Sommerville, G. Kotonya, Requirements Engineering: Processes and Techniques, Wiley & Sons, 1998. [25] B.H.C. Cheng, J.M. Atlee, Research Directions in Requirements Engineering, Future of Software Engineering, 2007. [26] S. Ried, Market Overview: The Middleware Software Market, Forrester, 2009. [27] M.A. Vouk, Cloud computing-issues, research and implementations, Journal of Computing and Information Technology 16 (2008) 235-246. [28] M. Abramovici, S. Schulte, Optimizing customer satisfaction by integrating the customer s voice into product development, ICED'07 Paris, France, 2007. [29] Agilemanifesto: Manifesto for Agile Software Development, available online at: http://www.agilemanifesto.org/, 2001.