competitive pressure, and the general fast pace of development.
• Continuous change: Web applications change rapidly and are therefore subject to permanent
evolution due to constantly changing requirements or conditions (Scharl 2000). The rapid and never-ending change of Web technologies and standards in particular makes it necessary to continuously adapt Web applications to these. This has two reasons: users want the newest Web hype, and the used tools are also technology-driven. This constant change of requirements and conditions is a central characteristic of Web applications. Changes may concern all three dimensions of a Web application – the product itself, its usage, and, in particular, its development.
• Competitive pressure: The extremely high competitive pressure on the Web, the time-to-
market pressure and the necessity for a Web presence (comparable to the gold rush of the late 1840s (Murugesan 2000), increase the need for ever shorter product lifecycles and extremely short development cycles and apparently leave no room for a systematic development process. Immediate Web presence is considered more important than long- term perspective (Pressman 1998).
• Fast pace: The extreme time pressure on Web application development is due to the
rapid change on the Web and the accordingly short lifespans of Web applications or their frequency of updates. Tsichritzis sums it up very aptly in (Tsichritzis 2000): “either you are fast or irrelevant”.
While for conventional software, evolution takes place in a planned series of versions, it is continuous for Web applications. This means that Web applications are in permanent maintenance. The cycle of change is often no longer than a few days or weeks (Pressman 2005). Web applications therefore require “lean” versions of traditional Software Engineer- ing processes with special emphasis on requirements analysis and specification (Chapter 2) on the one hand and operation and maintenance (Chapter 8) on the other.
1.4
Objectives and Structure of the Book
The objectives of this book can be defined as follows:
• Provision of insight into current concepts, methods, techniques, tools, and experiences for an engineering approach to Web application development.
• Identification of similarities and differences between the development of traditional (non-Web-based) applications and the development of Web applications.
• Analysis of concepts, methods, techniques, and tools of traditional Software Engineering to see how suited they are for Web application development.
• Exploration of potential risks in Web application development. • Outlook on future developments in Web Engineering.
The structure of this book is based on that of the Guide to the Software Engineering Body
of Knowledge (SWEBOK, Bourque and Dupuis 2005), a compendium of the different activities
of traditional Software Engineering. These activities are also applicable to Web application development, although – as this book shows – the details and their sequence and schedule have
to be partly adapted in order to account for the categories and characteristics of Web applications discussed in sections 1.2 and 1.3.
The various characteristics of Web applications have a differing degree of influence on the distinct aspects of Web Engineering and make different demands on the concepts, methods, techniques, and tools. These characteristics have accordingly had an important influence on the structure of this book and the content of the individual chapters, and we have sought to present a comprehensive discussion of the subject of Web Engineering.
Table 1-1 depicts the influence of the characteristics of Web applications discussed in section 1.3 on the fields of Web Engineering addressed in this book. The individual chapters seek to provide a comprehensive discussion of the different requirements resulting from this variety of influences, and the solutions found in literature and practice.
Fig. 1-3 illustrates the structure of this book as parts of a house. The core chapters are shown as three pillars: Approach, Product Development and Quality Aspects. Chapter 1 is the foundation on which all other chapters are based. Chapter 14, Semantic Web, is the roof, with an outlook to the future.
Figure 1-3 Structure of the book.
This book can be read sequentially from front to back. However, the individual “pillars” can also be read as clusters, i.e. non-sequentially. For instance Chapters 9, Web Project Management, and 10, Process, belong together, because both concern the approach. They repeatedly address the individual development phases. The term “phase” is used in these chapters, as in the rest of the book, as a synonym for activity, i.e. the most important thing is not the sequence of the phases, but the goals and activities pursued within a given phase. Chapters 2, Requirements
1.4 Objectives and Structure of the Book 19 Engineering, and 3, Modeling, describe requirements and conceptual design. Based on this, Chapters 4, Architecture, 5, Technology-aware Design, and 6, Technologies, describe mainly technical aspects of Web applications. Chapter 6, Implementation Technologies, is in fact a pivotal chapter, as many of the other chapters refer to implementation technologies as well. Chapter 7 focuses on testing, particularly addressing compliance with both functional and non- functional requirements including troubleshooting. Three essential quality aspects are addressed in separate chapters; these are 11, Usability, 12, Performance, and 13, Security. Chapter 14, Semantic Web, is the final chapter, providing an outlook on the dimensions of future Web applications.
The appendix contains a glossary of relevant terms and biographical notes on the authors. A list of references for all chapters and an extensive index conclude the book.
All chapters have the following structural features in common: • An abstract describing the essence of the chapter.
• A section summarizing the general concepts of the activity in question.
• This is followed by a discussion of the particular features of the activity in question as applied to Web Engineering, taking into account the characteristics of Web applications. • The core of each chapter comprises current concepts, methods, techniques, and tools of
Web Engineering.
• Each chapter is concluded with an outlook on future development trends. The following is a summary of the contents of the individual chapters:
• In Chapter 2: Requirements Engineering, Gr¨unbacher describes the particular challenges for Requirements Engineering (RE) for Web applications. This includes unavailable stakeholders, dynamically changing conditions, deployment environments that are hard to predict, the particular importance of quality aspects, and the frequent lack of experience with technologies. Therefore, some important principles must be kept in mind when applying existing RE methods to Web Engineering, such as continuous involvement of important stakeholders, iterative identification of requirements and a constant focus on project risks during the development process.
• In Chapter 3: Modeling, Koch and Schwinger describe model-driven Web application development, with a focus on content and hypertext, as in most existing approaches. To date, there are hardly any concepts for the increasingly important consideration of context and the consequent adaptation of Web applications. The scope of existing methods for Web application modeling and their main emphases are presented. Three state-of-the-art modeling tools are introduced in order to help the reader choose an appropriate modeling method.
• In Chapter 4: Architecture, Eichinger claims that the quality of a Web application is decisively influenced by its architecture. Poor performance, inadequate maintainability and extensibility, and poor availability can often be attributed to an inadequate architec- ture. Using multi-layered, flexible architectures, providing for multimedia content, and integrating existing data repositories and applications are important factors in developing successful Web applications.
• While Chapter 3 discusses “model-driven” top-down development of Web applications, in Chapter 5: Technology-aware Design, the authors Austaller, Hartl, Lauff, Lyardet,
and M¨uhlh¨auser describe “technology-driven” bottom-up development as an alternative. Hypertext/hypermedia design, information design, and object-oriented software design cannot provide a satisfying solution on their own. Therefore, approaches for Web-specific design are needed. The following three levels should be distinguished: 1. Visual design, where the look and feel is determined and multi-modal user interfaces are considered, 2. Interaction design, where the navigational paths and the actual dialogue with the components are designed, and 3. Functional design, determining the “core” of the Web application. As the design of each level becomes more concrete, tools for hypertext, information, and software design must be applied.
• In Chapter 6: Technologies, Nussbaumer and Gaedke argue that it is necessary to know the characteristics of the technologies in question in order to know when it is appropriate to employ them. The implementation of Web applications often does not only require intimate knowledge of the different technologies, but also of their interaction within a given architecture. This chapter presents an overview of different technologies and illustrates their interplay and usage with a few selected architectural examples. The recommendations of the World Wide Web Consortium (W3C) are given special emphasis. • Chapter 7: Testing by Steindl, Ramler and Altmann, explains that current testing methods are largely focussed on the functional requirements of Web applications. A broad range of non-functional quality requirements important to users, such as usability, reliability, and security, however, are not given enough consideration. The testing schema presented here includes a wide range of quality characteristics of Web applications and promotes the understanding for a systematic, comprehensive, and risk-conscious approach to testing. • In Chapter 8: Operation and Maintenance, Ebner, Pr¨oll and Werthner explain that
important tasks that should be addressed during the design and development phase are often pushed off to the operation and maintenance phase with the argument that a Web application is an evolutionary process in permanent development. This does not solve the actual problem, but rather increases the already existing importance of operation and maintenance. This leads to a blurring of the boundaries between development and maintenance, as opposed to the more structured approach of conventional software applications. There is also a growing trend towards a high degree of automation of tasks while the system is operational. For instance, routine tasks for content maintenance are largely automated, thereby eliminating sources of error and guaranteeing a stable operation. • In Chapter 9: Project Management, Mayr introduces us to the relevance of a comprehen- sive perspective on the challenges for Web project management. Project management is a human activity designed to coordinate the actions of human beings. This human-centered approach requires a high degree of conflict-solving competence in Web project leaders and an interdisciplinary understanding in Web teams. The project plan for Web application development must accordingly be very flexible and permit highly iterative incremental development with frequent customer contact. Tools and methods of Web project man- agement are particularly characterized by the current transition from traditional software development methods to highly flexible approaches.
• Chapter 10: Process by Engels, Lohmann and Wagner discusses the possibility of using traditional software development processes for Web application development. They formulate six basic requirements for the development process. These requirements are used for the evaluation of the Rational Unified Process (RUP) and Extreme Programming
1.4 Objectives and Structure of the Book 21 (XP). Neither of these processes fulfills all requirements. The strengths of RUP lie in its adaptability to the degree of complexity of the application that is being developed. XP, on the other hand, can cope with short development times and new or changing requirements. • Chapters 11 (Usability), 12 (Performance), and 13 (Security) describe three aspects of quality of particular relevance to Web applications. In Chapter 11: Usability, Hitz, Leitner and Melcher emphasize that Web applications with poor usability are not accepted by the users. New developments such as mobile Web applications and special features for users with disabilities also put increasing demands on usability. This chapter shows that usability cannot always be achieved in one step but must be considered during the entire development process.
• In Chapter 12: Performance, Kotsis describes a range of methods from modeling methods for performance verification to measurement methods. Examples given for modeling methods are operational models, queuing networks, and general simulation models. Measurement approaches require access to an existing system and have the benefit that the system can also be observed under real load. If performance problems are identified through measuring or modeling, the next step is to improve performance (extending the hardware, software tuning, and caching or replication). In addition to the traditional analysis and improvement cycle, performance management is a new scientific approach with the objective of combining measuring, analytical, and improvement methods and automating their interaction.
• In Chapter 13: Security, Kemper, Seltzsam, and Wimmer argue that Web applications reveal certain characteristics that have to be taken into account when designing their security functionality, which demand even more comprehensive security techniques compared with other kinds of applications. The term security itself is quite abstract and service providers and clients of a Web application can have different notions of it. This, for example, includes privacy issues, the prevention of eavesdropping when messages are exchanged over publicly accessible channels, and the reliable provisioning of services.
• In Chapter 14: Semantic Web, Behrendt and Arora present the Semantic Web as the next logical evolutionary step of the Web. They identify three main pillars. Firstly, Web pages have to be extended either manually by the providers or through tools with semantic tags, i.e. pages must contain a machine-readable description of the content. Secondly, users searching for information must use some type of intelligent software agents capable of processing Web pages designed with this approach. And finally, content producers and software agents would have to agree on a common vocabulary of concepts, an ontology. Without doubt, the Semantic Web is still in its infancy, but surveys among researchers and technology experts in industry show that the dominating opinion is that these are very promising technologies which will heavily influence the working environment of “knowledge workers” in particular.
23
2
Requirements Engineering
for Web Applications
Paul Gr ¨unbacher
Requirements Engineering (RE) covers activities that are critical for the success of Web engineering. Incomplete, ambiguous, or incorrect requirements can lead to severe difficulties in development, or even cause the cancellation of projects. RE deals with the principles, methods, and tools for eliciting, describing, validating, and managing requirements. In Web engineering RE has to address special challenges such as unavailable stakeholders, volatile requirements and constraints, unpredictable operational environments, inexperience with Web technologies, the particular importance of quality aspects such as usability, or performance. Therefore, when adopting existing RE methods in Web engineering, several important principles should be kept in mind: the involvement of important stakeholders; the iterative identification of requirements; awareness of the system architecture when defining requirements; and consequent risk orientation.
2.1
Introduction
Requirements play a key role in the development of Web applications. However, requirements are often not described properly and may be specified in an ambiguous, vague, or incorrect manner. Typical consequences of poor requirements are low user acceptance, planning failures, or inadequate software architectures.
RE deals with the principles, methods, and tools to identify, describe, validate, and manage requirements in system development. Today, numerous RE methods and tools are available. However, these approaches are often not applied by practitioners and RE is often performed in an ad-hoc manner, particularly in Web engineering. Although the complexity of today’s Web appli- cations require a more systematic approach, the maturity of the RE process is often insufficient.
Defining requirements is definitely not a new problem. In 1976 in their article entitled Software
Requirements: Are They Really a Problem?, Bell and Thayer emphasize that requirements don’t
turn out automatically, but have to be identified in an engineering activity (Bell and Thayer 1976). In the early 1980s, Boehm studied the cost of defects in requirements and found that late removal of undiscovered defects is up to 200 times more costly than early identification and correction (Boehm 1981). In his article No Silver Bullet: Essence and Accidents of Software
Engineering, Brooks stresses that the iterative collection and refinement of requirements are the
There is a wide consensus about the importance of requirements for successful system development and over the years numerous standards, approaches, models, description languages, and tools have emerged. Nevertheless, the software industry is still struggling with massive difficulties when it comes to requirements:
• In a study conducted among 340 companies in Austria in 1995, more than two thirds of these companies regarded the development of a requirement document as a major problem in their development process. In addition, more than half of the companies perceived requirements management as a major problem (European Software Institute 1995). • A survey among more than 8000 projects conducted by the Standish Group showed that
30% of all projects failed before completion and 70% of the remaining projects did not meet the expectations of customers. In more than half of the cases, the observed problems were closely related to requirements, including poor user participation, incomplete or volatile requirements, unrealistic expectations, unclear objectives, and unrealistic schedules (The Standish Group 1994).
• According to a study on the development of Web applications conducted by the Cutter Consortium only 16% of the systems fully meet the requirements of the contractors, while 53% of the deployed systems do not satisfy the required capabilities (Cutter Consortium 2000).
While there is general consensus on the importance and value of RE to meet schedule, budget, and quality objectives, there are often problems in the concrete adaptation and use of available processes, elicitation methods, notations, and tools. This is particularly true for the development of Web applications as there is still little experience compared with other domains and requirements are thus often acquired, documented, and managed in a very unsystematic way.
This chapter discusses RE principles for Web application development and studies how existing RE methods can be adapted to the specifics of Web projects. The chapter is organized as follows: section 2.2 gives a brief introduction to RE and defines basic technical terms. Section 2.3 discusses RE challenges for the development of Web applications. Section 2.4 describes how the characteristics of Web applications can be considered in RE activities by following a set of key principles. Section 2.5 discusses the adaptation of RE methods and tools to Web projects. The chapter closes with a brief summary and discussion of research challenges.