Srs

University of Palestine

Faculty of Applied Engineering and Urban Planning

Software Engineering Department

Software Engineering Group Project

Ticket Help Desk Support System

System Requirement Specifications (SRS)

Prepared by

Ahmed Obaid Wassim Salem

Fariza El Sharif Fawzy al tayeb

Supervised By

Dr: Mohammed Mikii

April 20, 2011

Ticket Help Desk Support System 2

Table of Contents

1 Introduction ................................................................................................................................ 4

1.1 Overview .......................................................................................................................... 4

1.2 Purpose…………………………………………………………………………………………………….4

1.3 Problem statement ............................................................................................................ 5

1.4 How to gather system requirements ................................................................................. 5

1.5 General Aim of the Automated System ........................................................................... 5

1.6 The System Objectives ..................................................................................................... 5

1.7 Methodology .................................................................................................................... 6

2 Help Desk Support System ........................................................................................................ 8

3.1 Project Description ........................................................................................................... 8

3.2 Help desk Support System Functions............................................................................... 8

3.3 Users of the Help Desk Support System .......................................................................... 9

3.4 Tools Used to Develop the System .................................................................................. 9

3 System Analysis ........................................................................................................................ 10

3.1 Introduction .................................................................................................................... 10

3.2 Functional Requirement ................................................................................................. 10

3.3 Non- Functional Requirement ........................................................................................ 12

3.4 Use Case Diagram .......................................................................................................... 13

3.5 Use Case Specification ................................................................................................... 14

3.6 Class diagram ................................................................................................................. 18

3.7 Activity Diagram ............................................................................................................ 19

4 Maintenance ............................................................................................................................. 19

4.1 Maintenance ................................................................................................................... 19

4.2 Maintenance Tools ......................................................................................................... 20

5 Conclusion ............................................................................................................................... 20

5.1 Limitations ..................................................................................................................... 21

6 References ................................................................................................................................. 22

7 Appendix ................................................................................................................................... 22


Table of Figures

Figure 1.1: Waterfall Model .................................................................................................................... 7

Figure 3.1: Login Package ..................................................................................................................... 13

Figure 3.2: Ticket Package .................................................................................................................... 14

Figure 3.3: Class Diagram ..................................................................................................................... 18

Figure 3.4: Login Help Desk Activity Diagram .................................................................................... 19

Figure 3.5: Create Ticket Activity Diagram .......................................................................................... 19

Figure 3.6: View Assigned Tickets AD ................................................................................................. 20

List of Tables

Table 3.1: Use Case Login .................................................................................................................... 14

Table 3.2: Use Case Open New Ticket .................................................................................................. 14

Table 3.2: View Assigned Tickets ......................................................................................................... 15

Table 3.4: Open New Ticket .................................................................................................................. 16

Table 3.5: Update User .......................................................................................................................... 16

Table 3.6: Complete a Pending Ticket. ......................................................................................................... 17

List of Abbreviations

HDSS Help Desk Support System

PHP Personal Home Page Programming Language

HTML Hyper Text Markup Language (Programming Language)

MySQL Structure Query Language

UML Unified Modeling Language

AD Activity Diagram

../AppData/Roaming/Microsoft/Golden%20-%20Tech/Desktop/HDSS%20Final%20Report%20final%20Azmi.doc#_Toc286870231





../../../../../pc%20home/AppData/Roaming/Microsoft/Golden%20-%20Tech/Desktop/HDSS%20Final%20Report%20final%20Azmi.doc#_Toc286870236


1 INTRODUCTION

1.1 Overview

The idea of our project revolves around technical support to ensure the functioning of the

services that we provide to our customers only and also includes technical support problems

resulting from the use of the client for any of the external programs the wrong way, as well

as problems resulting from the installation or run programs or pages or the interpretation or

resolve the problems of those programs and error messages , or any of the client work on

ways to clear but not limited to all or any of its files or data or the error in the definition of

data sources, loading is greater than its allocated within the organs of the common service.

Technical support for customers through one of their technical support and the right to

develop new regulations in the technical support of any area of service also have the right to

stop any of the systems in place for technical support, and will inform customers of this

briefing.

1.2 Purpose

The main goal and purpose to this project:

1. Provide the service to customers.

2. Learn how to processing technical matters and crises.

