Professional Documents
Culture Documents
Requirements Analysis For Bakery Software
Requirements Analysis For Bakery Software
Fogaing Christian
Assistant Instructor: Mr. Mekontso Herman
REPUBLIC OF CAMEROON
Peace Work Fatherland
*********
MINISTRY OF HIGHER EDUCATION
PKFOKAM INSTITUTE OF EXCELLENCE
Dignity Faith - Responsibility
*********
FACULTY OF SCIENCE AND
TECHNOLOGY
*********
PROJECT REPORT
GROUP II: BAKERY MANAGEMENT
Group Members
Tsaku Nelson Zange
Mopewou Franck Teddy J.
Simo Kaptue Jordan
Registration Numbers
13S006
13S002
13S004
Table of content
JUNE 8, 2015
I.
Analysis documentation
Introduction
Since the creation of the bakery store, managers with the help of their employees used to record
their daily sales, orders, commands etc. in a log book (registers) each time a product was bought or when
the store was filled. This made the overall work tedious, cumbersome, time consuming and boring as at
the end of each day, the inventory was to be made and products updated manually with the use of manual
calculations and recorded in registers. This style of management is still widely used nowadays especially
in developing countries. Because this is no more a safe method of managing stores and bakeries in
particular, especially with the ever evolving technologies nowadays, we therefore have as aim to develop
the engineering of bakery management by creating a consistent, robust and accurate software usable by
any bakery system to disable as much as possible most of the problems we still encounter such as theft,
inventory processing, receipt modeling, unnecessary, long and complicated calculations and many
others when using such aquake methods.
Because we are dealing with the management of products in the bakery, we therefore will focus
on selling the products, managing daily inventories printing receipts, keeping track of each and every
product and all other product related functionalities. Thus, management of employees and other
structures will not be handled except those identified as actors to our system. We therefore have two
main departments; the first being in charge of delivering products to incoming customers and the second
being in charge of product management. These two departments will constantly be in touch with the
software and consequently be held accountable for all processes on products. Each member in this
department will therefore have a head whose personal information such as the ID, name, etc. will be
required for registration.
Lastly, we have the bakery manager. The manager has a unique name and ID number as she/he
will have absolute access to the system.
Our system will therefore manage all these actors by providing them with functionalities in
order to facilitate its day-to-day functioning. All these will be better explained in our project, bounded
by the attainment of the following objectives.
1.2
Objectives
Our aim being to design a robust, consistent and accurate software for the bakery management, to automate
all the tasks and processes involved in it and to maintain the industry at a favorable level to current
industries technologies, enable us to have the following objectives:
Improve the speed and accuracy at which activities are performed in the bakery.
Ensure proper management of products and customer needs.
Exacerbate as much as possible security and proper inventory of products in and out of the bakery.
Constantly enable improvements and growth with respect to the current technology.
The customer:
The only secondary actor here is the customer who just aims at buying items delivered by the
receptionist. Information from the customer might therefore not be necessary except for very import
customers (VIPs) whos ID might be needed.
2.2
From the diagram, the manager (owner) is at the top of the hierarchy and is the one having the
highest rights in the bakery management software. Following him is the inventory clerk, then the
receptionist. The customer has no right on the software apart from requesting for his products from
the receptionist.
3.
3.1
Functional requirements
Identification of functional requirements with respect to actors
3.1.1 The receptionist:
The Functional requirements related to the receptionist are stated below:
The receptionist can search for any product: The software, through the graphical user
interface provides an option to search for any product. To search, the receptionist simply needs to enter
the ID of the product and press enter. This functionality will enable the receptionist to easily perform
other actions as will be explained. Each time a product is searched, you the receptionist can add it to
6
Edit a receipt: As a customer places his items on the counter, the receptionist is able to search for any
product from the database then adds or removes it from the receipt until it suits exactly the items placed
on counter from where she can print the receipt which is automatically updated into the inventory list.
Performing orders: The receptionist could inspire himself from the software by searching for any
readymade order, then edit and model it for the current required order. This will be mostly for very
important customers who most at times gives commands for a set of products, whose receipt must be
generated and good delivered at the due date.
3.1.2 The
Inventory Clerk:
Performing Stock inventory with respect to sales: Because the inventory clerk will have to perform
a stock inventory every day she/he should have direct access to the product database and be able to
update each and every product with respect to the sales inventory offered by the receptionist.
Performing Stock inventory with respect to supplies: The software through GUI will also record
by mean of the clerk any new product. Information such as product ID, name, price, quantity and
expiry date will therefore be requested from the clerk when registering the new product.
Ensuring proper maintenance of products with respect to expiry date and keeping track of every
product: The software also enables the clerk via our robust search engine to look for any expired
product enabling him to delete it or transfer it for other processes. Moreover, having access to the sales
inventory enables the clerk to ensure proper transactions and maintain security thus, the clerk will be
the first to be consulted in case of theft.
Create an employee (a new receptionist or clerk): The software therefore offers a GUI through which data
from the new employee will be entered and when validated, the new employee will automatically be
created in the database with already assigned functionalities in relation to the information entered.
Moreover, a minimum of controls will be performed during creation to ensure that the owner enter
consistent data(name, ID, address, telephone home, description, date) in order to avoid confusion .
II.
Modify and delete employee: Here, the owner will simply enter the employees ID in the required text
field from the GUI offered by the software. From there, all the employees personal information will be
displayed and they will be given options using buttons to either modify the selected employee or delete
him/her at will.
III.
Access any log file: This representing all the interaction of other employees (receptionist and clerk) with
the software; that is he/she will be able to follow all the transactions carried out into the software or request
for any query from the receptionist or clerk and will.
We should note that each and every employee including the manager will need to provide authentication
before carrying out any action. Thus, the current user will be given just five trials to access the software.
In case you forget your password, contact us.
3.2
Creating products: Products in the store must be given either a barcode or an ID, a name,
description, price etc. (as specification requirement tells) and all entered in the products database as long
as the product enters the store. If a product is new and has a bare code, it will then be created using the
barcode reader use case. Else, all the necessary information will be entered with an ID, without the help
of a barcode.
If the product already exist and stock needs to be filled, then the quantity should be updated in the
products database with respect to the expiry dates. This will be done with one click on the update use
case which extends the products.
-
If a product is expired, then as it is removed from the store, it should be deleted from the database
first by searching the product using the search use case then deleting the product using the delete use
case (two clicks at most), which all extends products.
-
For more information about a product, the user (inventory clerk) could directly click on the search
use case then click on the barcode use case (if the code exist) or simply enter the ID of the product in the
search use case. (Two clicks)
This use case just lets us know that, as soon as any customer sets an item on the counter all the
items on the counter at that moment must be searched and sold using the search item list use case by the
receptionist. It does not perform any specific task other than just relating the customer to the receptionist
through the items by a click on the sell item button in the GUI.
Use Case 3: search item (a primary use case made of a structured list)
-
Here, as soon as the customer sets item on counter, this use case is triggered were the receptionist
will swipe the barcode reader across the code on item (if any), then the system will look up the code from
the code reader in the database of products and then will retrieve the name and price (if product exists in
stock). This will be done with the help of the barcode use case which extends search item. Because most
of the products do not have barcodes, we then provide a text field in the GUI to retrieve the ID of the
corresponding product and display the product as the main search method.
After having searched the system will adds price and item type to the list using the add item use
case or will remove the price and item type from the list using the remove item use case.
-
After having made the exact list corresponding to all the items on counter, the system will finally
add all the prices to the correct tax subtotal and wait for sale execution.
Being a complex use case which must necessarily be robust and fast as far as execution is concerned
everything have been simplified such that depending on the number of items on counter, a maximum of
10
Extending search item, this use case will automatically provide a printable receipt as it includes
the print receipt use case and will also produce a list of items and quantity sold which will be
automatically saved in the sales inventory use case update the database of products.
-
Moreover, as soon as this use case is executed, and automatic update in the inventory list use case
will also be permitted as the inventory list use case is a generalization of product and so can inherit the
update use case. This is very important as the inventory list use case will be used by the inventory clerk
in getting the reduction in products and comparing it with the current sales inventory in the sales inventory
use case; thus, in case if any theft, the inventory clerk will be aware and able to give account.
This use case is a child of products because it will need to contain all the products in the bakery so
that each and every item which is sold will be automatically deleted in this use case, after which at the end
of the day, the inventory clerk will be able to compare removed items from this list with the sold items in
the sales inventory before executing any update in the product database.
We there notice a total of four actors in our bakery management (the customer, receptionist, inventory
clerk and manager) with the main actors being the receptionist and the inventory clerk as the actor-use case
interactions can tell. The manager must also be considered as a main actor because he/she is a generalization
of the receptionist and inventory clerk, and therefore inherits all the actions these two actors can perform in
11
Finally, assuming login has been made, it is worth noting that for a sale to be performed by the
receptionist a total of three clicks will the required if the item has a barcode, or four clicks if it doesnt.
On the other hand the inventory clerk will require just two clicks to confirm and update the products
through the inventory list.
4.
Non-functional requirements
A. Performance restrictions: for the bakery to make a maximum benefit of the software, the bakery
management software should be installed and run on very good and modern computer with the minimum
requirements which will be stated soon.
B. Robustness restrictions: The software is to be a robust one and should be able to handle error conditions
without exacerbating the users patience. This includes a tolerance of invalid data, software defects, and
unexpected operating conditions.
C. Security constrains: access to the software should be restricted to employees of the bakery with the right
credentials. Also, software files will be exclusively accessible to the owner only
12
5.
Figure 1: Relationship between Use cases and Actors in the bakery management
13
6.
6.1
14
6.2
Receptionist
15
Actors: this class encapsulates the concept of users. I.e. those who are permitted to use the software.
This restriction is provided by implementing a user pseudo Name and a password for confidentiality
Actors management: business class to manage users. There is a dependency relationship between
this class and the class actors (the class actor management is dependent on the class actors).
Orders: this class encapsulates the concept of sales. Meaning that the sales performed here are
registered together with the product id, number of items sold, total price and the sale id, to easily make the
inventories at the end of the day. There is an aggregation relationship between the class orders and the class
products (an order includes products).
Orders management: this is the business class to manage orders. There is a dependency relationship
between the classes orders and order management (order management depends on orders).
2. Class Diagram
Below is the class diagram of the bakery software showing not only the different concepts used in the
software design, but also the relationship between them.
16
17
2. Installation procedure
A pack containing the license agreement, the documentation, and the little log note explaining the
getting started tutorial for the software. In the very pack will be an original cd ROM containing the
software and all related information including the installation procedure.
As you insert the cd into your DVD driver, a dialog box will automatically appear requesting for
running the program as administrator. All you need to do is to click ok from where you will have to
read the license agreement and proceed to the actual installation process. Make sure you chose the
preferred directory for the program else, it will be installed into the default directory.
The manager (owner) has access to a special menu from where he can in turn access all the others,
including some special functionalities such as modifying prices, registering an employee, registering very
important customers, ensuring that proper inventories are made by checking that of any day he wants to
check in case of any suspicions, etc. To perform his tasks, he has simply has to login as administrator with
the required password from where his menu will be displayed providing him with all the options he needs.
Conclusion
Going through the complete documentation of our software, we can safely say with utmost
conviction that the speed and accuracy of each and every activity performed in the bakery will forcefully
be improved; proper management of products and customer needs will be ensured; security and proper
inventory of products in and out of the bakery will be accurately taken care of and constant
improvements/growth with respect to the current technology will always be enabled with the updates we
will always provide. Having attained our objectives as just highlighted above, we believe that proper usage
of our software will consequently halt to a short term achievement of our goal which was design a robust,
consistent and accurate software for the bakery management, to automate all the tasks and processes
involved in it and to maintain the industry at a favorable level to current industries technologies.
19