Introduction
Purpose of the system
A case study at “XYZ” (an on-site corporate restaurant management and catering
company) cited issues regarding a basic resources requirement list that has to be maintained
manually by the staff. To keep track of their inventory levels they have to calculate a list of the
groceries utilized during a course of time, calculate and analyze the requirements for the future,
and place their next order to the vendors if needed. This process takes up a lot of time and human
effort and is also prone to human error.
This poses a problem of a situation that the staff at “XYZ” ‟ as well as many other
restaurants faces. It takes up a lot of time to manually keep track of sales and place correct orders
to vendors, wasting useful labor in trivial works.
A product which would assist in tackling the
above-mentioned problems would prove to be fruitful to clients such as “XYZ” and
similar enterprises as this product would help convert the unproductive time to something more
useful, by removing the unnecessary error-prone complications and efforts.
Scope of the system Inventory Management System Project
The project aims at providing an efficient interface to the restaurants for managing their grocery
inventory based on each item sold. The basic idea involved here is that each item is linked to its
atomic ingredients which are stored in a database.
At the end of each day, the system analyzes
the total sale of menu items and proportionately deducts the appropriate amount from the resource
database. Then it compares the currently available resources with the threshold level of each
ingredient. If it finds that certain ingredients are below the threshold, it will generate a purchase
order for those item(s) and send it to the manager (admin) for approval.
We also propose to include a special feature “Prediction”.
This feature keeps track of any
upcoming occasions, climatic changes, and special events that may influence inventory needs for
the upcoming week. The system will then predict the required resources for these events based
on previously accumulated information/knowledge. It will now generate an updated purchase
order in accordance with the predictions.
The product also aims to keep track of the shelf life of resources. If any resource nears the end of
its shelf life, it would intimate to the manager (admin) the details of the quantity that is near its
expiration date. The restaurant must function efficiently, the groceries must be tracked correctly,
timely orders must be sent out to the vendors, and the inventory must be maintained and updated
at all times.
Objectives and success criteria of Inventory Management System Project
The objective of the project is to provide an efficient inventory control whose main functionality
apart from calculating the inventory include predicting the requirement for the next order and
also if there is a “Special Occasion” then accordingly the manager selects the particular occasion
and extra requirements is added to the next issuing order to the vendors which needs to be
approved by the manager.
The product also aims to keep track of the shelf life of resources. If
any resource nears the end of its shelf life, it would intimate to the manager (admin) the details
of the quantity that is near its expiration date.
The success criteria depend on
The accuracy in maintaining the inventory levels
The accuracy in predicting the requirements of the next order
The accuracy in relating recipes to their respective ingredients
Ease of use when it comes to updating inventory levels and placing orders to vendors
The Domain of Inventory Management System Project
This proposed project aims at inventory control in the restaurant and catering Industry. Such a
large domain would result in an equally large scope of development. As a result, we narrow
our software down to our case study of an outlet of “XYZ” concentrating only on the
basic resources utilized in inventory control of the outlet.
Although the software will be
developed keeping in mind the needs of “XYZ” and available data at first, then applying
it to the larger domain of the entire restaurant industry can be achieved with ease.
Our target domain is full of software to track sales of food items but lacks in this area of
inventory management. Our software can be scaled from large corporate dining all the way to
small privately-owned restaurants. It is also fairly domain-specific: the database runs off recipes
that generate the necessary ingredients. It also updates the inventory based on the sale of
those recipes. This requirement focuses our product on our domain and makes it more appealing
to those looking for a solution to this specific problem.
The Client
The client can vary from private restaurant owners to corporate restaurant management
companies, such as “XYZ” (www.XYZ.com). A corporate restaurant
management company that starts up, staff, and oversees the everyday workings of a corporate
restaurant, such as the one in the Groupon Chicago office.
As stated above, while our product
can be applied to the entire domain of the restaurant and catering business, focusing on a specific
business provides us with more precise and consistent data. A company such as “XYZ”
would be an ideal client, as they staff multiple corporate kitchens across the nation, including
kitchens for Groupon and even Google. A large scale company such as this can apply our
software to each and every kitchen, cutting down costs on a very large scale.
Our software will allow our clients to customize the database to suit the needs of each kitchen
individually.
They can vary in recipes, vendors from which they order their products, and
threshold levels. This provides a uniform product that can be customized at a smaller scale. Our
client would need to purchase multiple licenses, or more likely a corporate subscription that
would allow them to use the software in multiple kitchens. We would also offer single-use
licenses to appeal to restaurants that only need to manage a single inventory of goods.
The User
The main users of the product would be kitchen management and staff. The management would
approve the orders that would be sent out, provide vendor information, upload recipes, and set
threshold levels. Many of these tasks, such as the information regarding vendors, recipes, and
threshold levels would need to be set only once.
Of course, the option to add, remove, or update
this data would be implemented as well. Once this initial step has been taken, our software will
require nothing more than a weekly approval for the orders being sent out, minimizing the work
that management has to complete in order to ensure the correct amount of inventory is available.
The kitchen staff would be responsible for updating the number of products sold at the end of the day.
Each day, the register prints out the products sold and the quantity of each product sold.
Instead of manually subtracting that amount from the inventory, they input the amounts sold into our
software which will do the number crunching for them. This data is also stored in the
“predictions” feature for future use.
Definitions, acronyms, and abbreviations of the Inventory Management System Project
Manager: The manager implies the manager of the restaurant/company who handles all
the administrative works.
Recipe: This is the menu item that the restaurant/company provides to its customers.
Ingredient: This is the entity that the recipe is composed of.
Vendor: This is the company that provides the restaurant/company with the required
ingredients.
Order: Order is the list of ingredients and the quantities that is or are to be requested from the vendor.
The current system of Inventory Management System Project
“XYZ‟ (an on-site corporate restaurant management and catering company) follows a
system where the basic resources list needs to be manually calculated at the end of a certain time
period by the staff. They must accordingly check the inventory levels for determining if they are
below the threshold level then orders are processed to the vendors.
This sort of system not only leaves a lot of room for human error but is also incredibly time-consuming. The lack of a
the centralized database also creates an issue when it comes to keeping track of inventory levels as
well as past trends in ingredient requirements. The system also relies on human intuition and
guesswork to place the correct orders for the following week, which will not be as precise as an
an algorithm designed for this purpose.
The proposed system of Inventory Management System Project
Overview
We propose to develop software that keeps track of inventory in the “back of house”, or kitchen
and updates it according to daily sales. Each food item is linked to respective resources (or
ingredients) and as each product is sold the ingredients utilized in making that product are also
utilized.
These changes in inventory are kept track of through utilizing a database.
We propose to keep track of each and every ingredient by dynamically linking it to the product
and as a result, create a dependent relationship with that product.
At a specific time period (typically
the end of the week); if the inventory is below the threshold level, order forms to the specific
vendors are generated in order to restock the required items for the next week. The project also
makes smart predictions on required inventory for the following week based upon the predicted
climate and possible occasions or events that may influence future sales.
At the end of the
week, the software takes into account all threshold levels, predictions, and other factors to
generate an order form, which after being verified by the manager is sent out to the vendors.
Functional requirements of the Inventory Management System Project
The System aims at providing an efficient interface to the user for managing inventory, it shall
also, provide the user with varied options for managing the inventory through various functions at
hand. The ingredient levels are continuously monitored based on their usage and are checked for
the threshold levels in the inventory and accordingly the user is alerted about low levels of
certain ingredients.
The design is such that the user does not have to manually update the
inventory every time, the System does if for the user.
The System calculates and predicts the amount of usage for specific set days that are pre-set by
the user(admin), it also alerts the user of impending action to order ingredients before the
a specific day set by the user.
Therefore the user never has to worry about manually calculating the
estimated usage of the ingredients as the System does it for the user.
The simple interface of the System has functions like adding a recipe, removing, or updating the
recipe. It also extends to functions such as adding a vendor for an ingredient, removing the
vendor, checking threshold levels, processing orders, altering processed orders, etc.
Nonfunctional requirements of Inventory Management System Project
Usability of Inventory Management System Project
o The system must be easy to use by both managers and chefs such that they
do not need to read an extensive amount of manuals.
o The system must be quickly accessible by both managers and chefs.
o The system must be intuitive and simple in the way it displays all relevant
data and relationships.
o The menus of the system must be easily navigable by the users with buttons
that are easy to understand.
Reliability of the Inventory Management System Project
o The System must give accurate inventory status to the user continuously. Any
inaccuracies are taken care of by the regular confirming of the actual levels with the
levels displayed in the system.
o The System must successfully add any recipe, ingredients, vendors or special
occasions gave by the user and provide estimations and inventory status in
relevance with the newly updated entities.
The system must provide a password enabled login to the user to avoid any
foreign entity changing the data in the system.
o The system should provide the user updates on completion of requested processes
and if the requested processes fail, it should provide the user the reason for the
failure.
o The system should not update the data in any database for any failed processes.
Performance of the Inventory Management System Project
o The system must not lag, because the workers using it don‟t have down-time to
wait for it to complete an action.
o The system must complete updating the databases, adding of recipe, ingredient,
vendor, and occasions successfully every time the user requests such a process.
o All the functions of the system must be available to the user every time the system
is turned on.
o The calculations performed by the system must comply according to the norms set
by the user and should not vary unless explicitly changed by the user.
Supportability of the Inventory Management System Project
o The software is designed such that it works even on systems having the
minimum configuration.
o The system is adaptable even if additional plugins or modules are added at a
later point.
o The data can be exported to the manager so as to make the system more
portable.
Packaging of the Inventory Management System Project
o The system must be able to run on the Windows operating systems beginning
with Windows XP and must be able to run on future releases such as the
upcoming Windows 8
o The software must incorporate a license key authentication process.
o The packaging must come with a manual that details the use of the system,
and also the instructions on how to use the program. This manual may be
included either in a booklet that comes with the software or on the disc that
the software itself is on.
Implementation of the Inventory Management System Project
o The System User Interface is built on Microsoft Visual Studio 2010.
o The Programing is done in Microsoft Visual Studio 2010.
o The Database is implemented on the Microsoft Access 2010.
Interfacing
o The system must offer an easy and simple way of viewing the current inventory.
The system must be able to display the relationships between vendors, ingredients,
and recipes in an intuitive manner.
Legal
o The software must be licensed on an individual basis for smaller companies,
as well as through a multi-license deal for larger corporations.
o The client should agree to EULA before using our software.
Use cases:
- Update Resources Database Use Case
| Usecase name | UpdateResourceDatabase |
| Participating | Initiated by Manager(admin) |
| Actors | |
| Flow of events | 1. The Manager activates the updated resource database function.
2. The System presents a form to the Manager. The form asks for details of the sold food items during the course of the week and the corresponding quantity of the food sold. 3. The Manager inputs the data of the sold food for the week and the quantity that was sold and presses the Ok button. 4. The System reads the sold food data and then further reads, from the ingredients database, the ingredients that were used in making of the food items that were sold. 5. The System now calculates the number of resources used and will deduct the number of ingredients that were used up from the resource database. 6. The System now invokes the CheckThreshold use case. |
| Entry condition | The Manager(admin) is logged on to the System |
| Exit condition | If the process was successful, the Manager receives an acknowledgment that
the process was completed successfully. OR If the process was not successful, the Manager will receive an explanation of what error had occurred during the process? |
| Quality
Requirements |
The update process must complete successfully and without errors. |
Entity Objects
- Manager: The user who initiates and manages the whole use case. The Manager enters the sold food data into the form that is presented to him and also controls what actions are to be taken once all the calculations are over.
- Resources: These are the ingredients that are available for use in the making of the recipe.
Boundary Objects
- Update Resource Database Button: This is the Button the manager presses to initiate the processes in the use case
- Sold Food Form: This is the form Manager fills to give details about the food that was sold in the course of the week.
- Process Order Form: In this form, the manager enters the quantities corresponding to each ingredient that the manager wants to update.
Control Objects
Update Control Object: This object is created when the manager activated the UpdateResourceDatabase Function. The Object is then responsible for creating the SoldFood Form and requesting resource levels from the database, comparing new values with the threshold values, and also sending the new values back to the database.
The Object also sends out acknowledgments to the Manager once the requested processes are completed.
| Use case name | CheckThreshold |
| Participating
actors |
Initiated by UpdateResourceDatabase usecase Or by AddOccasion usecase |
| Flow of Events | 1. The System now compares the current levels of the resources with
the threshold levels of the resources. It now lists all the ingredients that are below the threshold level, along with the predicted usage of the ingredients and presents it to the Manager. 2. The Manager can now send out orders by pressing the Process order button. This action invokes the processOrder usecase. 3. If Manager presses cancel, no orders are processed. |
| Entry | The manager is logged on to check the inventory levels at the interval of a |
| Conditions | certain time period. |
| Exit Conditions | The inventory levels are checked and the appropriate action is taken. |
| Quality | The system correctly calculates the correct threshold differences |
| Requirements |
Entity Objects
- Resources: These are the ingredients that are available for use in the making of the recipe.
- ThresholdLevels: These are the ingredient levels below which an alert is generated for the manager to generate new orders.
Entity Objects:
Manager: The manager activates the use case to remove a recipe.
Recipe: This is an entity that is being removed by the manager. The recipe is defined by the items that are used in making of the recipe.
Boundary Objects:
RemoveRecipe: This button initiates the add recipe use case which helps in adding a new recipe to the database.
Remove Recipe Form: This form presents a list of recipes currently in the database and asks the manager to select which recipe is to be deleted.
Control Objects:
Remove Recipe Control: This control object manages the whole process of updating recipe. It manages the process of adding/removing the ingredients from the recipe. It also acknowledges the process status of the manager.
| Usecase | AddOccasion |
| name | |
| Participating | Initiated by Manager |
| actors | |
| Flow of events | 1. The Manager activates the “Add Occasion or Event” function on his/her |
| terminal. | |
| 2. The System displays a form to be filled out by the manager. | |
| 3. The Manager fills out the form by adding a name of the event or occasion | |
| and selecting the date(s) the event is to be held. | |
| 4. The Manager now fills list of recipes that will be utilized more on the | |
| selected day. | |
| 5. The System takes the data from the form and calculates the amount | |
| of ingredients that may be used up for the given dates based on past | |
| data and adds the data to the ingredient database. | |
| 6. The System now invokes the CheckThreshold use case. | |
| Entry condition | The Manager is logged into System. |
| Exit condition | The Manager receives a notification of successful completion of the process |
| OR | |
| The Manager is notified that the process was not complete with a valid | |
| explanation of the error that had occurred during the process. | |
| Quality | The Occasion is accurately added to the database. |
| Requirements | |
Entity Objects:
Manager: The manager activates the use case to add an occasion to the database.
Recipe: This is an entity that is being added here for special use on the day of the occasion. The recipe is defined by the items that are used in making of the recipe.
Ingredients: Ingredients are the entities that the recipe is made up of.
Boundary Objects:
Add Occasion Button: This button initiates the addOccasion use case which helps in adding a new occasion to the database.
Add Occasion Form: This form asks for details about the occasion that is to be entered in the database. Details such as date, recipes that are sold more etc. are added as occasion details
Control Objects:
Add Occasion Control: This control object manages the process of adding the new occasion to the database and thus recalculating new threshold levels and resources requirements for the manager to consider.
- Update Inventory Use Case
| Usecase name | UpdateInventory |
| Participating | Initiated by Manager |
| actors | |
| Flow of events | 1. The Manager activates the “Update Stock inventory” function on his/her |
| terminal. | |
| 2. The System now presents a form to the Manager asking for details | |
| of the received amount of ingredients. | |
| 3. The Manager enters the ingredients and the corresponding quantity | |
| received and presses the submit button. | |
| 4. The System adds the corresponding amount to the resources | |
| database and acknowledges the completion of the process. | |
| Entry condition | The Manager is logged into the System |
| Exit condition | The Inventory levels are successfully updated |
| Quality | The number shown to the manager accurately shows the actual amount of |
| Requirements | ingredients stored. |
Entity Objects:
Manager: This entity initiates the use case to update the stock inventory once the new order is received.
Ingredients: The ingredients are the basic building blocks of the recipe. Here the ingredient delivery is accepted in accordance with the order issued for the ingredients and updated in the ingredients database.
Boundary Objects:
Update Inventory Button: This button when pressed by the manager brings up a form for the manager to add the number of ingredients that are received in the order.
Update Inventory Form: This form asks the details about the ingredients that were received and the quantity that was received of the respective ingredient.
Control Objects:
UpdateInventory Control: This object manages the whole updating ingredient database after reading the sold received food data from the form.
- Correct Inventory Use Case
| Use case name | CorrectInventory |
| Participating
actors |
Initiated by Manager |
| Flow of Events | 1. The Manager presses the “Correct Inventory” button on the console.
2. The System presents a CorrectInventory form to the Manager with the list of ingredients and corresponding remaining quantity. 3. The Manager now enters the corrected quantity (if any corrections exist) corresponding to each ingredient and presses the submit button. 4. The System now updates the resources database with the correct quantity. The System calculates the errors that were existing in the original and the corrected values of the resources and accordingly adjusts the value of the number of ingredients used per recipe. It then prints out the correct inventory to the screen. 5. The Manager then acknowledges that the calculated inventory is accurate. |
| Entry
Conditions |
The Manager is logged into the system |
| Exit
Conditions |
The Inventory level is correctly updated |
| Quality
Requirements |
The data taken from the Manager is accurately stored in the database. |
Download Source code of inventory Management system project in PHP
Download in a new style inventory Management system project in PHP
Important Links for MCQs Preparation.
General Knowledge MCQs Preparation:Everyday Science MCQs Preparation:English MCQs Preparation:
