Srs group 4 v5 - esmart shopping

SCSR3104 – APPLICATIONS DEVELOPMENT
Software Requirements Specification
for
E-Smart Shopping
Version 1.0
Prepared by
Name Metric No.
Syed Muhamad Khalid B18CS0026
Farah Najihah Bt Mohd Naspu A18CS0061
Aina Afifah Bt Ab Latib B18CS0002
Muhamad Farid Nuricshan A17CS0259

Software Requirements Specification for E-Smart Shopping Page ii
Table of Contents
Introduction
Purpose 1
Intended Audience and Reading Suggestion 1
Product Scope 2-3
Overall Description
Product Perspective 4
Product Function 4
User Classes and Characteristic 7
Operating Environment 8
Design and Implementation Constraints 8
User Documentation 9
Assumption and Dependencies 9
External Interface Requirements
User Interface 10
E-Smart Shopping User Interfaces 10-17
Hardware Interfaces 17
Software Interfaces 18
Communication Interfaces 19
System Features
UC01 Budget Tracker 20
UC02 Product Navigation & Product Recommendation 21
UC03 Search Product 22
UC04 Barcode Scan 23
Other Non-Functional Requirements
Performance Requirements 26
Safety Requirements 26
Software Quality Attributes 36
Business Rules 27
Other Requirements 30

Software Requirements Specification for E-Smart Shopping Page iii
DOCUMENT CONTROL
General Information
Document Name : Proposal of E-Smart Shopping Application
Target User : Customer, Aeon Supermarket, Skudai
Prepared by : KAFF
Prepared Date : 15 July 2019
Reference Number : KAFF001-2
Version : 1.2
Document Level : Public | Open
Current Version Document
Prepared
By
Name Designation
Syed Muhamd Khalid Sceptic
Farah Najihah Bt Mohd Naspu Sceptic
Aina Afifah Bt Ab Latib Reporter
Muhamad Farid Nuricshan Scribe

Software Requirements Specification for E-Smart Shopping Page 1
1. Introduction
The purpose of SRS is to specify the requirements for Equine Park system. It
briefly explains the purpose, features, design of interfaces, functions of the system,
behaviour of the system, constraints and also how the system will react to external stimuli
in order to meet the desired requirements.
1.1 Purpose
The purpose of this document to describe the Software Requirements Specification
(SRS) of the proposed application. The application consists of two main parts, the mobile
application (E-Smart Shopping) and the backend server (SSBAC). This document also
includes application architecture design, scopes, four-module functions which are Budget
Tracker, Product Navigation, Halal Recognition and Product Ingredients. All these
functions to solve the problems that occur during shopping and makes shopping activities
easier.
1.2 Intended Audience and Reading Suggestions
The SRS described in this document is to be used by the research and development
team (refer to as the KAFF team) for developing the application. The KAFF Team will use
the SRS to fully understand the expectations and requirements needed in the application.
The stakeholder (here referred to as the Aeon Development Team) will be able to use this
SRS as a reference to if the KAFF Team is constructing the application as per Aeon Team
expectations.
● System analyst and developers – To build an application, gathering information
such as survey and interview have been performed by KAFF Team towards two
stakeholders which is a customer at Aeon Mall and owner of Aeon Mall to identify
the problem that occurs at supermarket. From that information, developers can
specify what functionalities, non-functionalities requirements and software
architecture in order to resolve the problems.

● Software testers – Systematically plan the functional and security strategy of the
application. Functional testing will be guided by system features and will be
perform by KAFF Team and lecturers before delivered the system to the
stakeholder.
● Documentation writers – Every use case consists of every flow and action from
the user in the system feature based on four modules which is Budget Tracker,
Product Navigation and Recommended Products, Products Ingredient and Word
Translation. It has to be delivered as end-user manual and technical
documentation that covers all the requirements aspects proposed and explained in
section 4.
● Stakeholder
 Aeon IT
 Aeon SCM
 Aeon Operation
 Customer of Aeon Mall
Aeon IT Department and Aeon Operation can refer to this document to understand
the capabilities of the proposed system and provide feedback to improve it. Aeon IT
can use this document to understand the technical description of the system and
later can refer to this document on how to operate, maintain and improve the
system.
1.3 Product Scope
The main objectives and the expected benefits of the system are:
 Provide better customer service
 Increase efficiency
 Attract more customer

