0% found this document useful (0 votes)
59 views61 pages

Project Report-Merged

The document provides a software engineering project report for a small scale grocery management system. It includes sections on the software process model and management with contributions from each team member. It also includes planning and scheduling diagrams such as a work breakdown structure, Gantt chart, timeline chart and PERT-critical path diagram. The software requirements specification defines the purpose, scope, user classes and operating environment. It outlines functional requirements for user registration, slot booking and services. Non-functional requirements around performance, security and quality are also documented.

Uploaded by

Vishesh Bhargava
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views61 pages

Project Report-Merged

The document provides a software engineering project report for a small scale grocery management system. It includes sections on the software process model and management with contributions from each team member. It also includes planning and scheduling diagrams such as a work breakdown structure, Gantt chart, timeline chart and PERT-critical path diagram. The software requirements specification defines the purpose, scope, user classes and operating environment. It outlines functional requirements for user registration, slot booking and services. Non-functional requirements around performance, security and quality are also documented.

Uploaded by

Vishesh Bhargava
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 61

Software Engineering Project Report

for
Small Scale Grocery Management System

Prepared by:-
Pratham Sharma 20BCE2463
Sahas Vivek 20BCE2701
Shreasi Sen 20BCE2738

28th April, 2022

1
Table of Contents
1 S/W PROCESS MODEL AND S/W PROCESS MANAGEMENT
A. INDIVIDUAL CONTRIBUTIONS
B. VIEWPOINT OF THE PROBLEM STATEMENT
- PURPOSE
- OBJECTIVE
- DOCUMENT CONVENTIONS
- INTENDED AUDIENCE
- PRODUCT SCOPE
C. PLANNING AND SCHEDULING DIAGRAMS
- WORK BREAKDOWN STRUCTURE
- GANTT CHART
- TIMELINE CHART
- PERT-CRITICAL PATH

2 SOFTWARE REQUIREMENTS SPECIFICATION


A. INTRODUCTION
- PURPOSE
- OBJECTIVE
- DOCUMENT CONVENTIONS
- INTENDED AUDIENCE AND READING SUGGESTIONS
- PRODUCT SCOPE
- REFERENCES
B. OVERALL DESCRIPTION
- PRODUCT PERSPECTIVE
- PRODUCT FUNCTIONS
- USER CLASSES AND CHARACTERISTICS (STAKEHOLDERS)
- OPERATING ENVIRONMENT
- DESIGN AND IMPLEMENTATION CONSTRAINTS
- USER DOCUMENTATION
- ASSUMPTIONS AND DEPENDENCIES
C. SCHEDULING DIAGRAMS
- GANTT CHART
- TIMELINE CHART
- PERT-CRITICAL PATH
- WBS STRUCTURE
D. EXTERNAL INTERFACE REQUIREMENTS
- USER INTERFACES
- HARDWARE INTERFACES
- SOFTWARE INTERFACES
- COMMUNICATION INTERFACES
E. SYSTEM FEATURES
- FUNCTIONAL REQUIREMENTS
- VALIDATION
- UPDATING USER’S INFORMATION
- PROVIDING PIN CODES
- SLOT BOOKING
- SERVICE SELECTION
- CONTACT DETAILS
- NEW USER REGISTRATION
2
F. OTHER NONFUNCTIONAL REQUIREMENTS
- PERFORMANCE REQUIREMENTS
- SAFETY REQUIREMENTS
- SECURITY REQUIREMENTS
- SOFTWARE QUALITY ATTRIBUTES
- BUSINESS RULES
G. OTHER REQUIREMENTS

3 SOFTWARE DESIGN SPECIFICATION


A. INTRODUCTION
- PURPOSE
- SYSTEM OVERVIEW
- DESIGN MAP
- DESIGN CONSIDERATIONS
B. DESIGN CONSIDERATION
- ASSUMPTIONS
- CONSTRAINTS
- SYSTEM ENVIRONMENT
- DESIGN METHODOLGY
- USE CASE DIAGRAM
- CLASS DIAGRAM
- STATE CHART
- ACTIVITY DIAGRAM
- SEQUENCE DIAGRAM
- DEPLOYMENT DIAGRAM
- COLLABORATION DIAGRAM
C. ARCHITECHTURE
- OVERVIEW
- SUBSYSTEM, COMPONENT OR MODULE 1…N
D. DATABASE SCHEMA
- TABLES, FIELDS AND RELATIONSHIPS
- DATABASES
E. LOW LEVEL DESIGN
F. USER INTERFACE DESIGN
- APPLICATION CONTROLS
- SCREEN 1…N

3 GUI DESIGN SPECIFICATION

A. INTRODUCTION
- PURPOSE
- SYSTEM OVERVIEW
B. ARCHITECHTURE
- OVERVIEW
- SUBSYSTEM, COMPONENT OR MODULE 1…N
C. USER INTERFACE DESIGN
- APPLICATION CONTROLS
- SCREEN 1…N
D. SOFTWARE USED
E. GRAPHICAL USER INTERFACE
- COMMON SCREEN
- LOGIN
3
- LIST OF AVAILABLE SHOPS
- LIST OF AVAILABLE SLOTS
- ADMIN SIDE LOGIN
- LIST OF USERS IN ADMIN SIDE

4 TEST CASE GENERATION


A. TESTING TECHNIQUES APPLIED
B. GENERAL MANUAL TEST CASES OF PROJECT MODULES
- UNIT TESTING- CUSTOMER SIDE
- UNIT TESTING- SHOPKEEPER SIDE
C. TESTING TOOL URL
D. GENERATING GRAPH OUT OF TEST CASE GENERATION

