The customer issue request by filling the form Basic course of action: 1. The customer login to the system 2. The customer click on issue request button 3. The system display request form 4. The customer fill the form 5. The customer submit the request 6. The system save the request 7. Use case end Alternative course of action(A): If the request is invalid A4: The system display error message A5: The customer correct the error and resubmit A6: Use case end Table 2.5.2.4 Use case documentation Table5. Assign technician use case documentation Name: Assign technician ID: UC

1. JIMMA UNIVERSITY
INSTITUTE OF TECHNOLOGY
COMPUTING DEPARTMENT
IT PROGRAM
WEB BASED MAINTENANCE REQUEST SERVICE
MANAGEMENT SYSTEM FOR JU
Team members: NAME ID.NO
1 Rehana kasim 01936/03
2 Semira Mohammad 01949/03
3 Seblewengele Dessie 01945/03
Advisors: Mr. Seid
And Mr.Yemam
Jan 31 2014

2. JIMMA UNIVERSITY
INSTITUTE OF TECHNOLOGY
COMPUTING DEPARTMENT
IT PROGRAM
Approved by
1.
2.
Content Table

4. Acknowledgement
First of all we would like to thanks ALLAH (SWA) for helping us to overcame this project .then
our advisor Mr. Seid and co advisor Mr. Yemam .special thankful for
Jimma University maintenance department staff how played a great role on our analysis phase by
giving us the information we want and for our department supplying project writing guidelines
and noticing the final time of project which accelerate us to accomplish our task at a time.
Finally we would also like to thank our friends who helped us a lot to finish this project.
Abstract

5. This project document all about online maintenance request management system for Jimma
University. It has three chapters: proposal, analysis and design. The proposal part deals with the
background, statement of the problem, scope and more importantly with a feasibility of the
project in terms of economic, technical and time feasibility. It also includes project time schedule
and organization of the project.
The second chapter elaborates analysis of the existing and the new system in detail. Analysis of
the existing system contains the description of the existing system and functional of the existing
system. And the new system deals with deep discussions of the new proposed system using a
UML diagrams. A detailed description of system functionalities and use case documentation are
also part of this new proposed system.
The third and the last part of this documentation is the design. The web based solutions to the
problems of the system which is online maintenance request management system are included in
this part. It starts with purpose and goals of the design. Next the proposed architecture of the
solution including subsystem decomposition, class diagram, component diagram, collaboration
diagram, deployment diagram and ER diagram followed with the access control and security are
included in this part.

7. 7

8. CHAPTER ONE
1.1 Background
Jimma University is a public higher educational institution established in December 1999 by the
amalgamation of Jimma College of Agriculture (founded in 1952), and Jimma Institute of Health
Sciences (established in 1983).The two campuses are located in Jimma city 335 km southwest of
Addis Ababa with an area of 167 hectares and Building maintenance office is also coexisted
with the establishment of Jimma university. Today computer and other electronic device
increasingly communicate and interact directly with other devices over a variety of network such
as internet. The internet provides individuals and informal organizations the ability to
communicate inexpensively.
Hence, developing the system using IT technology has a great effect for organizations and
offices; which in our case the JU Building Maintenance service office request process is
currently, their system is manual; in which the user fill forms, then, the client manager assigns
technician for the user subsequent to technician cease his job detail information documented
manually. So, if the JU Building Maintenance office is able to use IT technology they can benefit
in more than a few means they carry out.
A vision of maintenance service for JU is sustaining a good working environment which exists
and correcting some hindrances happening during the process of the office
Mission of maintenance service for JU is providing fast and efficient services for customers and
to satisfy them. And Maintenance service has Missions of ensuring that there will not be any
delay in academics plane due to any damage on academics supporting materials
1.2 Statement of the problem

