Help Desk Ticketing System - Requirements Specification

Help Desk Ticketing System
ThyssenKrupp Presta Steering Group USA
CIT 352 Project Final Report
Requirements Specification
December 10, 2009
André Hébert - Evan Sprague - Kyle Thompson

Help Desk Ticketing System - Requirements Specification.doc 2
Table of Contents
COMPANY HISTORY / DESCRIPTION...................................................................................................................................................6
ORGANIZATION CHART – TROY ...........................................................................................................................................................6
ORGANIZATION CHART – EXISTING IS ................................................................................................................................................7
STAKEHOLDERS....................................................................................................................................................................................8
PROJECT CHARTER...............................................................................................................................................................................8
INTERVIEW LOCATIONS AND TIMES....................................................................................................................................................9
INTERVIEWEES ......................................................................................................................................................................................9
REQUEST FOR IT PROJECT ............................................................................................................................................................... 10
INTERVIEW GUIDES............................................................................................................................................................................ 12
QUESTIONNAIRE ................................................................................................................................................................................ 16
DOCUMENTS TO BE REQUESTED...................................................................................................................................................... 18
RECORDING METHODS...................................................................................................................................................................... 18
INTERVIEW RECORD – LINDSEY SNAPP........................................................................................................................................... 19
INTERVIEW RECORD – JULIE BLOOM............................................................................................................................................... 22
COMPLETED QUESTIONNAIRES........................................................................................................................................................ 24
PROBLEM STATEMENT MATRIX........................................................................................................................................................ 34
CAUSE AND EFFECT ANALYSIS......................................................................................................................................................... 35
FUNCTIONAL REQUIREMENTS .......................................................................................................................................................... 37
NON-FUNCTIONAL REQUIREMENTS (PIECES CLASSIFICATION) ................................................................................................... 40
BUSINESS PROCESS DIAGRAM ........................................................................................................................................................ 41
SUPPORTING MATERIALS ................................................................................................................................................................. 42
BPD PROCESS DESCRIPTIONS ......................................................................................................................................................... 45
SCREENSHOTS OF EXISTING IS (VISUALHD/VHD).......................................................................................................................... 47
USE CASE GLOSSARY........................................................................................................................................................................ 53
USE CASE DIAGRAM .......................................................................................................................................................................... 54
USE CASE NARRATIVES (BUSINESS REQUIREMENTS)................................................................................................................... 55
LOGIN ........................................................................................................................................................................55
SUBMIT NEW TICKET.......................................................................................................................................................56
ASSIGN TICKET .............................................................................................................................................................57
VIEW/EDIT TICKET ..........................................................................................................................................................58
TICKET TRACKING...........................................................................................................................................................59
CLOSE/RESOLVE TICKET ..................................................................................................................................................60
INSTANT MESSAGING ......................................................................................................................................................61
E-MAIL NOTIFICATION / STATUS UPDATE...............................................................................................................................62
REPORTING ..................................................................................................................................................................63
SURVEY ......................................................................................................................................................................64
KNOWLEDGE BASE .........................................................................................................................................................65
MANAGE USERS ............................................................................................................................................................66

USE CASE LIST / EVENTS LIST.......................................................................................................................................................... 67
CONTEXT DIAGRAM ........................................................................................................................................................................... 68
MAIN FUNCTIONS DIAGRAM ............................................................................................................................................................. 69
LOWER-LEVEL DFDS .......................................................................................................................................................................... 70
1.0 – VALIDATE USER .....................................................................................................................................................70
2.0 – CREATE / UPDATE TICKET .........................................................................................................................................71
3.0 – SURVEY ..............................................................................................................................................................72
4.0 – REPORTING ..........................................................................................................................................................72
DECOMPOSITION DIAGRAM .............................................................................................................................................................. 73
EVENT DFDS ....................................................................................................................................................................................... 74
ASSIGN TICKET .............................................................................................................................................................74
CLOSE/RESOLVE TICKET ..................................................................................................................................................74
E-MAIL NOTIFICATION......................................................................................................................................................74
INSTANT MESSAGING ......................................................................................................................................................75
LOGIN ........................................................................................................................................................................75
REPORTING ..................................................................................................................................................................76
SURVEY ......................................................................................................................................................................76
TICKET TRACKING...........................................................................................................................................................77
VIEW/EDIT TICKET ..........................................................................................................................................................77
MANAGE USERS ............................................................................................................................................................78
SYSTEM DIAGRAM ............................................................................................................................................................................. 79
PRIMITIVE PROCESS FLOWCHARTS ................................................................................................................................................. 80
1.1 – QUERY USER DATABASE...........................................................................................................................................80
1.2 – COMPARE LOGIN INFO .............................................................................................................................................80
2.1 – QUERY OPEN TICKETS .............................................................................................................................................81
2.2 – DISPLAY TICKET SCREEN ..........................................................................................................................................82
2.3 – RECORD TICKET INFO ..............................................................................................................................................83
2.4 – E-MAIL NOTIFICATION .............................................................................................................................................84
2.5 – ASSIGN TICKET......................................................................................................................................................85
3.1 – SEND SURVEY.......................................................................................................................................................86
3.2 – RECORD SURVEY....................................................................................................................................................87
4.1 – QUERY KNOWLEDGE BASE AND SURVEY DATA .................................................................................................................87
4.2 – DISPLAY / PRINT REPORT..........................................................................................................................................88
5.0 – INSTANT MESSAGING...............................................................................................................................................89
6.0 – MANAGE USERS ....................................................................................................................................................90
DATA DICTIONARY / STRUCTURE..................................................................................................................................................... 91
ENTITY/DEFINITION MATRIX............................................................................................................................................................. 93
CONTEXT DATA MODEL ..................................................................................................................................................................... 94
KEY-BASED DATA MODEL ................................................................................................................................................................. 95
FULLY ATTRIBUTED DATA MODEL.................................................................................................................................................... 96

ACTIVITY DIAGRAMS (ANALYSIS)..................................................................................................................................................... 97
LOGIN ........................................................................................................................................................................97
EDIT TICKET .................................................................................................................................................................99
CLOSE TICKET.............................................................................................................................................................100
E-MAIL NOTIFICATION ...................................................................................................................................................101
REPORTING ................................................................................................................................................................102
SEQUENCE DIAGRAMS (ANALYSIS)................................................................................................................................................ 103
LOGIN: END USER ........................................................................................................................................................103
LOGIN: TECHNICIAN ......................................................................................................................................................104
LOGIN: IT MANAGEMENT ................................................................................................................................................105
SUBMIT NEW TICKET.....................................................................................................................................................106
EDIT TICKET ...............................................................................................................................................................107
CLOSE TICKET.............................................................................................................................................................108
E-MAIL NOTIFICATION ...................................................................................................................................................109
REPORTING ................................................................................................................................................................110
POTENTIAL OBJECT LIST ................................................................................................................................................................ 111
CLASS DIAGRAM (ANALYSIS) ......................................................................................................................................................... 113
USE CASE NARRATIVES (SYSTEM DESIGN)................................................................................................................................... 114
LOGIN ......................................................................................................................................................................114
ASSIGN TICKET ...........................................................................................................................................................116
VIEW/EDIT TICKET ........................................................................................................................................................117
TICKET TRACKING.........................................................................................................................................................118
CLOSE/RESOLVE TICKET ................................................................................................................................................119
INSTANT MESSAGING ....................................................................................................................................................120
E-MAIL NOTIFICATION / STATUS UPDATE.............................................................................................................................121
REPORTING ................................................................................................................................................................122
SURVEY ....................................................................................................................................................................123
KNOWLEDGE BASE .......................................................................................................................................................124
MANAGE USERS ..........................................................................................................................................................125
SEQUENCE DIAGRAMS (DESIGN).................................................................................................................................................... 126
ASSIGN TICKET ...........................................................................................................................................................126
CLOSE/RESOLVE TICKET ................................................................................................................................................127
E-MAIL NOTIFICATION / STATUS UPDATE .............................................................................................................................128
INSTANT MESSAGING ....................................................................................................................................................129
KNOWLEDGE BASE .......................................................................................................................................................130
LOGIN ......................................................................................................................................................................131
MANAGE USERS ..........................................................................................................................................................132
REPORTING ................................................................................................................................................................133
SURVEY ....................................................................................................................................................................135
TICKET TRACKING.........................................................................................................................................................136
VIEW/EDIT TICKET ........................................................................................................................................................137
CLASS STRUCTURE DIAGRAM (DESIGN)........................................................................................................................................ 138

