The previous section discussed characteristics of Web applications and RE specifics in Web engineering. We have shown that RE for Web applications has to deal with risks and uncertainties such as volatility of requirements and constraints, inexperience of developers, or the impact of legacy solutions. A risk-oriented approach is a good choice to deal with these challenges. In this section we describe basic RE principles for Web applications. We derive these principles from the invariants of the win-win spiral model (Boehm 1996, Boehm 2000a), a risk-oriented and iterative lifecycle model that places particular emphasis on the involvement of the stakeholders and the elicitation and reconciliation of requirements. The win-win spiral model has influenced many state-of-the-art process models, including IBM’s Rational Unified Process (RUP).
Web developers should keep the following principles in mind when performing RE activities: Understanding the System Context
Many Web applications are still developed as isolated technical solutions, without understanding their role and impact in a larger context. A Web application can however never be an end in itself; it has to support the customer’s business goals. For a Web application to be successful, it is important to clarify the system context (e.g., by analyzing and describing existing business processes) and the rationale of the system to be developed (“What are we doing this for?”). Developers have to understand how the system is embedded in its environment. Business analyses can determine the value of a Web application in relation to the resources it uses value driven requirements (Boehm 2000b). Understanding the system context also helps in identifying success-critical stakeholders, familiarizing with the intended use, and analyzing the constraints (Biffl et al. 2005).
Involving the Stakeholders
Success-critical stakeholders or their suitable representatives are at the heart of RE (Ginige and Murugesan 2001b) and their active and direct cooperation in identifying and negotiating requirements is important in each project phase. Project managers should avoid situations where
2.4 Principles for RE of Web Applications 31 individual project participants gain at the expense of others. It has been shown that such win-lose situations often evolve into lose-lose situations, causing the entire development project to suffer or even fail (Boehm et al. 2001).
The objectives, expectations, and requirements of stakeholders have to be acquired and negotiated repeatedly to address the dynamically changing needs in projects. We have shown that the multidisciplinarity and unavailability of stakeholders are specifics of RE for Web engineering. These characteristics lead us to derive the following requirements for the Web application context: (1) identification of success-effective stakeholders or suitable representatives (in case of unavailability); (2) understanding of stakeholders’ objectives and expectations; and (3) negotiation of different expectations, experiences, and knowledge (multidisciplinarity).
RE methods and tools have to be consistent with these requirements (see also section 2.5.3) and should contribute to the effective exchange of knowledge between the project participants, support a team learning process, the development of a shared vision among stakeholders, and help to detect conflicting requirements early. People know more than they say, so techniques for eliciting hidden knowledge are of particular interest.
Iterative Definition of Requirements
We have already discussed that a waterfall approach to requirements definition typical- ly does not work in highly dynamic environments and requirements should be acquired iteratively in Web application development. Requirements have to be consistent with oth- er important development results (architecture, user interface, content, test cases, etc.). At project inception, key requirements are typically defined on a higher level of abstrac- tion. These preliminary requirements can be used to develop feasible architectures, key system usage scenarios, and initial project plans. As the project progresses, development results can be gradually refined in more concrete terms, while continually ensuring their consistency (see also Chapter 10). An iterative approach is necessary, especially in an environment with volatile requirements and constraints, to be able to react flexibly as the project evolves. If firm deadlines are mandated on the development team, then an iterative development approach allows selecting high-value requirements that need to be implement- ed first.
Focusing on the System Architecture
Existing technologies and legacy solutions have a high impact on the requirements of Web applications. The “solution space” thus largely defines the “problem space” and understanding the technical solution elements with their possibilities and limitations is essential. Requirements elicitation can never succeed in isolation from the architecture. This should be particularly taken into account when defining requirements. A consequent consideration of the system architecture allows developers to better understand the impact of existing solutions on these requirements and assess their feasibility. The Twin-Peaks model (Figure 2-1) (Nuseibeh 2001) suggests to concurrently refine both requirements and the system architecture in an iterative manner with a continually increasing level of detail.
Risk Orientation
Undetected problems, unsolved issues, and conflicts among requirements represent major project risks. Typical risk items are the integration of existing components into the Web application, the prediction of system quality aspects, or the inexperience of developers. A risk assessment should therefore been conducted for all requirements. The identified risks should be dealt with accordingly during the course of a project to make sure that risky system alternatives are not pursued. Risk mitigation has to take place as early as possible. This can include, for example, prototyping, to avoid the IKIWISI problem, early releases of a Web application to collect user feedback, or early incorporation of external components to avoid late and severe integration problems.