How do bugs get into the system? Users or developers submit them, as email or html submissions; either might be enhanced by automatic bug-template generating tools. (As Tait19991 suggests, if submitting bug reports is not simple and familiar, the system will be ineffective.)
What is in a report?
Submitter :
Package :
Other paths include a "real time" support client like Athena's olc. (In that context, all we get is Submitter and Complaint, though there is sometimes category information, and the handler "pulls" for more.) The important thing is that any path make some attempt to identify the meaning of as much of the report as possible, in order to later use those fields effectively; this may mean implementing new input models in response to new technologies (such as stretching this to be a call tracking system.)
Everyone wants their bugs fixed now; the importance of the bug to the user is "interesting" but not inherent. Likewise the priority and work-ordering the developer does is an aspect of resource management, guided by but not inherent in the bug. Something like "work on high priority bugs, then old bugs, then wishlist ones" is a policy choice, and an allocation of developer resources (a newbie might be asked to "go look at the wishlist bugs, pick three you think you can fix, lock them, do it, and come back for auditing later.")
A significant part of keeping the user involved is to make sure they are informed of changes and progress. This means that capturing contact information is one of the most important parts of the initial report; even without a complaint, someone can contact the user to find out what is wrong (by analogy, calling 911 and failing to communicate typically leads to a return phone call, and possibly a visit.)
Once a report has arrived in the systems, various things can happen to it.
Many more things will show up in reaction to Real Users, so adaptability and modularity are important here, possibly at the expense of performance (though not of scalability.) In fact, Tait19991 mentions that there are many distinct support and release process models, and that the system should be able to accommodate them. This implies that perhaps a high level description of the support process could be used directly to configure the system, rather than simply leaving it "loose," so as to allow the system to better guide the process and avoid process-related failures.
Tait19991 also points out that bugs can be processed through other systems, and that shouldn't cause them to get lost. While one bug system need not duplicate the progress in another, a generic linking mechanism would probably be a useful common process model element.
The system should be able to answer various questions, both from users and developers.
The process model itself may lead directly to some particular kinds of reports, such as statistics on time between particular states.
We may want to keep a history to learn from.
A collection of projects exists. Resources get assigned to them. Projects can be "stuck" on dependencies; it should be possible to walk this graph and find effective places to put resources.
Since this "popped out" of the requirements, lets focus a little more analysis on it...
Name :
owner? :
value? :
priority? :
dependency on other Projects (and Resources?) :
name :
cost?
A Highly Configurable Software Bug Tracking System, Feb. 1999, MIT M. Eng Thesis, Calista Tait. ↩