Today numerous methods, guidelines, notations, checklists, and tools are available for all activities in RE. However, in order to succeed developers should avoid a “one-size-fits-all” approach, and RE methods consequently have to be adapted to the specifics of Web engineering (see section 2.3) and the situation of specific projects. The principles described in section 2.4 guide the definition of a project-specific RE approach for Web engineering. Among others, developers have to clarify the following aspects during the adaptation process:
• Which types of requirements are important for the Web application? (section 2.5.1) • How shall requirements for the Web application be described and documented? What are
useful degrees of detail and formality? (section 2.5.2)
• Shall the use of tools be considered? Which tools are suited for the particular project needs? (section 2.5.3).
2.5.1 Requirement Types
Both standardization bodies and commercial organizations have been developing a large number of taxonomies for defining and classifying various types of requirements. Examples are Vol- ere (Robertson and Robertson 1999) or IEEE 830-1998. Most taxonomies distinguish between
functional requirements and non-functional requirements. Functional requirements describe a
system’s capabilities and services (e.g., “The user can select an icon to view articles in the shopping cart at any given time.”). Non-functional requirements describe the properties of capa- bilities and the desired level of services (e.g., “The Web application shall support at least 2500 concurrent users.”). Other non-functional requirements refer to project constraints and system interfaces.
In the following we briefly discuss types of requirements particularly relevant in Web development projects:
Functional Requirements
Functional requirements specify the capabilities and services a system is supposed to offer (e.g., money transfer in an online banking application). Functional requirements are frequently
2.5 Adapting RE Methods to Web Application Development 33 described using use case scenarios and formatted specifications (Cockburn 2001, Robertson and Robertson 1999, Hitz and Kappel 2005).
Contents Requirements
Contents requirements specify the contents a Web application should represent. Contents can be described, for example, in the form of a glossary (see also Chapter 3).
Quality Requirements
Quality requirements describe the level of quality of services and capabilities and specify important system properties such as security, performance, or usability (Chung et al. 2000). The international ISO/IEC standard 9126 defines a technology-independent model for software quality which defines six quality characteristics, each divided into a specific set of subcharacteristics. These six quality characteristics are:
• Functionality describes the presence of functions which meet defined properties. The
subcharacteristics are suitability, accurateness, interoperability, compliance, and security. Security is especially important for Web applications and is discussed in more detail in Chapter 13.
• Reliability describes a software product’s ability to maintain its performance level under
specific conditions over a defined period of time. The subcharacteristics are maturity, fault tolerance, and recoverability.
• Usability describes the effort required to use a software product, and its individual
evaluation by a defined or assumed group of users. The subcharacteristics are understand- ability, learnability, and operability. Chapter 11 describes this important aspect for Web applications in detail.
• Efficiency describes the ratio between the performance level of a software product and the
resources it uses under specific conditions. Subcharacteristics include time behavior and resource behavior (see also Chapter 12).
• Maintainability describes the effort required to implement pre-determined changes in a
software product. Its subcharacteristics include analyzability, changeability, stability, and testability.
• Portability describes the suitability of a software product to be moved from one environment
to another. The subcharacteristics include adaptability, installability, conformance, and replaceability.
Initial attempts have been made by researchers to extend this basic model to Web-specific charac- teristics (Olsina et al. 2002). Chapters 11 through 13 discuss usability, performance, and security, which are success-critical quality aspects in general, and for Web applications in particular. System Environment Requirements
These requirements describe how a Web application is embedded in the target environment, and how it interacts with external components, including, for example, legacy systems, commercial- off-the-shelf components, or special hardware. For example, if a Web application is supposed to be ubiquitously available, then environment requirements have to specify the details.
User Interface Requirements
As Web users are expected to use a Web application without formal training, self-explanatory and intuitive guidance of users is critical for its acceptance. Requirements concerning the user interface define how a Web application interacts with different types of user classes. Important aspects are hypertext (navigation structure) and presentation (user interface). While naviga- tion and presentation details are normally defined in the modeling process, initial decisions about the user interface strategy should be defined during requirements elicitation. Proto- types are best suited to avoid the IKIWISI problem. Constantine and Lockwood suggest that users should cooperate in the design of scenarios for specific tasks. Their usage-centered
design approach is based on creating and iteratively fine-tuning models for roles, tasks, and
interactions (Constantine and Lockwood 2002, Constantine and Lockwood 2001) (see also Chapter 11).
Evolution Requirements
Software products in general and Web applications in particular are subject to ongoing evolution and enhancement. Therefore, Web developers need to capture requirements that go beyond the planned short-term usage of an application. For example, a quality requirement demanding an additional 5000 concurrent users in two years has to be considered by defining a scalable system architecture. Evolution requirements are possible for all the types of requirements discussed so far, for example, future capabilities, future security requirements, etc.
Project Constraints
Project constraints are not negotiable for the project’s stakeholders and typically include budget and schedule, technical limitations, standards, mandated development technology, deploy- ment rules, maintenance aspects, operational constraints, legal, or cultural aspects affecting a project.
2.5.2 Notations
A large variety of notations are available for specifying requirements in different degrees of detail and formality. Examples include stories, formatted specifications, or formal specifications. The identified project risks provide guidance in choosing a suitable level of specification quality, i.e., to define how much RE is enough in a given project (“If it’s risky to specify: don’t – if it’s risky not to specify: do”). In general, informal and semi-formal approaches are particularly suited for Web applications. (Kitapci et al. 2003) and Table 2-2 show different notations for requirements.
Stories
Stories are colloquial descriptions of desired properties; they are used to produce a common understanding between customers and developers. Examples are the user stories known from Extreme Programming (Beck 2000). A user story is formulated by a customer in her language
2.5 Adapting RE Methods to Web Application Development 35 Table 2-2 Comparing the suitability of different notations
Precision Ease
of
Validation Effort Non-Expert Suitability Scalability
Stories **** **** **
Itemized Requirements * *** **** ***
Formatted Specifications ** *** ** *** ***
Formal Specifications **** ****
and terminology, and describes problems and things the system should solve for that customer. Figure 2-2 describes a short scenario from the customer’s perspective:
A user checks the products she put in the online shopping cart. The input is validated as soon as the user clicks<Continue>. If no error is found, then the order will be accepted and a
confirmation e-mail will be sent to the user.
Figure 2-2 Example of an Extreme Programming user story.
Itemized Requirements
Itemized requirements are simple specifications in natural language. Each requirement has a unique identifier. One good example is a data item description as specified in IEEE/EIA-J-STD- 016.
Formatted Specifications
Formatted specifications use an accurately defined syntax, but allow natural-language descriptions within this frame. Examples include use case descriptions in Unified Modeling Language (UML) (Cockburn 2001), the RDD-100 Requirements Specification Language, the MBASE SSRD Guidelines (Kitapci et al. 2003), or the Volere Shell (Robertson and Robertson 1999).
Table 2-1 shows an example of a formatted specification similar to the one suggested in (Kitapci et al. 2003). Important attributes are: description, priority, rationale, and version history. Each requirement is identified individually and can be referenced during the process at any given time using a unique id. Interdependencies with other requirements and other development results, such as architecture documents or plans, are captured to support traceability.
UML use cases are particularly useful to describe functional requirements. A use case describes a system’s function from the perspectives of its actors and leads to a perceivable result for the actors. An actor is an entity external to the system that interacts with the system. A use case
diagram represents the relations between use cases and actors (see Chapter 3 for an example of
a UML use case diagram).
Use case diagrams are useful to depict high-level dependencies between use cases and actors. Use case details are defined in formatted specifications. The attributes typically cover the number and name of the use case, the involved actors, pre- and post-conditions, progress description,
exceptions and error situations, variations, source, rationale, trace links, or interdependencies with other UML diagrams.
Formal Specifications
Formal specifications are written in a language that uses a formally defined syntax and semantics. The most prominent example is “Z” (ISO/IEC13,568:2002). Formal specifications are hardly used for specifying Web applications, except in niche areas.
Suitability
Table 2-2 (Kitapci et al. 2003) compares the different notations with regard to the attributes accuracy, easy of validation, cost-effectiveness, suitability for non-experts, and scalability. A low to medium accuracy will be sufficient for specifying Web application requirements and a formal validation is normally not required. It is typically essential to keep the effort for eliciting and managing requirements low, and requirements should be understandable for non-experts. Finally, scalability is an issue due to the high complexity of many Web applications. We can see in Table 2-2 that informal and semi-formal description forms, e.g., stories, requirement lists, and formatted specifications, are particularly suited for Web applications.
2.5.3 Tools
We describe various classes of tools using the basic RE activities described in section 2.2.2. Existing RE tools are not limited to Web applications, but can be adapted to the specifics of Web application development.
Requirements Elicitation
In section 2.3 we mentioned that special emphasis should be placed on requirements negotiation in Web engineering. Negotiation methods and tools have been developed and explored in many disciplines as described in (Gr¨unbacher and Seyff 2005). EasyWinWin (Briggs and Gr¨unbacher 2002, Boehm et al. 2001, Gr¨unbacher and Braunsberger 2003) is a groupware-supported approach that guides a team of stakeholders in their efforts to jointly acquire and negotiate requirements. EasyWinWin defines a set of activities of a negotiation process. A moderator guides stakeholders through the process. The approach uses group facilitation techniques that are supported by collaborative tools (electronic brainstorming, categorizing, polling, etc.). These activities are: review and expand negotiation topics; brainstorm stakeholder interests; converge on win conditions; capture a common glossary of terms; prioritize win conditions; reveal issues and constraints; identify issues, options; and negotiate agreements.
Requirements Validation
Due to the openness of the Internet, online feedback systems can complement or even replace more costly methods, such as personal meetings or interviews, when validating Web application
2.6 Outlook 37