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 Inventory Management System is a web-based application

developed to manage the stock information of Bule Hora University.
The primary objective of the project is to provide a model software
solution through which all inventory-related data of the university
can be efficiently stored, monitored, and updated.

The system is designed as an intranet application and includes an

admin component that supports effective inventory control and
system maintenance. It manages the overall stock of the university,
including general inventory details, purchase information, and the
remaining quantity of items available in the institution. The system
also allows users to update inventory records whenever necessary.

Each item entered into the inventory is created with a unique stock
name and entry date, and these details can be modified at any time
depending on transaction updates, including returned items. To
ensure security and prevent unauthorized access or misuse, the
system includes a login page that protectively manages the
university’s stock operations.

The importance of implementing a web-based inventory system at

Bule Hora University has become critical, as timely access to
information is essential for effective resource usage. The system
improves visibility of equipment utilization, enhances movement
tracking, and supports demand forecasting, thus improving the
overall productivity of the institution. With the lack of an existing
tool to monitor material availability and quantity, this system will
help the university develop better operational management
capabilities.

1.2 Background information of the Organization

Bule Hora University was officially established on June 3, 1989 (E.C.)

and, over time, a number of departments and academic programs have
been opened, increasing the university’s admission capacity.

According to the university’s statistics, Bule Hora University currently

has 193 male and 109 female employees, making a total of 302 workers.
The store office of Bule Hora University was established during the early
years of the institution and has grown alongside the university’s
expansion. As the university’s capacity developed, the number of staff
members working in the store office also increased. Currently, the office
has four employees, whereas it began with only one.

The store office is considered the backbone of the university, as it is

responsible for managing all activities related to the materials and
resources available within the institution. Today, the store office of Bule
Hora University provides a variety of essential services. The main
activities include:

Registering new materials: This is done manually using Model 19

receipt forms to record new items.

Generating periodic reports: Reports are prepared every six

months and annually.

Issuing materials to users: When materials are given to users, the

transaction is recorded using a document known as Model 20.

1.2.1 Vision of BHU

Bule Hora University (BHU) aspires to become a center of excellence in

teaching, research, and community service. Its vision is to produce
competent professionals, generate impactful research outputs, and
contribute to national development through innovation, transparency, and
quality education. The university aims to be a leading institution
recognized locally and internationally for academic excellence, ethical
values, and sustainable development initiatives.
1.2.2 Mission of BHU

The mission of Bule Hora University (BHU) is to provide quality

education, conduct relevant and problem-solving research, and
deliver need-based community services. The university is committed
to producing skilled, ethical, and responsible graduates who can
contribute to the socio-economic development of the country. BHU
strives to foster innovation, promote cultural diversity, ensure
academic freedom, and create an environment that supports
sustainable development and national growth

1.3 Background of the project

Effective inventory management plays a crucial role in ensuring the

smooth operation of any institution, particularly in higher education
environments where various materials, equipment, and resources
must be continuously monitored. At Bule Hora University, the store
office is responsible for managing academic, administrative, and
operational materials. However, the current manual system used to
record, track, and update inventory has become inefficient and prone
to errors.

The manual recording of items using Model 19 and Model 20

documents makes the process time-consuming and increases the
likelihood of data loss, duplication, and inconsistencies. In addition,
generating periodic reports every six months and annually requires
significant effort and can result in delays in decision-making. As the
university continues to grow in size, departments, and material
demands, the limitations of the manual system have become more
evident.

To address these challenges, there is a clear need for a web-based

inventory management system that allows real-time monitoring,
accurate record-keeping, quick report generation, and improved
material control. A computerized system will enhance the efficiency
of the store office, reduce unnecessary waste, prevent misuse of
resources, and provide reliable data for administrative planning.
Therefore, this project aims to design and develop a web-based
Inventory Management System for Bule Hora University to
modernize and automate the processes of material registration,
tracking, reporting, and distribution. The implementation of such a
system will strengthen the workflow of the store office and contribute
to better resource management across the university.

