MIZAN TEPI UNIVERSITY

TEPI CAMPUS
SCHOOL OF COMPUTING AND INFORMATICS
DEPARTMENT OF INFORMATION SYSTEMS

Industrial Project On: QR-Based Fixed Asset Management System

For Mizan Tepi University Property Management Office
Name ID-NO.

1.Tola Hussein-----------------------------------------------------------------NSR/1644/13
2. Chalo Mitiku----------------------------------------------------------------NSR /0466/13
3. Adane Kassa-----------------------------------------------------------------NSR /0105/13
4.Dibora Endalu--------------------------------------------------------------NSR/0562/13
5.MuluneshMeseret------------------------------------------------------------NSR /1297/13

Project advisor: Mr.Demeke.A

Mr. Biruk.
FINAL PROJECT DOCUMENT SUBMITED TO DEPARETEMENT OF IS IN PARTIAL
FULFILLEMENT OF THE REQUIREMENTS FOR THE DEGREE OF BACHELOR OF

SCIENCE IN INFORMATION SYSTEMS

Submitted to Senior Project Coordinator

February 04, 2024

Tepi, Ethiopia
 QR-Based Fixed Asset Management System for MTU

Declaration
This is to certify that the final year industrial project prepared by name of Tola Hussein,Chalo
Mitiku,Adane Kasse,Dibora Endalu and Mulunsh Meseret titled: QR-based Fixed Asset
Management System for MTU Property Management Office and submitted in partial
fulfillment of the requirements for the Bachelor of Science Degree in Information Sysytems
complies with the regulations of the University and meets the accepted standards concerning
originality and quality.

Name Signature Date

Name _____________________ __________ __________

Name _____________________ ___________ __________

Name _____________________ ___________ __________

Name _____________________ ___________ __________

Name_____________________ __________ __________

DEPARTMENT OF INFORMATION SYSTEMS Page i

 QR-Based Fixed Asset Management System for MTU

To: Information Systems Department

Subject: Industrial Project Submission

This is to certify that the industrial project entitled “QR-based Fixed Asset Management
System for MTU submitted in partial fulfilment of the requirements for the degree of
Bachelor of Science in Information systems, has been carried out by the group members
under my supervision. Therefore, I recommend that the students has fulfilled the
requirements and hence hereby they can submit the project to the department

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

Name of Advisor Signature Date

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

Name of Advisor Signature Date

DEPARTMENT OF INFORMATION SYSTEMS Page ii

 QR-Based Fixed Asset Management System for MTU

Approval Page

It is approved that this project has been written in compliance with the formatting rules laid
down by the faculty.

Examiners

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

Examiner 1 Signature Date

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

Examiner 2 Signature Date

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

Examiner 3 Signature Date

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

-

Chairman Signature Date

DEPARTMENT OF INFORMATION SYSTEMS Page iii

 QR-Based Fixed Asset Management System for MTU

Acknowledgment
First of all, we would like to thank GOD for keeping us healthy to do this project. Next
thanks to our adviser Mr. Demeke .A for his advice, and guidance and gives necessary
comments until the completion of the documentation of the project. Would like to say thanks
to Mizan Tepi University property management office employees for giving us information
about how the current system work. Finally, thanks to group members and other people who
support us in our project document completion.

DEPARTMENT OF INFORMATION SYSTEMS Page iv

 QR-Based Fixed Asset Management System for MTU

Table of Contents
Acknowledgment ...................................................................................................................... iv

list Of Tables .......................................................................................................................... viii

list Of Figure ............................................................................................................................. ix

Abstract ...................................................................................................................................... x

Abbreviations and Acronyms ................................................................................................... xi

Chapter One ............................................................................................................................... 1

1. Introduction ........................................................................................................................ 1

1.1. Background of Mizan-Tepi University ....................................................................... 1

1.1.1. Vision ................................................................................................................... 2

1.1.2. Mission................................................................................................................. 2

1.2. Background of the Study ............................................................................................. 2

1.3. Motivation ................................................................................................................... 3

1.4. Statement of Problems ................................................................................................ 3

1.5. Objectives .................................................................................................................... 4

1.5.1. General Objective of project ................................................................................ 4

1.5.2. Specific Objective of the Project .......................................................................... 4

1.6. Scope and Limitation of the Project ............................................................................ 4

1.6.1. Scope of the Project ............................................................................................. 4

1.6.2. Limitations of the Project..................................................................................... 4

1.7. Methodology ............................................................................................................... 5

1.7.1. Data Gathering Methodology .............................................................................. 5

1.7.2. The System Analysis and Design Approaches .................................................... 5

1.7.3. The System Development Model......................................................................... 6

1.8. Development Tools and System Requirements .......................................................... 6

DEPARTMENT OF INFORMATION SYSTEMS Page v

 QR-Based Fixed Asset Management System for MTU

1.8.1. Hardware Requirement ........................................................................................ 6

1.8.2. Software Requirement ......................................................................................... 6

1.8.3. Programming and Database Tool: ....................................................................... 7

1.9. Feasibility study .......................................................................................................... 7

1.9.1. Technical Feasibility ............................................................................................ 7

1.9.2. Operational Feasibility ......................................................................................... 8

1.9.3. Economic Feasibility ........................................................................................... 8

1.9.4. Political Feasibility .............................................................................................. 8

1.9.5. Schedule Feasibility ............................................................................................. 8

Beneficiaries of the Project .................................................................................................... 9

1.10. Required Resources with Costs ............................................................................. 10

1.11. Team Composition ................................................................................................ 10

1.12. Significance of the Project ..................................................................................... 11

Chapter Two............................................................................................................................. 12

2. Description of Existing System ....................................................................................... 12

2.1. Existing System Description ..................................................................................... 12

2.2. Players in the existing system ................................................................................... 12

2.3. Functions / Activities of the existing system. ........................................................... 13

2.4. Business Rules........................................................................................................... 13

2.5. Bottlenecks of the Existing System ........................................................................... 14

2.5.1. Performance (Response time) ............................................................................ 14

2.5.2. Input (Inaccurate/redundant/flexible) and Output (Inaccurate) ......................... 14

2.5.3. Security and Controls ......................................................................................... 15

2.5.4. Efficiency ........................................................................................................... 15

2.6. Documents and Forms in the existing system ........................................................... 16

Chapter Three........................................................................................................................... 19

3. Proposed System Modelling ............................................................................................ 19

DEPARTMENT OF INFORMATION SYSTEMS Page vi

 QR-Based Fixed Asset Management System for MTU

3.1. Proposed System Requirement Specification ........................................................... 19

3.2. Functional Requirements........................................................................................... 19

3.3. Actors and use case identification ............................................................................. 20

3.3.1. Actor identification ............................................................................................ 20

3.1.3.2 Use case identification ......................................................................................... 20

3.3.2. Use case diagram ............................................................................................... 21

3.3.3. Use Case Description ......................................................................................... 22

3.3. Nonfunctional Requirements..................................................................................... 36

3.4. Sequence Diagram..................................................................................................... 37

3.5. Activity Diagram ....................................................................................................... 41

Chapter Four ............................................................................................................................ 45

4. System Design ................................................................................................................. 45

4.1 . Introduction ............................................................................................................. 45

4.2. Design Goal ............................................................................................................... 45

4.3. Current Software Architecture .................................................................................. 46

4.4. Proposed Software Architecture................................................................................ 46

4.5. Overview of the System ............................................................................................ 47

4.6. Subsystem Decomposition ........................................................................................ 48

4.7. Hardware/Software Mapping (Deployment Diagram) .............................................. 49

4.8. Persistence Data Management .................................................................................. 50

