EBCS231-Web Applications & Modelling

WEB APPLICATION
REQUIREMENT COLLECTIONS

Ahlijati Nuraminah, S.Kom, M.T.I.

ahlijati.nuraminah@esqbs.ac.id
25 Februari 2016

Updated Schedule and Topics (Theo

ry)

Week Dat
e

Topics

1 18/2 Introduction to Class. Introduction to Web Engineering

2 25/2 Web Engineering Requirement Collections
3

3/3 Web Application Modelling

4 10/3 Web Application Architecture

5 17/3 Assesment 1
6 24/3 Web Application Development Process and Project Management for Web
7 31/3 Web Testing and Documentation
8

7/4 Web Apps Development Part 1: Database and Query

9 14/4 Web Apps Development Part 2: User Authentication and Session

10 21/4 Assesment 2
11 28/4 Object Oriented Programming in PHP
12

5/5 Introduction to Jquery Makeup Class

13 12/5 Reporting
14 19/5 Content Management System
15 26/5 Assesment 3
16

Final Exam

Objective
Students understands the principles of good requirement s
pecifications
Students are able to conduct a stakeholder analysis by carr
ying out the process of requirements elicitation
Students are able to specify system requirements(functiona
l and nonfunctional) and document them in a well formatte
d documents
Students are able to manage the requirement through the c
ourse

Agenda
Introduction
to
Requiremen
ts
Engineering

Elicitation &
Negotiation

Specificatio
n

Validation

Manageme
nt

Example

Software Project Success Rate

http://herdingcats.typepad.com/my_weblog/2011/07/standish-numbers.html

Web Engineering Activity

Deployment
and
maintenace

Analysis and
specification
requirements

Testing
and
quality
control

Design
and
modelling

Developm
ent
/Program
ming

WATCH VIDEO

Introduction
Requirements Engineering (RE) the principles, methods, & tools for e
liciting, describing, validating, and managing project goals and needs.
Given the complexity of Web apps, RE is a critical initial stage, but ofte
n poorly executed.
What are the consequences?
Inadequate software architectures
Unforeseen problems
Budget overruns
Production delays
Thats not what I asked for

Low user acceptance

What is a Requirement?
A requirement describes a property to be met or a service to be provided
by a system.
IEEE 601.12 definition of requirement:
1. Condition needed to solve a users problem
2. Condition to be met or possessed by the system to satisfy a formal agreement
3. Documented representation of conditions as in 1 and 2

Key players in the game

.
.
.
.
10

Contract
Customer
Supplier
User

Why do we need Requirements?

Bell & Thayer (1976) Requirements dont define themse
lves.
Boehm (1981) Removal of mistakes post hoc is up to 20
0 times more costly.
The Standish Group (1994) 30% of projects fail before c
ompletion & almost half do not meet customer requirem
ents
Unclear objectives, unrealistic schedules & expectations, poor
user participation
11

Good Requirements Specifications I

Correct
Correspond to actual need

Unambiguous
Can be interpreted only in one way

Complete
Any external imposed requirement should be included

Consistent
Conflicting requirements should be avoided
12

Good Requirements Specifications II

Ranked for importance and/or stability
Requirements are not equally important
Requirements are not equally stable

Verifiable
Its possible to use a cost-effective process to check it

Modifiable
Can be restructured quickly
Adopt cross reference
Requirements are clearly separated

Traceable
Can be tracked from originating design documentation
13

Types of Requirements
Many taxonomies exist to describe requirements, but m
ost divide them into two groups:
Functional describes the capabilitys purpose
e.g., the ability to transfer money between user accounts

Non-functional describes the capabilitys properties

e.g., the Home Page must load within 5 seconds on a dial-up connecti
on

14

Functional Requirement Types

Data Requirements
How information is stored and managed

Interface Requirements
How the user is going to interact with the application

Navigational Requirements
How the user is going to navigate through the application

Personalization Requirements
How the application adapt itself according to user or environment profile

Transactional Requirements
How the application behave internally
15

Non-Functional Requirement Types

Content
Quality
Functionality, Usability, Portability, Scalability
Reliability, Efficiency, Security, Maintainability

System Environment
User Interface
Self-explanatory & intuitive
Usage-centered design

Evolution
Project Constraints
16