9. Currently most of the transactions in JU Building maintenance request service are manual; hence
if they are automated they will gracefully increase performance and efficiency of the existing
system. These transactions includes:-
Maintenance request is not handled easily.
When there is a problem or any failure on the buildings the requests which are sent to the
maintenance department is manual.
The user’s maintenance request forms are stored manually.
The technicians are assigned manually.
The users must go to the office to give feedback.
 The report is done manually.
1.3 Objective
1.3.1 General Objective
The general objective of this project is to develop web based maintenance request service
management system for JU.
1.3.2 Specific objective
To achieve the above mentioned general objective, the system will address the following specific
objective. The developed system will be able:
 To manage maintenance request.
 Manage user registration
 Manage account
 To allocate technician online.
 Give feedback online.
 To generate a report.
1.1.4 Scope of the project

10. The new Jimma University maintenance request service management system meets the following
system and information requirements.
 Accepts on-line request from clients.
 Create account to the users.
 Manage maintenance request which is given by the maintenance department or
enterprise.
 Give a response for user’s request.
 Allocate technician online.
 The user and technician will give feedback to the administrator.
 The system will generate detail report.
1.5 Methodology
When we illustrate the current system we use different techniques to collect information.
 Observation: we see the current system work flow problems that customer face,
requirements needed by users, necessity of online information management system.
 Interview: By asking question from concerned bodies we get information about the
current system.
1.5.1. Tools used for system design
System design –is the transformation of analysis mode in to design model system.
Class Diagram- it shows a set of class and their relationship.
Use case diagram- it shows what the system functions are performed for which actor.
Sequence Diagram- it shows how processes operate with one and in what order system.
Activity Diagram- it shows the process of the project from starting to the end.
1.5.2. Development tool

11. Table 1.5.2 Development tool
1.6 Feasibility of the project
1.6.1 Economic feasibility
Activities Tools/Programs
Client side coding HTML
Client side scripting JAVA script
Plat form MS-Windows
Database server/back end Mysql,Xamp
Webserver Apache
Server-side scripting PHP
Editors Macromedia Dream weaver, Edraw
Documentation MS-word

12. The purpose of assessing economic feasibility is to identify the financial benefit and cost
association with the development project; economic feasibility is often referring to us cost
benefit analysis. This system minimizes the cost of paper and reduces cost of hiring
unprofessional employees in the organization. There is no need to buy new machine used for this
system or hiring of new employees.
1.6.2 Technical Feasibility
The purpose of technical feasibility is to gain an understanding of the organization ability to
construct proposed system. The system graphical user interface is user friendly to the employees
and customer of the organization and in JU internet access is 24 hours available and the
employees which work in JU are educated .finally the system can be easily maintained base on
this our system is technically feasible.
1.6.3 Time Feasibility
This feasibility concerned with analysis defining the duration of the project for its initiation
states up to the final implementation of the system. Hence, we try to analyze and define the time
line so as to accomplish within the desired deadline.
1.1.7 Significance of the project
Earlier Jimma University building maintenance service is working with manual which is
consuming much time. The importance of this project is to change the manual system to
computerized or automated system. This computerized service will
 Reduce work burden of employee.
 Reduce resources wastage.
 Enables to perform different activities within a short period of time.
 Reduce the number of days taken to give a service.
 Supplies timely information for user.

13. 1.8 Limitation
 This website gives service for only staff members.
 This website is only for maintaining old buildings rather than constructing a new one.
 Time limited for the completion of the project is one factor for developing a complete
system.
 Budget constraints can be major limitation, in case required materials are not purchased
on time.
 If scope creep is made knowingly it may be a limitation since more time is required to
cover the newly added scope.
1.9 Organization of the project
The project consists of four chapters. The first chapter includes background, objective,
methodology, among others. After successfully completed proposal part, analysis of the
system is going to be conducted; this includes current system description, problem of the
current system, alternative solution, proposed solution, functional and nonfunctional
requirements and other tasks.
The chapter three deals with design using different modeling chapter four we
Implement the system based on identified solution. This chapter includes writing code
and testing. Finally the implemented system is checked weather it is
successfully implemented to solve the problem of the organization.
CHAPTER TWO