4.9. Class Diagram ........................................................................................................... 51

4.10. State Diagram ........................................................................................................ 53

4.11. Access Control and Security.................................................................................. 55

4.12. Global Software Control ........................................................................................ 56

4.13. Boundary Conditions ............................................................................................. 57

4.14. Subsystem Services ............................................................................................... 57

References ................................................................................................................................ 59

DEPARTMENT OF INFORMATION SYSTEMS Page vii

 QR-Based Fixed Asset Management System for MTU

LIST OF TABLES
Table 1. Times Schedule ........................................................................................................... 8
Table 2.Resource cost .............................................................................................................. 10
Table 3.Team Composition ...................................................................................................... 10
Table 4 use case descreption ................................................................................................... 22
Table 5 Login use case description .......................................................................................... 23
Table 6 Approve request description ...................................................................................... 24
Table 7 Register asset use case documentation ....................................................................... 25
Table 8 Prepare feedback use case documentation .................................................................. 26
Table 9 View report use case documentation .......................................................................... 27
Table 10 View asset information use case documentation ...................................................... 28
Table 11 Withdrawal asset use case documentation ................................................................ 29
Table 12 Generate report use case documentation .................................................................. 30
Table 13 Prepare request use case documentation ................................................................... 31
Table 14 Prepare problem report use case documentation ...................................................... 32
Table 15 View feedback use case documentation ................................................................... 33
Table 16 View problem report use case documentation .......................................................... 33
Table 17 Create user account use case description .................................................................. 34
Table 18 Approve request description ..................................................................................... 35
Table 19 Access control table .................................................................................................. 55

DEPARTMENT OF INFORMATION SYSTEMS Page viii

 QR-Based Fixed Asset Management System for MTU

LIST OF FIGURE

Figure 1 Model 19 .................................................................................................................... 16

Figure 2 Model 22 .................................................................................................................... 17
Figure 3 Bin card ..................................................................................................................... 18
Figure 4 Use Case Diagram .................................................................................................... 21
Figure 5 Login sequence diagram ............................................................................................ 37
Figure 6 Approve request sequence diagram ........................................................................... 38
Figure 7 Register asset sequence diagram ............................................................................... 39
Figure 8 Sequence Diagram for logout .................................................................................... 40
Figure 9 Login activity diagram .............................................................................................. 41
Figure 10 Approve request activity diagram .......................................................................... 42
Figure 11 Create an account activity diagram ........................................................................ 42
Figure 12 Register asset activity diagram ............................................................................... 43
Figure 13 Withdraw asset activity diagram ............................................................................ 43
Figure 14 Prepare request activity diagram ............................................................................ 44
Figure 15 Software architecture ............................................................................................... 47
Figure 16 Proposed system architecture ................................................................................. 48
Figure 17 Subsystem decomposition ..................................................................................... 49
Figure 18 Deployment diagram ............................................................................................... 50
Figure 20 Class Diagram ......................................................................................................... 52
Figure 21 Login State Diagram................................................................................................ 53
Figure 22 Register Assets State diagram ................................................................................. 54
Figure 23 Prepare Request State diagram ................................................................................ 54

DEPARTMENT OF INFORMATION SYSTEMS Page ix

 QR-Based Fixed Asset Management System for MTU

Abstract
An asset is something that belongs to and is used by the MTU for administration, instruction,
and study. The current fixed asset management method is labor-intensive and manual. All
fixed asset management tasks at MTU Property Management Office are manual, so this
procedure requires excessive labor. Data manipulation and handling are not secure and easily
susceptible to harm. Each item has the model numbers carefully written on it as well. This
system aims to provide solutions to such issues using the latest technologies and practices
relevant to Fixed Assets maintenance & reporting. Due to its web-based, registration and
tracking with QR codes, the developed system is quick and easy to use. Fixed asset
administration with QR codes would help the MTU property management office. While the
asset management component enhances the accountability and openness MTU Property
Management Office has over its assets, using QR asset labels speeds up and automates its
processes. MTU property management office can move its possessions much farther with a
QR-based asset management system.

DEPARTMENT OF INFORMATION SYSTEMS Page x

 QR-Based Fixed Asset Management System for MTU

Abbreviations and Acronyms

MTU: - Mizan Tepi University

QR: - Quick Response

GB: - Giga Byte

PC: -Personal Computer

HTM : -Hypertext Markup Language

CSS: -Cascading Style sheet

MySQL: - My Structured Query Language

PHP: - Hyper Text Pre-processor

URL:- Uniform Resource Locators

UML: - Unified Modeling Language

WAMP: - cross-platform, Apache, MySQL, PHP, and Perl

DEPARTMENT OF INFORMATION SYSTEMS Page xi

 QR-Based Fixed Asset Management System for MTU

Chapter One
1. Introduction
When we talk about fixed assets, we're talking about material possessions that belong to the
institution and aren't meant for sale or use right away. Typically purchased for long-term use,
these resources support the university's capacity to perform its administrative and
instructional duties. Vehicles, computers, furniture, and tools are examples of fixed assets.
Businesses can track and keep an eye on their permanent assets by using an asset
management system.The value of an organization's fixed assets represents fairly a
considerable proportion of its total value. Misstatements, incorrect presentations, and
misappropriation of fixed assets would lead to collapses and dilution of the company's
goodwill and its presence in the market. Hence it is of utmost importance for companies to
have better control of their fixed assets portfolio using the newest technologies.This system
aims to provide solutions to such issues using the latest technologies and practices relevant to
Fixed Assets registration and tracking. QR code for each Asset is generated at the time of
registration. With QR codes, you don't need to purchase bulky machinery. You can simply
use smartphone devices or tablets to scan the QR codes tagged in your equipment, access the
data, and manage your assets at your disposal. The QR code can be placed anywhere on a
smooth surface that envelops the equipment for an easy scan. Asset management system
although demands a lot of data entry, changing, or removing records of assets, they don't
have to be a long and painstaking process. With the help of QR codes, users can make their
operations automatic. Integrating QR codes is one way to optimize and promote a smooth and
seamless transaction of your asset management and tracking system and allows you to have
direct access to and track the asset information.

1.1. Background of Mizan-Tepi University

Mizan-Tepi University is one of the Universities in Ethiopia which is found in south nation,
nationalities and peoples region. It is located at Mizan-Teferi, where the main campus is, and
Tepi town 565kms & 578kms respectively at southwest of Addis Ababa, in the deep and
unique natural and anthropogenic diversity.The University started teaching and learning in
2006 by sharing building for University administration offices from Mizan Agriculture
technical and vocational college by admitting few regular students in college of social science
and humanities at Mizan Campus. By the time the university started its operation, there were

DEPARTMENT OF INFORMATION SYSTEMS Page 1

 QR-Based Fixed Asset Management System for MTU

only 215 students attending their first degree classes. Among this number of students, for the
first time, 138 students had graduated colorfully in July 2008/09.

This University gives different courses in different faculties under different departments.
Among these faculties school of computing and informatics is one which has three
departments. Among these department Information Systems is the one in which we are going
to develop a web-based application to the office of Construction Management office (project
office).

1.1.1. Vision
Mizan-Tepi University aspires to be the leading higher educational institution being center of
excellence in education and research in areas of natural resources and cultural value
utilization for development

1.1.2. Mission
Mizan-Tepi University has a mission of supporting the development endeavors of the people
by tackling the insistent problems by utilizing natural resources and cultural values, through
inculcating scientific knowledge and skills relevant to the country and assuring quality
education.

1.2. Background of the Study