Principles for RE I
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 groups gain should not come at the expense of ano
ther.
Repeat the process of identifying, understanding and negotiating.
17

Principles for RE II
Iteratively define requirements
Requirements need to be consistent with other system aspects
(UI, content, test cases)
Start with key requirements at a high level; these will serve as t
he basis for:
Feasible architectures
Key system use cases
Initial plans for the project

As the project progresses, requirements can become more con

crete.
18

Principles for RE III

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 increasin
g level of detail.

19

The Requirements Collection Process

Elicitation &
Negotiation

Specification

Management

Validation &
Verification

20

How to interact with Stakeholders

ELICITATION & NEGOTIATION

21

Elicitation & Negotiation

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.

Why is the web application being developed in the first p

lace?
22

Techniques for Elicitation & Negotiation

23

Interviewing
Joint Application Design
Brainstorming
Concept Mapping
Storyboard
Use Case Modeling
Questionnaires
Terminology Comparison

Challenges with Stakeholders

McConnell (1996)
Users dont know what they want.
Lack of commitment.
Ever-expanding requirements.
Communication delays.
Users dont take part in reviews.
Users dont understand the technology.
Users dont understand the process.
24

Challenges with Developers

Users and engineers/developers speak different langua
ges.
The tendency to shoe-horn the requirements into an ex
isting model
Saves time for developers, but results may not meet users nee
ds.

Engineers & developers are also asked to do RE, but som

etimes lack negotiating skills and domain knowledge.
25

How to formalize received inputs

SPECIFICATION

27

Specification Traditional RE
4 main categories of notation
Stories Plain-language scenarios; understandable to non-tec
hnical persons.
Itemized Requirements Plain-language lists of requirements
Formatted Requirements Accurately-defined, but allow for pl
ain-language descriptions
Ex. Use case scenarios in UML

Formal Specifications Expressed in formal syntax & semantic

s; rarely used in Web applications.
28

Specification RE for Web Apps

So, whats best for a Web development project?
Formatted requirements (i.e. use cases) and stories are heavily
used.
Low to medium accuracy is suitable for Web apps; formal spec
ifications very rarely required.
Keep effort for eliciting and managing requirements low.
Scalability is (most likely) important.

29

VALIDATION AND NEGOTIATION

30

Validation
This step is essential to verify that requirements specific
ation corresponds to users needs and customers requir
ements
Iterative feedback from stakeholders is essential
Is the requirement feasible?
Do the results meet stakeholders expectations?

We will discuss testing in greater detail later

31

Validation Techniques
Review or walk-through
Reading and correcting the requirements definition documentation and model
s

Audit
Partial check of the results presented in the review documentation

Traceability Matrix
Comparison of the application objectives with the requirements of the system

Prototyping for Validation

Implement a partial set of functional requirements but provide a global vision
of the user interface
32

MANAGEMENT

33

Management
Several tools are available to support Requirements mana
gement (also Open Source)
http://rmblog.accompa.com/2012/04/free-open-source-require
ments-management-tool/

Tool support is crucial for big project

Enable
Traceability
Modifiability
Verifiability
34

Taken from WebML Acer Usecase

EXAMPLE

35

Requirement analysis
Revision and formalization of the collected requirements, producin
g in output a set of semi-formal specifications, typically in terms of:
I. Group specification
II.Use-case specification
III.Data dictionary specification
IV.Site view specification
V.Style guidelines specification
VI.Acceptance tests specification
36

I. Group specification
Clustering of users into groups (formally described)
Groups
Hierarchy:

Group
Descriptio
n:

Group name:
Description:

marketing
and
communication
personnel
inserting, modifying, and deleting mkt materials.

Profile data:

First name, last name, email, office address.

Profile data are provided explicitly by the user.

Super-group:

Corporate.

Sub-groups:
Relevant use
cases:

Objects - read
mode:
Objects - content
mgmt mode:

37

Mar-Com Manager

None.
Login, Add a news item, Modify a news item,
Delete a news item, Add a news category,
Modify a news category, Delete a news
category, "Modify profile data".
Product and Product News.
Product News.

II. Use-case specification I

Formal description of units of interaction with the applic
ation by users of a given group (e.g., thru tables or UML
diagrams)
1. Use cases list for a user (use case diagram)
Add a news
item

Add a news
category

Login
Modify a news
item

Modify a news
category
Remove a
news item

