Software Requirements Specification

For

ONLINE SHOPPING SYSTEM

Version 1.0 approved

Prepared by Prateek Dubey

Modern College of Engineering

1st Aug 2012

Copyright 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Software Requirements Specification for <Project>

Page ii

Table of Contents
1. Introduction................................................................................................................................3 2. Overall Description....................................................................................................................5 3. System Features......................................................................................................................... 3 4. External Interface Requirements............................................................................................. 4 5. Other Nonfunctional Requirements......................................................................................... 5 6. Other Requirements.................................................................................................................. 5

Revision History
Name Date Reason For Changes Version

1.
1.1

Introduction
Purpose

The purpose of this document is a definition of general requirements of Online Shopping system. Here are presented functional and nonfunctional requirements. The Online Shopping System (OSS) web application is intended to provide complete solutions for vendors as well as customers through a single get way using the internet as the sole medium. 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. This document is meant to delineate the features of OSS, so as to serve as a guide to the developers on one hand and a software validation document for the prospective client on the other.

1.2

Document Conventions

<Describe any standards or typographical conventions that were followed when writing this SRS, such as fonts or highlighting that have special significance. For example, state whether priorities for higher-level requirements are assumed to be inherited by detailed requirements, or whether every requirement statement is to have its own priority.>

1.3

Intended Audience and Reading Suggestions

This document is intended for the employees who manage the Billing desks, the Administration personnel, the Software Developers, the Testers, and Marketing Staff. It has been divided into 4 Sections each providing an in-depth insight on different aspects of the Product. It contains the features of the product, the scope and limitations, the UI and various issues related to it, and the Operating requirements of the Product. The Users of the Product are advice to skip to the User Documentation Section directly. The Developers and Testers are advised to read the Document from the beginning.

1.4

Project Scope

Initial functional requirements will be: Secure registration and profile management facilities for Customers Browsing through the system to see the items that are there in each category of products like Apparel, Kitchen accessories, Bath accessories, Food items etc. Adequate searching mechanisms for easy and quick access to particular products and services. Creating a Shopping cart so that customers can shop n no. of items and checkout finally with the entire shopping carts. Regular updates to registered customers of the OSS about new arrivals. Strategic data and graphs for Administrators and Shop owners about the items that are popular in each category and age group. Maintaining database of regular customers of different needs. Shop employees are responsible for internal affairs like processing orders, assure home delivery, getting customer's delivery-time feedback, updating order's status and answering client's queries online. Feedback mechanism, so that customers can give feedback for the product or service which they have purchased. Also facility rating of individual products by relevant customers. Also feedback can be given on the performance of particular vendors and the entire mall as well. Adequate payment mechanism and gateway for all popular credit cards, cheques and other relevant payment options, as available from time to time.

Initial non-functional requirements will be: Secure access of confidential data (users details). SSL can be used. 24 X 7 availability. Better component design to get better performance at peak time. Advertisement space where it will effectively catch the customers attention and as a source of revenue. In addition to the above mentioned points, due to the highly evolving nature of the project, the following are planned to be delivered if deemed necessary: Warehousing within the very ambits of the project. More payment gateways like Cash On Delivery (COD) option available. Dynamic price model by which prices can be changed based on demand and supply. Dynamic Storefront: Each customer will have a web page personalized based on his or her recent purchases. This is the equivalent of having a unique storefront for each customer in hopes of drawing in as many return customers as possible.

1.5

References

IEEE SRS Format

2.
2.1

Overall Description
Product Perspective

OSS is aimed towards the vendors who want to reach out to the maximum cross-section of customer and common people who can be potential customer. This project envisages bridging the gap between the seller, the retailer and the customer. OSS should be user-friendly, quick to learn and reliable software for the above purpose. OSS is intended to be a stand-alone product and should not depend on the availability of other software. It should run on both UNIX and Windows based platform.

Software Requirements Specification for <Project>

Page 1

2.2 Product Features

User: Administrator Functions: The Mall Administrator is the super user and has complete control over all the activities that can be performed. The application notifies the administrator of all shop creation requests, and the administrator can then approve or reject them. The administrator also manages the list of available product categories. User: Shop Owner Functions: Any user can submit a shop creation request through the application. When the request is approved by the Mall Administrator, the requester is notified, and from there on is given the role of Shop Owner. The Shop Owner is responsible for setting up the shop and maintaining it. The job involves managing the sub-categories of the items in the shop. Also, the shop owner can add or remove items from his shop. The Shop Owner can view different reports that give details of the sales and orders specific to his shop. The Shop Owner can also decide to close shop and remove it. User: Customer Functions: A Customer can browse through the shops and choose products to place in a virtual shopping cart. The shopping cart details can be viewed and items can be removed from the cart. To proceed with the purchase, the customer is prompted to login. Also, the customer can modify personal profile information (such as phone number and shipping address) stored by the application. The customer can also view the status of any previous orders, and cancel any order that has not been shipped yet. User: Employees Functions: Purchase department under a Purchase manager to overlook purchasing activities if warehousing needs arise. Functions: Sales department under a Sales manager who will look after the sale of products and services, the most important activity. Functions: Accounts department under an Accounts Manager to look after the accounting activities of the enterprise.

2.3

User Classes and Characteristics

