There is a bit of irony in building a tool without a tool. It’s like building a table for a workbench so you can then build a table. So far we have been very efficient in our process of building our Requirements Management tool. We have a small team, with white boards and a wiki. What more could you need.
However, as time goes by, the code base grows along with the feature list. Suddenly we have a beta release and realize that our timeline is running short and people other than ourselves are contributing new ideas, adding features, and changing others. I woke up one morning and realized that my ever increasing anxiety was the fact that as our application grew my ability to keep track of it all shrunk. One answer of course is a tool, but what I found interesting was that, for me, the event that marked this need was not necessarily the requirements themselves but the management of what requirements were where, in other words, releases.
Alan M. Davis mentions in his book Just Enough Requirements Management the importance of being able to see a quick list of the requirements based on a set of specified annotations, such as release, status, priority, owner etc.