Software Requirement Specification (SRS) for

Web Store System

(WSS)

1. Introduction

1.1 Purpose
This is the Software Requirements Specification for Web Store System. This Web Store System
is designed to allow new online store owners a quick and easy means to setup and perform sales
and other core business over the internet. This document will outline all of the functions,
capabilities and requirements for Web Store System

1.2 Document Conventions

None

1.3 Intended Audience, Reading Suggestions

This document is intended to flush out the requirements by the customer . The customer can
review this document to ensure their needs along with the needs of their user’s are being met in
their new Web Store System. The development team will also use this document for guidance on
overall design and implementation of the Web Store System. The test and verification team can
reference this to ensure the requirements are being meet for the customer. Finally, the tech writer
will use this to assist with user documentation.

1.4 Project Scope

The Web Store System will:
• Manage customer accounts
• Manage an online store inventory
• Manage a customer’s “Shopping Cart”
• Confirm Orders
• Have an unambiguous interface to assist in browsing the categories and products
• Use Secure Socket Layer (SSL) for security
• Have an availability of 99.999%
• Allow an optional mirror site for reliability and backups
• Feature interface for future software enhancement via “Plug-ins”

1.5 References
This document draws insight from the Web Store System Overview, Functional Needs
Statement, and Stakeholder Goals List.

2. Overall Description

2.1 Product Perspective

Web Store System is a new system designed for users new to the online E-commerce. This will
be a website. The Web Store will be a quick and easy means to setup and operate an online Web
Store.

2.2 Product Features

Account Management (AM) (High Priority): AM allows users to create, edit, and view accounts
information. It also allows the user to login/out of the system.
Search Engine (SE) (Medium Priority): SE is the tool that assists the user in finding a specific
item in the database. It can receive search criteria, find search criteria, and return the results of
the search.
Product Management (PM) (High Priority): PM allows sales personnel to manage the product
line shown on the web site.
Shopping Cart (SC) (Medium Priority): SC is temporary storage for customers shopping on the
web. Items from the inventory can be reserved in a virtual cart until the customer decides to
purchase them.
Purchasing and Payment (PP) (High Priority): PP is used to approve and transfer payment from
buyers when purchasing items in the cart.
2.3 User Classes
System Administrator: Is generally the owner that takes care of maintenance for the Web Store
system. The administrator will be in charge of assigning privileges of accounts. Suggested more
than one individual can have administrator privilege to ensure advisability. Full documentation
will be provided to the Administrator to assist with this process.
Sales Personnel: Is generally the owner of the Web Store tasked with updating inventory and
product line descriptions. Once added, sales personnel can add, delete and change descriptions,
pictures, prices, and when ready flag items for customers to buy.
Customer: A customer is an individual wishing to purchase inventory from Web Store System.
The Web Store System will have a variety of clientele depending upon the inventory loaded on
the Key. When creating a new account on Web Store System it will default as a customer
account. Later if the account needs to be upgraded the administrator can accomplish this via the
administrator interface.

2.4 Operating Environment

OE-1: Web Store shall operate with the following internet browsers: Microsoft Internet Explorer
version 6 and 7, Netscape Communicator Version 4 and 5.
OE-2: Web Store shall operate on an Intel based system with Slackware Linux 2.6 and Apache
Web Server. Although maintenance documentation will be supplied and the operating system
will be tested, the developers of this Web Store are not responsible for the functionality of the
operating system.
OE-3: The system shall use SQL based database to store inventory information.

2.5 Design and Implementation Constraints

CO-1: Must use a SQL based database. SQL standard is the most widely used database format.
Restricting to SQL allows easy of use and compatibility for Web Store.
CO-2: Compatibility is only tested and verified for Microsoft Internet Explorer version 6 and 7,
Netscape Communicator Version 4 and 5. Other versions may not be 100% compatible. Also
other browsers such as Mozilla or Firefox may not be 100% compatible.
2.6 User Documentation
UD-1: Shall install online help for users via the web interface
UD-2: Shall deliver Operations and Maintenance manual, Users Guide book, and Installation
Instructions for the Administrator.

