You are on page 1of 11

SOFTWARE ENGINEERING LAB PRACTICAL

STORE MANAGEMENT SYSTEM

Under the Guidance of – Prof. Amrit Pal Singh

Submitted By –

Nitin Gautam (07116412814)

Sindhu Dasari (07216412814)

Tanya Jayant (07916412814)

Saumya Chauhan (08416412814)

Btech ECE 7th Semester


PROBLEM STATEMENT

It is very important to maintain efficient software to handle information of a Store. This


application provides a systematic way to record the information and to access it easily.

The Store Management System includes maintaining the section records of stock, sales,
management and employees in specific along with the overall records of the store.
A Store Management System is required for the company at large and for a store in small to
analyse, manage and keep a track of all the functions taking place in the store. This system
for the store specifically will deal with managing the employee records, which includes
maintaining salary records, departments, working hours, etc., managing the product records
dividing them into different departments/sections, monitoring their stock details, sales etc.
The Store Management System will include –

 Employee Module – this contains all the employee details including, name, emp_id,
designation, department, salary and working hours per week.
 Section Module – the store is divided into different sections/departments depending
on the category. (Eg: in a garment shop, store might be divided into kid’s section,
women’s section, men’s section.)
 Stock Module – Under each section it includes details of old stock as well as of the
new stock. It contains their price details, sales and requirements.
 Offer Module – In case of any festive sales, all the offers will be included and
defined.

For different branches of the same store around the city, the management system can be
modified according to their needs. We can also create an integrated platform to track and
analyse the records of different stores and realise a way to improve the statistics.

Future Scope – Developing a well-managed system for the company in whole.


SOFTWARE REQUIREMENTS SPECIFICATION
1. INTRODUCTION
Store Management System is similar to the concept of what a manager in an office does.
Just like the manager manages his employees, a store management system looks into all
the details of a store. From the stock requirements to the employee salary, offers in the
festive season to the customer bills, a Store Management System can also act as a
record system.

1.1 PURPOSE
The purpose of the document is to collect and analyze all assorted ideas that have come
up to define the system, its requirements with respect to consumers. Also, we shall
predict and sort out how we hope this product will be used in order to gain a better
understanding of the project, outline concepts that may be developed later, and
document ideas that are being considered, but may be discarded as the product
develops.
In short, the purpose of this SRS document is to provide a detailed overview of our
software product, its parameters and goals. This document describes the project's target
audience and its user interface, hardware and software requirements. It defines how our
client, team and audience see the product and its functionality. Nonetheless, it helps any
designer and developer to assist in software delivery lifecycle (SDLC) processes.

1.2 SCOPE
Primarily, the scope pertains to Offline Grocery Stores. It focuses on the company, the
stakeholders and applications, which allow for efficient sales, management of
employees, customer satisfaction and also accounts for the supply needs.
This SRS is also aimed at specifying requirements of software to be developed but it can
also be applied to assist in the selection of products. The standard can be used to modify
the document later when expanding business to manage the needs of different stores
and also to compile the statistics at large for the whole company.

1.3 SYSTEM OVERVIEW


The system has 5 basic modules. One for the Admin, who is the store head and has the
major share in the stake of the store. He can regularly check the sales report and the
profit report and accordingly generate a plan for the future.
The second is the Employee module which contains all the employee details, from their
working days to the salary. It marks the best performing employee and sets a mark for
all the other employees as well.
The third is the Stock module which includes the details of the stock in each department
and alerts the supplier if the stock is running out. It can also analyse the stock-demand
ratio and specify the employees of the quantity of stock needed.
The fourth is the Supplier module. The Supplier can regularly check if delivery is to be
done and can update the same when delivered to the site.
The Customer module keeps record of all the purchases of the customer. The records
can be checked through in case of any discrepancies. It also specifies the purchase
details, like the mode of payment, offers or coupons used (if any), etc.

1.4 OVERVIEW
The remaining sections of this document provide a general description, including
characteristics of the users of this project, the product's hardware, and the
functional and data requirements of the product. General description of the project is
discussed in section 2 of this document. Section 3 gives the functional requirements,
data requirements and constraints and assumptions made while designing the E-
Store. It also gives the user viewpoint of product. Section 3 also gives the specific
requirements of the product. Section 3 also discusses the external interface
requirements and gives detailed description of functional requirements. Section 4 is for
supporting information.

2 OVERALL DESCRIPTION
This document contains the problem statement that the current system is facing which
is hampering the growth opportunities of the company. It further contains a list of the
stakeholders and users of the proposed solution. It also illustrates the needs and wants
of the stakeholders that were identified in the brainstorming exercise as part of the
requirements workshop. It further lists and briefly describes the major features and a
brief description of each of the proposed system.
The following SRS contains the detail product perspective from different stakeholders. It
provides the detail product functions of Store with user characteristics permitted
constraints, assumptions and dependencies and requirements subsets.

2.1 PRODUCT FUNCTIONS


 It generates an overall report of the sales and the profit. This report also creates
an analysis between the past and the present statistics which helps the
stakeholders to devise the future plans accordingly.
 It manages the employee details. Helps in looking out for the person in-charge of
a certain department, their number of vacations, their salary, time of promotion
and personal details (name, employee id, number, address).
 Stocks are managed department wise as well as by studying the demand rate.
This requirement of stocks is visible to the supplier and generates an alert once in
critical mode. This ensures timely delivery of the items.
 The software also helps in managing the customer details, the items purchased,
mode of payment, amount payable and automatically updates the stock.
 A special login page is created for all the different usage of the software for
security reasons.
 The Admin/Owner of the store has the right to override any command.

2.2 USER CHARACTERISTICS


 Admin – Overrides any action. He is the owner or major stockholder of the store.
He can view, update, add or delete any information. He is the one who manages
the access rights of the other users.
 Employee – Manages his own department. The Head of the Department can also
update the details of other employees and has an access to view the statistics of
his department. Other employees can view only their own details and stock
requirement details of their department.
 Supplier – He can view and update the supply of stock. The software generates
an alert to the supplier if the stock goes below the required limit.
 Customer – He can view the ongoing offers and can check their purchase details.

2.3 CONSTRAINTS

 Reliability requirements
 Criticality of the application
 Safety and security considerations regulatory policies
 Hardware limitations
 Interfaces to other applications
 Parallel operation
 Audit functions
 Control functions
 Higher-order language requirements
 Signal handshake protocols.

2.4 ASSUMPTIONS

 The software is assumed to be independent of outside environment.


 It is only for an actual offline store and not an E-store.
 Currently made for only one individual branch and not a group of stores.
 Proper Login credentials are given according to the use.
 Each user is equipped with basic knowledge of computers.
 The storage capability is taken into account.
3 SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACE REQUIREMENTS


 Hardware interfaces of LAN connection will be required. We will also need to set
up an Intranet on a local server to securely run the application internally without
any outside interference. During the purchase of item, the software needs to be
modelled along with the barcode reader and the card machine for recognition of
items and payment respectively.
 Valid inputs to the software, the billing software needs to be properly interfaced
with the stock database to update its details.’
 The user generated data must be easily followed with the software. The response
time should be quick and should not let the customer waiting.
 Proper protocols must be followed for communication among the various
devices.

3.2 FUNCTIONAL REQUIREMENTS


1. Admin
 Register/Signup
 Login
 Enter employee details
 View sales report
 Update employee details
 View profit report
 Logout
2. Employee
 Register/Signup
 Login
 View employee details
 Enter sales
 View stock details
 Update stock details
 Enter supply
 Update supply
 Enter offers
 Make bill details
 Receive payment
 Logout
3. Supplier
 Register/Signup
 Login
 View supply
 Logout
4. Customers
 Register/Signup
 Login
 Search item
 Add item to cart
 Buying items
 Making payment
 View bill details
 Receive items
 Delete item from cart
 Give feedback
 Logout

3.3 PERFORMANCE
The performance depends on the hardware used by the clients.
Initial loading time will be taken when starting the software. Once the interfacing is done
with the time taken to do a task will be minimum.
The connectivity factor will also be taken into account as it will run on their server.

3.4 SYSTEM SOFTWARE ATTRIBUTES


3.4.1 Reliability
The system shall be reliable that it gives the right results on the search.
Automatic backup will be generated during the idle period which will remove
the risk of losing data. A system backup will be taken at the end of the day.
3.4.2 Availability
The system response time will be minimum. It shall be 100% available when
in use. There will be automatic checks for network failure and will be notified
if there are symptoms leading to failure.
3.4.3 Security
The system will be password protected. Users will have to enter correct
username, password and role in order to access the system. An unauthorized
login will generate an alert.
3.4.4 Maintainability
The system shall be designed in an easily maintainable manner. It will be easy
to inncorporate new requirements in the individual modules. Expansion of
the project will also be easy to accommodate.
3.4.5 Portability
The system shall be easily portable on any operating system with a few basic
changes.

3.5 DESIGN CONSTRAINTS


 The system shall be built using a standard web page development tool that
conforms to either IBM’s CUA standards or Microsoft’s GUI standards.
 There are memory requirements to store data and backup customer details in
case of future discrepancies.
 The computers must be running on internal server of the store to connect to the
system. This internal network provides for a secure environment.
 The product must be stored in such a way that allows the employee easy access
to it.
 Basic knowledge of computers is required to use it.

4. SUPPORTING DOCUMENTS
Refer to the Use-Case Diagrams, Data Flow Diagrams and Entity-Relationship
Diagrams for better understanding of the structure.
Entity Relationship Diagram
Use Case Diagram

You might also like