|
Ticket Tracker Application Requirements
by Henry Minsky (hqm@arsdigita.com)
I. Introduction
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.
II. Vision Statement
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.
III. System/Application Overview
- Create Project
Project Administration
- Create Feature Areas
- Assign Feature Areas To Projects
- Enter Ticket
- Make Assignments
- Display Tickets
- Customizable Sorting and Filtering of tickets
- Search
- Edit Ticket
- Generate Reports
- Email Handling
-
Email alerts when tickets created, assigned, or state is changed
- Handling of tickets submitted or replied to via email
IV. Use-cases and User-scenarios
- Customer/User
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.
- Developer or Customer Support
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.
- Administrator
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.
V.A Data Model Requirements
- 10.10 Project
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.
- 10.20 Feature Areas
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.
V.B Display Requirements
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:
- By creator [me | anyone]
- By assignee [mine | everyone's | unassigned]
- By status [open | deferred | closed | all]
- By creation time [last 24hrs | last week | last month | all]
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.
- ID#
- Priority
- Ticket_Type
- Type
- Submitted date
- Status
- Severity
- Deadline
- Assigned to
- Subject
- Project
- Feature area
- Modified date
- Closed date
- Public?
- Notify?
- Version
- 20.20 Persistent Preferences
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.
- 20.30 Project Summary Pages
V.C Ticket Entry Requirements
- 30.10 Ticket Data Fields
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.
- Ticket Type (e.g., Bug, Task, Enhancement request)
- Priority
- Status
- Severity
- Source (e.g., developer, customer)
- Cause
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 Editing Tickets
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.
V.D Search Requirements
- 30.30 Search
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.
V.E Administrator Interface Requirements
V.F Report Requirements
- 50.10 Report Functions
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
- Project name
- Total defects
- Active defects
- Closed defects
- Deferred defects
- Last Modified date
- Oldest defect
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.
(Optional: Implementation Notes)
VI. Revision History
| Document Revision # |
Action Taken, Notes |
When? |
By Whom? |
| 0.1 |
Creation |
10/09/2000 |
Henry Minsky |
hqm@arsdigita.com
Last modified: $Date: 2001/01/19 21:36:47 $
|
|
|