1.4 Statement of the problem

Bule Hora University currently uses a manual inventory management

system to manage all the properties of the university. This manual system
has several problems. Handling reservations is difficult because the stock
clerk must manually check the entire list of materials stored in the
inventory. Additionally, the current system does not allow fast processing
of user requests, adjustments, or cancellations of reserved items.

Generating reports in the current system requires significant effort and is

time-consuming. The stock record-keeping process is poor and prone to
several problems, such as files being destroyed or stolen, and it is difficult
to locate materials because they are stored in multiple different stores.
Furthermore, managing and controlling daily activities is also
challenging. Therefore, this project aims to address and solve the above-
mentioned problems.

1.5 Team composition

This is a solo student project.

Table 1.1: Project Team Composition

Team Member Role/Position Responsibilities

Oversees project planning,
coordinates tasks, and ensures
Project Manager Leader/Coordinator
project objectives are met on
time.
Gathers requirements, analyzes
System Analyst Requirement Analyst existing processes, and designs
system specifications.
Develops, codes, and implements
Software
Programmer/Developer the web-based inventory
Developer
management system.
Database Database Manager Designs, manages, and maintains
Administrator the database to ensure data
 Team Member Role/Position Responsibilities
integrity and security.
Tests the system, identifies
Quality errors, and ensures functional and
QA Specialist
Assurance/Tester performance requirements are
met.
Prepares user manuals, technical
Documentation
Technical Writer documentation, and project
Specialist
reports.

1.6 Objective of the project (SMART)

1.6.1 General Objective

1.6.1 General objective

To develop computerized system for Inventory Management System in

Bule Hora University

1.6.2 Specific objectives

In order to achieve the main objective, we have developed the following

specific objectives:

 Gathering required information for proposed system.

 To Design the particular function of proposed system by UML

 To implement User friendly GUI for the proposed system.

 To create and implement a database for the proposed system.

 Implement a report module.

 To Test and deploy the developed system.

 To document the system

1.7 Feasibility Analysis

A feasibility study is a preliminary study undertaken to determine and

document a project
[Link] is essential to evaluate the cost, operation, technical benefits
of the proposed system.
On the basis of the feasibility study decision is taken on whether to
proceed or to cancel the project.

1.7.1 Operational feasibility

The developed system to provide accurate, active, secured service and

decreases labor of inventory
workers and as well as registrar items. It is not limited to particular
groups or body.
It is a measure of how well a proposed system solves the problems and
takes advantage of the
opportunities identified during scope definition and how it satisfies the
requirements identified in the
requirements analysis phase of system development.

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 Reduced time spent on stock-taking and reporting (estima
hours) reduction).

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

Improved customer satisfaction due to better product ava

Informed decision-making through real-time data and rep

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

Item Estimated Cost (ETB)

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

Total 27,000

1.8 Scope of the project

The scope of this project is limited to developing a web-based Inventory

Management System for the store office of Bule Hora University. The
project focuses solely on creating a computerized system through which
the store management tasks of the university will be carried out.

The system is specifically designed for the store management office and
does not include other departments or work units within the university.
The reason for limiting the project to a single work unit—the store office
—and to a single institution—Bule Hora University—is, on one hand,
due to time and budget constraints, and on the other hand, to make the
project more manageable and achievable.

1.9 Significance of the project

Significance of the project is:

 It enables to employ appropriate computerized system.

 It will be replace manual base automated

 Enhancing the service offered by the store office.

 It enables the store customers to get fast access and help to the
organization in service

giving operations..

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

We use iterative model for our project. It is easy to manage due to

flexibility of the model. The

reason to choose this model is that it allow us to can iterate back if error
is occurring in one

phase and we can return back to other phase to fix errors at any phase of
the project life cycle.

The data collection methods, system development methods and system

development tools are

described below

1.11.1 Data Source

The data for developing the Inventory Management System for Bule
Hora University was collected from multiple sources to ensure accuracy
and completeness. The main data sources include:

Primary Data Sources:

Interviews with store office staff to understand the existing

inventory management process and identify problems.

Observations of daily store operations to gather firsthand

information about stock handling, reporting, and record-
keeping.

Questionnaires or surveys distributed to staff to collect information about

user requirements and system expectations.

Secondary Data Sources:

 Existing records and documents, such as Model 19 and
Model 20 forms used for inventory tracking.

Reports, manuals, and internal guidelines from the store

office.

Relevant literature and online resources on inventory

management systems, web-based applications, and database
management.

1.11.2 Fact Finding Techniques

To develop an effective Inventory Management System for Bule Hora

University, several fact-finding techniques were employed to gather
accurate and relevant information about the current system and user
requirements. The main techniques include:

Interviews:
Conducted with store office staff and other stakeholders to
understand the existing inventory management process, identify
challenges, and gather suggestions for the new system.

Observation:
Direct observation of daily store operations was carried out to see
how materials are received, stored, issued, and recorded. This
helped identify inefficiencies in the manual process.

Questionnaires/Surveys:
Structured questionnaires were distributed to staff members to
collect information about user needs, expectations, and problems
faced with the current system.

Document Review:
Existing records, such as Model 19 and Model 20 forms, reports,
and internal guidelines, were analyzed to understand the workflow,
data structure, and reporting requirements.

Research/Literature Review:
Relevant literature, online resources, and previous studies on
inventory management systems were reviewed to identify best
practices and technical solutions suitable for the university.

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.13 Development Tools

Tool/Technology Purpose/Use
Programming Language (e.g., Implements the backend logic and
PHP, Java, Python) functionality of the system.
Database Management System Stores, retrieves, and manages
(e.g., MySQL, PostgreSQL) inventory data securely.
Web Server (e.g., Apache, Hosts the web application and handles
Nginx) client-server communication.
Designs the frontend interface and
HTML, CSS, JavaScript
improves user interaction.
UML Modeling Tools (e.g., Creates system design diagrams such as
StarUML, Lucidchart) use case, class, and sequence diagrams.
IDE/Text Editor (e.g., Visual Provides an environment for coding,
Studio Code, Eclipse) debugging, and project management.
Version Control (e.g., Git, Tracks changes in the code and
GitHub) facilitates team collaboration.
Testing Tools (e.g., Selenium, Performs system testing, identifies
PHPUnit) errors, and ensures quality assurance.

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.

A limitation is an element, factor, or subsystem that restricts a system

from achieving its full potential. There are several constraints within our
proposed system that limit its effectiveness and performance. Our system
is focused solely on the inventory management process of Bule Hora
University. The main limitations include:

The application is not functional without intranet or internet

connectivity.

The application server requires a stable and continuous power

supply.

The system relies on accurate human data entry, which may

introduce errors.
 Some team members do not have laptops and must work on
desktops; as a result,data may be lost during power outages.

These limitations highlight areas where additional resources or

precautions are needed to ensure smooth operation of the system.

1.17 Risks & contingencies

Risk Impact Contingency Plan

Loss of unsaved data Use of uninterrupted power
Power outage and interruption of supply (UPS) and frequent
system development data backups
Implement offline access for
Internet/Intranet Inaccessibility of the
critical functions and ensure
failure web-based system
network redundancy
Implement validation rules in
Human errors in Incorrect or inconsistent
the system and provide user
data entry inventory records
training
Regular server maintenance,
Hardware or System downtime and
data backup, and use of
server failure potential data loss
reliable hardware
Prioritize core functionalities
Delay or scaling down
Budget constraints first and seek additional
of project scope
funding if needed
Provide training for team
Lack of technical members and involve
Development delays
skills experienced developers when
necessary

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 business rule is successfully an operating standard or polices that we

