REQUIREMENT ENGINEERING

FOR WEB APPLICATIONS

Dr. Sohaib Ahmed

 Agenda
2

 What is Requirement Engineering?

 Fundamentals of Requirement Engineering
 Requirement Engineering Activities
 Principles of Requirement Engineering
 Challenges with the Stake Holders
 RE … Introduction
3

 Requirements Engineering (RE) – the principles,

methods, & tools for describing, validating, and
managing project goals and needs.
 Defining Requirements…… Not New
4
Idea
 The authors build their case:
 Bell & Thayer (1976) – Requirements don’t turn out
automatically but have to be identified in an
engineering activity (Article: Software requirements:
Are they really a problem?)

 Boehm (1981) – Studied the cost of defects in

requirements and found that late removal of
undiscovered defects is up to 200 times more costly
than early identification (Article: No Silver Bullet:
Essence and accidents of Software Engineering)
 Defining Requirements…… Not New
5
Idea
 The authors build their case:
 The Standish Group (1994) – A survey among 8000
projects conducted - 30% of project failed before
completion & 70% did not meet customer
requirements
 Unclear objectives, unrealistic schedules & expectations, poor
user participation
 European Software Institute (1995) – 340 companies
in Austria – More than two third of these companies
regarded the development of a requirement document
as a major problem
 What are the consequences?
6

 Inadequate software architectures

 “Unforeseen” problems
 Budget overruns
 Production delays
 “That’s not what I asked for”
 Low user acceptance
 What are the consequences?
7
 Fundamentals of RE
8

 Identify and involve (if possible) the stakeholders

 Those that directly influence the requirements
 Customers, users, developers
 What are their expectations?
 May be misaligned or in conflict.
 May be too narrowly focused or unrealistic.
 Already, one can see RE as more of an art than a
science.
 Fundamentals of RE
9

 IEEE 601.12 definition of requirement:

 1) A condition or capability needed by a user to solve a
problem or achieve an objective
 2) A condition or capability must be met or possessed
by the system to satisfy a formal agreement
 3) A documented representation of a condition or
capability in as in (1) and (2)
 RE Activities
10

Elicitation &
Negotiation

Management Documentation

Validation &
Verification
 Requirements Engineering Activities
11

 Requirements Elicitation and Negotiation

 requirements are not out there to be collected by asking the right
questions. Rather, requirements are a result of a learning and
consensus-building process 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, multi-
criteria decision processes, facilitation techniques, interviews, or
document analysis
 Cont….
12

 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
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.
 Cont….
13

 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. 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.
 Cont….
14

 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.
 Specifics In Web Engineering
15

 Has RE for the Web differ from RE for

conventional software?
 Some would argue “no”, but many aspects of Web
applications suggest otherwise
 There are many differences between web
development and software development but there
are also similarities between them
 Distinguishing characteristics
16

 Multidisciplinary
 Unavailability of stakeholders
 Rapidly changing requirements & constraints
 Unpredictable operational environment
 Integration of legacy systems
 Quality aspects
 User interface quality
 Content quality
 Developer inexperience
 Firm delivery dates
 Multidisciplinarity
17

 Web apps requires participation of experts from

different groups
 For example: Multimedia experts, content authors,
software architects, database specialists or domain
experts
 The heterogeneity make it challenging to achieve
consensus when defining requirements
 Unavailability of Stakeholders
18

 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
 Because of wide spectrum of possible users in web
projects and finding a reasonable set of
representatives is hard
 Volatility of Requirements
19

 Requirements and constraints such as deployments

platforms and communication protocols are often easier
to define for conventional software systems than for web
apps
 As web apps are highly dynamic requirements and
constraints are harder to stabilize
 Frequent examples of changes are technology
innovations such as introduction of new development
platforms and standards or new devices for end users
 Unpredictable Operational
20
environment
 Developers find it hard or impossible to control
important factors that are decisive for the user
perceived quality of web applications
 For example changing bandwidths affect the
response time of mobile applications but are
outside the sphere of development team
 Impact of Legacy Systems
21

 Development of web apps is characterized by the

integration of existing software components such as
commercial off the shelf products or open source software
 Web developers frequently face the challenge to integrate
legacy systems accessible through web
 The components needs to be integrated strongly influence
the requirements and architectural style of the future
systems
 Under such circumstances waterfall approach will not
succeed, Twin-Peaks model can be appropriate in such a
context (See page 28)
 Significance of Quality Aspect
22

 Quality aspects are decisive for the success of web

applications
 Examples such as security in e-commerce, availability or
usability
 The response time of a web application depends on many
