The ticket tracker is a general purpose tool for managing and resolving issues.
The following is a requirement document for the ticket tracker package.
The ticket tracker is designed to let people work collaboratively on tasks. A ticket represents a task that needs to be done, such as fixing a broken computer or buying more food. In order to fulfill its purpose, the ticket tracker must ensure that the right person is notified promptly of all requests and that the interested parties can continuously monitor the progress.
All tickets are archived so that users are able to view past ticket history. Additionally, users can analyze the performance of the ticket tracker so that they are able to spot bottlenecks, find overdue tasks, etc.
A ticket tracker is composed of categories that group tickets together. For example, if a ticket tracker is used for city planning, then the categories can be "irrigation," "transportation," "crime control," etc. Or, if a ticket tracker is simply used to keep the men's restroom clean, then the categories might be "stall A", "stall B", "stall C", etc. In other words, categories are used to classify tickets.
The ticket tracker consists of two parts:
End user interface: users can
enter new tickets
view individual ticket details
interact with tickets that they are involved with (e.g., clarify ticket description)
view summary of tickets by different criteria
Admin interface: administrators can
add new categories
edit existing categories
edit priority/severity options
specify default assignees for categories
The ticket tracker uses the permission system to determine:
Who can view tickets
Who can edit tickets
Who can assign tickets
Who can administer categories
Site administrators can and probably should create multiple ticket trackers. For example, in a typical website, users might create a hierarchy of ticket trackers like this:
Main Site ticket tracker
|
+-- Customer Service ticket tracker
+-- Office Administration ticket tracker
|
+-- Noise ticket tracker
+-- Storage ticket tracker
Creating a ticket tracker:
Adam Smith finds the conditions of the office kitchen unacceptable. He goes to the ACS Administration page and creates a new ticket tracker for the purpose of keeping the kitchen clean. In order to classify tickets, he also creates three categories: "floor," "sink," and "counter." Since the interns in the office are not doing anything, Adam designates them to be the default assignees of the categories. Thus when a new ticket is entered, the interns are notified immediately via email and, hopefully, will attempt to clean up the mess in the kitchen.
Entering new tickets:
Nancy Nerd is hungry. She goes to the refrigerator and sees that it's empty. She then goes to the food supply ticket tracker to open a ticket for people to buy food. Eric Errand-boy immediately receives an email about the incoming ticket and goes to the supermarket. Once he's filled the refrigerator with the food, he marks the ticket as "finished". Nancy then gets an email saying food has been bought, and she goes to the refrigerator again, only to discover that her favorite food, Celeste Frozen Pizza, wasn't on Eric's shopping list. She goes back and rejects Eric's proclaimed fix, so Eric gets emailed again. He buys the pizza, returns, and once again hits "done". This time, Nancy heats up a pizza, and while the pizza is in the microwave, she acknowledges Eric's fix and closes the ticket.
Viewing summary:
Joe Allocator has two new hires. The project he is currently managing has five different feature areas, and he is not sure which feature area he should assign the newbies to work on. He opens up the project-management ticket tracker and goes to the summary page. It lists the total number of tickets, number of tickets outstanding, number of tickets suspended, and number of tickets closed from each feature area. Based on this information, Joe is able to decide the allocation of his new employees.
Searching through tickets:
Alisa P. Hacker finds the vending machine in the office broken. She wants to enter a ticket for it, but she is not sure if somebody else has filed one already. Being a courteous person, Alisa does not want to enter duplicate tickets. Rather than running around the office and asking every one of her officemates about it, she decides to use the search feature. She enters "vending machine" as the search string, and the ticket tracker immediately returns 10 entries. Sorting them by date, she then discovers a ticket for the same issue has just been entered five minutes earlier.
0.0 Speed - Performance is the major drawback for the 3.x ticket tracker. Should make sure each page in the 4.x ticket tracker would load at a decent speed, especially the index page.
0.10 Portability - Use as much PL/SQL as possible to improve portability to ACS Java.
Tickets
10.0 Tickets have the following information:
subject
detailed description (may be in either plain text or HTML)
priority in integer (how important this issue is)
severity in integer (how bad the symptoms/effects of the issue are)
the category this ticket belongs to
Categories
10.10 Categories have the following information:
name
optionally, a detailed description
optionally, the default assignees for this feature area (i.e., when a new ticket is entered for this category, it'll be automatically assigned to them)
the ticket tracker instance this category belongs to
Priority/Severity Options
10.20 There should a mapping table dealing with the priority/severity options. It shall contain the name-value pair for each priority and severity option.
10.30 The term "Category" is customizable. For example, instead of calling it "Category", users can name it "Feature Area" or "Floor Number".
20.0 User Basics
20.0.0 Users shall be able to see a summary of their tickets across multiple instances of the ticket tracker. The instances we use depend on the mount points in the site map.
20.0.10 Users shall be able to add new tickets into the ticket tracker.
20.0.20 Users shall be able to interact with the tickets they are involved with. (e.g., users can mark tickets assigned to them as fixed; users can clarify tickets that need their clarification)
20.0.30 Users shall be notified by email whenever the status of a ticket with which they are involved changes.
20.0.40 Users shall be able to add comments to a ticket.
20.1 Ticket Overview
20.1.0 By default, the interface displays a list of tasks that users need to do. The tasks are:
resolve ticket
clarify description
assign ticket
verify result
20.1.20 Users have the option to see:
Tickets submitted by them
Tickets assigned to them
All tickets
20.1.10 The list of tickets can be sorted by ticket attributes such as date or priority.
20.2 Summary
20.2.0 The summary includes the following information for each category:
number of total tickets
number of unassigned tickets
number of outstanding tickets
number of total suspended tickets
number of resolved tickets
20.3 Individual Ticket View
20.3.0 Displays the following information:
subject
description
priority
severity
the ticket's current status
the ticket's previous states in the process
users associated with the ticket
the category this ticket belongs to
20.4 Search
20.4.0 User shall be able to search for tickets by entering a search string. All tickets in the current ticket tracker containing the search string within either subject or detailed description should be shown.
20.4.10 The returned list of tickets should be sortable by the ticket attributes.
30.0 Admin Basics
30.0.0 Administrators shall be able to add new categories
30.0.10 Administrators shall be able to edit existing categories
30.0.20 Administrators shall be able to specify the default assignees for categories
30.0.30 Administrators shall be able to change the state of any ticket in the ticket tracker process (e.g., moving a ticket from "closed" to "open")
40.0 Advanced search.
40.10 Customized ticket tracker workflow.
40.20 The capability to move tickets from one ticket tracker to another.
40.30 Users shall be able to turn off email notification.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 11/11/2000 | Tony Tseng |
| 0.2 | Revision | 11/16/2000 | Tony Tseng |
| 0.3 | Revision | 12/16/2000 | Tony Tseng |
Last modified: $Id: dev-guide.html,v 1.1 2001/04/20 20:51:25 donb Exp $