Online

Shopping site
Document

Description
1.
2.
3.
4.
5.
6.

Requirement Specification
Functional Specification
Design specification
Database Design
Test phase and text cases
User Documentation

Page No
3 - 5
6 - 9
10-13
14-15
16-23
24-48

Software Requirements Specification

(SRS)
Abstract
This document fully and formally describes the requirements of the proposed
said project system. It sets out the functional and non-functional
requirements and includes a description of the user interface and
documentation and training requirements.

Introduction
Internet is attracting all type people day by day. The users are increased to
20 million in India alone. As it gets popularity there are many sites offering
products online. People have the choice to buy the product online. But all the
business segment people cant able to sell the product online because the
technology problem. Here we made an attempt to provide generalized
program to suit all the people to sell their products.

Existing System
Presently there are only few sites offering online sales. Online sales is not
much popular and all types of products are not available on internet present.

Proposed System
This general Online shopping site program will help many people who want to
sell their product online. This is general product. Each business people can
customize this program according to their requirement. So it help the many
people to sell their product online with their own site.

Hardware Requirements
Client system requirements:
Pentium II 400 MHz or faster.

Microsoft Windows 98 SE, Windows ME, Windows NT 4.0 Service Pack 6,

Windows 2000, Windows XP or Windows Server 2003.
128MB of RAM (256MB or more recommended).

120MB of hard disk space.

Microsoft Internet Explorer 4.0 or later.

Microsoft Visual SourceSafe 6.0 or later (optional).

VGA or higher monitor resolution.

Mouse or other pointing device.

Server system requirements:

Pentium III 1GHz or faster (Pentium IV 2.8 GHz with Hyper-Threading recommended).
Microsoft Windows NT 4.0 Service Pack 6, Windows 2000 Service Pack 3,
Windows XP Service Pack 1 or Windows Server 2003. Note that Windows Server
editions (Windows NT 4.0 Server, Windows 2000 Server or Windows Server
2003) rather than Professional ones are recommended. For information on
working under Windows XP Service Pack 2
Microsoft SQL Server 8.0 or Microsoft SQL Server 2000 Desktop Engine (MSDE
2000).
Internet Information Server (IIS) 4.x-6.x (optional).

Memory: 512MB of RAM (2GB or more recommended).

1GB hard disk space (2GB or more recommended).

Swap file: 1GB or more.

VGA or higher resolution monitor.

Mouse or other pointing device.

Software Requirements
Windows 2000/XP Operating System.
Visual Inderdev
Asp
MS Access
Internet Explorer

IIS 5.0

Functional Specification
The Functional Specification is created after the Software Requirements
Document. It provides more detail on selected items originally described in
the Software Requirements Document. Some software development
organizations combine these two documents into a single document.
The Functional Specification describes the features of the software product. It
describes the product's behavior as seen by an external observer, and
contains the technical information and data needed for the design. The
Functional Specification defines what the functionality will be, but not how
that functionality will be implemented.
The software engineer uses the Functional Specification document to create a
detailed design document that explains in detail how the software will be
designed and developed. The detailed design work may further decompose
and translate the functional requirements into pseudocode, and from there
into a computer module or program.
The functional specification translates the Software Requirements Document
into a technical description that:
Ensures that the product feature requirements are correctly
understood before moving into the next step, the software design
process.
Clearly and unambiguously provides all the information necessary to
design the software.

Developing Functional Specification Contents

The Functional Specification contents are determined by the project manager,
the software developer, and typical end-users.
The end-users are important members of this team, because they will help
ensure the software will meet the business and engineering needs of those
who will use the software. The project's user group is a good source for
information and review. For guidance on drafting a functional specification,
please see the links in the Background Material and Examples section below.

Functional Specification Scope

The Functional Specification includes specific information about each
functional requirement of the software. The Functional Specification should
describe, for each functional requirement:
Purpose - What the function is intended to accomplish.
Input - What inputs will be accepted, in what format the inputs arrive,
sources for the inputs, and other input characteristics.
Process -The steps to be performed, algorithms, formulas, or
techniques to be used. Software implementation details are not
included, however.
Output - Desired outcomes such as the output form (e.g. report
layout), the destination of the output, output volume and timing, error
handling procedures, and units of measure.
Usability items need to be included in the Functional Specification. These are
features that ensure user friendliness of the software. Examples include clear
error messages, input range checking as soon as entries are made, and order
of choices and screens corresponding to user preferences.