2.7 Assumptions and Dependencies

AD-1: Assume the customer has an access to internet.
AD-2: Assume the customers have an online payment mode.

3. System Features

3.1 Customer Accounts

3.1.1 Description And Priority
Customers will be able to create accounts to store their profiles, contact information, purchase
history, and confirm orders. This is a high priority system feature. Security methods will ensure
that customer accounts remain confidential and resistant to tampering.
3.1.2 Stimulus/Response Sequences
· Web Browser initiates request to Web Server via HTTPS
· Web Server parses request
· Web Server submits request to Service
· Service picks up request
· Service runs task
· Service returns results
· Web Server checks for completion
· Web Server returns results to Web Browser
· Web Browser displays results
3.1.3 Functional Requirements
Customers will be able to create accounts to store their customer profiles, configure contact
information, view their purchase history, and confirm orders. Customers will be able to register,
log in, and log out of their accounts. Furthermore, Customer profiles will also include payment
information, such as the ability to store credit card information, and address information.

3.2 Inventory Management

3.2.1 Description And Priority
Inventory management will allow for the placement of products into multi-tiered categories. This
is a medium priority system feature.
3.2.2 Stimulus/Response Sequences
Same as 3.1.2
3.2.3 Functional Requirements
Products will be stored in multi-tiered categories; a category can contain sub categories or
products. The inventory management will allow for administrators to update the categories, the
products placed in categories, and the specific product details.

3.3 Shopping Cart

3.3.1 Description And Priority
Customers will be able to add and store products for purchase within the shopping cart. This
feature is a medium priority system feature.
3.3.2 Stimulus/Response Sequences
Same as 3.1.2
3.3.3 Functional Requirements
Customers will also be able to add products into the shopping cart. The shopping cart will clearly
display the number of items in the cart, along with the total cost. The customer will also be able
to add to or remove products from the shopping cart prior to checkout and order confirmation.

3.4 Order Confirmation

3.4.1 Description And Priority
Order confirmation will allow the customer to review their order after checkout prior to
confirmation. This is a medium priority system feature.
3.4.2 Stimulus/Response Sequences
Same as 3.1.2
3.4.3 Functional Requirements
Customers will be able to confirm the order after checkout. If the order is incorrect, the customer
will be able to revise and update their order. The customer will then receive a confirmation email
with the specific order details.

3.5 Interface
3.5.1 Description And Priority
The interface will be presented to the customer in a web browser. The interface must remain
consistent among various web browsers and be intuitive to the customer. This is a medium
priority system feature.
3.5.2 Stimulus/Response Sequences
Same as 3.1.2
3.5.3 Functional Requirements
Customers will be presented with an unambiguous interface to assist in browsing the categories
and products. Customers will be able to search for products matching their search criteria. The
interface will be compatible with all major web browsers such as Internet Explorer, Mozilla
Navigator, Mozilla Firefox, Opera, and Safari.

4. External Interface Requirements

4.1 User Interfaces

The user interface designed is very friendly. User-interface will be ADA compliant and
otherwise easy to use for the general electorate.

4.2 Hardware Interfaces

None.

4.3 Software Interfaces

SI-1: WebOrder Browser Interface
SI-1.1: The order database of WebOrder will communicate with the account system through a
programmatic interface for the billing operations.
SI-1.2: Through programmatic interface, WebOrder will transmit information of items ordered
by customers to the Inventory management system.

4.4 Communications Interfaces

CI-1: The WebOrder system shall send an e-mail confirmation to the customer that the items
they ordered will be delivered to the shipping address along with tracking number.
CI-2: The WebOrder system shall send an e-mail to System Administrator regarding any
technical queries from customers or sales people.

5. Quality Attribute Requirements

5.1 Performance Requirements