To achieve them two components will be delivered:
 ESSYS - Mobile application for use by customer and admin at Aeon Mall
 SSBAC - Client-server system to be used by Aeon Inventory Department for
administrative purpose.
ESSYS will provide the following functions:
 To allow the customer getting the location and recommended goods product at the
supermarket
 to notify the customer when their budget is getting low
 To allow the customer to get the product ingredients specification
 To allow the customer getting the information by translation the words from other
countries and state if the products is halal or not.

ESSBAC will provide the following functions
 To allow customer to scan the barcode of the product
 To notify the customer the alert message on their budget tracker
 To allow the customer to get the product ingredients detail
 To allow the customer filling BT form

2. Overall Description
2.1 Product Perspective
Figure 2.1 depicts the overall architecture of the system. As shown in the figure the
integration of mobile phone application that we develop base on basic system requirement
itself such as Application Server to support the API (application program interface) and
the database that we choose to use Real-time firebase platform.
● Real-time database requires to store the details of the product in the supermarket
● Application server consists of web server connectors, computer programming
languages, runtime libraries, database connectors, and the administration code
needed to deploy, configure, manage, and connect these components on a web
host.
● The LDAP server is for authentication server to the admin before they change the
database or application server.

End-user system consist the customer of the supermarket and the admin which is the
owner of the supermarket. These role use their different platform. For customer, they use
the mobile application and for admin, they will use web base platform. Below are business
flow for the proposed system:

2.2 Product Functions

2.3 User Classes and Characteristics
This application mostly only focuses on the customer or user target of the
supermarket to make them keep on track of what they buying and to make them feel ease
when doing the shopping.
N
No
User Class and Characteristics
1
.
Customer/ User
Description
User is usually a person that will be using this application. The one who
will use all the module that will be provided in the application.
Subset of function used
1. Budget Tracker Module
2. Product Navigation & Recommended Products Module
3. Product Ingredients Module
4. Word Translation Module
2
.
Admin
Description
Admin is a worker from the selected supermarket that will be the one who
will monitor the application. If there any problem with the application,
admin will be the first one to be responsible. Admin also will update the
price or any promotion of any product in the supermarket.

2.4 Operating Environment
E-Smart Shopping operates in Android System with minimum requirement Lollipop 5.1 API
22. The Application subsystem will be written in JDK, Android SDK, XML. Using Android
Studio It will ease to uses.
Software Requirement ESSYS
Software Name Description
Java Development Kit Java compiler to integrate and build
Java-based modules of Android
system
Android SDK SDK deployment and management can
be conveniently done through the
installation of Android Studio
XML
Hardware requirement ESSYS
Android Mobile Device Mobile Device with Internet Platform
where E-Smart Shopping Installed
2.5 Design and Implementation Constraints
The design of software and system that will be implemented depending on the approval of
MMHE on what is being charted out in this documentation. The actual implementation will
also depend on the software, hardware, interface and services that is eventually provided
by MMHE. The following environment and implementation are suggested (based on the
information gathered from sections 2.1 and 2.4).
1. Server hardware
● New physical/virtual server centralized at Aeon server room

● Adequate CPU speed and HD/RAM size for medium-scale deployment
2. Server Software
● Operating System - Windows Server
● Web server – Firebase
3. Services for server maintenance
● FTP service
● Remote login service
4. IP and DNS
● Static Ip address or any kind of network setting to make the server
accessible over the internet
5. LDAP Service Integration
● Access to Aeon’s LDAP service for single sign-on(SSO) implementation to
ESSBAC
The system will be installed on the server provided bt AEON Team. Installation and
commissioning will be done by KAFF Team.
2.6 User Documentation
The application will come with an “About” tab, which will allow users to access the
offline and online HTML help manual. This manual will be updated with each new service
pack. Other user documentation includes one user manual for lowest level users, one
technical document describing the functionality of the subsection in detail for use of
technicians, one copy of documentation and link to the current source for future
contributors.
2.7 Assumptions and Dependencies
The developers assume that we will have to “pave our own way” concerning
programming the majority of the application, due to the mostly closed-source and
secretive nature. For what we cannot find from open documentation and research, it is
assumed that we will have to deduce how E-Smart Shopping standards and protocols
work from observing external behaviours found in existing Shopping software, and we will

