TITLE: ANDROID-BASED ONLINE PURCHASING MANAGEMENT

SYSTEM

Submitted to Information Technology Department in partial fulfillment of the

requirements for the degree of Bachelor of Science in Information Technology

GROUP MEMBERS
NAME ID
1. Abraham Teshom------------------------------1300159
2. Getish Tadese-----------------------------------1304914
3. Amanuel Mesafint------------------------------1304665
4. Shambel Belay----------------------------------1305942

ADVISOR NAME
____________________________________

JAN 23, 2025

WOLDIA , ETHIOPIA

i
 DECLARATION
The project is our own and has not been presented for a degree at any other university. all the
sources of material used for the project have been duly acknowledged.
Advisor name

-----------------------------

Signature---------------------

Department of information technology ---------------------

Date ------------------------------------

GROUP MEMBERS
NAME ID
1. Abraham Teshom------------------------------1300159
2. Getish Tadese-----------------------------------1304914
3. Amanuel Mesafint------------------------------1304665
4. Shambel Belay----------------------------------1305942

ii
 ACKNOWLEDGMENT
Above all, we would like to thank our god, god giving for us the ability to think, analyze ideas,
and be health for patients, as well as the strength to complete our project on time. Next to this, we
would like to thank our Department Information Technology for gave us the brilliant opportunity
to do this project on the topic to develop Android Based online purchasing management system
for Woldia university. We would like express our special thanks of appreciativeness for our
advisors Instructor Mr.-DESALEGN. For his valuable and constructive suggestions during the
planning and development of this project work. His willingness to give his time so generously has
been very much appreciation.

Finally, We are also thankful to purchasing directorate and other staff members for their constant
constructive criticism and invaluable suggestions, which benefited us a lot while developing the
project on “Android based Online purchasing management system”.

iii
LIST OF ACRONYMS FROM OUR DOCUMENT

BR: Business Rule

CRC: Class Responsibility Collaborator
ERD: Entity-Relationship Diagram
ERD: Entity-Relationship Diagram
HRM: Human Resource Management
IOS: iPhone Operating System
OOSAD: Object-Oriented System Analysis and Design
UAT: User Acceptance Testing
UI: User Interface
UML: Unified Modeling Language
XML: Extensible Markup Language

iv
CONTENTS PAGES

Declaration ...................................................................................................................................... ii

Acknowledgment ........................................................................................................................... iii

List of acronyms from our document............................................................................................. iv

ABSTRACT .................................................................................................................................. vii

CHAPTER ONE ............................................................................................................................. 1

1. introduction ................................................................................................................................. 1

1.1 Background of the organization ............................................................................................ 1

1.2 Statement of the Problem ...................................................................................................... 1

1.3 Objectives .............................................................................................................................. 2

1.3.1 General Objective ........................................................................................................... 2

1.3.2 SPECIFIC OBJECTIVES............................................................................................... 2

1.4 Methodology ......................................................................................................................... 3

1.4.1 Requirement Gathering Methods.................................................................................... 3

1.4.2 ANALYSIS AND DESIGN METHODOLOGY ........................................................... 4

1.4.3 Implementation Methodology ........................................................................................ 6

1.5 BENEFICIARIES and Significance of the Project ............................................................... 8

1.6 Significance of the Project .................................................................................................... 9

1.7 Scope of the Project............................................................................................................. 10

1.8 Limitations of the Project .................................................................................................... 11

CHAPTER TWO .......................................................................................................................... 12

2. SYSTEM FEATURES ............................................................................................................. 12

2.1 The Existing System............................................................................................................ 12

2.2 Proposed System ................................................................................................................. 12

2.3 Requirement Analysis ......................................................................................................... 12

v
 2.3.1 Functional Requirements .............................................................................................. 12

2.3.3 Business Rule Documentation ................................................................................ 18

2.3.4 User Interface prototype ......................................................................................... 19

2.3.5 State chart diagram ................................................................................................. 22

2.3.7 Sequence diagram ................................................................................................... 24

2.3.8 Analysis Class Model ................................................................................................... 29

2.3.9 Logic model ............................................................................................................ 33

2.4 Non-functional requirement ................................................................................................ 37

2.5. System Requirement .......................................................................................................... 39

2.5.1. Hardware requirements ........................................................................................... 39

2.5.2 Software requirements ............................................................................................ 40

2.6. Abstraction with CRC analysis .......................................................................................... 41

2.6.1 Conceptual modeling: Class diagram ........................................................................... 43

References ..................................................................................................................................... 45

vi
 ABSTRACT
This project entitled “Android based Online Purchasing Management System for Woldia
university” is designed to keep records of different purchasing informations and make retrieval
or searching of different purchasing information easier.the project has been designed in PHP
Technology.i.e php with html .all of the data need for the application is stored in the form of tables
in phpmyadmin .The main purpose of this project is to develop web based purchasing information
management system for Woldia University campus.our system reduces the manual work and tries
to eliminate or reduce difficulties up to some extent.Generally, the new system replaces the
existing manual system into automated or computerized system that will help to store each and
every purchasing information in a well organized manner.

vii
 CHAPTER ONE
1. INTRODUCTION
1.1 BACKGROUND OF THE ORGANIZATION
Woldia University was established in 2009 by Ethiopian government minister of education. It is
located north wollo zone, which is far from Addis Ababa 521km and far from Dessie 120km. The
University began in 2012 with around 600 students in some faculties like Technology, Business
and Economics, Social science and Natural science. To administer well, Strategy planning and
management system is applied in Woldia University to measure performance on strategic planning
and management system and relationally to align the day to day activities to an organization’s
vision and strategy using strategic performance measures and strategic initiatives as other profit
and non profit organizations do. In the institution that has been started its service in 2012 in its
main campus and in 2014 the university has established second campus in mersa and some of the
department like agricultural field of studying are shifted to there and this system allows the
organization to learn what works and to become more strategy focused. So the executives
committed short term and long term plans and strategies to the mission of the institution helping
employees to realize their full potential to evolve the campus to be in the best position to accelerate
new field of studies and learning and teaching methodologies for great achievements of the
institution in a short period of time.