· The system shall be able to handle 1000 customers logged in concurrently at the same time.
· The system shall be able to retrieve 200 products per second.
· The system shall be able to add product to shopping cart in less than 2ms.
· The system shall be able to search for a specified product in less than 1 second.
· The system shall be able to email customer and vendor in less than 1 second.
· The system shall be able to validate credit card in less than 2 seconds.
· The system shall be able to acquire shipping charges in less than 2 seconds.
· The system shall be able to restore 1000 records per second.

5.2 Safety Requirements

· The system will do periodic backups through a live internet connection.

5.3 Security Requirements

· The system shall validate credit cards against fraud.
· The system shall encrypt all sensitive information via https.
· The system shall encrypt all customer data in database.
· The system shall auto detect IP DOS attacks and block IP automatically.
· The system shall detect consecutive failed login attempts.
· The system shall be protected by open source firewall called Firestarter. http://www.fs-
security.com/

5.4 Availability Requirements

· The system shall have an availability of 99.99%.

5.5 Efficiency Requirements

· The system shall perform searches via Dijkstra's shortest path algorithm.
· For returning customers, the system shall validate 'existing' credit card in system after each log
in.
· The system shall automatically compress image files that are too large in size.
· The system will employ on demand asynchronous loading for faster execution of pages.
· The system shall validate email address existence.

5.6 Usability Requirements

· The system shall be easy to use
· The system shall be easy to learn
· The system shall utilize help bubbles to assist managers, customers, and administrators
· The system shall employ easy to locate buttons
· The system shall prompt customer with friend easy to read error messages.
· The system shall utilize consistent symbols and colors for clear notifications.

5.7 Maintainability Requirements

· The system shall utilize interchangeable plugins.
· The system shall be easily updatable for fixes and patches.
· The system shall create logs of all changes, updates, or fixes that are done to the site.
· The system shall be easy to upgrade.
5.8 Portability Requirements
· The system shall be extremely portable as it can be accessed on the web.

5.9 Testability Requirements

· The system should be able to run under debug mode.
· The system should be able to run test credit card transactions.
· The system should be able to run test shipping orders.
· The system should be able to create test environment of weborder system.

6. Other Requirements
· The system hardware shall be fixed and patched via an internet connection.
· The system shall adhere to the following hardware requirements:
· 4GB Flash ram chip
· 128MB SDRAM
· Intel XScale PXA270 520-MHz chipset
· OS: Apache web server
· Database: MySQL

Appendix A: Use Cases Templates

Customer Use Cases

Register Customer
Goal:
Register a new customer account with the system.
Actors:
Customer
Weborder System
Preconditions:
Customer must be able to access the web order system via a web browser with HTTPS.
Triggers:
Customer clicks button or link to "Register"
Basic Scenario:
1. Customer first clicks on the button or link to initiate registration process.
2. System prompts the customer to fill out his/her first name, last name, billing address, shipping
address, email address, and their password.
3. Customer enters fields.
4. System validates the customer's information.
5. System creates a new account for the Customer.
6. System creates a session cookie.
7. System displays an account home page to Customer.
Alternative Scenario:
A1. System recognizes Customer's cookie.
A2. Go to Step 7 (Basic Scenario).
Postconditions:
The Customer registers and creates a new customer account with the system.

Login Customer
Goal:
Login to a customer account with the system.
Actors:
Customer
Weborder System
Preconditions:
Customer account must already be registered.
Triggers:
Customer clicks button or link to "Login"
Basic Scenario:
1. Customer clicks on the button or link to initiate the login process.
2. System prompts the customer for his/her email and password.
3. System verifies the information.
4. System creates session cookie.
5. System displays account home page to the Customer
Alternative Scenario:
A1. System recognizes the Customer's cookie
A2. Go to Step 5 (Basic Scenario).
B1. Customer enters incorrect login information.
B2. System prompts the Customer to resend login details to the email account.
B3. Customer confirms.
B4. System sends an email to the registered email address.
B5. Go to Step 1 (Basic Scenario).
Postconditions:
The Customer is logged into the system.

