���
�����
��
Help�Desk�Ticketing�System�ThyssenKrupp�Presta�Steering�Group�USA�
������
CIT�352�Project�Final�Report�
Requirements�Specification��������
December�10,�2009��������
André�Hébert�����-�����Evan�Sprague�����-�����Kyle�Thompson�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �2�
Table�of�Contents��
COMPANY�HISTORY�/�DESCRIPTION ...................................................................................................................................................6
ORGANIZATION�CHART�–�TROY ...........................................................................................................................................................6
ORGANIZATION�CHART�–�EXISTING�IS ................................................................................................................................................7
STAKEHOLDERS....................................................................................................................................................................................8
PROJECT�CHARTER...............................................................................................................................................................................8
INTERVIEW�LOCATIONS�AND�TIMES....................................................................................................................................................9
INTERVIEWEES ......................................................................................................................................................................................9
REQUEST�FOR�IT�PROJECT ............................................................................................................................................................... 10
INTERVIEW�GUIDES............................................................................................................................................................................ 12
QUESTIONNAIRE ................................................................................................................................................................................ 16
DOCUMENTS�TO�BE�REQUESTED...................................................................................................................................................... 18
RECORDING�METHODS...................................................................................................................................................................... 18
INTERVIEW�RECORD�–�LINDSEY�SNAPP........................................................................................................................................... 19
INTERVIEW�RECORD�–�JULIE�BLOOM............................................................................................................................................... 22
COMPLETED�QUESTIONNAIRES........................................................................................................................................................ 24
PROBLEM�STATEMENT�MATRIX ........................................................................................................................................................ 34
CAUSE�AND�EFFECT�ANALYSIS......................................................................................................................................................... 35
FUNCTIONAL�REQUIREMENTS .......................................................................................................................................................... 37
NON-FUNCTIONAL�REQUIREMENTS�(PIECES�CLASSIFICATION) ................................................................................................... 40
BUSINESS�PROCESS�DIAGRAM ........................................................................................................................................................ 41
SUPPORTING�MATERIALS ................................................................................................................................................................. 42
BPD�PROCESS�DESCRIPTIONS ......................................................................................................................................................... 45
SCREENSHOTS�OF�EXISTING�IS�(VISUALHD/VHD).......................................................................................................................... 47
USE�CASE�GLOSSARY........................................................................................................................................................................ 53
USE�CASE�DIAGRAM .......................................................................................................................................................................... 54
USE�CASE�NARRATIVES�(BUSINESS�REQUIREMENTS) ................................................................................................................... 55
LOGIN ........................................................................................................................................................................55 SUBMIT�NEW�TICKET .......................................................................................................................................................56 ASSIGN�TICKET .............................................................................................................................................................57 VIEW/EDIT�TICKET ..........................................................................................................................................................58 TICKET�TRACKING...........................................................................................................................................................59 CLOSE/RESOLVE�TICKET ..................................................................................................................................................60 INSTANT�MESSAGING ......................................................................................................................................................61 E-MAIL�NOTIFICATION�/�STATUS�UPDATE...............................................................................................................................62 REPORTING ..................................................................................................................................................................63 SURVEY ......................................................................................................................................................................64 KNOWLEDGE�BASE .........................................................................................................................................................65 MANAGE�USERS ............................................................................................................................................................66
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
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
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
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
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �7�
Organization�Chart�–�Existing�IS��
���
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�
���
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�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �10�
Request�for�IT�Project�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �11�
�
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� ��
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:�� ���� � ���� � ���� � ���� �� ���
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� ��
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:�� ���� � ���� � ���� � ���� �� ���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �16�
Questionnaire�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �17�
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�
���
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.����
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.��
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.���
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��
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.������
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �24�
Completed�Questionnaires�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �25�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �26�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �27�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �28�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �29�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �30�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �31�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �32�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �33�
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�
�
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. �
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. �
�
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.�
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.�
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�
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.�
��������
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �41�
Business�Process�Diagram��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �42�
Supporting�Materials��BPD�Documents�&�Forms��Submit�New�Ticket��
��E-mail�to�IT�for�Assistance��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �43�
Assigned�Helpdesk�Ticket��
��E-mail�/�Phone�Communication��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �44�
Ticket�Resolution��
��Survey�Form��
�
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.��
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.�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �47�
Screenshots�of�Existing�IS�(VisualHD/VHD)��Welcome�Screen��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �48�
New�Ticket�Screen��
��Category�Selection�Screen��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �49�
Category�Selection�Screen�2��
��Description�Entry�Screen��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �50�
Technician�Main�Screen��
��Technician�Ticket�View�1��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �51�
Technician�Ticket�View�2��
��Technician�Ticket�View�3��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �52�
Technician�Ticket�History�View��
�����
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�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �54�
Use�Case�Diagram�����
��
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�
�
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�
�
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�
�
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:� �
�
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:� �
�
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:� �
�
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?�
�
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.�
�
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?�
�
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:� �
�
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.�
�
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.�
������
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�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �68�
Context�Diagram�������
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �69�
Main�Functions�Diagram������
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �70�
Lower-Level�DFDs��
1.0�–�Validate�User�
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �71�
2.0�–�Create�/�Update�Ticket�
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �72�
3.0�–�Survey�
���
��
4.0�–�Reporting�
���
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �73�
Decomposition�Diagram�����
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �74�
Event�DFDs��
Assign�Ticket�
�
���
Close/Resolve�Ticket�
�
���
E-mail�Notification�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �75�
Instant�Messaging�
�
���
Login�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �76�
Reporting�
�
���
Submit�New�Ticket�
�
���
Survey�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �77�
Ticket�Tracking�
�
���
View/Edit�Ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �78�
Manage�Users�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �79�
System�Diagram�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �80�
Primitive�Process�Flowcharts��
1.1�–�Query�User�Database�
�
�
1.2�–�Compare�Login�Info�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �81�
2.1�–�Query�Open�Tickets�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �82�
2.2�–�Display�Ticket�Screen�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �83�
2.3�–�Record�Ticket�Info�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �84�
2.4�–�E-Mail�Notification�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �85�
2.5�–�Assign�Ticket�
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �86�
3.1�–�Send�Survey�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �87�
3.2�–�Record�Survey�
�
��
��
4.1�–�Query�Knowledge�Base�and�Survey�Data�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �88�
4.2�–�Display�/�Print�Report�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �89�
5.0�–�Instant�Messaging�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �90�
6.0�–�Manage�Users�
�
�
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�
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�
� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �� �
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.���
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �94�
Context�Data�Model������
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �95�
Key-Based�Data�Model������
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �96�
Fully�Attributed�Data�Model����
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �97�
Activity�Diagrams�(Analysis)��
Login�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �98�
Submit�New�Ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �99�
Edit�Ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �100�
Close�Ticket�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �101�
E-Mail�Notification�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �102�
Reporting�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �103�
Sequence�Diagrams�(Analysis)��
Login:�End�User�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �104�
Login:�Technician�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �105�
Login:�IT�Management�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �106�
Submit�New�Ticket���
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �107�
Edit�Ticket�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �108�
Close�Ticket�
�
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �109�
E-Mail�Notification�
��
��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �110�
Reporting�
�
����
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�
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�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �113�
Class�Diagram�(Analysis)����
���
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:� �
�
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:� �
�
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:� �
�
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:� �
�
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:� �
�
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:� �
�
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:� �
�
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.�
�
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:� �
�
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:� �
�
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.�
�
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.�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �126�
Sequence�Diagrams�(Design)��
Assign�Ticket�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �127�
Close/Resolve�Ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �128�
E-mail�Notification�/�Status�Update�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �129�
Instant�Messaging�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �130�
Knowledge�Base�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �131�
Login�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �132�
Manage�Users�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �133�
Reporting�
�
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �134�
Submit�New�Ticket�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �135�
Survey�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �136�
Ticket�Tracking�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �137�
View/Edit�Ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �138�
Class�Structure�Diagram�(Design)��
�
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �139�
State�Machine�Diagrams�(Design)��
Add�User�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �140�
Assign�Ticket�
�
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �141�
Close_resolve_ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �142�
Closed_ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �143�
Email�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �144�
Instant_messaging�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �145�
Knowledge_base�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �146�
Login�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �147�
Management_reporting�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �148�
Submit_new_ticket�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �149�
Survey�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �150�
Survey_complete�
�
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �151�
Survey_form�
��
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �152�
Survey_timer1�
��
���
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �153�
Ticket_tracking�
��
��
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �154�
User�Management�
�
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �155�
View_edit_ticket�
��
����
Help�Desk�Ticketing�System�-�Requirements�Specification.doc� �156�
Appendix������������������������
Appendix�Items�Beyond�This�Page