1.2 STATEMENT OF THE PROBLEM

purchasing management system will address these issues by digitizing operations, reducing delays,
and ensuring greater accuracy and accountability in procurement activities.

Woldia University’s current purchasing management system includes a partial web-based solution but still
relies heavily on manual processes, which presents several challenges that hinder the efficiency and
effectiveness of the procurement process. The existing system involves time-intensive activities, such as
slow purchase request submissions, approval processing, and report generation, which cause delays in
acquiring essential goods and services. The continued reliance on paper-based documentation within parts
of the system leads to frequent errors, record duplication, and difficulties in maintaining accurate
procurement data. Furthermore, procurement information is not readily accessible to all stakeholders,

1
limiting transparency. The system also consumes excessive resources, such as paper, storage, and human
effort, particularly in areas where the web-based system has not been fully implemented. Report generation
remains cumbersome, and the paper-based aspects of the system pose security risks, including data loss and
unauthorized access. These challenges highlight the need for a more fully integrated, automated, and user-
friendly solution, such as an Android-based online purchasing management system, to streamline
operations, reduce delays, and enhance accuracy, accountability, and transparency in procurement activities

1.3 OBJECTIVES
1.3.1 GENERAL OBJECTIVE

The general objective of this project is to design and implement an Android-based Online
Purchasing Management System for Woldia University that streamlines the procurement
process, enhances operational efficiency, ensures data accuracy, and promotes transparency
while improving accessibility and accountability through digitization and automation

1.3.2 SPECIFIC OBJECTIVES

 To develop a system that will digitize and streamline purchasing requests,

approvals, and record-keeping processes.
 To ensure reliable and error-free data management by utilizing secure and
centralized digital records.
 To provide an Android-based application that will allow authorized users
to access procurement information anytime and anywhere.
 To enable administrators and stakeholders to monitor the status of
procurement activities in real time.
 To develop features that will automatically generate detailed and timely
reports for improved decision-making.
 To incorporate authentication and access control mechanisms to ensure the
confidentiality and security of procurement data.
 To minimize resource consumption, such as paper and labor, by adopting
a fully digital system.
 To create an intuitive and easy-to-use interface that will require minimal
training for end-users.

2
1.4 METHODOLOGY
1.4.1 REQUIREMENT GATHERING METHODS

To understand the needs and challenges of the current purchasing process, we use the following
methods to gather requirements:
Stakeholder Interviews
We conduct structured and semi-structured interviews with key stakeholders, including:
 Procurement officers
 Administrative staff
 Department heads
 Suppliers
These interviews focus on understanding their challenges, requirements, and expectations for
the proposed system.
Observation
We observe the existing purchasing processes to identify:
 Workflow inefficiencies
 Bottlenecks in the approval process
 Data handling practices
This helps us gather practical insights into how the procurement system operates in real life.
Document Analysis
We analyze existing documentation, such as:
 Purchase request forms
 Approval and rejection records
 Procurement policies and guidelines
 Reports generated by the current system
This analysis provides insights into data fields, formats, and regulations the system must follow.
Surveys and Questionnaires
We distribute surveys and questionnaires to a broader audience, including faculty and staff, to
collect feedback on:
 Frequency of use
 Common issues faced

3
  Desired features and functionalities
Brainstorming Sessions
We organize brainstorming sessions with team members and stakeholders to:
 Identify additional requirements
 Prioritize features
 Explore innovative solutions
Focus Groups
We engage small groups of end-users in discussions to validate findings and refine system
requirements based on their input.
By using these methods, we ensure a comprehensive set of functional and non-functional
requirements, aligning the proposed system with stakeholder needs and expectations.

1.4.2 ANALYSIS AND DESIGN METHODOLOGY

To ensure the development of an efficient and scalable Android-based Online Purchasing

Management System, we have adopted the Object-Oriented System Analysis and Design
(OOSAD) methodology. This methodology provides a structured approach to analyzing,
designing, and implementing the system, ensuring that it aligns with user needs and technical
requirements.

1.4.2.1 Analysis Phase

1.4.2.1.1 Feasibility Analysis
We have assessed the technical, operational, and economic feasibility of the system to ensure its
viability. The Online Purchasing Management System is both technically, operationally, and
economically feasible for the university. It leverages existing technology infrastructure, aligns with
the university's operational goals, and offers long-term cost savings by automating and
streamlining purchasing processes.

1.4.2.1.2 Technical Feasibility Analysis

The technical feasibility of the Online Purchasing Management System has been assessed to
determine whether the required technology is available and suitable for the system's development.
The system will be built for the Android platform, leveraging common technologies such as Java
for the backend and Android Studio for development. We have identified that the required

4
infrastructure, such as modern Android devices, operating systems, and network connectivity, is
readily available. Additionally, the system will utilize cloud storage for data storage and backup,
ensuring scalability and reliability. The system's modular design and integration with existing
university systems have been considered, with a robust API design to ensure smooth data
exchange.

1.4.2.1.3 Operational Feasibility Analysis

The operational feasibility of the Online Purchasing Management System has been evaluated to
determine whether the university’s operational structure and resources can support the system's
implementation and maintenance. The system has been designed to be user-friendly, requiring
minimal training for the staff involved in the purchasing process. The system will be hosted on
cloud platforms to ensure high availability and performance, and university IT staff will oversee
its maintenance.

1.4.2.1.4 Economic Feasibility Analysis