STATE MACHINE DIAGRAMS (DESIGN) .......................................................................................................................................... 139
ADD USER .................................................................................................................................................................139
ASSIGN TICKET ...........................................................................................................................................................140
CLOSE_RESOLVE_TICKET ...............................................................................................................................................141
CLOSED_TICKET ..........................................................................................................................................................142
EMAIL ......................................................................................................................................................................143
INSTANT_MESSAGING....................................................................................................................................................144
KNOWLEDGE_BASE.......................................................................................................................................................145
LOGIN ......................................................................................................................................................................146
MANAGEMENT_REPORTING..............................................................................................................................................147
SUBMIT_NEW_TICKET....................................................................................................................................................148
SURVEY ....................................................................................................................................................................149
SURVEY_COMPLETE ......................................................................................................................................................150
SURVEY_FORM............................................................................................................................................................151
SURVEY_TIMER1..........................................................................................................................................................152
TICKET_TRACKING........................................................................................................................................................153
USER MANAGEMENT .....................................................................................................................................................154
VIEW_EDIT_TICKET.......................................................................................................................................................155
APPENDIX ......................................................................................................................................................................................... 156

Company History / Description
The ThyssenKrupp Presta Steering group of companies in the US is part of the worldwide ThyssenKrupp
Presta organization. Both entities are part of ThyssenKrupp AG, a German industrial manufacturing company.
The Presta Steering Group in the US (PSGU) is a manufacturer of steering columns and steering gears for the
US automotive industry. US manufacturing facilities are located in Terre Haute, IN, Danville, IL, and
Charleston, SC. Major customers include Ford Motor Company and Chrysler LLC.
The context of this project is in the role of IT support for the Troy, MI presence of PSGU; ThyssenKrupp
Automotive Sales and Technical Center, Inc (TKA-STC). TKA-STC is a sales and engineering office located in
Troy, MI, and serves as a liaison to the primary US customers of ThyssenKrupp Presta, based in Eschen,
Liechtenstein. It was established in the early 1980s in Detroit under the name ATI, and has since been
absorbed into Krupp (1994 – Krupp Hoesch Automotive of America), then into Thyssen (1999 –
ThyssenKrupp Automotive Sales and Technical Center), and has hence become one of several hundred
ThyssenKrupp companies in existence worldwide. TKA-STC has recently been absorbed into the PSGU group
of companies for management and shared services purposes. IT is one of those shared services. As such,
we are beginning to integrate our support structure into the larger IT group, and problems with the existing
Helpdesk system in use by PSGU are coming to light.
Organization Chart – Troy
President
C. Shetler
Administrative
Assistant
Y. Coles
Key Acc Mgr Ford
+ New Business
J. Rozell
Acc Mgr Chrysler
Upper Steering
J. Ratajski
Acc Mgr Chrysler
Lower Steering
B. Hetrick
Sales
Engineer
T. Buse
Sales
Engineer
D. West
Sales
Engineer
S. Rink
Acc Manager
L. Lindsey
Acc Manager
F. Spiess
Sales Engineering
Manager
J. Douma
Logistics
Coordinator
D. Dann
Logistics
Coordinator
D. Nowak
IT
A. Hebert
IT
J. Bloom
Controlling/IT/SAP
Manager
M. Montoya

Organization Chart – Existing IS

Stakeholders
• System Analysts – Hébert, Sprague, Thompson
• System Builders
• End Users – All company employees
• IT Department Users (Technicians, IT Management)
• System Owners – PSGU Management
• Customers (indirectly)
Project Charter
1. Project objectives:
To analyze the business processes involved in providing IT support to the end-users of the systems,
and design an effective Help Desk Ticketing System to replace the existing solution.
2. Problem Statement:
The current help desk system (VisualHD) is awkward and slow for the end-users and IT staff. It does
not lend itself to users offering a useful description of their problem, leading to IT staff needing to
contact the users for more elaboration before work can begin on a resolution. Its interconnection with
the Lotus Domino environment makes the system less familiar to use than a web-based solution.
3. Initial Functionalities:
a. End-user self-reporting of IT issues
b. Technician reporting of end-user issues
c. Technician management of ticket resolution
d. Categorization of tickets
e. Tracking of ticket history
f. End-user survey at ticket closure
g. Quality reporting based on ticket categorization and survey results
4. Business Constraints:
The business requires:
a. A means for all employees to obtain quick resolution to IT issues
b. A method for employees to communicate effectively with IT regarding the resolution of issues
c. A method for the IT manager to monitor the performance of the IT staff and the quality of the
support provided
5. Technology Constraints:
a. The system must be accessible, with reasonable access speed, to all four US locations through
the existing TCP/IP MPLS network.
b. The system must interact with the existing e-mail infrastructure, such that users’ e-mail
requests to itsupport@thyssenkrupp.com will be processed by the system, and a ticket opened
to track resolution.
c. Must function on Windows clients, with standards-compliant web browsers
d. Must be capable of being backed up using existing Symantec Backup Exec backup solution

Interview Locations and Times
Due to geographical constraints, the interviews will be conducted via telephone. Dates and times to be
determined based on interviewee availability during the interview week period.
Interviewees
Lindsey Snapp
IT Supervisor
ThyssenKrupp Presta Terre Haute LLC
1597 E. Industrial Dr., Terre Haute, IN 47802
812-299-5004
Julie Bloom
SAP/EDI Specialist
ThyssenKrupp Presta Steering Group
3155 W. Big Beaver Rd., Ste 260, Troy, MI 48084
248-275-5819

Request for IT Project

Interview Guides
Interviewee: Lindsey Snapp, IT Supervisor, ThyssenKrupp Presta Terre Haute
Date: 5-Oct-2009
Time: 17:30
Location: Telephone
Subject: Help Desk Ticketing System
Time Allocated Interviewer Question or Objective Interviewee Response
5 to 10 min Objective
Open the interview:
Introduce ourselves.
Thank Interviewees for their valuable time.
State the purpose of the interview--to obtain an
understanding of the existing help desk ticketing system
5 min Question 1
Please describe the current process for an end user to
request support from IT, or report a problem?
Follow-up
5 min Question 2
What are the shortcomings of the current process?
Follow-up
5 min Question 3
What are end-user complaints about the current system?
Follow-up
5 min Question 4
What are IT department user complaints about the current
system?
Follow-up
5 min Question 5
Imagine the ideal situation-- Can you describe the support
process "as it should be"?
Follow-up
5 min Question 6
How can the system be improved to encourage getting more
detail and more accurate information in an end-user request?
Follow-up
5 min Question 7
How should the new system facilitate communication
between IT and the end-users?
Follow-up
Question 8
5 min What are your reporting requirements?
Follow-up
5 min Question 9
Is the end-user survey adequate, or should it be improved?
Follow-up

5 min Question 10
What are your survey reporting requirements?
Follow-up
5 min Question 11
What data is stored within a help desk ticket, and in user
records?
Follow-up
5 min Question 12
What other systems does the help desk ticketing system need
to interface with?
Follow-up
5 min Objective
Conclude the interview:
Thank Interviewee's and assure them they will be receiving a
copy of what transpired during the interview
50 minutes Time allotted for questions and objectives
10 minutes Time allotted for follow-up questions and redirection
60 minutes Time allotted for interview
General Comments and Notes:

Interviewee: Julie Bloom, SAP/EDI Specialist, ThyssenKrupp Presta Steering Group
Date: 2-Oct-2009
Time: 10:00
Location: Telephone
Subject: Help Desk Ticketing System
Time Allocated Interviewer Question or Objective Interviewee Response
5 to 10 min Objective
Open the interview:
Introduce ourselves.
Thank Interviewees for their valuable time.
State the purpose of the interview--to obtain an
understanding of the existing help desk ticketing system
5 min Question 1
Please describe the current process for an end user to
request support from IT, or report a problem?
Follow-up
5 min Question 2
Follow-up
5 min Question 3
Follow-up
5 min Question 4
What are your complaints about the current system as a
technician-user?
Follow-up
5 min Question 5
Imagine the ideal situation-- Can you describe the support
process "as it should be"?
Follow-up
5 min Question 6
How can the system be improved to encourage getting more
detail and more accurrate information in an end-user
request?
Follow-up
5 min Question 7
How should the new system facilitate communication
between IT and the end-users?
Follow-up

