Online Web Based Helpdesk Management Sys

On
ADDIS ABABA UNIVERSITY
System Analysis Document
On
Online Web Based Help Desk Management System for Addis Ababa
University
By
1. Asegid Asfaw CCE/5575/99
2. Henok W/Michael CCE/4137/99
3. Meseret Abiy CCE/0209/99
4. Wolelaw Berhane CCE/4169/99
5. Wondafrash Woldie CCE/4170/99
Industrial Project I (CSCE 495)
In Partial fulfillment of the Requirements for B.Sc Degree in Computer

Science
Advisor: Lemma Lessa (M.Sc. IS)
Submitted to:
Faculty of Informatics
Continuing and Distance Education Unit
Addis Ababa
08 January 2009 G.C. (Tir 2001 E.C.)

Addis Ababa University Online Web Based Helpdesk Management System
Table of Contents
Acronyms ...................................................................................................................................................... 6
Chapter One .................................................................................................................................................. 7
Project Identification and planning............................................................................................................... 7
1.1 Introduction .................................................................................................................................. 7
1.2 Background of the Organization ................................................................................................... 7
1.2.1 Information Communication Technology Development Office (ICTDO) .............................. 8
1.2.2 Network Infrastructure (LAN/WAN) ..................................................................................... 8
1.2.3 Data Center ........................................................................................................................... 9
1.2.4 Services ............................................................................................................................... 10
1.2.5 ICTDO Organization and Management ............................................................................... 10
1.2.6 The Helpdesk Section .......................................................................................................... 11
1.3 Statement of the Problem .......................................................................................................... 11
1.4 Objective of the Project .............................................................................................................. 12
1.4.1 General Objective ............................................................................................................... 12
1.4.2 Specific Objectives .............................................................................................................. 12
1.5 Feasibility Study .......................................................................................................................... 13
1.5.1 Economic Feasibility ............................................................................................................ 13
1.5.2 Technical Feasibility ............................................................................................................ 15
1.5.3 Operational Feasibility ........................................................................................................ 15
1.5.4 Conclusion on feasibility studies ......................................................................................... 16
1.6 Scope of the Project .................................................................................................................... 17
1.7 Significance of the Project .......................................................................................................... 17
1.8 Beneficiary of the Project ........................................................................................................... 18
1
1.9 Methodology............................................................................................................................... 18
1.9.1 Data Collection Methodology ............................................................................................. 18
1.9.2 System Development Tools ................................................................................................ 18
1.10 Project Organization ................................................................................................................... 19
1.10.1 Role and Responsibilities of Team Members ...................................................................... 20
1.11 Project Plan ................................................................................................................................. 20
1.11.1 Work Break down Structure and Deliverables.................................................................... 21
1.11.2 Gantt chart .......................................................................................................................... 23
1.12 Organization of the Document ................................................................................................... 24
CHAPTER TWO ............................................................................................................................................ 25
Business Analysis and Requirements Definition ......................................................................................... 25
2.1 Introduction ................................................................................................................................ 25
2.2 Major functions of the Existing System ...................................................................................... 25
2.3 Forms and Documents used in the existing System ................................................................... 27
2.4 Business Rules ............................................................................................................................. 27
2.5 Major Role Players ...................................................................................................................... 28
2.5.1 Helpdesk Manager .............................................................................................................. 28
2.5.2 ICTDO officer ....................................................................................................................... 29
2.5.3 Technicians.......................................................................................................................... 29
2.5.4 Secretary ............................................................................................................................. 29
2.5.5 Users ................................................................................................................................... 29
2.6 Problems of the Existing System in PIECES framework .............................................................. 30
2.7 Practice to be preserved from the existing system .................................................................... 32
2.8 Alternative options to address problems of the existing system. .............................................. 32
2.9 Option Analysis and the proposed new system.......................................................................... 33
2
2.9.1 Option 1: Enhancing the current system. ........................................................................... 33
2.9.2 Option 2: Purchasing off the shelf helpdesk software........................................................ 34
2.9.3 Option 3: developing windows based helpdesk management system .............................. 34
2.9.4 Option 4: developing online web based helpdesk management system ........................... 35
2.9.5 Option Analysis Conclusion ................................................................................................. 35
2.10 Essential Use Case Modeling....................................................................................................... 35
2.10.1 Actor and Essential Use Cases Identification ...................................................................... 36
2.10.2 Essential Use Case Diagram ................................................................................................ 38
2.10.3 Description of Essential Use Cases...................................................................................... 39
2.10.4 User Interface Prototyping.................................................................................................. 47
2.10.5 User Interface Flow Diagram .............................................................................................. 52
2.10.6 Domain Modeling with Class Responsibility Collaborator (CRC) Cards .............................. 52
2.10.7 Identifying classes ............................................................................................................... 53
2.11 System requirement of the new system ..................................................................................... 56
2.11.1 Functional requirements..................................................................................................... 56
2.11.2 Not Functional requirements .............................................................................................. 59
Chapter Three ............................................................................................................................................. 61
Object-Oriented Analysis ............................................................................................................................ 61
3.1 Introduction ................................................................................................................................ 61
3.2 System Use Case Modeling ......................................................................................................... 61
3.2.1 UI Identification .................................................................................................................. 62
3.2.2 Business Rule Identification ................................................................................................ 63
3.2.3 Actor Identification ............................................................................................................. 63
3.2.4 Use Case Identification ....................................................................................................... 64
3.2.5 Use Case Diagram ............................................................................................................... 65
3
3.2.6 Use Case Description........................................................................................................... 67
3.3 Sequence Diagrams..................................................................................................................... 75
3.4 Class Modeling ............................................................................................................................ 81
3.4.1 Class Identification .............................................................................................................. 81
3.4.2 Data and Actions ................................................................................................................. 82
3.4.3 Conceptual Modeling .......................................................................................................... 83
3.4.4 Unrefined class diagram ..................................................................................................... 84
3.4.5 Refined class diagram. ........................................................................................................ 85
3.5 Activity Diagrams ........................................................................................................................ 86
3.6 User Interface ............................................................................................................................. 96
3.7 Supplementary specifications ................................................................................................... 101
3.7.1 Non-functional requirements ........................................................................................... 101
3.7.2 Constraints ........................................................................................................................ 102
3.8 Documentation of change cases ............................................................................................... 102
Chapter Four ............................................................................................................................................. 103
Conclusion and Recommendation ............................................................................................................ 103
4.1 Conclusion ................................................................................................................................. 103
4.2 Recommendation...................................................................................................................... 103
References ................................................................................................................................................ 104
4
Acknowledgement
A very special thanks to Ato Lemma lessa, 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. And also a very special thanks to
Ato Workshet Lammenew for his continuing advice and support in all matters that we need.
Finally, we are indebted to all who encourage us to produce this project, especially Ato
Bahernegash Bellete ICTDO officer, who allows us to get necessary information and to use
ICTDO conference room whenever we need it.
5
Acronyms
Abbreviation Description
BR Business rule
CRC Class Responsibility Collaborator
HTML Hypertext Markup Language
ICT Information Communication Technology
MySQL My Structured Query Language
OOA Object Oriented Analysis
OWBHMS Online Web Based Helpdesk Management System
PHP Hypertext Preprocessor
UI User Interface
UML Unified Modeling Language
WBS Work Break Down Structure
XML Extended Markup Language
6
Chapter One
Project Identification and planning

1.1 Introduction
This part of the document deals with brief description of Addis Ababa University and
Information Communication Technology Development Office (ICTDO) of AAU along with
ICTDO’s office organization and job description of the helpdesk unit which this project focus on.
It also explains how the existing helpdesk system works, problems in the existing system,
objectives of the project, feasibility studies, scope and significance of the project along with the
methodologies that the team members follow to analyze, design and implement the proposed
system.
1.2 Background of the Organization

On March 20, 1950, Emperor Haile Silassie I declared the foundation of the University College
of Addis Ababa, which includes the faculties of Arts and Science. It was renamed Haile Selassie I
University in 1962 and then Addis Ababa University in 1975. At the time there were only 33
students enrolled compared to the current number of more than 50,000 students. Starting
from only one diploma and certificate granting department, namely Biology, the University
today comprises more than 25 faculties. The university promotes teaching leaning and research
as its core functionalities. [1]
Cognizant of the importance of Information communication Technology (ICT) for teaching-

learning and research process, AAU initiated a project named AAUNet. AAUNet is a university-
wide network that is designed to interconnect all campuses of Addis Ababa University.
Currently 14 campuses are interconnected with a state-of-the-art technology. After the
establishment of AAUNet there was a need to establish the office which regularly controls the
network, with this regard, of Information communication technology Development Office was
established.
7
1.2.1 Information Communication Technology Development Office (ICTDO)

The ICT Development Office was established in 1996 through visionary leadership of a few
individuals who realized that the AAU would be wise to join the information age by adopting
the technology that has been transforming the world. The newly formed office initiated a
project named AAUNet that has resulted in a wide area network (WAN) whose first phase of
construction was completed in November 2001. The network, which connects all the 14 widely
distributed campuses of the university, has been growing since. The services delivered through
the infrastructure have also been increasing.
Despite the pioneering role AAU has played in the deployment and use of ICT and the fact that
it now has a relatively sophisticated infrastructure, however, it is still far from a point where it is
adequately served by ICT. At the same time, AAU’s need for and dependence on effective ICT
support is now greater than ever.
The national attention given to the expansion and improvement of higher education as critical
factors in the country’s development has explicit and implied requirements for the use of ICT in
realizing the objectives. AAU’s role as a major contributor to these expansion and enhancement
efforts, along with the imperatives contained in its own ambitious strategic plan, call for the
speedy improvement of the efficiency and quality of its academic and administrative functions.
This is hard, if not impossible, to accomplish without adequate ICT support.
There are currently various initiatives underway, both at the ICT Development Office and
various quarters around the university, to meet the growing demand for and address the ICT
support needs of the university.
1.2.2 Network Infrastructure (LAN/WAN)