4
-

5
SOFTWARE ENGINEERING CSE3001

WINTER SEMESTER- LAB

PROFESSOR NAME SWARNALATHA P


SCHOOL NAME
SCHOOL OF COMPUTER SCIENCE AND ENGINEERING
(SCOPE), VIT

TITLE OF THE PROJECT GROCERY SHOPPING IN PANDEMIC

ASSESSMENT NAME S/W PROCESS MODEL AND S/W PROCESS


MANAGEMENT

NAME OF THE STUDENT SHREASI SEN

REG. NO. 20BCE2738

CONTRIBUTION:

I worked on the Gantt Chart and the Timeline Chart for this application by understanding the time and
customer requirements. We sub divided each task to understand fully the necessities to develop this
application to a highly scalable.
I will make UI / UX, basic frontend prototyping and the documentation using basic design tools like
Figma as developer handoff is facilitated using Figma. I will also be doing research to understand the
target users and their needs for enhancing the utility and scalability of this product. Once this phase is
completed, I will begin to build the basic frontend of the website using the design prototype using CSS to
style the website and HTML to build the basic skeleton of the webpage.

1. VIEWPOINT OF THE PROBLEM STATEMENT:


1.1 PURPOSE

The demand for basic necessities prevails during this time of a global pandemic. People have to get daily
supplies like food and medicine and have to risk themselves getting affected by the virus. Hence, we aim
to allow the people of a particular area to buy the daily grocery items by maintaining social distancing
norms and thereby reducing the risk of spreading coronavirus.

1.2 OBJECTIVE

To help the shop owners continue with their business so that they are financially stable while also
enabling citizens to get the required items during this lockdown period to the maximum possible extent
along with reducing the risk of transmission of the virus and following all the norms of social-distancing
which has taken a hit on everyone’s lives.

1.3 DOCUMENT CONVENTIONS

The SRS is documented using MS Word. The font used to document the SRS is Times New Roman.
Words which have been bold is the point of discussion in that particular paragraph with the bullet points
acting as sub-information of that topic.

1.4 INTENDED AUDIENCE

The intended audience for this involves people from all walks of life because our product aims to solve
the problem of availability of all perishable items. This product aims to solve the problem of accessibility
by delivering goods in an online mode to every single household. As we are in uncertain times, the best is
to make sure people remain indoors to minimize the spread of the deadly COVID 19 virus which is once
again back to wrecking havoc across the world.

1.5 PRODUCT SCOPE

Be it a pandemic or just a regular day this webapp will be useful in getting what the customers wish and
could possibly increase the business of the shop owners by making them widespread in the virtual world
which is often overlooked by the locals. It would save customers a lot of time and resources which
otherwise they might have spent in a futile trip to their known general store. Also, once the laws start to
loosen up a bit, we could also think of starting a doorstep delivery service.
The system would focus on the following key points:

1.Directing the buyer to the nearby seller that can fulfill his needs
2.Creating a slot system for buyer coming to one seller
3.Sending buyers to different sellers if a slot of buyer’s choice has already too many buyers

Advantages of our system:

1.Reducing coronavirus transmission


2.Hassle free buying
3.Crowd management

2.PLANNING AND SCHEDULING DIAGRAMS


2.1.WORK BREAKDOWN STRUCTURE
2.2.GANTT CHART

2.3.TIMELINE CHART

2.4.PERT- CRITICAL PATH

SUBTASKS LIST (NOTATION)

A- SCOPE AND ANALYSIS OF THE PROJECT

B- SOFTWARE AND TOOLS REQUIRED

C- IDENTIFYING TARGET USERS AND DATA COLLECTION

D- UI PROTOTYPING

E- FRONTEND DEVELOPMENT ADMIN SIDE

F- FRONTEND DEVELOPMENT USER SIDE

G- BACKEND DEVELOPMENT SETUP AND CONNECT DATA TO BACKEND


H- DEPLOYING BACKEND

I- CONNECTING BACKEND TO FRONTEND

J- BUG TESTING

K- DOCUMENTATION

L- FUTURE UPDATES

SUBTASKS TABLE

SUBTASK NOTATION DEPENDENCIES DURATION(IN DAYS)

A - 3

B A 2

C A 5

D B,C 5

E D 4

F D 5

G E,F 8

H G 6

I E,F,G 2

J I 6
K - 2

L - 2

PERT DIAGRAM

PERT DIAGRAM WITH CRITICAL PATH


A→C→D→F→G→I→J is the critical path

CRITICAL PATH TABLE

SUBTASK START TIME COMPLETION TIME CRITICAL PATH


NOTATION

A 0 3 *

B 3 5 -

C 3 8 *

D 8 13 *

E 13 17 -

F 17 22 *

G 22 30 *

H 30 36 -

I 30 32 *

J 32 38 *

K 0 2 -

L 0 2 -
Software Requirements
Specification

for

Small Scale Grocery


Management System
Version 1.0 approved

Prepared By:-

Pratham Sharma (20BCE2463) :-


Other Nonfunctional Requirements, Other Requirements, Appendix.

Sahas Vivek (20BCE2701) :-


External Interface Requirements, System Features.

Shreasi Sen (20BCE2738) :-


Introduction, Overall Description.

Organization :- SEM, SCOPE, VIT Date :- 08/02/2022


