Bugzilla for requirements management

[ASTDan]

I have an idea

I was wondering if anyone has used Bugzilla http://www.bugzilla.org/

In addition to managing bugs, could you use this tool to track requirements? You could tag each requirement as a "bug" and track when it was completed, and by whom.

Would using this method satisfy traceability requirements in regulated industries (i.e. FDA)

Dan

[PaulG.]

I liked Bugzilla, but haven't used it in a while. And we only tracked bugs with it.

I don't see any problem tracking requirements with it. And if you have a traceable document that describes how you track requirements with Bugzilla I don't see any problems with regulated industries, either. Sounds like a plan.

[jcarmody]

I was wondering if anyone has used Bugzilla http://www.bugzilla.org/

In addition to managing bugs, could you use this tool to track requirements? You could tag each requirement as a "bug" and track when it was completed, and by whom.

I had a discussion on NI's forum (during the LAVA outage) here, where managing requirements this way was mentioned; you're not the only one. I dunno about traceability.

[Black Pearl]

I do it with mantis (there is not much of a difference) and if you just need to track who is going to take care about it and who did implement/fix it, then a bug tracker is doing the job.

For mantis, I have a SQL database behind that takes note of every change, so preserving the history of each 'bug'.

I propably was the virtual person (vp) that braught it up on the NI forum, but it was introduced to me on LAVA on this thread

Felix

[crelf]

Would using this method satisfy traceability requirements in regulated industries (i.e. FDA)

I'm not an expert, but I don't think so. You need the requirements traceability tool to be developed using an accredited ISO process, otherwise you can't proove that it works properly, which means that you can't proove that the traceability artifacts produced by it for your project are accurate.

[jzoller]

Company policy forbids me from really commenting on this in a public forum (nor am I an expert), but check out http://www.fda.gov/downloads/RegulatoryInformation/Guidances/UCM124721.pdf as a starting point in the US.

Joe Z.

[ASTDan]

I'm not an expert, but I don't think so. You need the requirements traceability tool to be developed using an accredited ISO process, otherwise you can't proove that it works properly, which means that you can't proove that the traceability artifacts produced by it for your project are accurate.

This is a little off on a tangent, but if you use subversion for you SCC because it is open source and not developed using an accredited ISO process would that cause problems?

[PaulL]

I found the idea of using a bug tracker for requirements management intriguing. Mind you, my first inclination was that it wasn't a good idea, but I decided to try and figure out what the advantages and disadvantages were.

A couple issues came to mind.

1) It may be possible to establish some sort of traceability in certain issue tracking tools if you can link issues to one another. (We can do this in the issue tracker we use, JIRA). On the other hand, this is not document-centric and thus it would be difficult, if not impossible, to generate a report indicating which requirements one has linked to design, or to a test plan, or to test results, or to code.

2) While some level of hierarchy is also possible (JIRA lets the user define subtasks) simply entering issues does not allow the issue tracker to present the requirements in a single structured document (especially if one adds or removes requirements later!).

In short, I would recommend using a requirements management tool designed for the job (DOORS, Requirements Gateway, traceability within Enterprise Architect), which I think one will need for a project of any significant complexity. Traceability is demanding to do even with the right tools for the job!

Paul

[crelf]

This is a little off on a tangent, but if you use subversion for you SCC because it is open source and not developed using an accredited ISO process would that cause problems?

That's a good question - I suppose it would depend on what you were trying to prove to the regulatory body. If you're showing that you used SCC then you're probably ok, if you were using it for a configuration management traceability record the I'm not so sure...

In short, I would recommend using a requirements management tool designed for the job (DOORS, Requirements Gateway, traceability within Enterprise Architect)...

Real quick note: Requirements Gateway isn't a requirement management tool - it's a requirement traceability tool. I RG, and we use it here, but it doesn't manage your requirements, it traces them. Jeff will be uploading his NI-Week presentation soon which will explain that a little further, and how to include it into your process.

[PaulL]

Real quick note: Requirements Gateway isn't a requirement management tool - it's a requirement traceability tool. I RG, and we use it here, but it doesn't manage your requirements, it traces them. Jeff will be uploading his NI-Week presentation soon which will explain that a little further, and how to include it into your process.

Yes, Chris, I glossed over the important distinction that one doesn't, for instance, write requirements in NIRG. One imports requirements into NIRG to facilitate traceability and generate reports based on the links one establishes. Thanks for catching me!

(Note that it is possible to keep the NIRG file in a project and under version control.)

All,

Maybe it will help the discussion to include one expert's definition of requirements management in order to evaluate whatever tool or methodology you are considering: "The central purpose of requirements management is to manage changes to a set of agreed-upon requirements that have been committed to a specific product release. Requirements management also includes tracking the status of individual requirements and tracing requirements both backward to their origins and forward into design elements, code modules, and tests" (Karl Wiegers, More About Software Requirements, Microsoft Press, 2006, pp. 7-8).

By the way, I attended Jeff's NI Week presentation and I highly recommend downloading it if you weren't there. Really good stuff!

Paul

[Matthew Zaleski]

I have an idea

I was wondering if anyone has used Bugzilla http://www.bugzilla.org/

In addition to managing bugs, could you use this tool to track requirements? You could tag each requirement as a "bug" and track when it was completed, and by whom.

Would using this method satisfy traceability requirements in regulated industries (i.e. FDA)

Dan

Essentially, this is how MKS Integrity implemented their Requirements Solution. Integrity allows multiple issue types, each with their own list of fields and states they move through, AND they can link from one issue type to another. I'm getting ready to add the Requirements Management Solution to my MKS Integrity installation. The whole package ain't cheap but I've yet to find a freebie solution that comes close to its power. I think the MKS website itself is a piece of **** though.

It has all the hooks for building Requirement Documents from all the little Requirements and reusing Requirements from previous projects.

Edited August 28, 2009 by Matthew Zaleski