The ability for users to act on the information they receive has been revolutionized by the use
of the Internet and the World Wide Web. The MTU can easily access and secure its data by
using the Internet. At MTU, there is a need for an automated method of processing and
monitoring various existing manual or paper-based systems. The fixed asset management
system is one of these systems that need to be automated in the university. This system is
designed to make it easier for the university to manage its assets. In general, our project aims
to create a web-based fixed asset management system for MTU Property Management Office
that registers items, tracks items, and withdraws items by using QR codes.

DEPARTMENT OF INFORMATION SYSTEMS Page 2

 QR-Based Fixed Asset Management System for MTU

1.3. Motivation
To improve asset management efficiency and save time and materials that are difficult to
destroy, we are interested in creating a QR-based fixed asset management system for the
MTU Property Management Office.QR codes offer a quick and efficient way to track and
manage fixed assets. Implementing a QR-based system can automate the process of updating
asset information, reducing manual data entry and associated errors. Automation through QR-
based asset management can lead to cost savings by reducing the time and effort spent on
manual tracking. It also helps in optimizing the use of resources by preventing unnecessary
purchases through better visibility into the existing asset inventory.Considering that the
University's fixed asset management system now operates solely through manual .
Consequently, this lowers the effectiveness of asset management and makes it harder for us
to create this system due to over-activation. Cost control and optimization: By tracking asset
usage, maintenance, and depreciation, organizations can optimize asset utilization, reduce
maintenance costs, and make informed decisions about asset replacement or disposal.

Risk mitigation: Effective asset management helps organizations identify and mitigate risks
related to asset loss, theft, damage, or regulatory non-compliance.

1.4. Statement of Problems

The Property Management Office at MTU currently uses a manual fixed asset management
system that is based on paper-based procedures with handwritten asset details in markers. The
university has several difficulties with this manual method, especially in the fixed asset
management office. Manual labor is used to complete tasks, which reduces overall efficiency
and delays the timely delivery of vital information. It becomes difficult to retrieve relevant
records, which impedes prompt access to important data. Additionally, the risk of data loss
from insufficient data storage techniques is increased when paper-based systems are used.
Fixed asset models are manually documented with markers under the current asset
management system, wasting time and expensive resources in the process. The distribution of
information and problems with access lead to property losses, which hinder the asset
management process. The deployment of an automated and efficient fixed asset management
system at MTU is important in order to meet these issues. Through this shift, the university's
asset management departments would experience less difficulty in the short term due to
increased efficiency and data integrity.

DEPARTMENT OF INFORMATION SYSTEMS Page 3

 QR-Based Fixed Asset Management System for MTU

1.5. Objectives

1.5.1. General Objective of project

The general objective of the project is to develop a QR-based fixed asset management system
for the MTU property management office.

1.5.2. Specific Objective of the Project

To achieve the above aforementioned general objective, the project also address the
following specific:

 Understanding the problem of the existing system.

 Collecting relevant data and providing means of analyzing data.
 Perform requirement analysis.
 Design the system architecture for the proposed system.
 Develop a prototype (model) for a QR-based fixed asset management System by
using object-oriented modeling.
 Generate/create a QR code for fixed assets.

1.6. Scope and Limitation of the Project

1.6.1. Scope of the Project

The scope of the project is managing the fixed asset in a simple, effective, and useful manner
is the main focus of the project. The system's analysis with regard to client engagement is
equally fascinating.

This project mainly focuses on identifying the existing problem of the MTU fixed
management system and designing an alternative solution for the problem.

The system is targeted at MTU Property Management Office and does not include any other
university's asset management system.

Due to security precautions, only authorized users can view a specific proportion of the
content of this web-based application depending on their level of system access.

1.6.2. Limitations of the Project

System limitations are restrictions because of which the system cannot function:

The project is not capable of distributing assets on its own. Asset distribution needs human
intervention and authorized personnel coordination.
DEPARTMENT OF INFORMATION SYSTEMS Page 4
 QR-Based Fixed Asset Management System for MTU

Additionally, our system is unable to focus on internet asset purchases.

1.7. Methodology

1.7.1. Data Gathering Methodology

We use two data collection methods to collect the data needed for the team project those
are:

Primary data collection method

Observation: To gather relevant information the project team were observed how the current
system works.

Interview: We questioned asset management personnel in order to obtain information using

this strategy.

Secondary data collection methods

Document analysis: The team working on the project made an effort to find written records
detailing how they handle project-related assets.

1.7.2. The System Analysis and Design Approaches

The goal of this section is to provide a basic overview of the system that we are going to
develop. For the system analysis and design approaches for this project, we used object-
oriented system analysis & design. Because:

It provides code and function reuse through the concepts of inheritance, polymorphism,
encapsulation, modularity, coupling, and cohesion.

To design the system, the project team has to choose Object Oriented Modeling techniques
and UML tools.

Understanding the structure is easy because object-oriented modeling and tools are used to
represent real-world entities.

It enables us to comprehensively model a system before we develop it.

Modification of the object implementation is easy because objects are loosely coupled.

DEPARTMENT OF INFORMATION SYSTEMS Page 5

 QR-Based Fixed Asset Management System for MTU

1.7.3. The System Development Model

There are various software development life cycle models defined and designed which are
followed during the software development process. These models are also referred to as
"Software Development Process Models". Each process model follows a Series of steps
unique to its type to ensure success in the process of software development. However, the
proposed system follows the Iterative model. Because to design our project we are required to
review and redesign each phase iteratively to meet user requirements. The basic idea behind
this method is at each iteration design modifications are made and new functional capabilities
are added

Generally, we choose the iterative model because of:

The iterative model is the simplest model of software development tools.

Parallel development can be planned.

Risks are identified and resolved during iteration.

Testing and debugging during smaller iterations are easy.

The iterative model is the simplest model of software development tools.

1.8. Development Tools and System Requirements

1.8.1. Hardware Requirement

The hardware tools needed to complete the proposed system are:

PC: almost all tasks of our project are performed on a computer.

Flash disk (8GB): required for data movement to store & transfer data from one PC to
another PC.

Stationeries (pen, paper): for writing all necessary documentation associated with the project.

Notebook: to take notes during data collection and for another document.

1.8.2. Software Requirement

Windows Operating system: used for the system since it is readily available in laboratories.

Browser: Since our system is web-based, it is a very necessary requirement

DEPARTMENT OF INFORMATION SYSTEMS Page 6

 QR-Based Fixed Asset Management System for MTU

Microsoft Office Word 2016: for documenting the corresponding deliverables associated with
the project.

Editor (Sublime): To edit the entire implementation code.

XAMPP (cross-platform, Apache, MySQL, PHP, and Perl)

Visual Paradigm for UML: To draw UML diagrams

Snipping tools: to screen shoot the picture

EdrawMax: is an open-source software modeling tool that supports UML model diagrams.

1.8.3. Programming and Database Tool:

HTML: - provides the structure of the page

CSS: -describes how HTML elements are to be displayed on screen, paper, or in other media.

JavaScript: - used to validate our data or for client-side scripting.

Bootstrap: - for developing the responsive user interface.

PHP: - for the server-side script.

MySQL (a standard language for accessing databases).

1.9. Feasibility study

A feasibility study is a preliminary exploration of a proposed project or undertaking to
determine its merits and viability. A feasibility study aims to provide an independent
assessment that examines all aspects of a proposed project.

1.9.1. Technical Feasibility

The system created using a well-known programming language like PHP, JavaScript,
bootstrap, CSS, and a MySQL database and can function with the hardware and software of
an existing computer system. So that team members would be able to comprehend concepts
without difficulty and have the necessary skills to develop this project. Therefore, the
system we suggest is feasible.

DEPARTMENT OF INFORMATION SYSTEMS Page 7

 QR-Based Fixed Asset Management System for MTU