3. Increase the gain trust between the client and the labor market in the areas of hosting.

4. Address the disadvantages resulting from the misuse of the site or to the Control Panel.

5. Contribute in the security procedures of the hosted sites that require technical support.

6. Strengthen the economic terms of the investors lost in the hosting of strong competition is

where it is difficult to rely on hosting only, so the introduction of technical support in the

process of diversification has become necessary.

7. Hosting companies is very important and an important factor to increase the number of

customers every technical support and the period they are all there is a patchwork of

confidence in the company by customers.


1.3 Problem statement

The manual system facing of numerous problems which are:

Inability to access data quickly and easily.

Delay to adjust and reform some of the errors lead to suspension of work.

Users are facing difficulties during the course of action to learn the techniques and how to

solve the problems.

Repeat many of the procedures and questions of users that lead to a waste of time and

effort.

There is no place to save the data.

Data are not security and the employee can gain access to many data.

1.4 How to gather system requirements

Been obtained for most of the requirements by conducting interviews with users of the

system (Interviews) Through the review of the documents used in the current system and through

the perception of users of the new system (Document review).

Gathering system requirements is done through monitoring the method of work and outputs

of the current system and tracking operations of the existing system from beginning to end

(Observation).

1.5 General Aim of the Automated System

Help Desk Support System (HDSS) aims to improve quality of performance of the

department by automating the daily processes to improve inventory management, reporting

mechanism on errors and reduce both time required for completing tasks.

1.6 The System Objectives

The main objectives of the Help Desk Support System are to:

Facilitate communication between staff and Maintenance Department.

Produce statistical reports for inventory and tasks.

Identify problems with devices of clients.

Facilitate the access of the system online from anywhere.


Organize the tasks assigned to each technician.

1.7 Methodology

We use the following model (waterfall model) to implement of system; the methodology of

this project is based on five main areas:

1.7.1 Understanding the Requirements of the System

This phase of the project is meant to be for the understanding of the requirements of the

system by gathering information to understanding the helpdesk system and its purpose. A

detailed list of questions has been developed to help better analyze the system requirements.

1.7.2 Design the System

Based on understanding the requirements of the system, the structure of the system has

been identified and designed to respond to the requirements. All databases, forms and reports

were designed in this phase with close consultations with clients (UP staff), technicians and

managers (system administrator), to ensure that the designed system is user-friendly and that it

responds to and addresses their needs and demands.

To ensure that the system is secure, reliable and efficient, it was agreed that the following

programming tools will be designed for the development of the system: HTML, PHP and

MySQL.

1.7.3 Implementation of System

After setting up the scene for the implementation of the HDSS by identifying the

programming languages used and infrastructure of the system, it is now time for the actual

building of the system by adopting the following procedures: Using the previously identified

programming languages to develop the system under the frequent supervision of UP’s

Technicians and relevant managers to ensure the system is built in line with the required

capabilities.


1.7.4 Test and evaluate

Following the development of each of the project components a thorough test to be done

to evaluate the performance of the component and detect any unexpected problems that might

arise. Test case study will also be used to test both mandatory and optional functions of the

system.

Test will include ensuring the objective of the project is realized through the development of the

system in addition to testing the overall appearance, accessibility, navigation, interactivity and

consistency of the system through asking UP staff and technicians to try the system and give

feedback and comments and then take their comments into consideration.

1.7.5 Documentation

In the final stage of the project, detailed information on the system for developers will be

made in addition to a detailed user manual to be as a reference for the system.

Figure1.1: Waterfall Model.


2 Help Desk Support System

2.1 Project Description

The Help Desk Support System is used for the logging, tracking and reporting of all requests

received by the Help Desk from clients through special forms. Clients will be able to report on IT

related errors, problem, support needed, software failure, hardware problems,..etc. When the

client submits the online form, it will create a ticket for the help desk supervisor and they will

pass the ticket to a technician to address the problem.

The designed system can be used as a generic system, and therefore can be easily adopted to

fit with the needs of other stakeholders, companies and institutes. The HDSS allows various

levels of access for different types of users. For example, helpdesk technician does not the same

have privileges as a supervisor or system administration. The system offers two levels of

privileges; client or user and system administrator. The Helpdesk administrator has the primary

rights to set these access privileges for the users of the system when executing the system.

