by Tony Tseng, Phong Nguyen 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. ACS Workflow 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 tony@arsdigita.com Last modified: $Id: requirements.xml,v 1.1.1.1 2001/04/20 20:51:25 donb Exp $