0% found this document useful (0 votes)
230 views8 pages

Inventory Management System (For Beverage Wholesaler) : Software Requirements Specification and Design Document

This document provides a requirements specification for an inventory management system for a beverage wholesaler. It outlines the current manual paper-based system and proposes an automated system. The proposed system would allow receiving multiple items into inventory, viewing items and their locations, viewing item histories, transferring item locations, and shipping items out via trucks. It includes functional requirements like adding/updating inventory quantities and viewing item details. Non-functional requirements cover the hardware, user interface, security, quality, documentation, and performance needs. Data flow and class diagrams as well as a system structure chart are provided to model the system.

Uploaded by

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

Inventory Management System (For Beverage Wholesaler) : Software Requirements Specification and Design Document

This document provides a requirements specification for an inventory management system for a beverage wholesaler. It outlines the current manual paper-based system and proposes an automated system. The proposed system would allow receiving multiple items into inventory, viewing items and their locations, viewing item histories, transferring item locations, and shipping items out via trucks. It includes functional requirements like adding/updating inventory quantities and viewing item details. Non-functional requirements cover the hardware, user interface, security, quality, documentation, and performance needs. Data flow and class diagrams as well as a system structure chart are provided to model the system.

Uploaded by

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

Addis Ababa University

Submitted to: Mrs Axumawit T.

Group Members:
● Abel Tesfaye - NSR/4186/10
● Ameen Zuber - NSR/2467/10
● Dagmawi Getachew - NSR/7221/10
● Amanuel G/Hiwot - NSR/7850/10

Inventory Management
System (For Beverage
Wholesaler)

Software Requirements
Specification and Design
Document
26th December 2019

Table of Contents

Introduction 2

Current System 2

Proposed System 2
Overview 2
Functional Requirements 3
Non-Functional Requirements 4

System models 5
Data Flow Diagram 5
Class Diagram 6

System Structure Chart 7

1
Introduction
The business we would be making this software for is a beverage wholesaler whose day to day
activity involves buying multiple beverages in bulk, storing them then later selling them to store
owners.

He is responsible for organizing cargo transport when both buying and selling the beverages. On
top of that he has to continuously manage his inventory to make sure he won't be out of stock.

Current System
The current system is a cumbersome manual process which involved the following steps:

1. The wholesaler purchases multiple beverages from a factory then he organizes cargo
transport using his own trucks.
2. Once the beverages arrive, their arrival date, quantity, item name are recorded on a book.
3. The beverages are then stored in the warehouse and their location will be recorded.
4. Whenever the wholesaler sells an item, the items will be searched for on the book then
their physical location is found. Employees fetch the requested quantity and put them on
trucks.
5. The items will be sent to the customers and the book will be updated with the current
quantity on hand and the truck that shipped it.

Proposed System

Overview
Since the goal of this system is to replace "traditional" bookkeeping and inventory tracking
methods, the system should be able to keep track of items in the warehouse as well as keeping
track of the items state(outgoing, incoming or on hand).

To quickly locate items there should be an easy to use search functionality. And whenever items
are shipped or received the items on hand should be incremented or decremented as per the
item count.

In addition the items history should also be available, the item history contains information on
when and where it came from and what truck was used to deliver it to the warehouse.

2
Functional Requirements
● The user should be able to receive multiple items in the system from every shipment
○ A shipment can contain multiple items
○ If the item does not exist, a new item should be created with the initial quantity
(amount being received) and warehouse location
■ A default location of 0 for Aisle, Bay, Shelf should be used for initial intake.
○ If the item already exists, the current quantity available should be increased by the
amount being received
● A user should be able to see an overview (grid) of all items currently in the warehouse,
their current location, and quantity on hand
○ This should be a grid with a row for each item, and a column for Inventory number
(inventory ID), inventory name, UPC, Aisle location, bay location, shelf location,
and quantity on Hand
○ Can use search filters to narrow down the items shown in the grid to help filter the
results.
● A user should be able to view an item’s details and transfer location
○ This could be done by clicking on the item and going into the details.
○ The details screen would show the item number, name, UPC, available quantity,
current location
○ A link that should lead to a small pop up window should show the history of item’s
quantity on hand.
■ The popup window should contain:
● A grid which holds the truck numbers that the inventory came in
with, and how much it increased quantity on hand by.
● Also, it should show other information such as quantity currently
available and item’s location in the warehouse.
○ Allow the user to assign a new location, however, if inventory is already in this
location, do not move it, instead show a message to the user stating which item is
in that current location.
● A user should be able to ship out items via trucks
○ The user should be able to ship out multiple inventory items in one shipment
● A truck number should be entered for record keeping
● The quantity on hand should be deducted for amount shipped out.
○ If the quantity on hand is less than the amount being shipped out do not allow it.

Non-Functional Requirements

3
Hardware considerations

Inorder for the system to run optimally, the following hardware requirements must be met:

● Operating System: Windows 7, Windows 8, Windows 8.1, Windows 10


● Minimum screen resolution: 1024 x 768
● Minimum RAM: 4 GB
● Minimum secondary storage disk space: 10 GB
● Minimum secondary storage speed and type: 300 MB/s Solid State Drive (SSD)

User Interface

● The system should be very clear and easy to use as no prior formal training will be given
to the employees.
● Most commonly used user interface components should be displayed on the first window
of the system.

Security

● The system should be password protected.


● Employees should always change their password every week.

Quality

● The system should be available throughout the employees work hours. Maintenance and
system updates should be done after work hours.

Documentation

● User documentation in the form of easy to understand diagrams should be provided.


● Technical documentation of the system should be made available in case there is a
reason for working on the codebase.

Speed

● The system must be interactive and the delays involved must be minimal.
○ When opening any of the windows the delay should be less than 2 seconds.
○ But if opening databases, sorting items or fetching large data then delay should
not exceed 5 seconds.

Robustness

● The system should go for at least the whole work hours without being restarted or
encountering any failure/exception that would cause it to reboot.
● There should be generators and UPSs to ensure the system runs without any interruption.

4
● In the event of a reboot, the system should take no more than 5 minutes to be usable
again.

System models

Data Flow Diagram

Class Diagram

5
System Structure Chart

6
7

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy