SOFTWARE REQUIREMENTS

SPECIFICATION
Report
for
Online Auction

Madhak Ketan(110113107011)
Sharma Vivekanand(110113107008)
Saurabh Deopura(100110107054)

Prepared for
Computer dept.
G.H.Patel College Of Engineering And Technology
Vallabh vidyanagar()
INDEX

1.Introduction……………………………………….……………………………….…1
1.1 purpose………...………………………………..….…………………….…1
1.2 Scope...………………………………………………………………………1
1.3 Objective…………………………………………………………………….1
2.Requirements……………………………………………………………………..….4
2.1 Functional Requirements………………………………………….…..….4
2.2 Non- Functional Requirements………………………………………...…4
2.2.1 Safety Requirements…………………………………….………4
2.2.2 Security Requirements…………………………………………..4
2.2.3 Software Quality Attributes………………………………..……5
2.3 Hardware Requirements………………………………….…………….…..5
2.4 Software Requirements………………………………….………………….5
2.5 WaterFall Model………………………………………………………...….6
2.6 Feasibility Study……………………………………….………………….…7
2.6.1 Economic Feasibility……………………………..………..….…..7
2.6.2 Technical Feasibility………………………………………………7
2.6.3 Operational Feasibility…………………………………………….7
3 . Design and Implementation……………………………………………………..…11
3.1 Data flow Diagram………………………………………………….….......11
3.2 Use case Diagram ……...……………………………….………………..…12
3.3 E-R Diagram …………………………………………………………...…20
3.4 Activity Diagram
4 . Snapshots………………………………………………………...........................…..22
5 . Testing And Results……………………………………….............................……..37
5.1 Unit Testing……………………………………………………........................……37
5.2 Integration Testing……………………………………………….......................….38
5.3 System Testing………………………………………………........................….38
5.4 Acceptance Testing…………………………………………….........................…..39
6 . Bibliography…………………………………….……………….....................…41
CHAPTER 1

INTRODUCTION

1.1 Purpose

The purpose of our project is to conduct auction through online. So that public can get registered
and can sell or buy the items what they want through online by participating in auction.

1.2 Scope

This website is only for specified category of product.The seller or buyer can only sell for
specific category now,but further it is possible to extend different categories.

1.3 Objective

 ‘Bidtastic-Auction’ is a web application which facilitates online auction.

 An auction is a sale in which a seller presents his product on a public platform/ forum.
 The selling price in an auction is determined by the bids made by interested buyers.
 The price they bid is based on their own valuation and need for the product.
 The product is sold to the highest bidder.
 A potential buyer participates by bidding on an item that a seller has listed.
 The person who has offered the highest bid at close of auction wins the right to purchase
the item at that price.
Chapter 2

REQUIREMENTS

2.1 Functional Requirements

Secure Registration is provided as at the time of registration a verification link is sent to the user
in order to check the authenticity of the user, after following the verification link the user account
gets activated.

Further Description about the items are available for each item which are to be bid, with images
as well.

Email is sent to both the seller and buyer after the auction is successfully completed.

2.2 Non- Functional Requirements

2.2.1 Safety Requirements

If there is extensive damage to a wide portion of the database due to catastrophic failure, such as
a disk crash, the recovery method restores a past copy of the database that was backed up to
archival storage (typically tape) and reconstructs a more current state by reapplying or redoing
the operations of committed transactions from the backed up log, up to the time of failure.This
can be implemented with mysql.

2.2.2 Security Requirements

Security systems need database storage just like many other applications. However, the special
requirements of the security market mean that vendors must choose their database partner
carefully.so we have choose the mysql database in order to have the inbuilt security provided by
the mysql.

2.2.3 Software Quality Attributes

 AVAILABILTY:

Since we are hosting our project on the server it will be available all the time.
  CORRECTNESS:

The process of auction should be completed successfully without any error and appropriate item
should be sold to the highest bidder.

 MAINTAINABILITY:

The system should maintain correct record about the bids for particular item and the end date in
order to complete the bid.

 USABILITY:

The system should satisfy maximum number of users needs.

2.3 Hardware Requirements

 Pentium IV or higher, (PIV-300GHz recommended)

 256 MB RAM

 1 Gb hard free drive space

2.4 Software Requirements

 PHP (front end)

 HTML

 JavaScript

 MS Word 97 or later

 Web Browser: Microsoft Internet Explorer 4.0,Mozilla ,Google Chrome or later

 MySQL Server (back end)

 Operating System: Windows XP / Windows7/ Windows Vista

2.5 Feasibility Study

The prime focus of the feasibility is evaluating the practicality of the proposed system keeping in
mind a number of factors. The following factors are taken into account before deciding in favor
of the new system.

2.5.1 Economic Feasibility

Manual auction process takes time and place which leads to cost.But due to the availability of
our auction system this leads to no cost for the above factor.

The tools which are to be used are open source which to reduce the cost of our project.

2.5.2 Technical feasibility