have try to specify for
both the existing system and the proposed system of the store
management must satisfy. We
mainly focus on the existing system business rules. The existing system
has many business rules
or principles some of them are:
Business rule 1: New items are recorded and assigned a code by the
stock clerks.
Business rule2: After recording and assigning code by the store clerk the
items led to the store
keeper then he/she record, check and place them.
Business rule3: Only staff members of the university are allowed to take
an authenticated
material.
Business rule4: When the users/staffs want to borrow any material
he/she must register his id,
full name, email, status and other user details properly.
Business rule5: In order to get the item, he /she must get permission
from the academic
president /president and the store officer have to put their signature.
Business rule6: The staff member has to put his/her signature while
taking the item.
Business rule7: The staff member should not damage the item

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 m

2.7.1 Performance search through ledgers or spreadsheets. Generating a simple repo
take hours or even days.

Input: Data entry is highly prone to human error (e.g., transposing

2.7.2 Information numbers). Data is often redundant, entered in multiple ledgers.
(Input & Output) Output: Reports are often inaccurate due to source data errors, lea
poor decision-making. Information is not timely.

Physical ledgers can be easily lost, damaged (e.g., by water, fire),

2.7.3 Security and
accessed by unauthorized personnel. There is no audit trail to trac
Controls
made changes to the records.

The system is highly inefficient. Significant staff time is wasted o

2.7.4 Efficiency data entry, calculations, and report generation. Time spent on phy
stock counts is excessive.

Customer service is slow at the point of sale as the clerk must che
2.7.5 Service ledger for availability and price. The risk of selling out-of-stock i
high due to outdated 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

We use a use case to identify a sequence of actions that provides a

measurable value to the actor
which is participating in our system and our use case describes a way to
which the environment
interacts with the system.
Main courses action
Actor action System response

Step1: User has to activate the Step2: The System responses by

system. displaying the login interface and allow
Step3: User selects account type the user for the user name and password.
and fills Step5: System verifies user_name and
his or her username and password. Password.
Step4: he/she select login button. Step7: System displays its main window.
Step6: the User get authentication Step8: Use case end
and
access the system.

Alternative course of action (if user enters wrong user ID and / or

password)
Step6: System displays an incorrect username and password message.
Step7: System enables user to try again.
Name: Manage User
Table 3 Main Course of Action about Login
UC_ID: UC_02
Actor: Administrator
Description: This use case is done by the Administrator when they need
to delete, edit and make
some modification.
Preconditions: The Administrator login to the system to manage users.
Post conditions: The user information will be managed by administrator.
Main course of action:
About adding new user account
Actor action System response

Step1: the Administrator wants to Step4: the system validates the new
add new user user
to the system and he/she login to detail.
the system. Step5: the system save the user
Step2: the Administrator enters the detail to
new user the database.
name, account type, Password and Step6: the system permits some
reenter operational tasks according to
password to the system via adding his/her
new user category of the new user.
form. Step8:the system ends
Step 3: the Administrator submits
the new user
information.
Step7:the Administrator tells the
category, user
name and password to the user

Table 4 Main Course of Action about Add New User Accoun

Alternative course of action:
Step2: If the Administrator does not enter the username or the password
or he/she entered which
does not match correctly, the system displays a message please enters the
user name and
password correctly.
Step4: if not correct the system doesn’t save the entered information to
the database.
Step5: the system displays a fill again message and allow him/her to fill
again.
About updating an account:
Actor action System response

Step1: the Administrator wants to Step4: the system checks the new
update account
an account and he/she login to the information with the existing
system. account in the
Step2: the Administrator inserts database.
account Step5: the system saves the new
_type, user_name, password, and account to
other the database.
user information. Step6: the updating process ends
Step3: he/she submits the data.

Table 5 Main Course of Action about Update Account

Alternate course action:
Step5: the system doesn’t save the new account to the system database
and it displays a fill again
message.
lOMoARcPSD|61724473About inactivate the account
Actor action System response

Step1: the administrator wants to Step5: the system checks the