FUNCTIONAL DESCRIPTION:
The problem under study is being divided into several
modules/functions discussed below to understand the approach to the
solution in the broader way:
Main and Login Page : The main page, neatly designed page, here
login option is provided to login. Also new signup option is provided to
for new user to signup.
Product Category Display page : This screen display all the main
categories from this point user can select any category and they can
proceed to select the products in this category.
Product Selection Screen : This search screen. Option must be
provide to select the product based on name. select product based on
the category and based on the company. Etc.,
Product search result screen : This screen shows all the products
under the search criteria. If there are no products under this search
criteria then system will give the message that there are no products
found under this category. Also option is provided to select the
products.
View Cart Screen : View cart screen shows all the selected items,
here quantity as to be entered. And also option is provided to deselect
the products.
Order Details Screen : This screen shows the final products in the
view cart. This gives product list, quantity, Total Amount etc., So user
will get the clear information that how much is the total amount of this
selection.
Order Confirmation Screen : This is the final screen in buying
process. Here customer as confirm the order.

Software Design Specification

The Software Design Specification (SDS) given in this outline are guidelines to the
contents of your SDS. The document should present the conceptual and detailed
technical design of the software/module that you are developing.

Introduction
Purpose of this Document
This Software Design Specification (SDS) document contains a statement of the
design of the above title project. In an SDS, the designers are supposed to provide
an unambiguous design of the product. The design should contain an explanation of
a way to carry out each of the product specifications written in the Software
Requirements Specification (SRS). The design then serves as a guide to the
developers who write the code and actually create the product. The SDS discusses
how the program is separated into modules, how the modules interact with each
other, and how users see the program. The SDS also looks into several design
considerations, including design tradeoffs and code reusability.
Scope of the Development Project
The project Tool is a new project which creates an interactive and easy program. The
package serve to the end user customers. Eventually, we hope to reach a broader
audience.
Definitions, Acronyms, and Abbreviations

Action Script - Action Script is a tool used to write the code that controls the
actions in animated Flash presentations.
Asp.net Microsoft web based project development tool
C, C++ - The names of two object oriented programming languages
commonly used in industry.
CEO - Chief Executive Officer.
Form is object holder in Visual Basic Language. Defines single screen.
HTML - Hypertext Markup Language. A language used to create Web
documents.
IIS Internet Information Server 5.0
Internet Explorer Microsoft Internet Browser version 6.0
MS Access Microsoft developed Database Program.
Oracle Oracle Corporation RDBMS database program.
SDS - Software Design Specification document.
SQL Server Microsoft RDBMS software.
SRS - Software Requirements Specification document.
Visual Basic 6.0 Programming Language
VB.net Microsoft dot net Programming tool

System architecture description

Document Outline
Here is the outline of the proposed template for software design specifications. Please
note that many parts of the document may be extracted automatically from other sources
and/or may be contained in other, smaller documents. What follows is just one suggested
outline format to use when attempting to present the architecture and design of the entire
system as one single document. This by no means implies that it literally is a single
document (that would not be my personal preference):
Major Screens/Page

Description

Main and Login Page

Main page

Product Category Display page

Display all the categories

Product Selection Screen

products Search screen

Product search result screen

display the products

View Cart Screen

Selected item display

Order Details Screen

Order details

Order Confirmation Screen

after confirms the details.

Detailed description of components

Main and Login Page : The main page, neatly designed page, here
login option is provided to login. Also new signup option is provided to
for new user to signup.
Product Category Display page : This screen display all the main
categories from this point user can select any category and they can
proceed to select the products in this category.
Product Selection Screen : This search screen. Option must be
provide to select the product based on name. select product based on
the category and based on the company. Etc.,
Product search result screen : This screen shows all the products
under the search criteria. If there are no products under this search
criteria then system will give the message that there are no products
found under this category. Also option is provided to select the
products.
View Cart Screen : View cart screen shows all the selected items,
here quantity as to be entered. And also option is provided to deselect
the products.
Order Details Screen : This screen shows the final products in the
view cart. This gives product list, quantity, Total Amount etc., So user
will get the clear information that how much is the total amount of this
selection.
Order Confirmation Screen : This is the final screen in buying
process. Here customer as confirm the order.

