Question

I'm trying to find a bug tracking solution that fits with IEC 62304 guidelines. Quick summary:

• Bugs reports are called "Problem Reports" (PRs)
• PRs must be evaluated (date and name of evaluator documented)
• One or more PRs can lead to a "Change Request" (CR)
• CR must be closed out and (date and name documented)

I'm having trouble finding bug trackers that allow a completely separate CR document in the workflow. Is this be possible in FogBugz?

Answer 1

To expand on @Michel de Ruiter's answer a bit, the Inbox project is often used to allow customers to report bugs (problems, ideas, etc.) via email. Those cases are looked at and triaged by a customer support person who responds directly to the customer, or decides some other action is needed. If it is decided, likely through consultation with developers, that this is a bug and something needs to be changed, a work-case is created in the appropriate project/area as a sub-case of the initial report. This gives a very clear separation of bug report and change request, and also allows for the time spent on fixing the bug or work spent on the Change Request to be tracked in much more detail

Like Rich said in the comment, the category names (like Bug, Feature, etc.) can easily be changed through the Workflow Plugin to match the specific categories of your workflow, and even added to. So, for example, you could change the "Bug" category to read "Problem Report", and change "Feature" to read "Change Request". This would let you categorize the different cases very easily, and would also make searching/sorting/reporting on those cases very simple using the powerful Search and Filter mechanisms. Additionally, the workflow plugin would let you customize hoe Problem Report and Change Requests flow through the system to some extent if you need more control over things such as the possible resolution states for these categories of cases.

Another way this same paradigm could be achieved is through the use of the Tags feature. This way, you would tag each type of case as either Problem Report or Change Request, however due to the manual-entry aspect of this method, it can be a bit more messy.

Answer 2

Of course it is. This can be organized in several different ways.

One way is to have a project for the problem reports. Evaluators can create related cases in a different project containing the change requests. I think that's how Fog Creek works themselves.