A Sample SRS Document
A Sample SRS Document
Table of Contents
1). Introduction
1.1 Purpose of this document
1.2 Scope of this Document
1.3 Acronyms
1.4 References
1.5 Intended Audience and Reading Suggestions
1.6 Document Overview
2). Overall description
2.1 Product Perspective
2.2 Product Functions
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 User Documentation
2.7 Assumptions and Dependencies
3). External Interface Requirements
3.1 User Interfaces
3.2 Hardware Interfaces
3.3 Software Interfaces
3.4 Communication Interfaces
4). Functional Requirement Specifications (FRS)
4.1 System Features
4.2 Functional Requirements
4.2.1 Front end (Storefront) Requirements
4.2.2 Back end (Administrative Tools) Requirements
4.3 Use Cases
4.3.1 Front end (Storefront)
4.3.2 Back end (Administrative Tools)
5). Non-Funtional Requirements
5.1 Usability Requirements
5.2 Performance Requirements
5.3 Compatibility Requirements
6). Other Requirements
7). Glossary
1). Introduction
1.1 Purpose of this document
The purpose of this document is to outline the requirements for the eCommerce
(Business to Customer) Product to be developed for IBEE Solutions (P) Ltd.
1.3 Glossary
1.4 References
[IEEE] The applicable IEEE standards are published in “IEEE Standards Collection,”
2001 edition.
Products Catalog
Customer’s registration
Customer account
Products Search
Advanced Search
Products Comparison
Price list
News
Feedback
Shopping cart
Checking out
Polls
Back end (administrative tools)
Login
Managing products catalog
Adding new categories/subcategories
Viewing/Editing/deleting existing categories
Adding new products
Viewing/Editing/deleting existing product entry
Table of products
Importing products
Exporting products
Synchronization tools
Product custom options
Special offers
Discussions
Defining Polls
Adding news
Reports
4.2 Functional Requirements
U 1.2 Login
U 1.3 Products Catalog
U 1.4 Products search
U 1.5 Advanced search
U 1.5.1 Selecting category & taking product name, Taking price range,
color etc and finding.
U 1.5.2 Displaying result as per customization of not available providing
message.
U 1.6 Products comparison
U 1.7 Shopping Process
U 1.9.1 Selecting one option, voting and getting the pole results
(we can vote one time per session only)
U 1.10 Viewing news
U 1.10.1 Selecting displayed news item and getting that news.
U 1.11 Feed back
U 1.11.1 Taking information like product name, name, e-mail, message and
submitting.
U 1.11.2 Input data resetting facility.
U 1.12 Price list
Ad 1.6.1 Importing products from a CSV file and updating the database
Ad 1.7 Exporting products
Ad 1.8 Special offers
Ad 1.9 Orders information
Ad 1.10 Customers information
Ad 1.11 Discounts
Ad 1.12 Adding news
Ad 1.13 Adding polls
Ad 1.14 Reports
Ad 1.15 Synchronization
Introduction
Actors: – An actor is a person or other entity external to the software system
being specified who interacts with the system and performs use cases to
accomplish tasks. Different actors often correspond to different user classes, or
roles, identified from the customer community that will use the product. Name
the actor that will be initiating this use case and any other actors who will
participate in completing the use case.
Normal flow: – This is where the description of our use case goes.
The normal flow should include the most common (or) the most valuable path
through the use case.
Status: 2
Release: 1.0
Selects Country
Submits form
Enters first name , middle name ,last name and email
Selects profession
Selects Country
Submits form
Status: 2
Release: 1.0
Normal Flow: System: Displays the Front End (Customer Store Front) Home page
the password
Through mail.
Alternative Flows:
Business Rules: Registered user must enter valid user name and password
Status: 2
Release: 1.0
Normal Flow: System: Displays the Front End (Customer Store Front) Home page
Status: 2
Release: 1.0
Normal Flow: System: Displays the Front End (Customer Store Front) Home page
Alternative Flows: Browsing through catalog or advanced search user can get info
Status: 2
Release: 1.0
Business Rules:
Status: 2
Release: 1.0
Alternative Flows:
Business Rules:
Status: 2
Release: 1.0
Normal Flow: Guest/Registered User: selects one news item from the news block
Alternative Flows:
Business Rules: Guest/registered user can select one news item at a time
Status: 2
Release: 1.0
Normal Flow: System: Sends submitted details to the database and provides
acknowledgement.
Alternative Flows:
Status: 2
Release: 1.0
Release: 1.0
Normal Flow: Guest/Registered User: Selects one option in poll block and votes.
Business Rules: Guest/Registered User can vote one time per session.
4.3.2 Back end (Administrative Tools)
Status: 2
Release: 1.0
Admin User has to give Valid User ID and password for Logging; if
Business Rules:
any one is incorrect login operation won’t be performed.
Status: 2
Release: 1.0
Alternative Flows: Enters meta keywords, meta description and description(HTML) and
saves.
Status: 2
Release: 1.0
Confirms deleting
Alternative Flows:
Status: 2
Release: 1.0
Normal Flow: Admin User: selects parent, enters product name and product code,
selects tax class, enters sort order, price(number only), list price, In
stock, shipping freight, weight, minimum order quantity and
description(HTML) and saves.
Business Rules:
Status: 2
Release: 1.0
Normal Flow:
Admin User: views and close(view)
Confirms deleting
Alternative Flows:
Business Rules:
Status: 2
Release: 1.0
Alternative Flows:
Status: 2
Release: 1.0
Alternative Flows:
Business Rules:
Status: 2
Release: 1.0
Admin User: cancels the form without filling any data, after filling
some data and after filling full data.
Status: 2
Release: 1.0
Enters 3 Answer options each in separate line and Saves the Details
Normal Flow:
System: accepts the details and sends for intended Process.
Gives Ack.
Admin User has to type one Question and 3 answer options (each in
separate line).
Business Rules: Admin user can reset the data at any movement before saving the
data.
Status: 2
Release: 1.0
Business Rules:
Status: 2
Release: 1.0
Alternative Flows:
Business Rules:
5). Non Funtional Requirements
5.1 Usability Requirements
(As it is a Internet Application, must have some usabilty Features. End users of
this System are Unlimited and from Various Skilled groups, so that we can’t
restrict them. By providing some fecilities we have to make them comfortable.)
§ Colors what we use in this Web Portal design are must be attractive.
§ Fonts that uses for User Interface (Customer Store front) Design are must
be in Uniform.
§ Easy Navigations are freferable to do any task.
§ Multiple flows (ways) are freferable to do any task.
§ Home page Should be Centralized System (Screen/Window) to go to any
feature and to get any result.
§ The fecility to return to Home page from any page Should available.
§ Labels of all Objects in the entire system Must be in Understadable
form(Meaningful form).
5.2 Performance Requirements
(Application’s performance not only depends on application design also on
Customers System’s Configuration (both Hardware and Software), Internet Access
Speed, networks and Others)
Even though the performance is not only depends on application design, our
application design and implimentation also responcible for the Performance.
§ It has to load, with in the Industry Standard time.
§ It has to support up to 2000 Concurrent users.
§ It has to update the database in short time in order to reduce the stock
verfication problems.
5.3 Compatibility Requirements
7). Glossary