Database Design

Basket
Login Id
Pro Id
Qty

Text
Integer
Integer

O Date

Date

O No

Integer

CureCentre
Center ID
Category
C Name
Contact

Integer
Text
Text
Text

Address1

Text

Address2

Text

City

Text

Pin

Integer

Estd

Text

Spl

Text

Brief

adLongVarWChar

Comment

Text

DesTable
Des

Text

type

Text

DesTable2
Des

Text

type

Text

Doctor
DocID
DocName
Quali
Cname

Integer
Text
Text
Text

Add1

Text

Add2

Text

City
State

Text
Text

Pin

Integer

Spl

Text

Timing

Text

Desc

adLongVarWChar

Comment

Text

FranMain
LoginId

Text

Password

Text

MName

Text

Add1

Text

Add2

Text

Add3

Text

add4

Text

add5

Text

add6

Text

Pin
PhoneNo

Text
Text

Mobile

Text

email

Text

dob

Date

sex

Text

AIncome
BType
CompName
WebName
NoVis

Text
Text
Text
Text
Text

NoEx

Text

AcNo

Text

AcName

Text

BankName
BrName
DOJ
MType

Text
Text
Date
Byte

member
LoginId

Text

Password

Text

MName

Text

Add1

Text

Add2

Text

Add3

Text

Pin
PhoneNo

Text
Text

Mobile

Text

email

Text

dob

Date

sex

Text

AIncome

Text

DOJ
MType

Date
Byte

OrderDet
OrdNo

Integer

LoginId

Text

Proid

Integer

Qty

Integer

OrderMas
OrdNo

Integer

LoginId

Text

DoctorName
ODate

Text
Date

OtherCharges

Currency

GrandTotal

Currency

CMem

Text

Apr

Boolean

OthProduct
ProID
ProName

adDouble
Text

ProComp
ProCat
Price

Text
Text
Currency

Package

Text

Dosage

Text

Description

Text

Ingred

Text

Used

Text

Location
ImageID
Scope

Text
Text
Text

Plant
PlantID
pcat

Integer
Text

IName

Text

Sname

Text

Desc

adLongVarWChar

location

Text

Product
ProID

adDouble

ProName

Text

ProComp

Text

ProCat
Price

Text
Currency

Package

Text

Dosage

Text

Description

Text

Ingred

Text

Used

Text

Location
ImageID

Text
Text

Scope

Text

ProGrp

Byte

Train
TrainID

Integer

Category

Text

tName

Text

Principal
Address1

Text
Text

Address2

Text

City

Text

Pin

Integer

Estd

Text

Spl

Text

Brief

adLongVarWChar

Comment

Text

Yoga
YogaID

Integer

Name

Text

Type
Category

Text
Text

Desc

adLongVarWChar

Use

Text

yogafor
Comment

Text
adLongVarWChar

Testing
Introduction
This document is intended to be used throughout the coding and testing phases of
the project. It outlines the procedures used for testing and verification of the code.
The document also describes the integration procedures and the order in which
modules will be coded, and describes the test procedures and results of testing.
This section deals with the details of the classes of tests which must be conducted to
validate the functions, performance, and the constraints. This is achieved basically by
the means of testing which plays a vital role in the development of the software. The
various low level testing which can be grouped on a broader sense are discussed as
below:
There are three levels of testing:
1. Unit Testing -- Each module will be tested separately to ensure that it is
working before being combined with other modules.
2. Integration Testing -- Related modules will be integrated and tested
together before being placed into the system.
3. System Testing -- The entire system will be tested together after integration
is complete. System testing includes function, acceptance, installation and
regression testing. System testing will involve some beta testing by the client.
Notes
All testing has been carried out using some sample data.
Each section in the remainder of this document has lists of test criteria that must be
satisfied for the system to have passed that section of testing. In front of the each
criterial test Passed or Failed is written.