factors that are outside the control of the development
team
 A feasible approach is to specifying criteria for the
acceptance test indicating whether or not a requirement
has been met
 Quality of the user Interface
23

 A success critical aspect of web applications

 Web app developers need to be aware of the IKIWISI
(I Know It When I See It) phenomenon
 It is thus absolutely essential to complement the
definition and description of requirements by adding
prototypes of important application scenarios
 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
 Quality of Content
24

 In the context of RE it is particularly critical to define

the required quality of content
 Important quality characteristics include accuracy,
objectivity, credibility, relevance , completeness and
clarity
 Content Management systems gain importance and
allow representing content concisely by separating it
from layout and offering content editing tools
 For example: Joomla, Opencart, Virtualmart,
Wordpress, Magento, Drupal etc.
 Developer Inexperience
25

 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
 Firm Delivery Date
26

 Many web projects are design-to-schedule projects

where all activities and decisions have to meet a
fixed final project deadline
 The negotiation and prioritization of requirements
are crucial under such circumstances
 Principles for RE
27

 Understanding the system context

 Web apps are always a component of a larger entity
 Why do we need the system?
 How will people use it?
 Involving the stakeholders
 Get all groups involved.
 Balance – one group’s gain should not come at the expense
of another.
 Repeat the process of identifying, understanding and
negotiating.
 Principles for RE
28

 Iteratively define requirements

 Requirements need to be consistent with other
system aspects (User Interface, content, test cases)
 Start with key requirements at a high level; basis for:
 Feasible architectures
 Key system use cases
 Initial plans for the project
 As the project progresses, requirements can become
more concrete.
 Principles for RE
29

 Focusing on the System Architecture

 The “solution space” – existing technologies &
legacy systems – defines the “problem space.”
 The architecture must be considered in the elicitation
stage.
 Refine requirements and architecture iteratively with
increasing level of detail.
 Principles for RE
30

 Risk Orientation
 Risk management is at the heart of the analysis
process.
 What are the greatest risks?
 Integration issues with legacy systems
 Expected vs. actual system quality
 Inexperience of developers
 How to mitigate risks?
 Prototyping (to avoid IKIWISI)
 Show changes to customer iteratively
 Integrate existing systems sooner than later
 Adapting – Requirement Types
31

 Taxonomies (e.g. IEEE 830) exist that

describe functional and non-functional
requirements.
 Functional – describes the system’s capabilities
and services (e.g., the ability to transfer money
between user accounts.)
 Non-functional – describes the properties of
capabilities and the desired level of services (e.g.,
the system can handle 1,000 concurrent users)
 Adapting – Requirement Types
32

 Quality Requirements
 Describe the level of quality of services and
capabilities
 6 Types – defined by ISO/IEC standard 9126
 Functionality
 Reliability
 Usability
 Efficiency
 Maintainability
 Portability
 Adapting – Requirement Types
33

 Contents Requirements
 Specify contents of a web application
 System Environment Requirements
 Describes how a web application is embedded in the
targeted environment
 User Interface Requirements
 Defines how a web application interacts with different
type of users
 Evolution Requirements
 Future capabilities or future security requirements etc.
 Adapting – Documentation
34

 Categories of Notation
 Stories – Plain-language scenarios; understandable
to non-technical persons.
 Itemized Requirements – Plain-language lists of
requirements
 Formatted Requirements – Accurately-defined, but
allow for plain-language descriptions
 Ex. Use case scenarios in UML
 Formal Specifications – Written in a language that
uses a formally defined syntax and semantics
 Adapting – Documentation
35

 So, what’s best for a Web development

project?
 Low to medium accuracy is suitable for Web apps;
 Keep elicitation and management of requirements
low.
 Scalability is (most likely) important.
 Formatted requirements (i.e. use cases) are heavily
used.
 Adapting – Tools
36

 Requirements Elicitation
 EasyWinWin (Briggs & Grunbacher, 2002)
 Defines a set of activities of negotiation process
 Group facilitation techniques used
 Activities are: Review and expand negotiation;
brainstorm stakeholder interests; converge on win
conditions; a common glossary of terms; prioritize
win conditions; reveal issues and constraints;
identify issues, options; and negotiate agreements
 Adapting – Tools
37

 Requirements Validation
 Online feedback (Web surveys)
 Requirements Management
 Database system – traceability, versioning
 Challenges with Stakeholders
38

 McConnell (1996)
 Users don’t know what they want.
 Lack of commitment.
 Ever-expanding requirements.
 Communication delays.
 Users don’t take part in reviews.
 Users don’t understand the technology.
 Users don’t understand the process.