Table of Contents
Table of Contents 1
1. Introduction 2
1.1 Purpose 2
1.2 Objective 2
1.3 Document Conventions 2
1.4 Intended Audience and Reading Suggestions 2
1.5 Product Scope 2-3
1.6 References 3
2. Overall Description 3
2.1 Product Perspective 3
2.2 Product Functions 3-4
2.3 User Classes and Characteristics 4
2.4 Operating Environment 4
2.5 Design and Implementation Constraints 4
2.6 User Documentation 4-5
2.7 Assumptions and Dependencies 5
3. External Interface Requirements 12
3.1 User Interfaces 12
3.2 Hardware Interfaces 12
3.3 Software Interfaces 12
3.4 Communications Interfaces 12
4. System Features 12
4.1 System Feature 1 12-14
5. Other Nonfunctional Requirements 14
5.1 Performance Requirements 14
5.2 Safety Requirements 14
5.3 Security Requirements 14-15
5.4 Software Quality Attributes 15
5.5 Business Rules 15
6. Other Requirements 15
Appendix A: Glossary 15
Appendix B: Analysis Models 16
Appendix C: To Be Determined List 16

Revision History

Name Date Reason For Changes Version


1. Introduction

1.1 Purpose

The demand for basic necessities prevails over their supplies during this time of a global
pandemic. People have to get general daily items like food and medicine and have to risk
themselves getting affected by the virus. Hence, we aim to allow the people of a particular area
to buy the daily grocery items by maintaining social distancing norms and thereby reducing the
risk of spreading coronavirus.

1.2 Objective

To help the small shop owners with their business so that they are financially better off and the
citizens to get the required items during this lockdown period to the maximum possible extent
along with reducing the risk of transmission of the virus and following all the norms of social-
distancing which has taken a hit on their lives.

1.3 Document Conventions

The SRS is documented using MS Word. The font used to document the SRS is Times New
Roman. Words which have been bold is the point of discussion in that particular paragraph with
the bullet points acting as sub-information of that topic. Also note that priorities for higher-level
requirements are assumed to be inherited by detailed requirements.

1.4 Intended Audience and Reading Suggestions

The intended audience for this document involves people from all walks of life because our
product aims to solve the problem of availability of all perishable items. However, all the
sections might not be useful or of interest for people under a specific category. For example, a
housewife may find only the introduction and overall description of the product useful because
she is only interested in knowing the features and benefits of using our products. On the other
hand, a developer or a software engineer will overlook the external interface requirements and
system features section which is acceptable whereas a Marketing strategist will find his keen
interest in the introduction, overall description, non-functional and other requirements because it
somewhat defines his scope of investing in our product.

1.5 Product Scope

Be it a pandemic or just a regular day this webapp will be useful in getting what the customers
wish and could possibly increase the business of the shop owners by making them widespread in
the virtual world which is often overlooked by the locals. It would save customers a lot of time
and resources which otherwise they might have spent in a futile trip to their known general store.
Also, once the laws start to loosen up a bit, we could also think of starting a doorstep delivery
service.

The system would focus on the following key points:


1. Directing the buyer to the nearby seller that can fulfill his needs
2. Creating a slot system for buyer coming to one seller

2
3. Sending buyers to different sellers if a slot of buyer’s choice has already too many buyer

Advantages of our system:


1. Reducing coronavirus transmission
2. Hassle free buying
3. Crowd management

1.6 References

● Concept referral, vision, scope, UI/UX- www.amazon.in/


● IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software
Requirements Specifications. IEEE Computer Society, 1998.
● https://ejmcm.com/article_7462_146e951f8a1a487fa115384268492f5e.pdf
● https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7269931/

2. Overall Description

2.1 Product Perspective

Our product is a self-contained product however we can say that the motivation and courage of
launching such a product came from the success that Amazon has enjoyed over these years.
The process model used for our product is the spiral model. The reason behind using it is because
our project is a large one, we need to commit releases frequently, we can also create a prototype
easily and lastly as the situation fluctuates we can make necessary changes to our product.

This product aims at the fulfillment of basic necessities of most people and even certain specific
groups of individuals along with aiding small-scale shop owners to be financially capable of
living through these tough times along with helping retail parts of bigger industries to contribute
to the nation's economy is this project’s novelty. It is one of the few well-planned techniques
where overcrowding at a particular medical, grocery etc stores can be prevented. The
government can also control the outburst of a helpless crowd by dividing the time slots vs no of
people in consideration with the social distancing norms. Lastly, due to its open Source nature
you can modify it according to your needs on completion.

2.2 Product Functions

The main objective is to get the required items during this lockdown period to the maximum
possible extent along with reducing the risk of transmission of the virus and following all the
norms of social-distancing which has taken a hit on their lives.

A high-level summary of the functions of the product are below:


● The home page gives the user three options to choose from.
● If the user is a customer then he has the option to either check the availability of the items
of a shop in their area or book a slot for themself at that shop.
● If the user is a shopkeeper then he has the option to add an item or change the availability
of the existing items.

3
● We have also used the threshold number of customers allowed in a slot to be three which
can be increased according to the need and the government norms.
● Also a pin would be provided to each shopkeeper which would be unique but for demo
purposes we have given each shop an Id which starts from 123 for shop A and goes till
133 for shop W.

2.3 User Classes and Characteristics (STAKEHOLDERS)