AAU has fourteen campuses with a wide geographic distribution in and around Addis Ababa. All
but the recently acquired Akaki campus have had inter-campus connection in the form of a
hybrid wired and wireless connection for at least three years. There is a current effort
underway, in collaboration with ETC, to convert the somewhat limited wireless connections to
8
fiber. The main campuses (Sidist Kilo, Amist Kilo, and Arat Kilo) serve as the core of the network
with redundant high speed connectivity.
The connectivity devices (routers, switches, etc.) which were predominantly CISCO devices in
the past were upgraded and converted a year ago to more capable, predominantly Huawei (a
Chinese brand) devices through a donation from the Chinese company.
The internal network (LAN/WAN) is connected to the internet via a 6Mbps link to the ETC
exchange. The connection is managed internally through a gateway and protected from
intrusion and virus and other attack by two firewalls.
Within the various campuses there are numerous existing and new buildings that do not yet
have access to the network. Connecting more and more buildings (and rooms within the
buildings) is an ongoing process. Today there are about 6,000 nodes connecting end-users to
the network. These nodes include administrative and academic staff offices as well as computer
labs.
1.2.3 Data Center

The servers used to run the network and that provide other services (such as mail and web
services) are housed in two main datacenters. The approach followed under the recent network
upgrade was to have one main datacenter at Sidist Kilo with a backup and disaster recovery
center at Amist Kilo.
While there are about 35 servers (Sun & HP) of various specifications operated by the ICT office
there are numerous others scattered throughout the university under different faculties,
institutes, and administrative offices. This situation, while justifiable in rare cases, is not in line
with best practice. The AAU ICT Development Office (ICTDO) is making attempts to consolidate
server maintenance by trying to persuade the various stakeholders that they are better served
by having their servers hosted in the main datacenter.
The ICTDO has an ongoing project, with a £50,000 donation from Ethiopiaids of the UK, to
upgrade its main datacenter and its backup and disaster recovery datacenter.
9
1.2.4 Services
The services delivered by and through the ICT infrastructure, aside from the provision of
connectivity, may be grouped into two. First, there are technical services that provide indirect
support to the user community. These are services such as Domain Name Service (DNS), proxy
servers for facilitating managed internet access, LDAP for identity management, and firewall for
security. The second set of services is made up of services that provide direct support to end-
users in their normal day-to-day activities. These are such services as email, internet,
automation, e-learning, etc.
At AAU all the essential technical services are in place and operational. Of the direct support
services, the most widely used and the ones that have been in place for some time are email
and internet access. There are two online systems deployed using the existing infrastructure,
one is the registrar system and the other is the library catalog. There have also been previous
attempts at finance automation that have not been successfully implemented.
There is an initiative that has been underway for a little over a year to select and deploy an
integrated and enterprise-wide automation (business process and student administration
automation).
1.2.5 ICTDO Organization and Management

The ICT Development Office at AAU which has been in existence for about six years under
various designations has played the lead role in the adoption and use of ICT at the university. In
particular, it has been the entity that has initiated and managed the build-up of the university
wide network. Its efforts have been supplemented by various initiatives at the faculty and
institute level as well as initiatives from government entities such as the Ministry of Education
and the Ethiopian ICT Development Agency.
The office is currently organized into three units namely System Administration, Computing
Services, and Help Desk as shown in Figure 1.1 below. [1]
The system administration unit is responsible for the design, implementation, and day-to-day
operation of the network. The computing services unit is responsible for the acquisition,
10
development, deployment, and maintenance of applications and web services. The help desk
unit which this project focuses on provides wide ranging support to the user community.
Figure 1.1: ICTDO organizational Structure chart.
1.2.6 The Helpdesk Section

Helpdesk support section provides advice, consultancy, and support in all matters associated
with access to and use of AAU network infrastructure, including hardware and software
maintenance, onsite and telephone-based pc support to the university community. A help desk
will exist as a point of contact, disseminated in 14 different campuses such as Main Campus,
FBE, Technology North etc. The helpdesk staffs can give immediate support or can refer to
specialists if the problem is beyond their limit.
1.3 Statement of the Problem

In our preliminary investigation, we have noticed that the office currently follows manual help
desk system to carry out its service delivery; as a result there are a number of problems in the
system. Some of the problems are as follows.
There is no proper filing system where only filled paper forms are shelved
Difficult to get clear information and this leads bad report generation
11
Paper consumption is high as it requires to have filled forms for each logged problem
It is difficult to trace the assigned technician for a given problem
It is difficult to identify solved, unsolved or escalated problems
It is difficult to identify work load of technicians
It is difficult to generate consolidated reports regarding previously recorded problems,
their status and findings, performance of technicians and others.
There is no asset management system that ascertains AAU’s equipments
There is no knowledge repository that guides users to troubleshoot minor problems by
their own.
The communication mechanism between users and the helpdesk section is tedious as it
demands call or forwarding hardcopy or physical presence.
There is no monitoring/controlling mechanism
In order to address the above mentioned problems the team has come across to a conclusion
to change the existing manual helpdesk system to online web-based help desk management
system.
1.4 Objective of the Project

The objective of this project is to change the existing manual help desk management system
into a web based online helpdesk management system.
1.4.1 General Objective

The general objective of the project is to develop a complete, original, and valuable fully tested,
optimized; cross-browser compatible, practical, guaranteed, and economical web based online
helpdesk management system for AAU.
1.4.2 Specific Objectives

In order to achieve the general objectives, the project includes the following specific objective:
1. Object Oriented Analysis of the existing system.
1.1. Information about the organization
12
1.2. Identification of major players
1.3. Identify major functions and processes
1.4. Identifying the existing problems
2. Object Oriented Analysis of the proposed system
2.1. Overview of the proposed system
2.2. Identifying the functional requirements
2.3. Identifying the non-functional requirements
3. Object Oriented Design of the new system
4. Implementing and testing the new system.
5. Deliver training and documentation.
1.5 Feasibility Study

In this part we intend to indicate the possibility of completing the proposed system. As it goes
to the basics, it will provide necessary information to evaluate if the system is feasible to be
continued. The question and answer method have been employed to get a clear picture on this
feasibility study.
1.5.1 Economic Feasibility

The economic feasibility is intended to be studied if there will be any additional cost such as
purchasing new hardware, and benefits (cost/benefit analysis).
I. Cost
1. Is there any special cost for people including the staff and users?
No. However some training cost will occur for the implementation of the new computerized
system.
13
2. Are there any special cost for the hardware and equipments?
No. Our assessment indicates that the office deployed powerful servers in the main data
center and all users have got up-to-date desktops so that the proposed system does not
require any additional hardware and equipment.
3. Is there any special cost for software?
No. The proposed system will be developed using HTML, PHP, and Java Script as a front end
and MySQL as a back end and will be deployed on apache Web Server. And all these
software are distributed freely, however some patching cost might be occur.
4. Is there any special cost for training?
Yes. There will be, but the cost will be minimal and the system will be developed to be user
friendly.
II. Benefits
a. Tangible benefits
Cost reduction and/or avoidance
Error reduction
Increase flexibility
Improvement in management planning and control
b. Intangible benefits
Better service provision
Faster decision making
Timely and accurate information
Builds employee moral
The new system provides both tangible and intangible benefits to the office, which on the other
hand will build positive image of the office. This will also smoothen the management of the
office. These benefits are necessary and desirable.
14
1.5.2 Technical Feasibility

In this part of the research, the technical aspects of the system will be clarified. The technical
elements in the system will be confirmed and verified whether it is practical and achievable.
1. Does the organization have the necessary equipment for the system?
Yes. Even though the office has practiced a manual system before the office has the
required equipment. All the necessary hardware does not needs to be purchased however a
long-time investment on the computer peripherals is essential.
2. Can the future technology be adopted in the system?

No. There would not be any future technology that will be adopted since the stability of
these future systems have not been tested yet. The current, reliable technologies will be
used in this system.
3. Does the organization need any technical expertise?

Yes. The office will have to do some minor maintenance and debugging. All the users in the
AAU are computer literate, thus they will be able to understand and use the system with
basic training.
4. Will the hardware and software platform be reliable?

Yes. Both the platforms will be reliable and their reliability will be tested carefully to avoid
any problems in the future.
5. Will the system be able to handle the projected growth of the organization in the future?
Yes. There will be a backup provided and older data will be recorded and kept in a separate
backup
1.5.3 Operational Feasibility

Operational feasibility involves considering whether the system is appropriate with the working
environment of the office. All the terms (technical terms) used in the research are elevated
with the advertising terminologies used in the working environment of the agency.
15
The main constrain of the feasibility study is to ensure the proposed system gets the
management support. As in this research, authorization is obtained from the office to conduct
the research. Six questions are used to clarify the operational feasibility study.
1. Do the users (staff) support the new system?

Yes they do. This is because all their opinion about the new computerized system has been
gathered. They believe that the new system can reduce the errors during work and can
simplify their job.
2. Are they satisfied with the current file based system?

No. The current manual system needs the staffs to perform every task manually. For
example, it is a difficult task to search for a specific problem type and its solution for a
reference. A computerized system will be easier to use. Computerized system also will allow
ad hoc report generation that will be effective in decision-making.
3. Will there be any necessity for training?

Yes. There is a need for some basic training for few days to understand the system’s usages
fully. But the cost and time needed for the training is reasonable.
4. Will the users be involved in the planning of the new system from the beginning?
Yes. The staffs will be involved to provide ideas and expectation from the new system
5. Is the schedule for development systematic?

Yes. This is possible due to the usage of the uniform process model, which is a discipline
approach. It guides the system's development in stages up to the system implementation
process.
1.5.4 Conclusion on feasibility studies

The proposed system does not require a onetime and recurring cost because the office already
deployed the necessary hardware and software in the main data center and also all paper and
telephone bills will be avoided when the proposed system will be deployed. However some
16
financial allocation is vital in purchasing software patches but the amount is not much and will
not be a burden to the office.
Since the research concentrates on migrating from a manual system to a new computerized
system, there might be some unforeseen problems occurring in future. If the guidelines are
followed, it can solve the problem. The well-documented system development will give a clear
idea on the system’s functionality and will be helpful to overcome these unforeseen events.
1.6 Scope of the Project

Among others, some of the tasks to be undertaken by the group include reviewing the existing
systems of the ICTDO, requirement definition, analysis, design, developing the required system
and will come up with the following features.
Authentication
Request handling
Problem Assignment
E-mail Alert
Knowledge repository
Report Generation
Asset Management
1.7 Significance of the Project

Among the very many significances of the project, the team has identified the following as the
major ones:
1. Provide timely information for the users, decision makers as well as the concerned body.
2. To create easy work environment
3. Provide user friendly, well designed and dynamic web based solution
4. Establish central repository system
5. Provide self help to the end users
17
1.8 Beneficiary of the Project

All users (Academic staff, Administration staff and Students), the ICTDO office and the
employee will be benefited from the proposed system.
1.9 Methodology
This project adopts object oriented system analysis design approach as it has better reusability,
maintainability qualities and gives more emphasis to the analysis and design phases of the
development process when compared to structural system analysis and design approach.
1.9.1 Data Collection Methodology

To ensure all appropriate data is collected and user requirement is well identified it is important
to use a combination of data collection techniques. Accordingly, user requirements are
identified through interviewing users, the employee and heads of different sections in ICTDO.
The interview will also be conducted to relevant employees of each section. In addition, review
and analysis of the existing Manuals, various forms and files and observation of the existing
system will be undertaken.
The team found out that the above stated data collection techniques are suitable due to time
constraints and delay in responses if questionnaires were the technique to be used.
1.9.2 System Development Tools

a. Analysis and Design tools
- Unified Modeling Language (UML): As object oriented systems analysis and design
involves intensive modeling activities for the analysis, design and deployment activities,
we use UML as our system modeling language.
b. Case Tools
- Microsoft VISIO: as it supports to draw different UML modeling tools, we use this
application.
c. Interface/Layout design tools
18
- Macromedia Dream weaver 8 or later. As it has built in DHTML and HTML tags it
minimizes the time required to design the layouts.
- Adobe Photoshop CS 2 or later. It is professional photo editor.
d. Programming tools
- HTML
- PHP
- Jscript
e. Database
MySQL
1.10 Project Organization

The project team consists of five members headed by the project manager. The project is sub
divided into different tasks and each member will have different role and responsibly based on
knowledge and skill they acquired. Even if each member has his/her own major assignments,
there has been task sharing among team members.
Table 1.1 Project Team Organization table
Name Title
Asegid Asfaw Technical Team Member
Henok W/Michael Technical Team Member
Mesert Abiy Technical Team Member
Wolelaw Berhane Project Manger
Wondafrash Wolde Technical Team Member
19
Communication among team members will be facilitated through email, regular status review
meetings and telephone. The project manager is responsible for assigning members to specific
tasks, reviewing their performance and communicating the progress to each member.
1.10.1 Role and Responsibilities of Team Members
Project Manager
Provide management support, supervision, and oversight for the project Quality
Assurance function.
Make available resources as needed to support project development.
Ensure resolution of problem and concern issues.
Technical Team Members
System Analysis
System Design
Implementation and integration
Testing
Documentation
Promptly report result of audits to the project manager.
Periodically report unresolved noncompliant items to technical monitor/senior
management.
1.11 Project Plan

The project has two phases. The first phase comprises of business area analysis and
requirement definition. Upon successful completion of the first phase the project will embark
on the second phase, which entails designing and implementation of the analyzed system.
Tasks along with the time taken for each task are depicted in the Gantt chart.
20
1.11.1 Work Break down Structure and Deliverables

Table 1.2 Project Plan in table
No Activity Duration Start Finish Deliverables

(in days) Date Date
1 Project planning & Identification 2 March March Identified
3, 2009 5, 2009 Project
2 Feasibility Study 4 March March Feasible project

6,2009 10,2009
Economic feasibility 2
Technical feasibility 2
3 Business Area Analysis and 22 March March Analysis

Requirements definition 11,2009 31, Document
2009
Analyzing the Existing System 8
Identifying major functions and

process 3
Identifying major role players. 2
Identifying major Problems in the

3
Existing system
Analyzing the proposed system 12
Functional requirement 6
Non-functional requirement 6
4 Object Oriented Analysis Apr May 2, Analysis

2,2009 2009 Document
30
System Use case Modeling 8
21
Sequence diagram 5
Unrefined Class Diagram 6
Activity Diagram 5
User Interface Prototype 6
5 Object Oriented Design 44 Oct 1, Nov 25, Design

2009 2009 Document
Class type Architecture 5
State chart Modeling 4
Class diagram 4
Collaboration diagram 7
Component Diagram 5
Deployment diagram 3
Persistence Modeling 4
User interface Modeling 8
6 Object Oriented Implementation 43 Nov 26, Jan 1, System Code

2009 2010
a. Coding 25
System Coding 10
Process Coding 10
Database Coding 5
b. Testing 5
Unit testing 3
System testing 2
22
c. Hosting 5 Jan 7. Jan 13,

2010 2010
d. Migration 3 Jan 14, Jan 18

2010 2010
e. Training & Documentation 5 Jan 19, Jan 25, System

2010 2010 Documentation
1.11.2 Gantt chart

The Online web based helpdesk management system of AAU project plan is shown in figure 1.2 below.
Figure 1.2: Prject Plan
23
Figure 1.2: Gantt chart of the project plan.
1.12 Organization of the Document

The project paper consists of five chapters. The first chapter deals with introduction. The
second chapter contains description of the existing system along with functional and non
functional requirement of the propose system. The third chapter describes analysis of user
requirement and modeling of the requirement using UML tool. The fourth chapter presents
design of the new system. The fifth chapter provides system implementation issues and finally
the sixth chapter deals with conclusion and recommendation.
24
CHAPTER TWO
Business Analysis and Requirements Definition
2.1 Introduction
This chapter briefly describes the existing system functionality, problem of the existing system,
players of the system, business rule and modeling of the proposed system using Unified
Modeling Language (UML).
The assessment was made based upon:
Interviews of user, technicians and helpdesk manager.

A review of supporting documentation provided by the office and
A Site visit.
The 5 major functional areas of the existing system are indentified and evaluated.
2.2 Major functions of the Existing System

i. Request for help: users submit their request for support to the office in one of the
following three ways.
a. Using Users Problem Report Form (UPRF). The offices prepared and distributed user
problem report form to all faculties and department administration offices and, users
collect and fill-out this form and submit to local ICT office. Users are requires to fill-out
their name, faculty, department, email, floor or office number, telephone, date and
time along with problem type, description and severity level.
b. Using Telephone. The office allocates a direct telephone line for users who may not
get the UPRF. The secretary receives the call and fills the information on the form and
pass to the helpdesk manger.
c. In person. Sometimes users come to the office and grab anyone of the available
technician and take away for help without the knowledge of the helpdesk manager.
25
ii. Assign technician for reported problems: After the report has been submitted to the office,
especially if the problem is reported using UPRF or using telephone then the technician is
going to be assigned as follows, if the user is located in the main campus then the helpdesk
manager will assign a technician based on the information on the UPRF. If the user is
located at remote campus then the technician has full authority to address the problem.
iii. Escalate problem to higher assistance: if assigned problem can’t be solved by the given
technician then the designated technician requires immediate assistance from higher level
technician or from the helpdesk manager.
iv. Register equipments: Equipments which can’t be fixed on the site should be delivered to
the office for further diagnosis. At this moment the receptionist or the secretary fill-out
equipment check in and check-out form in order to control whose equipment is received
for maintenance. In the form Name of the owner, Name of equipment, Tag number,
Received date, Issue date and Signature of the owner are filled.
v. Report generated in the existing system: report generation is divided into two part daily
report and weekly reports
Daily report is presented verbally to the helpdesk manager by the technicians and that
include
Status of reported problem

Type of problem
Time taken to solve a given problem
Number of problem Escalated
Weekly reports, collected from remote campuses technicians, are presented in a form of
paper and that include
Frequency of the problem
26
Number of problem reported

Number of Problem solved
Number of Problem Escalated
2.3 Forms and Documents used in the existing System

o User Problem Reporting Form (UPRF) (please see the back page of this document)
o Equipment check in and checkout form (see the back page this document)
2.4 Business Rules

The office does not have written or formal document regarding business rule but as we have
discussed with the helpdesk manager the following business rules are well aware in the
university community and ICTDO.
Identifier: BR1.0
Name: Fulfillment of problem registration
Description: Only properly filled forms are directed to the helpdesk manager or
helpdesk technician.
Source: Interview
Identifier: BR1.1
Name: Obligation
Description: Helpdesk technicians are not obligated to fix equipments which are not the
property of AAU or consult issues that are not use for AAU.
Source: Interview
Identifier: BR1.2
Name: Priority
27
Description: service provision prioritized based on the sensitivity level of the business
area where the problem arises and severity level of the problem.
Source: Interview
Identifier: BR1.3
Name: Equipment Registration
Description: any equipment which is supposed to be maintained in ICTDO workshop

shall be registered on the equipment check in and out form. The information in the form
should contain name of the owner, equipment type, delivery and Issue date of the
equipment.
Identifier: BR1.4
Name: unsolved problem
Description: all unsolved problems within 24 hours should be reported to the helpdesk
manager.
Source: Interview
2.5 Major Role Players

The major role players of the existing helpdesk system are the Helpdesk manager, the
technicians, the secretary and the rest university community to whom the unit provides service.
2.5.1 Helpdesk Manager

Helpdesk manager has the responsibility to:
Supervise the technicians and the secretary.

Manage and supervise the workflow.
Assign technicians for the specific problem.
Monitor outstanding, solved, and escalated problems.
Make decision for escalated problems.
28
Examine report from technicians

Prepare and submit a report to ICTDO officer.
Consult the university community up on request of ICT related issues.
2.5.2 ICTDO officer

Approves announcements
2.5.3 Technicians
The helpdesk unit consists of 19 technicians. They are disseminated in the fourteen campuses.
They are responsible to:
Solve problems assigned to them.

Report solved and unsolved problems that are assigned to them.
Receive equipments to be maintained.
Handover maintained equipments to the owner.
Document problem findings.
2.5.4 Secretary
The Secretary has the responsibility to:
Receive call for help and inform the technicians using UPRF.
Handle the usual secretarial duties.
2.5.5 Users
The university community as a whole is the main user of the system. Each user has the
responsibility to:
Report ICT related problems to the Helpdesk unit as per the business rule of the
system
Co-operate with the technicians in solving the problem.
Bring equipments that cannot be solved outside the workshop.
29
2.6 Problems of the Existing System in PIECES framework

Based on the staff interviews and analysis of the working documents the following problems
are identified that hiders the unit not to provide its service to the university community. We
classify and present the problems in PIECES framework. [2]
a. Performance
If users need to get service from the office he/she must fill the form and present to
the office this kind of scenario takes much time because the user has to go to the
office to submit the form.
The nature of the work enforces the technician to move one office to the other. If a
request is initiated, while they are on duty there is no any mechanism to inform
them that request is coming. This kind of scenario is also takes much time to
respond for reported problem.
b. Information
Sometimes users and technicians don’t fill the UPRF properly. This occurs due to
negligence or lack of knowledge, and this lead to
o Difficulty to locate user’s office.
o Difficulty to understand the problem type.
o Difficulty to prepare a report based on reported problems.
o Difficult sometimes impossible to trace specified problem was reported.
o Difficult to trace problem was solved, not solved or escalated.
• It is difficult to identify work load of technicians.
The manager don’t have well formatted record keeping mechanism to keep a record
of who is assigned for which problem and who is free and this lead the manager to
assign technicians randomly.
• There is no any information available to evaluate technicians performance

• It is difficult to know how much time required to fix a given problem
c. Economics
30
• The unit has been providing a service to a large number of users and all requests for
help should be presented using the UPRF. This leads to
• High paper consumption per day which means the office incurs high expense to
prepare the form
• Users who cannot get the UPRF uses telephone to present their request and this also
exposed the university to incur telephone bill.
d. Control
• The unit does not need a high security control mechanism to protect the information
or data. This is because the office does not use sensitive or mission critical data
e. Efficiency
• UPRF are not properly shelved or kept, which has resulted impossible to compile a
report
• The UPRF does not have unique case number. Thus there is no way to find a specific
UPRF.
• if the UPRF is completely lost, there is no way to trace whether:
o The specified problem was reported
o The assigned technician was involved or not
o The problem was solved, unsolved or escalated.
f. Service
• It indicates whether the current services are reliable, flexible, and expandable. And
this could be described as follows:
o The system produces inaccurate results
o The system produces inconsistent results
o The system produces unreliable results
o The system is not easy to learn
o The system is not easy to use
o The system is awkward to use
o The system is inflexible to new or exceptional situations
31
o The system is inflexible to change

o The system is incompatible with other systems
o The system is not coordinated with other systems
The existing Helpdesk system does not produce results by its own. It is easy to use but awkward
in this computerized world. The manager writes weekly summary report by reading each UPRF
one by one. The existing UPRF form is not complete enough to accommodate the details of all
problem types.
2.7 Practice to be preserved from the existing system

The nature and the span of the work is very boring and vast, but the technician serves users in
all matter without any hesitation. This kind of practice is meant to be preserved even if the
existing system is going to be changed.
2.8 Alternative options to address problems of the existing system.
Option 1: Enhancing the Current System
Restructure, formulate and apply office policy and strengthen the helpdesk unit with additional
staff will minimize problems in the existing system and improve the service delivery. For
example if the structure includes record officer and this officer collect , register and store the
incoming UPRF in a well manner way, then problems which are seen in the preparation of
reports and unfair distribution of tasks to technicians can be addressed very well.
Option 2: Purchase and install off the shelf helpdesk management system
These days there are different kinds of off the shelf helpdesk management system, which are
already been designed and made available in the international market. This software can be
customized and modified in a way to meet organizations need.
Option 3: Design and Develop windows based helpdesk management system
32
The other option, to solve problems in the existing system, is design and develops windows
based helpdesk management system. This software can be considered as a solution but it has
its own advantage and disadvantage.
Option 4: Design and Develop online web based helpdesk management system
This is what we propose to solve problems in the existing system.
2.9 Option Analysis and the proposed new system

In this section we evaluate the options which are identified in section 2.9 using SOWT analysis.
A SWOT analysis is a tool, which can help to identify the Strengths, Weaknesses, Opportunities
and Threats of a particular solution.
2.9.1 Option 1: Enhancing the current system.

a. Strength
• Creates better filing system than the current system.

• Settle reasonable workloads among technicians.
• better report generating system
b. Weakness
• Still user uses UPRF to submit their request.

• Highly susceptible for data loss.
• Needs Bulky storage area
• Still paper cost is available
• Security require much cost and effort
• Generating report, controlling workload of technicians needs to match effort for the
manager.
• Creates burden on the helpdesk manager in collecting compiled information.
c. Opportunity
• This system creates limited or no opportunity in enhancing the PIECES framework

d. Threats
33
• No treats found.
2.9.2 Option 2: Purchasing off the shelf helpdesk software

a. Strength
• Less time require to implement

b. Weakness
• It is difficult to find compatible software with the current system.

• It hinder from finding the basic strength and weakness of the existing system
• Are not available in local market
c. Opportunity
• It can solve the existing problem effectively

d. Threats
• Cost of purchasing and customizing such kind of software are expensive

• It does not give us the opportunities to develop the proposed system.
2.9.3 Option 3: developing windows based helpdesk management system

a. Strength
• Simplifies the working environment

• Creates better filing system.
• Can generate accurate and formatted report
• Reliable security
b. Weakness
• Operating system and hardware architecture dependent

• Need too much effort and cost in order to resolve compatibility issue.
• Installation and deployment need much time and effort.
c. Opportunity
• It can generate an income for the developers and even for the owner.
34
d. Threats
• Problems on the network or power failure cause damage on the service delivery.
2.9.4 Option 4: developing online web based helpdesk management system

a. Strength
• It solves the problems in the existing system

• compatible in all existing computers and operating system
• Reliable file storage
• Better security
• Fast and reliable service delivery
b. Opportunity
• It gives us the opportunity to design and develop a full flagged solution in which we
can learn a lot.
• It can generate income for the developers and even for the owner.
• It builds positive image of the office.
• It boosts employees interest in all matters associated with service delivery.
c. Threats
• Problems on the network or power failure cause damage on the service delivery
2.9.5 Option Analysis Conclusion

We have discussed four alternative options and disclosed their strength, weakness,
opportunities and threats and we have chosen the fourth option as the best alternative
solution, which is automating the existing manual system into a web based helpdesk
management system.
2.10 Essential Use Case Modeling
In this section we describe the interactions between external actors and the system under
consideration to accomplish a certain goal, using essential use cases. As Abler said “A use case
describes something of value to an actor (often a person or organization). An essential use case
35
is a use case that is technology independent—it describes the fundamental business task
without bringing technological issues into account. Essential use cases are often used to explore
usage-based requirements”. And this modeling technique gives us the opportunity to reflect
the behavioral requirements of the new system which we are going to develop.
2.10.1 Actor and Essential Use Cases Identification
a. Actors
An actor is a person, organization, or external system that plays a role in one or more
interactions with the system (Ambler, 2002). The team tries to answer to following questions
during actor identification process.
• Which user groups are supported by the system to perform their work?
• Which user groups execute the system’s main functions?
• Which user groups perform secondary functions, such as maintenance and
administration?
• Will the system interact with any external hardware or software system?
• Based on the above mentioned questions we identified the following actors.
Name: User
Description: represent the university community to whom the office deliver the service
Name: Secretary
Description: Data entry and related tasks
Name: Helpdesk Manager
Description: Assign technician, generate a report, draft announcement and the like
Name: ICTDO Officer
Description: Approve announcement and make a decision for escalated problems
36
Name: Technician
Description: receive assignment, receive equipment, record findings.
b. Use Cases
A use case describes a sequence of actions that provide something of measurable value to an
actor [xx]. Thus, it capture who (actor) does what (interactions) with the system for what
purpose (goal) without dealing with system intervals.
1. Submit Problem
2. Register user
3. Assign Technician
4. Post Problem Findings
5. Check Problem Status
6. Prepare Announcement
7. Approve Announcement
8. Register Technician
9. Register Equipment
10. Generate Report
11. Search
37
2.10.2 Essential Use Case Diagram
Fig 2.1 Essential use case diagram
38
2.10.3 Description of Essential Use Cases
There are various formatting template and technique that are available to describe use cases in
detail. Probably the most widely used and shared format, since the early 1990s, is the template
created by Alistair Cockburn [4]. We have modified the template by eliminating some use case
sections as depicted below and employs for our cases
Use case section/ content 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 a request for help
Actor: User or Secretary
39
Precondition: the user is identified and authenticated.

Post condition: The request will be registered. Track number will be generated.
Stake holders and Interests:
• User: Wants to submit problem accurately and diligently
• Manager- Wants to be able to assign a technician for the given problem
• Office: Wants to accurately record problems and satisfy users
Basic course of action:
1. The use case begins when the user or the secretary (if the user is not in a position to
submit his/her request due to network or power failure then the secretary plays users
role on behalf) indicates they wants to a request for help .
2. The user or secretary inputs user name and password to the system via UI02 log-in
page.
3. The system verifies that the user or the secretary is valid to submit the request. [Alt
Course A]
4. The system Displays UI08 submit problem page.
5. The user or secretary inputs name, faculty, department, office number, telephone,
email date, problem type and description. If the problem type is a hardware.[Alt
Course B]
6. The system generates track number to the user.
7. End use case
Alternate course A: The user is not valid
A3: The system counts the number of wrong entries and determines the values of the
Counter. If the Value of the counter is greater than 3.
A4: The system informs the user he/she is not a valid to request for help.
A5: The use case ends.
Alternate course B: The hardware is not AAU’s property
B5: The system informs the user he/she cannot get the service.
B6: The use case ends.
40
Name: Assign technician

