ITT545:WEB ENGINEERING

CHAPTER 2: Requirements Engineering for Web

Applications

PREPARED BY: NOR AIMUNI MD RASHID/ UiTM CAWANGAN MELAKA KAMPUS JASIN
Chapter Outline
Fundamentals of Requirements Engineering
(RE)
RE Activities- Process, Planning and Design
RE Specifics in Web Engineering
Principles of RE of Web Applications
Types of Requirements
Notations and Tools for RE
Chapter Objectives & Outcomes

By the end of this chapter, student should be

able to:
Define requirement engineering and its
activities
Describe RE Specification in Web Engineering
and its principles in developing web
application.
Differentiate types of requirements involves
 INTRODUCTION

REQUIREMENTS ENGINEERING (RE):

The process of analyzing, documenting and validating
the requirements of the software.
the organized use of principles, techniques, tools and
languages for the cost-effective analysis,
documentation and changing user needs.
2.1: FUNDAMENTALS OF REQUIREMENT
ENGINEERING
 WHAT IS A REQUIREMENT?
 IEEE Std. 610.12 defines a requirement as
1. An ability needed by a user to solve a problem or achieve
an objective;
2. A condition that must be met to satisfy a contract and
standard;
3. A documented representation of a capability or condition
as in the above two points.
 Requirements are basically of the following two types:
1. Functional requirements;.
2. Non-functional requirements.
Functional requirements define a system’s capabilities and
services. EXAMPLE: functionality, maintainability,
traceability, consistency, unambiguity, etc. of the system.
Non-functional requirements are used to define the
desired levels of quality. They range from user interface
look and feel to response time requirements to security
issues.
non-functional requirements deal with the issues like
1. Quality attributes
2. Constraints
3. Goals
4. Non-behavioral requirements
 IMPORTANTS POINTS IN GATHERING THE
REQUIREMENTS

1. Identify stakeholder 3. Working toward collaboration

the context-free questions

Questions to gather initial

understanding of the
problem domain

Questions that focus on

the effectiveness of the
communication activity
2. Recognizing multiple viewpoints 4. Asking the questions
2.2 RE ACTIVITIES— PROCESS, PLANNING
AND DESIGN
 The RE is an umbrella activity and it involves:

Elicitation
Documentation
Verification and validation
Requirements management
Background activities and
those activities need to be
performed through the
entire web engineering
process
 REQUIREMENTS ELICITATION
 aim at improving communication among the developers,
clients and the users.
 Developers construct a model of the application domain by
observing users in their environment. They select a
representation that is understandable by the clients and users .
 They validate the application domain model by constructing
simple models of the user interface and collecting feedbacks
from the Web users.
 A scenario describes an example of the system in use. It shows
interactions between a user and a system.
 A use case is an abstraction that describes the scenario of
system. Both scenarios and use cases are written in natural
language that the Web users can also understand.
 REQUIREMENTS ELICITATION

Two methods for elicitation of information:

1. Joint application design (JAD)
2. Maintaining traceability
 REQUIREMENTS ELICITATION - JOINT APPLICATION
DESIGN (JAD)
 It aims at building consensus among the developers, the users
and the clients by jointly developing the SRS. It is a requirements
gathering technique developed at IBM in 1970s.
 JAD suggests that elicitation of requirements is done in one
single workshop session in which all stakeholders participate.
 The users, clients, developers and a leader sit together in one
room to present their viewpoints, negotiate and come to
mutually acceptable solution.
 The final deliverable is a JAD document, including definitions of
data elements, workflows and interface screens.
 Note that the final JAD document acts as an agreement among developers,
users, clients and thus, minimizes requirements changes later in the
development process.
REQUIREMENTS ELICITATION - JOINT APPLICATION
DESIGN (JAD)
 The main actors involved in the JAD are as follows: (a) Customer; (b)
Sponsor (top management person); (c) Facilitator (or project leader); (d)
Scribe (or record keeper); and (e) System analyst.
 The JAD is useful for larger projects. It involves the following main activities:
 (a) Project definition: It includes fact finding and information gathering.
 (b) Forming JAD teams: A JAD team is formed by a facilitator and the sponsor.
 (c) Kick-off meeting: Initial meeting is started by the sponsor. It focuses on
