Catalog

Chapter One: Introduction.........................................................................................6

1.1 Introduction..............................................................................................................6
1.2 Background information of the Organization..........................................................6
1.2.1 Vision of ASTU..............................................................................................7
1.2.2 Mission of ASTU............................................................................................7
1.3 Background of the project........................................................................................7
1.4 Statement of the problem.........................................................................................7
1.5 Team composition....................................................................................................8
1.6 Objective of the project (SMART)...........................................................................8
1.6.1 General Objective............................................................................................8
1.6.2 Specific objective............................................................................................8
1.7 Feasibility Analysis..................................................................................................8
1.7.1 Operational feasibility.....................................................................................9
1.7.2 Technical feasibility........................................................................................9
1.7.4 Behavioral/Political feasibility........................................................................9
1.7.5 Schedule feasibility.........................................................................................9
1.8 Scope of the project................................................................................................10
1.9 Significance of the project......................................................................................11
1.10 Target beneficiaries of the system........................................................................11
1.11 Methodology for the project.................................................................................11
1.11.1 Data Source.................................................................................................12
1.11.2 Fact Finding Techniques.............................................................................12
1.12 Systems Analysis and Design (approach)............................................................12
1.13 Development Tools..............................................................................................12
1.14 Testing procedures...............................................................................................13
1.15 Implementation.....................................................................................................13
1.16 Limitation of the project.......................................................................................13
1.17 Risks & contingencies..........................................................................................14
1.18 Assumptions and Constraints...............................................................................14
Chapter Two: Description of the Existing System..................................................15
2.1. Introduction of Existing System............................................................................15
2.2. Players in the existing system...............................................................................15
2.3. Major functions/activities in the existing system like inputs, processes & outputs
......................................................................................................................................16
2.4. Business rules........................................................................................................17
2.5 Report generated in the existing system.................................................................17
2.6 Forms and other documents of the existing systems..............................................18
2.7 Bottlenecks of the existing system (using the PIECES framework)......................18
2.8 Practices to be preserved........................................................................................19
2.9 Proposed solution for the new system that address problems of the existing system
......................................................................................................................................19
2.10 Requirements of the Proposed System.................................................................20
2.10.1 Functional requirements................................................................................20
2.10.2 Nonfunctional requirements..........................................................................21
Performance............................................................................................................21
Chapter Three: System Analysis (Modeling of the Proposed System)..................22
3.1 Introduction............................................................................................................22
3.2 System Requirement Specifications (SRS)............................................................22
3.2.1 Use Case Diagrams.......................................................................................22
 3.2.2 Use Case Documentation..............................................................................23
