As a Business Analyst with a technical background I am always interested in tools that help both the developers and the overall project. I have been looking at Issue Management Systems for some time now and I have to say that I am impressed with what I have seen so far from the Redmine project (www.redmine.org).
JIRA
A couple of years ago I suggested Australian Atlassian’s (www.atlassian.com) Jira when I was asked to recommend an Issue Management System. The project I have been working on over the last 18 months is also using Jira and I have to admit that I don’t think I will be recommending Jira again. It seems to be too complicated and the business users I have worked with avoid it as much as they can defeating the purpose as a collaboration tool.
Trac, Collaboa & Retrospectiva
The majority of open source projects I follow seem to be using Trac (trac.edgewall.org) or systems which have copied it’s features - like Collaboa (collaboa.org) and Retrospectiva (retrospectiva.org). I like their simplicity, intuitive interface and the integrated wiki. I think Redmine has done an excellent job and with references like phpBB (www.phpbb.com) and most recently TYPO3 (typo3.com) the word is out.
Wish list
From a business analyst point of view I still haven’t come across the perfect system. All the above systems are great tools for programmers, but for those of us who are not on agile projects and who need to document functional requirements are in most cases still stuck with Word documents. To this date I have not come across an open source requirements management tool, let alone one with a tight integration with the source code providing a transparent traceability matrix.
I would like to see the following as part of a system like Redmine;
- functional requirements (Use Cases)
- ability to keep different versions of each functional requirement associated with their respective releases (using the source control’s version tags?) and being able to compare them in a similar way as developers compare versions of source code
- ability to generate a Word/RTF or PDF document with all the Use Cases for a specific release (a lot of organisations have formal sign-off processes). Maybe this could even be managed using customizable ticketing workflows where an authorised person approves a version of a functional requirement to be part of a specific release?
- have a clear view what is deployed in the different environments (Development, Test/QA/UAT, Production) both from a functionality (Use Case) and source code point of view
Looking at these wish list features it doesn’t even seem to be that hard to do, maybe I should find some time and have a crack at creating a Redmine plugin 
I too am a new fan of Red Mine. Other issue trackers add too much complexity. A tool like bugzilla would need a bugzilla expert on the team!
I’m also having the same trouble with redmine as you: how to manage requirements with it.
I agree with parts of your wishlist, though I’m not too enthused by the waterfall style sign-off functionality. What I would add is the ability to decompose a requirement into parts, and to be able to assign these parts to different iterations. Also would it be nice to be able to define iteration length and schedule, so that it could be seen within the gantt charts?
I am not a big fan of the waterfall sign-off process either, my experience with government departments and large private companies is that this is the only way a project will get funded. That’s also the reason that the ideal system should be able to generate a word or pdf document.
The iterations you mentioned could simply be managed with the Roadmap with each roadmap version - because thats actually what a new iteration is - listing what will be part of the release.
Having worked for organisations of various sizes, I agree that while you might not agree with rigid sign-off procedures, you do have to learn to live with them.
In terms of your wish list, and similar to what Eamonn O’Connell suggests above, I’d add the ability to break down use cases into scenarios and be able to indicate the release for each. Simply being able to indicate the release for a use case (for the purpose of generating release specific documents) is not sufficient. It’s often appropriate to implement the primary flows through a use case in the first couple of releases and add new flows from the same use case in later releases. This is especially true in development processes that are moving towards the agile concept but are either not there yet or are modified for corporate environments, i.e. where process audit-ability is very important.
Tooling-wise, I’ve recently tried using Enterprise Architect (from http://www.sparxsystems.eu) with the RaQuest add-in for added requirements functionality and although it can be a little cumbersome, the majority of your wishes are satisfied. Plus the obvious addition of a comprehensive UML2.0 modeling tool. The downside (of course) is that it is not an issue tracking tool but as it is very standards based, perhaps there are add-ins or integrations with other tools in development.
I have used Enterprise Architect on numerous projects and I find it an excellent modeling tool (I didn’t know they had .eu website too, Sparx Systems - http://www.sparxsystems.com.au - is actually an Australian company based near Melbourne).
I guess it all depends on how requirements and use cases are organised. When talking about decomposing a requirement in to parts, you are actually creating requirements of a different level of detail. The need to be able to refer to scenarios within a use case can be seen as the same thing. That was exactly what I meant when I mentioned that there is a need to be able to identify which requirements - including the level of detail - are part of which release.