5 min Objective
Conclude the interview:
Thank Interviewee's and assure them they will be receiving a
copy of what transpired during the interview
50 minutes Time alloted for questions and objectives
10 minutes Time alloted for follow-up questions and redirection
60 minutes Time allotted for interview
General Comments and Notes:

Questionnaire

Documents to be Requested
• Screenshots of current system
o Forms used by end-users
o Forms used by IT staff
o Reports
o Survey data sample
• Manuals from current system
Recording Methods
• Audio recording pending technical solution
• Written recording otherwise

Interview Record – Lindsey Snapp
Lindsey Snapp, IT Supervisor, ThyssenKrupp Presta Steering Group
Interview: October 5th , 2009
Conference call via Skype, 5:30 p.m.
Recorded using Pamela for Skype
Interviewee Response
Question 1
Please describe the current process for an end user to request support from IT, or report a problem?
End-users are required to submit a help-desk ticket via VHD. Users select a category from a drop down
menu, enter a short description and hit submit to submit the request. One submitted it goes into a holding
queue, meaning the ticket doesn’t get assigned to a particular individual in particular. The reason being is
because they have both IT infrastructure issues and SAP related issues. One in the holding queue a person in
IT looks at that particular ticket and determines who it gets assigned to. Once assigned to that individual that
person receives an email stating they have been assigned to a ticket.
Question 2
When an end-user submits a ticket there is almost a guarantee that the IT department will need to follow up
with the customer about a particular issue. They may be followed up with phone, or email. Often times when
an end-user submits a ticket they select the first category in the drop down menu that doesn’t fit their problem
at all. Also many times the users don’t know how to read and follow up on a ticket that has been submitted.
Lindsey wishes the ticketing system would be more robust. By that the ticketing system should tell a user
they ticket has been updated, that would include the text inputted by the technician in the actual email itself,
along with a link to the ticket to along the end-user to follow along with the status. Mostly more advanced
users submit screenshots which helps solve a problem more efficiently.
Question 3
Depending on the location, many users don’t know how to follow up on a ticket they submitted. They either
don’t know how to click on a link, or it just says your helpdesk ticket has been updated. There is nothing that
says here’s an updated status with the technician’s response within the email and so forth.
Question 4
What are your complaints about the current system as a technician-user?
One of Lindsey’s complaints about the system is the ease of use of adding a solution to a knowledge base.
For example once a ticket has been resolved, it doesn’t say would like to add this to the knowledge base. You
have to manually go in and say add this ticket to the knowledge base. If that was fixed it would have to go
through multiple technicians so they understand what was going on and they don’t receive duplicates.

Question 5
Imagine the ideal situation-- Can you describe the support process "as it should be"?
Once a user enters a keyword or a category from the drop down list, it would query for all older tickets that
may be relevant to the end-users problem. Ideally if you have a user that continually inputs tickets it would
help determine if it is a hardware or software problem or if it’s an issue with that particular user.
Currently there is lots of manual setup. Ideally it should be easy to use for the end-user. Either it be web-
based or Lotus Notes it must be easy to get to. Users would then type in their problem and it would go out
and search for that issue and potentially give them a solution. Another great solution would be to eliminate
the “holding queue”, whereas when the ticket selects a category from the drop down list it would get assigned
to a particular individual. As of right now a ticket can be within the holding queue for several hours until it gets
assigned to a particular individual.
Question 6
How can the system be improved to encourage getting more detail and more accurate information in an end-
user request?
The system could scan the device that they are putting the request in from and gather as much information as
they can. When the user submits their request they know what they are submitting from (laptop, desktop), it
would gather their serial number, hard drive size, memory size and so forth. It would help the helpdesk
problem mate the issue along with inventory. For example if it’s a shared device the user is using and you
have no tickets from other issues from end-users it could help determine it is probably a user issue.
Question 7
How should the new system facilitate communication between IT and the end-users?
From a communicating perspective a ticket could notify the end-user has been assigned to Lindsey Snapp for
example. The user could then be more assured it is getting worked on by knowing who exactly is working on
it if they wanted to follow up with the issue. End-users must be more specific with their problems. Possibly
having multiple sub categories, and have intelligence behind it to know which technicians are available and
balance it that way.
Question 8
What are your reporting requirements?
Reports are generated at the end of the month. Currently reports generate Technicians, Average Time to
close a ticket. A separate report is sometimes created showing rather the problem was hardware or software
related. One thing that isn’t currently being generated is location which is being requested. Currently it would
have to be done manually, and it takes hours to complete.
Another requirement would to have grouping of tickets closed by a certain technician, along with an average
time for each. For example it would read average time for Lindsey to close a ticket is 18 min. Another good
statistic would be for instance, Kyle closed 20 tickets, 15 were from Evan. All of this is currently being done
manually. Having reporting done by location and by department could work.

Question 9
Is the end-user survey adequate, or should it be improved?
Not currently getting enough responses from surveys. 40% complete rate is currently possible solution is to
say after 3 failed attempts of filling out a survey not allowing an end-user fill out a helpdesk request until
previous surveys are completed. Having a survey tied to a user id or username to determine if a user
completed a survey within a certain time frame and that could even be up to two weeks.
A solution may be to possibly having to complete surveys on a calendar basis like Julie suggested and give a
response in more of a general sense rather than having to remember a specific issue. Also a request would
be to have the survey stand out more so it doesn’t tend to get buried in your inbox, and possible confirmation
upon deletion.
Question 10
What are your survey reporting requirements?
Reports currently being done are two parts being tied into one. One part is a technician side stating number
of tickets closed as a group and then it is broken down per technician. Manual configuration of average time
to close has to be done on the report. Other part is end-user request and how many surveys they are getting
from end-users. Average score for each technician would be nice. For instance User A’s average score was
3.7, so you could spot users that are trying to shoot down IT. Also reporting should be done on monthly basis
rather than lifetime within VHD.
Question 11
What data is stored within a help desk ticket, and in user records?
A help desk ticket includes a problem category, and a text description of the problem from the end-user who
submits the ticket. Technicians working on the ticket later can add ticket update text. The ticket also includes
the name and contact info of the end user who submitted it, as well as the technician’s name and contact info.
Ideally, tickets should contain copies of all communications between the end-user and the tech.
Question 12
What other systems does the help desk ticketing system need to interface with?
All updates to tickets need to be e-mailed to the technician and end-user involved; so a connection to our
SMTP email server is needed.

Interview Record – Julie Bloom
Julie Bloom, SAP/EDI Specialist, ThyssenKrupp Presta Steering Group
Interview: October 2nd, 2009
Conference call via Skype, 10:00 a.m.
Recorded using Pamela for Skype
Interviewee Response
Question 1
Please describe the current process for an end user to request support from IT, or report a problem?
They have to open a ticket, expressing what their problem is. End-users are able to submit screen shots by
attaching them to the ticket. The ticket then needs to be assigned by Lindsey Snapp, and Julie would receive
notification that the ticket has been assigned to herself.
Question 2
• Not being able to capture enough detail in the call while interacting with the end-users. Process is
extremely slow and things outside of the system are not currently being tracked. Most work is not
documented within VHD for its slow process.
• Communication lacks within VHD which almost always requires more detail from the end-user. Would
like to be able to use IM functionality that is built into Lotus notes which is not currently being used
would help make the process of opening up a ticket more interactive, so that you have an extra person
listing the extra information. Ticket doesn’t ask the end-user who to assign it to. The IT manager is
then responsible to decide whom it gets assigned to. Categorization should be incorporated with the
assigning of a ticket.
• Specific departments need to be informed of a ticket being assigned to them. Currently they have to
check multiple times a day. Someone is responsible for checking if end-user requests are within the
system. Non-functional requirement that needs to be addressed is it usually takes 2 minutes for VHD
to respond. Could potentially find another commercial product which would work better.
• End-users typically bypass the ticketing system by just placing a call or sending out an e-mail which
happens about 50% of the time and it is not being tracked. This typically happens when something
very small needs to occur, such as a password reset. With that being done, helpdesk has to go back
and manually put in a ticket. Users would like an instant response time when using ticket system.
Requirement would be to have a means of opening a quick ticket for a small issue that would be very
easy for and end-user to do. The ideal situation would have it as easy for the end-user to click the
helpdesk button as it would be to just place a call.
Question 3
Isn’t aware of any shortcoming other than issues listed as above

