views:

222

answers:

7

Imagine I place each requirement as a feature on my bugtracker. Would it be a nice idea? Are there better tools?

+5  A: 

This is what I, and a lot of people do. Put the specifications in as bugs, and then resolve the bugs when they are complete features.

Its a great way of assessing the relative priority of resolving bugs vs adding new features. In a way, an empty project has got a lot of bugs, because it doesn't do anything!

jgubby
+1  A: 

Bugtracking is all about closing entries. Product/requirement management is about keeping them alive.

BTW - some bug tracking systems support requirement management, but this is not the same.

agsamek
+5  A: 

I would say it's definitely a good idea, because you can easily track back later how the requirements and ideas envolved. You can also easily track your progress, time estimates, spent time etc.

Pozsár Balázs
+1  A: 

In general I think using a tracking system like this for managing a project works very well.

The important part is that you want to put actionable items in your database - just listing the requirements isn't going to help if that requirement doesn't translate directly to the code/high level design you want to be implemented. So, for a requirement I might enter an issue to decompose the requirement into features, spawning new records for implementing the features.

JeffP
+2  A: 

We do this - We transfer the Work Breakdown Structure (WBS) developed from the Marketing Requirements Document(MRD) into the bug tracker. We are then able to track/monitor progress on individual work items. the downside is that you have potentially the requirements definitions in two places, but for a small team like ours it hasn't been a problem.

We tried one time to only track in bug tracker but we found it hard to reconstitute the complete document when we needed to hand it to external users and or non technical users.

MikeJ
Just for those who doesn't know : WBS is http://en.wikipedia.org/wiki/Work_breakdown_structure and MRD is http://en.wikipedia.org/wiki/Marketing_Requirements_Document
Jader Dias
yeah. my bad. I will update and fix.
MikeJ
+2  A: 

It depends how complex your requirements tracking requirements are likely to be. A full requirements tracking system will support sub-requirements to many level and possible integration with other project management tools. If the project is simple and so your needs are less complex then you could easily use a bug tracker instead.

David Spillett
A: 

Bug Tracker is for defects, including documents. Tracking defects in your requirements documents is just as important if not more important to tracking defects in software. The earlier you find the defects the cheaper it is.

For initial functional requirements, I would just generate a separate tracker like a shopping list. As they are incorporated in the list, check off the item.

I apologize for the inital soapbox but a lot of people forget documents can have defects too, not just software.

mcauthorn

related questions