Administrator: He/she is the one who is responsible for maintaining all the login details
involving both the customer and the shopkeeper. Also any guidelines passed on by the
government which has to be displayed on the website has to be taken care of by him. Lastly,
the data base involved has to be maintained and secured by the administrator.
The General Public/Customer: They are the ones who will enjoy the benefits of our product.
They are only allowed to login and book the slots according to the availability. Lastly the most
important task they have to perform is to submit a wish list for the next day which has the details
of the customer demands.
The Shopkeeper: The first task the shopkeeper has to perform is to submit details of their shops
such as location, shop name, products provided etc. Second is to look into the wish list and try to
fulfill it to the extent that every customer gets the needful item which increases the value of our
webapp. Lastly, they need to update the stock time to time in order to avoid a situation where a
customer’s visit to the shop is futile which affects the reputation of the webapp.

2.4 Operating Environment

Being a web application it can be used on any operating system as well as no restriction on the
type of environment to be used. A laptop, tablet and a smartphone will support this web app
providing smooth functionality and user experience.

2.5 Design and Implementation Constraints

One immediate requirement that a user should fulfill and is recommended from our side is to
have good internet connectivity. However, the user will still be able to surf the website but won’t
have the updated information which can be misleading sometimes. All the protocols will be
handled by our team however we might face challenges in areas such as corporate or regulatory
policies of that particular Municipal Corporation. Also maintaining such a large database can be
strenuous at times. One major problem that we identified while hosting this webapp all over
India and around the world is the communication protocols because the world is a diverse place
with people making use of many different languages, however with a positive vision we host the
website in English which is generally understood by everyone.

2.6 User Documentation

The list of user documentation components that will be delivered along with the software are
listed below:
● A tutorial video will be provided on the website’s home page itself.

4
● A 24/7 available chat box will also be set up to bring solutions for our users at that very
instance.
● A feedback text box will also be provided because we always want to improve our user
interface and experience.
● Guides and Api references will also be included.

Lastly, a glossary will also be provided.

We aim to take referral for maintaining our standards from companies such as Flipkart and
Amazon.

2.7Assumptions and Dependencies

Assumptions:
● Our team assumes that all the users have access to internet connectivity.
● The users know how to surf online on a website.
● Have resources such as smartphones or laptops.
Dependencies:
● We need to get the approval of google to host this website prior to the fact that we fulfill
all the requirements.
● We are also dependent on a company to provide us with a domain name which enables us
to host our website.
● Also, we are heavily dependent on all the search browsers where our websites will be
available.
● External user interface.
● Business rules, Security and Safety requirements.
● Also on companies such as Oracle or MYSql with whom we will partner for maintaining
and creating the database.

SCHEDULING DIAGRAMS :-

GANTT CHART

5
TIMELINE CHART :-

PERT DIAGRAM :

SUBTASKS LIST (NOTATION)


A- SCOPE AND ANALYSIS OF THE PROJECT
B- SOFTWARE AND TOOLS REQUIRED
C- IDENTIFYING TARGET USERS AND DATA COLLECTION
D- UI PROTOTYPING
E- FRONTEND DEVELOPMENT ADMIN SIDE
F- FRONTEND DEVELOPMENT USER SIDE
G- BACKEND DEVELOPMENT SETUP AND CONNECT DATA TO BACKEND
H- DEPLOYING BACKEND
I- CONNECTING BACKEND TO FRONTEND
J- BUG TESTING
K- DOCUMENTATION
L- FUTURE UPDATES

6
SUBTASKS TABLE

SUBTASK NOTATION DEPENDENCIES DURATION(IN DAYS)

A - 3

B A 2

C A 5

D B,C 5

E D 4

F D 5

G E,F 8

H G 6

I E,F,G 2

J I 6

K - 2

L - 2

7
Activity Immediate Predecessors Duration

A - 3

B A 2

C A 5

D B,C 5

E D 4

F D 5

G E,F 8

H G 6

I E,F,G 2

J I 6

K - 2

L - 2

PERT DIAGRAM

8
PERT DIAGRAM WITH CRITICAL PATH

A→C→D→F→G→I→J is the critical path

CRITICAL PATH TABLE

SUBTASK NOTATION START TIME COMPLETION TIME CRITICAL PATH

A 0 3 *

B 3 5 -

C 3 8 *

D 8 13 *

E 13 17 -

F 17 22 *

G 22 30 *

H 30 36 -

9
I 30 32 *

J 32 38 *

K 38 40 -

L 40 42 -

SLACK TIME TABLE

SUBTASK NOTATION START TIME COMPLETION TIME CRITICAL PATH

A 0 3 *

B 3,4 5,6 -

C 3 8 *

D 8 13 *

E 13,17 17,23 -

F 17 22 *

G 22 30 *

H 30,33 36,39 -

I 30 32 *

10
J 32 38 *

K 38,40 40,42 -

L 40 42 -

WBS STRUCTURE :-

11
3. External Interface Requirements

3.1 User Interfaces :-

Our website is integrated with menu-driven and graphical user-interface for ensuring easy
access of the interface elements and to provide the users with a better understandability
on how to facilitate the actions. The interaction design, visual design, and information
architecture are properly combined so that it does not leave any doubt for the users on
how to find or access any element in the interface. The overall layout is simple and
attractive. The softwares required for designing the UI are HTML, CSS and JavaScript.

3.2 Hardware Interfaces :-


