How does RE for Web engineering differ from RE for conventional software systems? On the surface, the differences seem to be negligible as argued by researchers in the field: “While there are many differences between Web development and software development [. . .] there are also
similarities between them. These include [. . .] requirements elicitation [. . .]” (Deshpande et al.
2002). However, if we take a closer look at some specifics, differences become apparent. The following subsections explore these by using the characteristics of Web applications discussed in Chapter 1 (Lowe 2003).
2.3 RE Specifics in Web Engineering 27
Multidisciplinarity
The development of Web applications requires the participation of experts from different disciplines. Examples include multimedia experts, content authors, software architects, usability experts, database specialists, or domain experts. The heterogeneity and multidisciplinarity of stakeholders make it challenging to achieve consensus when defining requirements. This problem is compounded as the people from different disciplines have their own languages and jargons that need to be reconciled.
Unavailability of Stakeholders
Many stakeholders, such as potential Web users, are still unknown during RE activities. Project management needs to find suitable representatives that can provide realistic requirements. For example, there is often a wide spectrum of possible users in Web projects and finding a reasonable set of representatives is hard.
Volatility of Requirements and Constraints
Requirements and constraints such as properties of deployment platforms or communication protocols are often easier to define for conventional software systems than for Web applications. Web applications and their environments are highly dynamic and requirements and constraints are typically harder to stabilize. Frequent examples of changes are technology innovations such as the introduction of new development platforms and standards, or new devices for end users. Unpredictable Operational Environment
The operational environment of a Web application is also highly dynamic and hard to predict. Developers find it hard or impossible to control important factors that are decisive for the user- perceived quality of a Web application. For example, changing bandwidths affect the response time of mobile applications but are outside the sphere of the development team (Finkelstein and Savigni 2001).
Impact of Legacy Systems
The development of Web applications is characterized by the integration of existing software components such as commercial off-the-shelf products or open source software. In particular, Web developers frequently face the challenge to integrate legacy systems, for example when making existing IT systems of a company accessible through the Web (see Chapter 1). Developers are often asked to use existing components for economic reasons. The components that need to be integrated strongly influence the requirements and architectural style of the future system (see Chapter 4). Under such circumstances a waterfall approach to derive the system architecture from requirements will not succeed, as existing components, services, and the infrastructure define the range of possibilities and limitations for the developers. This means that, when identifying and defining requirements, Web developers have to be aware of the system architecture and
architectural constraints. An iterative approach as proposed in the Twin Peaks model (see Figure 2-1) is more appropriate in such a context.
Implementation Dependency Level of Detail Requirements Architecture Specification low low high high
Figure 2-1 The Twin-Peaks model (Nuseibeh 2001).
Significance of Quality Aspects
Quality aspects are decisive for the success of Web applications (Gr¨unbacher et al. 2004). Examples include the performance of a Web application (see Chapter 12), security as in e-commerce (see Chapter 13), availability, or usability (see Chapter 11). Despite the significance of quality aspects, developers have to deal with the problem that an exact specification of quality requirements is often hard or even futile before the actual system is built. For example, the response time of a Web application depends on many factors that are outside the control of the development team. A feasible approach for defining quality requirements is to specifying criteria for the acceptance test indicating whether or not a requirement has been met (see also an example of an acceptance criterion for a quality requirement in Table 2-1).
Quality of the User Interface
The quality of the user interface is another success-critical aspect of Web applications. When developing Web applications developers need to be aware of the IKIWISI (I Know It When I See It) phenomenon: users will not be able to understand and evaluate a Web application by just looking at abstract models and specifications; rather they need to experiment with it. It is thus absolutely essential to complement the definition and description of requirements by adding prototypes of important application scenarios (Constantine and Lockwood 2001). Chapter 11 is dedicated to the usability of Web applications and discusses the requirements analysis from the usability perspective.
2.3 RE Specifics in Web Engineering 29 Table 2-1 Formatted specification
Attribute Comment Example
Id Unique identifier 1.2.5
Type Element from the
requirement taxonomy
Learnability
Description Short explanation in
natural language
Web application X should be usable by occasional Web users without additional training.
Rationale Explaining why the
requirement is important.
Marketing managers are frequent users of the system.
Acceptance criterion A measurable condition,
which has to be met upon acceptance.
90% of the members of a randomly selected test group of occasional Web users can use the Use Cases 2.3, 2.6, 2.9, and 2.11 without prior training.
Priority An expression of the
importance and the feasibility of the requirement.
Very important; hard to implement
Dependent requirements List of requirements that
depend on this requirement.
1.2.7, 2.3.4, 2.3.6.
Conflicting requirements List of requirements that
are in conflict with this particular requirement.
4.5.6
Further information References to further
information.
Usability Guidelines v1.2
Version history A number of the revision to
document the development history.
1.06
Quality of Content
Many traditional RE methods neglect Web content, though it is an extremely important aspect of Web applications. In addition to software technology issues, developers have to consider the content, particularly its creation and maintenance. In the context of RE, it is particularly critical to define the required quality of content. Important quality characteristics include accuracy, objectivity, credibility, relevance, actuality, completeness, or clarity (Strong et al. 1997). Content management systems (CMS) gain importance and allow representing content concisely and consistently by separating content from layout, and offering content editing tools.
Developer Inexperience
Many of the underlying technologies in Web applications are still fairly new. Inexperience with these technologies development tools, standards, languages, etc. can lead to wrong estimates when assessing the feasibility and cost of implementing requirements. See also Chapter 1 and section 9.2.2, which discuss the aspects of juvenility and immaturity.
Firm Delivery Dates
Many Web projects are design-to-schedule projects, where all activities and decisions have to meet a fixed final project deadline (see also Chapter 1 and section 9.2.2). The negotiation and prioritization of requirements are particularly crucial under such circumstances (Boehm et al. 2001).