14. Analysis
2.1 Existing System
2.1.1 Existing System Description
In the existing system Jimma University the maintenance department gives service to staffs by
the direct contact to the maintenance department and by using manual request. The technician
assignation is done manually. In the existing system, all the activities are performed in
maintenance coordinator (department head) office; Files are manually stored, moved and
processed from one section to another. Finally the current system is so boring and time taking for
the users and employee.
2.1.2 Major Function of existing system
 Users sent maintenance request for the maintenance department head by filling forms
about what they want
 After checking this request if it is possible to done by those technician who found under
the maintenance department the request is sent to the technician from the maintenance
department head
 But if the service requested by the user is impossible by those technician who are found
under the maintenance department then the request is sent from the maintenance
department head to the enterprises
 Then the enterprise manager orders a technician manually.
 If the work is not done they will report again by going to the department physically.
2.2 New System
2.2.1 New System Description
The development of new web based maintenance service request management system for Jimma
University office benefits all the staffs and users by increasing the efficiency of the system. We
also come with a solution for big problem through making online maintenance request service.

15. This will reduces the burden for those busy staffs and also facilitates the operation of the system.
Our system registers the user through their id and then they can create their account. The other
thing is it will verify the works which is done by two departments and control over technician
assignation through online. The administrator also sends assignation message for the technician
about the request which is sent from the user as well as for the user about the technician when
he/she will go to the venue of the maintenance request. And it will generate a report.
2.3 Requirement Analyses
2.3.1 Functional Requirements
The new system deals with automating the maintenance request management system for Jimma
University. This web based Maintenance request management system for Jimma University is
desired to do several things for the department. It is described as follow.
 In this system we will make the maintenance service request online which is easily
accessible by users.
 Users should register online to get user account.
 After users authentication he /she can get the service.
 After user fill the form the system verifies the request.
 Administrators can assign the technician online.
 Technicians can see where and when it is assigned.
 The technician can report the work is completed.
 Users can send a report for the administrators the work is completed or not.
 Generate report.
2.3.2 Nonfunctional requirement
 The system provides short response time for user action.
 The designed system will not have much graphics, so, it can be loaded to a
browser in short time period.
 The designed system will use low utilization of system resource in terms of
space and time.
1. Usability
 The designed systems user interface graphics will reflects the system.

16.  The user interface will be light weight and easy to use and manage.
 The designed user interface will be attractive.
2. Backup and Recovery
 Backup will be stored on the intranet server and JU website.
 All process can be made available after unplanned down time within 1 day.
3. Security
 The system provides user name and password to prevent the system from
unauthorized access.
 The staff password must be greater than eight characters.
2.4 Business Rule
Business rule is the rules and regulation of the organization that is used to perform the overall
activities of the organization.
BR1.The customer must register online to get an account.
BR2.All users must have their own account to use the system according to their role.
BR3. The two departments work is different.
BR4.The administrator should check whether request is sent to them.

17. BR5.The technician must check his account daily.
BR6.The administrator should reply for the request as soon as it sent.
BR7.Each member of Jimma university staff information should be recorded on the database.
2.5 System design model
2.5.1 Use case modeling
System use case reflects analysis decisions and arguably even design decisions during analysis.
our main goal is to develop our essential use cases. A system use case model is composed of a
use case diagram and the accompanying documentations describing the use cases actors, and
associations
The identification of use case is;
 Issue request
 Login
 Online registration
 Manage account
 Response
 Give feedback
 View
 Assign technician
 Generate report
Actor Identification
Customer-is the one who use the system and make a request to get services.
Technician-who is assigned by the administrator to give service to the requests and give feedback
to the administrator that the work is done or not.
Administrator -control the whole system and administer according to the users information and
assign the technician online and give the response to the customer.
System -is the dispatcher which identify request which is sent made by the customer to the two
departments.

