[Online Boutique]

SOFTWARE REQUIREMENTS SPECIFICATION DOCUMENT

 Project Title

Revision History
Date Description Author Comments
<Version 1> <First Revision>

Document Approval
The following Software Requirements Specification has been accepted and approved by the following:

Signature Printed Name Title Date

Supervisor, CSIT 21306
 Project Title

Table of Contents

1. Introduction 4

2. The Overall Description 6

3. Specific Requirements 8

4. Analysis Models 12
 Project Title

1. Introduction
This document provides details about the entire software requirements specification for the
Online Boutique System.

1.1 Purpose
The purpose of this system is to implement the computerization of the clothes inventory and sales
etc. This uses the Php MyAdmin database and substitution encryption/decryption technique to hide
passwords of users.

1.2 Scope
In this subsection:

The name of the project is Online Boutique System (OBS). OBS (Online Boutique System) that
designed to manage your boutique is very user friendly software. With this software, you can
generate report based on your preference (daily, weekly, monthly, or yearly).

1.3 Definitions, Acronyms, and Abbreviations.

This program is a menu driven program. When we click the main menu the different forms will be
enabled. The program consists of the following modules:
 Source listing
This module is supposed to identify the products by their discription.
 Add products
This module is supposed to take the inputs from an input device.
 Add customers
This module is capable of adding customers in the specified formats.
 Update and delete products
This module will update and delete products
.  Update and delete customers
This module will be able to update and delete customers
 Searching
In this module the admin or employee can search the customer or products from the database based
on criteria’s
 Transactions

SRS Document 1.0

 Project Title

This module will take up transactions like selling products, buying products from supplier
updating cash and updating the bills. Appropriate actions will be taken
.  Report Generation
This is a client program which will request for reports..

1.4 References
In this subsection:
Online Boutique .

1.5 Overview
This system provides an easy solution for customers to buy the product without going to the shop
and also to shop owner to sale the product. This proposed system can be used by any naïve users
and it does not require any educational level, experience or technical expertise in computer field
but it will be of good use if user has the good knowledge of how to operate a computer.

SRS Document 1.0

 Project Title

2. The Overall Description

The Online Boutique system (OBS) application enables vendors to set up online shops, customers
to browse through the shops, and a system administrator to approve and reject requests for new
shops and maintain lists of shop categories. Also the developer is designing an online shopping
site to manage the items in the shop and also help customers to purchase them online without
visiting the shop physically. The online shopping system will use the internet as the sole method
for selling goods to its consumers.

2.1 Product Perspective

This product aimed toward a person who don’t want to visit the shop as he might don’t get time
for that or might not interested in visiting there and dealing with lot of formalities.

2.2 Product Functions

The product functions will include the following areas. The application is capable enough to
store different products and also perform some editing on them that is added. It will be having
user friendly GUI’s that will guide the user to easily achieve the same.
 AdminForm
 User Form
 Adding users
 Adding products
 Updating users
 Updating products
 Searching users and products
 Report generations User characteristics
l  No pre knowledge of database management
 Should be familiar with internet
 Should know English
 Should be able to use and do according to the graphical user interface

2.3 User Characteristics

There are 3 kinds of users for the proposed system.
 Administrators:

SRS Document 1.0

 Project Title

Administrators are the ones who adds or administers the categories for the products, and
administers the Vendors.

 Vendors/Sellers :
Vendors/Sellers will add their products to the database, which will be seen in the website to the
end users or say customers who can buy the products by selecting the one they need. Vendors
will have the special privileges than the end users, and have ability to manage the products added
by them.

 End Users/Customers:
The end user will be the one who visits the website and buys products online from the ones
added by the Vendors/Sellers.

2.4 General Constraints

 The main constraint here would be the checking the genuineness of the buyer, which
is not always possible. There can be security risks involved.

2.5 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.

SRS Document 1.0

 Project Title

3. Specific Requirements
3.1. External Interface Requirements :
3.1.1. User Interfaces:
Each part of the user interface intends to be as user friendly as possible. The fonts and buttons
used will be intended to be very fast and easy to load on web pages. The pages will be kept light
in space so that it won’t take a long time for the page to load.

3.1.2. Hardware Interfaces :

 Processor : Pentium or Higher.

 RAM : 312MB or Higher.

3.1.3. Software Interfaces :

 Operating System : Unix, Linux, Mac, Windows etc..

 Development tool : PHP : Hypertext Preprocessor, JavaScript, Ajax

 Data Base : MySQL

3.1.4. Communication Interface :

The Website Order system shall send an e-mail confirmation to the customer that the items they
ordered will be delivered to the shipping address along with user identification.

COMMUNICATION
SENDER RECEIVER

3.2 Functional Requirements

3.2.1. Master Maintenance :
This module consists of information about the products and services. This includes two sub-
modules, Product master and Price master.

3.2.1.1. Product Master :

