In truth, you won't actually need a lot of the things you fantasize you'll need.
from Signal vs Noise

Much of the Requirements Management Tools market (or more broadly the Application Lifecycle Management Tools market) relies on fantasy. People fantasize about things they think they'll need in a tool. They imagine how well their projects will run once they own the tool. They convince themselves to buy the tool. This fantasy is often supported by a the tool vendor's sales team.

I've worked with a lot of companies who have invested in such tools. My experiences have been eerily similar:

When I ask how they're applying the toolset, I'm met with slight embarrassment. They explain how they're not really using the tool to its fullest. Yet. But that they really intend to do better. They think more training or governance might help. They assume their situation is unique - that their peers at other companies are actually using all the features and doing all of the things that they're supposed to do.

Unfortunately, this the norm, not the exception. When building CaseComplete, we took a step back and asked what we really needed in a requirements tool. If we wanted to build a tool that people would actually use, what would it look like? This led us towards a few principles:

• Communicate - Don't Document. The point of gathering requirements is not to produce dry, unreadable documents - the point is to communicate. The tool should make it easier to share ideas - whether on paper, on your computer screen, on an LCD projected for a group, or whatever. The tool should make it easy to communicate what problem you're trying to solve and what the solution will be.
  
• Be Productive Immediately. In reality, most people don't even use a specialized tool for gathering requirements. They use a word processor and a spreadsheet and share these documents amongst themselves.
  
  Getting started with the tool should be as easy as firing up your word processor. You shouldn't have to submit a help desk ticket to get an account. Or get a week of formal training. Or wait for a system administrator to set up a project for you. Like your word processor, you should be able to fire it up and start gathering requirements in minutes.
  
• Capture the right info. The out-of-the-box experience for the tool shouldn't be a blank slate. Nor should it be a rigid template leaving you wondering what information you should populate into a field. The tool should guide you through gathering the right information at the right time. And since gathering requirements involves capturing different pieces of related information, the tool should capture those linkages too.
  
• Requirements Shouldn't Become a Burden. Gathering requirements isn't a matter of writing things down. It's a process of discovery. So we should expect our requirements to be in a state of continuous change. As the amount of requirements that we've captured grows, it shouldn't get harder and harder to change. The tool should make that easy for us - keeping all the linkages and relationships and ordering in place, making it easy for us to see the impact of our changes.

We tried to achieve all of these principles when we built CaseComplete and we're still trying to find ways to make it better. Let us know what you think - and tell us what you really need in a requirements management tool.