Technically it is feasible to develop this project as the available tools which are to be used
for the development are able to develop this type of projects,so technical problems are taken care
of due to use of the scripting language like php and database like mysql.

2.5.3 Operational Feasibility

The project which is developed is operational as it is an online auction project which is

useful for every such person who are interested to buy their items and sell,also the information to
be given by the seller or buyer can be provided by them with ease.

Chapter 3 DESIGN AND IMPLEMENTATION

3.1 DATA FLOW DIAGRAM

A Data flow diagram (DFD) is used to express system requirements in a graphical form. It is also
known as a bubble chart. A DFD depicts information flow and transform that are applied as data
moves from input. Use of DFD helps to clarify the system requirements. DFD are drawn surging
analysis and are the starting point for the design phase. A DFD could be used represent a physical
system, at the beginning of analysis, or a logical system at alter point in the system development
life cycle. Being graphical, it is easy to understand.
Level-1 DFD
Level 2 DFD
3.2 USE CASE DIAGRAM

3.3 E-R DIAGRAM

 E-R Diagram constitute a technique for representing the logical structure of a database in
a pictorial manner. This analysis is then used to organize data as a relation, normalizing
relation and finally obtaining a relation database.

 ENTITIES : Which specify distinct real-world items in an application.

 PROPERTIES/ATTRIBUTES : Which specify properties of an entity and

relationships.

 RELATIONSHIPS : Which connect entities and represent meaningful dependencies

between them.
3.4 ACTIVITY DIAGRAM
Chapter 5

TESTING

The reason behind testing was to find errors. Every program or software has errors in it, against
the common view that there are no errors in it if the program or software is working. Executing
the programs with the intention of finding the errors in it is therefore testing; hence a successful
test is one which finds errors. Testing is an activity, however it is restricted to being performed
after the development phase is complete, but is carried parallel with all stages of system
development, starting with requirement specification.

Test cases were devised with purpose in mind. A test case is a set of the data that a system will
process as normal input. The software units developed in the system are modules and routines
that are assembled and integrated to perform the required function of the system. Test results
once gathered and evaluated, provide a qualitative indication of the software quality and
reliability and serve as basis for design modification if required. In this phase testing is done at
different levels. Actually testing phase of the implementations works accurately and efficiently
before live operation commences.

5.1 Unit Testing

The unit testing was done after the coding phase was done. The purpose of the unit testing was to
locate errors on the module, independent of he other modules. Some changes in the coding were
done during the testing. Finally all the modules were individually tested from bottom up starting
with smallest and lowest modules and proceeding one at a time.

5.2 Black Box Testing

This method of software testing tests the functionality of an application as opposed to its
internal structures or working(i.e. white box testing). Specific knowledge of the application’s
code/internal structure and programming knowledge in general is not required. Test cases are
built around specifications and requirements, i.e., what the application is supposed to do. It uses
external descriptions of the software, including specifications, requirements, and design to derive
test cases. These tests can be functional or non-functional, though usually functional. The test
designer selects valid and invalid inputs and determines the correct output. There is no
knowledge of the test object’s internal structure.
5.3 White Box Testing

This method of software testing tests internal structures or workings of an application, as

opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective
of the system, as well as programming skills, are required and used to design test cases. The
tester chooses inputs to exercise paths through the code and determine the appropriate outputs.

5.4 Integration Testing

Once the unit was over, all the modules were integrated for integration testing. External and
internal interfaces are implemented and work as per design, the performance of the module is not
degraded.

5.5 Validation Testing

At the culmination of integration testing, software is said to be completely assembled as a

package; interfacing errors have been uncovered and corrected. Then as a final series of software
test, validation tests were carried out.

5.6 Acceptance Testing

This is the final stage in the testing process before the system is accepted for operational use.
Any requirement problem or requirement definition problem revealed from acceptance testing
are considered and made error free.
 BIBLIOGRAPHY

Books:

1) Programming the Word Wide Web, 4th Edition, by Robert Sebesta

2) PHP 6 and MySQL 5 for Dynamic Web Sites by Larry Ullman

3) Learn PHP , MySQL and JavaScript by Robin Nixon

4) Programming PHP by Rasmus Lerdorf, Kevin Tatroe, and Peter MacIntyre

5) Beginning PHP and MySQL by W.J .Gilmore

6) Advanced Javascript by Chuck Easttorn

7) JavaScript, A Beginner’s Guide by John Pollock

Websites:

1) www.w3schools.com

2) www.goodphptutorials.com

3) www.homeandlearn.co.uk

4) www.freewebmasterhelp.com

5) www.stackoverflow.com

6) www.developerfusion.co.uk

Categories:
 Field Type Constraint
Id Tinyintegrer Primary key
Cztegory varchar

Users:

Field Type Constraint

Id Int Primary key
Name Varchar
Password varchar
email varchar
verifystring varchar
active Tiny Integer

Items:

Field Type Constraint

Id Int Primary key
user_id Varchar
Cat_id varchar
name varchar
Starting_ price varchar
End_date Tiny Integer
De