Software Requirement Specification

for
Online Bidding System

Prepar
ed by,
Group
2:
AJITH S
AMEENUL
HASEEB U K
MITHUN
RAJ ARACKAL
SREENAT
HM

Date Of
Submission:
 11 February, 2011

Table of Contents
1. Introduction
2
1.1. Purpose
2
1.2. Product Scope 2
1.3. Definitions, Acronyms and Abbreviations 2
1.4. References 2
1.5. Overview 2
1.6. Environmental Characteristics 2
1.6.1. Harware 2
1.6.2. Software 3
1.6.3. People 3
2. Overall Description 3
2.1. Product Perspective 3
2.2. Product Functions 3
2.3. User Classes and Characteristics
3
2.3.1. Administrators 4
2.3.2. Buyers 4
2.3.3. Sellers 4
2.3.4. Casual visitors 4
2.4. Design and Implementation Constraints 5
2.5. User Documentation 6
2.6. Assumptions and Dependencies
6
3. Specific Requirements 6
3.1. External Interface Requirements 6
3.1.1. User Interfaces 6

3.1.2. Hardware Interfaces 6

3.1.3. Software Interfaces 6
3.1.4. Communication Interfaces 7
3.2. Functional Requirements 7

3.2.1. Listing 7
3.2.2. Account Creation
8
3.2.3. Selling 8
3.2.4. Buying 8
3.2.5. Rating
8

2
 3.3. Non Functional Requirements 8
3.3.1. Performance Requirements 8
3.3.2. Safety Requirements 8
3.3.3. Software Quality Attributes
9
3.3.4. Business Rules 9
1.Introduction:
1.1. Purpose: The purpose of this SRS is to specify the
requirements of the web based software application
onbids.com, which is an online bidding system. The
module to be developed is the first version of onbids –
version 1.0. This Software Requirements Specification
provides a complete description of all the functions and
specifications of onbids –version 1.0.

1.2. Product scope: onbids.com is designed to run on any

modern platform with GUI. It is assumed that the back
end that will be used for implementation is MySQL and
the front end that will be used is PHP.

1.3. Definitions, Acronyms and Abbreviations: Proper

sub numbering system for sub topics based on the
importance and priority of the matter is used in the SRS
document. The abbreviations used are:
• SRS: Software requirement specification
• GUI: Graphical user interface
• PHP: Personal home pages
• IEEE: Institute of electrical and electronic engineers
• FTP: File transfer protocol
• SQL: Structural query language

1.4. References:
1.4.1. Software Engineering, A Practitioner’s
approach, 6th edition. By Roger S Pressman. McGraw
hill international.
1.4.2. Fundamentals of Software Engineering, Rajib
Mall

1.5. Overview: This software deals with the buying and

selling of goods through online auctions. The auctioning
system is more like the common offline auctioning
system practiced in our land.

3
 1.6. Environmental Characteristics:
1.6.1. Hardware:
Processor: Intel Pentium III 733 MHz or above
Main Memory: 256 MB or above
Disk Space: 80 GB HDD or above

1.6.2. Software:
Front End:
Programming Language: PHP
Technology: PHP
Client:Any web browser
Operating System: Windows/Linux
Back End:
Database: MySQL
1.6.3. People
• Administrator – Owner of onbids.com
• Buyer
• Seller
• Casual Visitor
2.Overall description
2.1. Product perspective: This is proposed to be an
enhanced model of the present day existing auctioning
portals. Many flaws in the present online auctioning
portals haven’t been able to exploit the full potential of e-
commerce market. The Software Requirements
Specifications intends to identify the flaws in the current
existing system and propose an alternative or a solution
to them.

2.2. Product Functions:

• It consists of two modules
1. Customer module
2. Administrator module
• A customer should have a user account for
carrying out transactions.
• Transactions include auctioning of the
goods.
• Administrator provides the customer with an
account following proper registration procedures to
prevent malpractices in the transactions.
• Any visitor is allowed to browse through the
product list, their prices and bidding procedures.
• Bidding procedures are kept transparent so
that any user is able to go through the procedures.

4
2.3. User classes and characteristics There are 3 kinds of
users for the proposed system
2.3.1. Administrators: They create user accounts and give
it to the required customers.
 To educate consumers about onbids’ range of
products and indigenous services.
 They must provide rules for the transactions.
 They must maintain the website and update the
same making necessary changes at times.
 They must take care of the security issues
involved in the transactions.
 They must inform the users about their
transaction status and keep them updated
about the progress through emails.
 They must receive feedbacks from their
customers or any users about their system and
act upon the relevant ones.
 Look up at all the legal issues involved with the
business.
 Keep place for advertisements in the website as
a revenue generating option. The place has to
be maintained and proper listings done.
 Any failures in the system have to be detected
and repaired.

2.3.2. Buyers: They are the genuine customers of the

website. They can see the listing, bid for various
things, and also buy them to various payment options.

2.3.3. Sellers: These are the people involved in selling their

products through onbids. They consider this as a
virtual market place. They need to be provided with
proper advertisement place, and ratings of customers.
The sellers too are rated based on the feedback they
get from previous transactions completed from
customers. These feedback data are treated with
great respect and are transparent to everyone. The
sellers too value this very highly.

2.3.4. Casual visitors: These people don’t come to the site

on specific intensions of buying or selling. They just
visit to see the listing and to see the products. They
need not have an user account. They can be future
potential customers.