HDSS can generate reports and statistics based on requests received and stored in the

databases to the helpdesk and types of problems also about Things that are available in the store

and other things used or spent for clients. Helpdesk Manager, for their own use or even for the

use Directors of the system, will generally do this.

2.2 Help desk Support System Functions

o Check the Helpdesk System for new calls and online forms requested that have been

logged into the system.

o Check how long a call has been open on the system and update the progress made on the

request.

o Before a request is closed in the helpdesk it should include the problem resolution details.

o The helpdesk system will also allow for the Helpdesk Technicians to be paged with

tickets that have been opened into their queue.

o The system should be able to generate all type of report and statistic that can helped in

decision making.


o The Helpdesk system should allow for different levels of access for different types of

users.

o The helpdesk system should be able to inform you about all things are in the store and all

things are spent to client's period.

2.3 Users of the Help Desk Support System

The users of the system include:

Helpdesk Technicians: are the ones who will address problems that have been recorded into

the system. Technicians can view in their page the tickets that have been created into their

own queue as directed by supervisor.

Helpdesk Administrator: is the one who uses the system for monitoring, running queries

such as type of problems that are received to helpdesk and they can add, delete and update

users to the system.

Clients: are the normal users who submit requests to IT services via phone or submitting the

online forms. Users can also view the tickets they have created for follow up and filing

purposes. Ticket feature can also be used to help users request upgrading their PCs and

devices or other requests to supply stuff and not only limited to reporting problems.

2.4 Tools Used to Develop the System

The following tools have been used to develop the system:

MySQL: is the database where all information/data related to requests, records, logs is

stored.

PHP: is the programming language used to develop the system to enable it to be web-based

application. PHP is considered the link used to connect users to databases through a user-

friendly interface. Additionally, WAMP Server application was used as a local server to host

PHP files to generate them.

Adobe Dreamweaver CS5: is an easy-to-use software application used to create and manage

web pages. It offers many features to help develop professional layout in a few easy steps

much easier than HTML.

Servers: is the place that hosts all project code.


3 System Analysis

3.1 Introduction

The development of the HDSS came through several phases of analyzing the existing trends,

practices. Project relied more on using qualitative data collection methods such as personal

interviews, one-to-one meetings with technicians and other stakeholders, in addition to

observation of the whole support. The collected qualitative data helped building a solid

infrastructure for the development of a comprehensive system ..

In this Section, the functional and non-functional requirements are introduced using the

Unified Modeling Language (UML) which is an open method used to specify, Visualize,

construct and document the artifacts of an object-oriented software-intensive system under

development. UML offers a standard way to write a system's blueprints, including conceptual

components.

Concisely worded statement that describes how the software will behave when it is complete. In

other words, every time a requirement is implemented, the system shall behave in accordance to

the conditions that the requirements establish.

1. Functional requirement: addresses the operations that the system performs (behavior).

2. Nonfunctional requirement: applies to the standards or qualities of performance that

constrain the design or operations of the system.

3.2 Functional Requirement

Functional requirements capture the intended behavior of the system. This behavior may be

expressed as services, tasks or functions the system is required to perform.

3.2.1 Requirement Description

3.2.1.1General Views

1. A client can click on any available link or page to view the content information.


2. Client can exit the system at anytime.

3.2.1.2 Login

1. User of the system (Clients and Administrators) can login to the system using a username

and password.

2. If login information invalid, the system will display an error message and ask to re-enter

the correct login information again.

3.2.1.3 Add New Tickets

1. All users can create a new ticket.

2. A form will be displayed to the user to fill out details on the request then submit the form

to the relevant party.

3. The ticket will be automatically sent to administrator.

3.2.1.4 Add a New Department

1. Only administrator can add/remove departments, colleges or division.

2. An administrator can remove an existing department or college after deleting all users

under that college or department.

3.2.1.5 Administrator management

1. Administrator can view technicians and whether they are engaged or available and can

assign new tasks among technicians.

2. Administrator can update, modify or delete a particular task from any technician’s

account.

3.2.1.6 Add New User

1. User clicks on add a new user button to create a new account.

2. If no data entered and click on ADD button, cannot add data.

3. If the added data is true, the massage of successful added appear.

3.2.1.7 View Old Tickets


1. Clients can view their history of tickets.