Identification: UC002
Description: Assign a technician for a given problem
Actor: Manager
Precondition: The manager is identified and authenticated. Technician workload must be
checked.
Post Condition: Technician will be assigned.
Stake holders and Interest: Manager – need to assign a technician for each new arrival
problem.
1 The use case begin when the manager want to assign a technician.
2 The manager inputs user name and password via UI02 log-in page
3 The system verifies that the manager is valid to see outstanding problems.[Alt Course A]
4 The system displays outstanding problems UI 14 problem status list page.

5 The manager checks the work load of the technician via UI15 technician workload web
page.
6 The manager assigns a technician who is free or has less workload.
7 End use case
counter. If the value of the counter is greater than 3.
Name: Post problem findings
Description: If a given problem is solved then findings to solve the problem registered for
reference.
Actor: Technician, Helpdesk Manager
41
Precondition: The technician or helpdesk manager is identified and authenticated. The

specified problem must be solved problem.
Post condition: Problem finding is recorded. Problem report is updated.
Stake holders and Interest:
• Helpdesk Manager & Technicians – wants to update their findings for reference in case of
the same kind of problem might be reported.
1 The use case begins when the technician or the manager (for escalated problem)
indicates they want to record their findings.
2 The technician or the manager inputs user name and password in to the system via UI02
log-in page.
3 The system verifies that the technician or the manager is valid to write findings into the
system.[Alt Course A]
4 The technician or the manager searches the problem by its track number.[Alt Course B].
5 The system displays problem status list via UI 14 problem status list page.
6 The technician or the manager inputs the findings to the system
7 Update the database.
8 End use case
A4: The system informs the technician or the manager he/she is not a valid user to register
the findings. .
Alternate course B: the search result returns empty record
B5: The system informs the technician it cannot search the specified problem.
Name: Check problem status
42
Identifier: UC004
Description: Check a given problem is solved, unsolved or escalated
Actor: Helpdesk manager, User, Secretary, Technician.
Precondition: the actor is identified authenticated.
Post condition: The actor will get full information regarding to the specific problem.
Stake holders or interest: Manager - wants to know the status of the specified problem in
order to make decision.
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 UI02 log-in page.
3 The system verifies that the actor is valid to check the status of the problem.[Alt Course
A]
4 The actor inputs the track number of the specific problem via UI14.
5 The system displays the status of the problem via UI14.
6 End use case
A4: The system informs the actor he/she is not a valid user to check the problem status.
findings. .
Name: Prepare announcement
Identifier: UC005
Description: The secretary prepares and stores announcement.
Actor: Secretary
Precondition: The secretary is identified and authenticated.
Post condition: The announcement will be stored into the system.
Stake holders or Interest: the office needs to convey information to the user.
43

1 The use case begins when the secretary wants to prepare announcement.
2 The secretary inputs user name and password in to the system via UI02 log-in page.
3 The system verifies that the secretary is valid to input the announcement.[Alt Course A]
4 The secretary enters the announcement to the system.
5 End use case
A4: The system informs the secretary that she is not valid to enter the announcement.
Name: Approve announcement

Description: all announcements have to be approved before posted to the public by the ICTDO
officer.
Actor: ICTDO officer
Precondition: The announcement should be uploaded. The officer identified and authenticated.
Post condition: The announcement will be disseminated to the users.
Stake holders or Interest: Users – the user need to be aware of ICT related information.
1 The use case begins when the officer wants to approve the announcement.
2 The officer inputs user name and password in to the system via UI02 log-in page.
3 The system verifies that the officer is valid to approve the announcement.[Alt Course A]
4 The system displays new uploaded announcements via UI11 approve announcement
page, which indicate the list of new prepared announcement.
5 The officer puts his/her approval by selecting approve check box. [Alt Course B]
6 The system approves the announcement.
7 End use case
44

A4: The system informs the officer that she/he is not valid to approve the announcement.
Alternate course B: The officer needs to edit the announcement
B5: The system change UI11 approve announcement page into edit mode when the officer
needs to edit the announcement.
Name: Register Technician
Identifier: UC007
Description: register technicians who are employee to the office
Actor: Secretary
Precondition: the secretary will be identified and authenticated.
Post Condition: The technician will be registered.
1 Assume that she is in the system.
2 The system displays UI09 technician registration page
3 The secretary inputs first name, last name, telephone, email and location of the technician.
4 The system registers the technician.
5 End use case
Name: Generate report
Identifier: UC008
Description: The manager wants to generate a consolidated report.
Actor: Manager
Precondition: The actor is identified and authenticated.
Post condition: obtain a compiled report
Stake holders and Interest: ICTDO Officer & Helpdesk Manager
1 Assume that both actors are in the system
45
2 The system displays UI16 Report Generation Page,

3 The system asks the actors whether they want a printed report.
4 The system prints the report.
5 End use case
Name: Search
Identifier: UC009
Description: The Actors can search available data from the database.
Actor: ICTDO officer, Helpdesk Manager, Secretary, Technician, user
Precondition: the actor needs to have the key word.
Post condition: The actor obtains information.
Stake holders and interest: ICTDO officer and helpdesk manager – wants to get information.
Secretary - search user support information.
Technician- may searches information from the knowledge repository.
User: can find any supportive information regarding to his/her problem.
Basic Course of Action:
1 The system displays UI01 home page
2 The actor inputs the key word and search
3 The system displays the result via UI17 search result page.
4 End use case.
Name: Register Equipment
Identifier: UC010
Description: Register equipments which came for maintenance
Actor: Secretary
Precondition: equipments which could not repair on site should be delivered to the office.
Post condition: equipment will be registered and ready to diagnose and maintain in the work
shop.
Stake holders or interest: user
46
1 Assume that the identification and authentication is over and the secretary is in the system
2 The system displays UI07 aau equipment registration page, which allows the secretary to
enter information regarding the equipment.
3 The secretary inputs equipment’s type, track number, model, tag number, received date.
4 The system registers the equipment.
5 When the diagnostic and maintenance completed the owner collects his/her equipment,
the secretary search the specified equipment by name or tag number.
6 The system displays the result via UI18 equipment list page
7 The secretary inputs the issue date of the equipment.
8 The system updates the equipment.
9 End use
2.10.4 User Interface Prototyping

An essential user interface prototyping is a low-fidelity model or prototype, of user interface for
the system. It presents the general ideas behind the user interface, but not the exact details.
Essential user interface prototypes represent user interface requirements in a technology
independent manner. The team has identified the following major user interfaces.
Request for Help (submit Problem)

First Name Input field, Last Name Input field,
characters only characters only
Faculty List, Department List,

Faculty Name Department Name
Floor or Office number Telephone Number List,

Input filed, character and numeric character
Fig. 2.2 User Interface prototype for problem submission.
E-mail Input field, Date and Time List,
character Date and Time
Problem Type
List, 47
Check Problem Status
Search by Case Number Case Number

Label, Input field,
character only Numeric only
Problem Status
Reported By First Name Last Name

Label, characters only characters only
characters only
Assigned Tech. First Name Last Name

Label, characters only characters only
characters only
Status Status
Label, input field
characters only i.e. Solved, not solved, Escalated
Fig. 2.3 User Interface Prototype for Check Problem Status.
Prepare Announcement
Announcement Date Announcement

Input field, Input field,
Date and Time character and numeric
Drafted By
List,
i.e helpdesk manager, system
administrator manager
Fig. 2.4 User Interface Prototype for Post Announcement
48
Approve Announcement
Announcement Date Announcement

Date and Time character and numeric
Drafted By
input field,
character only
Fig. 2.5 User Interface Prototype for Approve Announcement
Register Technician
First Name Last Name

characters only characters only
Location Telephone
List, Input field,
i.e. main campus, 4 kilo characters + numeric
E-Mail
Input field,
characters + numeric
Save Cancel
Button, Button,
characters only characters
only
Fig. 2.6 User Interface Prototype for Register Technician
49
Assign Technician
Reported problems track List of Available Technician

number Input field,
List, numeric only
numeric only
Fig. 2.7 User Interface Prototype for Assign Technician.
Register Equipment (check in & Check out)
Track number Equipment Type

Input field,
numeric only
List,
Includes computer,
printers, scanner
Model Tag Number Received Date Issue Date

Input field, Input field, Input field, Input field,
character numeric only character only character only
only
Fig. 2.8 User Interface Prototype for Equipment Registration
50
Record Problem Findings
Problem Finding
Input Field,
character only
Fig 2.9 User Interface Prototype for Post Problem Findings
Generate Report
By Status Generated Report by Category

Input field,
By Location
character
Input field,
By Date
character
Input field,
By Technician
character
Input field,
character only
By Problem Type Display only

List,
Includes hardware,
software, internet etc
Fig. 2.10 User Interface Prototype for Generate Report
51
2.10.5 User Interface Flow Diagram
Fig 2.11 User Interface Flow Diagram
2.10.6 Domain Modeling with Class Responsibility Collaborator (CRC) Cards

Domain modeling is the task of discovering the classes that represent the things and concepts
pertinent to your domain space [3].CRC model is collection of standard index cards that have
been divided into three sections, which are class name on the first row, responsibilities left
column of the second row and collaborator on the right column of the second row
Class: -is a collection of similar objects

Responsibility: -is something that the class knows or does.
Collaborator: - is another class that a class interacts with to fulfill its responsibilities.
Class Name
Responsibilities Collaborator
Fig 2.11 CRC Sample table
52
2.10.7 Identifying classes
There are basically three types of classes: actor class, business class, user interface class.
I. Actor class
Actor class represents that appear in the use case model. The following actors are recognized in
the system.
User <<actor>> Helpdesk manager <<actor>>

- Submit IT related problems Problem - Assign technician Problem
- check problem status - check problem status Technician
- User Name, ID, Department, - escalate problem
block number, office number, - generate report
equipment tag number,
description.
Secretary <<actor>>
Technician <<actor>>
- post problem findings Problem - Post announcement Helpdesk Manager
- Escalate problem - Submit problem
- name and address - check problem status
- Register technician
ICTDO officer <<actor>>

