Requirements Analysis for bakery software

Instructor: Mr. Fogaing Christian

Assistant Instructor: Mr. Mekontso Herman

1

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

Table of content

Group Members Registration Numbers

Tsaku Nelson Zange 13S006

Mopewou Franck Teddy J. 13S002

Simo Kaptue Jordan 13S004

JUNE 8, 2015



2

Project: BAKERY MANAGEMENT SYSTEM............................................... 1

I. Analysis documentation ................................................................................. 3

1. Description of the project with theoretical review............................................ 3

1.1 Introduction………………............................................................................. 3

1.2 Objectives ....................................................................................................... 4

2. Identification of the actors................................................................................. 5

2.1 List of actors and their roles………................................................................ 5

2.2 Relationship between actors............................................................................ 6

3. Functional requirements ................................................................................... 6

3.1 Identification of functional requirements with respect to actors…................ 6

3.2 Identification and expression of relationships between use cases.................. 9

4. Non-functional requirements........................................................................... 12

5. Use case diagram.............................................................................................. 13

6 Sequence System Diagram ............................................................................... 14

6.1 Use case: add Product..................................................................................... 14

6.2 Use case: sell Product..................................................................................... 15

II. Design Documentation.................................................................................. 16

1. Relationship between business concepts ......................................................... 16

2. Class diagrams ..................................................................................................16

III. System installation documentation............................................................ 18

1. Minimum computer requirements.................................................................... 18

2. Installation procedure....................................................................................... 18

III. User Documentation.................................................................................... 18

Getting started with the system........................................................................ 19

IV. Conclusion…………................................................................................19



3

I. Analysis documentation

1. Description of the project with theoretical review

1.1 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.



4

Products management being the target element in the bakery will therefore require us to have all

the important information about them such as product ID, name, price, stock, expiry date, etc. which

will be of great help in database management. As for customers, all we might be interested in is an

associated ID to each customer given that we might want to establish some relations between that

customer and the products.

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.



5

2. Identification of the actors

2.1 List of actors and their roles

Below are the actors of our system:

The receptionist:

She/he is a primary user in the system at the bakery. The receptionist will have to perform multiple roles

such as selling items by registering a list of the items and providing a receipt to current customers.

Because the receptionist sells products, she/he will therefore be requested an authentication before

proceeding.

The inventory Clerk:

She/he is also a main actors who requires system support as she/he will need to provide a daily account

of the products in stock with respect to what has already been sold by the receptionist. The inventory

clerk will therefore be requested an authentication as well.

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) who’s ID might be needed.

The bakery manager :

The owner is the one at the head of the administration of the bakery management software. She/he is

therefore a main actor as she/he inherits from all the others thus, is able to request for a query from the

receptionist and inventory clerk at any time.



6

2.2 Relationship between actors

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. Functional requirements

3.1 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



7

the current list or remove it depending whether she wants to sell or retrieve information. Remember

before any action, the receptionist must provide an authentication at the welcome menu.

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.



8

3.1.3 The Customer:

Buy products or perform a command: This is the only action that will be carried out by the customer

which required no system support. All the customer does is to place his/her products on counter wait

for identification from the receptionist and deliver the required amount of money for the products.

3.1.4 The owner (manager):

Adding to all the tasks the receptionist and inventory clerk can perform, the owner will be able to:

I. 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 employee’s ID in the required text

field from the GUI offered by the software. From there, all the employee’s 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.



9

3.2 Identification and expression of relationships between use cases

3.2.1 Use cases

Create products

Search product

Update product

Delete product

Search item

Item Counter

Add item

Remove item

Sell item

Print receipt

Save Order

Inventory list

Authentication

3.2.1 Relationship Between use cases

Use case 1: Products Management (primary use case)

- 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.



10

- 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)

Use Case 2: Item on counter

- 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



11

three clicks will be made to add an item the price and quantity to the current list if barcode does not exist,

or just two clicks will be sufficient if the barcode exists.

Use Case 4: sell items (extends search item)

- 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.

Use Case 5: Inventory list (generalization of products)

- 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.

Use Case 6: Authentication

This use case enables data security and prevents theft as it consists of a username and password of both

the receptionist and inventory clerk before any other operation is made. This is why this use case is

included in the search item use case of the receptionist and the inventory list use case of the inventory

clerk as they must first login before carrying out any activity.

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



12

addition to being able to request for reports and queries from both the receptionist and inventory clerk. The

only secondary actor here is the customer since the only thing he/she does is to set his items on counter,

which in theory has nothing to do with the computerized system.

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 doesn’t.

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 user’s 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



13

5. Use case diagram

Figure 1: Relationship between Use cases and Actors in the bakery management



14

6. Sequence System Diagram

To further show how the actors actually interact with the system, we will draw the sequence diagram

of two primary actors and their and the system separately.

6.1 Use case: Create Product

If false authentication, error message printed and a 2nd chance given

Display welcome page with login options

Click on create a new product

Display new product data form

Fill the form and enter

Approval message displayed

If valid, the inventory clerk’s menu is displayed

Enter authentication into the corresponding login



15

6.2 Use case: sell Product

Display welcome page with login options

Enter authentication into the corresponding login

If false authentication, error message printed and a 2nd chance given

If valid, the receptionist’s menu is displayed

Click on perform orders

Display product sales menu with related functionalities

Edit the required orders form and enter

Approval message displayed and receipt printed

Receptionist



16

II. Design documentation

This part of the documentation deals with the design phase of the bakery management software. Here,

business classes are identified and the various relationships at different level shown. This is followed by the

class diagram of our bakery management software.

1. Identification of the business classes and relationship between business concepts The classes with which the user will deal with directly or indirectly through the intermediate concepts

are described as shown below:

Product: This class encapsulates the concept of a product or item in a bakery

Product management: business class to manage products. There is a dependency relationship

between the class product management and the class product i.e. the class product management depends on

the class product.

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.



17



18

III. System installation documentation

1. Minimum computer requirements

A 1.7Ghtz possessor

A Radeon or Intel graphic card

Intel Pentium/AMD Core Duo processor

Java 8 U45 installed

Latest version of MySQL database running on the host computer with all the drivers.

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.

IV. User Documentation

Now you are ready to make use good use of the bakery management software. This last section will guide

you in the process of utilization of the various functions of the software.

Getting started with the system Because one of our primary objective is to make the software as friendly as possible with the user,

we have therefore built a consistent GUI able at every time to meet the needs of each and every employer

in the enterprise with the required credentials to use the software. Thus, each user will simply need to

enter his authentication from where he will be directed to his/her corresponding menu. Depending on the

employee’s job, he/she is limited to only his section of the software to interact with.



19

After login in, the inventory clerk can simply clicks on the tab called inventory list where she/he has

the option view all current products, add a product, remove a product and modify the quantity with respect

to the sales inventory and the supplies. In fact he or she will ensure the integrity of all activities carried

out on the products. In order to perform these tasks, the clerk should simply click on any of the buttons

provided in his menu and an interface will open for him to easily do whatever he wants.

The receptionist also follows the same procedure as above. She just needs to click on the create order

button on the upper section of the window menu bar in which is provided with the corresponding options

for performing a consistent order as fast as possible. There is also an option to view the printable receipt

before processing the printing (preview). All she has to do is to click on those options and performs the

task she needs.

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.

Documents

Requirements Analysis for bakery software