2. A list of all tickets requested will be displayed with relevant information by a technician

on the status of the request, whether it is complete or pending.

3.2.1.9 Modify user

1. Administrator can change and update user account information once they move from one

department to another without losing any of the information recorded for that user.

3.2.1.10 Add new maintenance services

1. Only administrator can add/remove maintenance services.

3.3 Non- Functional Requirement

3.3.1 Reliability issues

The system should be able to receive more than a thousand processes by the users

simultaneously.

3.3.2 Usability issues

Users of the system should be able to view information in mille seconds.

3.3.3 Portability issues

The system tends to the adaptation of a software system to other environments consisting

of different hardware, different operating systems, and so forth. These requirements make it

possible to continue using the same basic software in diverse situations or to use it

simultaneously in diverse hardware and operating systems situations.


3.3.4 Security issues

The system aims at preventing unauthorized access to the system or parts of it, detection

of unauthorized access and the activities performed by the hackers, and the recovery of damages

caused by unauthorized hack cases.

3.3.5 Modifiability issues

System allows the rest of the institutions to adjust and use system without many

amendments on the structure of the system, and in an easy and inexpensive way.

3.3.6 Availability issues

Availability of information in the system; will the reaction time for operations be less

than two seconds on average? And will the reaction time of the reports be less than four seconds?

3.4 Use Case Diagram

Figure 3.1: Login Package

Client

Log in

Technician Admin

System

Log out

Session timeout


3.5 Use Case Specification

3.5.1 Use Case Login

Brief description

The use case is initiated by any user of the system whether client,

technician or administrator when they want to access the system. They

will be required to enter a valid user name and password to continue.

Pre- condition Actor account is active.

Characteristics of

activation User of the system should be an employee at the System.

Flow of events

Basic flow

At the login page actor keys in the username and password, and

then click on submit button.

System verifies login info.

System displays the helpdesk main menu.

Figure 3.2: Ticket Package

Add Ticket

Client

Technician

Administrator

Remove Ticket

Assign Ticket

Extends

Extends

Extends

Extends

View User Tickets

View Ticket

Comment Ticket

View assistant Ticket

View Pending Ticket


End of use case

Exceptional flow

Invalid login message: the system shall display “Please enter a

valid username and password”

In case of user account is not active the system will display

message “your account is not active ... contact your system

administrator”

Post-Conditions Login authenticated.

Actor is given access to the main menu.

Table 3.1: Use Case Login.

3.5.2 Use Case Open New Ticket

Brief description The use case is initiated by any client when they need to submit a

request for the technician.

Pre- condition Successful login.

Characteristic of

activation

On user demand.

Flow of events Basic Flow

Actor clicks on create a new ticket link from the main menu

A display form will appear to fill out details of request

System checks if all the required fields are filled out.

System creates a ticket and displays the ticket details

Alternative Flow

Actor can click on reset button to clear entry fields of data to fill

them again

Exceptional Flow

Some required field are not filled and notify the actor to fill them

Post-Conditions Ticket is created and ticket details are displayed on screen.

Table 3.2: Use Case Open New Ticket.


3.5.3 View Assigned Tickets

Brief description View list of assigned tickets that are created by clients ordered by date

and time


Characteristic of

activation On admin demand.

Flow of events

Basic Flow

Actor click on view assigned tickets link on the main menu

List of actor’s assigned tickets are displayed on screen.

Actor clicks on the title of tickets to view details

Ticket details are displayed on screen

Post-Conditions System displays ticket on screen

Table3.3 View Assigned Tickets.

3.5.4 Update User

Brief description Enter Name of user and password within special criteria.


Characteristic of

activation On user demand.

Flow of events Basic Flow

Actor clicks on search tickets link from the main menu

Search ticket page is displayed on screen

Type the keyword or select criteria to search and click the search

button

System displays a list of tickets on screen in accordance with

chosen criteria

Actor clicks on title to display all ticket details

Ticket details is displayed on screen

Exceptional Flow

Keyword not found any row then ask actor to try again

Post-Conditions Search results are displayed on screen.


Table 3.4 Update User.

3.5.5 Complete a Pending Ticket

Brief description Technician can view the tickets and respond by making comments on

the problem and write a final report

Pre- condition The account should be with Technician Privileges

Characteristic of

activation On technical demand and view the ticket