The basic hardware interfaces include keyboard, mouse for a computer and a touchscreen
for a mobile device. The minimum requirements from the user’s side are :-
1. A processor with a minimum speed of 1 GHz or more.
2. An ethernet connection or a wireless adapter.
3. A minimum RAM of 1 GB or more.
The nature of the data is quantitative which includes the items available in each shop of
the targeted area, items required by the particular shops, users basic information and their
cart items which are to be recorded. This information is stored in a database for which a
server is required.
3.3 Software Interfaces :-
The website is independent of any operating system. Interfacing with several modules is
essential in order to perform various operations. It requires Database connectivity (SQL)
and Server interfacing (APACHE). Python Flask (includes the required libraries) and
JavaScript are the software requirements for the web hosting and the integration with the
server.

3.4 Communication Interfaces :-


HTTP protocol is used for allowing the users to communicate the data on the world wide
web. The protocol includes mechanisms for detecting and handling errors and
acknowledgment mechanisms between client and service .

4. System Features :-

4.1 Functional Requirements :-


Functional requirements specify which outputs should be produced from the given
input. They describe the relationship between input and output.

12
4.1.1 Validation :-

The customers and the shopkeepers are supposed to create their respective accounts
specifying their details in the website. On logging into the site, the system must allow
the user to make a total of 3 entries of his/her username and password. If the details
are valid, log in the user else terminate. An alternative option of ‘Forgot Password’
should also be given to the user to reset his password.

4.1.2 Updating user’s information :-


The system should provide an option to update the shop’s available items with the
stock amount. Any price changes can also be updated under this feature. This in
turn should be reflected in the shop owners database.

4.1.3 Providing Pin codes :-


Unique pin codes should be given to the shop owners by the websites so that their
online shop is secured. This pin would allow them to access their shop items and
update the prices and the stock. This would make sure there are no malpractices.

4.1.4 Slot Booking :-


A total of 15 customers are allowed to book in a particular slot timing. The website
should restrict the user to book any slot which has exceeded the total booking of 15.
A provision of canceling the booking should also be made.

4.1.5 Service selection :-


The website must provide appropriate options if the user has entered as a customer
or a shop-keeper. Here is an example:
For customers, it should ask them for checking out the items and its prices available
in each shop after filtering out the area, adding their items into the cart and booking
the slot timing for purchasing the items.
For shop-owners, it should provide them with an option of updating their item list,
viewing the customers details who wants to purchase from their shop and to modify
their shop availability timings.

4.1.6 Contact details :-


An email address and a phone number of the shop owner will be specified in the
contact details of the particular shop using which the user could communicate with
the shop owner regarding his grocery requirements. As the user clicks on the email
address, he/she will be redirected to his/her g-mail account for composing the
message.

13
4.1.7 New User registration :-This page provides registrations for new customers and
shop owners.

5. Other Nonfunctional Requirements

5.1 Performance Requirements


● The Website must be easy to navigate and must be easily usable by a non-tech user also.
So, the website should be used and accessed by the user easily.
● The Website should not hang and should run smoothly. It should have the capacity to at
least accommodate 2000 users at a time.
● Any update of information by the user should be recorded immediately.
● The Website should not take a lot of time to load. It can take 4 s at maximum. This is
required for better customer satisfaction.
● The notifications should be shown whenever a slot is booked. And a reminder should
be sent for the same 15 min before the slot timings.
● The Screen refresh time should be low.
● System failure should not occur frequently.
● Time to restart after failure should be less.
● Percentage of events causing failure should be less.
● Probability of data corruption on failure should be less.

5.2 Safety Requirements

● The information of the users and the history of usage should not be lost. This is very
important as the history of the user is very essential information for both the user and
the admin.
● There should be data backup in case the website crashes so that the information is not
lost.
● There should be a backup server which will be useful whenever the main site crashes.

5.3 Security Requirements

● Email and Phone number verification of the users must be done.


● Only the administrator should know about all the confidential data.
● System must be accessed only inside the server.

14
● Any personal information of users should not be made public. The Privacy of the user
should be taken care of.
● Switching of tabs should be restricted.
● Multiple logins of the same account should not be allowed.

5.4 Software Quality Attributes

● The software should be adaptable in order to meet various future requirements.


● Software should have good availability and reliability.
● Modification of a software product after delivery to correct faults must be done,
to improve performance or other attributes.
● The software should be reusable.
● The same software should be usable in different environments.
● Software testing must be done when required.

5.5 Business Rules


● Only the Admin should be allowed to maintain the website.
● Updates in the site must be made by the admin only and no other people should be given
access.
● Only the verified users must be allowed to use it.

6. Other Requirements
● The software should allow for new updates.
● It should be reusable.
● It should be tested for any bugs.
● It should be easily used by users.
● It should run smoothly and efficiently.

Appendix A:

15
Appendix B: Analysis Models

User Case Diagram

Appendix C: To Be Determined List

16
Software Design
Specification
for
Small Scale Grocery
Management System
Revision 1.0

Table of Contents

Table of Contents............................................................................... 0-1

Revision History................................................................................ 2

Approved By...................................................................................... 2

1. Introduction.................................................................................. 3

1.1 Purpose.................................................................................. 3

1.2 System Overview.................................................................... 3

1.3 Design Map............................................................................ 3

1.4 Supporting Materials............................................................... 3

1.5 Definitions and Acronyms....................................................... 3

2. Design Considerations.................................................................. 4

2.1 Assumptions........................................................................... 7
2.2 Constraints.............................................................................. 7

2.3 System Environment............................................................... 7

2.4 Design Methodology............................................................... 8