Question 4
What are your complaints about the current system as a technician-user?
• Opening the VHD program takes a long time to load, approximately 30 seconds. You could typically
send a user an email quicker to report a problem.
Question 5
Imagine the ideal situation-- Can you describe the support process "as it should be"?
• System has to be as simple if not simpler than picking up the phone, walking into somebody’s office or
sending the department an email. If something is not done to fix the problem, the three methods
listed above will be used first, unless the department states they won’t fix their issue unless they
create a ticket. In that case it would really upset the end-user. The users don’t understand that the
help desk ticketing system is used as a tracking mechanism; they just view it as something that is
going to slow the process.
• The ideal situation is to have the end-user be familiar with the system without having to think about it.
At this point with technology it would have to be web-based. With a web-based solution wouldn’t want
it to require a separate login. It would reside on an internal web-page. Within this the user would type
a quick description, and provide a screenshot and presses GO which in essence would be the entire
process of opening a ticket.
Question 6
How can the system be improved to encourage getting more detail and more accurate information in an end-
user request?
Refer to question 2
Question 7
How should the new system facilitate communication between IT and the end-users?
• Possibly open an IM session with the end-user and have that be recorded within the ticket. Also
having e-mails back-and-forth be recorded into the ticket would be ideal. Outside of the work
environment it could be done with Google. Right now specific people within those departments use
texting whereas an IM service could be done much cheaper.
Comments about survey process
When a ticket is closed, the end-user receives notification they have the option to fill out a survey, and they
get a standard list of questions along with a comment box. Recently filled out survey and it went nowhere,
specifically not linked to the appropriate people. Julie would like a survey sent on timely intervals, not every
time a ticket is closed, most of the time they get deleted because she is busy. It would be more adequate if
she received one say once a month saying “please spend ten minutes of your time to provide us with your
overall response.” Guessing most users don’t fill out survey and feels as if they would receive them
periodically they would receive more honest feedback.

Completed Questionnaires

Problem Statement Matrix
PROJECT: Help Desk Ticketing System PROJECT MANAGER: Mike Wu
CREATED BY: Team #8 LAST UPDATED BY: André Hébert
DATE CREATED: 7-Oct-2009 DATE LAST UPDATED: 8-Oct-2009
Brief Statements of Problem,
Opportunity, or Directive
Urgency Visibility Annual Benefits Priority
or Rank
Proposed Solution
1. New tickets go into a holding
queue, and have to be
assigned to technicians
manually.
Immediate High $100,000. 1 New development
2. Users are not submitting
enough detail in new tickets for
technicians to work from.
4 months Low $25,000 2 New development
3. Users are unaware of how to
access help desk system.
Immediate High $25,000 1 New development
and user education
4. Retrieving information from
past tickets is difficult.
8 months Med $75,000 2 New development
5. Reporting involves a lot of
manual processing due to
limitations in current system.
12 months High $200,000 2 New development
6. Process for end users to open
a new ticket is difficult and
awkward – users often bypass
the help desk system
completely.
7. VHD system is extremely slow,
particularly from WAN-linked
locations.
8. Communication between IT
and end users is not logged.
9. Survey participation rate is
very low.
10. No provision for instant
messaging currently exists.

Cause and Effect Analysis
Project: Help Desk Ticketing System Project Manager: Mike Wu
Created by: Team #8 Last Updated by: André Hébert
Date Created: 7-Oct-2009 Date Last Updated: 8-Oct-2009
CAUSE AND EFFECT ANALYSIS SYSTEM IMPROVEMENT OBJECTIVES
Problem or Opportunity Causes and Effects System Objective System Constraint
1. New tickets go into a
holding queue, and have
to be assigned to
technicians manually.
1. Increased time between user
submission of ticket and
beginning of technician’s work
on the issue.
2. Increased workload for IT
management, who manually
assigns tickets.
1. Automatic
assignment of tickets
based on category
chosen by user, and
technician skill set.
1.
2. Users are not
submitting enough detail
in new tickets for
technicians to work from.
1. Time to resolve ticket is
increased, due to increased
technician time used to clarify
issue with end user.
2. System does not encourage
users to submit adequate
information.
1. System to assist user
in attaching
screenshot of issue.
2. System to encourage
users to submit an
adequate amount of
detail.
1.
3. Users are unaware of
how to access help desk
system.
1. Users bypass help desk
system by walking to IT
department, or calling in an
issue
2. Increased IT department time
for resolution, duplication of
effort.
1. System access
should be extremely
easy – as easy as
picking up the phone
or walking to IT.
1.
4. Retrieving information
from past tickets is
difficult.
1. Duplication of effort –
technicians not aware if
problem has been addressed
in the past.
2. Longer time to resolution.
1. Upon opening a
ticket, a technician
should see an
automatic search of
all past tickets based
on keywords entered.
1.
5. Reporting involves a
lot of manual processing
due to limitations in
current system.
1. IT management spends large
amounts of time compiling
reports every month.
2. Less flexibility than desired in
reporting.
1. Reporting capabilities
to be enhanced as
detailed in functional
requirements.
1.
6. Process for end users
to open a new ticket is
difficult and awkward –
users often bypass the
help desk system
completely.
1. Users bypass help desk
system by walking to IT
department, or calling in an
issue.
2. Increased IT department time
for resolution, duplication of
effort.
1. Process for opening a
new ticket should be
quick and easy; SSO
login, quick ticket
process, screenshot
assistance.
1.
7. VHD system is
extremely slow,
particularly from WAN-
linked locations.
1. Users in WAN-linked locations
are very discouraged from
using help desk system.
2. Technicians in WAN-linked
locations are reluctant to use
help desk system.
1. Server-side
processing inherent
in web-based
applications, with
minimal network
traffic to client.
1.

8. Communication
between IT and end
users is not logged.
1. Difficult to retrace problem-
solving steps.
2. Difficult for a second
technician to take over a ticket
if needed.
1. E-mail and IM
facilities built into
system will be logged
in ticket
automatically.
1.
9. Survey participation
rate is very low.
1. Department performance
metrics are potentially skewed.
1. Capability to set
survey frequency
2. Capability to limit
users’ ability to
submit new tickets
based on non-
participation in
surveys.
1.
10. No provision for
instant messaging
currently exists.
1. User interaction limited to
telephone and email.
1. Instant messaging
system to be built
into ticketing system.
1.

Functional Requirements
1. General
1.1. System must be web-based.
2. Login
2.1. No login should be required beyond existing Windows login (SSO).
2.1.1. Interface to Active Directory required.
3. Submitting a help desk ticket
3.1. Simple/Routine Issues
3.1.1. Need a simplified ticket opening method for simple issues.
3.2. Complex Issues
3.2.1. Must allow free-form description of problem.
3.2.1.1. Must request detailed information from end user.
3.2.2. Must provide categories for user to select.
3.2.3. Must automatically capture and attach screenshot of the problem, assisting the user in doing
so.
4. Ticket assignment (triage)
4.1. Must be automatic based on category chosen by end-user and technician skill set.
4.2. Must distribute tickets evenly between technicians with same skill set.
4.2.1. This should be done in a round-robin distribution.
4.3. Manual reassignment must be possible, by any technician or manager.
5. Technician – View/Edit Ticket
5.1. All details of ticket entered by end user must be viewable by technician within application.
5.2. Technician must be able to edit any information in ticket to correct assumptions or incorrect
information given by end user.
6. Communications
6.1. E-Mail
6.1.1. System must allow direct e-mail communication between technician and end-user, and log all
e-mail contact in the ticket.
6.2. Telephone
6.2.1. System must allow technician to document telephone contact with end user.
6.3. Instant Messaging
6.3.1. System must allow instant messaging between technician and end-user, and log all such IM
contact in the ticket.

