Database Reference
In-Depth Information
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 up-
date 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 com-
munities.
How Do You Fix Things?
With the information you've gathered so far, you can now define some loose require-
ments and break them down by user type so you can have a much clearer understand-
ing 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 require-
ments 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.