2.5 Risks and Volatile Areas.......................................................... 8

3. Architecture.................................................................................. 8

3.1 Overview................................................................................ 9

3.2 Subsystem, Component, or Module 1 …N................................ 9-10

3.3 Strategy 1…N......................................................................... 10

4. Database Schema.......................................................................... 10

4.1 Tables, Fields and Relationships............................................... 10

4.1.1 Databases........................................................................... 11

5. High Level Design......................................................................... 12

5.1 View / Model Element 1…N.................................................... 12

6. Low Level Design.......................................................................... 12

6.1 Module 1…N.......................................................................... 12

7. User Interface Design................................................................... 12

7.1 Application Controls............................................................... 12

7.2 Screen 1… N.......................................................................... 13-14

Appendix A: Project Timeline........................................................... 15

1
Revision History

Version Name Reason For Changes Date

1.0 Sahas Vivek Initial Revision 01/03/2022


Pratham Sharma -UML MODELS
Shreasi Sen -USE CASE
-CLASS
-STATE CHART
-ACTIVITY
-SEQUENCE
-COLLABORATION
-DEPLOYMENT
-ER MODEL
-ARCHITECTURE SYSTEM MODEL
-OBJECTIVES
-LOW LEVEL DESIGN PSEUDOCODES FOR
POSSIBLE MODULES(1/N)
USER INTERFACE PEN/SOFTWARE
(MODULE 1/N/OVERALL)

Approved By

Approvals should be obtained for the project manager, and all developers working on the project.

Name Reg. No. Date

Sahas Vivek 20BCE2701 01.03.2022

Pratham Sharma 20BCE2463 01.03.2022

Shreasi Sen 20BCE2738 01.03.2022

2
1. Introduction
1.1 Purpose
The demand for basic necessities prevails over their supplies during this time of a global
pandemic. People have to get general daily items like food and medicine and have to risk
themselves getting affected by the virus. Hence, we aim to allow the people of a particular area
to buy the daily grocery items by maintaining social distancing norms and thereby reducing the
risk of spreading coronavirus.

1.2 System Overview


This project extends the functionality of the Binder Request process that is currently active in PCMS
processes. Additional fields and features will be added to the binder request form, new workflow
sub-processes will be added to the binder request process, and a process report will be developed that is
unique to the binder request process. Metics and TaskViews reports will be available for binder requests,
but these will be implemented as the workflow reporting project and will not be included in this SDS.

1.3 Design Map


SUE - Summarize the information contained within this document or the family of design artifacts.
Define all major design artifacts and/or major sections of this document and if appropriate, provide a brief
summary of each. Discuss any significant relationships between design artifacts and other project
artifacts.

1.4 Definitions and Acronyms


No definitions for this particular project.

2. Design Considerations
All design considerations were handled in Binder Release Phase 1.

2.1 Assumptions
Metrics and TaskView reports will be handled in the workflow reporting project.

3
2.2 Constraints
Not applicable for this project.

2.3 System Environment


This is a web application and hence it can be used on any operating system and hence there is no
restriction on the type of environment to be used. A laptop, tablet and a smartphone will support
this web app providing smooth functionality and user experience. A server will be necessary to
host the website and a database too, to store data.

2.4 Design Methodology


1. Use Case Diagram

4
2. Class diagram

3. State chart

5
4. Activity diagram

5. Sequence Diagram

6
6. Deployment Diagram

7. Collaboration Diagrams

7
2.5 Risks and Volatile Areas
Not identified for this topic

3. Architecture

This section provides user interface design descriptions that directly support construction of user
interface screens. The details of each sub module are as listed below. All the screens with their
workings have been listed below. A basic explanation will be added to each screen.

8
3.1 Overview
This product aims at the fulfillment of basic necessities of most people and even certain specific
groups of individuals along with aiding small-scale shop owners to be financially capable of
living through these tough times along with helping retail parts of bigger industries to contribute
to the nation's economy is this project’s novelty. It is one of the few well-planned techniques
where overcrowding at a particular medical, grocery etc stores can be prevented. The
government can also control the outburst of a helpless crowd by dividing the time slots vs no of
people in consideration with the social distancing norms. Lastly, due to its open Source nature
you can modify it according to your needs on completion.

The main objective is to get the required items during this lockdown period to the maximum
possible extent along with reducing the risk of transmission of the virus and following all the
norms of social-distancing which has taken a hit on their lives.

3.2 Subsystem, Component, or Module 1 …N


Common Screen- Choose whether you are a user or an admin

User side

In this screen, the user will be able to view the list of available shops in their locality. After the
user has selected their preferred area, they will be able to see the list of all the available slots for
that particular shop.

Admin side

This screen will allow the admin to view the list of users and their booked slots. After the user
has finished their slot, there is a status which can be updated accordingly.

4. Database Schema
4.1 Tables, Fields and Relationships
A description of the tables and their attributes are as listed below:

9
1. AdminTable

| admin_id | first_name | last_name | email_address |

2. Customer Table

| username | name | c_id | password | phone_num | address |

3. Slots Table

| quantity | time | day |

4. Shop Table

| s_id | s_name | s_address |

5. Bookings Table

| booking_id | booking_time | shop_id |

6. Items Table

| item_id | item_name |

4.1.1 Databases

2 databases will be used for this project, one for development and testing and the other will be
deployed in production.

10
5. High Level Design
5.1 Binder Request Form

5.2 User Interface Modifications

5.3 Workflow sub-processes