Edit Customer Details

Goal:
Edit the customer account details.
Actors:
Customer
Weborder System
Preconditions:
Customer must be logged-in on the system.
Triggers:
Customer clicks on the button or link to "Edit Account"
Basic Scenario:
1. Customer clicks the button or link to initiate the process to edit the account.
2. System displays the account home page to the Customer.
3. Customer clicks the button or link in order to edit the account details.
4. System verifies the changes.
5. System stores new account information.
Alternative Scenario:
None
Postcoditions:
The Customer has changed the account details.

Logout Customer
Goal:
Logout the customer account on the system.
Actors:
Customer
Weborder System
Preconditions:
Customer must be logged-in on the system.
Triggers:
Customer clicks on the button or link to "Logout"
Basic Scenario:
1. Customer clicks the button or link in order to initiate logout process.
2. System terminates the session cookie.
3. System displays the home page.
Alternative Scenario:
None
Postconditions:
The Customer is logged out of the system.

Add Item To Cart

Goal:
Customer adds item(s) in the cart
Actors:
Customer
System
Preconditions:
The customer must be logged-in on the system.
Triggers:
Customer clicks the button or link to "Add To Cart".
Basic Scenario:
1. Customer clicks the button or link in order to add to the cart with specified quantity.
2. System adds the item(s) to the cart.
3. System prompts the Customer to edit the quantity or remove the item from cart.
4. Customer confirms the items in the cart.
5. System stores cookie with cart details.
6. Customer returns to product listings.
Alternative Scenario:
A1. Customer terminates the web browser window after adding item(s) to cart.
A2. Customer returns to weborder interface.
A3. System recognizes cookie and goes to step 6 (Basic Scenario) with existing items in
cart.
Postconditions:
The Customer has added item(s) to the shopping cart.

Checkout An Order
Goal:
Customer places and confirms an order for the checkout process.
Actors:
Customer
Weborder System
Preconditions:
1. Customer must be logged-in on the system.
2. Customer must have item(s) in the shopping cart.
Triggers:
Customer clicks button or link to "Ckeckout"
Basic Scenario:
1. Customer clicks the button or link to initiate the checkout process.
2. System calculates order of items in the shopping cart.
3. System appends cookie with flag for checkout process.
4. System presents the customer with the account details and payment methods.
5. Customer confirms account details and payment methods.
6. Customer confirms order.
7. System stores order confirmation and order details.
8. System sends email confirmation to the Customer.
9. System appends cookie with flag for completed checkout process.
Alternative Scenario:
A1. Customer terminates order web browser during order the checkout process.
A2. Customer returns to weborder interface.
A3. System recognizes cookie and goes to step 4 (Basic Scenario).
Postconditions:
The Customer has placed and confirmed an order.

Administrator Use Cases

Login Administrator
Goal:
Login to an Administrator account with the system.
Actors:
Administrator
Weborder System
Preconditions:
Administrator account must already be registered.
Triggers:
Administrator clicks button or link to "Login"
Basic Scenario:
1. Administrator clicks button or link to initiate login process.
2. System prompts the Administrator for email and password.
3. System verifies information.
4. System creates session cookie.
5. System displays account home page to Administrator
Alternative Scenario:
A1. System recognizes Administrator 's cookie
A2. Go to Step 5 (Basic Scenario).
B1. Administrator enters incorrect login information.
B2. System prompts Administrator to resend login details to email account.
B3. Administrator confirms.
B4. System sends email to registered email address.
B5. Go to Step 1 (Basic Scenario).
Postconditions:
The Administrator is logged into the system.

Logout Administrator
Goal:
Logout the Administrator account on the system.
Actors:
Administrator
Weborder System
Preconditions:
Administrator must be logged-in on the system.
Triggers:
Administrator clicks button or link to "Logout"
Basic Scenario:
1. Administrator clicks button or link to initiate logout process.
2. System terminates the session cookie.
3. System displays home page.
Alternative Scenario:
None
Postconditions:
The Administrator is logged out of the system.