7. End user tracking of issue resolution
7.1. End user must be able to:
7.1.1. See original ticket submission.
7.1.2. Update ticket with new information.
7.1.3. Indicate that issue is resolved and ticket should be closed.
8. Status updates
8.1. System must automatically e-mail the end user and the technician when there is any change or
update to the ticket.
8.2. E-mail messages send by the system should include a link to access/view/update the ticket, directly in
the e-mail.
9. Ticket closure/resolution
9.1. Ticket closure can be initiated by technician or end user.
9.2. If end user initiates, technician must document resolution and confirm closure before ticket is closed.
9.3. If technician initiates, must document resolution before ticket is closed.
9.4. Technician and end user must be notified of closure via e-mail.
10. Knowledge Base
10.1. All tickets must become part of the knowledge base once the ticket is closed.
10.2. Upon receiving a new ticket, a technician’s view of the ticket should automatically include past
tickets with keyword matches to the current one to aid in problem resolution.
11. Survey
11.1. Current 5-question survey is adequate
11.2. Maintain free-form comments section
11.3. Add ability to set frequency of survey requests to end user by time period
11.4. Add ability to block end user’s ability to submit new tickets if a predefined number of surveys have
been left unanswered.

12. Reporting
12.1. General
12.1.1.All reporting should be on a monthly basis.
12.2. Performance
12.2.1.Average time to close ticket per technician
12.2.1.1. By location of end user
12.2.1.2. By issue category (hardware/software)
12.2.1.3. By end user department
12.3. Survey
12.3.1.Report survey scores (1-5)
12.3.1.1. By technician
12.3.1.2. By end user
12.3.1.4. By end user location
12.3.2.Report survey participation level
12.3.2.1. By technician
12.3.2.2. By end user
12.3.2.4. By end user location

Non-Functional Requirements (PIECES Classification)
Nonfunctional
Requirement Type
Requirement(s)
Performance • System must react instantaneously when user’s ticket is opened or status is
changed.
• Opening ticketing system must be instantaneous, even across slower WAN
connections.
Information • System must encourage user to provide sufficient detail through an attractive
design and carefully-chosen wording.
• Communication to end-user via e-mail should be consistent, include link to
view/update ticket, and be logged in the ticket.
Economy • System efficiency should translate to IT department efficiency, thereby
increasing throughput and profit.
• Project shall not exceed allocated budget.
Control & Security • End users should have access only to their own tickets
• Technicians should have access to modify tickets, but not to remove.
Efficiency • Tracking of end user request must be easy and efficient for technicians.
• Tracking progress of tickets should be easy for users.
• Submitting a new ticket should be quick and easy.
• Link/icon to launch help desk system should be easy to find.
Service • System as a whole must be simple and easy to understand for end user
• System should be web-based.

Business Process Diagram

Supporting Materials
BPD Documents & Forms
Submit New Ticket
E-mail to IT for Assistance

Assigned Helpdesk Ticket
E-mail / Phone Communication

Ticket Resolution
Survey Form

BPD Process Descriptions
Business Process Description
Process Name Check for new tickets
Executive Steps & Rules 1. Query existing IS for newly-submitted tickets from end-users
2. Review list to be assigned to technicians
Data Input / From New tickets from end users or technicians
Data Output / To New tickets to Assign Tickets to Technicians process
Constraints At least one new ticket must have been created.
Process Name Assign Tickets to Technicians
Executive Steps & Rules 1. Review list of tickets from previous process
2. Open each ticket and review contents
3. Based on problem description, assign ticket to a technician with the proper
skill set
***Note: This is currently a manual process. System will have a category
assigned to ticket, system will automatically assign to a technician based
on category.
Data Input / From List of tickets from Check for new tickets process.
Data Output / To Assigned ticket to technician
Constraints None.
Process Name Problem-Solving / Troubleshooting Process
Executive Steps & Rules 1. This illustrates the collaborative process followed by an IT technician and
end-user as they work to resolve a problem. Communication here can be
via phone, e-mail, instant messaging, or in person.
Data Input / From Ticket Data from IT Management’s Assignment of original ticket from End-
User.
Data Output / To Communication between end-user and technician, and resolution, to the Close
Ticket / Document Resolution process.
Constraints None.

Process Name Close Ticket and Document Resolution
Executive Steps & Rules 1. Technician reviews the ticket data and records of communications relating
to the ticket.
2. Technician makes determination that the issue is resolved.
3. Technician documents the resolution of the issue in the ticket.
4. Ticket is moved to “Closed” state.
Data Input / From Problem solving details from Problem solving process.
Data Output / To Survey Form to End User
Ticket Resolution to Reporting Process
Constraints None.
Process Name Reporting Process
Executive Steps & Rules 1. Query database of closed tickets
2. Query database of Completed Survey Forms
3. Compile data in Excel
4. Analyze data in Excel
***Note: This describes the current business process. The system will
automate this process and allow the production of a report based on
criteria.
Data Input / From Ticket Resolution and Completed Survey Form
Data Output / To Report to IT Management
Constraints At least one ticket resolution (and optionally a survey form) must be complete.

Screenshots of Existing IS (VisualHD/VHD)
Welcome Screen

New Ticket Screen
Category Selection Screen

Category Selection Screen 2
Description Entry Screen

Technician Main Screen
Technician Ticket View 1

Technician Ticket History View

Use Case Glossary
Use-Case Glossary
Use-Case Name Use-Case Description
Participating
Actors and Roles
Login This use case describes the event of a user
authenticating with the help desk system.
End User
Technician
IT Management
Submit New Ticket This use case describes the event of an end user
creating a new help desk ticket.
End User
Assign Ticket This use case describes the automated event of
assigning a ticket to an appropriate technician,
based on the category chosen in the “Submit New
Ticket” use case.
View/Edit Ticket This use case describes the event of a technician or
IT management viewing an existing ticket with the
ability to edit its contents.
Technician
IT Management
Ticket Tracking This use case describes the event of an end user
viewing his/her own ticket to track its resolution
status. Only additions can be made in this mode,
no edits.
End User
Close/Resolve Ticket This use case describes the event of a technician
closing an existing ticket and entering resolution
details into the ticket record.
Technician
Instant Messaging This use case describes the event of an instant
messaging conversation between a technician and a
user.
End User
Technician
E-mail Notification /
Status Update
This use case describes the event of the system
notifying both the technician and user concerned of
a change in the assignment, contents or status of
an existing ticket. Notification is sent via e-mail.
Reporting This use case describes the event of periodic
reporting on ticket activity and survey results by IT
management.
IT Management
Survey This use case describes the event of a survey being
sent to an end user by the system. Surveys are
sent based on past ticket activity linked to the user,
and depend on a timing variable.
End User
Knowledge Base This use case describes the event of interacting with
the database of closed help desk tickets. The
Close/Resolve Ticket use case adds the newly-
closed ticket to the knowledge base. The View/Edit
Ticket use case queries the knowledge base for
tickets similar to the one being viewed.
Manage Users This use case describes the event of
adding/editing/removing users from the ticketing
system.
IT Management

Use Case Diagram

Use Case Narratives (Business Requirements)
Author:__Team #8 Date:__13-Oct-2009_
Use-Case Name: Login
Use-Case ID: HDTS-001
Priority: High
Source: Functional Requirement Document
Use Case Type
Business Requirements
Primary System Actor: End User, Technician, IT Management
Primary Business Actor: End User, Technician
Other Participating
Actors:
End User, Technician, IT Management
Other Interested
Stakeholders:
Description: This use case describes the event of a user authenticating with the help desk system.
Precondition: User must have browser open to login screen
Trigger: Typing in username and password followed by pressing a login button
Typical Course Of
Events:
Actor Action System Response
Step 1: User types in their user name and
password
Step 3: System confirms that user name is in the
system
Step 2: User Presses Login button Step 4: System confirms users password
Step 5: browser redirects user to help desk system
Alternate Courses: Alt-Step 3: System is unable to confirm that the user name is in the system
Alt-Step 4: System is unable to confirm user password
Alt-Step 5: User us sent an error message stating the inaccuracy of user name or password
Conclusion: User logs into help desk system
Postcondition: Browser now displays the help desk system
Business Rules:
Implementation
Constraints and
Specifications:
The browser may display a different set of GUI for the help desk system based on whether the
users login is associated with a End User, Technician or IT management after login.
Assumptions:
Open Issues: 1. Need to determine how forgot password for login is handled