Will be done in the next review.

11
6. Low Level Design
Code:
Admin
position: relative;
width: 1155px;
height: 699px;

background: #FFFFFF;

Available slots
position: relative;
width: 1155px;
height: 699px;

background: #FFFFFF;

Available shops

position: relative;
width: 827px;
height: 515px;

background: #FFFFFF;

Make your choice here


position: relative;
width: 827px;
height: 515px;

background: #FFFFFF;

Rest of the code will be updated in


https://github.com/sahas-01/Grocery-Management-Frontend

6.1 Binder Request Form

12
6.1.1 Contact Changes

6.1.2 Submit Button

6.1.3 Cancel Button

6.1.4 Other Changes

6.2 Workflow sub-processes

6.2.1 Binder Extension

7. User Interface Design


This section provides user interface design descriptions that directly support construction of user
interface screens.

7.1 Application Controls


All the screens with their workings have been listed below. A basic explanation will be added to
each screen.

7.2 Screen 1… N

Common Screen- Choose whether you are a user or an admin

13
User side

View available shops- In this screen, a user will be able to view the list of available shops

View slots by shop- This page gives the user the list of available slots for that particular
shop

Admin side

View Users- View the list of users and their booked slots. When the user has finished their
slot, there is a status which can be updated.

14
7.2.1 Workflow Reports

Not applicable for this project.

Appendix A: Project Timeline

Reference the Microsoft project Binder Request Release 2 – Development..

15
GUI Design
Specification
for
Small Scale Grocery
Management System
Revision 2.0

Table of Contents

Table of Contents ................................................................................... 0-1

Revision History..................................................................................... 2

Approved By ............................................................................................2

1. Introduction ....................................................................................... 3

1.1 Purpose ....................................................................................... 3

1.2 System Overview ........................................................................ 3

2. Architecture ....................................................................................... 8

2.1 Overview ..................................................................................... 9

2.2 Subsystem, Component, or Module 1 …N ................................... 9-10

3. User Interface Design ....................................................................... 12

3.1 Application Controls ................................................................... 12

4. Software used...............................................................................
1
4.1 Figma .....................................................................................

5. GUI ...............................................................................................

Appendix A: Project Timeline............................................................... 15

Contributions:

Sahas worked on the user side screens such as the login page functionality, the dashboard page.
and worked on the database functionality.

Pratham worked on the admin side functionality such as the dashboard page and the slots page to
view the slots.

Shreasi worked on the designing the components such as the shop cards, the list view and the
dashboard page

2
Revision History

Version Name Reason For Changes Date

1.0 Sahas Vivek Initial Revision 01/03/2022


Pratham Sharma -UML MODELS
Shreasi Sen -USE CASE
-CLASS
-STATE CHART
-ACTIVITY
-SEQUENCE
-COLLABORATION
-DEPLOYMENT
-ER MODEL
-ARCHITECTURE SYSTEM MODEL
-OBJECTIVES
-LOW LEVEL DESIGN PSEUDOCODES FOR
POSSIBLE MODULES(1/N)
USER INTERFACE PEN/SOFTWARE
(MODULE 1/N/OVERALL)

2.0 Sahas Vivek Second Revision 15/03/2022


Pratham Sharma -ARCHITECTURE SYSTEM MODEL
Shreasi Sen
-LOW LEVEL DESIGN PSEUDOCODES
MODULES(1/N)
-USER INTERFACE
-DESCRIPTION OF GUI
-SOFTWARE USED

Approved By

Approvals should be obtained for the project manager, and all developers working on the project.

Name Reg. No. Date

Sahas Vivek 20BCE2701 01.03.2022

3
Pratham Sharma 20BCE2463 01.03.2022

Shreasi Sen 20BCE2738 01.03.2022

1. Introduction
1.1 Purpose
The demand for basic necessities prevails over their supplies during this time of a global
pandemic. People have to get general daily items like food and medicine and have to risk
themselves getting affected by the virus. Hence, we aim to allow the people of a particular area
to buy the daily grocery items by maintaining social distancing norms and thereby reducing the
risk of spreading coronavirus.

1.2 System Overview


This project extends the functionality of the Binder Request process that is currently active in PCMS
processes. Additional fields and features will be added to the binder request form, new workflow
sub-processes will be added to the binder request process, and a process report will be developed that is
unique to the binder request process. Metrics and Task Views reports will be available for binder
requests, but these will be implemented as the workflow reporting project and will not be included in this
SDS.

2. Architecture

4
This section provides user interface design descriptions that directly support construction of user
interface screens. The details of each sub module are as listed below. All the screens with their
workings have been listed below. A basic explanation will be added to each screen.
2.1 Overview
This product aims at the fulfillment of basic necessities of most people and even certain specific
groups of individuals along with aiding small-scale shop owners to be financially capable of
living through these tough times along with helping retail parts of bigger industries to contribute
to the nation's economy is this project’s novelty. It is one of the few well-planned techniques
where overcrowding at a particular medical, grocery etc stores can be prevented. The
government can also control the outburst of a helpless crowd by dividing the time slots vs no of
people in consideration with the social distancing norms. Lastly, due to its open Source nature
you can modify it according to your needs on completion.

The main objective is to get the required items during this lockdown period to the maximum
possible extent along with reducing the risk of transmission of the virus and following all the
norms of social-distancing which has taken a hit on their lives.

5
2.2 Subsystem, Component, or Module 1 …N
Common Screen- Choose whether you are a user or an admin

