Requirements Engineering for Cloud Computing

Requirements Engineering for Cloud Computing

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 requirements engineering. This means eliciting optimum understanding of the customer’s requirements and implementing this into appropriate requirements of the solution to be realized. This contribution evaluates selected requirements engineering methods in terms of their applicability to the specific requirements of cloud-based solutions. Therefore a comparison framework containing the features of cloud computing is developed suitable for a structured comparison of different requirements engineering methods. This comparison framework is applied to four established process models for requirements engineering followed by recommendations for a requirements 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 requirements 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 requirements fields, it is necessary to make a distinction between specific and traditional requirements. 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’ requirements [4]. The success of cloud computing therefore depends on how

Stefan Wind, research assistant, research fields: cloud computing, requirements engineering, E-mail: [email protected].

Corresponding author: Holger Schrödl, research assistant, research fields: value chain management, cloud computing. E-mail: [email protected].

well customers’ and other stakeholders’ requirements and wishes are met. The basis for developing successful offers is a requirements engineering system adapted to cloud computing.

The success of development processes and projects essentially depends on whether the results meet the requirements of stakeholders (such as the customer, executive management, legislators, etc.). A central factor here is the implementation of an appropriate and professional requirements engineering tool [5-7]. Errors concerning the requirements 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 requirements engineering [9]. Moreover, studies carried out in a wide variety of domains (product development, software engineering, etc.) show that errors made while determining requirements have a major influence on the development process [10]. And the work and costs involved in eliminating the errors

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 requirements 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 requirements engineering models. In section 3, a comparison framework for requirements engineering in cloud computing is developed. In section 4, the comparison framework is applied to different requirements 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 requirements 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 requirements 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 requirements engineering process: description of initial situation and objectives, drawing up functional requirements, drawing up non-functional requirements, establishing risk acceptance, drawing up draft of life cycle and overall system architecture, analyzing quality of requirements, 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 requirements. Rather, only some of the requirements 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 requirements handling are made available to the contractor [16].

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 requirements 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, requirements 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 requirements, 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 requirements engineering and, besides techniques for determining requirements, also provide templates for structuring requirements specifications [19].

The approach is organized as follows:

y Motivation (the purpose of the project or product); y Restrictions and specifications for the project (conditions and assumptions);

y Functional requirements (such as Use Case models);

y Non-functional requirements (usability etc.);

y Project information (e.g., risks, costs, task lists). Volere provides users with a systematic, structured and very comprehensive requirements engineering template. All the information in the template is held in a single document (monolithic), conversely to RUP. In order to develop requirements, Volere prefers a requirements template. Quality assurance is an intermediate step (so-called gateway) which is used between requirements 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 requirements 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 requirements 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 requirements.

3. A Comparison Framework for

Requirements Engineering in Cloud

Computing

computing in order to develop a comparison framework for requirements 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 requirements 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 requirements analysis and agreement. During this phase the requirements 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 requirements 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 requirements.

The third characteristic is the formal documentation

and description of the requirements, and this represents the basis of all further activities [7]. Only once the requirements 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 requirements of the individual components to be used.

The first characteristic is considered to be the possibility of validating requirements. This is intended to check whether the documentation actually expresses the stakeholders’ requirements [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 requirements. 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 requirements engineering. It must be possible to elicit the requirements 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 requirements. These infra-structure requirements 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 requirements sources, which affect the requirements engineering process [3]. From this can be derived the following characteristics for requirements engineering models.

The first characteristic is a coordinated and integrated requirements 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 requirements 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,

interviews, scenario techniques, etc.) [7] is appropriate in equal extent for every type of source (customer, provider, etc.). In particular, when ascertaining requirements 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 requirements engineering in the development of cloud computing solutions.

4.1 V-Model

The V-model does not offer universal requirements 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 requirements [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 requirements 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

Cloud offer ing (Customer view p oint ) Support with ascertaining requirements (9) 9 9 9 Support with analysing and agreeing requirements 8 9 9 9 Cloud offer ing (Supplier v iewp o int) Validating requirements 9 9 8 9 Taking account of non-functional requirements 9 8 8 9 Management methods and change management (9) 9 8 9 Orches trat

ion Architectural _capability (9) 9 8 8 Structured elicitation of infrastructure requirements 9 8 8 (9) SaaS / Applicat ion Componen ts Coordinated and integrated RE for all single components of SaaS

8 8 8 8

Better customer integration into the RE-process (9) (9) 9 9 Consideration of changes of requirements after/during delivery 8 8 (9) (9) Consideration of the source of requirements during elicitation (9) 8 9 9 Consideration of the source of requirements during change management 8 9 (9) (9)

Key: 9 Characteristic met, (9) Characteristic partially met, 8 Characteristic not met.

determining non-functional requirements as a separate process step. Since the V-model is based on documentation [16], it also offers good support for requirements 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

integrated requirements engineering process for individual components, a change management process for the phase after delivery, and support for managing requirements 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 requirements engineering, including the consideration of non-functional requirements [17]. Nevertheless it cannot help in the SaaS framework, and particularly not in ascertaining the source of requirements. RUP is also lacking orchestration characteristics, particularly in its description of the agility of architecture requirements. 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 requirements after final delivery (e.g., in the form of a library). The capability to ascertain the source of requirements exists in principle, because the requirements 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 requirements is assisted by means of the planning game [21]. There is no support for requirements 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 requirements one of XP’s strengths. It is due to this shortfall in its options for offering opportunities to elicit agile architecture requirements, along with a structured elicitation of infrastructure requirements, 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 requirements engineering [19]. However, it has weaknesses in the area of SaaS. It does not support a coordinated and integrated requirements 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 requirements, 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 requirements agility. As expected, it fully supports the traditional tasks of requirements engineering such as eliciting, coordinating, prioritising and documentating, validating and managing requirements, and also considering the non-functional requirements.

5. Conclusions

established process models for requirements 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 requirements engineering for cloud computing. Existing shortfalls were identified, and, building on these, recommendations have been derived for cloud computing requirements 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 requirements engineering models but also more specific models.

This article represents a first step for requirements engineering in cloud computing. It is intended to set the foundation for a reference model for requirements 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.

[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.