Flow of events Basic flow

When you open a login page, enter the user name and password of

the administrator, and then click the submit button.

System verifies login info.

View tickets and read the content problem.

Modify the state of the ticket was completed.

Writing the final report of the ticket.

End of use case

Exceptional flow

Invalid login message: the system shall display “Please enter a

valid username and password”

Post-Conditions Login authenticated.

Table3.5 Complete a Pending Ticket.


3.6 Class diagram

3.6.1 Class Diagram Method Description

Class diagram described as an approximation of the main components that make up the system

Person is all users who have access to the system whether they have administrator’s

privileges, technician’s privileges or a normal client privileges.

Newsperson (String): to add a new person , may be admin , client or user.

Delete Person (String):to delete existing person , may be admin , client or user.

Modify Person (String): to modify existing person, may be admin, client or user.

Admin: is a user with full authorizations over the system. Admin can fill in all fields and

can activate or deactivate all types of accounts.

Client: can update their profiles and change their regular settings such as password,

personal information

Figure 3.3: Class Diagram


Ticket: all information related to maintenance tasks requested including clients making

requests, technicians assigned to follow up a request, and all details of the request.

View Ticket (): to view all users how uses the HDSS system with his description.

View Assistant Ticket (): to view all assistant.

View Pending Ticket (): to view all pending ticket.

Final Report It is an update process to track the status of the tickets. A technician’s final

report appears on the tickets.

3.7 Activity Diagram

Figure 3.4: Login Help Desk Activity Diagram

Actor type in Username

and password

System verifies

username and

password

System display help

desk main menu page

Username and password

valid?

End

No

Yes

Begin

Figure 3.5: Create Ticket Activity Diagram

System create ticket and

display ticket details

End

No

Yes

Begin

All required field are filled?

System display create

ticket page

Actor type in details of

ticket

Actor click on create

button

System checks if required

field are filled


Figure 3.6: View Assigned Tickets AD

4 Maintenance

Software maintenance is done to this system for the purpose of correcting faults, improving

performance, or adapting the system to a new environment. System can be maintained when

needed or required. The following the times when system needs to be maintained:

When a new functionality is added.

When the reality the software models changes.

Software must be updated to run on improved hardware or with improved software.

End

Begin

Actor click view assigned ticket

link

System display list of actors

assigned ticket

Actor click on title of ticket to

view details

System displayed ticket details


4.1 Maintenance Tools

They system is designed to be flexible to changes that might happen to the working

environment including its ability to add/remove a new department , update ticket , update

department ,add new user and update user. All these problems can be handled by the system

administrator.

The following are the main types of maintenance that might need to be done to the system:

Corrective: fixes a fault in the software without changing or adding to the software's

functionality.

Adaptive: modifies software to preserve functionality in a changed environment.

Perfective: improves software performance, maintainability, etc., and can extend the

functionality of the application.

Preventive: changes are made to the system in order to prevent further faults and to improve the

structure and maintainability of the system.

5 Conclusion

As the growing use of computers and other electronic devices would mean the growing

demand on rapid and quick technical support, this Help Desk Support System is carefully

designed to fit with the rapid technical support. It not only helps reducing the time of recording

and tracking inquires and problems traditionally, but also improves quality and accuracy of data

produced by the system which can lead to more facilitation of decision making process in time.

HDSS is designed to accommodate future upgrading and development without the need for

building a new system to fit with the growing needs and demands of the system. Having this

system hosted online means the ability of both technicians and administrator to track and respond

to demands of clients at any time beyond the boundaries and walls of university which add one

more advantage to replacing the paper-based style.


1.1 Limitations

Time has been a limitation to this project. One semester is way too short for the

implementation of a complete comprehensive and integrated system like the HDSS.

Therefore, in the future prospects, a number of key issues have been explored to upgrade

and develop the system in the soon future.

Lack of availability of electricity and limited logistics slowed down the progress of the

implementation of the project.

Lack of expertise of team members using the adopted programming language made it

take much longer to handle unexpected problems.

6 References

http://openseminar.org/se/modules/22/index/screen.do.

7 Appendix

Appendix A: User’s Manual for the HDSS.

Appendix B: Source Code.

Appendix C: meeting reports.

http://openseminar.org/se/modules/22/index/screen.do

Documents

Srs