The Islamia University of Bahawalpur

Department of Computer Science

SOFTWARE REQUIREMENTS
SPECIFICATION
(SRS DOCUMENT)

for
Afiat
Version 1.0

By
Muhammad Ameer Hamza
FA21BDOCS1M08151
Session Fall 2021 – 2023

Supervisor
 Muhammad Akmal
Bachelor of Science in Computer Science

Revision History

Name Date Reason for changes Version

Ameer Hamza 10/12/2022 Development of Afiat website 1.0

Application Evaluation History

Comments (by committee) Action Taken

*Include the ones given at scope time both in doc and
presentation

Supervised by
Muhammad Akmal

Signature
Content table
Chapter 1 Introduction................................................................................................................................4
1.1 Purpose..............................................................................................................................................5
1.2 Scope.................................................................................................................................................5
1.3 Definitions, acronyms, and abbreviations..........................................................................................6
1.4 References.........................................................................................................................................7
Chapter 2 Overall Description.....................................................................................................................8
2.1 Product perspective...........................................................................................................................8
2.2 Operating Environment.....................................................................................................................8
2.3 Design and Implementation Constraints...........................................................................................8
2.4 Purpose of Application……………………………………………………………………………………………………………8

2.5 User Documentation..........................................................................................................................9

Chapter 3 Specification Requirement........................................................................................................10
3.1 External Interface Requirements.....................................................................................................10
Functionality......................................................................................................................................10
Usability.............................................................................................................................................13
Reliability & Availability.....................................................................................................................13
Security..............................................................................................................................................14
Supportability....................................................................................................................................14
Design Constraints.............................................................................................................................14
Interfaces...........................................................................................................................................15
3.2 Functional Requirements.................................................................................................................16
Initiate Tour.......................................................................................................................................16
Tour as a Member.............................................................................................................................16
Read News.........................................................................................................................................17
Catalog...............................................................................................................................................18
3.3 Use Cases.........................................................................................................................................22
User side............................................................................................................................................22
Seller Side..........................................................................................................................................23
Actor..................................................................................................................................................25
3.4 Non-Functional Requirements.........................................................................................................26
 Availability.........................................................................................................................................26
Reliability...........................................................................................................................................26
Robustness........................................................................................................................................26
Performance......................................................................................................................................27
User friendliness................................................................................................................................27
Maintainability...................................................................................................................................27
Portability..........................................................................................................................................27
Security..............................................................................................................................................27
4 References……………………………………………………………………………………………………………………………………27

Introduction
In this project we made an ecommerce website that sells the products online. It will enable
customer to visit online shops and store and purchase things online without visiting physical
shop. In this project two major modules that have been provided are administrator module
and user module. The administration module will enable administrator to approve or reject
orders and maintain shop categories. Administrator can add or remove products from website.
The next module is user module where user can view the website and can add products to
their cart and so on.

Purpose
The primary goal of my project is to reach maximum customers at the right time to increase sales
and profitability of the business. Functions of this project include buying and selling goods,
transmitting funds or data over the internet. This document will provide the software
requirements of online shop that will run on Android and Windows Operating System. It is also
referred to as the sales of different items on the marketplaces in which money transaction activity
takes place. It will elaborate the user and administrator side view of the website. It will outline the
system's features, user interface, and functionality as well as what the system is meant to
accomplish.

Scope
All Android-powered tablets and smartphones will be able to use the Afiat. It makes their
shopping easier and makes it easier to find products on the market.
This is meant to assist the user in following use cases:
 • Discover the product of their choice at the neighboring markets.
• Address the user to find out if the product is available.
• On the application store list, display registered markets.
• Compile a list of relevant product categories.
• View authentic market vendors.
• Offer vendors a chat room
• Product locations in various locations.
• Consider information on cost and caliber.
• Look up the items and customer reviews.
• Alert you when the product you searched for is in stock.

Overall description
Product perspective
This project is specifically intended for the local mobile market. The majority of the features
seen in other e-stores will be there, but the goal is to make local merchants' sales accessible to
customers online. Additionally, when used for the first time, it will create an account and turn
the user into a member for future purchases. By providing engaging offers and discounts, we
will encourage users to love shopping.
Operating Environment
All versions of Android must be supported by our app. To show appropriate graphical fields,
a sufficient graphics memory is also required. For data archiving and retrieval, we'll utilize
Firebase. 1GB minimum RAM and 1.5 dual core processor is required.

Design and Implementation Constraints