Fig 2.12 Actor Class
- Approve announced Secretary
II. Business Class
Business classes are places, things, concepts and events that describe what the business is all
about. In this system the subsequent business classes are recognized
53
Problem Register Tech
- case number User or secretary * see prototype* Secretary

- reported date Technician
- problem status Manager
- problem type Secretary
- Assigned technician
- problem description
- problem findings
- solved date
Post announcement approve announcement
* see prototype* Secretary * see prototype * ICTDO officer

Helpdesk manager
Register equipment
- owner name Secretary

- equipment type Technician
- equipment model
Fig 2.13: Business Class
- equipment tag number
- received date
- delivered date
- case number
54
III. User Interface class
User interface classes are screen menus and reports that make up the user interface. The
subsequent user interfaces are recognized.
Submit problem Assign Technician
* see prototype * User New problems Helpdesk Manager

Secretary assigned technician
assigned date
Approve announcement
Post announcement
* see prototype * ICTDO officer
* see prototype * Secretary
Check Problem Status

Search Data
Helpdesk manager Search content Secretary
Technician User
Manager
ICTDO officer
Technician
Register technician

Manager
55
Register Equipment
Generate Report
Post Problem findings
* see prototype * Manager
* see prototype * Technician
ICTDO Officer
Fig 2.14: Business Class
2.11 System requirement of the new system
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 proposed system aims to keep as much of the advantages of the
current system as possible while doing away with the disadvantages.
The system to be designed will implement web based application within the intranet of AAU.
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.11.1 Functional requirements

1. Problem submitting module
The system should help
Submitting problem by allowing the user filling the necessary information on the online
problem submitting form.
56
Viewing all submitted problems and generating report related to the problem.
2. Fixed Asset registering module

Registering ICT-related AAU fixed assets by allowing the user filling the necessary
information on the online fixed asset registering form.
Viewing all registered fixed assets and generating report related to it.
3. User Registration module

Registering system users by allowing the system administrator by filling the necessary
information on the online user registering form.
Viewing all system users and generating report related to the user.
4. Technician Assigning module

Assigning technician to a submitted problem by allowing the helpdesk manager filling
the necessary information on the online technician assigning form.
Viewing all problem assigned technicians and generating report related to the
technician.
5. Problem Prioritizing module
The system should help helpdesk manager

Prioritizing the submitted problems by allowing the helpdesk manager filling the
necessary information on the online problem prioritizing form.
57
Viewing the status of all problems by priority and generating report these reports.
6. Technician Registering module

Registering all legible AAU technicians in the ICTDO Helpdesk unit by allowing the
system administrator filling the necessary information on the online technician
registering form.
Viewing all registered technicians and generating report related to all the technicians.
7. Problem type registering module

Registering problem types by allowing the system administrator filling the necessary
information on the online problem type registering form.
Viewing all registered problem types and generating report related to the problem type.
8. Findings registering module

Submitting findings of each technician with respect to each assigned problem by
allowing the technician filling the necessary information on the online problem finding
registering form.
Viewing all findings registered and generating report related to the findings.
9. Announcement module
58
Submitting and approving announcements by allowing the respective user filling the
necessary information on the online announcement form.
Viewing all announcements and generating report related to them.
10. User Help Guide module

Viewing help guidelines for some frequently happening problem routines.
11. Activity report generating module
The system should help the Helpdesk manager

Viewing all submitted problems within a given time range and their status and
generating the respective report in a format deliverable to the ICTDO officer.
Viewing workload of technicians within a given time range and generating the
respective report.
2.11.2 Not Functional requirements