The economic feasibility of the Online Purchasing Management System has been analyzed to
assess whether the system can be developed and maintained within the university's budget. The
initial development costs will include software development, testing, and deployment. However,
these costs are outweighed by the long-term benefits, such as reducing manual paperwork,
minimizing errors, improving procurement speed, and automating repetitive tasks. The cloud
hosting services will provide cost-effective scalability, eliminating the need for large upfront
infrastructure investments. Furthermore, the system’s ability to streamline operations and reduce
administrative overhead will result in cost savings over time.

1.4.2.2 Design Phase

Architectural Design

 Adopt a three-tier architecture comprising:

 Presentation Layer: Android application interface for end-users.
 Business Logic Layer: Server-side logic to process data and enforce business rules.

5
  Data Layer: Centralized database to store procurement-related information
securely.
UML Diagrams
 Sequence Diagrams: Illustrate the sequence of interactions between system
components.
 State Chart Diagrams: Depict the states and transitions of critical system objects,
such as purchase requests.
 Class Diagram: used to model the structure of a system, including the objects, their
relationships, and their behaviors.
Database Design
 Develop an Entity-Relationship Diagram (ERD) to model database tables and
relationships.
 Normalize the database to ensure data integrity and avoid redundancy.
User Interface Design:
 Create mockups and prototypes for key application screens, such as login, purchase
requests, and reports.
 Focus on usability and intuitive navigation to ensure user-friendliness.
By following the OOSAD methodology, the system will be designed to be robust, scalable, and
adaptable, addressing the current challenges faced by Woldia University’s procurement process.

1.4.3 IMPLEMENTATION METHODOLOGY

The implementation of the Android-based Online Purchasing Management System will

follow a structured approach to ensure the system is deployed effectively and meets the needs of
stakeholders. The methodology comprises the following stages:
Development Environment Setup
Tools and Technologies
Android Studio for developing the mobile application.
PHP for the backend development.
MySQL for database management.
Git for version control and collaboration.
Hardware Requirements

6
Development and testing will be performed on workstations with adequate processing power and
memory.
Servers will be set up for hosting the backend and database.
Coding and Development
Frontend Development
Develop user interfaces using Android’s XML layouts.
Implement interactive features using Java.
Backend Development
Write server-side logic to process data and enforce business rules.
Create secure APIs for communication between the Android application and the backend server.
Database Integration
Design and create tables in MySQL to store procurement data, user information, and transaction
records.
Implement data access layers for CRUD (Create, Read, Update, Delete) operations.
Testing and Debugging
Unit Testing
We will test individual modules, such as login functionality, request submission, and report
generation, to ensure they function correctly.
Integration Testing
We will test the interaction between the Android application, backend APIs, and the database to
verify seamless integration.
System Testing
We will test the complete system to confirm that all functionalities work as expected and are free
from defects.
User Acceptance Testing (UAT)
We will involve end-users to validate that the system meets their requirements and expectations,
ensuring it is ready for deployment.
Deployment
Server Deployment
We will deploy the backend system and database on a secure web server or cloud platform.
Application Deployment

7
We will distribute the Android application via the Google Play Store or provide it as a direct
APK file for installation. And then students, faculty, and staff can easily download the app from
a trusted source.
Training and Documentation
User Training
We will provide training sessions to familiarize users with the system.
We will prepare user guides and manuals for reference to ensure users can operate the system
effectively.
Technical Documentation
We will document the system’s architecture, APIs, and database schema to support future
maintenance and upgrades.
Maintenance and Support
Bug Fixing
We will address any issues or bugs identified during deployment and use to ensure the system
functions smoothly.
System Updates
We will regularly update the system to incorporate new features or address changing
requirements.

1.5 BENEFICIARIES AND SIGNIFICANCE OF THE PROJECT

Beneficiaries of Project
The primary beneficiaries of this project are:
University Leadership (President and Campus Dean)
 They will request and monitor purchasing needs.
 They will ensure that procured items match specifications and budgets.
Purchasing Directorate
 They will oversee and manage all purchasing activities.
 They will coordinate between departments, suppliers, and purchasing teams.
Administrator
 They will manage user accounts and control access.
 They will maintain system integrity and monitor operations.

8
Suppliers
 They will submit tenders and supply goods and services to the university.
 They will access tender notices and results via the platform.
Finance Officers
 They will allocate and manage budgets for purchases.
 They will approve the financial aspects of requisitions.
Department Heads
 They will submit departmental purchasing requests.
 They will approve initial requisitions before forwarding them to the purchasing team.
Purchasing Team
 They will handle tenders, evaluate submissions, and register winning suppliers.
 They will post tender notices online and ensure transparency.
Approval Committees
 They will evaluate and approve or reject requests based on budgets and procurement
rules.
Quality Assurers
 They will inspect and validate the quality of purchased items to ensure compliance with
specifications.
Property Administration Team
 They will register and store received goods.
 They will ensure that inventory aligns with procurement records.

1.6 SIGNIFICANCE OF THE PROJECT

Operational Efficiency
 The project will automate manual processes, which will reduce delays and
errors in the purchasing workflow.
Enhanced Transparency
 By providing a clear record of purchase requests and approvals, the system will
improve accountability and transparency within the university.
Cost Savings

9
  By minimizing redundant processes and optimizing resource allocation, the
project will lead to significant cost savings over time.
User Satisfaction
 A user-friendly interface and efficient processes will enhance satisfaction among
students, staff, and faculty, fostering a more productive academic environment.
Scalability and Adaptability:
 The system will be designed to accommodate the university’s growth and adapt to
changing needs, ensuring long-term relevance and value.

1.7 SCOPE OF THE PROJECT