In the online community, there is a genuine demand for our product. Therefore, we have a
minimum of four months to finish it. The IEEE standards should be followed. English will be
the default language. The ability to see the app in Urdu will be available in the next
increment.

Purpose of Application
eMart provides maximum security control for your on-line transactions with support for
industry standard ecommerce security protocols and single sign-on technology. eMart's
robust user, asset and role-based permissions provide support for SSL as well as LDAP & NT
Active Directory.

Requirement identifying technique

 Use case description
Use Case ID: Af-1
Use Case Afiat
Name:
Actors: Primary Actor : Administrator
Secondary Actor: Customer

Description: 1. Any member can register and view available products.

2. Only registered member can purchase multiple products
regardless of quantity.
3. ContactUs page is available to contact Admin for queries.
4. There are three roles available: Visitor, User and Admin.
5. Visitor can view available products.
6. User can view and purchase products.
7. An Admin has some extra privilege including all privilege of
visitor and user.
8. Admin can add products, edit product information and
add/remove
9. product.
10. Admin can add user, edit user information and can remove
user.
11. Admin can ship order to user based on order placed by sending
12. confirmation mail.
Trigger: First you will have to sign up the website. Then user will have sign in with
user id. Then user will browse the whole web and select items that user want
to buy. User can add these selected items to cart. Then customer will check
the order checkout and User can manage the orders in product cart
Preconditions: The condition for purchasing any item
1. User must sign in to website.
2. User must provide information for payment method
Postconditions: When user purchase any product.
1. User’s Order will be stored in DB.
2. Inventory of available items is updated to reflect items in this order.
3. Remaining delivery capacity for the requested time window is
updated.
Normal Flow: 1. A customer will enter the website after Login.
2. A customer can choose to have the product delivered or for
pick-up/take-away.
3. The process consists of a customer choosing the product of their
choice,
4. A customer scanning all the products on category wise.
5. Then he/she will choosing an item, and add them to cart
6. Then he/she will checkout the cart and view all ordered products.
7. Payment is then administered by paying with the bank or jazz cash or
easy paisa through the app or website
8. when orders is dispatched from store to them website and app inform
the customer by cracking id.
9. when the order is ready for pick-up or the amount of time it will take
 for delivery and so on.
Alternative The alternative flow of website is given below
Flows: 1. User can order multiple Cosmetic items.
[Alternative 2. There is no limit of orders until the stock is available.
Flow 1 – Not
in Network]
3. When user complete the payment method then a message shown him
that your order is completed.
4. If user select one product and complete order. then after it another
selecting product he cannot add this into cart after shipment.
Exceptions: Orders cannot be canceled after shipment.
1. COS informs Patron that it’s too late to place an order for today.
2. If Patron cancels the meal ordering process, then COS terminates use
case. 2b. Else if Patron requests another date, then COS restarts use
case.
Business Rules: Following are some rules of our Business.
1. You can select multiple items and add them to cart.
2. User can also manage his cart.
3. User can add or delete products from the Business cart.
4. Any product delivery can be canceled before shipment.
5. None of products can be changed.
6. If you want to exchange your products then you have to visit our
warehouse.
7. An unauthorized user cannot purchase any product.
8. An unauthorized user can only view the Website
Assumptions: Assume that 15 percent of Patrons will order the daily special (Source:
previous 6 months of cafeteria data)

Functional Requirements
This section describes specific features of the software project. If desired, some
requirements may be specified in the use-case format and listed in the Use Cases
Section.

Initiate Tour
Tour as a Guest

Introduction

View our software system as a non-registered user.

Inputs

Default customer ID.

Processing

Assign the user a default customer ID implicitly.

Give him the basic rights to view products, to browse catalogs.
 Outputs

Lead user to selection of viewing products, browsing catalogs and watching promos.
Tour as a Member
Introduction

Start using our software system as a registered member. The members can avail
promotions and offers. They can also earn points on purchasing which they can
redeem in future.
Inputs

Valid member ID and PIN.

Processing

Compare the user-input member ID and PIN with our database.

Determine if he is a member.
Outputs

Show his membership status.

If he is a member, give him coupons and promos to redeem his points.

Read News
Introduction

News informs user the exciting products and promotions offered lately. It also tells
user all the services and new features that E mart provides.
Inputs

Customer ID, either default (as for guests) or member ID.

Processing

Link to the list of news.

Outputs

The list of latest news. A list of all the services will be displayed as well.