have to replicate the results using our own code and other applications and libraries. This
project has to depend on the suitability of Android API of the android that will be used
because it will affect some function if the API is different and not compatible. The project
will have to depend on Firebase for the database. This project is developed under the
working assumption that as an open source project it shall be noted that the project shall
change over time.
It is assumed that E-Smart Shopping will be used in any supermarket but we
specifically for AEON mall at Taman Universiti, Skudai. It also is assumed that the
application can do scanning barcode to detect the price, can deduct the amount for the
budget needed, can provide navigation for the product, can detect Halal code and can
translate any foreign word to a word that user can understand well.

3. External Interface Requirements
3.1 User Interfaces
Module 1: Budget Tracker
Figure 1.1 Set amount of budget
Figure 1.1 above is about Budget Tracker where user need to set an amount that
will be spent per shopping. This features also can set a date and write some notes for
user purpose. After set all above requirement, user can hit ‘Set’ button.

Figure 1.2 Enter the serial barcode and deduct the amount from the previous
number
Figure 1.2 above is an interface that user need to enter the product serial barcode
and it will show up the price of the product and will deduct from the amount that has been
set before. The interface also provide a progress bar that shows to visualize the
progression. It also provides “X” button, if user wants to delete item just click the button.
The interface also includes “+” button so the user can edit the amount of budget if the
user wanted to increase or decrease the amount.

Module 2: Product Navigation & Recommended Products Module
Figure 2.1 Product Navigation
Figure 2.1 shows an interface that users use to search the product item location in
the supermarket this interface will short list by user input of product name in the search
box. User also can click the product image to see the price of the product.

Figure 2.2 Product Recommended
In figure 2.2 shows an interface that execute after user click the product in figure
2.1 it will go to the product details location and show the price and location of product.

This interface also appear the same product that users want to search. Here will call that
product recommended and will also appear include product price.
Module 3: Halal Searching Module
Figure 3.1 Halal Searching Screen in ESSYS

In this interface directly search the name of product to show Halal or Non-Halal of
the Product. The Button Search will show the Product name,prize, and state Halal or Non-
Halal information
Figure 3.2 Halal Statement

Module 4: Product Ingredients Module
Figure 4.1 Halal recognition screen in ESSYS
In this interface the user can take an image of halal logo from the product to know
the status and to check the product is approve or not from JAKIM. The button “Scan Your
Barcode” will show the details of the selected item. The details of the product will include
the ingredients, manufacture, halal certificate and product information.

Figure 4.2 Product details after logo recognition detection
3.2 Hardware Interfaces
All the hardware used within the system are the standard hardware for client-server
computing. They are consist of server computer, desktop computer and client mobile
device. Some of computer use for make a coding in android studio software to develop the
mobile application. The hardware communicate among them using standard TCP/IP
protocol (HTTP, HTTPS, LDAP, SMTP). The data they interchange using JSON String
and Plain Text. For security purposes, communication among them have to be made via
HTTPS communication channel. Authentication via LDAP service may also be required
(for critical data operations) before the hardware can communicate with their peers within
the system. For client mobile device, current implementation is concentrate on Android
version 4 and above can be use the mobile application. Specific to our target that have to
implementation, client mobile device must be equipped with using camera facility so the
users can scan the barcode or take fully take advantage of the service provided by the
system.

3.3 Software Interfaces
The figure shows the structure of the system that we implemented the integration of
mobile phone application that we develop based on basic system requirement itself such
as Application Server to support the Api (application program interface) and the database
that we choose to use Real time firebase platform.
Figure 3.3
The software component that shows in figure 3.3.1 may act as a client, database or
server. Their roles as a client or server, communication channel to be used, support
modules and message/data involved are listed in Table 3.1.

3.4 Communications Interfaces
Client Server Communication
Channel
Tools/Libraries Message/data
Application
Server
Apache
Server
HTTP Secure Json Scheme JSON String
ESSYS App
Fireb
ase
Retrieve data to
application
realtime firebase JSON String
Desktop
Apache
HTTP Secure HTML forms and
links, W3 CSS,
Bootstrap,
JQuery/AJAX
HTML Text,
standard POST
& GET
methods,
multipart
form-data,
JSON Strin
Application
Server
Ldap Server
LDAP service Perl::LDAP
module
(CPAN)
N/A