Currently, all purchasing activities at Woldia University are performed partially web-based. The
newly developed system is designed exclusively for the main campus to streamline and manage
core purchasing activities, including requesting, filtering, processing, purchasing, reporting,
addressing outputs, and facilitating additional communication. Key functionalities of the system
include:
 Creates and manages accounts with role-based access control for different
stakeholders.
 Assign usernames and passwords for members.
 Collect purchasing requests from various departments and campuses.
 Registers suppliers and maintains records of their performance.
 Register tender results, and posting details of winners.
 Facilitates notifying departments to submit purchasing needs.
 Deliver purchased materials as specified.
 Records purchased items, verifies their quality, and updates inventory systems.
 Ensure quality assurance of materials.
 Generate timely reports for relevant stakeholders

10
1.8 LIMITATIONS OF THE PROJECT

Platform Dependence

 The system is designed specifically for Android, limiting accessibility for users on
iOS or other platforms.

Language Barrier

 The system is developed in English, which may hinder usage by staff or

stakeholders who are not proficient in the language.

Internet Dependency:

 The system requires an active internet connection to operate, making it inaccessible

during network outages.

11
 CHAPTER TWO
2. SYSTEM FEATURES
2.1 THE EXISTING SYSTEM

Woldia University’s purchasing management currently operates through a partially web-based

system, supplemented by manual processes. While certain functionalities, such as submitting
purchasing requests and tracking approvals, are supported by the web-based platform, much of the
process still relies on paper-based documentation. Departments submit requests through the
system, which are reviewed by their heads for availability before being forwarded to the
purchasing directorate for procurement. Materials are acquired through methods like open bids,
restricted tenders, direct procurement, or quotations, but the tender notices, bid evaluations, and
winner announcements remain largely manual. An approval committee evaluates the budget for
each request via a combination of online and offline methods. Purchased materials are received
and checked for quality, after which the property administrator team records and stores the
approved items, integrating these records into the system where applicable.

2.2 PROPOSED SYSTEM

Proposed System for Woldia University: Android-Based Purchasing Management System The
proposed system aims to automate the manual purchasing process at Woldia University to ensure
efficiency, transparency, and better resource management. The proposed system will be an
Android-based online purchasing management system. It is designed to digitize and streamline the
entire purchasing workflow, from submitting requests to procurement and final delivery. The
system will enable users at all levels (departments, approval committees, and suppliers) to interact
efficiently.

2.3 REQUIREMENT ANALYSIS

2.3.1 FUNCTIONAL REQUIREMENTS

In this project, the system must provide the following:

User Management
 Secure login with username and password.

12
  Role-based access control (e.g., Administrator, Department Head, Supplier).
 User account creation, activation, and deactivation.
Purchasing Request Management
 Submission of purchase requests by departments.
 Approval or rejection of requests by the approval committee.
 Real-time tracking of request statuses.
Tender Management
 Posting of tender notices for suppliers.
 Bid registration and submission.
 Evaluation and selection of bid winners.
Quality Assurance
 Verification of delivered items against specifications.
 Rejection of items that do not meet required standards.
Inventory Management
 Recording of purchased items in the inventory.
 Tracking item usage and availability.
 Generation of inventory reports.
Reporting and Analytics
 Generating real-time reports on procurement activities.
 Budget tracking for departments.
 Supplier performance reports.

13
2.3.2 System Use Case
2.3.2.1 Use case Diagram
System
View Purchasing Request

post Pur item

Purchasing Dirct Campus Dirctor
view purchased item Logout
reg. model19
<<include>>
<<include>> <<include>>
register winner <<include>>
<<include>> requ purchased
<<include>>
<<include>>
post Tender notice
<<include>> view directorate notce Dep;t Head
login
<<include>>
puchase team view tender result <<include>>

<<include>> <<include>>
reg. school
<<include>>
view approved req. <<include>> <<include>>
Supplier <<include>> School Dean
fill their own detail <<include>> reg.dep,t

<<include>> reg.user
view tendr notice
<<include>>
<<include>>
approve block account
<<include>>
<<include>>
<<include>> Administrator
reject reactivate account
Approve committe <<include>> <<include>>

<<include>>
register model22
view pur_request

view model20
view model19
check item quality

<<include>>
register model19
View Items
quality assurer

property admnistrator team

Finance officer

2.3.2.2 Use Case documentation

Use case ID: Represents identification number that enables us to make the use case traceable.
Use case name: Represents the name that we have used in the business use case model.
Participating Actor: Represents who interacts with the system either internally or externally.
Precondition: Represents what is the expected situation before the use case can be started.
Event flow: represents the steps we have to follow to get output we want from system.
Post-condition: represents what is expected output at the end of use case.
Alternative Flow: steps we have to follow if there is another ways to get the same result.
Table 1: Business use case for view model19
14
Use case View model19
Name:

Use case ID: Uc01

Description Used To view model19

Actors: Finance Officer

Preconditions: Supplier must have model 19

Event flows

1.suplier must have model 19

2.finance officer take a model 19 from supplier
3.finance officer view model 19 from suppliers
Post condition Model 19 is viewed successfully

Table 2: Business use case for description of View tender Result

Use case Id: Uc02

Use case View Tender Result

name:

Description To view different tender results

Actors: Finance Officer

Preconditions: Tender information must be Existed

Event flows

1.Finance Officer must view tender results

15
 2. View model 19 and a letter that comes from winner that has given by inventory department and
purchasing directorate respectively

Post condition Tender result is viewed successfully

Table 3:Business use case for description of Approve/reject

Use case Id: Uc3

Use case Approve purchase request

Name:

Description This use case allows Approval committee to approve different purchasing requests

Actors: Approval committee

Preconditions: New purchasing request is come from different departments

Event flows

1.new purchasing request is come from different department

2.the approval committee check the budget from the finance office
3 if the they have a budget approve the purchasing request to purchase
Post condition The purchasing request is approved successfully