Remove a
news category

Mar-Com Manager
38

2.

II. Use-case specification

Single use case specification (table or activity diagram)

Title

Login of user belonging to multiple groups

Purpose

To express how users with more than one role access the
functions of the applications.

Pre-condition

Postcondition

A user that belongs to multiple groups is registered. For each

group, the site view serving the requirements of the group
members is defined.

User

Application Server

Initial Request

Send Form

Input Credentials

Accept Credentials

Database

Verify Credentials

The user successfully logs into the application and accesses the
site view corresponding to one of his groups.
Select Home Page

Workflow

39

The following steps must be performed:

1.The user receives an input form asking for username and
password;
2.The user inputs his credentials;
3.If the credentials are correct, the user is authenticated, the list
of groups the user belongs to is determined, and the list of
names and URLs of the home pages of the site view of such
groups is displayed to user;
4.The user chooses one entry from the list, and enters into the
selected site view.

Elaborate Page
Default Home Page List
Index of Home Pages

Serve Request

Receive Home Page

III. Data dictionary specification

List of the main information objects identified during dat
a requirements collection
Each entry can be specified by:
NewsItem

40

Name
Synonyms
Description
Sample instances
Properties
Relationships
Components
Super-concept
Sub-concepts

Piece of news
A corporate or product piece of news
TravelMate 610 launched, 20th June 01
Title, Body, Image, Date,
NewsToProduct
None
None
Highlighted news

IV. Site Map specification

IN: list of user groups, list of use cases, data dictionary
OUT: list of needed site maps, specified by:

Name
Description
Target User Groups
Implemented use cases
Site view map: a table illustrating the different areas that compos
e the site view. Each area is specified by:

41

Area Name
Area Description
Accessed/Managed Objects
Priority level

Site View

News Content Management

Description

Includes the pages through which the Mar-Com Managers will access content
management functions, for inserting or updating content about news categories and
news items.

User Groups

Mar-Com Managers

Use Cases

Login, Add a news category, Edit a news category, Remove a news category,
Add a news item, Edit a news item, Remove a news item.

1.2.d Site view specification example

Site View Map

Area Name

Area Description

Objects

News Content In the default page, the user accesses the list of NewsCategory
Management
countries for which he is content manager and selects NewsItem
a country to administer. In the News Category page,
the user accesses the list of news categories for the
selected country. Here, the user can perform content
management functions over news categories,
according to the use cases Add a news category,
Edit a news category, Remove a news category.
Otherwise, he can select one category, and access
the list of the available news items in the selected
category.
In the News page, the user can perform content
management functions over a selected news item
according to the use cases Add a news item, Edit a
42
news item, Remove a news item.

Priority
High

V. Style guidelines specification

Rules for the presentation of pages:
Specification of standard page grids: rows, columns and cells arrang
ement
Content positioning specification: banners, logo, menus positioning
Graphical guidelines: rules for graphic items like fonts, colors, borde
rs and margins
Device-specific and browser-specific guidelines
Example: Mock-ups: sample representations of a few typical applicat
ion pages (for a specific device and rendition language)
43

V. Style guidelines specification

800 px

st
1
Column
Page
Area

2nd Column

Main Menu Area

Main Content Area

Foot Area
150 px

44

Thats almost all for day

WRAP-UP

45

Things to keep in mind

(or summary)
Know your Audience & Objectives
Balancing stakeholder interests
Focus on high-level requirements first.

Elicitation & Negotiation is a learning process

RE requires flexibility
Iterative changes should be expected
Be sure stakeholders understand this!

Clear documentation is critical

46

Online sample
http://ecl.cs.ui.ac.id/PAUS/Reqs/DefTS_files/Sample%20SRS.pdf
http://www.socialforum.se/wp-content/uploads/2012/05/SystemRequiremen
tsSpecification_Mobilwebb.doc
https://aps-rumah-sakit.googlecode.com/files/SRS%20SI-Rumah%20Sakit.do
c

This Week Tasks

In your group, do the requirement collection process (EL
ICITATION, SPECIFICATION/DOCUMENTATION, VALIDATI
ON AND MANAGEMENT)
Write your results in the form of simple, semi-formal SRS
(see example).
Do requirement MANAGEMENT process throughout the c
ourse
The final SRS will be submitted together with the Final Pr
oject Code and other documentation