The user should be familiar with the Shopping System related terminology like Shopping cart/Checkout/Transaction etc. The user should be familiar with the Internet.

Software Requirements Specification for <Project>

Page 2

2.4

Operating Environment
The system will work under all UNIX, LINUX, WINDOWS based platform, with the basic requirement of Connection to the internet.

2.5

Design and Implementation Constraints

There is no maintainability of back up so availability will get affected. Limited to HTTP/HTTPS. Real-life credit card validation and Banking system is not implemented. No multilingual support.

2.6 User Documentation

1. The user manual will be provided along with the system which will contain the detailed steps for the installation of the system and its usage. 2. The on-line help will be provided for any troubleshooting problems with the system , by the usage of a forum where a customer can write his/her problem and services will be provided to him in the next 24hrs. 3. The tutorials in the form of CDs, DVDs will also be provided to use the system in a sophisticated way. 4. The 24x7 customer support will be provided for any onsite troubleshooting problems, if any.

2.7 Assumptions and Dependencies

The details related to the product, customer, payment and service transaction provided manually. Administrator is created in the system already. Roles and tasks are predefined.

Software Requirements Specification for <Project>

Page 3

3. System Features
3.1 Cash on Delivery
3.1.1 Description and Priority
COD option provides the user with a flexibility to use the system in a more flexible manner. As most of the customers are not basically uses the online net banking, so they have the option of paying the cash to the delivery staff in person at the time of delivery the item. Its of a very HIGH priority feature, as this feature is capable for broadening the customer base of the system.

3.1.2

Stimulus/Response Sequences
This feature will be triggered at the time of the checkout process, when the user wants to buy something; he has the option of selecting the COD method.

3.1.3

Functional Requirements REQ-1: REQ-2: The user should be available with the required cash at the time of payment. The system interface should be user-friendly in order for the user to understand and use it more easily.

3.2

On-Line Live System

3.1.1

Description and Priority

As the system application is a live application, access to it can be done 24x7 from any part of the world. The system will be available live to be used by any number of people all over the world.

3.1.2

Stimulus/Response Sequences
This feature will be triggered from the time you are connected to the internet and accessing the live website of the system for shopping.

3.1.3

Functional Requirements REQ-1: The user should have an internet connectivity along with the basic knowledge of using it.

Software Requirements Specification for <Project>

Page 4

REQ-2: REQ-3:

The system should be available all time and should be capable of holding the required traffic and the load on the website. The system should not crash down due to the traffic load on the website.

4.
4.1

External Interface Requirements

User Interfaces
1. Sign IN and Sign OUT: Both the buttons are used by an existing customer to access his/her account for buying or searching any item in the system. 2. Sign UP: Its being used by a new customer to register himself on the system for unlimited access of the system. 3. Checkout: Its been used by the customer at the final stage of buying the product from the system, by selecting the mode of payment.

4.2

Hardware Interfaces
1. For the system to work effectively the LAN connections to the system should be checked properly. 2. The system should be capable of supporting the standard internetworking protocols like HTTP, FTP, and HTTPS etc.

4.3

Software Interfaces
1. The LINUX, WINDOWS OS should be preinstalled on the PC on which the system is going to used. 2. The front end of the system is developed using VB.NET. 3. The database used for storing the user records and transactions made by the user till date can be Oracle or MYSQL. 4. The JDK should be preinstalled in the PC for the basic functioning of the system.

4.4

Communications Interfaces
1. The system will be using standard networking protocols like HTTP for the user to access the application live. 2. The password of the users credit card details and any other confidential details of the card will not be stored.

Software Requirements Specification for <Project>

Page 5

5.
5.1

Other Nonfunctional Requirements

Performance Requirements
1. Capability to process customer billings, and store the data in the database. 2. The collected data should be processed simultaneously along with the billing. 3. The results should be sent to the appropriate user.

5.2

Safety Requirements
1. The system should adhere to strict Electrical Standards as ISO 9009 2. The systems external design should conform to Aesthetic Standards.

5.3

Security Requirements
1. The administrator should be required to login using a separate login for the Admin Staff. 2. The billing personnel should be required to sign in using their personnel login. 3. For login for above staff , maximum incorrect attempts to sign-in should be 3.

5.4

Software Quality Attributes

Correctness: The offers shown to the customers should be correct and only be shown for the time for which they are intended. Availability: The system should be always live, as the billing is done on Real-Time basis and processing of the collected data is done on Real-Time basis as well. Reliability: The system should be robust to failures as it will prove costly if the system crashes

6.

Other Requirements

<Define any other requirements not covered elsewhere in the SRS. This might include database requirements, internationalization requirements, legal requirements, reuse objectives for the project, and so on. Add any new sections that are pertinent to the project.>

Appendix A: Glossary
<Define all the terms necessary to properly interpret the SRS, including acronyms and abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire organization, and just include terms specific to a single project in each SRS.>

Software Requirements Specification for <Project>

Page 6

Appendix B: Analysis Models

<Optionally, include any pertinent analysis models, such as data flow diagrams, class diagrams, state-transition diagrams, or entity-relationship diagrams.>

Appendix C: Issues List

< This is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending decisions, information that is needed, conflicts awaiting resolution, and the like.>