Use-Case Name: Submit New Ticket
Priority: High
Use Case Type
Primary Business Actor: End User
Other Participating
Actors:
End User, Technician
Other Interested
Stakeholders:
IT Management
Description: This use case describes the event of an end user creating a new help desk ticket.
Precondition: User must be logged in
Trigger: User presses submit after filling out the ticket information
Typical Course Of
Events:
Step 1: User selects a category from a
dropdown menu, that best describes the
classification of the issue they are
experiencing
Step 4: System automatically designates an unique
key ID number to the submitted ticket
Step 2: User types a description of the
issue they are experiencing in the
designated field
Step 5: Ticket information is sent to the Assign
Ticket system (Separate Use Case)
Step 3: User presses a submit button Step 6: All information is saved in database
Alternate Courses: User uses other means to submit ticket
Conclusion: User submits a ticket though the standard means
Postcondition: The ticket has been recorded and sent to the Assign Ticket system (Separate Use Case)
Business Rules: The description field must allow for a large amount of characters for detailed descriptions
Implementation
Constraints and
Specifications:
• Each internal key ID must be unique
• User must provide a category and description
Assumptions:
Open Issues: 1. Are sub categories necessary to better narrow down the type of issue the user is
experiencing

Use-Case Name: Assign Ticket
Priority: High
Use Case Type
Primary System Actor:
Primary Business Actor:
Other Participating
Actors:
Technician, IT Management
Other Interested
Stakeholders:
Technician, End User
Description: This use case describes the automated event of assigning a ticket to an appropriate technician,
based on the category chosen in the “Submit New Ticket” use case.
Precondition: User has filled out and submitted a ticket, including selecting a category
Trigger: User presses Submit button after filling out ticket information
Typical Course Of
Events:
Step 1: User submits new ticket (Separate
Use Case)
Step 2: System associates the category the user
selected with the assigned technician for that
category
Step 3: Save information to database
Step 4: Pass all submitted information to E-mail
Notification / Status Update system (Separate Use
Case)
Alternate Courses: Alt-Step 2: Ticket is manually changed by a Technician or IT Management to a better suited
Technician
Conclusion: Ticket is assigned to a technician based on information provided by user
Postcondition: The ticket now has a designated Technician and has been passed to the E-mail Notification /
Status Update system (Separate Use Case)
Business Rules:
Implementation
Constraints and
Specifications:
After ticket has been assigned, the assigned technician can be changed by the originally assigned
technician or IT management
Assumptions:
Open Issues: 1. How system is affected if subcategories are used
2. Does system scan description text for key words to better assign ticket

Use-Case Name: View/Edit Ticket
Priority: High
Use Case Type
Primary System Actor: Technician, IT Management
Other Participating
Actors:
Other Interested
Stakeholders:
End User
Description: This use case describes the event of a technician or IT management viewing an existing ticket with
the ability to edit its contents.
Precondition: Ticket has been created, and assigned a technician
Trigger: Technician opens an existing ticket
Typical Course Of
Events:
Step 1: Technician selects an existing
ticket
Step 2: System retrieves all information associated
with the ticket from the database
Step 4: Technician adds to or edits ticket Step 3: System populates display with retrieved
information
Step 5: System updates saved information in
database
Alternate Courses:
Conclusion: Ticket information is displayed on screen, and changed if necessary
Postcondition: All added and edited information is saved to the database
Business Rules:
Implementation
Constraints and
Specifications:
Assumptions:
Open Issues:

Use-Case Name: Ticket Tracking
Priority: High
Use Case Type
Primary System Actor: End User
Other Participating
Actors:
Other Interested
Stakeholders:
Description: This use case describes the event of an end user viewing his/her own ticket to track its resolution
status. Only additions can be made in this mode, no edits.
Precondition: The end-user must have a ticket submitted within Help Desk Ticketing System.
Trigger: This use case is initiated when a ticket is submitted to the internal Help Desk ticketing system
Typical Course Of
Events:
Step 1: The end-user is able to view
current assignees to their individual ticket
along with the ability to add additional
information if needed.
Step 3: The end-user is able to click the
link provided in the email, which allows the
user to make changes to the ticket if they
choose to do so.
Step 2: The system responds by sending a
confirmation email to the end-user stating the ticket
has been updated if more information was added
along with the information the end-user supplied
within the ticket. E-mail messages sent by the
system should include a link to access/view/update
the ticket, directly in the e-mail.
Alternate Courses:
Conclusion: This use case concludes when the status of a end-user ticket has been updated.
Postcondition: The ticket has been updated and ready for immediate viewing by both technicians and end-users.
Business Rules:
Implementation
Constraints and
Specifications:
• Ability to track via web interface or through email for portability.
Assumptions:
Open Issues:

Use-Case Name: Close/Resolve Ticket
Priority: High
Use Case Type
Primary System Actor: Technician
Other Participating
Actors:
End-User
Other Interested
Stakeholders:
Description: This use case describes the event of a technician closing an existing ticket and entering resolution
details into the ticket record.
Precondition: The ticket has been submitted into the Help Desk Ticketing system and currently assigned to a
technician.
Trigger: This use case is initiated when a technician comes upon a resolution for the end user’s issue or an
end-user requests individual ticket to be closed.
Typical Course Of
Events:
Step 1: Ticket Closure can be initiated by
either a technician or requested by end-
user.
Step 2: If end-user initiates, technician
must document resolution and confirm
closure before ticket is closed
Step 3: If technician initiates must update
resolution before ticket is closed
Step 4: System responds by updating both current
assignees and end-user of a resolution and closure
via email. Email contains reported communications
between end-user and technician for future
reference.
Alternate Courses:
Conclusion: The use case concludes when the end-users ticket has successfully been resolved.
Postcondition: The ticket has been marked as resolved within the Helpdesk ticketing system, and could be
reopened by the end-user which would initiate the use case again. Otherwise ticket is successfully
resolved and end-user is satisfied with resolution.
Business Rules:
Implementation
Constraints and
Specifications:
Assumptions:
Open Issues:

Use-Case Name: Instant Messaging
Priority: High
Use Case Type
Primary System Actor: Technician
Other Participating
Actors:
End-user
Other Interested
Stakeholders:
Description: This use case describes the event of an instant messaging conversation between a technician and
an end-user.
Precondition: A ticket must be entered into the Help Desk ticketing system by an end-user.
Trigger:
Typical Course Of
Events:
Step 1: Instant Messaging communication
must be initiated by a technician to an
end-user to retrieve more information
about the issue
Step 2: System must log all IM conversations and
log conversation within the original ticket. Email
notification must be sent to end-user and technician
for records.
Alternate Courses:
Conclusion: The use case concludes when the technician has received enough information about the current
issue from the end-user.
Postcondition: The end-users ticket is updated with communication records between the end-user and the
technician.
Business Rules:
Implementation
Constraints and
Specifications:
• All PC’s must be equipped with Instant Messaging Client software
Assumptions: Both end-user and technicians have IM client service available to them.
Open Issues: What Instant Messaging Client’s are easiest for both parties?

Use-Case Name: E-Mail Notification / Status Update
Priority: High
Use Case Type
Primary System Actor:
Other Participating
Actors:
End User, Technician
Other Interested
Stakeholders:
IT Management
Description: This use case describes the event of the system notifying both the technician and user concerned
of a change in the assignment, contents or status of an existing ticket. Notification is sent via e-
mail.
Precondition: N/A
Trigger: This use case is initiated when an existing ticket is assigned to a technician, edited/updated, or
closed.
Typical Course Of
Events:
Step 1: An existing ticket is modified by
being assigned to a technician, edited by
the technician, or closed by the technician.
Step 2: The system responds by sending an e-mail
notification to both the technician assigned to the
ticket and to the end user to whom the ticket
belongs, containing the text added or edited in the
ticket, or a notification of assignment, or a
notification of the ticket’s closure.
Alternate Courses: None.
Conclusion: This use case concludes when the e-mail notification is sent successfully.
Postcondition: N/A
Business Rules: None.
Implementation
Constraints and
Specifications:
Interface to e-mail system must be SMTP to allow for future e-mail infrastructure changes without
effect.
Assumptions: None.
Open Issues: None.