Unit Testing
The purpose of unit testing is to uncover errors in the smallest software unit -- the
routine. Each routine will be tested individually using black box-oriented tests. The
programmer of each module will design a set of test cases for that module and
ensure that the module is fully tested. Important or complex routines will also be
tested by at least one other person.

Integration Testing
This section describes the integration strategy and procedures for the system. It
gives the order in which modules will be developed and how they will be integrated.
It also describes the specific tests that will be performed on integrated sets of
modules. Note: It is important that each module be thoroughly tested as a unit
before being integrated with other modules.
Integration testing of unit tested modules is necessary to ensure that:

modules interface correctly with each other;

one module does not have inadvertent, undesirable effects on another
module;
submodules (routines) combine to produce the desired functions of the major
module;
interfaces to, and use of global data structures are consistent.

System Testing
Functional Requirements Testing
The functionality tests should be performed by the application representatives and
treat the whole system as a black box using the actual applications or middleware.
The aim of these tests is to verify the overall functionality of the system.
This will be performed by a section by section walkthrough of the SRS functional
requirements section. All functional requirements in the SRS must be fulfilled.

Beta Testing
Method
This will be performed by the client, and by potential users of the system at the
Bureau of Meteorology. Users will be given a copy of the system to try out. Any
problems with the system will be reported back to the group.
Beta Testing
To help us achieve the best possible result with our project, we have decided to get
as much input as possible from potential users of our system.
Bugs.
If unexpected events happen while using project,
Alterations.
If there is anything missing from the system, that you would like to see there, we
would also like to know about it. Most likely we will not be able to implement the
changes to the current system (due to time restraints), but when the full system is
written next year, it will most likely be present.

All Comments... Can be sent to us in various ways.

Please include your name and email address in any correspondence.

Results
Comments received from the customers:
Alpha testing - prototype 2 of system

Performance and Stress Testing

A set of tests have been developed for performance and stress testing. Performance
tests will ensure that the system responds in a reasonable time to user input (as
defined in the SRS). The aim of stress testing is to try to break the program by
giving it abnormal or extreme input quantity, frequency or volume.
Performance testing will be performed at the client's site after installation. According
to the SRS:
The system must respond to all reports within 10 seconds on an Pentium IV
computer with a load average less than 1.
Performance criteria satisfied.
Stress testing with extreme and abnormal input cases has been been performed
where necessary on individual routines in the Unit Testing section.

Stress testing satisfied.

Acceptance Testing
Acceptance testing consists of a suite of tests to be performed in the presence of the
client before he accepts the system. It will consist of the function tests, performance
tests (at the client's site), a walk-through of the user manual and the final
demonstration.

Function tests accepted.

Performance tests accepted.
User manual walkthrough accepted. Will be held performed along with
Installation Testing.
Final demonstration accepted.

Installation Testing
Installation tests will check the installation and configuration procedure as well as
any missing dependencies.
Installation tests test the installation and configuration procedures. These tests are a
set of scripts that automatically download all necessary packages and install them.
Acceptance testing will be repeated after installation of the system at the Customer
Place. This is to ensure that the system works correctly in the Customer Place.
Note: System has not been installed for the client yet. Will be installed this week.
Some specific points that also need to be tested are:
1. Directory paths for data and help files are set up correctly and can be found
by the system.
2. Check for necessary third party controls.
3. All IDL library functions can be found by the system.
4. All fonts for the text tool can be found and loaded -- beta testing uncovered
some problems loading some fonts.
5. Check Printer drivers are installed properly.

Regression Testing
The selective retesting of a software system that has been modified to
ensure that any bugs have been fixed and that no other previously
working functions have failed as a result of the reparations and that
newly added features have not created problems with previous
versions of the software. Also referred to as verification testing,
regression testing is initiated after a programmer has attempted to fix
a recognized problem or has added source code to a program that may
have inadvertently introduced errors. It is a quality control measure to
ensure that the newly modified code still complies with its specified
requirements and that unmodified code has not been affected by the
maintenance activity.
Regression testing was not usually necesary, because most of the
errors detected were very localised, and did not affect other functions
in an adverse manner.

Screen Shots

Main and Login Page

Product Category Display Page

Product Selection Screen

Product search result screen

View Cart Screen

enter quantity here.

Order Details Screen

Order Confirmation Screen