1.9.2. Operational Feasibility

The system would be built with operational viability in mind. If it is launched, the system
would perform flawlessly across all platforms. The new system is usable, reliable,
maintainable, supportable, and problem-solving from an operational standpoint.

1.9.3. Economic Feasibility

Economic Feasibility is a measure of how cost-effective the proposed solution will be. We
would develop the proposed system at a minimum cost at a lower price. To identify the
economic feasibility of the project the team has done a cost-benefit analysis which enables it
to specify the benefits and costs associated with the project. Therefore, our project is
economically feasible.

1.9.4. Political Feasibility

The system that will be created provides services to users without opposing governmental
initiatives, thus it does not contradict any official mandates.

1.9.5. Schedule Feasibility

Schedule feasibility is making sure whether the potential time frames and Completion date
can meet or not. The project team members expect the Project would be completed on time.
So, our systems would be feasible about the schedule.

Months
January February March April May June
weeks 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3
Project Proposal
Requirement Analysis

Design
Implementation
Installation and Testing

Project Closure

Table 1. TIMES SCHEDULE

DEPARTMENT OF INFORMATION SYSTEMS Page 8

 QR-Based Fixed Asset Management System for MTU

Beneficiaries of the Project

For end-users:

End-users benefit from efficient asset management by having access to the tools and
equipment they need for their work.

The system ensures that assets are available when and where they are needed, reducing
delays and disruptions.

End-users can focus on their tasks without disruptions caused by equipment failures or
unavailability.

A well-managed asset system contributes to increased productivity as employees can rely on

the availability and reliability of necessary assets.

Asset management systems help in proactive maintenance and timely repairs, reducing the
chances of unexpected breakdowns.

This minimizes downtime for end-users who rely on assets to carry out their responsibilities.
End-users benefit from user-friendly interfaces that make it easy to interact with the asset
management system.

Intuitive interfaces reduce the learning curve and make it simpler for employees to request,
use, or report issues related to assets.

By providing a clear understanding of asset availability and conditions, the system minimizes
friction in asset use.

End-users can rely on the system to know which assets are suitable for their tasks, reducing
the time spent searching or waiting for equipment

DEPARTMENT OF INFORMATION SYSTEMS Page 9

 QR-Based Fixed Asset Management System for MTU

1.10. Required Resources with Costs

NO Material Amount Price per unit

1 Personal Computer 1 45,000

2 Flash disk 1 500

3 printing document -- 800

4 Paper 1 pack 2000

5 Total 48300
Table 2.Resource cost

1.11. Team Composition

This project team is composed of three males and two females. The following table shows
the background information about the project team.

No Name Sex Email Address Phone no Responsibility

1 Tola Hussien M [email protected] +251937041859 Developer
2 Chalo Mitiku M [email protected] +251927194941 System Design
3 Adane Kassa M [email protected] +251960786436 System Analysis

4 Dibora Endalu F [email protected] System Design

5 Mulunesh F [email protected] Data gathering
Meseret
Table 3.Team Composition

DEPARTMENT OF INFORMATION SYSTEMS Page 10

 QR-Based Fixed Asset Management System for MTU

1.12. Significance of the Project

We used web-based principles and QR codes to design the system, so all the data of one or
more assets would be accurately and uniformly kept for quick decision-making.

The administrator interacts with the back-end and front-end interface programs; the staff can
interact from the front-end interface only to perform the operations. All the related records
based on the process are stored accurately. The administrator is responsible to maintain and
manage the system. That means the staff's responsibility is only help to manage the system
like view manage user detail.

After implementing this project, the system would have the following benefits.

 Decision-making made easy: Further decision-makers would have the ability to

review and analyze records and support historical information in making decisions.
 Asset Tracking made easy: Since QR code is generated at the time of Asset
registration for the particular Asset. It is then pasted on the Asset. This allows better
tracking of the condition of an asset.
 QR codes would identify assets with a serial or model number. This data links to an
asset database that would retrieve asset history fast.
 Effective and Efficient mechanism for physical Asset Verification.
 To Speed up the operation.
 To reduce costs & time consumption.
 Minimize the time and effort needed to perform tasks.
 Make tasks simple and efficient in every aspect.
 Avoiding data loss because of improper data storage.

DEPARTMENT OF INFORMATION SYSTEMS Page 11

 QR-Based Fixed Asset Management System for MTU

Chapter Two

2. Description of Existing System

2.1. Existing System Description

The Property Management office is responsible for managing fixed assets at MTU. The asset
managing activities are performed manually, such as registering new assets, viewing asset
information, report generation, preparation of user requests, and distributing the asset to the
requested user.

2.2. Players in the existing system

Administration Office: The administrative office approves the letters of application that
staff members present and send to the facility.

Facility Directorate: The facility directorate will receive the application letters that workers
present and submit when they are approved by the administration office.

Property Manager: The Property Manager will also prepare Model 20 for the application
(which contains his or her name and signature, the asset information, and the department to
which the asset will be transferred) and lead it to the storeman once the administration office
and facility directorate have approved the application letters that employees present.

Fixed Asset Storeman: Fixed-asset storeman writes on bin cards and registers new assets
using Model 19 to keep track of the inventory. The storeman will transfer the assets to the
team preparing the application based on the accepted application. To calculate how many
things are still in stock, the storeman of fixed assets uses model 22 to withdraw assets and
register them.

Staff: Staffs are employees at MTU and are also users of assets from all colleges and
administrative divisions. They can write an application letter to withdraw money from the
bank or to ask for something to be bought for their institutions or departments. Before
submitting their proposal to the administration office or facility directorate, it must be signed
by their department head and college dean. When they leave college or move jobs, they will
give the asset back to property management.

DEPARTMENT OF INFORMATION SYSTEMS Page 12

 QR-Based Fixed Asset Management System for MTU

2.3. Functions / Activities of the existing system.

Asset Inventory Management: The office maintains an accurate inventory of all fixed assets
owned by the university. This includes recording asset details such as descriptions,
identification numbers, purchase dates, costs, locations, and any relevant information.

Location Tracking via QR Codes:Implement location tracking by associating QR codes

with specific physical locations. Users should be able to update asset locations by scanning
QR codes at different sites.

Asset Tracking and Movement: The office tracks the movement of assets within the
university. This includes recording transfers of assets between departments or locations,
updating the asset register accordingly, and ensuring that accurate records are maintained for
asset locations and custodians.

Reporting: The office prepares reports and documentation related to fixed assets as required.
This includes providing regular updates on asset inventory, depreciation, maintenance
activities, and disposal records.

Maintenance and Repairs: The Property Management Office may coordinate or oversee the
maintenance and repair activities for fixed assets. This involves scheduling and tracking
routine maintenance tasks, organizing repairs when needed, and ensuring that assets are kept
in good working condition.

Fixed-asset storeman registers new assets with model 19 and adds on bin cards, to know how
many items are in stock.

The Storeman of fixed assets registers assets while withdrawing with model 22 and deduct
them from the stock card to determine how many items are left in the store.

Asset users who acquire new fixed assets for their university-specific colleagues should
deliver the request to the property management office. Manage fixed assets of MTU.

2.4. Business Rules

Business rules of fixed asset management refer to the guidelines and policies that govern the
management of a company's fixed assets. Fixed assets include property, equipment, such as
electronics, machinery, vehicles, and furniture, which are used in the company's operations.

The asset users must be involved in a University.

DEPARTMENT OF INFORMATION SYSTEMS Page 13

 QR-Based Fixed Asset Management System for MTU

The staff must bring letters of application from their department.

The staff's request to withdraw the asset must have received the approval of the facility
director and property manager.