Add User
Goal:
Register a new customer, sales person, or administrator account with the system.
Actors:
Administrator
Weborder System
Preconditions:
Administrator must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Administrator clicks button or link to "Add Users"
Basic Scenario:
1. Administrator clicks the button or link to initiate Add user process.
2. System prompts the Administrator to fill out first name, last name, username, email address,
password, and privileges of the user.
3. System validates new user information.
4. System creates a new account for the new user with desired privileges.
5. System displays account home page to Administrator.
Postconditions:
A new customer account is created within the system.

Remove User
Goal:
Remove a user from the system.
Actors:
Administrator
Weborder System
Preconditions:
Administrator must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Administrator clicks button or link to “Remove User"
Basic Scenario:
1. Administrator clicks button or link to initiate the remove user process.
2. System prompts the Administrator to select a user by searching or viewing a list of users.
3. System displays user information.
4. System confirms deletion of selected user.
5. System displays account home page to Administrator.
Postconditions:
An account has been deleted within the system.

Change User Properties

Goal:
Alter properties such as passwords and privileges of the user.
Actors:
Administrator
Weborder System
Preconditions:
Administrator must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Administrator clicks button or link to “Change User Properties"
Basic Scenario:
1. Administrator clicks the button or link to initiate change user properties process.
2. System prompts the Administrator to select a user by searching or viewing a list of users.
3. System displays the user information.
4. System alters the user properties.
5. System displays the account home page to Administrator.
Postconditions:
An account has been altered within the system.

Add Product
Goal:
Add a product to the system.
Actors:
Admin
Weborder System
Preconditions:
Admin must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Admin clicks the button or link to "Add Product"
Basic Scenario:
1. Admin clicks the button or link to initiate Add Product process.
2. System prompts the Admin to fill out product name, product id, product
description, product price, upload a product image, number of items in inventory, and
availability of product.
3. System validates the new product information.
4. System creates a new product page for the new product.
5. System displays the newly created product page.
Postconditions:
A new product is created within the system.

Remove Product
Goal:
Remove a product from the system.
Actors:
Admin
Weborder System
Preconditions:
Admin must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Admin clicks the button or link to "Remove Product"
Basic Scenario:
1. Admin clicks the button or link to initiate Remove Product process.
2. System prompts the Admin to select a product by searching or viewing a list of
products.
3. System validates the product information.
4. System removes the product page and product information from the system.
5. System displays the newly created product page.
Postconditions:
A product is deleted from the system.

Update Product Attributes

Goal:
Update Product attributes within the system.
Actors:
Admin
Weborder System
Preconditions:
Admin must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Admin clicks the button or link to "Update Product Attributes"
Basic Scenario:
1. Admin clicks the button or link to initiate Update Product Attributes process.
2. System prompts the Admin to select a product by searching or viewing a list of products.
3. System displays all of the product attributes and allows Admin to update the product name,
product id, product description, product price, update the product image, product availability,
and/or the number of items in the inventory.
4. System validates the product information.
5. System updates the product page and product information within the system.
6. System displays the newly updated product page.
Postconditions:
The product attributes have been changed.

Register Customer
Goal:
Register a new customer account with the system.
Actors:
Customer,Admin
Weborder System
Preconditions:
Customer must be able to access the weborder system via a web browser with HTTPS.
Triggers:
Customer clicks the button or link to "Register"
Basic Scenario:
1. Customer clicks the button or link to initiate registration process.
2. System prompts the customer to fill out first name, last name, billing address, shipping
address, email address, and password.
3. Customer enters fields.
4. System validates customer's information.
5. System creates a new account for the Customer.
6. System creates session cookie.
7. System displays account home page to Customer.
Alternative Scenario:
A1. System recognizes Customer's cookie.
A2. Go to Step 7 (Basic Scenario).
Postconditions:
The Customer registers and creates a new customer account with the system.
an order.