Use-Case Name: Reporting
Priority: High
Use Case Type
Primary System Actor: IT Management
Primary Business Actor: IT Management
Other Participating
Actors:
None
Other Interested
Stakeholders:
Corporate Management
Description: This use case describes the event of periodic reporting on ticket activity and survey results by IT
management.
Precondition: At least one ticket must have been closed, and at least one survey response must have been
completed.
Trigger: IT Management triggers this use case through the user interface.
Typical Course Of
Events:
Step 1: This use case is initiated when the
IT Management user selects the option to
run reports.
Step 2: The system responds by offering choices to
run reports on survey data and/or ticket data, by a
specified timeframe and end user
location/department criteria to be specified by the
user.
Step 3: IT Management selects reporting
criteria as needed.
Step 4: System queries database and produces
report as requested.
Conclusion: This use case concludes when the management user’s report is complete and displayed.
Postcondition:
Business Rules:
Implementation
Constraints and
Specifications:
Reporting parameters to be specified by the management user:
• Timeframe to be reported
• Survey Data:
o By Technician
o By End User
o By Department
o By End User Location
• Ticket Data:
o By Technician
o By End User
o By Department
o By End User Location
Assumptions: None
Open Issues: Exactly what parts of ticket data should be queried?

Use-Case Name: Survey
Priority: High
Use Case Type
Primary System Actor: Time, End User
Primary Business Actor: End User
Other Participating
Actors:
Other Interested
Stakeholders:
IT Management
Description: This use case describes the event of a survey being sent to an end user by the system. Surveys
are sent based on past ticket activity linked to the user, and depend on a timing variable.
Precondition: Associated ticket must be closed, and system timer must trigger survey.
Trigger: Closed state of ticket, and time as defined by administrator.
Typical Course Of
Events:
Step 1: An existing ticket is closed (see
Close/Resolve Ticket use case).
Step 2: System sends survey to the end user via a
link sent in an e-mail.
Step 3: End User receives survey and
completes survey questions.
Step 4: Survey responses are logged to database.
Alternate Courses: Alt. Step 2: Rule may be set to restrict number of surveys per number of tickets closed, or per
period of time. If rule blocks sending survey, process stops here.
Conclusion: This use case concludes when the end user clicks Submit button on survey form.
Postcondition: Survey complete.
Business Rules: Users may be required to complete surveys by company policy.
Implementation
Constraints and
Specifications:
Interface to e-mail system must be SMTP to allow for future e-mail infrastructure changes without
effect.
Assumptions: None
Open Issues:

Use-Case Name: Knowledge Base
Priority: High
Use Case Type
Primary System Actor: Close/Resolve Ticket Use Case, View/Edit Ticket Use Case
Primary Business Actor: None
Other Participating
Actors:
Technician
Other Interested
Stakeholders:
IT Management
Description: This use case describes the event of interacting with the database of closed help desk tickets. The
Close/Resolve Ticket use case adds the newly-closed ticket to the knowledge base. The View/Edit
Ticket use case queries the knowledge base for tickets similar to the one being viewed.
Precondition: At least one ticket must reach the Close/Resolve Ticket use case.
Trigger: This use case is initiated by other use cases: The Close/Resolve Ticket use case saved all of the
details of the closed ticket to the knowledge base for future reference. The View/Edit Ticket use
case queries the knowledge base for closed tickets that are similar to the one being viewed.
Typical Course Of
Events:
Step 1: The Close/Resolve Ticket use case
completes its run. As a result, details of
the closed ticket are fed to the Knowledge
Base.
Step 2: Details are saved to Knowledge Base
database.
Step 3: The View/Edit Ticket use case
queries the Knowledge Base for past
tickets that are similar to a newly-
submitted ticket.
Step 4: The Knowledge Base retrieved queried
information
Conclusion: This use case concludes when data are committed to database, or when the query is complete.
Postcondition: Database transaction complete.
Business Rules: Tickets in knowledge base cannot be deleted.
Implementation
Constraints and
Specifications:
N/A
Assumptions: None.
Open Issues: None.

Author:__Team #8 Date:__1-Dec-2009_
Use-Case Name: Manage Users
Priority: High
Use Case Type
Primary System Actor: IT Management
Primary Business Actor: None
Other Participating
Actors:
Other Interested
Stakeholders:
All Users
Description: This use case describes the event of adding/editing/removing users from the ticketing system.
Precondition: None.
Trigger: This use case is initiated by IT management, by logging into the system and selecting “Manage
Users”.
Typical Course Of
Events:
Step 1: IT Management starts HDTS and
clicks “Manage Users”
Step 2: System lists all existing users, with options
to edit, delete, or add a user.
Step 3: IT Management chooses to edit or
add a user.
Step 4: System gives user details in editable form
Step 5: IT Management saves changes Step 6: Changes are committed to database.
Alternate Courses: Alt-Step-3: IT Management chooses to delete a user. System confirms and commits change to
database.
Conclusion: This use case concludes when data are committed to database.
Postcondition: Database transaction complete.
Business Rules: Users created when they are hired, and deleted when they leave the company.
Implementation
Constraints and
Specifications:
N/A
Assumptions: None.
Open Issues: None.

Use Case List / Events List
Actor/External Agent Event (Or Use Case) Trigger Responses
End-User
Technician
IT Management
Opening Helpdesk
Ticketing System
Login Login Confirmation
End User Submitting a new
ticket within the
Helpdesk System.
Submit New Ticket Assign Ticket to
Technician.
End User
Technician
Updating ticket with
new information.
Update Ticket Trigger E-mail
Notification/Status
Update.
End User Track progress of
ticket resolution and
submit updates.
Ticket Tracking Interact with Open
Tickets data store.
Technician
End User
Communicate with
End User about
specific problem.
Instant Messaging Save responses to
Open Tickets data
store.
Technician Allows Technician to
Close Ticket when
problem is solved.
Close/Resolve Ticket Save closed tickets to
Knowledge Base data
store. Also removes
from open tickets.
End User
Time
Sends Survey to End
Users on a timely
interval specified by IT
Management.
Close/Resolve Ticket,
Time
Completed Survey
goes to Survey
Responses data store.
IT Management
Time
Generates a report
initiated by IT
management based
on time parameters.
Reporting Survey data and
closed ticket data
form report presented
to IT management.
Submit New Ticket
(End User)
New ticket submitted
by End User is
assigned to
Technician based on
defined category.
Assign Ticket Trigger E-mail
Notification/Status
Update.
View/Edit
Close/Resolve Ticket
Assign Ticket
E-mail end users and
technicians when a
update has been
submitted
E-mail
Notification/Status
Update
E-mail notification
sent to Technician and
End User
View/Edit Ticket
Add entire ticket
record and all
communications to
Knowledge Base for
future records.
Knowledge Base Saves to Knowledge
Base Store

Context Diagram

Main Functions Diagram

Lower-Level DFDs
1.0 – Validate User

2.0 – Create / Update Ticket

3.0 – Survey
4.0 – Reporting

Decomposition Diagram

Event DFDs
Assign Ticket
E-mail Notification

Instant Messaging
Login

Reporting
Submit New Ticket
Survey

Ticket Tracking
View/Edit Ticket

Manage Users

System Diagram

Primitive Process Flowcharts
1.1 – Query User Database
1.2 – Compare Login Info

2.1 – Query Open Tickets

2.2 – Display Ticket Screen

2.3 – Record Ticket Info

2.4 – E-Mail Notification

2.5 – Assign Ticket

3.1 – Send Survey

3.2 – Record Survey
4.1 – Query Knowledge Base and Survey Data

4.2 – Display / Print Report