With the facility director's and property manager's permission, the fixed asset storeman may
release the assets to the staff members who represent the departments and colleges.

2.5. Bottlenecks of the Existing System

2.5.1. Performance (Response time)

 The response time of the Existing System is less.

2.5.2. Input (Inaccurate/redundant/flexible) and Output (Inaccurate)

❖ Inputs

Data is not accurately captured if it contains errors.

Input data is not validated.
Manual Data Entry: Inputting data manually into the system can be time-consuming and
error-prone, leading to inaccuracies in asset records.
Lack of Automation: Inefficient or manual processes for capturing asset data, such as
barcode scanning or RFID tagging, can slow down data entry and increase the likelihood of
errors.
Limited Data Sources: Relying on a limited number of data sources for asset information,
such as spreadsheets or paper-based records, can restrict the completeness and accuracy of
asset data.
❖ Outputs
Limited Reporting Capabilities: Insufficient reporting tools or templates for generating
meaningful insights from asset data can hinder decision-making and analysis.
Inaccurate Outputs: Errors in output reports or documents, such as incorrect asset values
or depreciation calculations, can lead to financial discrepancies and compliance issues.
Lack of Real-time Visibility: Delayed or outdated asset information in output reports can
impede real-time decision-making and proactive asset management.
Sometimes lack necessary and relevant information.
Sometimes Information is not in a useful format.

Information is not timely to its subsequent use.

DEPARTMENT OF INFORMATION SYSTEMS Page 14

 QR-Based Fixed Asset Management System for MTU

2.5.3. Security and Controls

 The existing system doesn’t provide comfort and easiness in coordination.
 Input data is not adequately edited.
 Ethics are branched on data or information – refers to data or information getting to
unauthorized people.
 Redundantly stored data is inconsistent in different files.
 Data privacy regulations or guidelines can be violated.
 Processing errors are occurring by people.
 Limited Reporting Capabilities: Insufficient reporting tools or templates for
generating meaningful insights from asset data can hinder decision-making and
analysis.

2.5.4. Efficiency
 People/human power, machines, or computers waste time
 Information is redundantly generated
 The system is inflexible to new or exceptional situations
 The system is inflexible to change
 As we observed in the existing system performing some action takes more time and a
lot of resources.

DEPARTMENT OF INFORMATION SYSTEMS Page 15

QR-Based Fixed Asset Management System for MTU

2.6. Documents and Forms in the existing system

Figure 1 Model 19

DEPARTMENT OF INFORMATION SYSTEMS Page 16

QR-Based Fixed Asset Management System for MTU

Figure 2 Model 22

DEPARTMENT OF INFORMATION SYSTEMS Page 17

QR-Based Fixed Asset Management System for MTU

Figure 3 Bin card

DEPARTMENT OF INFORMATION SYSTEMS Page 18

 QR-Based Fixed Asset Management System for MTU

Chapter Three

3. Proposed System Modelling

The proposed system for QR-based fixed asset management for MTU Property Management
Office involves using QR codes to track and manage the fixed assets owned by the university.
The system is designed to improve the efficiency and accuracy of asset management, reduce
the risk of loss or theft, and make it easier to keep track of the location and status of assets.
The system will involve attaching QR code labels to each fixed asset, which will contain
unique identifiers that are linked to a database. The database will store information about
each asset, including its location, condition, maintenance history, and other relevant data.
Overall, the QR-based fixed asset management system will provide MTU Property
Management Office with an efficient and effective way to manage its fixed assets, reducing
the risk of loss or theft, improving maintenance and inspection processes, and providing
accurate and up-to-date information about the status of assets.
ame pattern.

3.1. Proposed System Requirement Specification

System requirement is the requirements at the system level that describe the functions which
the system as a whole should fulfill to satisfy the stakeholder needs and requirements, and it
is expressed as nonfunctional requirements and functional requirements.

3.2. Functional Requirements

The functional requirements characterize the functionality of the system as follows:

 The system should grant access to the user after he provides a username and
password.
 To get that provide a username and password admin can create an account for the
users.
 The asset user (staff) can prepare the request to withdraw the asset and prepare a
problem report for the administrative officer, facility director, and property manager.
 The administration officer, facility director, and property manager approve the request
and prepare feedback for the asset user (staff).
 The system should grant to generate reports for the storeman and staff for a property
manager

DEPARTMENT OF INFORMATION SYSTEMS Page 19

 QR-Based Fixed Asset Management System for MTU

 The storeman withdraws the asset after the administration officer, facility director,
and property manager approve the prepared request with tagging QR-code on each
item of assets.

3.3. Actors and use case identification

3.3.1. Actor identification

The following is the list of actors who interact with the system

 Administration office
 Facility director
 Property Manager
 Storeman
 Staff
 Administrator

3.1.3.2 Use case identification

 Login
 Approve the request
 Manage account
 Prepare feedback
 View report
 View asset information
 Withdraw asset
 Generate report
 Register asset
 Prepare request
 Prepare problem report
 View feedback
 View the problem report
 Logout

DEPARTMENT OF INFORMATION SYSTEMS Page 20

 QR-Based Fixed Asset Management System for MTU

3.3.2. Use case diagram

In UML, use-case diagrams model the behavior of a system and help to capture the
requirements of the system. Use-case diagrams describe the high-level functions and
scope of a system. These diagrams also identify the interactions between the system
and its actors. The use cases and actors in use-case diagrams describe what the system
does and how the actors use it, but not how the system operates internally.

Figure 4 Use Case Diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 21

 QR-Based Fixed Asset Management System for MTU

3.3.3. Use Case Description

Use case description explains in detail the general flow of use case diagrams. Each
table contains the use case name, the actor that initiates and interacts with the use
case, and the flow of event that show the interaction between the actor and the use
case which enable the user to easily understand the functions of the proposed system.
Before going to a scenario of the use case we describe our systems use case.

R No Use case name Description

1 Login Uses when the user enters the system
2 Manage account Uses when the admin creates, deactivates, and activates a
user account.
3 Approve request Uses when the staff prepares a request for the administration
office, general facility director, and property manager to
withdraw the asset.

4 Register asset Uses when the storeman wants to register a new asset.
5 Prepare request Uses when the asset user prepares a request for a property
manager to take the asset.
6 Prepare report Uses when the fixed asset storeman wants to prepare the
general report for the property manager.
7 Prepare feedback Uses for when the property manager can prepare feedback
for the asset user problem.
8 View report Uses when the property manager views the report prepared
by the storeman and asset user.
9 Withdraw asset Uses when the storeman wants to withdraw an asset for the
staff.
10 Prepare problem Uses when the asset user wants to prepare a report if there is
report some problem.
11 View problem Uses when the fixed asset storeman wants to view the user's
report problem regarding assets or the system.
12 View asset info Uses when the property manager and fixed asset manager
view general asset information.
13 View feedback Uses the asset used to view the feedback prepared by the
property manager.
14 Logout Uses after the users are finished their work from the system
and close.
Table 4 use case descreption

DEPARTMENT OF INFORMATION SYSTEMS Page 22

 QR-Based Fixed Asset Management System for MTU

Use case name Login

Actors All users

Precondition The user must have an account.

Description Users who have the privilege to access the system's

functionalities

Postcondition If the user is authenticated the user logged into the

system and the system displays all features available for
the role associated with the user.

The basic flow of the Event 1. The user opens the system.
2. The system displays a login form.
3. The user fills out the login form.
4. The user clicks the login button.
5. The system validates the entered information.

6. The system authenticates information from the

database.
7. The system directs the user to their respective page.
8. The use case ends.

Alternative flow event A7.a When incorrect information is entered by the user,
then the system will display an error message A8.use
case end

