The Ticket Tracker application provides tracking of defects on a per-project basis. A defect is any change request, such as a bug or a feature request. In this application we call defects as tickets for historical reasons, in reference to trouble tickets used in customer support centers.
A project will require developers to work on many tasks, where each task may be moved through several states. The Ticket Tracker allows developers on each project to keep track of discrete tasks called tickets. It is important to provide powerful search, display, and email notification functions in order to make the system useful in a production setting, where thousands of tickets may be active within the system at any given time.
A user reports a defect via a ticket entry page. They select a project and feature area to classify the defect. Information is filled out in a form, and the ticket is created with a state marked as open. It may be assigned to a default project assignee automatically.
The user may search the database using a Quick Search or Advanced Search form. This is important in order to prevent duplicate defects from being entered multiple times.
A developer logs into the server and views the ticket home page. Based on their default settings, they may be given a list of all tickets assigned to them, or all tickets within a set of projects to which they are assigned.
The developer selects a ticket, and then decides what to do. They can take some action, and then edit or move the ticket to a new state, such as Fixed Awaiting Approval or Need more Information. If they have fixed the ticket and the fix has been verified , they may move it to Closed state.
The developer may link tickets together to group related defects. For example, one coding bug in a application may be responsible for numerous defect reports, and when the bug is fixed, all the related defects should be re-examined and possibly closed.
A project manager can generate reports and summaries of all tickets in a project, sorted or filtered using search criteria.
The ticket system administrator can create new projects or feature areas, edit the list of feature areas for a given project, or close a project which is no longer active. A project is owned by an ACS group, so that some security or filtering can be performed on this property.
10.10.10 Each project has a unique identifier
10.10.20 Each project has a short and long title
10.10.30 Each project has a version
10.10.40 Each project has a creator
10.10.50 Each project has a start and end date
10.10.60 Each project belongs to a user group
10.10.70 A project can be set as viewable only by members of it's owner group
10.10.80 Each project has ticket code set associated with it. A code set is the collection of codes that a Project or set of projects use on their tickets (so for example aD can have a small set suited to small groups and HP can have a large set which reflects their formalized ticket resolution process. These include states for ticket type, status, deverity, priority, source and cause.
10.10.90 Each project has a default display mode
10.10.100 Each project has a message template, which is used to fill in a new ticket entry message text area.
10.10.110 Each project has a list of Feature Areas which are used to organize project tickets into categories.
A Feature Area is simply a category by which tickets can be classified, such as "Customer Support", "Facilities", or "Munich Office".
10.20.10 A Feature Area has a unique title
10.20.20 A Feature Area has a description
10.20.30 A Feature Area has default message template, which is presented to a user when entering a new ticket in that Feature Area.
20.10 Ticket Listing
20.10.10 The user views tickets from a table view which contains summary information about tickets. The tickets shown are drawn from a list which is generated by a current set of filter conditions.
The filter conditions are based on the following orthogonal conditions:
20.10.20 Tickets in the summary listing can be sorted in ascending or descending order using the following criteria. Sorting is allowed on multiple criteria, such as by deadline and then priority.
A particular set of sort and view filter criteria can be saved and named on a per-user basis. This allows custom views to be added, and a customized "home" page for the user to view tickets in the most useful form for their daily work.
20.20.10 Custom Table View A new table view can be created and named for viewing tickets. The table view consists of an ordered list of data fields which the user wants to see listed.
20.20.20 Custom Sort Filter A new sort filter can be created and named for listing the tickets in a table view. The sort order consists of a list of primary, secondary, tertiary, etc columns on which to sort the table of currently viewable tickets.
30.10.10 Each ticket has a unique ID
30.10.20 Each ticket belongs to a single project
30.10.40 Each ticket has a software version string
30.10.50 Each ticket belongs to a Feature Area (also known as domain)
30.10.70 Each ticket has a creator
30.10.110 Each ticket has a one line summary
30.10.120 Each ticket has a free text description, which can be formatted as plain running text, HTML, or preformatted (fixed width font verbatim) text.
30.10.150 A ticket may be submitted via a web browser, in which case the following information will be stored: Browser header info, user IP address
30.10.240 Each ticket has the following state variables, which take on values defined by the code set in effect for the current ticket system configuration.
30.10.300 Ticket Status Change Time/Date Fields
30.10.310 Posting Time
30.10.320 Last Status Change
30.10.330 Closed Date
30.10.340 Closed By
30.10.350 Deadline
30.10.480 Last Modified Date
30.10.490 Last Modifying User
30.10.390 A ticket which is overdue may have periodic "nag" notifications sent to the assignees
30.10.410 A ticket is marked as private to the members of the project's group, or public
30.20.10 A ticket can be edited by an authorized user. A quick-edit mode should be provided whereby common tasks such as moving to a fixed set of states or adding a comment.
A full edit mode must be provided which allows the user to edit any of the data fields.
30.20.20 An audit trail must be maintained which lists the user and date for each data field which is changed on a ticket.
30.30.10 Simple Search A single input text field will be supplied to perform a simple search for tickets. The text entered in the simple search field will be matched against a set of common data fields in a ticket, including the title, message, comments, and creator name. If the search key entered is an integer or integers, then tickets with those id numbers will be shown.
30.30.20 Advanced Search An advanced search option will show a form which allows the user to enter explicit keywords and search choices to match on specific data fields such as ticket status or creation date.
Results presented from the search function will be presented in the main ticket view window, as the results of any other filtering function would be.
Activate / Deactivate Project
Edit Project
50.10.10 Ticket Summary An option to summarize projects will be offered. A summary of the entire ticket database can be made using the folowing options:
Summarize by: project | feature area | submitting user | assigned user
The project summary will list statistics for each project consisting of
50.10.20 Project Summary For a given project or projects, options to generate a summary will be given as
View/Print: Full Report (with comments) | Summary Report (no comments) | Bug Report
The summary will be a single document where all the bugs are listed in a report which makes it easy to get a big picture of what the current defects for a project are.
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 10/09/2000 | Henry Minsky |