inactivate the account. entered
Step2: he/she login to the system. information with the existing
Step3: the administrator enters the account in
account type, user_name of the user the database
to be Step6: the system sends message
inactivated in the form. “Do you
Step4: the administrator selects the want to inactive?” to the
inactivate button. administrator
Step7: the administrator selects the Step8: the system in activated the
yes account
option. from the system.
Table 6 Main Course of Action about Inactivate Account
Alternate course action:
Step3: the system displays fill again message to Administrator.
Step4: it does nothing.
Step5: the system sends a try again message.
Step7: the system ends if he/she selects no.
Name: Manage Item
UC_ID: UC_03
Actor: Stock Clerk
Description: This use case is done by the stock clerk when items are
needed to be managed.
Preconditions: The stock clerk has to login to the system when he/she
wants to manage item to
the system.
Post conditions: The item information will be recorded to the database of
the system.
Main course of action:
About adding item:
Actor action System response

Step1: the stock clerk wants to add Step4: the system checks the item
new detail.
item to the system. Step5: the system saves the item
Step2: the stock clerk inserts the input
item information to the database.
type, serial_no, brand, model and Step6: the system check whether it
quantity, to the system via add item have
form saved successfully or not.
Step3:the stock clerk selects Add Step7: the system displays a
Item message
button “successfully added”.
Step8: end the system

Table 7 Main Course of Action about Add Item

Alternative course of action

lOMoARcPSD|61724473Step 3: the system does nothing.

Step4: the system displays “fill again” message.
Step5: does not save the entered data.
Step6: the system displays “not added” message.
Main course of action:
About updating the item detail:
Actor action System response

Step1: the stock clerk wants to Step5: the system checks the
update the entered
item from the system. information with the existing item
Step2: he/she login to the system. deail in
Step3: the stock clerk enters the the database
item type, Step6: the system sends message
item name, item code to be updated “Do you
in the want to update?” To the stock
update form. clerk.
Step4: the stock clerk selects the Step8: the system updates the item
update from
button. the system
Step7: the stock clerk selects the
yes
option

Table 8 Main Course of Action about Update Item

Alternate course action:
Step5: displays “try again” message.
Basic course action:

lOMoARcPSD|61724473About deleting item detail:

Actor action System response

Step 1: the stock clerk wants Step 4: the system checks the
deletes the entered
item from the database. item_code with the existing
Step 2: the stock clerk enters item_code in
item_code the database.
to the form. Step 5: the system sends
Step 3: the stock clerk clicks on confirmation
delete option message to the stock clerk.
button. Step 7: the system deletes the item
Step6: the stock clerk selects the from
yes the database.
option Step 8: the deleting process ends.
Table 9 Main Course of Action about Delete Item
Alternative course of action:
Step5: the system displays fill again message to the stock clerk.
Step7: the system ends if he/she selects no.
Name: View Report
UC_ID: UC_04
Actor: Managers
Description: This use case is seen by manager and the stock clerk when
they want to view about
the item report, employee report, scheduling report.
lOMoARcPSD|61724473Preconditions: The manager and stock clerk
login to the system and the staffs and the items are
already in database.
Post conditions: the manager and the stock clerk views a report of some
activities based on their
task.
Main course of action:
Actor action System response

Step 1: the manager wants to view Step3: the system displays the
the selected
report. report automatically.
Step2: The manager selects a Step 4: the report process end
report type.

Table 11 Main Course of Action about View Item

Alternative course action:
Step2: displays please fill the form.
Step5: the system displays a fill again.
Name: Request Item
UC_ID: UC_06
Actor: Staff Members
Description: this process is done by the staff members when they need to
request to take or
return an item.
Preconditions: The staff members have to login to the system and they
have to fill the request
item form correctly.
lOMoARcPSD|61724473Post conditions: The staff member will have
sent take or return item request.
Main course of action about taking Item Request:

Actor action System response

Step1: the staff wants to request the Step 4: the system validates the
item. item
Step2: the staff member enters the detail.
item Step5: the system sends the
description (item type, item name, request.
brand, Step6: the process ends.
quantity, model, serial_no etc.)
he/she
wants.
Step3: the staff member clicks on
request item

Table 12 Main Course of Action about Take Item Request.