Table 4: Business use case for description of Check quality of supplied item

16
 Use case Id: Uc5

Use case name: Check quality of supplied item

Description This use case allows quality assurer to Check quality of different supplied item

Actors: Quality assurer

Pre-conditions: Items information must be Existed

Event flows

1.Assure quality of the supplied item

2.View the items that the supplier supplies

Post condition Quality assurer views the quality of each item.

Table 5: Business use case for description of Register model19

Use case ID UC06

Use case name Register model19

Participating Actor Property administration team

Pre-condition Materials(items) information must there to

register model 19

Event flows

1.Registering the purchased items that they receive from the supplier

2.Store purchased items

17
Post condition The model 19 registered successfully

Alternative flows -

Table 6: use case description for register winner

Use case Id: Uc7

Use case name register winners

Description To register the winner among several suppliers

Actor Purchasing team

Precondition The Winner information must be there to register the winners detail

Event flows

1.Open the tender

2.Register the winner

3.Takes an agreement with the supplier

Post condition Winner is registered

2.3.3 BUSINESS RULE DOCUMENTATION

BR1: winner must be registered before starting the agreement.

18
BR2: winner must submit original plan of house or 300,000 to HRM.
BR3: Departments, offices, librarians, schools to request purchase with the right specifications of
materials
BR4: Repeated the same material with different number in the same request form is impossible for
example when we fill the request form and we want a number of materials which are the same
items it should be express in number at the same serial number.
BR5: Request the material which is available in store is forbidden.
BR6: The purchasing team can’t analyze the request before the approval committee approve it
BR7: Purchasing workers cannot purchase materials whose price is greater than the approved
Performa
BR8: Purchasing must be done after the validity of materials is checked by the right expert
BR9: The property department cannot receive unchecked purchases
BR10: Any employee cannot put out the materials from inventory department before get the permit
from property administrator team by taking model 20.

2.3.4 USER INTERFACE PROTOTYPE

To create an Android-based online purchasing management system for Woldia University, we can
adapt its concepts into a mobile user interface (UI) prototype.

Android UI Prototype for Online Purchasing Management System

Main Features

 User authentication (login/logout).

 Purchase request submission and tracking.
 Administrator management (approve/reject requests, create user accounts).
 Viewing tender notices and results.
 Supplier management (register suppliers, submit items).
 Quality assurance (verify purchased items).
 Reports and analytics.

Proposed Screens

Login Screen

19
  Fields: Username, Password.
 Button: Login

Purchase Request Screen

 Fields: Item Name, Quantity, Description, Department, Budget.

 Button: Submit Request.

Tender Notices Screen

List view of tender notices.

Button: View Details.

Approval Screen (For Approval Committee)

List of purchase requests.

Options: Approve, Reject.

Supplier Registration Screen

20
 Fields: Name, Contact Info, Items Supplied.

Button: Register Supplier.

Quality Assurance Screen

List of delivered items.

Button: Verify Quality.

Reports and Analytics Screen

Charts and summaries of purchasing activities.

Export options for reports.

Figure 2.1

21
3. Tools and Technologies

Frontend: XML for UI design.

Backend: PHP Mysql database storage

Programming: Java.

2.3.5 STATE CHART DIAGRAM

State chart diagram is normally used to model how the state of an object in purchasing information
management system changes in its lifetime.
State chart diagram for login

User start program

waiting for login user enter login info waiting to check machines

check

Error:no valid user

login failed

Valid user

Logged in

Figure 2.2 state chart diagram for login page

22
 Start initalization
Open the system

system display login page

Click login button

Enter user name and password

incorrect user name and password

Valid

System displays purchasing request form

Fill purchasing need

End
click submit button

Figure 2.3 state chart diagram for request

23
 Initail Select
login Back up
Start Noavailable

Check

Back up Controller

Process
start

Database

Take

Logout
Adminstrator

Figure 2.4 State chart for take backup

2.3.7 SEQUENCE DIAGRAM

Sequence diagram is a kind of interaction diagram that show how processes purchasing systems
operate with one another and in what order.

24
 login
Home page
User Login Controller Database

1 : Open home page()

2 : select login option()
3 : Request login form()
4 : open login user interface()

5 : Fill login information()

6 : Send information()

7 : Invalid()
8 : invalid login information()

9 : Re enter login information()

10 : Valid()
11 : Check()

12 : not existed()
13 : Error worng user information()

14 : Existed user Account()

15 : open previlaged Home()

Figure 2.5: sequence diagram for login

25
 Create Account

Adminstrator
Admin page
Create Account Controller Database
1 : Login to()
2 : Select()
3 : Create account form request()

4 : Display create account page()

5 : Enter user information()

6 : Send information()

7 : Invalid()
8 : Invalid user information()

9 : Re enter user Account information()

10 : Send()

11 : Valid()
12 : send()

14 : Error user is already existed() 13 : Existed()

16 : User Account is Successfully Created() 15 : not existed()

Figure 2.6: sequence diagram for Create Account

26
 Request Purchase

User User page requ.purchasing need form Controller Database

1 : Open()
2 : Select()
3 : request purchasing form()
4 : Display purchasinr rquest form()

5 : Fill the purchasing need()

6 : Send information()

7 : Invalid()
8 : Error enter information proporly()

9 : Re enter new purchasing information()

10 : Valid()
11 : send()
12 : successfully send()

13 : the new purchasing information successfully send()

Figure 2.7: sequence diagram for request purchasing

27
 Take backup

Adminstrator
Adimin page Backup Page Back up Controller Database
1 : Login to()
2 : select()
3 : backup page form request()
4 : Displaytype of backuo to be taken()
5 : Fill form()
6 : send()

7 : invalid()
8 : Display error message()

9 : Re fill form()
10 : send()

11 : valid()
12 : Take backup()
13 : backup successe()
14 : Display Success message()