Exceptional flow event E7. b Error! The database that cannot open will be
contacted to the property manager message displayed.
E8.use case end.

Table 5 Login use case description

DEPARTMENT OF INFORMATION SYSTEMS Page 23

 QR-Based Fixed Asset Management System for MTU

Use case name Approve request

Actors Administration officer, Facility director Property

manager

Description Approve requests prepared by staff

Precondition They login into their page

postcondition Approving the request of the user

The basic flow of the Event 1. They click on approve request button.
2. The system displays the report with
approve request button.
3. They click on approve request button.
4. System display you are successfully
approved request message display.
5. Use case end.

Alternative flow event A2. There is no request still now the message
display A3. Use case end.

Exceptional flow event E4. Error! The database cannot open the system
check your database message will be displayed.
E5. Use case ends.

Table 6 Approve request description

DEPARTMENT OF INFORMATION SYSTEMS Page 24

 QR-Based Fixed Asset Management System for MTU

Use case name Register assets

Actors Storeman

Description To register new asset comes to the property

Precondition Storeman log-in to the system

Powithdrawaln Register new asset

The basic flow of the Event 1. The storeman clicks on the register asset
button.
2. System display registers asset form.

3. Storeman fills out the form with the

required information.
4. The Storeman clicks on the save button.
5. The system validates the information.

6. The system displays an asset registered

successfully message will be displayed.
7. Use case end.

Alternative flow event A6. When incorrect information is entered by

the user, then the system will display an error
message.
A7. Use case ends.

Exceptional flow event E6. Error! The database cannot open contact to
property manager message will be displayed.
E7.use case end.

Table 7 Register asset use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 25

 QR-Based Fixed Asset Management System for MTU

Use case name Prepare feedback

Actors Property Manager

Description Prepare feedback for asset user

Precondition Property manager login into his/her page

postcondition Prepare feedback

The basic flow of the Event 1. The property manager clicks on prepare
feedback button.
2. The system displays a feedback form.

3. The property manager fills in all the

required info thereon.
4. The property manager clicks on Submit
button.
5. The system validates the information.

6. System display feedback prepared

successfully message will be displayed.
7. Use case end.

Alternative flow event A6. When incorrect information is entered by

the user, then the system will display an error
message.
A7. Use case ends.

Exceptional flow event E8. Error! The database cannot open check your
database message will be displayed.
E9.use case end.

Table 8 Prepare feedback use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 26

 QR-Based Fixed Asset Management System for MTU

Use case name View report

Actors Property Manager

Description To view the prepared report

Precondition Property manager login into his/her page

Postcondition Approve the prepared report

The basic flow of the Event 1. The property manager clicks on the view
asset information button.
2. The system displays asset information in
table form.
3. Use case ends.

Alternative flow event A2. There is no report currently message will be

displayed.
A3. Use case ends.

Exceptional flow event E4. Error! The database cannot open check your
database message will be displayed.
E5.use case end.

Table 9 View report use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 27

 QR-Based Fixed Asset Management System for MTU

Use case name View asset information

Actors The property manager or Storeman

Description View the general information about the asset.

Precondition Users log in to the system

Post-condition View information about asset

The basic flow of the Event 1. Users click on the view asset information
button.

2. The system displays asset information in

table form.
3. Use case end.

Exceptional flow event E2. Error! The database cannot open contact to
property manager message will be displayed.
E3.use case end.

Table 10 View asset information use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 28

 QR-Based Fixed Asset Management System for MTU

Use case name Withdrawal asset

Actors Storeman

Description Withdraw assets from the store for the user.

Precondition Fixed asset storeman log-in to the system

postcondition Delegate the asset to the user

The basic flow of the Event 1. The storeman clicks on the withdrawing
asset button.
2. The system will display the withdrawal
form.
3. Storeman fills out the form.
4. The storeman clicks on withdraw button.
5. The system validates the information.

6. The system authenticates the entered data

found in the database.
7. The system displays asset withdrawn
successfully message will be displayed.
8. Use case end.

Alternative flow event A6. When incorrect information is entered by the

user, then the system will display an error
message.

A7. If the entered data is not correct please enter

again.
A8. Use case ends.

Exceptional flow event E7. Error! If the database cannot open, a contact
property manager message will be displayed.
E8.use case end.

Table 11 Withdrawal asset use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 29

 QR-Based Fixed Asset Management System for MTU

Use case name Generate report

Actors Storeman

Description Generate a report for a property manager

Precondition Storeman log-in to the system

postcondition Prepare report

The basic flow of the Event 1. Storeman clicks on prepare report button.
2. System displays prepare report form.
3. Storeman fills out the form.
4. Storeman clicks on submit button.
5. The system validates the information.

6. System display successfully generates report

message display.
7. Use case end.

Alternative flow event A6. When incorrect information is entered by the

user, then the system will display an error
message.
A7. Use case ends.

Exceptional flow event E6. Error! The database cannot open contact to
property manager message will be displayed.
E7.use case end.

Table 12 Generate report use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 30

 QR-Based Fixed Asset Management System for MTU

Use case name Prepare request

Actors Staff

Description Requesting the Administration office to withdraw

the asset.

Precondition Staff log in to the system

Post-condition Prepare a request for an Administration office to

withdraw assets.

The basic flow of the Event 1. Staff clicks on prepare request button.

2. System display prepares request form will be

displayed.
3. Staff fill out the form with the required
information.
4. Staff clicks on the submit button.
5. The system validates the information.

6. System display request generated

successfully message will be displayed.
7. Use case end.

Alternative flow event A6. When incorrect information is entered by the

user, then the system will display an error
message A7. Use case end.

Exceptional flow event E6. Error! The database cannot open contact to
property manager message will be displayed.
E7.use case end.

Table 13 Prepare request use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 31

 QR-Based Fixed Asset Management System for MTU

Use case name Prepare problem report

Actors Staff

Description Prepare a report on the problem

Precondition Staff log in to the system

postcondition Prepare problem report

The basic flow of the Event 1. Staff clicks on prepare problem report
button.

2. System display prepares problem report

form will be displayed.

3. Staff fill out the form with the required

information.
4. Staff click on Submit button
5. The system validates the information

6. System display problem report created

successfully message will be displayed.
7. Use case end.

Alternative flow event A6. When incorrect information is entered by the

user, then the system will display an error
message.
A7. Use case ends.

Exceptional flow event E6. Error! The database cannot open contact to
property manager message will be displayed.
E7.use case end.

Table 14 Prepare problem report use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 32

 QR-Based Fixed Asset Management System for MTU

Use case name View feedback

Actors Staff

Description View feedback prepared by the property

manager.

Precondition Staff log in to their page

postcondition View the solution for their report

The basic flow of the Event 1. The Staff clicks on view problem report
button

2. The system displays the feedback in tabular

form
3. Use case end.

Exceptional flow event E2. Error! The database cannot open the system
check your database message will be displayed.
E3.use case end.

Table 15 View feedback use case documentation

Use case name View problem report

Actors Property Manager

Description View problem report for fixed assets.

Precondition Property manager login into his/her page

postcondition View problem report

The basic flow of the Event 1. The property manager clicks on the view
problem report button.
2. The system displays the report in tabular form
3. Use case end.

Exceptional flow event E2. Error! The database cannot open the system
check your database message displayed.
E3.use case end.

Table 16 View problem report use case documentation

DEPARTMENT OF INFORMATION SYSTEMS Page 33

 QR-Based Fixed Asset Management System for MTU

Use case name Create user account

Actors Administrator

Description Create an account for the user

Precondition Administrator login into his/her page

postcondition Create new account

The basic flow of the Event 1. The administrator clicks on Create account
button.