3.2.3 Sequence Diagram.........................................................................................25
3.2.4 Activity Diagram...........................................................................................26
3.2.5 Analysis Level Class Diagram (Conceptual Modeling)................................27
3.2.6 User Interface Prototyping............................................................................29
3.2.7 Supplementary Specifications.......................................................................30
Chapter Four: System Design...................................................................................31
4.1 Introduction............................................................................................................31
4.2 Class Type Architecture.........................................................................................31
4.3 Class Modeling (Design Level Class Diagram).....................................................32
4.4 State Chart Modeling..............................................................................................35
4.5 Collaboration Modeling (Communication Diagram).............................................36
4.6 Component Modeling.............................................................................................36
4.7 Deployment Modeling............................................................................................37
4.8 Persistence Modeling (Database Schema).............................................................38
4.9 User Interface Design.............................................................................................38
Chapter Five: Implementation and Testing.............................................................39
5.1 Introduction............................................................................................................39
5.2 Final Testing of the System....................................................................................39
1. System Integration Testing:..................................................................................40
2. User Acceptance Testing (UAT):.........................................................................40
3. Performance and Stress Testing:..........................................................................41
4. Security Testing:...................................................................................................41
5.3 Hardware and Software Acquisitions.....................................................................41
5.4 User Manual Preparation........................................................................................42
5.5 Training..................................................................................................................43
5.6 Installation Process.................................................................................................43
5.7 Start-up Strategy.....................................................................................................44
Chapter Six: Conclusions and Recommendation....................................................45
6.1 Conclusions............................................................................................................45
6.2 Recommendations..................................................................................................46
Appendix......................................................................................................................47
References....................................................................................................................47
I. Title Page
PROJECT DOCUMENTATION
INVENTORY MANAGEMENT SYSTEM
Submitted in Partial Fulfillment of the Requirements for the Degree of Bachelor of
Science in Computer Science
By:
[Your Name]
[ID Number]
To:
Department of Computer Science
College of Computing and Informatics
Bule Hora University
Bule Hora, Ethiopia
Date of Submission: [dd/mm/yy]
Supervisor: [Supervisor's Name]

III. Dedication (Optional)

(A personal, one-page message.)
To my family, for their unwavering support and sacrifices throughout my academic
journey. Your belief in me has been my greatest strength.
And to my friends and colleagues, for the shared knowledge and camaraderie.

IV. Acknowledgement
I would like to express my profound gratitude to my project supervisor, [Supervisor's
Name], for his/her invaluable guidance, insightful feedback, and constant
encouragement throughout the development of this project. His/her expertise and
patience were instrumental in shaping this work.
My sincere thanks also go to the Department of Computer Science at Bule Hora
University for providing the necessary resources and a conducive environment for
learning and research.
I am also indebted to the staff of [Hypothetical Local Business, e.g., "Bule Hora
General Store"] for their cooperation during the requirement gathering phase,
providing crucial insights into the challenges of manual inventory management.
Finally, I extend my appreciation to my classmates and friends for their constructive
discussions and moral support.

V. Table of Contents
(This will be auto-generated by your word processor. Ensure all headings and page
numbers are accurate.)

VI. List of Figures

Figure 1.1: Team Composition Structure
Figure 2.1: Existing Manual System Process Flow
Figure 3.1: Use Case Diagram for the Inventory Management System
Figure 3.2: Sequence Diagram for the "Add New Item" Use Case
Figure 3.3: Activity Diagram for the Stock Reordering Process
Figure 3.4: Analysis Level Class Diagram
Figure 3.5: User Interface Prototype - Login Screen
Figure 3.6: User Interface Prototype - Dashboard
Figure 4.1: Design Level Class Diagram
Figure 4.2: State Chart Diagram for an Inventory Item
Figure 4.3: Deployment Diagram
Figure 4.4: Final User Interface - Main Dashboard

VII. List of Tables

Table 1.1: Project Team Composition
Table 1.2: Cost-Benefit Analysis
Table 1.3: One-Time Cost Breakdown
Table 1.4: Recurrent Cost Breakdown
Table 2.1: PIECES Framework Analysis of the Existing System
Table 3.1: Use Case Documentation - "Login"
Table 3.2: Use Case Documentation - "Add New Inventory Item"

VIII. Abbreviations

BHU:
IMS: Inventory Management System
SRS: System Requirement Specification
UI: User Interface
UX: User Experience
DBMS: Database Management System
SQL: Structured Query Language
PHP: Hypertext Preprocessor (a scripting language)
HTML: HyperText Markup Language
CSS: Cascading Style Sheets
SMART: Specific, Measurable, Achievable, Relevant, Time-bound
PIECES: Performance, Information, Economics, Control, Efficiency, Service

X. Abstract
The inefficiencies inherent in manual inventory management systems, such as data
inconsistency, difficulty in tracking stock levels, and susceptibility to human error,
pose significant challenges for small and medium-sized enterprises. This project aims
to design, develop, and implement a web-based Inventory Management System
(IMS) to automate and streamline these processes. The system was developed using
an iterative methodology, incorporating tools like XAMPP (for the server
environment), PHP, and MySQL. The analysis and design phases utilized UML
diagrams, including Use Case, Sequence, and Activity diagrams, to model both the
existing and proposed systems. The implemented system provides core
functionalities including user authentication, product categorization, real-time stock
level monitoring, sales recording, automatic low-stock alerts, and report generation.
The system underwent rigorous unit, integration, and user acceptance testing to
ensure reliability and usability. The result is a robust, user-friendly application that
demonstrates a significant improvement in inventory accuracy, operational
efficiency, and decision-making support compared to the manual method. This
project serves as a practical demonstration of software engineering principles
applied to solve a real-world business problem.
Keywords: Inventory Management, System Analysis and Design, PHP, MySQL, UML,
Automation, Web Application.

Chapter One: Introduction

1.1 Introduction
This chapter provides a comprehensive overview of the Inventory Management
System (IMS) project. It outlines the project's context, the problems it aims to solve,
its objectives, scope, and the methodology employed for its development. The
chapter establishes the foundation for understanding the necessity and feasibility of
the proposed system.

1.2 Background information of the

Organization
Bule Hora Univercity
is a leading institution of higher learning in Ethiopia, committed to excellence in
teaching, research, and community service. The project aligns with the university's
mission by applying theoretical knowledge to practical, problem-solving scenarios.

1.2.1 Vision of BHU

To be a preeminent center of excellence in science and technology in Africa.

1.2.2 Mission of BHU

To produce competent graduates in science and technology through effective
teaching, learning, and research; and to promote technology transfer and
community services.

1.3 Background of the project

Many small and medium-sized businesses and university stores in Ethiopia rely on
manual, paper-based systems for inventory tracking. This involves logbooks,
spreadsheets, and physical stock counts, which are time-consuming, prone to errors,
and inefficient for generating timely reports. This project was conceived to address
these challenges by developing a centralized, automated software solution.

1.4 Statement of the problem

The existing manual inventory system is characterized by:

Inaccuracy and Data Redundancy: Manual data entry leads to errors and duplicate
records.

Inefficiency in Tracking: Difficulty in locating items and determining real-time stock

levels.

Lack of Real-time Information: Decisions regarding procurement and sales are based
on outdated information.

Ineffective Reporting: Generating sales, stock-out, and reorder reports is a slow and
labor-intensive process.

Poor Security: Physical record books are vulnerable to loss, damage, and
unauthorized access.

1.5 Team composition

This is a solo student project.
Table 1.1: Project Team Composition
ID
Name Role Responsibilities
Number

Project Manager, Overall project planning, system

[Your
[Your ID] Developer, analysis, design, coding, testing, and
Name]
Analyst documentation.

1.6 Objective of the project (SMART)

1.6.1 General Objective
To design and develop a web-based Inventory Management System that automates
stock tracking, sales recording, and reporting to improve operational efficiency and
decision-making.
1.6.2 Specific objective

To analyze the current manual inventory process and identify its limitations within
four weeks.

To design a secure, multi-user system with a relational database schema by the end
of the 8th week.

To develop functional modules for user login, product management (add, edit,
delete), stock-in/out tracking, and low-stock alerts by the 12th week.

To implement a reporting module that generates PDF reports for inventory status
and sales history by the 14th week.

To test, deploy, and document the fully functional system by the 16th week.

1.7 Feasibility Analysis

1.7.1 Operational feasibility
The system is highly operationally feasible. It is designed with a simple, intuitive user
interface that requires minimal computer literacy. It will reduce the workload of
staff, freeing them from tedious manual tasks. The proposed system aligns perfectly
with the organizational goal of improving efficiency.

1.7.2 Technical feasibility

The project utilizes well-established and widely supported technologies: PHP for
server-side scripting, MySQL for the database, and HTML/CSS/JavaScript for the
front-end. These technologies are open-source, have a vast developer community,
and can run on low-cost hardware (a standard PC with XAMPP/WAMP stack). The
required technical expertise falls within the scope of a final-year computer science
student, making it technically feasible.

1.7.3 Economic feasibility

The development cost is minimal as it uses free, open-source software. The primary
costs are related to the developer's time and the eventual deployment hardware.
1.7.4 Behavioral/Political feasibility
The system is likely to be welcomed by users as it simplifies their jobs. Management
will benefit from better data for decision-making. Resistance to change is expected
to be minimal, especially with proper training and demonstration of the system's
benefits.

1.7.5 Schedule feasibility

The project timeline of one academic semester (approximately 16 weeks) is
sufficient for the analysis, design, development, testing, and documentation of this
system, given its well-defined scope.
Cost Benefit Analysis
Table 1.2: Cost-Benefit Analysis
Cost Benefit

Development time (160 hours) Reduced time spent on stock-taking and reporting (estimated 50%

Basic hosting/PC for Elimination of errors leading to reduced financial loss from stock
deployment discrepancies.

Improved customer satisfaction due to better product availability.

Informed decision-making through real-time data and reports.

Cost of the project
Cost break down
Recurrent Cost
Table 1.3: Recurrent Cost Breakdown
Item Estimated Cost (ETB)

Electricity & Internet 500 / month

Total 500 / month

One time Cost
Table 1.4: One-Time Cost Breakdown
Item Estimated Cost (ETB)

Development PC (if new) 25,000

Domain Name & Basic Hosting (1 yr) 2,000

Total 27,000
1.8 Scope of the project
In-Scope:
User Registration and Authentication.
Management of Product Categories and Items.
Recording of Stock-In (Procurement) and Stock-Out (Sales) transactions.
Real-time tracking of inventory quantities.
Automatic low-stock alerts.
Generation of basic reports (Inventory List, Sales Report).
Basic user role management (Admin, Staff).

Out-of-Scope:
Integration with barcode scanners or RFID systems.
Advanced financial accounting (e.g., ledger, profit/loss statements).
Multi-currency or multi-language support.
Mobile application development.
Integration with supplier or point-of-sale (POS) systems.

1.9 Significance of the project

This project demonstrates the practical application of software engineering
principles. It provides a tangible solution to a common business problem, showcasing
how technology can be leveraged to create efficiency, accuracy, and better resource
management.

1.10 Target beneficiaries of the system

Small and Medium-sized Enterprise (SME) owners and managers.

Storekeepers and inventory clerks.
University departmental stores and co-operatives.
The project developer (as a learning experience and portfolio piece).

1.11 Methodology for the project

An Iterative and Incremental Development methodology was adopted. This allowed
for the development of the system in cycles, where each cycle (analysis, design,
implementation, testing) added a new set of functionalities. This approach was
chosen for its flexibility and ability to incorporate feedback early in the process.

1.11.1 Data Source

Primary Data: Gathered through interviews and observation at a local store.

Secondary Data: Academic papers, online articles on inventory management, and
existing system documentation templates.

1.11.2 Fact Finding Techniques

Interview: Conducted with the store manager to understand the pain points of the
manual system.
Practical Observation: Spent time observing the current process of stock entry, sales
recording, and report generation.
Document Analysis: Reviewed existing record books, sales receipts, and stock lists to
understand the data flow and structure.

1.12 Systems Analysis and Design

(approach)
The Structured Systems Analysis and Design Method (SSADM) principles were
followed, utilizing Data Flow Diagrams (DFDs) in the initial stages and Unified
Modeling Language (UML) for object-oriented modeling in the later stages.

1.13 Development Tools

Front-end: HTML5, CSS3, JavaScript, Bootstrap
Back-end: PHP
Database: MySQL
Server Environment: XAMPP (Apache, PHP, MySQL)
Design & Modeling: [Link] / Lucidchart for UML diagrams
Code Editor: Visual Studio Code

1.14 Testing procedures

Unit Testing: Individual modules (e.g., login, add item) were tested in isolation.
Integration Testing: Modules were combined and tested together (e.g., adding a sale
updates the stock level).
System Testing: The complete, integrated system was tested against the SRS.
User Acceptance Testing (UAT): A mock session was conducted with a potential user
to validate functionality and usability.

1.15 Implementation
A Phased (Parallel) implementation strategy is recommended. The new system will
run alongside the old system for a short period. This allows for result comparison
and ensures a fallback option in case of critical failures, minimizing risk.
1.16 Limitation of the project

The system does not support real-time multi-user concurrent editing conflicts
robustly.
The initial data migration from the manual system to the digital system must be
done manually.
The system's performance with a very large dataset (e.g., >100,000 products) has not
been stress-tested.

1.17 Risks & contingencies

Risk: Loss of data due to system crash.

Contingency: Implement a daily automated database backup routine.
Risk: User resistance to adopting the new technology.
Contingency: Provide comprehensive training and user-friendly documentation.
Risk: Scope creep during development.
Contingency: Adhere strictly to the defined project scope and manage change
requests formally.

1.18 Assumptions and Constraints

Assumptions: Users have basic computer literacy; the organization has a reliable
power source and internet connection for deployment.
Constraints: Project must be completed within one academic semester;
development is limited to the technologies taught in the curriculum.
(This completes Chapter One. Due to the extensive length, this response will cover
the first chapter in detail. To continue with the subsequent chapters (Two through
Six) with the same level of detail, please submit a new request.)
Final Note: This documentation is a template. You must replace the bracketed
information [ ], hypothetical examples, and generic descriptions with the specific
details, analysis, and diagrams from your own project work. The quality of your final
document depends on the depth and accuracy of your specific research and
development efforts.
Chapter Two: Description of the Existing

System

2.1. Introduction of Existing System

The existing inventory management process at the case study site (e.g., a local
university store or a small retail shop) is entirely manual and paper-based. The
system relies on physical logbooks, spreadsheets like Microsoft Excel, and human
memory to track stock levels, record sales, and manage reordering. There is no
centralized database, and data is fragmented across multiple record books, leading
to significant operational inefficiencies and a high potential for error. This chapter
provides a detailed analysis of this current system, its players, processes, and the
critical bottlenecks that justify the development of a new, automated solution.

2.2. Players in the existing system

Store Manager: Responsible for overall inventory control, approving purchase
orders, reviewing monthly stock reports, and making strategic decisions.
Storekeeper / Clerk: The primary operator of the system. Duties include:
Recording incoming stock in a "Goods Received" ledger.
Updating stock levels in an Excel spreadsheet or a stock ledger after each sale.
Manually calculating remaining quantities.
Informing the manager when stock is low.
Handling customer sales and issuing handwritten receipts.
Supplier: Provides goods and an accompanying delivery note/invoice.
Customer: Purchases items and receives a manual sales receipt.

2.3. Major functions/activities in the

existing system like inputs, processes &
outputs
Figure 2.1: Existing Manual System Process Flow
(Imagine a simple flowchart here)
[Supplier] -> [Delivery Note] -> [Storekeeper] -> [Update Goods Received Ledger] ->
[Update Stock Ledger/Excel] -> [Customer Purchase] -> [Calculate Sale, Issue Receipt]
-> [Update Stock Ledger/Excel] -> [End of Day/Month] -> [Manager Manually Checks
Ledgers] -> [Generate Reports]
Inputs:
Supplier delivery notes and invoices.
Sales data from daily transactions.
New product information (name, price).

Processes:
Manual data entry into ledgers and spreadsheets.
Manual calculation of stock levels (Current Stock = Previous Stock + Stock In - Stock
Out).
Physical searching for items in the storage area.
Manual verification of stock levels against physical counts.

Outputs:
Handwritten sales receipts for customers.
Filled "Goods Received" and "Stock Ledger" books.
Manually compiled Excel spreadsheet for stock status.
End-of-month summary reports created manually by the manager.

2.4. Business rules

A new stock entry cannot be made without a corresponding supplier delivery note.
The selling price of an item must be higher than its cost price.
A sale transaction cannot be processed if the item quantity is zero.
Only the store manager is authorized to approve the ordering of new stock.
Physical stock counting must be done at the end of every month to verify records.

2.5 Report generated in the existing

system
Monthly Stock Status Report: A manually compiled list from the stock ledger or
Excel, showing the opening balance, goods received, goods sold, and closing balance
for each item.
Low-Stock Alert: An informal verbal or written note from the storekeeper to the
manager, based on the storekeeper's periodic checks of the ledger.
Sales Report: A summary of total sales over a period (daily, weekly, monthly),
created by manually aggregating data from sales receipt books.

2.6 Forms and other documents of the

existing systems

Goods Received Ledger: A bound book with columns for Date, Supplier Name, Item
Name, Quantity Received, and Cost Price.
Stock Ledger: A separate bound book for each item or a consolidated one with
columns for Date, Transaction Type (In/Out), Quantity, and Balance.
Sales Receipt Book: A pre-printed, carbon-copy book for issuing receipts to
customers.
Supplier Delivery Note: A physical document provided by the supplier upon delivery.

2.7 Bottlenecks of the existing system

(using the PIECES framework)
Table 2.1: PIECES Framework Analysis of the Existing System
PIECES Category Problem Identified

The response time for checking stock levels is slow, requiring a manual searc
2.7.1 Performance
ledgers or spreadsheets. Generating a simple report can take hours or even d

Input: Data entry is highly prone to human error (e.g., transposing numbers)
2.7.2 Information often redundant, entered in multiple ledgers.
(Input & Output) Output: Reports are often inaccurate due to source data errors, leading to po
decision-making. Information is not timely.

Physical ledgers can be easily lost, damaged (e.g., by water, fire), or accessed
2.7.3 Security and
unauthorized personnel. There is no audit trail to track who made changes to
Controls
records.

The system is highly inefficient. Significant staff time is wasted on manual da

2.7.4 Efficiency
calculations, and report generation. Time spent on physical stock counts is ex

Customer service is slow at the point of sale as the clerk must check a ledger
2.7.5 Service availability and price. The risk of selling out-of-stock items is high due to outd
information.

2.8 Practices to be preserved

The monthly physical stock count is a good practice for validation and should be
integrated into the new system as a reconciliation feature.
The requirement for managerial approval for purchase orders is a crucial control
mechanism.
The clear categorization of items used in the ledgers should be maintained in the
new database.

2.9 Proposed solution for the new

system that address problems of the
existing system
The proposed solution is a centralized, web-based Inventory Management System
(IMS). This system will:
Eliminate Redundancy & Errors: Provide a single source of truth for all inventory
data, with automated data entry and calculations.
Improve Efficiency & Performance: Enable real-time stock level checks and
automated report generation at the click of a button.
Enhance Security: Implement user authentication (login) and role-based access
controls. The digital database will be regularly backed up.
Improve Service: Provide a quick search functionality and accurate, real-time stock
information, speeding up the sales process.
Provide Proactive Alerts: Automatically generate low-stock alerts, eliminating
dependence on manual checks.

2.10 Requirements of the Proposed

System
2.10.1 Functional requirements

The system shall allow users to log in with a username and password.
The system shall allow authorized users to add, view, edit, and deactivate product
categories and items.
The system shall record all stock-in (purchases) and stock-out (sales) transactions.
The system shall automatically update the quantity in stock after every transaction.

Performance requirements
The system should update stock levels in real-time (within 2 seconds of a
transaction).
The system should load any list view (e.g., product list) in under 3 seconds.

Process requirements
The process for recording a sale shall automatically check product availability before
completion.
The process for adding a new item shall require the user to assign it to a pre-existing
category.

Input related requirements

All input fields for quantities and prices shall be numerically validated.
Required fields (e.g., product name, category) shall be enforced by the system.
Output related requirements
The system shall generate a PDF report of the current inventory status.
The system shall display an on-screen alert listing all items whose stock has fallen
below a pre-defined threshold.

Storage related requirements

The system shall store transaction history for at least three fiscal years.
The system shall archive deleted items rather than permanently deleting them.

2.10.2 Nonfunctional requirements

Performance
The system should support at least 5 concurrent users without significant
performance degradation.
The system's dashboard should load completely within 4 seconds over a standard
university Wi-Fi connection.

User Interface
The user interface shall be intuitive and require minimal training for users familiar
with web browsing.
The interface shall be responsive and usable on standard desktop and laptop
screens.
Security and Access permissions
The system shall implement role-based access control (e.g., Admin, Storekeeper).
Admin: Can manage users, view reports, adjust system settings.
Storekeeper: Can manage products and record transactions.
All passwords shall be encrypted in the database.
Backup and Recovery
The system shall facilitate a manual database backup operation from the admin
panel.
A full database backup shall be performed automatically every 24 hours.
Resources
The system shall run on a standard web server with PHP 7.4+ and MySQL 5.7+.
The client-side shall only require a modern web browser (e.g., Chrome 90+, Firefox
88+).

Chapter Three: System Analysis (Modeling of

the Proposed System)

3.1 Introduction
This chapter details the analysis and modeling of the proposed Inventory
Management System (IMS). Using the Unified Modeling Language (UML), we
transform the requirements identified in Chapter Two into visual and textual models.
These models provide a precise blueprint of the system's functionality, structure,
and behavior, serving as a crucial communication tool between the analyst,
developer, and stakeholders before the design and implementation phases begin.
The primary focus is on what the system must do, not how it will be implemented.

3.2 System Requirement Specifications

(SRS)
This section formally defines the functional and behavioral models of the proposed
system.

3.2.1 Use Case Diagrams

The Use Case Diagram illustrates the interactions between the system's actors
(users) and its core functionalities (use cases).
Figure 3.1: Use Case Diagram for the Inventory Management System
(A visual diagram would be here. Description below)
Actors:
Admin: Has full access to all system functions.
Storekeeper: Manages daily inventory operations.
System: An internal actor that performs automated tasks.
Use Cases:
Authenticate User: Covers login and logout (shared by Admin & Storekeeper).
Manage User Account (Admin): For user registration and management.
Manage Product Category (Admin): Create, read, update, deactivate categories.
Manage Inventory Item (Storekeeper): Add, view, edit, deactivate products.
Record Stock-In (Storekeeper): Log new shipments and procurement.
Record Sale (Storekeeper): Process a customer sale/stock-out.
View Inventory Reports (Admin, Storekeeper): Generate and view stock level, sales
reports.
View Low-Stock Alert (Admin, Storekeeper): View list of items below threshold.
Generate Report (System): Automated process triggered by a user request.

3.2.2 Use Case Documentation

Table 3.1: Use Case Documentation - "Login"
Field Description

Use Case Name Authenticate User

Actor(s) Admin, Storekeeper

Field Description

Description This use case allows a user to log into the system by providing valid creden

Preconditions The user must be registered in the system.

Postconditions The user is granted access to the system based on their role.

1. User navigates to the login page.

2. System displays login form.
3. User enters username and password.
Main Success Scenario
4. User clicks "Login".
5. System validates credentials.
6. System redirects user to the appropriate dashboard.

5a. Invalid credentials:

Extensions 5a1. System displays an error message.
5a2. Use case restarts at step 2.
Table 3.2: Use Case Documentation - "Add New Inventory Item"
Field Description

Use Case Name Manage Inventory Item (Add)

Actor(s) Storekeeper

Description This use case allows a Storekeeper to add a new product to the inventory.

Preconditions The Storekeeper is logged in. At least one product category must exist.

Postconditions A new inventory item is created and available in the system.

1. Storekeeper selects "Add New Item" from the inventory menu.

2. System displays a blank item form.
3. Storekeeper enters item details (name, description, category, cost price, selli
Main Success initial quantity, reorder threshold).
Scenario 4. Storekeeper clicks "Save Item".
5. System validates the data.
6. System saves the new item to the database.
7. System confirms successful save and displays the new item in the list.

5a. Validation fails (e.g., missing name, negative price):

Extensions 5a1. System highlights the erroneous fields with messages.
5a2. Use case resumes at step 3.
3.2.3 Sequence Diagram
Sequence diagrams show the flow of interactions between objects over time,
focusing on the order of messages.
Figure 3.2: Sequence Diagram for the "Record Sale" Use Case
(A visual diagram would be here. Description below)
Objects: :Storekeeper, :SalesUI (Interface), :SalesController (Process
Logic), :InventoryItem (Domain Object), :SalesTransaction (Domain
Object), :Database
Message Flow:

:Storekeeper -> :SalesUI : submitSale(itemID, quantitySold)

:SalesUI -> :SalesController : processSale(itemID, quantitySold)
:SalesController -> :InventoryItem : getCurrentStock()
:InventoryItem -> :Database : SELECT stock_quantity FROM items...
:Database --> :InventoryItem : stockQuantity
:InventoryItem --> :SalesController : stockQuantity
[alt] If stockQuantity >= quantitySold
:SalesController -> :SalesTransaction : create(new Sale)
:SalesTransaction -> :Database : INSERT INTO sales...
:SalesController -> :InventoryItem : updateStock(-quantitySold)
:InventoryItem -> :Database : UPDATE items SET stock_quantity...
:SalesController --> :SalesUI : saleSuccessConfirmation
:SalesUI --> :Storekeeper : Display "Sale Recorded Successfully"

3.2.4 Activity Diagram

Activity diagrams model the workflow or business process from a high level.
Figure 3.3: Activity Diagram for the Stock Reordering Process
(A visual diagram would be here. Description below)
Swimlanes: Storekeeper, System
Flow:

Start Node
(Storekeeper) View Low-Stock Report [Triggered manually or by system alert]
(System) Check Stock Level for All Items [Automated daily task]
[Is Stock Level < Threshold?] - Decision Node
[Yes] (System) Add Item to Low-Stock Alert List
[No] (System) Do Nothing
(Storekeeper) Review Low-Stock List
(Storekeeper) Initiate Purchase Order
(Storekeeper) Wait for Stock Delivery
(Storekeeper) Record Stock-In Transaction
(System) Update Item Quantity
End Node
3.2.5 Analysis Level Class Diagram
(Conceptual Modeling)
This diagram identifies the key domain concepts, their attributes, and the
relationships between them, without specifying implementation details.
Figure 3.4: Analysis Level Class Diagram
(A visual diagram would be here. Description below)
Classes and Key Attributes:

User
userID: int
username: String
password: String
role: String (Admin, Storekeeper)
email: String
Category

categoryID: int
categoryName: String
description: String
InventoryItem
itemID: int
itemName: String
description: String
costPrice: double
sellingPrice: double
quantityInStock: int
reorderThreshold: int
StockTransaction (Abstract)
transactionID: int
dateTime: DateTime
quantity: int
performedBy: String
StockIn (inherits from StockTransaction)
supplierInfo: String
Sale (inherits from StockTransaction)
customerInfo: String
totalAmount: double

Relationships:
User is associated with StockTransaction (a user performs a transaction).
Category is composed of many InventoryItem (1..* - Category has 1..n Items).
InventoryItem is associated with StockTransaction (a transaction affects an item).
3.2.6 User Interface Prototyping
Wireframes and mockups of key screens to visualize the user interaction.
Figure 3.5: UI Prototype - Login Screen
(A simple wireframe image would be here)
Elements: System Title "Inventory Management System", Username field, Password
field, "Login" button.
Figure 3.6: UI Prototype - Main Dashboard
(A simple wireframe image would be here)
Elements: Navigation Menu (Dashboard, Products, Sales, Stock-In, Reports, Users),
Welcome message, Summary Cards (Total Products, Low Stock Items, Today's Sales),
Quick Links, Low-Stock Alert List.
Figure 3.7: UI Prototype - Add/Edit Product Form
(A simple wireframe image would be here)
Elements: Form with fields: "Product Name" (text), "Category" (dropdown),
"Description" (textarea), "Cost Price" (number), "Selling Price" (number), "Initial
Quantity" (number), "Reorder Threshold" (number). Buttons: "Save", "Cancel".

3.2.7 Supplementary Specifications

This section covers non-functional requirements and rules not captured in the use
cases.
A. Business Rules

BR1: sellingPrice of an InventoryItem must be greater than its costPrice.

BR2: The quantityInStock of an InventoryItem cannot fall below zero after a sale.
BR3: A Sale transaction can only be performed by an authenticated user with the
'Storekeeper' or 'Admin' role.

B. Data Validation Rules

All numeric fields (costPrice, sellingPrice, quantity) must be positive numbers.

username and email must be unique across all User entities.
The reorderThreshold must be a non-negative integer.

C. Constraints

The system shall be developed in PHP using the MVC architectural pattern.
The database shall be MySQL.
Chapter Four: System Design

4.1 Introduction
This chapter translates the analytical models from Chapter Three into a detailed,
technical blueprint for construction. The focus shifts from what the system does
to how it will be implemented. We define the system's architecture, detailed class
structures, dynamic behaviors, component organization, deployment environment,
data storage strategy, and final user interface design. This chapter serves as the
primary guide for developers during the implementation phase.

4.2 Class Type Architecture

The system will adhere to a multi-layered (N-Tier) architecture, specifically tailored
for a web application using the Model-View-Controller (MVC) pattern. This
separation of concerns promotes maintainability, scalability, and testability.

User Interface Layer (View): This layer comprises the HTML, CSS, JavaScript, and PHP
view files. It is responsible for presenting data to the user and capturing their input.
It communicates with the Controller layer to request actions and receive data for
display.
Components: login_view.php, dashboard_view.php, product_form_view.php

Controller/Process Layer (Controller): This layer acts as an intermediary between the

View and the Business layer. It processes user requests, invokes business logic, and
determines the appropriate view to render in response.
Components: [Link], [Link], [Link], Report
[Link]
Business/Domain Layer (Model): This layer contains the core business logic and
entities of the application. It encapsulates the data and the rules that govern access
to and manipulation of that data. It is independent of the UI and persistence
mechanisms.
Components: [Link], [Link], [Link], [Link], [Link], Re
[Link]
Persistence Layer (Data Access): This layer is responsible for all communication with
the database. It handles CRUD (Create, Read, Update, Delete) operations. The
Domain objects are unaware of how they are stored and retrieved.
Components: [Link], [Link], [Link], SaleDAO.p
hp (DAO = Data Access Object)

System Layer: This layer provides supporting services used by all other layers.
Components: [Link] (for logging errors and activities), [Link] (for
session management and authentication checks), [Link] (for managing database
credentials and settings).

4.3 Class Modeling (Design Level Class

Diagram)
This is a refinement of the analysis class diagram (Fig 3.4), now including
implementation details such as method signatures, data types, and visibility.
Figure 4.1: Design Level Class Diagram
(A detailed visual diagram would be here)
Key Classes and Methods:

User
- userId: int
- username: string
- passwordHash: string
- role: string
+ login($username, $password): bool
+ logout(): void
+ hasRole($role): bool

InventoryItem
- itemId: int
- itemName: string
- description: string
- costPrice: float
- sellingPrice: float
- quantityInStock: int
- reorderThreshold: int
- category: Category
+ updateStock($quantity): void
+ isLowStock(): bool
+ calculateProfitMargin(): float

Sale
- saleId: int
- saleDateTime: DateTime
- totalAmount: float
- items: SaleLineItem[] (Composition)
+ addItem($inventoryItem, $quantity): void
+ calculateTotal(): void
+ finalizeSale(): bool
SaleLineItem (New class to handle multiple items in one sale)
- lineId: int
- quantity: int
- unitPrice: float
- inventoryItem: InventoryItem

ProductDAO (Data Access Object)

+ findById($id): InventoryItem
+ findAll(): array
+ save(InventoryItem $item): bool
+ update(InventoryItem $item): bool
+ delete($id): bool

4.4 State Chart Modeling

This diagram shows the various states an object can be in and the events that cause
transitions between those states.
Figure 4.2: State Chart Diagram for an InventoryItem
(A visual diagram would be here)
States:

New: The item object has been created but not yet persisted to the database.
Transition: save() -> Active
Active: The item is available in the inventory and can be included in sales and stock-
ins.
Transition: deactivate() -> Discontinued
Transition: updateStock($qty) -> Active (self-transition, but stock level changes).
Transition: updateStock() results in quantityInStock <= 0 -> Out of Stock
Out of Stock: The item's quantity has been depleted.
Transition: updateStock($positiveQty) -> Active
Discontinued: The item has been deactivated and is no longer available for new
transactions.
Final State.

4.5 Collaboration Modeling

(Communication Diagram)
This diagram emphasizes the structural organization of objects that send and receive
messages, providing a different view of the interactions shown in the Sequence
Diagram.
Figure 4.3: Communication Diagram for "Process Sale"
(A visual diagram would be here. Description below)
Objects and Links:
:Storekeeper -> :SaleController : 1: processSaleRequest(itemList)
:SaleController -> :Sale : 2: createNewSale()
:SaleController -> :ProductDAO : 3.1: getItem(itemId) [for each item]
:ProductDAO --> :SaleController : 3.2: return InventoryItem
:SaleController -> :Sale : 4: addItem(InventoryItem, quantity)
:Sale -> :SaleLineItem : 5: create(lineItem)
:Sale -> :Sale : 6: calculateTotal()
:SaleController -> :SaleDAO : 7: saveSale(Sale)
:SaleDAO -> :InventoryItem : 8: updateStock(quantity)

4.6 Component Modeling

This diagram shows the high-level, reusable parts of the system and their
dependencies.
Figure 4.4: Component Diagram
(A visual diagram would be here)
Components:
Web UI Component: Depends on the Controller Component.
Controller Component: Depends on the Business Logic
Component and Authentication Component.
Business Logic Component: Depends on the Data Access Component.
Data Access Component: Depends on the Database Component.
Authentication Component: Depends on the Data Access Component.
Reporting Component: Depends on the Business Logic Component.

4.7 Deployment Modeling

This diagram specifies the physical architecture on which the system will run.
Figure 4.5: Deployment Diagram
(A visual diagram would be here)
Nodes:

Client Machine: «device» Personal Computer / Laptop

«artifact» Web Browser (Chrome, Firefox)
Application Server: «device» Apache Web Server (on a PC or VPS)
«artifact» PHP Engine
«artifact» Inventory Management System (all PHP files)
Database Server: «device» MySQL Server (can be on the same node as the
Application Server)
«artifact» Inventory Database Schema

Connections: «http» between Client and Application Server, «jdbc» between

Application Server and Database Server.
4.8 Persistence Modeling (Database
Schema)
This section details the physical database design derived from the class model.
Figure 4.6: Physical Database Schema
(An Entity-Relationship Diagram would be here)
Tables:

users: (user_id INT PK AI, username VARCHAR(50)

UNIQUE, password_hash VARCHAR(255), role ENUM('admin',
'storekeeper'), email VARCHAR(100))
categories: (category_id INT PK AI, category_name VARCHAR(100), description TEXT)
inventory_items: (item_id INT PK
AI, item_name VARCHAR(255), description TEXT, cost_price DECIMAL(10,2), selling_p
rice DECIMAL(10,2), quantity_in_stock INT, reorder_threshold INT, category_id INT
FK, is_active BOOLEAN DEFAULT TRUE)

sales: (sale_id INT PK

AI, sale_date DATETIME, total_amount DECIMAL(10,2), performed_by INT FK
(users.user_id))
sale_line_items: (line_id INT PK AI, sale_id INT FK (sales.sale_id), item_id INT FK
(inventory_items.item_id), quantity INT, unit_price DECIMAL(10,2))
stock_in_transactions: (transaction_id INT PK AI, item_id INT
FK, quantity INT, date DATETIME, supplier_info VARCHAR(255), received_by INT FK
(users.user_id))

4.9 User Interface Design

This section presents the final, polished user interface designs, moving beyond the
wireframes from the analysis phase.
Figure 4.7: Final UI - Main Dashboard
(A high-fidelity mockup would be here)
Description: A clean, professional interface with a blue and white color scheme. The
navigation menu is on the left. The main dashboard area shows:

Summary Cards: with icons for Total Products (1,245), Low Stock Items (12 - in red),
Today's Sales (ETB 5,430.00).
Chart: A simple bar chart for "Sales Last 7 Days".
List: A "Critical Low Stock" table showing the top 5 items that need immediate
attention.
Figure 4.8: Final UI - Product Management Page
(A high-fidelity mockup would be here)
Description: A data table listing all products with columns: ID, Name, Category, Stock
Qty, Price, Status, and Actions (Edit/Deactivate buttons). A prominent "Add New
Product" button is at the top right. The stock quantity is colored: green (sufficient),
orange (low stock), red (critical/out of stock).
Figure 4.9: Final UI - Sales Transaction Page
(A high-fidelity mockup would be here)
Description: A two-panel layout. The left panel is for searching and adding items
(with a barcode scanner input field hinted for future use). The right panel is the
shopping cart, listing added items, quantities, prices, and a running total. Buttons:
"New Sale", "Hold Sale", "Complete Sale".

Chapter Five: Implementation and Testing

5.1 Introduction
This chapter marks the transition from system design to tangible reality. It details the
practical steps taken to bring the Inventory Management System (IMS) to life, from
the final rounds of testing to its deployment in a target environment. The chapter
covers the system's testing strategy, the acquisition of necessary resources, the
preparation of user documentation and training materials, and the detailed plan for
installation and system start-up. The primary goal of this phase is to ensure a robust,
reliable, and user-ready system that successfully addresses the problems identified
in the existing manual process.

5.2 Final Testing of the System

A rigorous testing strategy was employed to validate the system's functionality,
reliability, and performance. This builds upon the initial testing procedures outlined
in Chapter One.
1. System Integration Testing:

Objective: To verify that all individually tested modules work together as a complete
system as specified in the SRS.

Process: The Product, Sale, User, and Reporting modules were integrated
incrementally.
Test Case Example:
Action: Add a new sale for an item.
Expected Result:
The Sale module creates a new sales record.
The Product module automatically decrements the item's quantityInStock.
The Reporting module reflects the updated sales data and stock level.
Result: PASS - All integrated components functioned correctly, and data consistency
was maintained across modules.

2. User Acceptance Testing (UAT):

Objective: To obtain formal sign-off from the client (or a representative user) that
the system meets their business needs and is ready for deployment.
Process: A scenario-based testing session was conducted with a potential
storekeeper user.
UAT Scenario: "End-of-Day Process for a Storekeeper"
Steps: Log in -> Record 5 different sales -> Process a new stock-in delivery for a low-
stock item -> Generate and view the "Daily Sales Report".
Feedback: The user found the interface intuitive. The automatic stock update was
highlighted as a major improvement. A suggestion was made to add a "Quick
Product Search" by barcode on the sales page, which was noted for a future version.
Result: The system was accepted as it fulfilled all core business processes effectively.

3. Performance and Stress Testing:

Objective: To evaluate the system's response time and stability under peak load.
Process: Using a simple script, 10 concurrent login attempts and 50 rapid sequential
sales transactions were simulated.
Results:
Average page load time: < 2 seconds.
Sale transaction processing time: < 1 second.
The system remained stable without crashing, though a slight slowdown was noted
during the peak of concurrent logins. This was deemed acceptable for the expected
user base.

4. Security Testing:

Objective: To ensure the system is protected against unauthorized access and data
breaches.
Tests Conducted:
SQL Injection: Attempted to input SQL code into login and form fields. The system
successfully rejected the attempts, thanks to the use of prepared statements.
Authentication Bypass: Attempted to access restricted pages
(e.g., admin_dashboard.php) without logging in. The system correctly redirected to
the login page.
Password Security: Verified that passwords are stored as hashed values
(using password_hash() in PHP) in the database, not as plain text.
Result: All critical security tests were PASSED.

5.3 Hardware and Software Acquisitions

The following resources are required for the development and deployment of the
IMS.
Item Type Purpose Status/Acquisition

Development System development Available (Student's

Hardware
Laptop and initial testing. personal computer)

Local server
environment for
XAMPP/WAMP Acquired (Free, Open-
Software development
Stack Source)
(Apache, PHP,
MySQL).

Visual Studio
Software Source code editor. Acquired (Free)
Code

Live deployment
Web Hosting To be acquired (e.g.,
Software server with PHP &
Service shared hosting plan)
MySQL support.

Desktop For the store/client to Available (Client's

Hardware
Computer run the system. existing PC)

5.4 User Manual Preparation

A comprehensive user manual was prepared to facilitate smooth adoption. The
manual includes:

System Overview: A brief description of the IMS and its purpose.

Getting Started: Instructions on how to access the system via a web browser and log
in for the first time.
Module-by-Module Guide: Detailed, step-by-step instructions with screenshots for
every major function:
How to Log In/Out
How to Add a New Product
How to Record a Sale
How to Process a Stock-In Delivery
How to Generate and Interpret Reports
Troubleshooting: Solutions to common problems (e.g., "Forgot Password," "Item not
found in list").
FAQ Section: Answers to frequently asked questions.

5.5 Training
A structured training plan was designed for the end-users (Storekeeper and Admin).
Target Audience: Store Manager (Admin role) and Storekeeper.
Training Method: Interactive, hands-on workshop session.
Duration: 2 sessions, 2 hours each.
Training Agenda:
Session 1 (For Storekeeper):
System Navigation and Login.
Daily Operations: Recording Sales and Stock-Ins.
Checking Stock Levels and Understanding Low-Stock Alerts.
Session 2 (For Admin & Storekeeper):
Admin Functions: Managing User Accounts and Product Categories.
Generating and Analyzing Reports (Sales, Inventory Status).
Q&A and Practice Session.

5.6 Installation Process

The following steps outline the process for installing the IMS on the client's server.
Server Environment Setup:
Secure a web hosting plan that supports PHP 7.4+ and MySQL 5.7+.
Create a MySQL database and a user with full privileges for that database via the
hosting control panel (e.g., cPanel).
Application Deployment:
Upload all PHP, HTML, CSS, and JavaScript files to the public web directory
(e.g., public_html) on the server using an FTP client (e.g., FileZilla).
Import the database schema by executing the provided inventory_system.sql file via
the hosting provider's phpMyAdmin interface.

Configuration:
Edit the [Link] file with the live database connection details (hostname,
database name, username, password).
Test the connection by trying to log in to the system.

5.7 Start-up Strategy

A Phased (Parallel) Implementation strategy will be recommended to the client to
minimize risk.

Phase 1: Parallel Run (1-2 Weeks)

The new IMS will run alongside the existing manual system.
All transactions will be recorded in both systems.
Purpose: To compare the outputs of both systems, build user confidence, and
identify any discrepancies without disrupting operations.

Phase 2: Full Cutover

After a successful parallel run and confirmation of the IMS's accuracy, the
organization will switch entirely to the new system.
The manual ledger books will be archived but will no longer be updated.
The IMS becomes the single source of truth for all inventory-related data.

Chapter Six: Conclusions and

Recommendation

6.1 Conclusions
The development of the web-based Inventory Management System (IMS) has
successfully demonstrated the practical application of software engineering
principles to solve a real-world business problem. This project set out to address the
critical inefficiencies of manual inventory systems—namely data inaccuracy,
operational delays, poor reporting, and lack of security—by creating an automated,
centralized, and user-friendly solution.
Throughout the project lifecycle, from the initial feasibility analysis and requirements
gathering to the detailed system design, implementation, and rigorous testing, all
the SMART objectives outlined in Chapter One were met. A fully functional system
was developed that:

Automates Core Processes: It seamlessly handles product management, stock-in/out

transactions, and real-time inventory tracking.
Enhances Decision-Making: It provides instant access to stock levels and generates
accurate sales and inventory reports on demand.
Improves Data Integrity: By eliminating manual data entry for calculations and using
a relational database, it has significantly reduced errors and data redundancy.
Increases Operational Efficiency: It has drastically cut down the time required for
daily tasks like stock-taking and report generation.

The system is not only technically sound, built with robust and scalable technologies
(PHP, MySQL), but it is also economically viable due to its use of open-source tools.
The User Acceptance Testing (UAT) confirmed that the system is intuitive and meets
the core needs of its target users. In conclusion, this project proves that a well-
designed software system can transform a cumbersome, error-prone manual
process into a streamlined, efficient, and reliable operation, thereby adding
significant value to small and medium-sized enterprises.
6.2 Recommendations
While the current version of the IMS is fully functional and ready for deployment,
several enhancements are recommended for future work to increase its scope,
power, and adoption:
Integration of Barcode Scanning: The next logical step is to integrate barcode
scanning functionality. This would require a simple USB barcode scanner and
modifications to the sales and product entry modules to accept scanner input, which
would dramatically speed up transaction processing and reduce human error to near
zero.
Development of a Mobile Application: A companion mobile app, especially for
Android devices, would provide unparalleled flexibility. Storekeepers could perform
stock checks and even record sales directly from the storage area or shop floor,
further enhancing operational mobility.
Advanced Reporting and Analytics: Incorporating more sophisticated data analytics,
such as sales trend forecasting, identification of best-selling and slow-moving items,
and profit margin analysis over time, would provide management with deeper
strategic insights.
Supplier Management Module: Adding a module to manage supplier information,
track purchase orders, and monitor supplier performance would create a more
comprehensive supply chain management tool.
Multi-branch and Multi-warehouse Support: For growing businesses, enhancing the
system to manage inventory across multiple physical locations would be an essential
upgrade.
Online User Community and Support Portal: Establishing a simple online portal for
documentation, video tutorials, and user feedback would help in the long-term
maintenance and evolution of the system.

Appendix
The Appendix contains supplementary materials that are too detailed for the main
body of the report.
Appendix A: Complete Source Code Listing
The full, well-commented source code for all PHP, HTML, CSS, and JavaScript files.
Appendix B: Database Dump File
The complete SQL dump file (inventory_system.sql) used to create the database
schema and insert initial test data.
Appendix C: User Manual
The full, detailed user manual with screenshots.
Appendix D: Test Cases and Results
A spreadsheet documenting all test cases, including Unit, Integration, System, and
UAT scenarios, with inputs, expected outputs, and actual results.
Appendix E: Project Planning Gantt Chart
A visual timeline of the project milestones and tasks.
References

Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems Analysis and Design with
UML: An Object-Oriented Approach (5th ed.). John Wiley & Sons.
McLaughlin, B., Pollice, G., & West, D. (2006). Head First Object-Oriented Analysis
and Design. O'Reilly Media.
W3Schools. (2023). PHP Tutorial. [Online] Available
at: [Link] [Accessed: May 2024].
MySQL Documentation. (2023). MySQL 8.0 Reference Manual. Oracle Corporation.
[Online] Available at: [Link] [Accessed: May
2024].
Sommerville, I. (2016). Software Engineering (10th ed.). Pearson Education.