Catalog
Browse Catalog
Introduction
All users have the authority to look at all the products that we provide. The users
include guests, buyers and shopkeepers. Shopkeepers want to browse the catalog
because they need to know the types and prices of products we already have to
determine if it is worth posting their goods on our catalogs.
 Inputs

Customer ID, either default (as for guests) or member ID.

Processing

Link to the list of products and product prices.

Outputs

The list of products types, price, their manufacturers and availabilities.

Post Products on Catalog

Introduction

Only shopkeepers have the authority to post products on our catalogs.

Inputs

Valid member ID and PIN.

Processing

If user is a guest, lead him to registration page. If the input ID and PIN are not consisting
with in database, give an error message to let them contact with database administrator.
Prompt supplier to input his product’s name, type, price, and number of items available in
stock, handling and shipping time, contact phone and email. Update our catalog database
in real time.
Outputs

Page of “registration” or “post on catalog”.

Purchase
Making an order
Introduction

This is a service for buyers. Only members have the authority to buy products.
Inputs

Valid member ID and PIN.

Processing

1. If user has not registered or logged in, lead him to login page. Else if the input ID and
PIN are not consisting with in database, give an error message to let them contact with
database administrator.
2. Else if member does not provide his account information, lead him to page of
inputting account information.
 3. Else, lead him to page of purchase. Prompt buyer to input number of items wanted.
Check the buyer’s personal information. Assign buyer a confirmation number and display
the page of receipt. Update our catalog database in real time.
Outputs

Page of “registration”, “providing account information” or “purchase”.

Order confirmation number and receipt.

Track Order and Cancellation Process

View Order Status
Introduction

This is a service to let buyer track his order. It also shows if it is too late to cancel the
order process. Only member who has made the order can view order status.
Inputs

Valid member ID, PIN and order confirmation number.

Processing

If user has not registered or logged in, lead him to page of registration.
Else if the input ID and PIN are not consisting with in database, give an error message to
let them contact with database administrator.
Else, lead him to page of view order status.
If user does not have an order in database, show him nothing to track.
A link to shipping companies is provided, such as UPS, FedEx and etc.
Outputs

Page of “log in” or “track orders”.

Cancel Order
Introduction
Only buyer who has made the order can cancel the order process.
Inputs

Valid member ID, PIN and order confirmation number.

Processing

1. If user has not registered or logged in, lead him to page of registration.
2. Else if the input ID and PIN are not consisting with in database, give an error message
to let them contact with password recovery methods.
 3. Else, lead him to page of canceling orders.
4. If user does not have an order in database, show him nothing to cancel.
5. Cancellation can be done without penalty before stores handled the order.
6. No order can be cancelled after products have been shipped out to the buyer.
Outputs

Page of “log in” or “cancel orders”. Confirmation of cancellation

Registration and Update Memberships

Registration
Introduction
This is a service for guests. User can input their credit card information now or later.
Inputs

Default customer ID.

Processing

1. If the member ID has been taken, prompt user to choose another one. Prompt user to
select a password.
2. Prompt user to input information of his company, such as company name, location,
phone, fax, and email.
3. User can select to input their credit card information now or later.
4. Without credit card information, E mart will not allow user to purchase products.
5. Update our membership database.
Outputs

Page of registration.

Use case
This section contains use cases of the E-MART, an e-commerce application.

User side
The use case for the user side clearly tells us that the user will firstly register as a member
then the user will login to the system. After that the user will take a tour of the app (i.e how it
works). The user will browse through catalogs and select his desired category. There the user
will browse items and select a product to ship to his address. Then the user will be asked a
payment method to complete his order. After selecting a payment method and completing the
formalities of address and payment method, the order will be shipped to user’s given address.
The user side functions as shown in Fig-1.

Fig-1 user side use case diagram

Seller Side
The seller will have to register himself as a member the he will be prompted to log in. after
that the seller will post his products on catalog. He will also update the catalogs if there are
new arrivals or stock was empty previously. Furthermore, the seller can check for payments
from the user, if the user has paid for the item then the seller will make item ready to
dispatch. The seller can also withdraw his payments by the desired payment method. The
seller side functions as shown in Fig-2.
 Fig-2 seller side use case diagram

Actors
1st Actor (customer)
This is the comprehensive use case of the entire app and there are two actors. First is user and
the second one is administrator or seller. User will firstly register as a member then the user
will login to the system. After that the user will take a tour of the app (i.e. how it works). The
user will browse through catalogs and select his desired category. There the user will browse
items and select a product to ship to his address. Then the user will be asked a payment
method to complete his order. After selecting a payment method and completing the
formalities of address and payment method, the order will be shipped to user’s given address.
The details enhanced in this case for user side are that he can update his account and manage
account. He can avail discount on his purchases. The user can write a review about the
product and he can also view the tracking information of the item. Moreover, a user can also
cancel his order if he is not sure about making the order.

