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

Help Desk Ticketing System - Requirements Specification

Embed Size (px)

Citation preview

Page 1: 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�

Page 2: Help Desk Ticketing System - Requirements Specification

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

Page 3: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �3�

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 SUBMIT�NEW�TICKET .......................................................................................................................................................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

Page 4: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �4�

ACTIVITY�DIAGRAMS�(ANALYSIS)..................................................................................................................................................... 97

LOGIN ........................................................................................................................................................................97 SUBMIT�NEW�TICKET .......................................................................................................................................................98 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 SUBMIT�NEW�TICKET .....................................................................................................................................................115 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 SUBMIT�NEW�TICKET .....................................................................................................................................................134 SURVEY ....................................................................................................................................................................135 TICKET�TRACKING.........................................................................................................................................................136 VIEW/EDIT�TICKET ........................................................................................................................................................137

CLASS�STRUCTURE�DIAGRAM�(DESIGN)........................................................................................................................................ 138

Page 5: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �5�

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

Page 6: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �6�

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������������������������������

PresidentC. Shetler

Administrative AssistantY. Coles

Key Acc Mgr Ford + New Business

J. Rozell

Acc Mgr Chrysler Upper Steering

J. Ratajski

Acc Mgr Chrysler Lower Steering

B. Hetrick

Sales EngineerT. Buse

Sales EngineerD. West

Sales EngineerS. Rink

Acc ManagerL. Lindsey

Acc ManagerF. Spiess

Sales Engineering ManagerJ. Douma

Logistics Coordinator

D. Dann

LogisticsCoordinatorD. Nowak

ITA. Hebert

ITJ. Bloom

Controlling/IT/SAP Manager

M. Montoya

Page 7: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �7�

Organization�Chart�–�Existing�IS��

���

Page 8: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �8�

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�[email protected]�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�

���

Page 9: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �9�

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�

Page 10: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �10�

Request�for�IT�Project�

Page 11: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �11�

Page 12: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �12�

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� ��

Page 13: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �13�

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:�� ���� � ���� � ���� � ���� �� ���

Page 14: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �14�

�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� ��

�� 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�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� ��

Page 15: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �15�

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:�� ���� � ���� � ���� � ���� �� ���

Page 16: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �16�

Questionnaire�

Page 17: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �17�

Page 18: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �18�

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�

���

Page 19: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �19�

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�What�are�the�shortcomings�of�the�current�process?� 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�What�are�end-user�complaints�about�the�current�system?� 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.����

Page 20: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �20�

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.��

Page 21: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �21�

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.���

Page 22: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �22�

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�What�are�the�shortcomings�of�the�current�process?��

• 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�What�are�end-user�complaints�about�the�current�system?��Isn’t�aware�of�any�shortcoming�other�than�issues�listed�as�above��

Page 23: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �23�

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.������

Page 24: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �24�

Completed�Questionnaires�

Page 25: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �25�

Page 26: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �26�

Page 27: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �27�

Page 28: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �28�

Page 29: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �29�

Page 30: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �30�

Page 31: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �31�

Page 32: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �32�

Page 33: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �33�

Page 34: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �34�

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.�

6�months� High� $100,000� 1� New�development�

7. VHD�system�is�extremely�slow,�particularly�from�WAN-linked�locations.�

3�months� High� $125,000� 1� New�development�

8. Communication�between�IT�and�end�users�is�not�logged.�

3�months� Low� $40,000� 3� New�development�

9. Survey�participation�rate�is�very�low.�

6�months� Low� $20,000� 4� New�development�

10. No�provision�for�instant�messaging�currently�exists.�

12�months� Low� $30,000� 4� New�development�

Page 35: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �35�

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. �

Page 36: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �36�

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. �

Page 37: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �37�

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.�

Page 38: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �38�

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.�

Page 39: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �39�

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.3. By�end�user�department�

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.3. By�end�user�department�

12.3.2.4. By�end�user�location�

Page 40: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �40�

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.�

��������

Page 41: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �41�

Business�Process�Diagram��

Page 42: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �42�

Supporting�Materials��BPD�Documents�&�Forms��Submit�New�Ticket��

��E-mail�to�IT�for�Assistance��

��

Page 43: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �43�

Assigned�Helpdesk�Ticket��

��E-mail�/�Phone�Communication��

Page 44: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �44�

Ticket�Resolution��

��Survey�Form��

Page 45: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �45�

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.���

Business�Process�Description�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.���

Business�Process�Description�

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.��

Page 46: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �46�

�Business�Process�Description�

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.���

Business�Process�Description�

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.�

Page 47: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �47�

Screenshots�of�Existing�IS�(VisualHD/VHD)��Welcome�Screen��

��

Page 48: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �48�

New�Ticket�Screen��

��Category�Selection�Screen��

Page 49: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �49�

Category�Selection�Screen�2��

��Description�Entry�Screen��

Page 50: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �50�

Technician�Main�Screen��

��Technician�Ticket�View�1��

Page 51: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �51�

Technician�Ticket�View�2��

��Technician�Ticket�View�3��

Page 52: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �52�

Technician�Ticket�History�View��

�����

Page 53: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �53�

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�

Page 54: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �54�

Use�Case�Diagram�����

��

Page 55: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �55�

Use�Case�Narratives�(Business�Requirements)���

Help�Desk�Ticketing�System��

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�

Page 56: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �56�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Submit�New�Ticket�

Use-Case�ID:� HDTS-002�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� End�User,�Technician,�IT�Management�

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:�

Actor�Action� System�Response�

��

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�

Page 57: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �57�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Assign�Ticket�

Use-Case�ID:� HDTS-003�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

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:�

Actor�Action� System�Response�

��

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�

Page 58: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �58�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� View/Edit�Ticket�

Use-Case�ID:� HDTS-004�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� Technician,�IT�Management�

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

��

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:� �

Page 59: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �59�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Ticket�Tracking�

Use-Case�ID:� HDTS-005�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� End�User�

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

��

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:� �

Page 60: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �60�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Close/Resolve�Ticket�

Use-Case�ID:� HDTS-006�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� Technician��

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

��

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:� �

Page 61: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �61�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Instant�Messaging��

Use-Case�ID:� HDTS-007�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� Technician�

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

��

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?�

Page 62: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �62�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� E-Mail�Notification�/�Status�Update�

Use-Case�ID:� HDTS-008�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

Primary�System�Actor:� �

Primary�Business�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:�

Actor�Action� System�Response�

��

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.�

Page 63: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �63�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Reporting�

Use-Case�ID:� HDTS-009�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

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:�

Actor�Action� System�Response�

��

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.��

� � �

Alternate�Courses:� None.�

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?�

Page 64: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �64�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Survey�

Use-Case�ID:� HDTS-010�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

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:�

Actor�Action� System�Response�

��

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:� �

Page 65: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �65�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__13-Oct-2009_��

Use-Case�Name:� Knowledge�Base�

Use-Case�ID:� HDTS-011�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

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:�

Actor�Action� System�Response�

��

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�

� � �

Alternate�Courses:� None.�

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.�

Page 66: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �66�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__1-Dec-2009_��

Use-Case�Name:� Manage�Users�

Use-Case�ID:� HDTS-012�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���

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:�

Actor�Action� System�Response�

��

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.�

������

Page 67: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �67�

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�

Close/Resolve�Ticket�View/Edit�Ticket�

Add�entire�ticket�record�and�all�communications�to�Knowledge�Base�for�future�records.�

Knowledge�Base� Saves�to�Knowledge�Base�Store�

��

Page 68: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �68�

Context�Diagram�������

Page 69: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �69�

Main�Functions�Diagram������

��

Page 70: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �70�

Lower-Level�DFDs��

1.0�–�Validate�User�

��

��

Page 71: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �71�

2.0�–�Create�/�Update�Ticket�

��

��

Page 72: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �72�

3.0�–�Survey�

���

��

4.0�–�Reporting�

���

���

Page 73: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �73�

Decomposition�Diagram�����

��

��

Page 74: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �74�

Event�DFDs��

Assign�Ticket�

���

Close/Resolve�Ticket�

���

E-mail�Notification�

��

Page 75: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �75�

Instant�Messaging�

���

Login�

���

Page 76: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �76�

Reporting�

���

Submit�New�Ticket�

���

Survey�

��

Page 77: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �77�

Ticket�Tracking�

���

View/Edit�Ticket�

���

Page 78: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �78�

Manage�Users�

��

Page 79: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �79�

System�Diagram�

Page 80: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �80�

Primitive�Process�Flowcharts��

1.1�–�Query�User�Database�

1.2�–�Compare�Login�Info�

Page 81: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �81�

2.1�–�Query�Open�Tickets�

Page 82: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �82�

2.2�–�Display�Ticket�Screen�

��

Page 83: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �83�

2.3�–�Record�Ticket�Info�

��

Page 84: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �84�

2.4�–�E-Mail�Notification�

Page 85: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �85�

2.5�–�Assign�Ticket�

��

��

Page 86: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �86�

3.1�–�Send�Survey�

��

Page 87: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �87�

3.2�–�Record�Survey�

��

��

4.1�–�Query�Knowledge�Base�and�Survey�Data�

���

Page 88: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �88�

4.2�–�Display�/�Print�Report�

��

Page 89: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �89�

5.0�–�Instant�Messaging�

Page 90: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �90�

6.0�–�Manage�Users�

Page 91: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �91�

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�

Page 92: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �92�

�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�

� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �

Page 93: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �93�

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.���

��

Page 94: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �94�

Context�Data�Model������

Page 95: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �95�

Key-Based�Data�Model������

��

Page 96: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �96�

Fully�Attributed�Data�Model����

����

Page 97: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �97�

Activity�Diagrams�(Analysis)��

Login�

����

Page 98: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �98�

Submit�New�Ticket�

���

Page 99: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �99�

Edit�Ticket�

���

Page 100: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �100�

Close�Ticket�

����

Page 101: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �101�

E-Mail�Notification�

���

Page 102: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �102�

Reporting�

����

Page 103: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �103�

Sequence�Diagrams�(Analysis)��

Login:�End�User�

����

Page 104: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �104�

Login:�Technician�

��

Page 105: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �105�

Login:�IT�Management�

Page 106: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �106�

Submit�New�Ticket���

��

Page 107: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �107�

Edit�Ticket�

����

Page 108: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �108�

Close�Ticket�

��

��

Page 109: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �109�

E-Mail�Notification�

��

��

Page 110: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �110�

Reporting�

����

Page 111: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �111�

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�

X� Attribute�of�Ticket�

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�

X� Attribute�of�Ticket�

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�

Page 112: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �112�

�Ticket� � √� �Ticket�Assignment� Each�ticket�is�assigned�to�a�

technician�based�on�criteria�or�problem�

X� Attribute�of�Ticket�

Ticket�ID�Number� Each�ticket�is�assigned�a�unique�ID�number�

X� Attribute�of�Ticket�

Update� Update�to�original�ticket�description�

X� Attribute�of�Ticket�

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�

Page 113: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �113�

Class�Diagram�(Analysis)����

���

Page 114: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �114�

Use�Case�Narratives�(System�Design)��

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Login�

Use-Case�ID:� HDTS-001�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-001�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

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:�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:� �

Page 115: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �115�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Submit�New�Ticket�

Use-Case�ID:� HDTS-002�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-002�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� End�User,�Technician,�IT�Management�

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:�

Actor�Action� System�Response�

� Step�1:�This�use�case�is�initiated�when�an�end�user�has�successfully�logged�into�the�HDTS,�and�has�no�existing�open�ticket.�

Step�2:�The�system�responds�by�displaying�screen�submit_new_ticket,�which�offers�the�end�user�a�dropdown�menu�to�select�the�ticket�category,�and�a�free�text�area�to�describe�the�problem�in�detail.�

��

Step�3:�User�selects�a�category�from�a�dropdown�menu,�that�best�describes�the�classification�of�the�issue�they�are�experiencing�

� Step�4:�User�types�a�description�of�the�issue�they�are�experiencing�in�the�designated�field.�

� Step�5:�User�presses�a�submit�button� Step�6:�System�automatically�designates�an�unique�Ticket�ID�number�to�the�submitted�ticket�

� � Step�7:�Ticket�information�is�sent�to�the�Assign�Ticket�system�(Separate�Use�Case)��

� � Step�8:�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:� �

Page 116: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �116�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__3-Dec-2009_��

Use-Case�Name:� Assign�Ticket�

Use-Case�ID:� HDTS-003�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-003�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� HDTS�(Assign�Ticket�Controller)�

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:�

Actor�Action� System�Response�

��

Step�1:�New�ticket�created�in�Submit�New�Ticket�use�case.�

Step�2:�System�assigns�a�technician�to�the�ticket�based�on�the�category�defined�in�the�ticket�and�the�categories�supported�by�each�technician.��

� �� Step�3:�System�updates�database�record�with�technician�assignment�info.��

Alternate�Courses:� �

Conclusion:� Ticket�is�assigned�to�a�technician�based�on�information�provided�by�user.�

Postcondition:� The�ticket�now�has�a�designated�Technician.�

Business�Rules:� �

Implementation�Constraints�and�Specifications:�

After�ticket�has�been�assigned,�the�assigned�technician�can�be�changed�by�the�originally�assigned�technician.�

Assumptions:� �

Open�Issues:� �

Page 117: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �117�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� View/Edit�Ticket�

Use-Case�ID:� HDTS-004�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-004�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� Technician�

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

� Step�1:�This�use�case�is�initiated�when�a�user�of�type�Technician�completes�Login�successfully.�

Step�2:�The�system�responds�by�displaying�screen�view_edit_ticket, which�includes�a�dropdown�box�to�select�between�all�open�tickets�assigned�to�that�technician.�

��

Step�3:�Technician�selects�an�existing�ticket�from�the�dropdown�menu.�

Step�4:�System�retrieves�all�information�associated�with�the�ticket�from�the�Tickets�data�store,�and�displays�it�on�the�screen�in�editable�form.��The�system�also�adds�a�Ticket�Update�text�entry�box,�an�Instant�Messaging�button�and�a�Submit�button�to�the�screen.�

� Step�5:�Technician�edits�on-screen�ticket�details,�or�adds�to�the�ticket�using�the�Ticket�Update�text�entry�area,�and�clicks�the�Submit�button.�

Step�6:�System�updates�saved�information�in�data�store.�

Alternate�Courses:� Alt-Step-5:��Technician�clicks�Instant�Messaging�button:�System�responds�by�initiating�Instant�Messaging�use�case.�

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:� �

Page 118: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �118�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Ticket�Tracking�

Use-Case�ID:� HDTS-005�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-005�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� End�User�

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

� Step�1:�This�use�case�is�initiated�when�an�end�user�has�successfully�logged�in,�and�has�an�existing�open�ticket.�

Step�2:�The�system�responds�by�displaying�screen�ticket_tracking,�which�displays�all�existing�ticket�info�from�the�Tickets�data�store,�in�view-only�format.��In�addition,�the�screen�will�have�an�editable�Ticket�Update�text�entry�area,�a�Submit�button�and�an�Instant�Messaging�button.�

��

Step�3:��If�required,�the�end�user�enters�updated�ticket�information�and�clicks�Submit.���

Step�4:�The�system�responds�by�updating�the�ticket�record�in�the�Tickets�data�store.��The�updated�information�becomes�part�of�the�uneditable�existing�ticket�info,�and�a�new�Ticket�Update�text�entry�area�appears.�

Alternate�Courses:� Alt-Step-3:��User�clicks�Instant�Messaging�button:�System�responds�by�initiating�Instant�Messaging�use�case.�

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:� �

Page 119: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �119�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Close/Resolve�Ticket�

Use-Case�ID:� HDTS-006�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-006�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� Technician��

Primary�Business�Actor:� �

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:�

Actor�Action� System�Response�

��

Step�1:�Ticket�Closure�is�initiated�by�a�technician�from�the�view_edit_ticket�screen�by�clicking�the�Close�button.�

Step�2:�The�system�displays�the�ticket_resolution�screen,�which�contains�a�text�entry�area�for�the�technician�to�enter�the�final�resolution�of�the�problem,�and�a�Submit�button.�

� Step�3:�A�technician�completes�the�ticket�resolution�and�clicks�Submit�button.�

Step�4:�System�stores�ticket�resolution�in�Tickets�data�store.�

� � Step�5:�Email�Notification�use�case�is�initiated�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:� �

Page 120: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �120�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Instant�Messaging��

Use-Case�ID:� HDTS-007�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-007�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� Technician�

Primary�Business�Actor:� �

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.�• Technician�must�be�viewing�the�view_edit_ticket�screen�or�end�user�must�be�viewing�the�

ticket_tracking�screen.�Trigger:� Instant�Messaging�button�is�clicked�on�view_edit_ticket�screen�or�ticket_tracking�screen.�

Typical�Course�Of�Events:�

Actor�Action� System�Response�

� Step�1:�Instant�Messaging�is�initiated�by�a�technician�on�the�view_edit_ticket�screen,�or��by�and�end�user�on�the�ticket_tracking�screen�by�clicking�the�Instant�Messaging�button��

Step�2:�System�responds�by�opening�window�instant_messaging�on�the�initiator’s�screen,�and�on�the�other�party’s�screen,�simultaneously.��Window�includes�a�text�entry�box,�a�running�display�of�previous�messages,�and�a�Close�button.�

� Step�3:�Text�is�input�by�either�user� Step�4:�System�stores�input�into�Ticket�data�store,�then�displays�message�on�both�technician�and�end�users�instant_messaging�screen.�

� Step�5:�Repeat�step�3�and�step�4�as�needed�

� Step�6:�Either�user�clicks�the�Close�button�on�the�instant_messaging�screen.�

Alternate�Courses:� �

Conclusion:� The�use�case�concludes�when�the�technician�has�received�enough�information�about�the�current�issue�from�the�end-user�and�no�more�text�is�imputed.�

Postcondition:� The�end-users�ticket�is�updated�with�communication�records�between�the�end-user�and�the�technician.�

Business�Rules:� �

Implementation�Constraints�and�Specifications:�

Assumptions:� �

Open�Issues:� �

Page 121: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �121�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� E-Mail�Notification�/�Status�Update�

Use-Case�ID:� HDTS-008�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-008�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� �

Primary�Business�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�end�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:�

Actor�Action� System�Response�

��

Step�1:�This�use�case�is�initiated�when�a�technician�updates�a�ticket�within�the�view_edit_ticket�screen�(including�the�close/resolve�process�in�the�ticket resolution�screen)�or�after�a�ticket�is�created�by�the�end�user�through�the�submit_new_ticket.�����Step�3:When�an�issue�has�been�resolved�the�technician�closes�the�ticket�via�the�view_edit_screen�and�clicks�Submit�button��

Step�2:�The�system�responds�by�querying�through�the�Tickets�data�store�looking�for�ticket�changes�and�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.����Step�4:�If�the�status�of�the�ticket�has�changed�to�resolved�status�the�system�responds�by�notifying�the�end�user�through�e-mail�of�a�status�change�and�the�system�will�remove�that�particular�ticket�from�the�Ticket�data�store.���

� � �� � �

Alternate�Courses:� Alt-Step-1:��End�user�submits�a�ticket�update�through�the�ticket_tracking�screen.�

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.�

Page 122: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �122�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Reporting�

Use-Case�ID:� HDTS-009�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-009�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

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:�

Actor�Action� System�Response�

��

Step�1:�This�use�case�is�initiated�when�a�user�of�type�IT�management�completes�Login�successfully.�

Step�2:�The�system�responds�by�displaying�screen�management_reporting which�includes�three�dropdown�menus,�one�to�run�a�report�on�survey�data�and/or�ticket�data.��The�second�dropdown�menu�allows�IT�management�to�select�a�specified�timeframe.��Third�dropdown�menu�allows�user�to�select�location/department�from�ticket�criteria.��Screen�also�includes�a�“Manage�Users”�button�to�launch�user�management.��

� Step�3:�IT�Management�selects�criteria�from�dropdown�menus�that�are�displayed�on�screen�management_reporting.The�IT�manager�chooses�to�run�a�report�by�selecting�the�submit�button�

Step�4:�System�queries�Ticket�and�Survey�data�stores�and�produces�report�as�requested,�displayed�to�management_reporting�screen.��

� � �

Alternate�Courses:� Alt-Step-3:��IT�Management�selects�Manage�Users�button:�System�responds�by�displaying�screen�manage_users�(see�Manage�Users�use�case).�

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:� �

Page 123: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �123�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Survey�

Use-Case�ID:� HDTS-010�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-010�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

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:�

Actor�Action� System�Response�

� Step�1:�This�use�case�is�triggered�when�at�least�one�ticket�for�an�end�user�has�been�closed,�and�a�specified�time�interval�has�been�reached.�

Step�2:�The�system�responds�by�notifying�the�end�user�via�e-mail�that�a�survey�is�available�for�completion,�related�to�the�ticket(s)�recently�closed.��The�e-mail�contains�a�link�to�access�the�survey�page�survey_form�to�complete�the�survey.�

��

Step�3:�The�end�user�clicks�on�the�link�in�the�e-mail.�

Step�3:�System�displays�page�survey_form,�which�is�pre-populated�with�the�relevant�ticket�ID�number,�and�contains�5�standard�questions,�a�comments�text�entry�area�and�a�submit�button.�

� Step�4:�The�end�user�responds�to�the�survey�questions,�and�clicks�the�Submit�button.�

Step�5:�The�system�responds�by�displaying�screen�survey_complete,�which�contains�a�confirmation�message�for�the�end�user.��Survey�responses�are�logged�to�Survey�Responses�data�store.��

Alternate�Courses:� �

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:� �

Page 124: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �124�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__24-Nov-2009_��

Use-Case�Name:� Knowledge�Base�

Use-Case�ID:� HDTS-011�

Priority:� High�

Source:� Requirements�Use�Case�HDTS-011�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

Primary�System�Actor:� Technician�

Primary�Business�Actor:� None�

Other�Participating�Actors:�

None�

Other�Interested�Stakeholders:�

IT�Management�

Description:� This�use�case�describes�the�event�of�interacting�with�the�database�of�closed�help�desk�tickets.�From�the�View/Edit�Ticket�use�case,�the�technician�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�triggered�by�a�technician�pressing�on�the�Knowledge�Base�button�on�the�view_edit_ticket�screen.�

Typical�Course�Of�Events:�

Actor�Action� System�Response�

� Step�1:�This�use�case�is�initiated�when�a�technician�clicks�the�Knowledge�Base�button�on�the�view_edit_ticket�screen.�

Step�2:�The�system�responds�by�displaying�screen�knowledge_base,�which�contains�the�result�of�a�database�query�that�searches�the�Tickets�data�store�for�previously-closed�tickets�that�contain�similar�description�text.��Each�line�includes�ticket�ID�number,�category,�and�description.�

��

Step�3:�The�technician�clicks�on�a�ticket�ID�number�in�the�listing�

Step�4:�The�system�displays�screen�closed_ticket,�which�contains�all�of�the�stored�details�related�to�the�ticket�ID�number�chosen.��

� Step�5:�The�technician�clicks�the�Close�button�when�consultation�is�complete�

Step�6:�The�system�returns�to�screen�knowledge_base.��

� � �

Alternate�Courses:� None.�

Conclusion:� This�use�case�concludes�when�the�technician�clicks�the�Close�button�on�the�screen�knowledge_base.�

Postcondition:� Database�transaction�complete.�

Business�Rules:� Tickets�in�knowledge�base�cannot�be�deleted.�

Implementation�Constraints�and�Specifications:�

N/A�

Assumptions:� None.�

Open�Issues:� None.�

Page 125: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �125�

Help�Desk�Ticketing�System��

Author:__Team�#8������� Date:__3-Dec-2009_��

Use-Case�Name:� Manage�Users�

Use-Case�ID:� HDTS-012�

Priority:� High�

Source:� Functional�Requirement�Document�

Use�Case�Type�Business�Requirements���System�Analysis:��������������System�Design:�����������������

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:�

Actor�Action� System�Response�

��

Step�1:�This�use�case�is�initiated�when�an�IT�management�user�clicks�the�“Manage�Users”�button�on�the�screen�management_reporting.�

Step�2:�The�system�responds�by�displaying�screen�user_management�which�includes�a�scrollable�list�of�all�HDTS�users.��Each�line�includes�a�button�to�delete�the�user.��One�“Add�User”�button�is�displayed�at�the�top�of�the�listing.��

� Step�3:�IT�Management�user�clicks�“Add�User”�button.�

Step�4:�The�system�responds�by�displaying�screen�add_user�which�collects�user�info�from�IT�management.��Screen�includes�a�Submit�button�to�commit�data.�

� Step�5:�IT�Management�saves�changes�by�clicking�Submit�button.�

Step�6:�The�system�responds�by�committing�the�user�info�to�the�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.�

��

Page 126: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �126�

Sequence�Diagrams�(Design)��

Assign�Ticket�

Page 127: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �127�

Close/Resolve�Ticket�

���

Page 128: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �128�

E-mail�Notification�/�Status�Update�

��

Page 129: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �129�

Instant�Messaging�

Page 130: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �130�

Knowledge�Base�

��

Page 131: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �131�

Login�

��

Page 132: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �132�

Manage�Users�

Page 133: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �133�

Reporting�

Page 134: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �134�

Submit�New�Ticket�

��

Page 135: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �135�

Survey�

���

Page 136: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �136�

Ticket�Tracking�

���

Page 137: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �137�

View/Edit�Ticket�

���

Page 138: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �138�

Class�Structure�Diagram�(Design)��

Page 139: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �139�

State�Machine�Diagrams�(Design)��

Add�User�

���

Page 140: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �140�

Assign�Ticket�

��

Page 141: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �141�

Close_resolve_ticket�

���

Page 142: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �142�

Closed_ticket�

���

Page 143: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �143�

Email�

���

Page 144: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �144�

Instant_messaging�

���

Page 145: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �145�

Knowledge_base�

���

Page 146: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �146�

Login�

���

Page 147: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �147�

Management_reporting�

���

Page 148: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �148�

Submit_new_ticket�

���

Page 149: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �149�

Survey�

���

Page 150: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �150�

Survey_complete�

���

Page 151: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �151�

Survey_form�

��

���

Page 152: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �152�

Survey_timer1�

��

���

Page 153: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �153�

Ticket_tracking�

��

��

Page 154: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �154�

User�Management�

����

Page 155: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �155�

View_edit_ticket�

��

����

Page 156: Help Desk Ticketing System - Requirements Specification

Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �156�

Appendix������������������������

Appendix�Items�Beyond�This�Page