Online Shopping site

Document

Description Page No

1. Requirement Specification 3 - 52. Functional Specification 6 - 93. Design specification 10-134. Database Design 14-155. Test phase and text cases 16-236. User Documentation 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.

IntroductionInternet 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 can’t 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 SystemPresently 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 SystemThis 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 InderdevAspMS AccessInternet ExplorerIIS 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 SpecificationThe 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 Text

Pro Id Integer

Qty Integer

O Date Date

O No Integer

CureCentre

Center ID Integer

Category Text

C Name Text

Contact 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 Integer

DocName Text

Quali Text

Cname Text

Add1 Text

Add2 Text

City Text

State 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 Text

PhoneNo Text

Mobile Text

email Text

dob Date

sex Text

AIncome Text

BType Text

CompName Text

WebName Text

NoVis Text

NoEx Text

AcNo Text

AcName Text

BankName Text

BrName Text

DOJ Date

MType Byte

member

LoginId Text

Password Text

MName Text

Add1 Text

Add2 Text

Add3 Text

Pin Text

PhoneNo Text

Mobile Text

email Text

dob Date

sex Text

AIncome Text

DOJ Date

MType Byte

OrderDet

OrdNo Integer

LoginId Text

Proid Integer

Qty Integer

OrderMas

OrdNo Integer

LoginId Text

DoctorName Text

ODate Date

OtherCharges Currency

GrandTotal Currency

CMem Text

Apr Boolean

OthProduct

ProID adDouble

ProName Text

ProComp Text

ProCat Text

Price Currency

Package Text

Dosage Text

Description Text

Ingred Text

Used Text

Location Text

ImageID Text

Scope Text

Plant

PlantID Integer

pcat Text

IName Text

Sname Text

Desc adLongVarWChar

location Text

Product

ProID adDouble

ProName Text

ProComp Text

ProCat Text

Price Currency

Package Text

Dosage Text

Description Text

Ingred Text

Used Text

Location Text

ImageID Text

Scope Text

ProGrp Byte

Train

TrainID Integer

Category Text

tName Text

Principal Text

Address1 Text

Address2 Text

City Text

Pin Integer

Estd Text

Spl Text

Brief adLongVarWChar

Comment Text

Yoga

YogaID Integer

Name Text

Type Text

Category Text

Desc adLongVarWChar

Use Text

yogafor Text

Comment 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 TestingThe 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 TestingFunctional 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