Figure 2.8: sequence diagram for Take backup

28
 user purchasin team page register winner
Controller Database
1 : login()
2 : select()
3 : Fill Register Winner form()

4 : Display form()

5 : send information()

6 : invalid()
7 : winner is not rergistered()

8 : re enter register winner information()

9 : Valid()
10 : register()

12 : winner registered successfully() 11 : successful registration()

Figure 2.9: sequence diagram for register winner

2.3.8 ANALYSIS CLASS MODEL

The Analysis Class Model includes essential classes, their attributes, methods, and details about
their relationships, roles, and multiplicities. It provides a foundation for understanding the
structure and interactions within the Android-Based Online Purchasing Management System.

Model Classes

User

 Attributes:

 userId (String): Unique identifier for the user.

29
  userName (String): Name of the user.

 password (String): User login credential.

 role (String): Role of the user (e.g., Admin, Supplier).

 status (String): Status of the account (e.g., Active, Inactive).

 Methods:

 login (): Authenticates user credentials.

 logout (): Ends the user session.

 manageAccount(): Allows the admin to create or modify accounts.

 Relationships:

 One user can submit multiple purchasing requests.

 Multiplicity: 1 to * (One-to-Many).

Purchasing Request

 Attributes:

 requestId (String): Unique identifier for the request.

 itemDetails (String): Description of the requested item.

 quantity (int): Number of items requested.

 status (String): Current status (e.g., Pending, Approved, Rejected).

 date (Date): Date when the request was submitted.

 Methods:

 submitRequest(): Allows users to submit purchase requests.

 updateRequest(): Enables modifications to the submitted request.

30
  trackStatus(): Provides real-time tracking of the request's status.

Relationships:

 A Purchasing Request is associated with one Approval Committee.

Multiplicity: One-to-One (1:1).
 Multiple Purchasing Requests can be submitted by a single User.
Multiplicity: Many-to-One (* to 1).

Supplier

 Attributes:

 supplierId (String): Unique identifier for the supplier.

 supplierName (String): Name of the supplier.

 contactDetails (String): Supplier’s contact information.

 rating (float): Performance rating of the supplier.

 Methods:

 submitBid(): Allows the supplier to participate in tenders.

 viewTenderNotices(): Displays active tender notices.

 Relationships:

 One Supplier can submit bids for multiple Tenders.

Multiplicity: 1 to * (One-to-Many).

 A Supplier fulfills one or more PurchasingRequests.

Multiplicity: 1 to * (One-to-Many).

ApprovalCommittee

 Attributes:

 committeeId (String): Unique identifier for the committee.

31
  members (List): List of users in the committee.

 Methods:

 reviewRequest(): Reviews a purchasing request for validity.

 approveRequest(): Approves or rejects the request based on set criteria.

 Relationships:

 One ApprovalCommittee oversees multiple PurchasingRequests.

Multiplicity: 1 to * (One-to-Many).

Tender

 Attributes:

 tenderId (String): Unique identifier for the tender.

 tenderDetails (String): Description of the tender.

 openDate (Date): Opening date for tender submissions.

 closeDate (Date): Closing date for tender submissions.

 Methods:

 postTender(): Publishes a new tender notice.

 evaluateBids(): Evaluates and selects winning suppliers.

Relationships:

 One Tender can have multiple Suppliers submitting bids.

Multiplicity: 1 to * (One-to-Many).

Inventory

 Attributes:

32
  itemId (String): Unique identifier for an inventory item.
 itemName (String): Name of the inventory item.
 quantityInStock (int): Number of items currently available.
 qualityStatus (String): Quality status of the item (e.g., Verified, Rejected).
 Methods:
 update Stock(): Updates inventory levels after procurement.
 verifyItemQuality(): Checks quality and specification compliance.
 Relationships:
 Multiple PurchasingRequests are linked to Inventory updates.
Multiplicity: *** to 1 (Many-to-One) **.

2.3.9 LOGIC MODEL

Below is the algorithm/pseudo code for each key process in the Android-Based Online
Purchasing Management System. Each process is broken down into steps to explain the
system's logic.

1. User Authentication Process

Purpose: Verifies user credentials and grants role-based access.

Pseudo Code:
Algorithm User Authentication (username, password)
Input: username, password
Output: Authentication status and role-based access

BEGIN
Connect to the database
Search for username in the Users table
IF username exists THEN
Compare entered password with the stored password
IF passwords match THEN
Fetch the user's role (e.g., Admin, Supplier, etc.)
Grant access to the appropriate dashboard based on role
RETURN "Authentication successful, Role: [User's Role]"

33
 ELSE
RETURN "Authentication failed: Incorrect password"
ENDIF
ELSE
RETURN "Authentication failed: User not found"
ENDIF
END

2. Purchase Request Submission

Purpose: Allows users to submit requests for purchasing items.
Pseudo Code:
Algorithm SubmitPurchaseRequest(userId, itemDetails, quantity, justification)
Input: userId, itemDetails, quantity, justification
Output: Request submission status

BEGIN
Validate userId
IF userId is valid THEN
Create a new request record
Assign a unique requestId
Store itemDetails, quantity, justification, and current date in the database
Set the request status to "Pending"
Notify the user of successful submission
RETURN "Request submitted successfully with Request ID: [requestId]"
ELSE
RETURN "Invalid user ID"
ENDIF
END

3. Approval Workflow
Purpose: Routes purchase requests to the approval committee for validation.

34
Pseudo Code:
Algorithm ApproveRequest(requestId, committeeId, budget)
Input: requestId, committeeId, budget
Output: Approval status

BEGIN
Fetch request details using requestId
Validate budget against request amount
IF budget is sufficient THEN
Update the request status to "Approved"
Notify the purchasing team for further action
RETURN "Request Approved"
ELSE
Update the request status to "Rejected"
Notify the user of rejection with reason
RETURN "Request Rejected: Insufficient budget"
ENDIF
END

