Assosa University

College of Computing and Informatics

Department of Information Technology

Online Information Desk and Support System for Assosa

University
Prepared by:
1. Mesenbet Abewa
2. Arebu Yimer
3. Kaleab Girma

A Project Submitted to the Department of Information Technology of Assosa

University in Partial Fulfillment of the Requirements for the Bachelor Degree of
Science in Information Technology

Advisor: Biniyam Wondie (MSc.)

ASSOSA, ETHIOPIA
May, 2019
 APPROVAL SHEET
This project is Information Desk and Support System for Assosa University. Before this time our project is not done
by other students in our campus .we use it as a guide line and we site it as a reference. Prepared and submitted by
fourth year information technology Students namely:

Mesenbet Abewa
Arebu Yimer
Kaleab Girma

In partial fulfillment of the requirements for the degree of BSC.

Project Advisor Head of the department

Name Name
Mr. Biniyam W. (MSc.) Mr. Kassahun
(MSC)

Sign___________________5/31/2019 Sign___________________5/31/2019

Examiners

Name Signature

1.__________________________ ________
2.__________________________ ________
3.____________________________________ ___________

Information Desk and Support System Page III

 Acknowledgement
Firstly, we would like to express our gratitude to Almightily God and his mother, for doing this
Information desk and support system and kindness through our life and to give us ability, willingness to
accomplish this paper successfully

A very special thanks to Teacher Biniyam Wondie, advisor of this project developer’s team, has made
substantial contribution to us by providing valuable information, advice and guidance to keep track in
appropriate way and to finalize the project on time. Finally, we are indebted to all who encourage us
to produce this project.

Information Desk and Support System Page III

 Abstract
The project entitled “Online Information Desk and Support System for Assosa University” This is an Intranet based
application that can be accessed throughout the campus is handled in two parts. The first part includes problem
identification, planning, business analysis, requirements definition and object-oriented analysis details of the project.
It presents background of ASU IT facilities, objective and scope of the project, statement of the problem and its
justifications, and the project plan. It describes the existing system functional and nonfunctional requirements,
business rules, major role players, and problems with their solutions. It finally models the proposed system use cases,
sequence diagrams, class diagrams, activity diagrams and user interface prototypes. It is documented in the first three
chapters and is delivered separately.
The second part of the project consists of requirements review, System Implementation and testing, object-oriented
design, and final implementation details. It is briefly discussed the solution domain in detail using class type
architecture, design level class modeling, state chart diagram, collaboration diagrams, component modelling, and
deployment diagram. It presents the algorithms and flowcharts that is implemented along with the testing procedures.

Information Desk and Support System Page III

 Acronyms and Abbreviations
ASU…………………………Assosa University
IT……………………………Information Technology
UML…………………………Unified Modeling Language
RAM …………………………Random Access Memory
XAMPP………………………extension for Apache MYSQL Perl Platform
PHP………………………….Hypertext Pre-Processor
ALTC A………………………Alternative course action A
ALTC B………………………Alternative course action B
ICTWG………………………ICT Work groups
OIDSS…………Online Information Desk and Support system
IDSS……………………..Information desk and Support system
IDS……………………………..Information desk system

Information Desk and Support System Page VIII

 Table of Contents
Acknowledgement..................................................................................................................................................2
Abstract..................................................................................................................................................................3
Table of Contents...................................................................................................................................................4
Chapter one...........................................................................................................................................................1
1. Introduction......................................................................................................................................................1
1.1. Background of the Study.................................................................................................................................2
1.1.1. Mission.........................................................................................................................................................2
1.1.2. Vision...........................................................................................................................................................2
1.2. Existing System Description...........................................................................................................................3
1.3. Problem of Existing System............................................................................................................................3
1.4. Proposed System Description..........................................................................................................................4
1.5. Objectives of Proposed System.......................................................................................................................4
1.5.1. General Objective.........................................................................................................................................4
1.5.2. Specific Objectives.......................................................................................................................................4
1.6. Scope in...........................................................................................................................................................5
1.7 Scope Out.........................................................................................................................................................5
1.8. Methodologies and Tools................................................................................................................................5
1.8.1. Methodologies..............................................................................................................................................5
1.8.1.2. Data Gathering Methodology....................................................................................................................5
1.8.1.2. Systems analysis and design methodology...............................................................................................6
1.8.2. Tools.............................................................................................................................................................6
1.9. Significant of the Project.................................................................................................................................7
1.10. Work Plan (Time Table)................................................................................................................................7
1.11. Cost................................................................................................................................................................8
CHPTER TWO.....................................................................................................................................................9
2.1. Introduction...................................................................................................................................................9
2.2. Organizational work flow..............................................................................................................................10
2.3. Organizational business rule.........................................................................................................................10
2.4. Essential use case with actor Identification...................................................................................................11
2.4. 1. Actors........................................................................................................................................................11
2.4.2. Essential Use Cases....................................................................................................................................12
2.4.3. Essential use case diagram.........................................................................................................................13

Information Desk and Support System Page VIII

Chapter Three.....................................................................................................................................................22
3.1. Introduction.................................................................................................................................................22
3.1.1. The Interaction Levels of IDSS..................................................................................................................22
3.2. System use case.............................................................................................................................................23
3.2.1. Actor Identification....................................................................................................................................24
3.2.2. Use case Identification...............................................................................................................................24
3.2.3. use Case Diagram.......................................................................................................................................25
3.3. System use case description..........................................................................................................................27
3.4. Sequence diagram..........................................................................................................................................36
3.5. Activity diagram............................................................................................................................................42
3.6. Class diagram................................................................................................................................................46
3.7. Essential user interface prototype..................................................................................................................48
Check problem status...........................................................................................................................................49
3.8. User Interface Flow Diagramming................................................................................................................52
3.9. User Interface Design....................................................................................................................................54
3.9.1. User Interface design for Login Page.........................................................................................................54
3.9.2. User Interface design for Admin Menu Page.............................................................................................54
3.9.3. User Interface design for Employees create request..................................................................................55
3.9.4. User Interface design for admin assign requests to ICT Officers..............................................................55
3.9.5. User Interface design for add ICT Officers by admin................................................................................56
3.10. Collaboration diagram.................................................................................................................................57
3.11. Deployment Diagram..................................................................................................................................60
3.12. Architectural Design....................................................................................................................................61
Chapter Four......................................................................................................................................................64
System Implementation and Testing................................................................................................................64
4.1. Introduction...................................................................................................................................................64
4.2. Algorithm Design..........................................................................................................................................64
4.3. Flow Chart Diagram......................................................................................................................................66
4.4. Coding...........................................................................................................................................................67
4.4.1 Implementation sample code of main process............................................................................................67
4.5. Testing Procedure..........................................................................................................................................68
4.6. Test Case Specification.................................................................................................................................70

Information Desk and Support System Page VIII

4.6.1. Test Cases for Login Component Testing..................................................................................................70
Chapter Five.......................................................................................................................................................71
Conclusion and Recommendation....................................................................................................................71
5.1. Conclusion.....................................................................................................................................................71
5.2. Recommendation...........................................................................................................................................72
References............................................................................................................................................................73

Information Desk and Support System Page VIII

 List of Figure