ensuring that all team members understand what JAD is.
 (d) Regular JAD sessions: Based on user’s availability, JAD sessions are held for
discussion on planning, analysis, design and development.
 (e) Traceability: It focuses on recording, structuring, linking, grouping and
maintaining dependencies among requirements, and between requirements
and other work products.
 REQUIREMENTS ELICITATION - MAINTAINING
TRACEABILITY
 Traceability is the ease with which you can traverse between different
phases.
 It includes tracing where the requirements came from and the project they
affect.
 Traceability enables the developers to show that the system is fully developed
and the testers to show that the system satisfies their requirements.
 The approach used cross-references among the documents, models and the
codes.
 For large project, specialized database tools enable partial automation of
capture, editing and linking of traceability dependencies at a more detailed
level.
 For example, DOORS by Telelogic and RequisitePro by Rational are such tools that
reduce the cost of maintaining traceability.
 DOCUMENTATION
 The results of the requirements elicitation and analysis activities are documented in the
requirements analysis document (RAD).
 This document serves as a contract between the client and the developer, and it
describes the system in terms of functional and non-functional requirements.
 The audience for the RAD includes:
 1. Clients;
 2. Project management;
 3. Users;
 4. System analysts;
 5. System designers.
 The first part of the document includes use cases and non-functional requirements,
whereas the formalization of the specification in terms of object models is written during
analysis.
 This RAD should be written after the use case model is stable, i.e., when the number of
modifications to the requirements is optimal. Suitable degree of preciseness and
formality is decided depending on the types of identified risks and the skills and
experience of the expected readers.
 VERIFICATION AND VALIDATION
Verification is a static process of testing the
documents. The requirements analysis document
(RAD) is also verified.
Validation is a dynamic process of running
executables (code). Similarly, requirements need to
be validated.
Traditional projects used reviews, inspections,
prototyping, etc. for validation of requirements, but
in Web engineering field, direct user participation is
a must, for example, through online collection of
user feedback.
VERIFICATION AND VALIDATION

Verification Validation

It includes checking It includes testing and

documents, design, codes validating the actual
and programs. product.
Verification is the static Validation is the dynamic
testing. testing.
It does not include the It includes the execution of
execution of the code. the code.
 REQUIREMENTS MANAGEMENT
Requirements are not stable or fixed.
Change frequently as the user demands increases,
and that regular change in the requirements and
constraints on Web projects is one of the major
features of the Web projects.
For achieving the task of combining the new
requirements and changes to the existing
requirements, several methods and tools may be
used. These tools help in achieving traceability.
2.3 RE SPECIFICS IN WEB ENGINEERING
 DIFFERENCE BETWEEN RE IN TRADITIONAL/
CONVENTIONAL SOFTWARE ENGINEERING
 1. Multidisciplinary
 2. Non-availability of stakeholders
 3. Volatility of requirements
 4. Dynamic operational environment
 5. Affect of old systems
 6. Importance of quality factors
 7. Quality of content
 8. Lesser developer experience
 9. Rigid delivery dates
 10. Vulnerability issues
2.4 PRINCIPLES OF RE OF WEB
APPLICATIONS
PRINCIPLE 1: ANALYZE THE PRESENT BUSINESS
SCENARIOS
According to Boehm, business analysis is useful to
find out the value of a Web application with respect
to the resources it uses.
This understanding of system has several
advantages, which are as follows:
1. Identifying the success-critical stakeholders;
2. Understanding the purpose of such a Web
application;
3. Finding out the constraints on the project, if any.
 PRINCIPLE 2: STAKEHOLDERS’ FEEDBACK
AND INVOLVEMENT
 The requirements of stakeholders have to be located and
negotiated again and again to cope with the dynamically
changing needs of the projects.
 following requirements are necessary for any Web application:
1. Finding and identifying the stakeholders that affect project’s
success;
2. Finding the user’s requirements, objectives and goals;
3. Coping with different expectations, experiences and
knowledge (multidisciplinary).
PRINCIPLE 3: ITERATIVE APPROACH OF
REQUIREMENTS DEFINITION
As a project progresses, the development results
can be slowly refined in more concrete terms,
while continuously ensuring their consistency.
Requirements are volatile, i.e., they may change
any time. Thus, iterative approach is better. If the
development time is limited, then iterative
approach will list and implement the higher priority
requirements first. Eg Agile methodology
PRINCIPLE 3: ITERATIVE APPROACH OF
REQUIREMENTS DEFINITION
 PRINCIPLE 4: SYSTEM ARCHITECTURE
 A complex Web architecture makes the Web site code also
complex. This makes its testing difficult.
 Thus, proper Web architecture must be designed. For this, expert
Web designers are needed, and this is a very big issue in Web
engineering field.
 The twin-peaks model suggests the concurrent refinements of
both requirements and the system architecture in an iterative
fashion, with each level introducing a newer detail.
 PRINCIPLE 5: RISK IDENTIFICATIONS
 A good project manager must identify the risks as the project
starts. It is so because the late identification of a risk can led to
project failure.
 Risks also arise due to undetected problems, unsolved issues
and conflicts among the requirements.
 As far as the Web applications are concerned, several risks
have been identified like integration of the existing
components into the Web application, determination of
system quality aspects or less-experienced developers.
 Risk mitigation is one of the important activities.
2.5 TYPES OF REQUIREMENTS
WEB ENGINEERING PROJECT REQUIREMENTS

1. Web functional requirements: Functional

requirements refer to those requirements that
specify the functionality of a given project. They are
shown using use case diagrams, as suggested by
Cockburn.
2. Contents requirements: These requirements
specify the contents a Web application should
show.
 WEB ENGINEERING PROJECT REQUIREMENTS
 3. Quality requirements/ Non-functional requirements: Quality has the following
four dimensions:
 (a) Specification quality: It refers to how well the specifications are specified
for the product or service being provided. If all specifications of a web
project are met then the other activities can follow this specification step.
 (b) Design quality: It refers to how well the product or service to be delivered
is designed. If the design is weak, then the software may fail at any time.
 (c) Development/ software construction quality: Good-quality code is
obtained by following the coding guidelines of the programming languages
being used. The aim is to write a reliable and defect-free code.
 (d) Conformance quality: It determines how well the quality control is carried
out in the organization.
 WEB ENGINEERING PROJECT REQUIREMENTS
 4. Environment of system-based requirements: Its interaction
with the older systems or some new hardware is also to be
focused upon. These are also requirements of a system related
to it operational needs.
 5. GUI-related requirements: Users interact with the help of
graphical user interfaces (GUIs) only. The GUIs include a form
also. The front-end design is as much important as is the back-
end design.
 WEB ENGINEERING PROJECT REQUIREMENTS
 6. Evolution requirements: Web applications are developed
using spiral model. This is because they are getting evolved
every day and every hour. Web developers must take care of
all this. The future capabilities, future security requirements,
future workloads, etc. must also be considered.
 7. Constraints on the project: Many restrictions work on a
project while it is being developed like managerial constraints
related to its cost, project’s time and the resource
requirements. Technical limitations, following the standards,
maintenance part, deployment constraints, operational
constraints, legal constraints, etc. also affect a Web project.
2.6 NOTATIONS & TOOLS
FOR RE
 NOTATIONS FOR RE

Many methods are available for showing all of the

requirements gathered. Some methods include:
1. Stories;
2. Unique identifiers given to all of the
requirements;
3. Use case method (as given by Cockburn); and
4. Standards like IEEE SRS Std. 830 (ISO also gives
some standards).
 TOOLS FOR RE
Analysis tools help a software engineer in creating
system models.
These models contain a representation of data,
function and behavior as well as classify it as data,
architectural, procedural and interface design.
So, analysis tools provide quicker and better
solutions so that errors do not propagate into the
design phase.
 SUMMARY
 The process of gathering, analyzing, categorizing and
modeling the requirements of Web users is known as
requirements engineering.
 The chapter discusses how and from where to gather
Web project requirements.
 The chapter also highlights the basic principles followed
for Web requirements analysis. It discusses the
requirements of the Web application based projects.
 It is mandatory; otherwise, certain requirements are
missed out, and this may later on result in customer
dissatisfaction.
 The chapter also lists the different case tools that can be
used to do Web analysis.
END OF CHAPTER