2nd Actor (Administrator)

The Administrator will post products on catalog. He will also update the catalogs if there are
new arrivals or stock was empty previously. Furthermore, the admin can check for payments
from the user, if the user has paid for the item then the seller will make item ready to
dispatch. The administrator will also add a new category if new items or category is
introduced. Moreover, the admin will also allocate a shipping agent to the specific order to be
delivered on door step. The 1st and 2nd actor systematic diagram is shown in Fig-3

Functional Requirements
The most significant portion of the paper is this one. All of the system's functional
requirements are listed in this section. It provides a thorough explanation of the system's
functionality.
Functionality
Configuration for seller about ordered product
1. All configurable goods must be shown by the system.
2. The system must let the user choose the product to configure.
3. The system must show all of the product's configurable components that are available.
4. The system must allow the user to add one or more components to the setup.
5. The system must alert the user to any conflicts with the current settings.
6. To resolve conflicts in the present configuration, the system must let users to adjust
their configuration.
7. The system must enable users to validate that the present setup is complete.
Give thorough product information
1. The system must show comprehensive information about the chosen items.
2. The system must offer browsing options for seeing product information.
Offer a product search functionality
1. The system must allow users to type search terms into the screen's search box.
2. The system must let users choose from a variety of alternatives on the screen while
doing a search.
3. The system will show all matched items depending on the search.
4. On the present screen, the system must only show 10 matched results.
5. The system should make it possible for users to switch between search results.
6. When no matching product is located during the search, the system must inform the
user.

Personalize your profile

1. In the client profile, the system must show both the active and finished purchase
history.
2. The computer system must enable users to choose an order from their order history.
3. The system must show all relevant information regarding the chosen order.
4. The system must show the user's most popular search terms on their profile.
5. The system must allow users to register on their profiles for newsletters and polls.
Offer customer service
 1. The system must include customer support alternatives such as sitemaps, FAQs, and
online assistance.
2. The system must let the user choose the kind of help he wants.
3. For support purposes, the system must allow users to enter customer and product
information.
4. The system must show the phone numbers for customer assistance on the screen.
5. The system must allow users to input the phone number that support staff should use
to reach them.
6. When asked, the system must show the online assistance.
Make a shopping cart available
1. When making an online purchase, the system must offer a shopping cart.
2. The system must let users to add and remove items from their shopping carts.
Offer a variety of delivery options
1. The system must show the many shipping alternatives that the shipping department
offers.
2. During the payment process, the system must allow the user to choose the delivery
option.
3. The shipping costs must be displayed by the system.
4. The system must show the shipment time estimate.
Providing online order modification and cancellation
1. The eligible orders for modification must be shown by the system.
2. The user can choose the new order using the system.
3. A user may cancel an order using the system.
4. Users may modify their shipping and payment options through the system.

5. In case the user's order is changed, the system must inform them.

Non-Functional Requirements
This section specifies nonfunctional requirements other than constraints.

Usability
Interactive Graphics
1. The system must ensure that all web activities have a consistent appearance and feel.
2. Each market in the market catalogue must have a digital picture provided by the
system.
 3. The system must offer toolbars and icon use.
Accessibility
1. The system must provide for disability accessibility.
2. The system must support several languages.

Availability and Reliability

Internal Back-end Computers
1. The system must offer automated switchover and storage of all databases on
redundant machines.
2. The system must enable database replication to off-site storage facilities.
Performance
1. The product must run from a local server and be based on the Android operating
system.
2. The product will require some initial loading time, which will depend on the speed of
your internet connection and the media you're using to execute it.
3. The client's or customer's hardware components will determine performance.
Robustness
The system should have the ability to continue to function accurately even the customer input
wrong commands. This would be done by exception handling.

Maintainability
The system should be easy to maintain by administrators. The system’s database should be
backup every week. After certain amount of time, the system should be added new function,

Security
The system should protect itself from external attacks that may be accidental or deliberate
such as viruses, unauthorized use of system services, unauthorized use of system services,
unauthorized modification of the system or its data. All customers’ account information must
be stored in the system’s database. Only the database administrators have direct access to the
database for making any change related to the database schema and for maintenance
purposes.

References
The references used in this SRS are:
1. Daraz.pk
2. Amazon
3. eBay
4. Walmart