4. Tender Management
Purpose: Posts tenders and evaluates supplier bids.
Pseudo Code:
Algorithm ManageTender(tenderId, tenderDetails, openDate, closeDate)
Input: tenderId, tenderDetails, openDate, closeDate
Output: Tender posting and bid evaluation

BEGIN
Post tender notice with tenderDetails, openDate, and closeDate
Notify registered suppliers of the tender
WAIT until closeDate for bid submissions

35
 Evaluate bids:
FETCH all bids submitted for tenderId
Sort bids based on price, quality, and delivery time
Select the bid with the best value
Register the winning supplier
Notify the winning supplier and update tender status
RETURN "Tender completed with Winner: [supplierId]"
END

5. Inventory Update
Purpose: Updates inventory levels after procurement and performs quality checks.
Pseudo Code:
Algorithm Update Inventory(itemId, quantity, qualityStatus)
Input: itemId, quantity, qualityStatus
Output: Inventory update status

BEGIN
Fetch inventory details using itemId
Validate the qualityStatus of received items
IF qualityStatus is "Pass" THEN
Add quantity to the existing inventory
Update inventory record
RETURN "Inventory updated successfully"
ELSE
RETURN "Quality check failed: Items rejected"
ENDIF
END

6. Report Generation
Purpose: Generates reports for stakeholders based on purchasing activities.
Pseudo Code:

36
 Algorithm Generate Report(report Type, date Range)
Input: report Type (e.g., Requests, Approvals, Inventory), date Range
Output: Requested report

BEGIN
SELECT data from the database based on report Type and date Range
IF data exists THEN
Format the data into a readable report (e.g., PDF, Excel)
RETURN "Report generated successfully"
ELSE
RETURN "No data available for the selected criteria"
ENDIF
END

2.4 NON-FUNCTIONAL REQUIREMENT

The non-functional requirements define the quality attributes of the Android-Based
Online Purchasing Management System. These requirements ensure the system operates
effectively and meets user expectations in terms of performance, reliability, security, and
usability.
Performance
Response Time: The system must respond to user requests (e.g., login, submitting
requests, fetching reports) within 3 seconds under normal load.
Concurrent Users: The system should support at least 100 concurrent users without
degradation in performance.
Scalability: The system should be scalable to handle increased traffic and data volumes as
the number of users and operations grows.
Reliability
Uptime: The system must maintain 99.9% availability, ensuring minimal downtime.
Fault Tolerance: The system should recover automatically from minor faults, such as
temporary database connection loss, without impacting users.
Backup: Automated backups of the database must be performed daily to prevent data loss.

37
 Error Handling: The system must provide clear and informative error messages for
unexpected issues, guiding users to resolve them.
Security
Authentication: All users must log in using unique credentials, and passwords must be
stored using secure encryption (e.g., SHA-256).
Authorization: Role-based access control must ensure that users only access
functionalities and data relevant to their roles (e.g., admin, supplier, department head).
Data Encryption: All sensitive data, including communications between the app and the
server, must use end-to-end encryption (e.g., HTTPS with TLS).
Audit Logs: Maintain detailed logs of all user actions (e.g., login, data modification) for
accountability and troubleshooting.
Data Integrity: The system must prevent unauthorized modifications to stored data
through secure database transactions.
Usability
User-Friendly Interface: The system must feature a simple, intuitive interface optimized
for Android devices, with clear navigation and error feedback.
Accessibility: The system should support accessibility features such as large fonts and
voice navigation for visually impaired users.
Localization: The system should support multiple languages, including English and the
local language, for wider usability.
Maintainability
Modularity: The system's architecture must be modular to allow easy updates or
integration of new features without affecting existing functionality.
Documentation: Comprehensive documentation (e.g., user manuals, developer guides)
must be available to facilitate maintenance and user training.
Error Logging: Maintain logs of system errors to simplify debugging and improve future
updates.

Portability
Device Compatibility: The system must work on Android devices running version 8.0
(Oreo) or higher.

38
 Server Independence: The backend should be hosted on a cloud platform to ensure
portability and scalability
Availability
Offline Mode: The system should allow users to submit basic requests offline and sync
them automatically when connectivity is restored.
Redundancy: Utilize redundant servers to ensure uninterrupted service in case of hardware
failure.
Scalability
The system must accommodate future increases in data, users, and transactions without
significant architectural changes.
Cloud hosting must allow on-demand scaling of computational resources.
Error Tolerance
The system must detect and recover from unexpected failures (e.g., invalid input,
connectivity loss) without crashing.
User-friendly error messages must provide guidance to users on corrective actions.

2.5. SYSTEM REQUIREMENT

2.5.1. HARDWARE REQUIREMENTS
Server-Side Hardware Requirements

Hardware Minimum Specification Recommended Specification

Component
RAM 8 GB 16 GB or higher
Hard Disk 256 GB SSD 512 GB SSD or higher
(Storage)
Network 1 Gbps Ethernet Port 10 Gbps Ethernet Port
Interface
Operating Windows Server 2019 Latest stable versions ( Windows)
System
Database MySQL 5.7 or higher MySQL 8.0 or higher
Server

39
 Backup External HDD, 1 TB Cloud storage with redundancy
Storage

2. Client-Side Hardware Requirements

Hardware Component Minimum Specification Recommended Specification

RAM 2 GB 4 GB or higher
Internal Storage 16 GB 32 GB or higher
Display 5-inch screen, 720p resolution 6-inch or larger, Full HD+ (1080p)
Battery 3000 mAh 4000 mAh or higher
Operating System Android 8.0 (Oreo) or higher Android 10.0 or higher
Internet 3G connectivity 4G or Wi-Fi connectivity