User side

In this screen, the user will be able to view the list of available shops in their locality. After the
user has selected their preferred area, they will be able to see the list of all the available slots for
that particular shop.

Admin side

This screen will allow the admin to view the list of users and their booked slots. After the user
has finished their slot, there is a status which can be updated accordingly.
https://github.com/sahas-01/Grocery-Management-Frontend

3. User Interface Design


This section provides user interface design descriptions that directly support construction of user
interface screens.

3.1 Application Controls


All the screens with their workings have been listed below. A basic explanation will be added to
each screen.

3.2 Screen 1… N

Common Screen- Choose whether you are a user or an admin

6
User side

View available shops- In this screen, a user will be able to view the list of available shops

View slots by shop- This page gives the user the list of available slots for that particular
shop

Admin side

View Users- View the list of users and their booked slots. When the user has finished their
slot, there is a status which can be updated.

7
4. SOFTWARE USED
4.1 FIGMA

Figma works on any operating system that runs a web browser. Macs, Windows PCs,
Linux machines, and even Chromebooks can be used with Figma. It is the only design tool
of its type that does this, and in shops that use hardware running different operating
systems, everyone can still share, open, and edit Figma files.

5. GRAPHICAL USER INTERFACE


5.1 Common Screen

This is the common screen where the user will choose either a shopkeeper(for shops) and
customer(for normal users like us).

8
5.2 Login

The login page which is pretty much common for both the customers and the shopkeeper, the login
will be implemented mostly by using googleoauth or firebase.

5.3 List of available shops

This page gives the customer the list of shops in his/her radius. Only those shops are shown
which are within a radius of 5km or less from the customer.
9
5.4 List Of Available Slots

Once the user sees the shops in the radius, they can then view the number of slots for every
shop as listed in the screen above and if it shows up in green, then that slot is available to
be booked, else the booked slot is shown in red.

5.5 Admin Side login

10
5.6 List of users in admin side

This is the screen on the admin side where the shop owner will be able to view the list of
users who have registered in different slots during the day, with an option to update the
status once the user has finished his slot timing.

11
Test Case Generation for
Small Scale Grocery
Management System
Revision 3.0

Individual Contributions:

Shreasi Sen 20BCE2738


Tested the shopkeeper(admin) modules. The profile page does require more
changes as it is different from the one mentioned in the SRS document and the
slot management needs a little tweaking.

Testing technique(s) applied

White box Testing is used. White box testing techniques analyze the internal
structures the used data structures, internal design, code structure and the
working of the software rather than just the functionality as in black box
testing. It is also called glass box testing or clear box testing or structural
testing.

1
Generating manual test cases of project modules

Unit Testing-Customer side

Test Activity Inputs Expected Actual Status(P Comments


Case ID Result Result ass/Fail)

TC-01 Click on None Redirect to Redirects to Pass None


customer the customer the
login screen shopkeeper
login screen
TC-02 Enter valid username:- Redirect to Redirects to Pass None
username and xyz123 home page home page
password password:-
*****
TC-03 Enter invalid username: Redirect to Redirects Pass Invalid login
username and 123xyz login page To login page attempt
password Password: stopped
*****
TC-04 Select an Shop(s) Customer Customer is Pass None
available shop selected will be able able to view
from list of to view the the slots for
available shops available the selected
slots for that shop
selected
shop
TC-05 Select an Slot Customer Customer is Fail Invalid
available slot selected will be not request
from the list for redirected to redirected to
the selected confirmation the
shop page confirmation
page
TC-06 Logout None Back to Same as Pass None
common expected
screen result

2
Unit Testing-Shopkeeper side

Test Activity Inputs Expected Actual Status(P Comme


Case Result Result ass/Fail) nts
ID
TC-01 Click on None Redirect to Redirects to Pass None
shopkeeper the the
shopkeeper shopkeeper
login screen login screen
TC-02 Enter valid username:- Redirect to Redirects to Pass None
username and xyz123 shopkeeper home page
password password:- home page
*****
TC-03 Enter invalid username: Redirect to Redirects Pass Invalid
username and 123xyz login page To login page login
password Password: attempt
***** stopped
TC-04 Add a new slot Slot A modal Modal shows Pass Better
timing,Dur shows up to up as per User
ation, Shop add the expectation experien
name,ID relevant ce
details such
as slot
timing,
duration,etc.
TC-05 Submit details on Slot Shopkeeper Error 404 Fail Page not
the modal form timing,Dur redirected to found
ation, Shop home page error,
name,ID on success accessing
an
unknown
page
TC-06 Logout None Back to Same as Pass None
common expected
screen result

Testing tool URL


https://testproject.io/
TestProject has made it easy to share & reuse recorded steps between test cases and has
made it so that anyone can create simple and useful tests without needing any previous
coding experience. The TestProject Smart Recorder also has AI-Powered Self-Healing
technology built right in.

3
Generating graph out of test case generation
Customer side

Shopkeeper side

4
Configuration Management-Use SVN subversion
tool for your project

It is an open-source tool for version control. SVN is used to manage the current
and previous versions of files like source code, documentation, and files. It acts
as the time machine for the developers and allows them to go back and browse
the history of the project.
We utilised this tool to keep all the revision history and create a complete
version of all the requirements.

[ Note: Automated Testing has been omitted for revision version 3.0 because
the backend development and the appending of frontend and backend are still
in progress. Hence, Software Testing has been carried out by using only Manual
Testing techniques. ]

You might also like