SRS Document 1.0

 Project Title

Product master includes the information about particular product, such as product number, item,
name, category, images of products, description, features, constraints of products, which are to
be displayed on the website.

3.2.1.2. Price master:

Price master deals with the cost of the product, discounts applicable for the particular product of
a vendor/seller.

3.2.2. Transactions:
All transactions undergoing in the website will be controlled and managed by this module.
Transactions in the sense, Shopping Cart management.

3.2.3. Reporting:
This module deals with report management of the entire system. This includes three sub-modules
Stock Report, Order Report and Delivery Report.

3.2.3.1. Order Report :

Order Report will have the list of products ordered and the customer details who have bought
that product, which are undelivered.

3.2.3.2. Delivery Report :

Delivery Reports will generate products list, which are delivered to customers.

3.2.4. Housekeeping Module:

This module deals with backing up of data for future references and hence to reduce the database
size

3.1.1 Inputs
(1)Selecting order options by reader.
(2)Selecting images and text option by reader.

3.1.2 Processing
This website shows product by fetching the DB.

3.1.3 Outputs
The website gives view of surah in Arabic language and audio and video format to user.

SRS Document 1.0

 Project Title

3.4 Non-Functional Requirements

Following Non-Functional Requirements will be there in the insurance to the internet:
(i) Secure access to consumer’s confidential data.
(ii) 24X7 availability.
(iii) Better component design to get better performance at peak time.
(iv) Flexible service based architecture will be highly desirable for future extension.
(v) Non-Functional Requirements define system properties and constraints.
(vi) Various other Non-Functional Requirements are:

3.4.1 Performance
It shows the product and category immediately after the start of main page.

3.4.2 Reliability
Website does not crash even it gets lowest storage space in memory.

3.4.3 Availability
This system is available in internet.

3.4.4 Security
This website is not affected by any virus immediately.

3.4.5 Portability
This website could run over any processor and OS.

3.6 Inverse Requirements

State any *useful* inverse requirements.

3.7 Logical Database Requirements

This section specifies the logical requirements for any information that is to be placed into
a database. This may include:
 Types of information used by various functions
 Frequency of use
 Accessing capabilities
 Data entities and their relationships

SRS Document 1.0

 Project Title

 Integrity constraints
 Data retention requirements
If the customer provided you with data models, those can be presented here. ER diagrams
(or static class diagrams) can be useful here to show complex data relationships.
Remember a diagram is worth a thousand words of confusing text.

3.8 Design Constraints

There are few constraints that the system should follow. They are:

 All the inputs should be checked for validation and messages should be given for the improper
data. The invalid data are to be ignored and error messages should be given.

 Details provided by the vendor during his sign up should be stored in database.

 While adding the products to the system, mandatory fields must be checked for validation
whether the vendor has filled appropriate data in these mandatory fields. If not, proper error
message should be displayed or else the data is to be stored in database for later retrieval.

 All mandatory fields should be filled by customer, while buying the items from the cart.

SRS Document 1.0

 Project Title

4. Analysis Models
List all analysis models used in developing specific requirements previously given in this
SRS. Each model should include an introduction and a narrative description. Furthermore,
each model should be traceable the SRS’s requirements.

4.1 Sequence Diagrams

SRS Document 1.0

 Project Title

4.2 Use Case

Product

Feedback

Customer Delivery Method

Edit pro.

Del. pro. System

View Authentication

Admin login

Activity Diagram

The UML activity diagram is much like a flow chart. It shows steps (called appropriately enough, activities)
as well as decision points and branches. It’s useful for showing what happens in a business process or an
operation.

Representing an Activity Diagram

Each activity is represented by a rounded rectangle-narrower and more oval-shape. The processing within
an activity goes to completion and then automatic transmission to the next activity is occurs. An arrow
represents the transition from one activity to the next.

Activity Diagrams of our project are following:

SRS Document 1.0

 Project Title

For Admin:

Login

Password Incorrect
Eror message

Correct Password

Successfull

For Customer:

Product

Price

Payment

Feedback

SRS Document 1.0

 Project Title

For Product:

Product

Price

SRS Document 1.0

 Project Title

For Admin (edit, add) Product:

Login

Incorrect
Eror message

Correct

Select Product

Select Add Product

Incorrect
Eror message

Add Successfully

Logout

SRS Document 1.0

 Project Title

For Admin (edit, delete) Product:

Login

Incorrect
Eror message

Correct

Select Product

Select Delete Product

Incorrect
Eror message

Delete Successfully

Logout

SRS Document 1.0

 Project Title

4.3.Dataflow Diagrams (DFD)

SRS Document 1.0

 Project Title

4.4 State-Transition Diagrams (STD)

SRS Document 1.0

 Project Title

4.5 State-Transition Diagrams (STD)

SRS Document 1.0

 Project Title

4.6.Entity Relationship Diagrams

SRS Document 1.0