Software Requirement Specification
for
Online Shopping System
(For Furniture shop)
Table of Contents
1. Introduction
1. Purpose
2. Scope
3. Definitions
1. Overview
4. Additional Information
2. General Description
3. Functional Requirement
1. Description
2. Technical Issues
4. Interface Requirement
1. GUI
2. Hardware Interface
3. Software Interface
5. Performance Requirement
6. Design Constraints
7. Other non-Functional requirement
1. Security
2. Reliability
3. Availability
4. Maintainability
5. Portability
8. Operational Scenario
9. Preliminary Schedule
1. Introduction
1. Purpose
The Online Shopping System (OSS) for furniture shop web
application is intended to provide complete solutions for
vendors as well as customers through a single get way using the
internet. It will enable vendors to setup online shops, customer
to browse through the shop and purchase them online without
having to visit the shop physically.
2. Scope
This system allows the customer’s to maintain their product for
add or remove the product over the internet.
3. Definitions
OSS- Online shopping System (for furniture shop)
SRS- Software Requirement Specification
GUI- Graphical User Interface
Stockholder- The person who will participate in system
Ex. Customer, Administrator etc.
1. Overview
This system provides an easy to solution customer’s to buy the
product without go to the shop and also shop owner to sale the
product.
4. Additional Information
The system work on internet server, so it will operated by any
end user for the buying purpose.
2. General Description
The Online Shopping system (OSS) application helps to manage
the items in the shop and also help customers to purchase. The
online shopping system will use the internet as the sole method
for selling goods to its consumers.
3. Functional Requirement
This section provides requirement overview of the system.
Various functional modules that can be implemented by
the system will be -
1. Description
3.1 Registration
If customer wants to buy the product then he/she must be
registered, unregistered user can’t go to the shopping cart.
3.2 Login
Customer logins to the system by entering valid user id and
password for the shopping.
3.3 Changes to Cart
Changes to cart means the customer after login or registration
can make order or cancel order of the product
3.4 Payment
For customer there are many type of secure billing will be
prepaid as debit or credit card, postpaid as after shipping, check
or bank draft.
3.5 Logout
After the payment of the product the customer will log ged out.
3.6 Report Generation
After all transaction the system can generate the portable
document file (.pdf) and then sent one copy to the customer’s
Email-address and another one for the system data base to
calculate the monthly transaction .
2. Technical Issues
This system will work on client-server architecture. It will
require an internet server. The system should support some
commonly used browser such as IE etc.
4. Interface Requirement
Various interfaces for the product could be-
1. Login Page
2. Registration Form
3.There will be a screen displaying information about product that the
shop having.
4.If the customers select the buy button then another screen of
shopping cart will be opened.
1. Login Page
2. Registration Form
3. Product Page
4. Shopping Cart
2. Hardware Interface
The System must run over the internet, all the hardware shall
require to connect internet will be hardware interface for the
system. As for e.g. Modem, WAN – LAN, Ethernet Cross-
Cable.
3. Software Interface
The system is on server so it requires the any scripting language
like PHP, VBScript etc.
The system require Data Base also for the store the any
transaction of the system like MYSQL etc. system also require
DNS(domain name space) for the naming on the internet. At the
last user need web browser for interact with the system.
5. Performance Requirement
There is no performance requirement in this system because the server
request and response is depended on the end user internet connection.
6. Design Constrain
The system shall be built using a standard web page development tool
that conforms to Microsoft’s GUI standards like HTML, XML etc.
7. Other non-Functional requirement
1. Security
The system use SSL (secured socket layer) in all transactions
that include any confidential customer information.
The system must automatically log out all customers after a
period of inactivity.
The system should not leave any cookies on the customer’s
computer containing the user’s password.
The system’s back-end servers shall only be accessible to
authenticated administrators.
Sensitive data will be encrypted before being sent over insecure
connections like the internet.
2. Reliability
The system provides storage of all databases on redundant
computers with automatic switchover.
The main pillar of reliability of the system is the backup of the
database which is continuously maintained and updated to
reflect the most recent changes.
3. Availability
The system should be available at all times, meaning the user
can access it using a web browser, only restricted by the down
time of the server on which the system runs. In case of a of a
hardware failure or database corruption, a replacement page
will be shown. Also in case of a hardware failure or database
corruption, backups of the database should be retrieved from
the server and saved by the administrator. Then the service will
be restarted. It means 24 X 7 availability.
4. Maintainability
A commercial database is used for maintaining the database and
the application server takes care of the site. The maintainability
can be done efficiently.
5. Portability
The application is HTML and scripting language based. So The
end-user part is fully portable and any system using any web
browser should be able to use the features of the system,
including any hardware platform that is available or will be
available in the future.
An end-user is use this system on any OS; either it is Windows
or Linux.
The system shall run on PC, Laptops, and PDA etc.
8. Operational Scenario
The customer wants to buy item. The system shows all product
categories to customer. If customer select item then they listed in
shopping cart for buying.
The payment will made with credit card or bank check. If customer
wants to cancel the order before shipping then he or she can cancel it.
Customer can see the buying report on account detail.
9. Preliminary Schedule
Online shopping system
LOGIN
Manage customer
Brouse category
database
Manage customer add or remove item
database from cart
Payment
Update item
category
Administrator
approve/reject
shop creation By credit card By check
Customer
Shipping order Give feed back
Log out
Visit site View account detail
Visitor
Creat new account Cancle order
before shipping
3. Use Case diagram for online shopping system.
Online shopping system
LOGIN
Manage customer
Brouse category
database
Manage customer add or remove item
database from cart
Payment
Update item
category
Administrator
approve/reject
shop creation By credit card By check
Customer
Shipping order Give feed back
Log out
Visit site View account detail
Visitor
Creat new account Cancle order
before shipping
4. Data-Dictionary diagram for online shopping system.
Order_lines Order Customers
1
1
quantity order_number customer_id
cost_eatch order_date customer_firstname
shipped credit_card_number customer_lastname
order_filled customer_address
customer_phone
customer_email
Product
product category Shipping
product_id
product_name
category_name product_description shipping_id
category_content retail_price shipping_customer id
category_list product_number shipping_date
shipping_cancle
5. DFD diagram for online shopping system.
5.1 context level:
Online
User shoppin Products
g
System
5.2 level 1:
Search
User Products
product
Customer
login
data
Reviews
View
Specification
specification
Images
5.3 level 2:
User Addtocart Products
Edit cart
Checkout
6. Class diagram for online shopping system.
User Customer
-login_id:string{id} -id:string{id}
-pass:string -address:address
-state:userstate -phone:phone
Payment
-1
1 -1 -id:string
* -1 -paid:date
0..* -total:real
* -1
-0 * -*
Account
1 -id:string -1
-is_closed:boolean 1
-open:dtae
-1 -close:date 1 * -*
* -0..1* -1 Order
-number:string 1
Shopping cart -orderd:date
-shipped:date
-created:date -total:real -1
1 -1 -1 1
Lineitem
-* -quantity:integer -*
-price:price
* *
1 -1
1 -1
Product
-id:string{id}
-name:string
-supplier:supplier
9. Testing and debugging of online shopping system.
Software testing is a process of running with intent of finding errors in
software. Software testing assures the quality of software and
represents final review of other phases of software like specification,
design, code generation etc.
1. Unit testing:
Unit testing emphasizes the verification effort on the smallest unit
of software design i.e.; a software component or module. Unit testing is a
dynamic method for verification, where program is actually compiled and
executed. Unit testing is performed in parallel with the coding phase. Unit
testing tests units or modules not the whole Software. I have tested each
view/module of the application individually. As the modules were built up
testing was carried out simultaneously, tracking out each and every kind
of input and checking the corresponding output until module is working
correctly.
2. Integrating testing:
In integration testing a system consisting of different modules is
tested for problems arising from component interaction. Integration testing
should be developed from the system specification. Firstly, a minimum
configuration must be integrated and tested. In my project I have done
integration testing in a bottom up fashion i.e. in this project I have started
construction and testing with atomic modules. After unit testing the modules
are integrated one by one and then tested the system for problems arising
from component interaction.
3. validation testing:
It provides final assurances that software meets all functional,
behavioral & performance requirement. Black box testing techniques are
used.
There are three main components
- Validation test criteria (no. in place of no. & char in place of char)
- Configuration review (to ensure the completeness of s/w configuration.)
-Alpha & Beta testing-Alpha testing is done at developer’s site i.e. at home
& Beta testing once it is deployed. Since I have not deployed my
application, I could not do the Beta testing.
Test Cases- I have used a number of test cases for testing the product. There
were different cases for which different inputs were used to check whether
desired output is produced or not.
1.Addition of a new product to the cart should create a new row in the
shopping cart.
2. Addition of an existing product to the cart has to update the
quantity of the product.
3. Any changes to items in the cart have to update the summary correctly.
4.Because same page is inserting data into more than one table in the
database atomicity of the transaction is tested.
5.The state of the system after a product has been dragged in to the cart
should be same as the state of the system if the same product is added to the
cart by clicking a button.
9.4 white box testing:
In white box testing knowing the internal working of the product, tests can
be conducted to ensure that internal operations are performed according to
specification and all internal components have been adequately exercised. In
white box testing logical path through the software are tested by providing
test cases that exercise specific sets of
conditions and loops.
Using white-box testing software developer can derive test case that
•Guarantee that all independent paths within a module have been exercised
at least once.
• Exercise all logical decisions on their true and false side.
• Exercise all loops at their boundaries and within their operational bound.
• Exercise internal data structure to ensure their validity.
At every stage of project development I have tested the logics of the
program by
supplying the invalid inputs and generating the respective error
messages.
9.5 performance testing:
Remote testing:
users Loop count Cart detail Shop product page
page(MS) (MS)
100 150 792 8312
500 150 6392 99069
1000 150 20457 227056
Observation:
Response Time of a complex webpage with database and business
logic functions is far more than a simple webpage. The Response times of
remote testing are better than those of local testing when the number of users
is comparatively lesser.
10. Time line chart for online shopping system.