5.0 – Instant Messaging

6.0 – Manage Users

Data Dictionary / Structure
Data Dictionary/Structure
Data Structure Data Type
BLANK SURVEY =
FORM (FORM = SURVEY FORM) See SURVEY FORM
CLOSED/COMPLETED TICKET INFO =
TICKET (TICKET = OPEN TICKET) + See OPEN TICKET
TIME + INT
CLOSED CHAR (1)
CLOSED TICKET INFO
(0{OLD TICKET}N) ( OLD TICKET =
CLOSED/COMPLETED TICKET INFO)
See CLOSED/COMPLETED TICKET INFO
CONVERSATION RECORD
CONVERSATION (CONVERSATION =
MESSAGES)
See MESSAGES
FULLNAME =
LAST NAME + CHAR ( max 20)
FIRST NAME + CHAR ( max 20)
MIDDLE INITIAL CHAR (1)
KNOWLEDGE BASE =
TICKET (TICKET = OPEN TICKET) + See OPEN TICKET
RESOLUTION LONG VARCHAR
LOGIN =
USERNAME + CHAR ( max 20)
PASSWORD + CHAR ( max 20)
LOGIN CONFIRMATION =
LOGIN CONFIRMATION MESSAGE LONG VARCHAR
MESSAGES
(0{IM’S}N) LONG VARCHAR
NOTIFICATION =
USER INFO (USER INFO = USER) + See USER
TICKET (TICKET = OPEN TICKET) See OPEN TICKET
OPEN TICKET =
TICKET ID NUMBER + INT
USER INFO (USER INFO = USER) + See USER INFO
TECHNICIAN INFO (TECHNICIAN INFO =
USER)
See USER INFO
TICKET CATEGORY + CHAR ()
TICKET DESCRIPTION + LONG VARCHAR
(1{EMAIL}N)+ LONG VARCHAR
IM (IM = MESSAGES) See MESSAGES
(1{TICKET UPDATE}N) LONG VARCHAR
PREVIOUS TICKET INFO =
CLOSED TICKET (CLOSED TICKET =
CLOSED/COMPLETED TICKET INFO)
See CLOSED/COMPLETED TICKET INFO
REPORT DATA
TICKETS ( TICKETS = TICKET INFO) + See TICKET INFO
SURVEYS (SURVEYS = SURVEY DATA) See SURVEY DATA

Data Dictionary/Structure
Data Structure Data Type
SURVEY DATA
QUESTION (QUESTION = SURVEY
FORM) +
See SURVEY FORM
DATA (DATA = SURVEY RESPONSES) See SURVEY RESPONSES
SURVEY FORM
SURVEY QUESTIONS VAR CHAR
SURVEY RESPONSES =
TICKET ID NUMBER + INT
SURVEY (SURVEY = SURVEY FORM) + See SURVEY FORM
RESPONSES LONG VARCHAR
TICKET INFO =
TICKET INFO (TICKET INFO = OPEN
TICKET)
See OPEN TICKET
USER =
NAME (NAME = FULLNAME)+ See FULLNAME
EMAIL ADDRESS + CHAR ( max 20)
LOGIN INFO ( LOGIN INFO = LOGIN ) See LOGIN
PHONE NUMBER + NUM ( 10)
DEPARTMENT + CHAR ( max 20)
LOCATION + VARCHAR
[TECHNICIAN, CHAR ( max 10)
END USER, CHAR ( max 8)
IT MANAGEMENT] + CHAR ( max 13)
(1{CATEGORY}N) CHAR ( max 20)
USER INFO =
USERINFO ( USERINFO = USER) See USER

Entity/Definition Matrix
Entity Business Definition
Major Entities
Users A business entity that describes particular
users of the help desk ticketing system. They
can include end-users, technicians and
management
Open Ticket A service request from an end-user in which
gets assigned to a technician. Conversations
between the end-user and technician also take
place and are recorded.
Knowledge Base Solutions from previous closed/completed
tickets are added for future reference.
Survey Responses After end-user has completed a survey it gets
recorded for reporting capabilities.

Context Data Model

Key-Based Data Model

Fully Attributed Data Model

Activity Diagrams (Analysis)
Login

Submit New Ticket

Edit Ticket

Close Ticket

E-Mail Notification

Reporting

Sequence Diagrams (Analysis)
Login: End User

Login: Technician

Login: IT Management

Submit New Ticket

Edit Ticket

Close Ticket

E-Mail Notification

Reporting

Potential Object List
Potential Object Notes Obj Reason
Category Describes category of issue X Attribute of Ticket
Close Ticket The action of closing a ticket X Method of Ticket
Criteria Displays sorted data by
Technician, End User,
Department and End User
Location
X Attribute of Report
Department Describes Department user
belongs to
X Attribute of User
Description An explanation of issue user is
experiencing
X Attribute of Ticket
E-mail Address E-mail address of user X Attribute of User
E-mail Notification The action of a user receives E-
mail notification anytime ticket
is update, assigned or closed.
X Method of Ticket
End User A user of the HDTS X Attribute of User
Error Message The action of a message being
displayed when login
credentials are incorrect
X Method of Login
Instant Message Messaging between End Users
and technician takes place if
more information is needed
from the End User
Instant Messaging The action of communication
between End Users and
Technicians
X Method of Ticket
Knowledge Base Status of Ticket X Attribute of Ticket
Location Location of the End User X Attribute of User
Login Login is required to use HDTS √
New Ticket The process a user follows to
create a ticket
X Method of Ticket
Open Ticket The action of creating a ticket X Instantiate Ticket
Password Password is needed for added
security which is tied to each
End User
X Attribute of User
Report A report is requested by IT
Management on a timely
interval
X Interface
Resolution A description of the steps taken
to resolve the issue
Survey A survey is sent to End Users
once a resolution has occurred
based on a timely interval set
by IT Management
√
Survey Responses Completed questions that were
completed by End User
X Attribute of Survey

Ticket √
Ticket Assignment Each ticket is assigned to a
technician based on criteria or
problem
Ticket ID Number Each ticket is assigned a
unique ID number
Update Update to original ticket
description
User √
User Info Describes the End User X Attribute of User
User Type Can consist of IT Management,
End User and Technician
X Attribute of User
Username A username is tied to a
particular End User
X Attribute of User

Class Diagram (Analysis)

Use Case Narratives (System Design)
Author:__Team #8 Date:__24-Nov-2009_
Use-Case Name: Login
Priority: High
Source: Requirements Use Case HDTS-001
Use Case Type
System Analysis:
System Design:
Primary Business Actor: End User, Technician
Other Participating
Actors:
End User, Technician, IT Management
Other Interested
Stakeholders:
Description: This use case describes the event of a user authenticating with the help desk system.
Precondition: User must have browser open to login screen
Trigger: Typing in username and password followed by pressing a login button
Typical Course Of
Events:
Step 1: This use case is initiated when a
user launches the HDTS from the desktop
icon.
Step 2: The system responds by displaying screen
login, which prompts the user for a username and
password to access the system.
Step 3: The user types their assigned
username and password and clicks Submit
button.
Step 4: The system confirms that the username and
password are valid by displaying message
login_success, and then displays screen
submit_new_ticket if the end user has no open
ticket, or ticket_tracking if end user has an open
ticket.
Alternate Courses: Alt-Step 4: System is unable to confirm that the user name is in the system, or is unable to
confirm that the password is valid: System displays message login_failure to inform the user of
failure, and returns to Step 2.
Alt-Step-4: User is defined as Technician: System displays screen view_edit_ticket.
Alt-Step-4: User is defined as IT Management: System displays screen reporting.
Conclusion: User logs into help desk system
Postcondition: Browser now displays the help desk system
Business Rules:
Implementation
Constraints and
Specifications:
The browser may display a different set of GUI for the help desk system based on whether the
users login is associated with a End User, Technician or IT management after login.
Assumptions:
Open Issues:

Help Desk Ticketing System - Requirements Specification

Help Desk Ticketing System - Requirements Specification

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Help Desk Ticketing System - Requirements Specification

Similaire à Help Desk Ticketing System - Requirements Specification (20)

Help Desk Ticketing System - Requirements Specification