The Rational Unified Process (RUP) is a software development process model and it ... Essentially, requirements engineering in the RUP consists of the six.
Requirements Engineering for Cloud Computing: A Comparison Framework Stefan Wind and Holger Schrödl University Augsburg, Business Informatics and Systems Engineering, Universitätsstrasse 16, 86159 Augsburg, Germany {Stefan.Wind,Holger.Schroedl}@wiwi.uni-augsburg.de
Abstract. In industrial practice, cloud computing is becoming increasingly established as an option for formulating cost-efficient and needs-oriented information systems. Despite the increasing acceptance of cloud computing within the industry many important questions remain unanswered, or are answered only partially. Besides issues relating 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 realised. This article examines selected, established requirements engineering methods in order to study the extent to which they can be applied to the specific requirements of cloud-based solutions. Furthermore, it develops a comparison framework containing the features of cloud computing. This comparison framework is applied to four established process models for requirements engineering. Recommendations for a requirements engineering system adapted to cloud computing are derived. Keywords: Requirements Engineering.
Engineering,
Cloud
Computing,
System
1 Introduction While cloud computing has already found its way into practice, there continue to be considerable deficits in the scientific basis [1]. One such shortfall is requirements engineering for cloud computing - as a separate unit with its own various domains. While some initial research initiatives have been carried out under the sub-domain of Software as a Service (SaaS) (c.f. [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 these 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 a sobering conclusion: many offers do not meet - or only partially meet - customers’ requirements [4]. The success of cloud computing therefore depends a great deal on how well customers’ and other stakeholders’ D.K.W. Chiu et al. (Eds.): WISE 2010 Workshops, LNCS 6724, pp. 404–415, 2011. © Springer-Verlag Berlin Heidelberg 2011
Requirements Engineering for Cloud Computing: A Comparison Framework
405
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], [6], [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 and more wide-ranging 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].
2 Requirements Engineering Models Various process models were investigated within a 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.
406
S. Wind and H. Schrödl
2.1 V Model The V model produced by the [German] Federal Ministry of Internal Affairs (BMI) is intended to enable the execution of (software) projects both small and large [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 realisable 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 according to the type of project: depending on the type of project certain decision points need to be met. In principle 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, Establish risk acceptance, Draw up draft of life cycle and overall system architecture, Analyse quality of requirements, Draw 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 summarises 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]: Analyse the problem, Understand the stakeholders’ needs, Define the system, Manage the scope of the system, Manage changing requirements, Refine 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 for Cloud Computing: A Comparison Framework
407
requirements engineering and, besides techniques for determining requirements, also provide templates for structuring requirements specifications [19]. The approach is organised according to the following points: • • • • •
Motivation (the purpose of the project or product, user, customer etc.) Restrictions and specifications for the project (conditions and assumptions) Functional requirements (such as Use Case model, data requirements) Non-functional requirements (usability, maintainability, legal requirements, etc.) Project information (e.g. risks, costs, task lists)
Volere provides users with a systematic, structured and very comprehensive requirements engineering template. As opposed to RUP all the information in the templates is held in a single document (monolithic); conversely, the RUP provides several documents (so-called artefacts), each containing relevant information. In order to develop requirements, Volere prefers a requirements template. Quality assurance is an intermediate step (socalled 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 explained” [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 effectively and 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 A classification system has been drawn up in cloud 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 categorised according to certain characteristics, and the relevant
408
S. Wind and H. Schrödl
specifities 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).
Fig. 1. Conceptual Cloud Architecture
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], [24]. A crucial characteristic is the requirements analysis and agreement. During this phase the requirements need to be firmed and consensus obtained from all stakeholders. 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
Requirements Engineering for Cloud Computing: A Comparison Framework
409
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 requirements and implement them into a specific solution. The idea of cloud computing necessitates that the supplier does not actually produce the entire offer himself, but makes use of the services and components 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 walk-throughs. 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. The third characteristic is the existence of a change management system, which verifies any changes in requirements and examines them for any possible effects on existing requirements [24]. Assurance must be given that changes are documented and analysed and any additional costs that may arise are checked in advance. It should be mentioned here that this criterion differs from change management in the SaaS domain, because it is aimed at changes occurring during project implementation, while with SaaS, the focus is on changes made after the project is complete. 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 system architecture. In particular this includes support for formal modelling forms for information system architectures such as ARIS or UML. The second characteristic is the agility of requirements engineering in relation to the description of architecture
410
S. Wind and H. Schrödl
requirements. A component-based architecture is distinctive for aspects such as reusability, replaceability, extendability and scalability [27]. A third characteristic is identified as being the structured elicitation of infrastructure requirements. These infrastructure 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. A further characteristic is the appropriate selection by stakeholders within the development framework, because they have a crucial influence over the success of a target-oriented development project [6], [7]. It is necessary to pay particular attention to supra-disciplinary coordination of requirements emanating from the software and service areas [3]. 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], due to different language bases and differing levels of understanding by developers, this must not be abandoned. Fourthly, 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. Once development is completed, a clean requirements management system will include, besides the objective of assuring traceability and validation, a careful statement of the requirements sources. Only thus is it possible to interpret this correctly in its context, even later on. 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 because 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.
Requirements Engineering for Cloud Computing: A Comparison Framework
411
4 Applying the Comparison Framework The characteristics deduced from the above paragraphs are set out in table 1. Table 1. Comparison Framework Characteristic
V Model
RUP
(9)
9
9
9
Support with analysing and agreeing requirements
8
9
9
9
Support with documentation and prioritisation
9
9
(9)
9
Validating requirements
9
Taking account of non-functional requirements
9
Management methods and change management
Architectural capability
SaaS / Application Components
Cloud offering (Supplier viewpoint)
Support with ascertaining requirements
Orchestration
Cloud offering (Customer viewpoint)
Area
Volere
8
9
8
8
9
(9)
9
8
9
(9)
9
8
8
Agility in relation to architecture requirements
8
8
8
8
Structured elicitation of infrastructure requirements.
9
8
8
(9)
Coordinated and integrated RE for all single components of SaaS
8
8
8
8
Selection of the right stakeholders
8
(9)
(9)
9
(9)
(9)
9
9
Consideration of changes of requirements after/during delivery
8
8
(9)
(9)
Thorough and continuous documentation of requirements
8
8
8
(9)
(9)
8
9
9
8
9
(9)
(9)
Better customer integration into the RE-process
Consideration of the source of requirements during elicitation
Consideration of the source of requirements during change management
9
XP
Key: 9 Characteristic met, (9) Characteristic partially met, 8 Characteristic not met.
412
S. Wind and H. Schrödl
It can be seen from the comparison that, at the current state of development of the various process models and approaches, there is no universal and ideal support for requirements engineering in the development of cloud computing solutions. 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]. For this reason the model does not provide for stakeholders’ choices that may extend beyond system limits, but this is extremely important in SaaS. 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 the fact that there is no supradisciplinary 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 further point of criticism is the lack of agility in describing changing architecture requirements. A better picture emerges in the area of the total solution. On one hand the model aids the process of 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. However, its strict rules create a disproportionate amount of work. 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 selection of appropriate stakeholders beyond domain boundaries and 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 in the area of orchestration characteristics, particularly in its description of the agility of architecture requirements. Like the RUP model, 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). Yet XP still does not offer a coordinated and integrated RE for individual components. 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
Requirements Engineering for Cloud Computing: A Comparison Framework
413
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 in part, and in the main this lies with the customer. In the total solution area, because of the system, 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. However XP does not provide sufficient support for documenting requirements, because documentation is produced only in the form of user stories (in principle executable code is prioritised higher than documentation [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 the implementation of RE for cloud computing. 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. On the other hand it does support stakeholders’ selections beyond domain boundaries in the form of a special stakeholder management section. This also includes stakeholder integration throughout the entire development process, and this is indicated by frequent stakeholder interaction provided for in 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 Conclusion and Future Work The objective of this article was to validate established process models for requirements engineering in regard to their implementation for cloud computing. A comparison framework was developed on the basis of a study of the available literature. This comparison framework covers 16 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 on the comparison framework, and then discussed in more detail. The results enabled us to show that
414
S. Wind and H. Schrödl
none of the established models is suitable to cover in full the needs of 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 componentbased 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. Typical representatives of a particular type of requirements engineering models were selected for consideration. This choice is intended to represent a class of requirements engineering models. An extension to the area of consideration in the sense of validating the comparison framework could result in further findings. 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. Leimeister, S., Riedl, C., Böhm, M., Krcmar, H.: The Business Perspective of Cloud Computing: Actors, Roles, and Value Networks. In: 18th European Conference on Information Systems, ECIS (2010) 2. Berkovich, M., Esch, S., Leimeister, J.M., Krcmar, H.: Requirements engineering for hybrid products as bundles of hardware, software and service elements – a literature review. In: 9. Internationale Tagung Wirtschaftsinformatik, Wien, Österreich (2009) 3. Berkovich, M., Esch, S., Leimeister, J.M., Krcmar, H.: Torwards Requirements Engineering for Software as a Service. MKWI Göttingen (2010) 4. Forrester: TechRadar For Infrastructure & Operations Professionals: Cloud Computing. Forrester, Q3 (2009) 5. Lindemann, U.: Methodische Entwicklung technischer Produkte: Methoden flexibel und situationsgerecht anwenden. In: 2. Aufl.. Springer, Berlin (2006) 6. Rupp, C.: Requirements-Engineering und Management – Professionelle, iterative Anforderungsanalyse für die Praxis. In: 4. Aufl. Carl Hanser Verlag, München (2007) 7. Pohl, K.: Requirements Engineering – Grundlagen, Prinzipien, Techniken. In: 2., Korr. Aufl. dpunkt Verlag, Heidelberg (2008) 8. Aurum, A., Wohlin, C.: Engineering and Managing Software Requirements. Springer, Berlin (2005) 9. Standish Group: CHAOS Report, http://www.standishgroup.com/ 10. Hall, T., Beecham, S., Rainer, A.: Requirements problems in twelve software companies: an empirical analysis. IEEE Proceedings Software 149, 153–160 (2002) 11. Berkovich, M., Leimeister, J.M., Krcmar, H.: Ein Bezugsrahmen für Requirements Engineering hybrider Produkte. Multikonferenz Wirtschaftsinformatik, Göttingen (2010) 12. Dörnemann, H., Meyer, R.: Anforderungsmanagement kompakt – mit Checklisten. Spektrum Akademischer Verlag, Heidelberg (2003)
Requirements Engineering for Cloud Computing: A Comparison Framework
415
13. Sterling Commerce: 87 Prozent deutscher Unternehmen planen Investitionen in CloudServices. Pressemitteilung vom 11.02.2010, http://www.sterlingcommerce.de 14. Weinhardt, C., Anandasivam, A., Blau, B., Borissov, N., Meinl, T., Michalk, W., Stößer, J.: Cloud-Computing - Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete. In: Wirtschaftsinformatik, Jg. 51, H. 5, pp. 453–462 (2009) 15. Balzert, H.: Lehrbuch der Softwaretechnik: Softwaremanagement. In: 2. Aufl. Spektrum Akademischer Verlag, Heidelberg (2008) 16. Reinhold, M.: V-Modell XT und Anforderungen. In: Rupp, C. (Hrsg.) RequirementsEngineering und Management – Professionelle, iterative Anforderungsanalyse für die Praxis. 4. Aufl., Carl Hanser Verlag, München (2007) 17. Dörnemann, H., Meyer, R.: Anforderungsmanagement kompakt – mit Checklisten. Spektrum Akademischer Verlag, Heidelberg (2003) 18. Versteegen, G. (Hrsg.), Heßeler, A., Hood, C., Missling, C., Stücka, R.: Anforderungsmanagement – Formale Prozesse, Praxiserfahrungen, Einführungsstrategien und Toolauswahl. Springer, Berlin (2004) 19. Robertson, S., Robertson, J.: Mastering the Requirements Process. In: 2. Aufl. ACM Press Inc., New York (2006) 20. Wolf, H., Roock, S., Lippert, M.: eXtreme Programming – Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis. In: 2., akt. u. erw. Aufl. dpunkt Verlag, Heidelberg (2005) 21. Beck, K.: Extreme Programming Explained. Embrace Change. Addison-Wesley, Reading (2000) 22. Engelien, G.: Der Begriff der Klassifikation. Buske Verlag, Hamburg (1971) 23. Knoblich, H.: Die typologische Methode in der Betriebswirtschaftslehre. Wirtschaftswissenschaftliches Studium 1, 141–147 (1972) 24. Sommerville, I., Kotonya, G.: Requirements Engineering: Processes and Techniques. Wiley & Sons, Chichester (1998) 25. Cheng, B.H.C., Atlee, J.M.: Research Directions in Requirements Engineering. In: Future of Software Engineering (2007) 26. Ried, S.: Market Overview: The Middleware Software Market. Forrester (2009) 27. Vouk, M.A.: Cloud Computing – Issues, Research and Implementations. Journal of Computing and Information Technology 16, 235–246 (2008) 28. Abramovici, M., Schulte, S.: Optimising customer satisfaction by integrating the customer’s voice into product development. In: ICED 2007, Paris, France (2007) 29. Agilemanifesto: Manifesto for Agile Software Development, http://www.agilemanifesto.org/