Non-functional requirements cover aspects of the system such as user interface, performance,
quality issues, security that the system must fulfill. The system should include the following
non-functional requirements.
The front end of the system will be developed using HTML and JavaScript while the
database will be built with MYSQL Server.
The system requires the following but existing and available hardware resources
Server
Networking cables, hubs, and switches and routers
Personal Computers
The system will be:
59
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 monitor the progress of the problem.
Scalable as new hosts (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 modules 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
60
Chapter Three
Object-Oriented Analysis
3.1 Introduction
In object oriented system development approach, both data and actions are bounded together
so that data hiding is possible through abstraction to form objects which are instances of
classes. These data and actions are considered to be of the same importance, and neither takes
precedence over the other. Classes may also be related to each other through hierarchical
relationships such as generalization, specialization and inheritance for better code reusability
and maintainability.
In this chapter we produce an Object-oriented analysis model of the AAU Online Web Based
Helpdesk Management System describing the application domain from the specification
produced in chapter two. We focus on the identification of objects, their behaviour, their
relationships, their classification, and their organization. The team works hand in hand with
users in this activity, especially when the system specification needs to be changed and when
additional information needs to be gathered. 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. 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.
The chapter is organized in such a way that it starts by presenting a system use case modeling
followed by sequence diagrams, class diagrams, activity diagrams and UI prototypes. It finally
describes Non functional requirements and constraints followed by the list of future likelihood
change cases of the AAU Online Web Based Helpdesk Management System (OWBHMS).
3.2 System Use Case Modeling

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. A system use case includes a high level of implementation decision
beyond an essential use case. An essential use case model is an abstract technology-
61
independent view of the behavioral requirements. It is a task case model of the system. A
system use case model 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. [3]
A system use case modeling activity involves the identification User interfaces (UI), Business
Rules, Actors, Use Cases and Use Case Diagramming tasks as described in the subsequent
sections.
3.2.1 UI Identification
The user interface is the portion of the AAU Online Web Based Helpdesk Management system
where the user directly interacts with, including the web forms, reports, documentation, and
support via telephone and electronic mail. The following table, Table 3.1, consists of the list of
identified user interfaces of the Helpdesk Management system.
Table 3.1: List of UI of the OWBHMS of AAU
Identifier Interface Name
UI 01 Home page
UI 02 Log-in page
UI 03 System user registration web page
UI 04 Problem solving guideline uploading web page
UI 05 AAU offices Registration web page
UI 06 Problem type registration web page
UI 07 AAU equipment registration web page
UI 08 User problem report page
UI 09 Technician registration web page
UI 10 Prepare Announcement web page
UI 11 Announcement approval web page
UI 12 Problem solving guideline viewing web page
UI 14 Problem status viewing web page
62
UI 15 Technician workload viewing web page
UI 16 Report generation web page
UI 17 Problem Status List
3.2.2 Business Rule Identification

The business rules are the operating principles, policies and constraints that the AAU OWBHMS
must satisfy where each business rule identified has Name, Identifier as listed in Table 3.2
below. Note, as we mentioned in chapter one there is no written business rule or policy
documents but the below specified rules are well aware in the university.
Table 3.2: List of AAU OWBHDMS business rules
Identifier Name
BR 01 All users must be registered and have a user name and

password.
BR 02 Each AAU’s equipment must have tag number before reporting

for support.
BR 03 Each AAU office must be assigned support priority level.
BR 04 Announcements must be approved before they are posted to the

public.
BR 05 Equipments which could not repair on site should be delivered to

the office for further investigation.
BR 06 All users should bring an employment ID for registration.
3.2.3 Actor Identification

An actor represents anything or anyone that interacts with the system. This may include
people, external systems, and other organizations. The identified actors of the system have
name and description as listed in the Table 3.3 below.
63
Table 3.3: List of the AAU OWBHDMS actors
Name Description
ICTDO officer Displays consolidated reports
Approves announcements
Manager Displays consolidated reports
Views any required information
Assigns problems to technicians
Addresses escalated problems
Views technician workload
Technician Posts problem findings and escalated problems
Views assigned problems
Secretary Views problem status
Posts problems to be solved received through telephone
User Post problems to be solved
View problem status
3.2.4 Use Case Identification

Use case is a sequence of actions that provides a measurable value to an actor. Another way to
look at it is that a use case describes a way in which a real world actor interacts with the
system. The following table, Table 3.4, consists of the list of identified use cases (UC) of the
Online Web Based Helpdesk Management system.
Table 3.4: List of use cases of the OWBHMS of AAU
Identifier Use case
UC 01 Log-in to the system
UC 02 Register system user
64
UC 03 Register technician
UC 04 Post problem solving guideline
UC 05 Register AAU office
UC 06 Register Problem type
UC 07 Register AAU equipment
UC 08 Post Problem
UC 09 Prepare announcement
UC 10 Assign Technician
UC 11 Post Problem findings
UC 12 Escalate problem
UI 13 Approve Announcement
UI 14 Generate Report
UI 15 Display Problem solving

guideline
UI 16 Display Problem status
UI 17 Check Technician workload
UI 18 Equipment list
3.2.5 Use Case Diagram

Use case diagram depicts 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 demarcated. The
actors are outside the boundary of the system, where as the use cases are inside the boundary
of the system as shown in Figure 3.1 below.
65
Figure 3.1: Use Case Diagram for the OWBHDMS of AAU.
66
3.2.6 Use Case Description

Name: Request
Identifier: UC001
Description: Submit a request for help
Actor: User or Secretary
Precondition: the user is identified and authenticated.
Post condition: The request will be registered. Track number will be generated.
Stake holders and Interests:
• User: Wants to submit problem accurately and diligently
• Manager- Wants to be able to assign a technician for the given problem
• Office: Wants to accurately record problems and satisfy users
1. The use case begins when the user or the secretary (if the user is not in a position
to submit his/her request due to network or power failure then the secretary plays
users role on behalf) indicates they wants to a request for help .
2. The user or secretary inputs user name and password to the system via UI02 log-in
page.
3. The system verifies that the user or the secretary is valid to submit the request.
[Alt Course A]
4. The system Displays UI08 submit problem page.
5. The user or secretary inputs name, faculty, department, office number, telephone,
email date, problem type and description. If the problem type is a hardware.[Alt
Course B]
6. The system generates track number to the user.
7. End use case
Counter. If the Value of the counter is greater than 3.
67

Alternate course B: The hardware is not AAU’s property
B5: The system informs the user he/she cannot get the service.
Name: Assign technician

Description: Assign a technician for a given problem
Actor: Manager
Precondition: The manager is identified and authenticated. Technician workload must be
checked.
Post Condition: Technician will be assigned.
Stake holders and Interest: Manager – need to assign a technician for each new arrival
problem.
1. The use case begin when the manager want to assign a technician.
2. The manager inputs user name and password via UI02 log-in page
3. The system verifies that the manager is valid to see outstanding problems.[Alt
Course A]
4. The system displays outstanding problems UI 14 problem status list page.
5. The manager checks the work load of the technician via UI15 technician workload
web page.
6. The manager assigns a technician who is free or has less workload.
7. End use case
68

Name: Post problem findings
Description: If a given problem is solved then findings to solve the problem registered for
reference.
Actor: Technician, Helpdesk Manager
Precondition: The technician or helpdesk manager is identified and authenticated. The
specified problem must be solved problem.
Post condition: Problem finding is recorded. Problem report is updated.
Stake holders and Interest:
• Helpdesk Manager & Technicians – wants to update their findings for reference in case of
the same kind of problem might be reported.
1. The use case begins when the technician or the manager (for escalated problem)
indicates they want to record their findings.
2. The technician or the manager inputs user name and password in to the system via
UI02 log-in page.
3. The system verifies that the technician or the manager is valid to write findings
into the system.[Alt Course A]
4. The technician or the manager searches the problem by its track number.[Alt
Course B].
5. The system displays problem status list via UI 14 problem status list page.
6. The technician or the manager inputs the findings to the system
7. Update the database.
8. End use case
69
A4: The system informs the technician or the manager he/she is not a valid user to register
the findings. .
Alternate course B: the search result returns empty record
B5: The system informs the technician it cannot search the specified problem.
Name: Check problem status
Identifier: UC004
Description: Check a given problem is solved, unsolved or escalated
Actor: Helpdesk manager, User, Secretary, Technician.
Precondition: the actor is identified authenticated.
Post condition: The actor will get full information regarding to the specific problem.
Stake holders or interest: Manager - wants to know the status of the specified problem in
order to make decision.
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 UI02 log-in page.
3. The system verifies that the actor is valid to check the status of the problem.[Alt
Course A]
4. The actor inputs the track number of the specific problem via UI14.
5. The system displays the status of the problem via UI14.
6. End use case
A4: The system informs the actor he/she is not a valid user to check the problem status.
findings. .
70
Name: Prepare announcement

Identifier: UC005
Description: The secretary prepares and stores announcement.
Actor: Secretary
Precondition: The secretary is identified and authenticated.
Post condition: The announcement will be stored into the system.
Stake holders or Interest: the office needs to convey information to the user.
1. The use case begins when the secretary wants to prepare announcement.
2. The secretary inputs user name and password in to the system via UI02 log-in
page.
3. The system verifies that the secretary is valid to input the announcement.[Alt
Course A]
4. The secretary enters the announcement to the system.
5. End use case
A4: The system informs the secretary that she is not valid to enter the announcement.
Name: Approve announcement

Description: all announcements have to be approved before posted to the public by the ICTDO
officer.
Actor: ICTDO officer
Precondition: The announcement should be uploaded. The officer identified and authenticated.
Post condition: The announcement will be disseminated to the users.
Stake holders or Interest: Users – the user need to be aware of ICT related information.
71

1. The use case begins when the officer wants to approve the announcement.
2. The officer inputs user name and password in to the system via UI02 log-in page.
3. The system verifies that the officer is valid to approve the announcement.[Alt
Course A]
4. The system displays new uploaded announcements via UI11 approve
announcement page, which indicate the list of new prepared announcement.
5. The officer puts his/her approval by selecting approve check box. [Alt Course B]
6. The system approves the announcement.
7. End use case
A4: The system informs the officer that she/he is not valid to approve the announcement.
Alternate course B: The officer needs to edit the announcement
B5: The system change UI11 approve announcement page into edit mode when the officer
needs to edit the announcement.
Name: Register Technician
Identifier: UC007
Description: register technicians who are employee to the office
Actor: Secretary
Precondition: the secretary will be identified and authenticated.
Post Condition: The technician will be registered.
1. Assume that she is in the system.
2. The system displays UI09 technician registration page
3. The secretary inputs first name, last name, telephone, email and location of the
technician.
72
4. The system registers the technician.

5. End use case
Name: Generate report
Identifier: UC008
Description: The manager wants to generate a consolidated report.
Actor: Manager
Precondition: The actor is identified and authenticated.
Post condition: obtain a compiled report
Stake holders and Interest: ICTDO Officer & Helpdesk Manager
1. Assume that both actors are in the system
2. The system displays UI16 Report Generation Page,
3. The system asks the actors whether they want a printed report.
4. The system prints the report.
5. End use case
Name: Search
Identifier: UC009
Description: The Actors can search available data from the database.
Actor: ICTDO officer, Helpdesk Manager, Secretary, Technician, user
Precondition: the actor needs to have the key word.
Post condition: The actor obtains information.
Stake holders and interest: ICTDO officer and helpdesk manager – wants to get information.
Secretary - search user support information.
Technician- may searches information from the knowledge repository.
User: can find any supportive information regarding to his/her problem.
Basic Course of Action:
1. The system displays UI01 home page
2. The actor inputs the key word and search
73
3. The system displays the result via UI17 search result page.
4. End use case.
Name: Register Equipment
Identifier: UC010
Description: Register equipments which came for maintenance
Actor: Secretary
Precondition: equipments which could not repair on site should be delivered to the office.
Post condition: equipment will be registered and ready to diagnose and maintain in the work
shop.
Stake holders or interest: user
1. Assume that the identification and authentication is over and the secretary is in the
system
2. The system displays UI07 aau equipment registration page, which allows the secretary
to enter information regarding the equipment.
3. The secretary inputs equipment’s type, track number, model, tag number, received
date.
4. he system registers the equipment.
5. When the diagnostic and maintenance completed the owner collects his/her
equipment, the secretary search the specified equipment by name or tag number.
6. The system displays the result via UI18 equipment list page
7. The secretary inputs the issue date of the equipment.
8. The system updates the equipment.
9. End use
74
3.3 Sequence Diagrams

Sequence diagrams are used to model the logic of usage scenario; usage scenario is exactly
what its name indicates-the description of potential 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)
Figure 3.3: Post Problem (SD#002)
75
{SD#003: Main Menu<UI> Technican Assignment

Manager<Actor> :Technician DB
Assign Technican} <UI> :Problem
Manager wants to assing technican

<<create>>
Request new problem list
*Manager want to getProblem(assignedTechnican=null)
assign technician to a
new problem. return(assigned Technican=NULL
New problem List
* The system displays
any new posted Request Technican List
problems. Request technican on duty GetTechnican Workload
* The manager request
available technician name and workload no
Available Technican on duty with their current workload list()
on duty.
* The system displays Assign Technican
available technician. Assined Technican(Id,track no)
Update Problem(ID,Track no)
* The manager assign a
technician to new/ updated rows()
unassigned problems Update success()
message
extends SD#004
(view technican workload)
see next process on SD#004
Figure 3.4: Assign Technician (SD#003)
Manager Main Menu Technician Workload :Technician :Problem

Page<UI> DB
<Actor> <UI> <Controller> <controller>
{SD#004
View Technican
Wish to View technician
Work Load}
workload <<Create>> Technician profile GetTechnican(OnDuty =yes)
request
*The manager wishes to
view technician Technican name Return Technican(Onduty=yes)
workload.
* The manager request Tech ID
Technician workload GetTechnican If[bool=1]
status to the system workload(ID) count=+1
Match(ID)
Technician workload Assigned problem (Name,num) Boolean()
Return count(num)
status.
Loop(criteria=false)
Figure 3.5: View Technician Workload (SD#004)
76
Figure 3.6: Register AAU Office (SD#005)
Figure 3.7: Register System User (SD#006)
77
Figure 3.8: Register Technician (SD#007)
{SD#008 Secretary Problem type Page :Problem DB

Register <Actor> <UI> <controller>
Problem Type}
Fill Problem type

* The secretary enters
problem type list.
Invalid message()
* The system validate the
data
* The system update the Save()
database. Add()
success message Success message()
Figure 3.9: Register Problem Type (SD#008)
78
Officer Announcement Page :Announcement

{SD#009 DB
<Actor> <UI> <Controller>
Approve
Announcement}
Check announcment
request
* The officer check posted Request announcemnt
announcement. Announcement content Posted announcement
available announcement. Approve or
* The officer approve the Reject Edit()
announcement. Approved=[0/1]
Boolean()
Success message
Figure 3.10: Approve Announcement (SD#009)
Figure 3.11: Post Problem Finding (SD#010)
79
Figure 3.12: Register AAU Equipment (SD#011)
Figure 3.13: Prepare Announcement (SD#012)
80
Main Menu Problem Status Page : Problem

<Actor> <UI> Problem File
{SD#013 <UI> <Controller>
View Problem Status}
Wish to View
problem <<Create>>
* User, Manager, secretary
Or Technician wish to
view problem Input Track no
* The Actor Enter Track no Problem(track no) Get-Problem ()
* The System verify Track
no Return Problem ()
problem status detail. Verify Track no
Invalid message() [track no=false]
[track no=true]
Problem status()
Figure 3.14: View Problem Status (SD#013)
3.4 Class Modeling

Class model shows the classes of the system, their interrelationships (including, inheritance,
aggregation and association), and the operation and attributes of the class. A class is a
representation of an object. To describe a class we define its attributes and methods. Attributes
are the information stored about an object while methods are what the object or the class
does.
3.4.1 Class Identification

From the documentation of the system use cases in Section 3.2, the project team has identified
the following list of classes as represented in Table 3.5 below.
Table 3.5: List of identified classes for the OWBHDMS of AAU
Identifier Name Description
Cl01 Class User Describes every user of the system
Cl02 Class Manager Describes the Helpdesk manager
Cl03 Class ICTDO Describes the ICTDO officer
Cl04 Class Technician Describes a technician
Cl05 Class Secretary Describes the Secretary
81
Cl06 Class Describes an announcement

Announcement
Cl07 Class Problem Describes a reported problem
Cl08 Class Office Describes problem reporting office
Cl09 Class Equipment Describes supportable equipment
Cl10 Class Guideline Describes a guideline users can follow to solve

a specific problem
Cl11 Class Report Describes a specific report output from the

system
3.4.2 Data and Actions

As described in Section 3.1, each identified class in Table 3.4 is represented in terms of its data
content and the associated actions. The data are represented as the attributes while the actions
are expressed by methods and properties. The identified attributes and actions are listed in the
subsequent tables Table 3.5 and Table 3.6.
Table 3.6: List of identified attributes
Identifier Attribute Name Description
At01 UserName Consists of name of a system user
At02 UserGroup Consists of specific group of a user
At03 Track Number A Unique number assigned to each reported

problem
At04 Announcement A unique code assigned to each

ID announcement.
82
Table 3.7: List of identified actions
Identifier Action Name Description
Ac01 AddUser Addis a new system user
Ac02 EditUser Edits attributes of an existing system user
Ac03 AddProblem Adds a new problem by assigning a Unique

case number.
Ac04 EditProblem Amend attributes of an existing problem
3.4.3 Conceptual Modeling

Class model shows the classes of the system, their interrelationships (including, inheritance,
aggregation and association), and the operation and attributes of the class. A class is a
representation of an object. To describe a class we define its attributes and methods. Attributes
are the information stored about an object while methods are what the object or the class
does[xx]
83
3.4.4 Unrefined class diagram
84
Figure 3.16: Unrefined Class Diagram of the AAU OWBHDMS
3.4.5 Refined class diagram.
Figure 3.15: Class Diagram of the AAU OWBHDMS.
85
3.5 Activity Diagrams

UML 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. The project team has modeled activity diagram
for each use cases identified in use case modeling
part.
Fig. 3.16 Activity Diagram For Post Problem
86
Fig 3.17 Activity Diagram for Check Problem Status
87
Fig. 3.18 Activity Diagram for Assign Technician
88
Fig. 3.19 Activity Diagram for Prepare Announcement
89
Fig. 3.20 Activity Diagram for Prepare Announcement
90
Generate Report
AD#:006
Fill-out Login Form
[Incorrect]
[correct]
Display List of Options
Generate Report
Fig. 3.21 Activity Diagram for Generate Report
91
Fig. 3.22 Activity Diagram for Register User
92
Fig.3.23 Activity Diagram for Register Office
93
Fig. 3.24 Activity Diagram for Register Equipment
94
Fig. 3.25 Activity Diagram for Post Problem Findings
95
3.6 User Interface
User interface prototyping (UI) is an iterative analysis technique in which users are actively
involved in the mocking-up of the User Interface for a system.
UI prototyping has two purposes: First, it is an analysis technique because it enables to explore
the problem space the system addresses. Second, prototyping enables to explore the solution
space of the system at least from the point of view of its users. The team has conducted user
interface prototyping and found the following major user interfaces.
Fig. 4.26 User Interface Diagram for Login
96
Fig 4.27 User Interface Diagram for Post Problem
97
Fig. 4.28 User Interface Diagram for Check Problem Status
Fig. 4.29 User Interface Diagram for Problem Status Result
98
Fig 4.30 User Interface Diagram for Post Annoucement
99
Fig. 4.31 User Interface Diagram for Approve Announcement
100
Fig. 4.32 User Interface Diagram for Register Technician
3.7 Supplementary specifications
3.7.1 Non-functional requirements
The new system can be installed on many operating systems. The new system runs not only on
Linux and on other UNIX derivates, but on all Microsoft Windows platforms too. The new
system has no excessive hardware requirements. We recommend using a machine which is
already exists in different department of the AAU.
Non-functional requirements cover aspects of the system such as performance quality issues
security that the system must fulfill. The system should include the following non-functional
requirements.
The front end of the system will be developed using HTML andϖ JavaScript while the
database will be built with MYSQL server.
101
The new system requires the following hardware resources:

Personal computers, Networking cables, Server, Switches, Hubs, Routers
For database that will be added in the future, we recommend to use MySQL. However, all
database servers that use SQL for their database language should be able to work with the new
system.
3.7.2 Constraints
The new system has some constrains due to the rules & regulations of the ICTDO office. The
following are constrains of the system:
There is priority level for different offices.
The system works only for AAU property.
The system works only for properly filled forms online.
The system works only for the university staff.
3.8 Documentation of change cases

Change cases are used to describe new potential requirements for a system or modifications to
existing requirements. We describe the potential change to our existing requirements, indicate
the likeliness of that change occurring, and indicate the potential impact of that change. The
following are change cases of the system:
Change case: need to support new database vender
Likelihood: medium. The office has a plan in near future to negotiating contract with
database vender.
Impact: potentially large if SQL is hard-coded into the application.
Change case: need to support personal computers.
Likelihood: certain. The university already has personal computers.

Impact: large. The costs of personal computers are very expensive so that economically it has
large impact.
102
Chapter Four
Conclusion and Recommendation
4.1 Conclusion
This document contains only the analysis part of the overall project. In the introduction part the
team has identified problems of statement, scope, objective, significance, schedule of the
project and other related issues. Then the team has studied the business area and identified all
the functional and non-functional requirements for the proposed system. Finally these
requirements are modeled using all types of object oriented analysis artifacts.
The team believes that anyone can read and understand the document because it is well
illustrated using both text and modeling and it will be the base for the design and
implementation phases, which we will develop in the second part of the project. Finally the
team might add additional features and functionalities to the system on the design and
implementation phase.
4.2 Recommendation
This project tries to address all problems which cussed the office not serve the user in its full
capacity. We believe that the system that is going to be developed will curve the problems and
enhances the office’s service delivery role and builds a positive image. The team has no
hesitation recommending using the software that we are going to develop. Our investigation
indicates that, due to lack of ICT policy and business rule, the helpdesk section spent a lot of
time and effort to address some specific problem type so in our opinion it will good to have
such policy and procedures.
103
References
http://www.aau.edu.et/ict/index.php, last date visited on May 28,2009
System Analysis and Design, Jeffery L. Whitten and Lonnie D. Bentley /2005
The object Primer, Third edition by Scott W. Ambler/2003.
Object Oriented Design and Analysis using UML, Third Edition by Craig Larman/2002
104

Online Web Based Helpdesk Management Sys

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Online Web Based Helpdesk Management Sys

Uploaded by

Copyright:

Available Formats

On

ADDIS ABABA UNIVERSITY

System Analysis Document

1. Asegid Asfaw CCE/5575/99

2. Henok W/Michael CCE/4137/99

3. Meseret Abiy CCE/0209/99

4. Wolelaw Berhane CCE/4169/99

5. Wondafrash Woldie CCE/4170/99

Industrial Project I (CSCE 495)

In Partial fulfillment of the Requirements for B.Sc Degree in Computer

Advisor: Lemma Lessa (M.Sc. IS)

Continuing and Distance Education Unit

08 January 2009 G.C. (Tir 2001 E.C.)

Chapter One .................................................................................................................................................. 7

Project Identification and planning............................................................................................................... 7

1.1 Introduction .................................................................................................................................. 7

1.2 Background of the Organization ................................................................................................... 7

1.2.1 Information Communication Technology Development Office (ICTDO) .............................. 8

1.2.2 Network Infrastructure (LAN/WAN) ..................................................................................... 8

1.2.3 Data Center ........................................................................................................................... 9

1.2.4 Services ............................................................................................................................... 10

1.2.5 ICTDO Organization and Management ............................................................................... 10

1.2.6 The Helpdesk Section .......................................................................................................... 11

1.3 Statement of the Problem .......................................................................................................... 11

1.4 Objective of the Project .............................................................................................................. 12

1.4.1 General Objective ............................................................................................................... 12

1.4.2 Specific Objectives .............................................................................................................. 12

1.5 Feasibility Study .......................................................................................................................... 13

1.5.1 Economic Feasibility ............................................................................................................ 13

1.5.2 Technical Feasibility ............................................................................................................ 15

1.5.3 Operational Feasibility ........................................................................................................ 15

1.5.4 Conclusion on feasibility studies ......................................................................................... 16

1.6 Scope of the Project .................................................................................................................... 17

1.7 Significance of the Project .......................................................................................................... 17

1.8 Beneficiary of the Project ........................................................................................................... 18

1.9.1 Data Collection Methodology ............................................................................................. 18

1.9.2 System Development Tools ................................................................................................ 18

1.10 Project Organization ................................................................................................................... 19

1.10.1 Role and Responsibilities of Team Members ...................................................................... 20

1.11 Project Plan ................................................................................................................................. 20

1.11.1 Work Break down Structure and Deliverables.................................................................... 21

1.11.2 Gantt chart .......................................................................................................................... 23

1.12 Organization of the Document ................................................................................................... 24

CHAPTER TWO ............................................................................................................................................ 25

Business Analysis and Requirements Definition ......................................................................................... 25

2.1 Introduction ................................................................................................................................ 25

2.2 Major functions of the Existing System ...................................................................................... 25

2.3 Forms and Documents used in the existing System ................................................................... 27

2.4 Business Rules ............................................................................................................................. 27

2.5 Major Role Players ...................................................................................................................... 28

2.5.1 Helpdesk Manager .............................................................................................................. 28

2.5.2 ICTDO officer ....................................................................................................................... 29

2.5.4 Secretary ............................................................................................................................. 29

2.5.5 Users ................................................................................................................................... 29

2.6 Problems of the Existing System in PIECES framework .............................................................. 30

2.7 Practice to be preserved from the existing system .................................................................... 32

2.8 Alternative options to address problems of the existing system. .............................................. 32

2.9 Option Analysis and the proposed new system.......................................................................... 33

2.9.1 Option 1: Enhancing the current system. ........................................................................... 33

2.9.2 Option 2: Purchasing off the shelf helpdesk software........................................................ 34

2.9.3 Option 3: developing windows based helpdesk management system .............................. 34

2.9.5 Option Analysis Conclusion ................................................................................................. 35

2.10 Essential Use Case Modeling....................................................................................................... 35