4. System Features
This section describes main features of the proposed system
4.1 System Feature 1
UC01 - Budget Tracker
Figure 4.1 : Use Case diagram of Budget Tracker
(M = access through Mobile App, W = access through Web Browser)
Name Budget Tracker
Identifier UC01
Description Set the budget
Goal To allow customer to track their budget
Actor Customer

Package UC01 Budget Tracker
Assumption Not applicable
Frequency Medium
Basic Course 1. Customer access to UC01 module
2. Customer set the amount needed
3. Customer will scan the product
4. Customer can add on budget
5. Customer can delete item
Alternate Course Not applicable
Condition Not applicable
Post Condition Actor able to access module based their role in system
Included Use Case None
Extended Use Case None

UC02 - Product Navigation & Recommended Products Module
Figure 4.2 use case diagram Product Navigation & Recommended
(M = access through Mobile App)
Name Product navigation & Product Recommended
Identifier UC02
Description Search product location and appear the similar product that user want
to search
Goal To help customers find the position of a product and to advise the
customer about the same item the customer wants to look for.
Actor Customer, client
Package UC02 Product Navigation & Product Recommended
Assumption None

Frequency Medium
Basic Course 1. Customer need to give the input in search box
2. The application will filter the product based on what input that
user fill in the search box.
3. Database send the Information
Alternate Course None
Condition Customer need to type the product that they want to find in the search
box.
Post Condition None
Including Use Case None
Extended Use
Case
None

Figure 4.3 Use case diagram for search product in module 3
(M = Access through Mobile Application)
Name Text Recognize
Identifier UC03
Description Searching Product to identify halal or Non-halal
Goal To give halal information to user
Actor Customer
Package UC03 Text Recognize
Assumption None

Frequency Medium
Basic Course 1. Customer search the product
2. Database send the Information
Alternate Course None
Condition Camera Permission
Post Condition None
Including Use Case None

UC04 - Product Ingredients Module
Figure 4.4 Use case diagram for product ingredients in module 4
(M = Access through mobile, W = Access through website)
Name Barcode Scan
Identifier UC04
Description Recognize halal logo
Goal To give product ingredients to user
Actor Customer
Assumption Not applicable
Frequency Medium
Basic Course 1. Customer access to UC04 module
2. Customer click Scan barcode
3. Customer take an logo/barcode image
4. Customer click “Scan Your Barcode”

5. Customer get the product ingredients
Alternate Course Not applicable
Condition Not Applicable
Post Condition Customer get the product details
Included Use Case None
5. Other Nonfunctional Requirements
5.1 Performance Requirements
1. System can handle the big data when execution data been using.
2. System must recognize the barcode fast as soon as possible.
5.2 Safety Requirements
1. The data of the product only can be changes by the owner of supermarket at
the back end database.
5.3 Security Requirements
1. Security requirement only be implements in the database part which is firebase
authentication to access the Realtime database.
2.

5.4 Software Quality Attributes
Compatibility
1. The application must be compatible with android 22 version minimum and latest
android version.
2. The application need connection from internet to successful use.
Documentation
1. All system documentation must be embedded in the source code
Availability
1. The system is expected to be available 99.99% uptime except connectivity and
physical failure.
5.5 Business Rules
 The price is based on the supermarket regulation.
 The app is useful while customer using it in the supermarket.
 User can use this app to find the location of product that they want.
 User can check the ingredient of product in the supermarket by scan by itself.
 Customer can keep track their budget went they want to shopping.

6. Other Requirements
Appendix A: Glossary
AJAX Asynchronous JavaScript and XML
FCM Firebase Cloud Messaging
JSON JavaScript Simple Object Notation
LDAP Lightweight Directory Access Protocol
SRS Software Requirements Specification
UTM Universiti Teknologi Malaysia
ESSYS E Smart Shopping System
API Application Program Interface
Appendix B: Analysis Models
Figure B.1: Sequence Diagram of Product Navigation

Figure B.2: Sequence Diagram of Budget Tracker

Figure B.3 : Sequence Diagram of Search Product
Figure B.4 : Sequence Diagram of Product Ingredient

Srs group 4 v5 - esmart shopping

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Srs group 4 v5 - esmart shopping

Similar to Srs group 4 v5 - esmart shopping (20)

Recently uploaded

Recently uploaded (20)

Srs group 4 v5 - esmart shopping