2.5.2 SOFTWARE REQUIREMENTS

The following table outlines the software requirements necessary for the successful deployment
and operation of the Android-Based Online Purchasing Management System.

1. Server-Side Software Requirements

Software Component Minimum Specification Recommended

Specification
Operating System Windows Server 2019 Latest stable version of
Windows
Database Management MySQL 5.7 or higher MySQL 8.0 or higher
System (DBMS)
Web Server Apache 2.4 Apache 2.4 with
mod_security
Backend Framework PHP 7.4 or higher PHP 8.0
Programming Language PHP, Java PHP 8.0 (for backend)
IDE/Text Editor Visual Studio Code / Sublime Visual Studio Code with
Text extensions

40
 Backup Software Rsync or BackupPC for Cloud-based backup
Windows Backup solution

2. Client-Side Software Requirements

Software Minimum Specification Recommended Specification

Component
Mobile OS Android 8.0 (Oreo) or higher Android 10 or higher
Mobile Framework Android SDK 30 or higher Android SDK 33 or latest stable
version
Mobile Application APK compatible with Android Optimized for Android 10+
8.0+

3. Development Tools

Tool Specification
Version Control GitHub
Build Tool Gradle (for Android)
Testing Tools JUnit
API Development Postman
Containerization Docker for packaging and deploying services
Monitoring Tools Prometheus / Grafana

2.6. ABSTRACTION WITH CRC ANALYSIS

Class Responsibility Collaborator (CRC) Analysis is a structured approach used to identify key
abstractions (classes) in a system. This method helps define the responsibilities of each class and
how they collaborate with other classes. For the Android-based Online Purchasing
Management System, the key abstractions, responsibilities, and collaborators are identified as
follows:

41
Classes and CRC Analysis
Class Responsibilities Collaborators
User Authenticate users via login AuthenticationManager,
credentials. - Manage user roles (e.g., PurchaseRequest, Notification
administrator, requester).
PurchaseRequest Create and track purchase requests. - User, ApprovalCommittee,
Store details such as item type, Notification
quantity, and specifications.
ApprovalCommittee Approve or reject purchase requests. PurchaseRequest, Notification
Verify budget availability for
requests.
Notification Send alerts and updates to users. User, PurchaseRequest,
Notify about approval or rejection of ApprovalCommittee
requests.
Administrator Manage system users and assign User, AuditLog
roles.
Monitor system activities.
AuditLog Record system activities for security Administrator, User
and compliance.
Supplier Submit quotations and participate in PurchaseRequest,
tenders. QualityAssurer
Provide details for delivered items.
QualityAssurer Validate the quality of supplied Supplier, PurchaseRequest
goods.
ReportGenerator Generate detailed procurement and PurchaseRequest,
usage reports. ApprovalCommittee, User
Explanation of CRC Elements

1. Classes: Represent the primary abstractions in the system, such as users, requests, or
notifications.

42
 2. Responsibilities: Define what the class is accountable for in terms of the system's
functionality.
3. Collaborators: Identify other classes with which a class interacts to fulfill its
responsibilities.

Example CRC Card for "PurchaseRequest" Class

 Class Name: PurchaseRequest

 Responsibilities:
1. Accept input for new purchase requests.
2. Maintain records of request status (e.g., pending, approved, rejected).
3. Notify the approval committee and requestor of updates.
 Collaborators:

 User
 ApprovalCommittee
 Notification


2.6.1 CONCEPTUAL MODELING : CLASS DIAGRAM

43
 view
admnistrator
1 *
+id:int register
+name:string purchasing team supplier
campus directorate +password:int
+id:int 1 +id:int
1 +id:int
+reg_emp() +name:string +fname:string
permit +name:string
+createaccount() +password:int +lname:string
+password:int
+reg_campus() +post_notice() +email:string
+submit_req() +itemtype:string
+regist_dep() +register_winner() *
+register_model20() +itemmodel:string
+regis_office() +open_bid()
* 1 +quantity:string
+reactivateaccount() 1
1 +blockaccount() 1 +uit_Price:string
model20 has
+take backup() +total_price:string 1..*
+withdraw_requistion +viewaccount() +applytender()
_no:int +viewlogfile() +view_tenderesul()
+request_no:int has 1 1 1 *
approvalcommite create
requester_body:string submit 1 1
+item_type:string has has
+id:int account 1
+quantity:string +name:string * 1 quality assurer
+permition() +password:int department head +user_id:id
request +id:int
+approve() * 1 1 +user_name:string 1
+name:string
1 +reject() +id:int request
+id:int
1 has +password:string
+password:int
+name:string +role:string
1 +type:string
+password:int status:string +quality()
1..* +specification:strin
g +login()
approve/reject +request() store
+specification:sting * +loout()
+request_date:strin view 1
has 1 1
g
1 1has purchasing
take school dean directorate
+store() property admn_team
check
1 +id:varchar(20) +id:int +id:int
finance officer request +name:varchar(20) +name:string +name:string
1 +password:varchar(20) +password:int +password:int
+id:varchar(20) +request() +reg_item() +view_req()
+name:varchar(20) view_req() 1 +post_notice()
+password:varchar(20) 1 1
+viewmodel19() view
register *
+viewtenderresult() 1
item
model19 *
1 * +item_id:int
view +recipt_no:int +model:sting
model22 +item_type:string *
register +type:string
+model_quantity:int *
+receipt_no:int +unit_price:int
+item_type:string +total_price:int
+order_no:int +store()
quantity:string *
+model:string register
withdraw
+withdraw()
1
take

Figure 2.10: class diagram for relationship behavior

44
REFERENCES

Woldia University purchasing Office

https://www.geeksforgeeks.org/unified-modeling-language-uml-introduction/

45