Alternative course of action:
Step5: system displays a try again message.
About returning item request:
Actor action System response

Step1: the staff wants to request the Step 4: the system validates the
item. item detail.
Step2: the staff member enters the Step5: the system sends the request
item to the
description (item type, item code, manager and the manager approves
name, the
brand, quantity, model, serial_no return request.
and other Step6: the process ends.
specifications based on the item
type)
he/she want to return.
Step3: the staff member clicks on
return
Item request.

Table 13 Main Course of Action about Return Item Requesting.

Alternative course of action:
Step4: the system displays try again message.
Name: Receive Response
Actor: Staff Members
UC_ID: UC_07
Description: this use case is done by the staff members when the
manager sends a
response to them.
Precondition: the staff members have to send a request and the manager
is interested to
give a response to them.
Post condition: the staff members receive an approval response or
disapproval message.
Main course of action
Actor Action System Response

Step1: the staff member’s login to Step 3: the system displays the
the response
system. information either approval or not;
Step2: the staff member selects the if the
receive response is an approval, then the
response menu. message
Step4: the staff member views the should contain an item detail he/she
response. requested and its item code and the
quantity
allowed to him/her.
Step5: the process ends.

Table 14 Main Course of Action about Receive Response

3.2.3 Sequence Diagram

A sequence diagram is a kind of interaction diagram that shows how

processes of the proposed

system of inventory management system operate and in what order. A

sequence diagram shows
object interactions arranged in time sequence. It depicts the objects and
classes involved in the

scenario and the sequence of messages exchanged between the objects

needed to carry out the

functionality of the scenario of the proposed system. Sequence diagrams

typically are associated

with use case realization in the logical view of the proposed system under
development. The

main sequence diagrams of the new system of inventory management

system are listed below"

Figure 3 Sequence Diagram of Login

Figure 4 Sequence Diagram of Add New User

3.2.4 Activity Diagram

As we have seen, a sequence diagram shows how objects interact over

time to accomplish

specific system functions or activity of inventory management system.

Activity diagram shows

also the conditional logic for the sequence of system activities needed to
accomplish a business
process of proposed system in a good way

Figure 10 Activity Diagram of Add New User

Figure 11 Activity Diagram of Manage User
Figure 12 Activity Diagram of Add Item
Figure 13 Activity Diagram of View Report
Figure 14 Activity Diagram of Take Request Item

3.2.5 Analysis Level Class Diagram (Conceptual Modeling)

Diagrams are used to represent the structure of the system in terms of

objects, their notes and

nature of relationship between classes. It shows the static features of the

objects and do not

represent any particular processing. [ CITATION Onl \l 1033 ]Our

system has the following
classes:

Manager: is the representation of the real world class of manager which

interacts with system to

accomplish the managerial activity such as view report, approve request.

Staff members: is the representation of the real world user.

Administrator: is an administrator which uses the automated system to

manage users.

Item: it is the representation of the real world class of materials.

Stock clerk: the representation of the real world class which interacts with
system to accomplish

the activity such as managing items.

Figure 2 Class Diagram of our System

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], SaleController.

php, [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], Stoc

[Link], [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]

, [Link] (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)

Figure 15 Design of Class Diagram

4.4 State Chart Modeling

State chart Modelig describes the flow of control of the inventory

management proposed system

from one state to another state to describe the system dynamically. States
are defined as a

condition in which an object exists and it changes when some event is

triggered. So the most

important purpose of State chart diagram is to model life time of an

object from creation to
termination.

Figure 16 State Chart of Login

Figure 17 State Chart of Add User

Figure 18 State Chart of Update Item

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 DECIM
AL(10,2), selling_price 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_b
y 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), rec
eived_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

System
Development Hardwar development Available (Student's
Laptop e and initial personal computer)
testing.

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

Visual Studio Source code

Software Acquired (Free)
Code editor.

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

For the
Desktop Hardwar store/client to Available (Client's
Computer e run the existing PC)
system.

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.