Fig 2.1. Essential Use case Diagram.............................................................................................15
Figure 3.2: Login (SD#001)..........................................................................................................38
Figure 3.3: Registration for Users (SD#002).................................................................................39
Fig3.4. Sequence diagram for create request/post problem UC#003............................................40
Fig3.5. Sequence diagram for Chatting at client side/requester UC#004......................................41
Fig3.6. Sequence diagram for Registration of Offices UC#008....................................................42
Figure 3.7: View Problem Status (SD#006)..................................................................................43
Fig 3.8. Activity diagram for login system....................................................................................44
Fig 3.9. Activity diagram for create request/post problem............................................................45
Fig 3.10. Activity Diagram for Check Problem Status..................................................................46
3.11. Activity Diagram for Generate Report.................................................................................47
Fig. 3.12. Activity Diagram for Register Employees, ICT-officer...............................................48
Figure 3.13: Class Diagram of the ASU Helpdesk management system......................................49
Fig. 3.14 User Interface Prototype for Create request/Problem for help.......................................50
Fig. 3.15 User Interface Prototype for Check Problem Status.......................................................51
Fig. 3.16 User Interface Prototype for Generate Report................................................................52
Fig. 3.17 User Interface Prototype for Login page........................................................................52
Fig. 3.18 User Interface design for implementation Home page...................................................53
Fig3.19. User Interface flow diagram for Users............................................................................54
Fig 3.20. User Interface flow diagram for Users...........................................................................55
Fig. 3.21. Collaboration diagram for create Request problem.......................................................56
Fig. 3.22. Collaboration diagram of user registration....................................................................57
Fig. 3.23. Collaboration diagram for Login...................................................................................58
Fig 3.24. Deployment diagram......................................................................................................59
Figure 3.25.: Layered class type architecture for the IDSS...........................................................62
Figure 4.1: Flowchart diagram for Make Request ........................................................................66
Fig 4.2. Unit testing for login page ..............................................................................................69

Information Desk and Support System Page VIII

 List of Tables

Table 1.1 Work Plan (Time Table) 1...............................................................................................7

Table 1.2 cost value for our project.................................................................................................8
Table 2.1. Essential use case..........................................................................................................13
Table 2.2 Description for Essential Use cases...............................................................................16
Table 3.1 login use case description..............................................................................................28
Table 3.2. Register use case description........................................................................................30
Table 3.3 request use case description...........................................................................................33
Table 4.1 Test cases for Log in component 1................................................................................70

Information Desk and Support System Page VIII

 Chapter one
1. Introduction
Continuous adapting and updating of new technologies have made development of effective and
efficient help desk services challenging for different organizations. Any Organizations must actively
search for new ways to provide better help desk services that can satisfy the growing customer demands
and expectations. Help desk is a customer support center in an organization that provides information,
administrative and technical supports to users, with the view to solving problems that users encountered
in the course of using the organization resources or facilities.

Help Desk also supports the functionality of our campus by responding to users’ requests in a timely
manner. It is hence, a core sector through which problems, complaints and requests are reported,
managed, coordinated and resolved. Help desk is a solution application that is used for managing our
campus help desk. The Helpdesk is the single point of contact for all users to report issues with the
hardware, software products, and network that are supported in our district regarding to IT department.
The Helpdesk can resolve some of the issues immediately, and when more help is required the created
work tickets for the Site Admin controllers address the issue for to the concerned person. This helps the
users get the most out of the technology provided.

From a general or wider perspective, it is an integral part of the service Function, responsible for
bringing resources together to address a problem or other issue. The Help Desk Management System
that is being studied about and developed as a project is called Help desk management system for
Assosa University

The main intention or motivation of what we choose and do on this title is handling complaints and
problems all day in our campus and giving a short time response is very difficult and there is no one who
carried on the volume of requests. Also to minimize confusion for new entry students in our campus by
providing information about university location and additional information.

In our project the help desk project provides effective approach in handling all reported technical
concerns with proper record keeping and monitoring to clients and technical personnel

Information Desk and Support System Page 1

As well as systems administrators. In this project what we have to develop for the sake of employees and
students to get solved from their problem and also to get the feedback from the employees regarding the
problems solution.
1.1. Background of the Study
Assosa University (ASU) is one of the third generations public universities in Ethiopia which was
established in May2011 by the Council of Ministers decree number 215/2011. The objective of ASU is
to produce highly qualified and dedicated man power, to conduct research and to provide community
service. It is also engaging in various developmental activities to achieve the country’s growth and
transformation plan. P.o.Box: 18 (Assosa University (ASU)); Assosa, Ethiopia.
The University is located in Assosa municipality area which is the capital of Benishangul Gumuz
Regional State. The town is an important for communication, trade and growth center situated at a
distance of 660 kilometers away from Addis Ababa, 210kilometers south of the Grand Ethiopian
Renaissance Dam/GERD/ and 96 km East of the Ethio-Sudanese border.
The University officially began its duty on June 2011 in a temporary campus at Assosa Agricultural
TVET College. The academic wing started with 100 Teachers, 5 faculties including 17 undergraduate
fields of studies since then. After two years of staying in the temporary campus, it was shifted to its own
new building campus.
1.1.1. Mission
Based on the interest in the nation, Assosa University has a dedication to contribute graduates that are
competent in knowledge, skill and attitude; undertake problem-based research and render pertinent
services to the community.
1.1.2. Vision
Assosa University aspires to be one of the top ten universities in Ethiopia by 2025. Values and
Principles of the University: - Assosa University is the owner of the following Core values and
principles. Transparency and Accountability, Academic Freedom, Multi-Nationality, Quality Service,
Responsibility, Participatory, Excellence, Integrity, Fairness, Loyalty.
The University has the following powers and functions, from thus some’s are: Establishing educational
class, designing and deciding their levels, powers and functions where necessary. Designing, giving,
establishing and administering under and post graduate programs and short training based on the need of
the country. Designing modern library service and making it available for the users who were allowed to
use. Cooperating with the educational quality affairs agency. Asking payment for the given service when
necessary. Performing other related activities which help the achievement of the objectives.

Information Desk and Support System Page 2

1.2. Existing System Description
Every company or organization has at least one help desk system where are the complaints and queries
can be stored, resolved and saved for future reference. But as this Help Desk System in Assosa
University is worked manually, so it will take a lot of time and labor to solve all the problems of the
employees at a given time and even to handle too many customers at one time.
Individual has to spare his time and energy in order to obtain even the basic information regarding the
organization/campus. Apart from this there can be a long and tedious procedure in order to have a
solution regarding any particular query.
Manually the work is increased even, just like writing the whole data, query and other requirements,
apart from sending them message or replying them manually one by one. Even at the time of updating
information, it gets quite risky due to the increment in chances of errors to update the information by
oneself. Generally, there is no Information desk and Support System in Assosa University.
1.3. Problem of Existing System
In reality, our campus currently has a poor Help Desk management that leads to an inferior employees
experience and lack of performance from our campus support staff.
 Requester or someone who needs support do not to get a satisfied response based on what he
asks’ or complain at a time.
 The present system which is totally manual consumes a lot of time for a request to be satisfied.
And also It is difficult to identify solved, unsolved or escalated problem
 It is difficult to trace the assigned technician for a given problem
 It is difficult to identify solved, unsolved or escalated problems
 There is a long and tedious procedure in order to have a solution regarding any particular query.
Difficult to get clear information and this leads bad report generation
 Less co-operation and communication work habit. Manually the work is increased even, just
like writing the whole data, query and other requirements, apart from sending them message or
replying them manually (i.e. in paper).
 There is no system/site that provides information for employees and students, even for new
gusts who needs help in case of our campus information (e.g. where the ICT

Information Desk and Support System Page 3

Directorate is), this came again leads confusion and misinforming. There is no knowledge repository
that guides users to troubleshoot minor problems by their own
1.4. Proposed System Description
This new proposed Help Desk Management System is designed in such a way that all the processes and
steps are done online. And information which needs to be updates and exchange can be done effectively,
and thus increasing the efficiency of our campus and give the best services throughout the time for
customers. The help desk project enables users to get answer based on what they need for their support
issue. This help desk management project have been proven to make employees and student get support
in as much faster rate.
This project mainly developed for the sake of employees and students in our campus to get and solved
from their problem and also to get the feedback from their regarding the problems solution. Achieving
and maintaining a successful Help Desk management system can leads to the success of our campus as a
unity and facilitate the working environment with the need and request of employees.
This help desk management system will fulfil employees and students need by providing them related
support for their relevant issues as well as time period considered for solving the problems will be much
shorter. Helpdesk support system provides advice, consultancy, and support in all matters associated
with access to and use of ASU network infrastructure, including hardware and software maintenance.
1.5. Objectives of Proposed System
1.5.1. General Objective
The overall objective of our project is to develop Information desk and Support System For
Assosa University.
1.5.2. Specific Objectives
 To provide the customer or end user with information and support services related to our
campus or offices
 To provide first contact resolution as swiftly and efficiently as possible.
 To notify the help desk administrator about the unresolved issue at a time.

Information Desk and Support System Page 4

  To allow users view the details about each issues but he/she are not authorized to edit unless
he/she is the person who submit the issue.
 To Implement and test the new help desk system.
 To Provide the customer with standard instructions, or other Guides as a self-help solution
1.6. Scope in
This help desk management system is a web based application only for Assosa University. It’s
developed in English language, but it can be developed in any local language so that the Person’s using
this system can have a greater involvement and ease of understanding the system. And also our help
desk project will come up with the following features
 Authentication
 Request creation
 replay Response for requested issues
 Problem Assignment
 Chat Forum
 Report Generation
1.7 Scope Out
 Create a GPS navigator map for locate each places in our campus
 All actors in our campus are not included in our project
 Expert system are not included

1.8. Methodologies and Tools

1.8.1. Methodologies
1.8.1.2. Data Gathering Methodology

 Interview:-For the purpose of gathering requirement from students and employees we are
going to have frequent interviews with users who are expected to be users of the system that
we are going to develop.
 Observation: -to gather information that need physical observation that what problems visibly
for looking our team use observation method, By Observing the existing problem

Information Desk and Support System Page 5

  Document Analysis: to gather written information (such as information about background of
organization), and even some previously done project reports which are used as a reference to
look the flow of ideas to design the system that what we are going to develop. We used
document analysis.
1.8.1.3. Systems analysis and design methodology
1) In Analysis and Design: - Object Oriented System Analysis and Design (OOSAD) E-
DROWMAX using Unified Modeling Language (UML) Software, this enable to reduce the
communication gap between user and designers. Also enable for us to model the real world
accurately.
2) In Implementation
 Database (XAMPP)
 Programming language (HTML,Java script, PHP)
1.8.2. Tools
The programming tools that the project Will concentrates are the following:
 Software Tools:
 PHP Programming language
 Programming language
 xampp database
 Microsoft VISIO software: it supports to draw different UML modeling tools, we
use this application.
 MS word 2007: for documentation.
 Window 10 Operating system
 MS power point for presentation
 Hardware Tools:
 Printer: for printing document
 Computer RAM 4GB
 Secondary storage device
 flash disk(16 GB),Hard disk:478GB
 Paper, pen, projector, etc.

Information Desk and Support System Page 6

1.9. Significant of the Project
With the growth in information technology, our project offers numerous benefits to Assosa University
that deals on customers’ information and support.

 Resolving a service or help request quickly and seamlessly increases productivity.

 Reducing the working time for the users too, to solve their problems and queries in a
short time.
 It will create easy work environment
 It will Provide user friendly, well designed and dynamic web based solution
 Reduce the communication distance between the employees and the students.
 Provide available information for the intended customers in our campus
The main stakeholders and beneficiaries in our project will be Users (which may be students or other
external users), employees (teachers, lab-Assistance, and ICT officer) and students in our campus will be
benefited from the proposed system.
1.10. Work Plan (Time Table)
Table 1.1 Work Plan (Time Table) 1

Information Desk and Support System Page 7

1.11. Cost
The following Table shows the estimated cost for our project.
Table 1.2 cost value for our project
Project expenditure Quantity Unit price
sample smart phone 1 2000

flash disk(16GB) 1 250

Paper(A4 size),pens, - 200

print fees
Total 2450

Information Desk and Support System Page 8

 CHPTER TWO
System Analysis and Requirement gathering phase
2.1. Introduction
This chapter contains and describes about organizational work flow in our existing study area,
organizational business rule, requirement analysis of User requirement and system requirements,
Functional requirement, Non Functional requirement, essential use case, essential use case diagram and
use case description. And also in this chapter we will see different methods in gathering requirements.
Requirements are one of the most vital pieces to ensuring the success of our project. Information desk
and Support System helps customers to achieve goals and accomplish tasks within the contexts of their
primary work at a time. That helps track the customer support requests.

There are a number of approaches for obtaining the System requirements and each of these will be
Analysis, understand and examine the existing work flow of the organizations, what the organization
follows a rule and finally implementation of a helpdesk management system Explored in order to
acquire the broadest and deepest appreciation of what must be achieved in the system.

The output from the requirements capture must be analyzed to obtain a complete list of functional and
non-functional requirements that can then be used to design and implement the system. And also what
actors are participated in our system to generate a comprehensive requirements list.

As per the software part we would require XAMPP server for cross-platform web server solution,
consisting mainly of the Apache HTTP Server, MySQL database, and interpreters for scripts written in
the PHP.For programming purpose we would be using HTML, CSS, JavaScript and PHP.

Information Desk and Support System Page 9

2.2. Organizational work flow
In our campus the existing system is a system that is been carried out in terms of manual operation, A
system in which all the methods of checking customers information is of a manual approach. Searching
for somebody’s information, and if someone needs help it is time consuming and boring. Careful
analysis also shows that because of the complexities of the manual system, information stored is difficult
to retrieve.
For this project, we purposely select and use actors, those have their own functionality or responsibility.
Then in existing data flow process the one who needs help must goes to the office and ask help and
support to the concerned person with regard to his/her problem.
Even each individual customers and users have their own administrative management group, it is
impossible to work on their roles effectively, in case of manual and paper based administrative rules. ask
for help for the intended person, may be teacher or assistance or ICT teams on different issues in manual
paper based system or by going on their office, and do not get a satisfactory and short timely response
based on their issue. And teachers send a request and get a response on a tedious process by calling to
their cell phone or just going on the respondent office. And on lab-equipment and on-lab issues
assistance send a report manually to the intended ICT work team’s administration group, i.e. paper based
and can’t get a quick response on the issues. Then based on the reported issue the ICT work groups give
a response or solve a problem at a place, even they could not solve at a time.
2.3. Organizational business rule
In our study area rules and policies are very important to satisfy the customers and also for success of
the organization in its own business level, which used to govern all activities in specified work flow,
control the work flow, and performed in the work environment, that provides a way for our campus way
of doing business. Policies and rules in Assosa University in our helpdesk area are very important in
order to:

 Satisfy the business objectives.

 satisfy the customers based on their regarding issues
 Able to save time and give a consistent response when answering on help, support questions. So
the Information desk and Support System in Assosa University governs and controls the work
flow through the following rules:-

Information Desk and Support System Page 10

Even though, The help desk center does not have written or formal document regarding business rule but
implicitly there are some basic business rules are well aware in the university community

BR1: Fulfillment of problems Or Request, only properly filled forms are directed to the intended
information desk and help center, i.e. a person who needs any help and support must fulfill all
appropriation request form

BR2.any external users who needs any help or support even on location, Office finding must look on
direction locator or ask some university membership users.

BR3. As an obligation, support ICT Officers are not obligated to fix equipment’s which not the property
of Assosa University.
2.4. Essential use case with actor Identification
In this section we describe the interactions between external actors and the system under consideration
to accomplish a certain goal using essential use cases. An essential use case sometimes called a business
the case is simplified, abstract, generalized use case that captures the intention of the user in a
technology and implementation independent manner.

2.4. 1. Actors
Actor is a person, organization, or external system that plays a role in one or more interactions with the
system, in order to identify the actor’s specification process we have to focus on the following questions.
 Which user groups are supported by the help desk system to perform their work?
 Which user Entities execute the system’s main functions?
 Which user groups perform secondary functions, such as maintenance and administration? Based
on such above mentioned questions we identified the following actors in help desk system.

Information Desk and Support System Page 11

 Name: users

Description: they are a major university communities whom they will request for the different
facilities of the campus, including external users.

Name: Employees

Description: they can also create a request tickets, may give response for the users (those are
teachers, lab-assistance and others)

Name: Helpdesk Administrator

Description: able to add more users in our system specification to the system, manage for all the
user accounts and requested issues to check whether they are solved or not.

Name: ICT-officers

Description: Receive Requests and make a decision for those problems

2.4.2. Essential Use Cases

Essential Use case is a list of steps, typically defining interaction between a role of actor and a system to
achieve a goal. is in the form of a dialogue between the user and system which helps to support better
communication between requester and respondents using functional system.
In Our industrial project, our system purpose or intentions underlying on the interaction of users to
achieve Users requirements and goal also our project encompasses on the concept of system
requirement, The user perspective view of system, how to Test the system in terms of examining is our
system satisfy the users in our system, set of requests with appropriate response on their regard issue.
Our project also focus on the Communication of end user with domain experts.
Essential use case in our system begins when someone in our campus goes for help or send a request
report, just on proposed system logged-on the page, then in the existing system the users/customers that
needs help on the paper form fill and send those reports or by going on a place, or they can take their
own measurement for addressing their issues. Then based on their issue the concerned respondents give
and generate a response, but the process is a time

Information Desk and Support System Page 12

Consuming and may get a non-satisfactory result. As a simple representation and descriptive way the
essential use case format labels the columns user intention and the response of the helpdesk system.
Table 2.1. Essential use case
User intention helpdesk system
Goes for help or send a request report(for concerned respondents give a response
existing system),but first users must be legal
members
Select on help menus from the list Supplies or display request report form
Description of the problems Offer possible solution

The essential use case describes a sequence of actions that provide something of measurable value to an
actor. Thus, it determine who (actor) does what (interactions) with the system for what purpose (goal)
without dealing with system intervals.
1. Generate a Problem or create requests
2. Replay a response for queries and register those solutions as a reference
3. Register users that may be respondents or requesters.
4. View Status of requests
5. View responses
6. View all requests with their response

2.4.3. Essential use case diagram

Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions that on
help desk systems should or can perform in collaboration with one or more external users or requesters
of the system [4]. Each use case should provide some observable and valuable result to the actors or
other stakeholders of the system.it is an abstract technology independent view of the behavioral
requirements.

A use case describes how the system should respond under various conditions to a request from one of
the stakeholders to deliver a specific goal. Whenever we discuss the requirements of a system we
recognize one or more people or things that have an interest in the behavior of that

Information Desk and Support System Page 13

System. These are called the stakeholders of that system. Use case diagrams provide an insight into
specifying the roles the users perform.

A Use Case diagram provides not only a simple way of communicating ideas with users but also, when
complete, produces a high level understanding of what must be achieved in the system. It’s very
important and crucial aspects, follow the basic Steps, from those: Define the actors, define the goals,
Determine who primary and secondary actors is.

The use case diagrams is a graphic description that represents the methodology used in the system
analysis to identify, clarify and organize system requirements of help desk management system. The
main actors of helpdesk management system in our project in this use case diagram are: administrator,
Employees, ICT-officers, and Users who performs the different type of use cases operations.

The relation between and among the actors and the function use cases of helpdesk system:
 Administrator entity: use cases of this actor are manage requests, manage user’s account of our
system and full helpdesk system. Doing on the Admin-level functions such as creating accounts,
look at the created request texts and Assign Requests to the Officers or engineers. And also the
admin looks each communication on help and support issues and complaints from unsatisfied
users and assign those requests again to the concerned people for management purpose
(Administrator),and also provide information for gusts those need any help request
 Employee entity: use cases of those actors are create or send a request on different issues., view
requests, view responses, replay responses.(teachers, Lab-assistance)
 ICT-officer: use cases for those actors are manage for requests and give a reply response on
those issues
 Users: These are the users who will request for the different facilities of the campus on different
issues, including gusts those need help and support regarding on their issue.
As soon as a request text is created, the request report should be sent to the person who have the
responsibility, and stand and enroll for the request that contain the request details.

Information Desk and Support System Page 14

The activities that a user’s/requesters can perform, of which viewing a list of requests he/she can make
and submitting a request are the major one, and based on those generated problem he/she got a replay
response.

Fig 2.1. Essential Use case Diagram

Information Desk and Support System Page 15

2.5. Description of Essential Use Cases
To describe the use cases, there are different types of formatting’s and techniques that are available to
describe use cases in detail. In case in our project we use most widely used and shared format created by
Alistair Cockburn [4].
Table 2.2 Description for Essential Use cases
Use case contents Statement
Use case ID and use case name Use case identification
Actor Calls on the system to deliver its
services
Precondition What must be true on start, and
worth telling the reader
Post condition What must be true on successful
completion, and worth the telling
the reader.
Stakeholders and Interest Who cares about this use case, and
what do they want
Basic course of action A typical, unconditional happy
path scenario of success
Alternate course of action Alternate scenarios of success or
failure.
Name: Request
Identifier: UC001
Description: Submit or create a request for help
Actor: User such as users, employees can create a report of requests
Precondition: the user is authenticated through their identity and legal membered name.
Post condition: The request will be registered.
Stake holders and Interests:
 Employee: main Stake holders who wants to create and submit issues accurately and
diligently to the responsible concerned person.
 ICT-officer: persons able to record each problems and replay for requests to
satisfy users

Information Desk and Support System Page 16

  users: they can also able to create a requests, may be regarding to computer maintenance
purpose, including external users or gusts
Basic course of action:
1. The use case begins when the users, employee’s wants to create a request for help.
2. The above mentioned users identified through valid identity ID, and treated based on the
business rule [ALTCA A]
3. The user or employee inputs name, faculty, department, office number, telephone, email date,
problem type and description. If the problem type is like hardware problem. [ALTCA B]
4. End use case
Alternate course A: The user is not legal member
A2: if the users or employees are not legal members and fill inappropriate form detail
A3: The administrator informs to retrace the user he/she is not legal member to request for help.
A4: The use case ends.
Alternate course B: The hardware is not at or for ASU property
B4: The administrator informs the user he/she cannot get the service.
B5: The use case ends
Name: register applied solutions for problems
Identification: UC002
Description: If a given problem is solved then those techniques to solve that problem are
registered as future reference.
Actor: Helpdesk ICT-officer
Precondition: The Helpdesk ICT-officer are identified and authenticated through organization
business rule. The specified problem must be solved problem.
Post condition: Problem finding and solving techniques are recorded. Problem report can
updated.
Stake holders and Interest:
• Helpdesk ICT ICT-officer– wants to record and update their finding solution for reference in
case of in another day the same kind of problem might be reported.
Basic course of action:

Information Desk and Support System Page 17

1. The use case begins when the Helpdesk ICT-officer (for specified problems) indicates they
want to record their finding solution.
2. The ICT-officer are identified his/her legality through organization business rule [ALTC A]
3. The ICT-officer looks for those problems their own problem type catalog. [ALTC B].
4. The ICT-officer record the finding Solution
5. End use case
ALTC A: If the user is not valid
A2: if the ICT-officer are not legal members to record solutions for each problems.
A3: ICT-officer cannot register the finding solution.
A4: The use case ends.
ALTC B: If there is no problem result
B3: The ICT-officer cannot get it and cannot record for solution to specified problem.
B4: The use case ends.
Name: Generate report
Identifier: UC003
Description: The ICT-officer, administrator wants to generate a consolidated report.
Actor: ICT-officer, administrator
Precondition: The actors legal membership, identified through organization business rule.
Post condition: obtain a compiled report
Stake holders and Interest: ICT Officer & Helpdesk Manager, both can generate a report
Basic course of action:
1 Assume that both actors are legal members of the organization
2, they Report to fill on Generation Page,
3. They prints the report.
4. End use case
Name: View response/information
Identifier: UC004
Description: view or Check responses for a given requested problem
Actor: Administrator, employee, users, ICT-officer.

Information Desk and Support System Page 18

 Precondition: all those the actors are identified to be legal for their legal membership in our
campus.
Post condition: all those actors will get full information regarding to the requested and specified
problem.
Stake holders or interest: Administrator - wants to know the specified problem in Order to
check whether users are satisfied on solution or not, to make decision.
Other actors what we mention above – wants to know to get response based on their regarding
issue, and also can get information.
Basic course of action
1. The use case begins when the actors wants to View response/information of problem.
2. Those actors are identified for legality through organization business rule. [ALTC A]
3. The actors asks by going on respondent office to View response and get information for the
specific problem.
4. Then, if they were request or generate for their problem then, they can view for the response
report and can get information on what they want to know
5. End use case
ALTC A: The whole users are not legal members of the organization
A2: They cannot view or get information on problem Findings.
A3: The use case ends.
2.6. Requirement analysis
As stated in the objectives, the proposed system is intended to replace the current system and bring new features and
functionalities while minimizing complexity and maintaining user interface simplicity.
The system to be designed will implement web based application within the intranet of ASU. Every user of the system
will be authenticated with respect to the appropriate user identification and password credentials while logging to the
system through the web interface. Then the user will be authorized to access the respective sub modules only.
Moreover, the system includes the following functionalities. The main tasks with each module functionality are data
entry, updating when necessary, viewing and reporting.
2.6. 1. Functional Requirements
Based on the Use Case diagram above, a list of requirements is produced at a lower level of abstraction
to that the design and implementation incorporate the appropriate functionality. One of the minimum
requirements for the project is to produce “a suitable prototype call logging system with the ability to
track cases and create reminders for support staff.

Information Desk and Support System Page 19

The different users of the system students, Teachers, CT-work teams, administrator and Lab- assistance
carry out different activities in our system. The proposed system perform functions and enable us to:
Helpdesk support system should help
 Submitting request by allowing the user filling the necessary information on the online problem submitting
form.
 Viewing all submitted requests or problems with an updating of status on each request activities in different
role types
 Support in all matters associated with access to and know ASU (provide information), even offices, including
other hardware and software maintenance technical support to the university community through different
channels like request form or chat forum discussion.
 View all submitted requests or problems and submitted reports on categorical dashboard structure with their
status
 Register helpdesk system users and engineers by allowing the system administrator by filling the necessary
information on the Information desk and Support System user registering form.
 Viewing all system users and engineers and enables for administrator add or remove the system users.
 Assign Engineer Officers or ICT officers for reported problems
 Posting or displaying different types of information’s ,notice to users

2.6.2. Non Functional Requirements

The non-functional requirements for the system form a set of the main desires of the users interviewed.
It is wished that the system currently in place is improved upon in terms of the user interface. The
security aspects must kept simple by relying on the user credentials entered when the user first logs in to
Windows and, finally, the system must be easy to manage from a technical point of view. Those
requirement specifies criteria that can be used to judge the operation of a system which specifies how the
system performs a certain function considerations when designing the solution

Information Desk and Support System Page 20

Non Functional requirements mainly focus and specify on constraints on how the system will do so.
Those requirements are also describe the performance characteristic of the system and also related
concepts to the system attributes such as reliability and response time, those issues are mainly arise due
to user requirements.

Non-functional requirements cover aspects of the system such as user interface, performance, quality
issues, security that the system must fulfill. The following are non-functional requirement associated
with the Information desk and Support System:-

 The front end of the system will be developed using PHP and JavaScript while the database will
be built with XAMPP Server. The Helpdesk system will be:
 Implemented with minimal cost as the existing infrastructure and open source software will be
used
 Easy to use as easy user interface will be used and users can access the system just from their
office and can look for the progress of the problem.
 Scalable as new users can be easily added so as to use the system
 Secured as only authorized users can login to the system and access is limited to authorized users
only
 Easy to deploy as hosting is on the existing servers and accessing requires any available browser
 Validating data entry at the web form (user interface)
 Easily maintainable when the configuration demands change With optimal performance where the
system should be able to complete most tasks
 instantly and confirm the user With backup and restore facilities at the server
 The system will be available 7 days a week and 24 hours a day. And A measure of how often a
system’s resources and services are accessible to end users, often expressed as the uptime of a
system

Information Desk and Support System Page 21

 Chapter Three
System description and Design
3.1. Introduction
In this chapter we produce an Object-oriented analysis model of the ASU Online Web Based Helpdesk
System, by describing the application domain from the specification produced in chapter two. We focus
on the identification of objects, their behavior, their relationships, their classification, and their
organization. In This Object-Oriented Analysis model is a produced deliverable model of the system and
we use it, together with non-functional requirements, to prepare for the architecture of the system
design.

This chapter is organized in such a way that we start by presenting a system use case modeling followed
by sequence diagrams, class diagrams, activity diagrams, UI prototypes, Collaboration diagram and
Deployment Diagram are included. It is composed of the functional model represented by system use
cases and UI prototypes, the analysis object model represented by class diagrams, and the dynamic
model represented by sequence and activity diagrams. We use the Unified Modelling Language (UML)
graphical notation as our Object-oriented analysis tool. The UML is a general-purpose visual modelling
language that is used to specify, visualize, construct, and document the artefacts of a software system.

Finally, we describes the whole Architectural Design of the ASU Online Web Based Helpdesk
Management System.
3.1.1. The Interaction Levels of IDSS
In our help desk system three hierarchical levels of services will be provided: at the User Level, at the
Supporter Level and at the Administrator Level.

1. At User level:

It is the most basic module level. The user will create a request, discuss and look on chat forum platform
up on different categorical issues and topics.
Form by stating the problem. The system solve problems by the expertize persons or ICT officers in the
corresponding domain based up on the requested Assigned priority level.

2. At Employee level:
In this module level, The Employees can create a request form by stating the problem type. Then, the
system solve problems by the expertize persons in the corresponding domain based up on the requested
priority level.

Information Desk and Support System Page 22

3. At Supporter level:
Expert persons in several domains. It is the supporter’s responsibility to accept the requests assigned
either to themselves or to the group they belong to and trying to solve those problems

4. At Administrator level:

The administrator is responsible to manage the resources, communication among requesters and
respondents for management purpose and to examine the requester can get a good response in terms of
time or on their prospective need, if not it sends to the intended concerned respondents by accepting
feedback or complaints, add or remove users or expert persons and keep the helpdesk system in good
shape. The admin also have a responsibility to assign a requests to a list of ICT officers that have been
registered.
3.2. System use case
A system use case ontology constitutes a sequence of actions that provide a description of a slice of system
functionality as visible to an actor. These actions are just dialogues between the actor and the system.
In Our helpdesk system use case constitutes a sequence of actors and use case function that develop a
measurable value to an actor another way to look at it is that a use case describes a way to which a real
world to interacts with the system. That provides a description of system functionality as visible to an
actor. A system use case includes a high level of implementation decision beyond an essential use case.
System use case is a task case model of the system.
It is a concrete and detailed use case model of the analysis of the behavioral requirements, describing in
detail how users will work with the system, including references to its user-interface aspects. A system
use case modeling activity involves the Actors, Use Cases and Use Case Diagramming tasks as
described in the subsequent sections bellow.

Information Desk and Support System Page 23

3.2.1. Actor Identification
Actor in our system is anyone that interacts with the helpdesk system. This may include people, external
systems, and other organizations. The identified actors of the system have name and description. We
identify the following as actors in our helpdesk system:-

 User
 Administrator
 Employee (or) help desk servant and,
 ICT-officer
Generally, actor means something that initiates, stimulates the system to react or something that
responds to the systems requests.
3.2.2. Use case Identification
This is primarily done in the form of a scenario that describes a sequence of steps
 Register system users
 Login to the system
 Request creation
 replay Response for requested issues
 Problem Assignment
 Report Generation
 manage system users
 View Request status
 Delete records, Update user information
 Discussion Forum that gives information about various programming languages, general knowledge related
questions, information related questions,etc

Information Desk and Support System Page 24

3.2.3. use Case Diagram
A representative way, and describe the behavior of the Helpdesk system from an external point of view
where it displays a visible result to the actors. The identification of actors and use cases done before
results in the definition of the boundary of the system where the tasks accomplished by the Helpdesk
system and the tasks accomplished by its environment are specified. In the diagram the actors are
outside the boundary of the system, whereas the use cases are inside the boundary of the system.

Information Desk and Support System Page 25

 Fig3.1.System Use case diagram

Information Desk and Support System Page 26

3.3. System use case description
Narrative Use case Description Style
Name: Login
Actor: Employee, ICT-officer, Users and Administrator

Identifier: UC001

Description: This use case describes the process by which actors mentioned above logs into the
system to perform do their own specific task.

Pre-condition: All actors must have a valid user name and password

Post condition: Successfully logs into the system and is re-directed to their own main page.

Stake holders and Interests: Those All Actors Has Their Own Specific Operation or Purpose
for What They Are Logged in to the System, as described in the above system use case diagram.

Basic Course of Action:

1. Actors enter and submit his/her user name and password.

2. The system validates and authenticates the user information (A1) (A2).

3. Login successful and the system re-direct its own home page.

4. End of use case

Alternate Course of Action: If account is not available. (A1)

1. The system displays a message indicating to enter user name and password.

2. Continues at basic step #1. (A2)

1. The system displays a message indicating that the user name and/or password are incorrect
and to try again.

2. Continues at basic step #1.

Information Desk and Support System Page 27

User Action System Response description Style
Table 3.1 login use case description

use case name Login

Use case ID UC001
Actors Employee, ICT-officer, Users
and Administrator
Description actors mentioned above logs
into the system to perform do
their own specific task
Precondition All actors must have a valid
user name and password
Post condition Successfully logs into the
system and is re-directed to
their own main page
Basic User action System response
Basiccourse
courseofof
action
action
1. Actors enter and submit 2. The system validates and
his/her user name and authenticates the user
password. information
3. Login successful and the
system re-direct its own home
page.

Alternate course of action 2. Continues at basic step #1. 1. The system displays
a message indicating that the
user name and/or password are
incorrect and

Information Desk and Support System Page 28

Name: Register Users
Identifier: UC002
Description: register employees, ICT-officer who are members in ASU.
Actor: employee, ICT-officer
Precondition: the Admin must be logged in and authenticated.
Post Condition: all the employee, ICT-officer will be registered.
Basic course of action:
1. Assume that the admin is in the system.
2. The system displays UI registration page
3. The admin inputs all required basic information of whom registered actors
4. The system registers the employee, ICT-officer.
5. End use case
Alternate course of action: The admin may miss required information of the register users

A3: The system tell him to fill all appropriate information and continue, if true

A4. System informs successfully registered the employee, ICT-officer

A5: The use case ends.

Information Desk and Support System Page 29

 Table 3.2. Register use case description

use case name Register Users

Use case ID UC002

Actors employee, ICT-officer
Description register employees, ICT-
officer who are members in
ASU
Precondition The Admin must be logged in
and authenticated.
Post condition All the employee, ICT-officer
will be registered.

Basiccourse
Basic courseofof action
action User action System response
1. The admin is in the system. 2. displays UI registration
3. The admin inputs all page
required basic information of 3. Login successful and the
whom registered actors system re-direct its own home
page.

Alternate course of action 2. Continues at basic step #3. 1. system tell him to fill
all appropriate information and
continue, if true:-
3. System informs successfully
registered the employee, ICT-
officer

Information Desk and Support System Page 30

Name: Request

Identifier: UC003

Description: Submit or create a request for help

Actor: User such as Users, Employees, and ICT-officer can create a ticket of requests

Precondition: the user is authenticated through their user name and email password.

Post condition: The request will be assigned. Finally, the request will be responded by

changing its status.

Stake holders and Interests:

 Employee: main Stake holders who wants to create and submit issues accurately and
diligently to the responsible concerned person.
 ICT-officer: persons replay for requests to satisfy users based on its assigned work and
status automatically change after the event.
 users: they can also able to create a requests, may be regarding to computer maintenance
purpose, including external users or gusts
Basic course of action:

1. The use case begins when the users, Employees or, ICT-officer wants to create a request for
help.

2. The above mentioned users inputs user name and password to the system via log-in user
interface page.

3. The system verifies or check that the users are valid to submit the request based on their role type. [ALTCA]

4. The help desk system Displays submit problem page.

5. The users, employees and ICT officer inputs Request Type, office number, Block Number,
and description. First their request status is open by default.
6. End use case

Information Desk and Support System Page 31

Alternate course A: The user is not valid

A3: The system counts the number of wrong entries and determines the course of action

A4: The system informs to retrace the user he/she is not a valid to request for help.

A5: The use case ends.

Table 3.3 request use case description

use case name Request

Use case ID UC003
Actors Users, Employees, and ICT-
officer
Description Submit or create a request for
help
Precondition All actors authenticated
through their user name
Basic course of action and email password
Post condition The request will be
assigned,

User action System response

Basic course of action
1. Actors inputs user name 2. system verifies or
and password to the system check that the users are valid
via log-in user interface to submit the request
page. 3. system Displays submit
4. Actors Inputs required problem page
information, problem type 5. The admin system Assign
and description. requests to the ICT officers
Alternate course of action 2. Continues at basic step #1. 1. if not valid user, retrace
the user he/she is not a valid
3. System informs
successfully sent the request

Information Desk and Support System Page 32

Use case name: chat
Actor: users, employee, CT-officer and Admin
Identifier: UC004

Description: Forum chat communication, exchange information related to various topics.

Flow of event

1. The user select “Chat forum “link.

2. The system displays the forum chat dashboard page.
3. Then select for list of topics that what the user want to communicate and writes text and click on “send”
button.
4. The system transfer message to other end user.
5. Use case ends

Alternative course of Action

5.1 If the actors fill invalid values to the system or not fill the filled, prompt to fill correct
input.

Pre-condition: all the actors must logged using their valid address (user name and ID)

Post condition: the user able to get and exchange information on

the selected topic in chat forum platform.

Use case Name: give or type a solution and post for problems

Identification: UC005

Description: If a given problem is solved then those techniques to solve that problem are
registered as future reference for others.

Actor: Helpdesk ICT-officer

Precondition: The Helpdesk ICT-officer are identified and authenticated. The specified problem
must be solved problem.

Post condition: Problem finding and solving techniques are recorded and posted for the users.

Stake holders and Interest:

Information Desk and Support System Page 33

• Helpdesk ICT-officer – wants to record and update their finding solution for reference in case
of in another day the same kind of problem might be reported and also post for discussion.

Basic course of action:

1 The use case begins when the Helpdesk ICT-officer (for specified problems) indicates they
want to record their finding solution.

2 The Helpdesk ICT-officer inputs user name and password in to the system via UI02 log-in
page.

3 The system verifies that those ICT-officer are valid to record their finding solution into the
system. [ALTC A]

4 The ICT-officer looks for those list of status problems. [ALTC B].

5 5 The system displays problem status list via UI 14 problem status list page.

6 The ICT-officer post the finding Solution to the system 7

7.Update the records in the Database.

8 End use case

ALTC A: If the user is not valid

A3: The system checks the trial number of wrong entries and determines the course of action. If
the entry value is not correct.

A4: The system informs to the ICT-officer he/she is not a valid user to register the finding
solution.

A5: The use case ends.

Information Desk and Support System Page 34

Name: Check problem status
Identifier: UC006
Description: Check a given problem is closed, open or worked
Actor: Administrator, Users, Employees, ICT-officer.
Precondition: the actor is identified authenticated.
Post condition: The actor will get full information regarding to the specific problem.
Stake holders or interest: Administrator - wants to know the status of the specified problem
User – wants to know current progress of his/her problem.
Basic course of action
1. The use case begins when the actor wants to check the status of problem.
2. The actor inputs user name and password in to the system via UI log-in page.
3. The system verifies that the actor is valid to check the status of the problem. [Alt Course A]
4. The system displays the status of the problem via UI14.
5. End use case
Alternate course A: The user is not valid
A3: The system checks the number of wrong entries and determines the values. If it’s wrong
A4: The system informs the actor he/she is not a valid user to check the problem status.
A5: The use case ends.
Name: Assign ICT officers
Identification: UC007
Description: Assign ICT officers for a given problem
Actor: Administrator
Precondition: The Administrator is identified and authenticated.
Post Condition: ICT officers will be assigned.
Stake holders and Interest: Administrator – need to assign ICT officer for each new arrival problem.
Basic course of action:
1. The use case begin when the Administrator want to assign ICT officer.
2. The Administrator inputs user name and password via UI log-in page
3. The system verifies that the Administrator is valid to see outstanding problems. [Alt Course A]
4. The system displays outstanding problems UI problem status list page.
6. The Administrator assigns ICT officer for thus specified request.
7. End use case

Information Desk and Support System Page 35

Alternate course A: The user is not valid
A3: The system the entries that are wrong and determines the values. If then,
A4: The system informs the user he/she is not a valid to request for help
A5: The use case ends.
Name: Logout
Identifier: UC009
Actor: Employee, ICT-officer, Users and Administrator
Description: it is activated when those logged user of the system logout after finishing their task
properly.
Basic course of action: those went to logout from the site. Then they simply click on logout button.
3.4. Sequence diagram
Sequence diagrams are used to model the logic of usage scenario; usage scenario is exactly what its
name indicates-the description of potential l ways your system is used. The project team has modeled
sequence diagram for each use case identified in use case modeling part.

Figure 3.2: Login (SD#001)

Information Desk and Support System Page 36

 Figure 3.3: Registration for Users (SD#002)

Information Desk and Support System Page 37

 Fig3.4. Sequence diagram for create request/post problem UC#003

Information Desk and Support System Page 38

 Fig3.5. Sequence diagram for Assigning Requests to the Engineers by admin UC#004

Information Desk and Support System Page 39

 Fig3.6. Sequence diagram for Registration of Offices UC#008

Information Desk and Support System Page 40

 Figure 3.7: Engineers (ICT officers) View Problem Status (SD#006)

Information Desk and Support System Page 41

3.5. Activity diagram
Activity diagrams are used to model workflow or business processes and internal operation I our
Helpdesk system. A Unified Modelling Language activity diagram is used to document the logic of a
single operation/method, a single use case or the flow of logic of a business processes. We modeled
activity diagram for each use cases identified in use case modeling part.

Fig 3.8. Activity diagram for login system

Information Desk and Support System Page 42

 Fig 3.9. Activity diagram for create request/post problem

Information Desk and Support System Page 43

 Fig 3.10. Activity Diagram for Check Problem Status

Information Desk and Support System Page 44

 Fig. 3.11. Activity Diagram for Generate Report

Information Desk and Support System Page 45

 Fig. 3.12. Activity Diagram for Register Employees, ICT-officer

3.6. Class diagram

Our system class diagram shows the classes of the system that used to represent the structure of the
system in terms of objects, (including, inheritance, aggregation and association), and the operation and
attributes of the class), their notes and nature of relationship between classes. Attributes are the
information stored about an object while methods are what the object or the class does. To describe a
class we define the attributes

Information Desk and Support System Page 46

And methods. Attributes are the information stored about an class object while methods are what the
object or the class does.

Figure 3.13: Class Diagram of the ASU IDS system

Information Desk and Support System Page 47

3.7. Essential user interface prototype
An essential user interface prototyping is a prototype that is sketchy and incomplete, that has some
characteristics of the target product but is otherwise simple, usually in order to quickly produce the
prototype of user interface for the helpdesk system. It presents the general ideas behind the user
interface, but not the exact details. In our helpdesk system we identified the following major user
interfaces.

Request for Help (submit Problem)

Last Name input Field,

First Name input Field, characters characters only
only

College List, FaculityName Department List, Department

Name

Block number: type number

Telephone No, List Character

Floor/Office Number Description of problem, Input

Input field. Character and number Field Character

Date and Time List Date and

Email Input Field: Character Time

Help Topic/Problem Type List

Fig. 3.14 User Interface Prototype for Create request/Problem for help

Information Desk and Support System Page 48

 Check problem status

Search by Request ID Label, Request ID input Field, Numeric

character only

Problem Status

Request ID Input field, Numeric

Request ID, Label Numeric only

First Name Last Name

Reported By, Label character only characters only
characters only

Request
Fig. Description,
2.3 User Label
Interface Prototype for Check Problem
Status.
Character only
Fig. 2.3 User Interface Prototype for Check Problem
Description of problem, Input
Sta Field Character

Fig. 3.4Label,
Status User Interface Prototype
Characters only for create request/ Problem for
help Status input field i.e. solved,
not solved

Date Created, Label Date and Time Date and Time List Date and
Time

Fig. 3.15 User Interface Prototype for Check Problem Status

Information Desk and Support System Page 49

 Generate Report

By Status Generate Report by

Category
By Problem

By Date

Display Here

Fig. 3.16 User Interface Prototype for Generate Report

ONLINE-HELPDESK LOGIN PAGE

Login Here

User Name Label Username Input Field

Character only Character

Password Label Password Input Field

Character password

Login
3.9. User interface flow diagram
New user? Create account

Fig. 3.17 User Interface Prototype for Login page

Information Desk and Support System Page 50

 አሶሳ ዩኒቨርሲቲ

ONLINE-HELPDESK MANAGEMENT SYSTEM

Home About ASU Contact Us View Information Help Login

Searc
h

ASU HDMS

* ASU Site MAP

* ASU Site

1 2 3 4
* Digital Library

ASU Social Links

* Facebook

* Twitter

Copyright Reserved By: Group Seven

Fig. 3.18 User Interface design for implementation Home page

Information Desk and Support System Page 51

3.8. User Interface Flow Diagramming

: Public page

: Login : create account

page

: Main
page

Problem Report page View : Chat page

page

: Problem status : College & department

: Office : Response

Fig3.19. User Interface flow diagram for Users

Information Desk and Support System Page 52

 Public Page

Home about ASU Contact Us View Information Login

Search

ICT officer Users

Administrator
Employees

Manage Create Create

users response Create account
request
Manage View Create
request response View request
response
Register Create View
College request View office response

Manage Check
View request problem
reports View status
College

View View View

Register
report department College/dep’t
office
t

Assign View office

Requests
Chat

Fig 3.20. User Interface flow diagram for Users

Information Desk and Support System Page 53

3.9. User Interface Design
3.9.1. User Interface design for Login Page

3.9.2. User Interface design for Admin Menu Page

Information Desk and Support System Page 54

3.9.3. User Interface design for Employees create request

3.9.4. User Interface design for admin assign requests to ICT Officers

Information Desk and Support System Page 55

3.9.5. User Interface design for add ICT Officers by admin

Information Desk and Support System Page 56

3.10. Collaboration diagram
A collaboration diagram is an illustration of the relationships and interactions among objects in the
unified modeling language. Collaboration diagram shows the message flow between objects in an object
oriented application and also implies the basic association between classes. It is used to show the
behaviors of several objects collaborating together to fulfill a common purpose. Collaboration
diagram typically focus on the structure organization of objects that send and receive message.

Fig. 3.21. Collaboration diagram for create Request problem

Information Desk and Support System Page 57

 Fig. 3.22. Collaboration diagram of user registration

Information Desk and Support System Page 58

Fig. 3.3 Collaboration diagram for problem Status ICT officers

Fig. 3.23. Collaboration diagram for Login

Information Desk and Support System Page 59

3.11. Deployment Diagram
Deployment diagram describe the basic static view at run-time configuration of processing nodes ,and
the components that run on those nodes. In other words, deployment diagrams show the hardware
requirement for the system, the software installed on that hardware, and the middleware used to connect
the Distributed/different located machines to one another.

Fig 3.24. Deployment diagram

Information Desk and Support System Page 60

The figure above illustrates a typical three-tier application deployment diagram. Client applications
communicate with the web server using a standard protocol such as HTTP. The client machine can be
installed any workstation operating system and at least it should have standard browser software.
The web server can be installed windows server based operating system which support apache web
service. The web server communicates with the database using MYSQL connector.
3.12. Architectural Design
The class type architecture provides a strategy for layering the classes of our software to distribute the
functionality of our system among classes. Layering is the concept of organizing our software
design into layers/collection of classes or components that fulfill a common purpose, such as
implementing our user interface or the business logic of our system. This architecture depicts the
interactions between classes. This IDSS uses the five layered class architecture for the design of object
oriented software. The five layers of classes are UI Classes layer, Controller/Process Classes layer,
Business/Domain Classes layer, Persistence Classes Layer, and the System class’s layer. Let Us
Describe Each of Layers before DesignThe Diagram as follows.
3.12.1 User Interface Layer
User interface layer classes contain a code for the user interface part of an application. It
implements the major user interface elements of the system. Designing the user interfaces for the IDSS
involves the following major interfaces which are system login screen, main menu, Inquiry display
screen, problem accepting screen, user registration screen, report generation screen and so on.
3.12.2. Controller/Process Layer
The purpose of a controller/process class is to implement business logic that pertains to several
objects, particularly objects that are instances of different classes. The Controller classes in the IDSS are
Validate login entry, accept problem, accept user, accept feedback, Generate report.

Information Desk and Support System Page 61

3.12.3. Business/ Domain Layer
Business/domain class, also called an analysis or entity class, usually they’re identified during system
analysis. The business layer enables you to encapsulate the basic business functionality without having
to concern yourself with user interface, data management or system management issues. Business
classes of the IDSS are user, problem, Admin, Employees, ICT officer.
3.12.4. Persistence Layer
The persistence layer provides the infrastructure for the storage and retrieval of objects. It helps to
isolate the application from changes to permanent storage approach. The persistence layer by
encapsulating data management functionality it increases the maintainability, extensibility and
portability of our application. The persistence layer only provides access to permanent storage. It is not a
permanent storage mechanism. The goal of the persistence layers to reduce the maintenance effort that is
required whenever changes are made to our data. The persistence classes of the IDSS are user, problem,
Administrator, Employee, ICT officer, and user.
3.12.5. System Layer
The system layer provides access to the operating system and non-object oriented resources. The
operating system must fit the software we develop in a manner that whenever there is modification made
on some classes, the operating system must not be disturbed by that change. The system class for the
most part encapsulates operating system functionalities that we need to make accessible to the objects
with in an application. It is common to wrap a series of operating system calls to provide a related set of
functionality.

Information Desk and Support System Page 62

3.12.6. Architecture
The architecture shows the interactions between the five layers of the IDSS as follows.

UI Layer
System login screen S
Main menu
Problem Accepting screen
Findings accepting screen Y
Searching screen Office, Campus,
Building registration screen
User registration screen
S

Controller/Process Layer
T
Validate login entry
Accept/ Modify User
Accept/Modify Problem E
Accept/Modify/Delete/Search
Equipment

M
Domain
Layer

User, Administrator, C
Problem, Campus,
Department, Office, Building,

L
Persistence Layer

User, Administrator,
A
Problem, Campus,
Office,
Equipment, S

DB

Figure 3.25.: Layered class type architecture for the IDSS

Information Desk and Support System Page 63

 Chapter Four
System Implementation and Testing
4.1. Introduction
This chapter deals with the implementation of the web application. Before the application is to be
posted on a server and put to use, it needs to be tested using different mechanisms. For this
purpose, unit testing and system testing will be performed using different input data. To develop
the code for the application, we will create algorithms that can guide us through the different
steps of the code. The algorithms help us to facilitate coding, to make easier debugging process
and to control the system flow. The algorithms will be supplemented by flowcharts.
This chapter also covers the actual coding of the application. The backend of the system is
implemented using SQL database Server. For connecting the backend database with the front end
interface, we have made use of html web pages. This chapter presents algorithm design, flow
chart for each algorithm, Hardware and software acquisition, user manual, testing, installation
and start up strategy.
4.2. Algorithm Design
We design algorithm for controller class member function. This design enables us to see every
step and flow of logic in each function. It is important in the coding part of the implementation.
The following is the list of class member functions obtained from the relational persistence
model:
MakeRequest ()
AssignRequest ()
CloseRequest ();
DeleteEngg ()
DeleteCust ()
AddCust ()
EditEngg ()
EditCust ()

Information Desk and Support System Page 64

The above list indicates that the main processes are categorized as adding data to database and
Modifying it, and finally viewing inquiries or reports, assigning requests. The system also
validates a user as Part of the login process. Therefore, we design algorithms as a sample in this
paper for the: Add problem process.
4.2.1 Algorithm for MakeRequest ()
The “MakeRequest ()” member function of the “Problem” class checks data completeness and

creates a new problem and record in the database. the values view require only selecting from

the available lists. “AssignedTo”,”StatusView”, “ActionSolved” and “EnginnerName” data

members are the columun views. Successful login is a default prerequisite for this task and the

next remaining algorithms as it is a checking gate for any operation in connection with the

OIDSS. The following are the four steps.

For the algorithm of the “MakeRequest ()” function.

1: Validate Login through “Check User()” function.

2: IF login is valid

2.1: Fill the input data described in the data members of the “Request” class.

2.2: IF the filled input is valid

2.2.1: Register problem in the database ( ).

2.2.2: Display Views (“The new record is ‘status’open” as initial)

2.3: Else

2.3.1: Display Error Message ( )

2.3.2: Go to step 2.1

3: ELSE

3.1: Display Error Message ( )

3.2: Go to step: 1

4: END

Information Desk and Support System Page 65

4.3. Flow Chart Diagram
Flowchart diagram enables programmers to translate an algorithm to more than one
programming language. The diagram represents the logical sequence of instructions in
a program. The flowchart diagrams for the algorithms described as follows.
4.3.1 Flowchart diagram for MakeRequest () algorithm

Start

“Validate User ()”

Accept
“Problem”
input Data

Display Error
Message

Check Values
Invalid
?
valid

Add New
Problem

display
“Problem
Status”

END

Figure 4.1: Flowchart diagram for Make Request 1

Information Desk and Support System Page 66

4.4. Coding
4.4.1 Implementation sample code of main process
<?php
$action = isset($_GET['action']) ? $_GET['action'] : '';
switch ($action) {
case 'makeRequest' :
'makeRequest'();
break;
case 'assignRequest' :
assignRequest ();
break;
case 'closeRequest' :
closeRequest ();
break;
case 'deleteEngg' :
deleteEngg();
break;
case 'deleteCust' :
deleteCust();
break;
case 'addEngg' :
addEngg();
break;
case 'addCust' :
addCust();
break;
case 'editEngg' :
editEngg();
break;
case 'editCust' :
editCust();
break;
case 'editCusts' :
editCusts();
break;
default :
header('Location: index.php');
}
function makeRequest()
{
$compType = $_POST['compType'];
$compTitle = $_POST['compTitle'];
$Office_Number = $_POST['Office_Number'];
$Block_Number = $_POST['Block_Number'];
$compDesc = $_POST['compDesc'];
$cust_id = (int)$_SESSION['user_id'];
$cust_name = $_SESSION['user_name'];
$sql = "INSERT INTO tbl_requests (cust_id, cust_name, comp_type,

Information Desk and Support System Page 67

comp_title,Office_Number,Block_Number,comp_desc, status, eng_id, eng_name, eng_comment, create_date,
close_date) VALUES ($cust_id, '$cust_name', '$compType',
'$compTitle','$Office_Number','$Block_Number','$compDesc', 'open', 0, '' , '', NOW(), '' )";
$result = dbQuery($sql);
header("Location: view.php?mod=customer&view=compDetails1");
exit;
}
function assignComplained()
{
$compId = $_POST['ddd'];
$engId = $_POST['engId'];
if($engId=="unsolved"){
$sql = "UPDATE tbl_requests
SET ename = 'Unsolved'
WHERE cid = $compId";
echo $sql;
$result = dbQuery($sql);
header("Location: view.php?mod=customer&view=compDetails1");
exit;
}
else if ($engId=="solved") {
$sql = "UPDATE tbl_requests
SET ename = 'Solved'
WHERE cid = $compId";
echo $sql;
$result = dbQuery($sql);
header("Location: view.php?mod=customer&view=compDetails1");
exit;
# code...
}
}
4.5. Testing Procedure
Software testing plays pivot role in determining the success or failure of the entire of software engineering.

System Testing
In plain words a system can be defined as a real life environment in which the software will be used. Some prefer to
define system as a combination of hardware, software and other operational component while some prefer to include
just the software and hardware component.
A system testing includes a full-fledged implementation scenario of the software development. This is a phase, which
highlights on the operational bugs and the software checklist, which are removed through the process of debugging.
Software debugging is the process by which we attempt to remove coding defects from a computer program. In order
to remove bugs from the software, first it must be discovered that a problem exists, then classify the error, locate
where.

Information Desk and Support System Page 68

Unit Testing
Unit testing allows us to focus on smaller units of the system. It makes easier to pinpoint and correct faults. In unit
testing called components (or communicating components) are replaced with stubs, simulators, or trusted components.
Calling components are replaced with drivers or trusted super-components. The unit is tested in isolation.
Unit testing is important for maintaining application quality assurance. The primary goal of unit testing is to take the
smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether
it behaves exactly as it is expected. Each unit test is tested separately before integrating them into modules to test the
interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during
its use.
Comment
We have tried to test login and Request registration as a sample of untie testing and we encounter that the system doesn’t

check the data with the data base for login and also it doesn’t register some of the data that are going to be inserted in the

address table.

Correction
Login checks if the user name entered exists in the data base or not, is username and password are correct or not. And in the

case of Request registration the data that are entered in the Request registration form are inserted to the Request and address

table.

Fig 4.2. Unit testing for login page 1

Information Desk and Support System Page 69

4.6. Test Case Specification
4.6.1. Test Cases for Login Component Testing
Table 4.1 Test cases for Log in component 1

Test Identifier Login form

Test location Application Main Menu
Feature to be tested To login in to the Application
Feature pass/fail Test passes if correct username and
password
is entered.
Means of control Input data and output
Test procedure 1. Insert username
2. insert password
3 Select role Type
4. click “Login”

Data Provided on the sample data sheet

Chapter Five
Information Desk and Support System Page 70
 Conclusion and Recommendation
This chapter contains summary of the project, concluding remarks and recommendation to the office in attempt to
minimize problems which are seen in Info desk and support section
5.1. Conclusion
The primary aim of this project is to improve the Info desk and support delivery service that has been given by the
university’s office to the university community by changing its manual Info desk and support system into full
automated Info desk and support management system. The study focused on ways to assess the effective of current
Info desk and support management system that has been implemented and to understand why the system could not
serve the community as it expected.
This study met the above mentioned motivation and focuses area through an Object Oriented System Analysis and
Design methodology and classified the study into different steps using chapters. The first chapter deals with project
identification and planning. In this chapter background of the organization, its service delivery and problems that are
hindered the service delivery are identified and mentioned. As the study continued, feasibility studies have been
conducted, scope of the project is clearly specified and an interview, document revision and site visit have been carried
out and all the results mentioned, and also work breakdown, deliverables and Gantt chart have been depicted in this
chapter in the project plan subsection.
The second chapter deals with Business analysis and requirement definition. In this chapter major functions of the
existing system have been identified, form and documentation which are used in the existing system are listed,
business rules are mentioned, major role players are identified, useful practices that has been deployed in the current
system have been identified, different options which can solve identified problems and different criteria’s which can be
used to select the best solution among available options have been set. As the chapter continued modeling of the existing
system has been depicted using essential use case modeling and functional and nonfunctional requirements of the proposed
system clearly mentioned. The third chapter deals with Object Oriented Analysis in which functional requirements has been
depicted using system use case modeling use case diagram, use case description, sequence diagram, class modeling, activity
diagrams and user interface modeling are the models used to analyze the proposed system and also supplementary
specifications are discussed in details.
The second part of the project consists of requirements review and validation, object-oriented design, and final

implementation details. It describes the solution domain in detail using class type architecture, design level class modeling,

Activity diagram, collaboration diagrams, and deployment diagram.

5.2. Recommendation
The current manual Info Desk and support system is deficient to serve the ever growing number of users in the

Information Desk and Support System Page 71

university; because it fails to embrace convenient, user friendliness, cause to high resource consumption, lack of

proper documentation and reporting rather opting for unmanageability, inefficient service delivery, lack of

communication between the manger and the technician. This project pointed out different options to minimize

problems in the existing system. One that takes into account is developing online Info Desk and support management

system, local management of ICT policies and procedures that are relevant to the service should be drafted and put

into use, and a means of fostering training for end users by the office. To this end, the team strongly recommends this

Online Web Based Info Desk and support System to be deployed for the next with some modification and feature additions

as soon as possible.

Information Desk and Support System Page 72

 References
1) Proceedings of the World Congress on Engineering and Computer Science 2016 Vol I

WCECS 2016, October 19-21, 2016, San Francisco, USA

2) http://umpir.ump.edu.my/id/eprint/3714/1/low_siew_pei.pdf (help Desk management system)

3) http://www.academia.edu/15971996/E-Helpdesk_Online_Helpdesk_for_College_Campus(E-

Helpdesk : Information desk and Support System for College Campus)

4) Object Oriented Design and Analysis using UML, Third Edition by Craig Larman/2002

5) E-Helpdesk: Online Helpdesk for College Campus (IJIRST/ Volume 1 / Issue 11 / 049)

6) A. Cockburn. Writing Effective Use Cases. Addison-Wesley 2001

7) Sequence Diagrams Massimo Felici Sequence Diagrams 2004–2011

8) Practical UML: A hands on introduction for developers http://dn.codegear.com/article/31863

UML Distilled Ch. 3, by M. Fowler

9) Bentley Whitten, Jeffery (2004) System analysis and design methods. New Delhi: Tata

McGraw hill.

Information Desk and Support System Page 73