5
The following context diagram states the above data in a
graphical form:

Central
Casual visitor Processing server

Listing

Selling
Seller
Administrator

Buying
Buyer

Administration

Fig 1 Context Diagram for onbids

2.4. Design and Implementation Constraints

• The main constraint here would be the checking the

genuineness of the buyer, which is not always possible.
There can be security risks involved.
• The design constraints are that the browser at each
place may not follow similar screen resolutions,
browsers etc. This can lead to the website not having
the impact it is planned to have.
• Also the rules of the land will prohibit certain items to
be sold on the site. Hence all those factors need to be
filtered in.

6
 • Also storage space constraints may come if the listing
becomes too large. Hence a strong server needs to be
chosen to host the database.

2.5. User Documentation:

2.5.1. Online user help with all the necessary help
needed to use the site in a bulletin format.
2.5.2. Software and database specification
2.5.3. Details of rules and regulation to sellers as well
as buyers.

2.6. Assumptions and Dependencies

None as per now.

3.Specific Requirements
3.1. External Interface Requirements:

3.1.1. User Interfaces: Each part of the user interface

intends to be as user friendly as possible. The fonts
and buttons used will be intended to be very fast and
easy to load on web pages. The pages will be kept
light in space so that it won’t take a long time for the
page to load. The staring page will ask the user what
kind of a user is he, either seller, buyer or a casual
visitor. Based on which the future pages will be loaded
in a sequential manner. Each listing page will have a
area to put the bid, the product details with photo etc.
Each page also will have a search engine to search
the products available so that it is readily available
and the user need not search for it.

3.1.2. Hardware Interfaces: A web server will be used to

host the WebPages and the database management
system. Most pages will be dynamic pages built with
php. Each page will be optimized to the type of web
browser and resolution being used. A minimum of PIII
system running at 733 MHz will be needed to run the
modules. Normal modes of network modes used in
Internet technology will be used.

7
 3.1.3. Software Interfaces: The incoming message mostly
includes requests for a specific task, which on the
course of the development will be decided in detail
and dealt with in design specification document. The
incoming messages from the messages will be
converted to a specific format in the database
language, the processing made and the request
served. The operations will be intended to be made as
fast as possible.

3.1.4. Communications Interfaces: The web server

maintenance and other activities to be done using FTP
transfer protocol. The security and other issues will be
dealt with in the course of the project, as there is little
idea as to how these things work to our team as per
now. There will other communication interfaces with
the users of the site with site-specific email, forms
and complaint addressable mechanisms. These things
as far as possible will be automated.

3.2. Functional Requirements

3.2.1. Listing: This includes the listing feature of the
website where any search or other request of a user
to a particular subject is served. The pertinent web
pages are loaded and the particular database is
initialized. There are listings based on the priority as
by user preferences. This is actually the listing of web
pages to the users by time of selling, deadline, price,
quality etc. Listing includes listing of
o Products to be sold directly
o Products open for bidding till a particular date
o Sellers in a particular area or with specific ratings
o Used products on for sale.
o Just casual listings of random things
o Payment options to buy or sell.

Action Software reaction

User logs in the system
User defines the
information to view
User views the information
The system authenticates
System provides the necessary
details as requested by the
particular employee

8
Table No 1.The table states a typical control passing in the system
during logging in

Listings will be made very fast and user friendly. Proper

security is also a very pertinent point here.

3.2.2. Account creation: This includes creating user

accounts to each of sellers and buyers separately.
This includes taking pertinent information from them
and then initializing the database. The database
needs to be properly updated on each transaction by
the user and all the details of his/her account should
figure in the account listing. The security of the
account also should be dealt with.

3.2.3. Selling: Here the seller can list his/her things on

his/her quoted price. The details of which will be kept
in the user database. The buyers can raise the
amount according to his wish till a particular time. The
item will go to the buyer who has quoted the
maximum amount after the expiry of the time.The
details of his goods on selling list will be updated to
him on a regular basis to his email id. The payment
and feed back details are kept transparent.

3.2.4. Buying: There are 4 ways of buying or intending to

buy
o Direct buying
o Bidding
The details of which will be dealt with in the design
specification. Each of these details are kept in the
user account where he is kept updated about all his
moves.

3.2.5. Ratings: Each products, buyers and sellers are

constantly rated based on the feedback and the
market behavior so that users feel secure about the
system. These ratings are given based on a best
pointer of five, the details of which are yet to be
worked out. These ratings are intended to bring some
trust and credibility to the concept of an online
market.

3.3. Nonfunctional Requirements:

9
3.3.1. Performance Requirements: As stated before in
hardware specification.

3.3.2. Safety Requirements: Suitable safety has to be

taken while allowing a product to be sold on onbids.
They have to follow the legalities of the land, and
must be ethical. There could be possible misuse of the
system by bogus user, bidding and buying without
paying up. It is not always possible to check the postal
addresses. Also during money transactions the
unreliable networks may cause further problems. So
such practices need to be avoided.

3.3.3. Software Quality Attribute: The system is easy to

load and light .It adds to the quality and usability of
the system. Some others quality considerations such
as adaptability, availability, correctness, flexibility,
maintainability, portability, reliability, reusability,
robustness, testability, and usability will also be very
seriously taken to consideration.

3.3.4. Business Rules: Nothing is above customer

satisfaction. So the rules need to be kept flexible to
meet user needs and preferences at different times.
Other models can be applied but is beyond the scope
of the team.

10