2. The administrator clicks on Create account

button.
3. The system displays create account form.

4. The administrator fills in all the

information.
5. The administrator clicks on submit button.
6. The system validates the information.

7. System authentication is where the user

name is not existing.

8. The system displays that the new user

account created successfully message will
be displayed.
9. Use case end.

Alternative flow event A6. When incorrect information is entered by

the user, then the system will display an error
message.

A7. The user name already exists a message

will be existing.
A8. Use case ends.

Exceptional flow event E8. Error! The database cannot open check your
database message will display.
E9.use case end.

Table 17 Create user account use case description

DEPARTMENT OF INFORMATION SYSTEMS Page 34

 QR-Based Fixed Asset Management System for MTU

Use case name Approve Registration

Actors Administration officer, Facility director, and

Property manager

Description Approve registration prepared by the storeman

Precondition They login into their page

postcondition Approving the registered assets

The basic flow of the Event 6. They click on approve registered button.

7. The system displays the report with

approve register button.
8. They click on approve register button.

9. System display you are successfully

approved registration message display.
10. Use case end.

Alternative flow event A2. There are no new income/registration assets

still now the message display
A3. Use case ends.

Exceptional flow event E4. Error! The database cannot open the system
check your database message will be displayed.
E5. Use case ends.

Table 18 Approve request description

DEPARTMENT OF INFORMATION SYSTEMS Page 35

 QR-Based Fixed Asset Management System for MTU

3.3. Nonfunctional Requirements

Non-functional requirements focus on the user experience. A non-functional requirement is a
statement defining a system quality, constraint, or external interface.

The non-functional requirements characterize the functionality of the system as follows:

Responsiveness: The bootstrap mechanism will use to construct the system, which is
responsive. To create a system that can adapt the size of the user's computer screen.

User-friendly: The user interface of the system should be simple to grasp and allow for easy
interaction, allowing the user to utilize it without much computer program experience.

Accuracy: When the user enters the proper information, the system only returns valid results;
otherwise, when the user enters the incorrect information, the system returns invalid replies.

High maintainability or ease of changing the subsystem: The system will be designed
utilizing object-oriented software development techniques, which make the software highly
maintainable.

Security: The system should only permit registered users, or those who have previously
made accounts using usernames and passwords, to access it. Whenever they are entered into
the database, the password is also encrypted.

Performance criterion: The system we suggested has a long access period and a rapid
response period. The system is accessible at any time, supports multiple users concurrently,
and is simple to use.

DEPARTMENT OF INFORMATION SYSTEMS Page 36

 QR-Based Fixed Asset Management System for MTU

3.4. Sequence Diagram

A sequence diagram is a type of interaction diagram because it describes how and in what
order a group of objects works together. These diagrams are used by software developers and
business professionals to understand requirements for a new system or to document an
existing process. The team uses a sequence diagram to easily define the sequence of tasks that
are accomplished by the actors of the system.

Figure 5 Login sequence diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 37

QR-Based Fixed Asset Management System for MTU

Figure 6 Approve request sequence diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 38

QR-Based Fixed Asset Management System for MTU

Figure 3.4 Create a account sequence diagram

Figure 7 Register asset sequence diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 39

QR-Based Fixed Asset Management System for MTU

Figure 3.6 Withdraw asset sequence diagram

Figure 8 Sequence Diagram for logout

DEPARTMENT OF INFORMATION SYSTEMS Page 40

 QR-Based Fixed Asset Management System for MTU

3.5. Activity Diagram

An activity diagram visually presents a series of actions or flow of control in a system similar to a
flowchart or a data flow diagram. Activity diagrams are often used in business process modeling.
They can also describe the steps in a use case diagram. Activities modeled can be sequential and
concurrent. Overall, this activity diagram provides a high-level overview of the main activities
involved in the QR-based fixed asset management system, from scanning the QR code to updating the
asset information in the database.

Figure 9 Login activity diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 41

QR-Based Fixed Asset Management System for MTU

Figure 10 Approve request activity diagram

Figure 11 Create an account activity diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 42

QR-Based Fixed Asset Management System for MTU

Figure 12 Register asset activity diagram

Figure 13 Withdraw asset activity diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 43

QR-Based Fixed Asset Management System for MTU

Figure 14 Prepare request activity diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 44

 QR-Based Fixed Asset Management System for MTU

Chapter Four
4. System Design

4.1 . Introduction
After gathering information by using different methodologies the information is transferred
from analysis to the design phase. In this phase we describe the general description of the
analysis phase and additionally the internal structure of the system and hardware
configuration. In this phase, we describe in detail the proposed system architecture, current
system architecture, and at last the services of the subsystem.

4.2. Design Goal

Design goal means when we develop our system things to be considered. Those goals
are:
 User friendly: The system should have an easily understandable interface (the user
can interact with the system through the user interface easily), so the user can use it
without having high-level knowledge of the computer application.
 Accuracy: The system gives only valid results if the user gives the correct input
otherwise the system gives an invalid response if the user gives wrong in the put.
 Maintainability: The system is developed using an object-oriented software
development technique that makes the software highly maintainable. If there are any
additional requirements the system is flexible to change.
 Performance requirement: the system that we proposed has a wide access time and
its response time is quick. It delays a minimum second to open and access the system.
The user can access the system at any point in time. The system generates QR codes
for each registered item, and each item's QR code is used to verify it. This system can
support many users at a time. It is also easy to use.
 Security: the system must be protected from authorized access, threats, attacks, and
vulnerabilities.
 Reliability: the system must perform its intended functions and operations in a
system's environment without experiencing failure or system crash

DEPARTMENT OF INFORMATION SYSTEMS Page 45

 QR-Based Fixed Asset Management System for MTU

4.3. Current Software Architecture

The organization uses paper and some computer applications such as Word, Excel,
and others. There is no current software architecture.

4.4. Proposed Software Architecture

The proposed system is expected to replace the existing manual system with a web-based
fixed asset management system which is the software architecture used for the system in
three-tier architecture the first tier is the user browser the second tier is a web server and the
third is MySQL database.

Web browsers: These include Mozilla Firefox, Google Chrome, Opera Mini, Internet
Explorer, and some other browsers. These are used to run the system in the computer system.
These operating systems can be installed in the client computers and therefore can be
accessed as much as needed.

 Web server: It is the heart of the system. It has a lot of responsibilities to

perform like communicating with clients and databases. Since the system is
network-connected, it uses HTTP to send and receive data. HTTP protocol is
used for communication between two devices/machines over the network to
interact with each other.
 MYSQL Database: This is the database software that deals with storing and
managing the data based on the request from the web server. It will write new
records to the storage and will retrieve and deliver them to the web server
when needed. MySQL is one of the most popular database technologies in the
world. Known for being secure and scalable, , it is the go-to solution for
businesses of all sizes.

DEPARTMENT OF INFORMATION SYSTEMS Page 46

 QR-Based Fixed Asset Management System for MTU

Figure 15 Software architecture

4.5. Overview of the System

We select three-layer architecture systems. The reason we use a three-layer is that users or
clients can access the system from anywhere via the World Wide Web. Our system is related
to the database and the database is accessible and is implemented using three-tier
architectures. To implement this system, we use the MySQL server (XAMP server) which
manages the database and for the middle tier, we will use PHP which communicates tiers and
for the Client-side, we use a different web browser, which will be used to make
communication between client and server.

Three-tier architectures

Three-tier architecture is a client-server architecture in which the functional process logic,

data access, computer data storage, and user interface are developed and maintained as
independent modules on separate platforms.

It has the following three tires:

 Presentation Tier: - Occupies the top level and displays information related to
