2.2.1 Where Do Requirements Come From?
The individual objectives and expectations of stakeholders are the starting point of the requirement elicitation process. Stakeholders are people or organizations that have direct or indirect influence on the requirements in system development (Kotonya and Sommerville 1998). Important stake- holders are customers, users, and developers. Typical stakeholders for Web applications include content authors, domain experts, usability experts, or marketing professionals. The objectives and expectations of stakeholders are often quite diverse, as demonstrated by a few examples:
• The Web application shall be available online by September 1, 2006 (customer constraint). • The Web application shall support a minimum of 2500 concurrent users (quality objective
2.2 Fundamentals 25
• J2EE shall be used as development platform (technology expectation of developer). • All customer data shall be securely submitted (quality objective of user).
• The user interface shall support layouts for different customer groups (quality goal of
customer).
• An arbitrary user shall be able to find a desired product in less than three minutes (usability
objective of customer).
• A user shall be able to select an icon to display articles included in the shopping cart at any given time (capability objective of user).
The identification and involvement of success-critical stakeholders are central tasks of project management. A big challenge is to understand and reconcile the often conflicting objectives, expectations, backgrounds, and agendas. For example, there might be conflicts between a desired set of capabilities and the available budget; between the set of capabilities, the project schedule, and the desired quality; or perhaps between a desired development technology and the developers’ skills and experiences. Understanding and resolving such contradictions and conflicts early on is crucial and an important contribution to risk management. Negotiation techniques have been proposed to support this task (Gr¨unbacher and Seyff 2005). In this process developing a shared vision among stakeholders is a pre-requisite for success.
Stakeholder objectives are often represented informally and provide the foundation for deriving
more detailed requirements.
A requirement describes a property to be met or a service to be provided by a system. IEEE 610.12 defines a requirement as (1) a condition or capability needed by a user to solve a problem or achieve an objective; (2) a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents; (3) a documented representation of a condition or capability as in (1) or (2).
Requirements are typically categorized as functional requirements, non-functional require- ments, and constraints (Robertson and Robertson 1999). Functional requirements define a system’s capabilities and services, while non-functional requirements describe desired levels of quality (“How secure?”, “How usable?”, etc.). Equally important, constraints are non-negotiable conditions affecting a project. Examples of constraints are the skill-level of the development team, the available budget, the delivery date, or the existing computer infrastructure in the deployment environment.
A requirements document summarizes all requirements and constraints agreed between the contractor and the customer (see also “Notations” in section 2.5).
It has been shown that the assumption of the waterfall model, i.e., defining complete, consistent, and correct requirements early on, is unrealistic in most projects (and in particular for Web application development). RE methods are thus often used in the context of iterative and agile life approaches. Current RE approaches therefore emphasize the identification and involvement of stakeholders, the negotiation and scenario-based discovery of requirements, an analysis of the organizational and social contexts prior to detailed modeling, and the clear definition of constraints affecting development (Boehm 2000b, Nuseibeh and Easterbrook 2000).
2.2.2 Requirements Engineering Activities
RE covers the elicitation, documentation, verification and validation, as well as the management of requirements throughout the development process.
Requirements Elicitation and Negotiation
Researchers have shown that “requirements are not out there to be collected by asking the right questions” (Nuseibeh and Easterbrook 2000). Rather, requirements are a result of a learning and consensus-building process (Boehm et al. 2001, Lowe and Eklund 2002). In this process, communication among the stakeholders is essential, as only their shared expertise can lead to mutually acceptable solutions. A wide set of methods and collaborative tools are available to facilitate communication and knowledge exchange in RE. Examples include creativity techniques, scenario-based methods, multicriteria decision processes, facilitation techniques, interviews, or document analysis (Nuseibeh and Easterbrook 2000).
Requirements Documentation
If stakeholders attain consensus, their agreements have to be refined and described in a
requirements document in the degree of detail and formality that is appropriate for a project
context. The choice of the appropriate degree of detail and formality (see section 2.5.2) depends on both the identified project risks and the experience and skills of the expected readers. Informal descriptions such as user stories, and semi-formal descriptions such as use cases, are particularly relevant in Web engineering.
Requirements Verification and Validation
Requirements need to be validated (“Did we specify the right things?”) and verified (“Did we specify things correctly?”). There are several conventional methods for this purpose, such as reviews, inspections, or prototyping (Halling et al. 2003). In Web engineering, the openness of the Internet facilitates novel forms of direct user participation in requirements validation, e.g., through the online collection of user feedback (Deshpande et al. 2002).
Requirements Management
Rather than being stable, requirements are subject to frequent changes. Continuous changes of requirements and constraints are a major characteristic of Web projects. Methods and tools for requirements management support both the integration of new requirements and changes to existing requirements. They also help in evaluating the impact of changes by managing interdependencies among requirements, and between requirements and other development artifacts (traceability). Due to the difficulties of requirements management for even moderately complex systems, tools are typically used to support this task.