18. 2.5.1Use Case Diagram
A Use Case diagram is a graphical representation of the high- level system scope. It includes
A Use Case diagram is a graphical representation of the high-level system scope. It includes use
cases, which are pieces of functionality the system will provide, and actors, who are the users of
The system. Looking at a Use Case diagram, you should easily be able to tell what the system
will do and who will interact with it.

19. Fig 2.5.1 Use case diagram
2.5.2 Use case documentation

20. Table1.Online Register use case documentation
Name: Online Register
ID: UC#1
Actor: Customer
Description: Each customer register in maintenance
department to get the permission to use the
service of the system
Precondition : Customer must be Jimma university staff
member
Post condition: Customer will be register in the system if they
are fulfill registration criteria
Basic course of action: 1: Customer wants to register in the system
2: Customer select registration button
3: The system display registration form
4: Customer fill all the necessary information
5: Customer submit his registration
6: System validates the form
7: Display successfully message
8: Use case end
Alternative course of action(A): If the registration is invalid
A6: System display error message and return to
step 4
A7: Use case end

21. Table 2.5.2.1 Use case documentation
Table2. Login use case documentation
Name Login
ID UC#2
Actor Customer,administrator,technician
Description All actors click on login button
to the system
Precondition All actors should know user name and
password to enter the system
Post condition The User enters to privileged page
Include
Extend
Basic course of action 1.The user open homepage
2.The user click on login button
3.The system display the login page
4. The user enters the user name and password
5. The system determines the actors user
accounts weather they enter correct user
account or not
6.The user login to the system
7. Use case end
Alternative course of action(A) If user does not enter valid name and password

22. A3: System display error message or renter the
correct user name or password
A4: The system will return to step 3
A5: Use case end
Table 2.5.2.2 Use case documentation
Table3. Manage Account use case documentation
Name Manage Account
ID UC#3
Actor Administrator
Description The administrator can manage the users
account
Precondition Account created
Post condition User resign from jimma university
Include Login
Extend
Basic course of action 1.The administrator Login
2.the administrator click manage account
3.the system display accounts
4.select the account
5.click on delete
Alternative course of action(A)

23. Table 2.5.2.3 Use case documentation
Table4.Issue request use case documentation
Name: Issue request
ID: UC#4
Actor: Customer
Description: In this system the customer issue the request
he/she want
Precondition: The user must be authenticated
Post condition: The user issue request and get response
Include use case Login
Extend
Basic course of action: 1.customer want to send request
2.customer must be login
3.the customer click on issue request

24. 4. system display the fill form page
5.customer fill the form
6.customer click on submit button
7.system check the filled form
8. The system determine the request
9. The system save the request to the database
10.the system display “successfully message”
11. use case end
Alternative course of action (A): If the customer fill form is invalid
A5. System display error confirmation and
return to step 3
A6. Use case end
Table 2.5.2.4 Use case documentation
Table5. View use case documentation
Name: View
ID: UC#5
Actor: Administrator,customer,technician
Description: All users should view their messages which are
sent to them.
Precondition: The message should be send to them

25. Post condition: The message (request) will be viewed.
Include Login
Extend
Basic course of action: 1.The users wants to view
2. All user must be login in his/her account
3. user click on view button
4.the system displays their message
information
5.use case end
Table 2.5.2.5 Use case documentation
Table6. Response use case documentation
Name: Response
ID: UC#6

26. Actor: Administrator
Description: The admin will give a response to the users
(customers)
Precondition: The user must send the request
Post condition: The administrator will assign a technician send
a response to the requests.
Include Login ,view
Extend
Basic course of action: 1:The user must login
2:user wants to give response
3:select the requester
4: click on response button
5:sends message to the requester about the
assignation
6: System display successfully message
7: use case end
Alternative course of action(A):
Table 2.5.2.6 Use case documentation