services available on a website. This tier communicates with other tiers by sending
results to the browser and other tiers in the network.
 Application Tier: - Also called the middle tier, logic tier, business logic, or logic tier,
this tier is pulled from the presentation tier. It controls application functionality by
performing detailed processing.
 Data Tier: - Houses database servers where information is stored and retrieved. Data
in this tier is kept independent of application servers.

DEPARTMENT OF INFORMATION SYSTEMS Page 47

 QR-Based Fixed Asset Management System for MTU

Figure 16 Proposed system architecture

4.6. Subsystem Decomposition

To decrease the complexity of the system we can decompose the system into subsystems.
When we are decomposing the system by applying two properties of the subsystem. One is
coupling and the second is coherence. Coherence is the strength of the dependencies among
classes within a subsystem. The coupling is measure the dependency between two or more
subsystems. Generally, we can decompose the system by loose coupling and high coherence.

DEPARTMENT OF INFORMATION SYSTEMS Page 48

 QR-Based Fixed Asset Management System for MTU

Figure 17 Subsystem decomposition

4.7. Hardware/Software Mapping (Deployment

Diagram)
A deployment diagram is a static view of the run-time configuration of hardware nodes and
the software components that run on those nodes. It shows the hardware of the system, the
software that is installed on that hardware, and the middleware used to connect the disparate
machines. . Generally, deployment diagrams are used for describing the hardware
components where software components are deployed It is described as follows

DEPARTMENT OF INFORMATION SYSTEMS Page 49

 QR-Based Fixed Asset Management System for MTU

Figure 18 Deployment diagram

4.8. Persistence Data Management

Persistent data management describes the persistent data stored by the system and the data
management infrastructure required for it. The persistence of our object can be achieved by a
relational database since it is used as a machine to make the object persistent. It describes the
persistent data aspect of a software system. The system will use the MySQL database server
for storing data. This will allow the database to be easily integrated with and accessed by the
rest of thsystem.

DEPARTMENT OF INFORMATION SYSTEMS Page 50

 QR-Based Fixed Asset Management System for MTU

Figure 19 Persistent data diagram

4.9. Class Diagram

The class diagram is the main building block of object-oriented modeling. It is used for
general conceptual modeling of the structure of the application, and for detailed modeling,
translating the models into programming code. Class diagrams can also be used for data
modeling. This class diagram provides a high-level overview of the classes and their
relationships in the QR-based fixed asset management system.

DEPARTMENT OF INFORMATION SYSTEMS Page 51

QR-Based Fixed Asset Management System for MTU

Figure 20 Class Diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 52

 QR-Based Fixed Asset Management System for MTU

4.10. State Diagram

A state diagram (also known as a state machine or statechart diagram) is an illustration of all
the possible behavioral states a software system component may exhibit and the various state
changes it's predicted to undergo throughout its operations.

Using standard UML notation, a state diagram somewhat resembles an operational flowchart
that outlines the various state-altering processes that occur within a system. However, state
diagrams are specifically designed to focus on the state of an object rather than the change-
inducing processes associated with them. Instead, any underlying events that trigger state
changes are identified as Ttransition elements.

Figure 21 Login State Diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 53

QR-Based Fixed Asset Management System for MTU

Figure 22 Register Assets State diagram

Figure 23 Prepare Request State diagram

DEPARTMENT OF INFORMATION SYSTEMS Page 54

 QR-Based Fixed Asset Management System for MTU

4.11. Access Control and Security

Access control is a way of limiting access to a system or physical or virtual resources. In
computing, access control is a process by which users are granted access and certain
privileges to systems, resources, or information. The following table describes the QR-based
fixed asset management system for MTU property management system access control.

Access Administrator Administration Facility Property Storeman Staff

Office Director Manager

1 Login      

2 Approve   
Request

3 Manage 
Account

4 View asset     
Information

5 Withdraw 
asset

6 Register 
asset

7 Prepare 
request

8 Approve   
Registration
Table 19 Access control table

DEPARTMENT OF INFORMATION SYSTEMS Page 55

 QR-Based Fixed Asset Management System for MTU

4.12. Global Software Control

The QR-based fixed asset management system for MTU property management office
architecture is to have explicit, centralized software control. Also the system dynamic control
of admin. Global software control describes how global software control is implemented. In
particular, this section should describe how requests are initiated and how subsystems
synchronize.

The control flow of the system is event-driven. According to the requirement analysis
document (RAD), our system should make sure many users can interact at a time and should
not affect data consistency. This can be implemented by the event handlers. The event
handler can monitor the movement of the user like on click, and so on to achieve the
interaction with the user. In other words, different users can trigger different events at the
same time. The application responds to events in the order they arrive. Each time the user
interacts with a component, an event is sent to the specific subsystem. Different events are
sent to different subsystems. One subsystem can work correctly based on the order of the
events, and it ignores events that are not relevant to its purpose.

DEPARTMENT OF INFORMATION SYSTEMS Page 56

 QR-Based Fixed Asset Management System for MTU

4.13. Boundary Conditions

The system built by using different programming languages to mention them hypertext
markup language (HTML), JavaScript), PHP, and Bootstrap will be used in this project. To
control boundary conditions and the QR-based fixed asset management system will javascript
program. JS handles the following condition: -

Login condition: -

1. It controls email and passwords to be entered in the proper format.

2. It gives a notification if an error occurred in the login process.
3. It shows the notification to enter your email and password if they are empty.

Registration condition: -

1. It is used for controlling data type, it controls the form to be filled with the
appropriate data type and generally, it controls the input system.

2.It supports the database to collect necessary data from the form.

Generally, the system will have the following boundary condition

 The username and password in the fields are not empty.

 The welcome screen does not appear before logging in.
 The password did not match.
 Username already reserved
 If there is an incorrect filling, not jumped to the next field
 The email address is already reserved

4.14. Subsystem Services

Subsystem Service is a group of operations provided by the subsystem. The subsystem is
where work is processed in the system. A subsystem is a single, predefined operating
environment through which the system coordinates the workflow and resource use. The
system can contain several subsystems, all operating independently of each other.
Subsystems manage resources.

The following are the subsystem services:

DEPARTMENT OF INFORMATION SYSTEMS Page 57

 QR-Based Fixed Asset Management System for MTU

 Administration office
o Approve the request
o View asset information
o Approve regestration
o
 Facility director
o Approve the request
o View asset information
 Property Manager
o Approve the request
o View asset information
 Storeman
 Register asset
 Withdraw asset
 View asset information
 Add Asset category
 Staff
o Prepare request
o View assets information
o View request asset
 Administrator
o Manage accounts
o Create account
o Deactivate account
o Activate account

DEPARTMENT OF INFORMATION SYSTEMS Page 58

 QR-Based Fixed Asset Management System for MTU

References
[1] “AssetPro-Fixed Assets Management System AssetPro-Fixed Assets Management
System,” 2020.

[2] “How QR Codes Can Improve the Speed of Tracking Assets.”

[3] “About Us – Mizan Tepi University.” http://www.mtu.edu.et/about-us/ (accessed Mar. 24,

2023).

[4] “SDLC - Iterative Model.”

[5] “What is Feasibility Study in Project Management and Its Types? | Simplilearn.”

[6] “What is Sequence Diagram?” https://www.visual-paradigm.com/guide/uml-unified-modeling-

language/what-is-sequence-diagram/ (accessed May 20, 2023).

[7] “Deployment Diagrams Explained in Detail, With Examples - Plutora.”

https://www.plutora.com/blog/deployment-diagrams-explained-in-detail-with-examples
(accessed May 20, 2023).

DEPARTMENT OF INFORMATION SYSTEMS Page 59