I need a Web-based Problem Tracking System for my company. . . .

Objectives

• Use of ubiquitous XML (database record, communication transfer, etc.)
• Good database design for defect tracking/problem reporting. Record locking and data security implemented.
• N-tiered web-based architecture
• Problem states well known; only defined state transitions allowed
• Manages a set of end-users; each user in a user-class (eg., Developer, Manager, Tester). User classes configurable and extensible.
• System implements security based on user-class (ie., what you can do depends on who you are). This needs to be configurable.
• All users are password protected
• Extensible tree of problem/defect categories (every problem in a category). Categories do not need to be known up-front.
• System supports problems that exist across multiple source trees and software releases
• Audit trail kept of all states problem ever has been in
• Ability to automatically communicate state changes via email to interested parties
• Web-based application to create problems and update problems through the workflow process
• Web-based reporting features
  • Problem groupings using a variety of criteria
  • Single problem with audit trail

Data Needs

Extensible Category Tree (traversable, editable); e.g.,

• products/software/languages/java/JDK2/APIs/RMI/Documentation
• products/software/languages/java/JDK2/APIs/RMI/Features
• internal/software/tools/EJB/Specifications/Requirements

State Transition table (problem states and valid transitions); some states to be handled are:

• Submitted (Unassigned)
• UndergoingAnalysis (assigned to someone to analyze)
• Incomplete (not enough info; assigned back to the submitter)
• Analyzed (analysis complete; proposal made (eg., FixIt, TooRisky, ...); includes time estimation, resources required, work-arounds, etc )
• BeingWorkedOn (actively being worked on)
• Fixed (Changed module/document names/versions submitted)
• Integrated (Built into a release)
• Closed (after verification successfully completed)
• Failed (fix failed; reassigned back to person who worked on it)
• Deferred (work on the problem postponed)
• Cancelled (due to error, duplication, ...)

Problem Description (1 per problem). Needs to include at least the following:

• *ID (number automatically assigned)
• Date/Time
• Submitter
• SubmitterInfo (e.g., company)
• Type, including
  • Software Bug
  • Documentation Bug
  • New Feature
  • Ease-Of-Use enhancement
  • Duplicate
  • Error
• Severity, including
  • Critical
  • Major
  • Average
  • Minor
  • Exception (non-conformance to standard)
• Priority, including
  • Resolve Immediately
  • Give High Attention
  • Normal
  • Low Priority
• Status, including
  • Active
  • Inactive
• Synopsis
• Problem Description
• Reproduceable Scenario
• Work-around
• { SendTo }

Supplementary information (1 per Environment/Category/Release problem is in)

• *ID
• *Environment(e.g., OS)
• *Category
• *Release
• Problem State (see States enumerated above) and supplementary info
• ChangeDateTime (Audit maintained)
• ActionPerson
• Resolution
• Estimated time to be spent on this problem
• Actual time spent
• { DocumentType, File/Module, Version }. Changes made to fix this problem.
• { SendTo }

Reporting Capability (screen and printed) to include:

• QueryBy Category, Severity, Environment, Problem#, Date
• QueryBy Status, ActionPerson
• Single Problem (including History)