27. Table7. Assign technician use case documentation
Name: Assign technician
ID: Uc#7
Actor: Administrator
Description: The admin should select the assign technician
Precondition: the technician must be registered on the
database
Post condition: The admin assign the technician
Include Login
Extend
Basic course of action: 1. The administrator must login
2.The administrator select assign technician
page
3.The system displays the technician list and
information page
4.The administrator select the concerned
technician
5.The administrator send the assignation
message to the technician
6. The system confirm delivery message.
7. use case end
Table 2.5.2.7 Use case documentation

28. Table8. Feedback use case documentation
Name: Feedback
ID: UC#8
Actor: Customer ,technician
Description: Customer and technician give feedback to
administrator after the work is properly done
Precondition Customer ensure issue request and technician
must be assigned for the work
Post condition The user give feedback
Include Login
Extend
Basic course of action 1. Wants to give feedback.
2. user first login
3.The user click on feedback button
4. The system displays the feedback form.
5.fill the form
6. click submit button
7.use case end
Alternative course of action(A): If the username and password is invalid
A1.the system display the error message

29. A2.use case end
Table 2.5.2.8 Use case documentation
Table9. Generate report use case documentation
Name: Generate report
ID: UC#9
Actor: Administrator
Description: Generate report for all user of the system who
wants to view the report.
Precondition: All detail information should be record on the
database.
Post condition: All users able to view the report generate
information.
Include Feedback
Extend
Basic course of action: 1.admin want to generate report
2. The admin must login.
3. The click on generate report.
4. The system displays report type
5.select the report type

30. 6. The system displays the report
7.use case end
Table 2.5.2.9 Use case documentation
2.6 Sequence diagram
2.6.1 Sequence diagram for “Online register”

31. Fig 2.6.2 Sequence diagram modeling

32. 2.6.2 Sequence diagram for “Login”
Fig 2.6.3 Sequence diagram modeling

33. 2.6.4Sequence diagram for “Issue request”
Fig 2.6.5 sequence diagram modeling

34. 2.6.5 Sequence diagram for “View”
Fig 2.6.5 sequence diagram modeling

35. 2.6.6Sequence diagram for “Response”
Fig 2.6.6 Sequence diagram modeling

36. 2.6.7 Sequence diagram “Assign technician”
Fig2.6.7 Sequence diagram modeling

37. 2.6.8Sequence diagram for “Feedback”
Fig2.6.8 Sequence diagram modeling

38. 2.6.9 Sequence diagram for “Generate report”
Fig2.6.9 Sequence diagram modeling

39. 2.7 Activity diagram
An activity diagram illustrates the dynamic natural of a system by modeling the flow of control
from activity. An activity represents an operation on some class in the system that result in a
change in the state of the system. Typically activity diagrams are used to model work flow or
business processes and internal operation.
2.7.1 Activity diagram for “login”

40. Fig 2.7.1 Activity diagram modeling
2.7.2 Activity diagram for “online registration “

41. Fig 2.7.2 Activity diagram modeling
2.7.3 Activity diagram for “Response”

42. Fig 2.7.3 Activity diagram modeling
2.7.4 Activity diagram for “issue request

43. Fig 2.7.4 Activity diagram modeling
2.7.5 Activity diagram for “view”

44. Fig 2.7.5 Activity diagram modeling
2.7.6 Activity diagram for “assign technician “

45. Fig 2.7.6 Activity diagram modeling
2.7.7 Activity diagram for “feedback”

46. Fig 2.7.7 Activity diagram modeling
2.7.8 Activity diagram for “Generate report”

47. Fig 2.7.8 Activity diagram modeling
2.8 Conceptual modeling Class diagram

48. Class Diagram provides an overview of the target system by describing the objects and classes
inside the system and the relationships between them. It provides a wide variety of usages; from
modeling the domain-specific data structure to detailed design of the target system
Fig 2.8 conceptual diagram
2.9 Prototyping model

