Databases Reference
In-Depth Information
A Broken System
In general, the users of help-desk systems can be categorized into two groups: people who log problems (end users)
and people who help solve the problems (technicians). Depending on which user community you fall into, it's likely
you have different needs, but overall, the system should help the end users and the technicians communicate about
the problem or issue.
The first step is to understand how your help desk is being managed today and why it's not working. Speaking
to both the technicians and the end users can provide a huge amount of information, but the challenge is that this
information usually comes in the form of complaints about the current system.
Quizzing the end users reveals that their main complaint is that they never know the status of the problems
they've logged. They can go days, sometimes weeks, without communication from the technicians, and in the eyes of
the users, no communication means no one is working on their problems. Another user complaint is that the
help-desk technicians often don't know how to contact them to ask further questions or communicate progress.
On the other end of the issue, the technicians are overloaded. Ticket information is kept in an Excel spreadsheet.
Originally, the help desk was only one person, but now there are several technicians working independently. While
performing their daily duties, each needs to update the spreadsheet with information regarding the tickets assigned to
them. The increasing number of people accessing a single spreadsheet causes problems, because only one person can
open and update the spreadsheet at any given time. The technicians are also tired of constantly being called by users
wanting an update on the status of their issues.
It's obvious that the system is broken. Neither the users nor the technicians are happy about the situation. It's
your job to take the information you've gleaned from these conversations and design something that will address the
needs of both user communities.
How Do You Fix Things?
With the information you've gathered so far, you can now define some loose requirements and break them down
by user type so you can have a much clearer understanding of what each community needs. Then, from those
requirements, you can begin to think about the database design that you'll need to create in support of them.
Defining the Requirements
You can look at requirements from two perspectives. End users have one set of requirements and technicians another.
Some requirements overlap between the two groups. Others are unique to one group or the other.
End users should be able to
•
Create a new ticket outlining their problem.
•
See the status and progress of tickets.
Technicians should be able to
•
Easily identify and view new tickets.
•
Easily identify which tickets are directly assigned to them.
•
Search existing tickets.
•
Create new tickets on behalf of an end user.
•
Assign tickets to other technicians.
•
Add details (comments, information, and attachments) to tickets.
•
Update the status of a ticket.