49. The prototyping model is a systems development method(SDM)in which a prototype(an early
approximation of a final system or product)
User interface prototype for Login
Fig 2.9.1 User interface prototyping

50. User Interface prototype for Registration
Fig 2.9.2 User interface prototyping

51. User Interface Prototype for Issue Request
Fig2.9.3 User interface prototyping
2.10 State Chart

52. A state chart diagram shows the behavior of classes in response to external stimuli. This diagram models
the dynamic flow of control from state with in a system.

53. State chart for issue request
Fig 2.10.1 State chart diagram

54. State chart for account

55. Fig 2.10.2 state chart diagram
2.11 Communication Modeling
It is called collaboration or interaction diagram, is an illustration of the relationships and
interactions among software objects in the unified modeling language (UML).Communication

56. diagram resembles a flowchart that portrays the roles, functionality and behavior of individual
objects as well as the overall operation of the system in real time. The messages between objects
are shown as arrows connecting the relevant rectangles along with labels that define the message
sequencing.
Communication diagram for Login
Fig 2.10.1 Communication diagram
Communication diagram for issue request

57. Fig 2.10.2 Communication diagram
Communication diagram for generate report

58. Fig 2.10.3 Communication diagram
Chapter Three
System Design
3.1 Purpose and goals of design

59. This project is designed in a manner that solves the problem of the maintenance department by
minimizing the work load that appears on the employees because of the existing manual system.
It provides more efficient, reliable and time saving system. In this project design the team will
try to show:
 how the project is designed
 what are tasks done under the whole project
 The different modules and their way of functioning are described here.
3.2 Goals of design
Generally, the project will be designed by addressing all of the above criteria of the project
design. It is designed to simplify functions of the manual system and it is capable of doing large
amount of works in short period of time with more accuracy and reliability. Generally this
project design will describe how the project is designed, what tasks done under this project and
different modules and their way of functioning.
The goal of system design according to the proposed project is to manage complexity by
dividing the system into smaller, manageable pieces and to increase the system:-
 Efficiency: the system doing something well and thoroughly without waste of money and
time.
 Flexibility: the system able to change to suite new condition or situation
 Security: the system should be secured, i.e. Not allow unauthorized users to access the
system.
 Reliability: the system should be reliable.
3.3 proposed software architecture
The general architecture of the software looks like the following picture. At the top layer the user
interface of the system is set and maintenance request management application login or website

60. Finally at the back end the request database
Fig 3.3 software architecture
3.3.1 Subsystem decomposition
Any system can be decomposed in to different subsystem based on the functional services. Some
of the subsystems are

61. Fig 3.3.1 Subsystem decomposition diagram
3.4 Class modeling

62. Purpose of design-class modeling is to model the static structure of how the software will be
built
Fig 3.4 Class modeling
3.5 Component modeling

63. A component is a physical unit of implementation with well-defined interfaces .well-designed
components do not depend directly on other components but
Fig 3.5 component diagram
3.6 Deployment Diagram

64. The deployment diagram shows how a system will be physically deployed in the hardware
environment. Its purpose is to shows where the different components of the system will
physically run and how they will communicate with each other. since the diagram models the
physical runtime. A system’s production staff will make considerable use of this diagram.
Fig 3.6 deployment diagram
3.7 E-R Diagram

65. An entity relationship diagram is a specialized graphic that illustrate the relationships between
entities in a database. ER diagrams often use symbols to represent three different types of
information. Boxes are commonly used to represent entities. Diamonds are normally used to
represent relationships and ovals are used to represent attributes.
Fig 3.7 Entity relationship diagram
Appendix A: unified modeling language notations

66. Symbol description

68. Appendix B: ER-diagram notation
Symbol description
Appendix C: Abbreviation
UC#.............................................Use case
BR#.............................................Business rule
HTTP……………………………Hypertext protocol
MYSQL…………………………Database connection
Reference