I was at an industry talk a week or two ago, and a vendor in the corridor was selling a Requirements Management tool.
The tool in question provided a mechanism to enter, store, and report on product requests. It also allowed web entry of requests directly by customers and prospects via a portal, so the busy PM wouldn't have to enter requests himself. So far as I could tell, or the demo boy could tell me, it didn't do much else.
In the simplest form, requirements management could be just storing and listing requests. I guess. Though that's pretty simple-minded.
An axiom for product managers is that we serve markets, not individuals. We build product that meets the needs of a broad audience. We don't like to build one-offs. We identify groups of people with similar needs in terms of features, delivery channel and so forth, and money to spend, and then go about fulfilling those needs.
So for a product request to be useful to a product definition process, we need to be able to do things with it that are a little more involved than just listing. We may need to decompose into finer grained components of ideas. We definitely need to combine several requests together that may be worded in different ways. We want to identify the group who made that request, and collect the other requests made by group. We probably want to define one or more product features that together satisfy that request, and associate releases with those product features. And so forth.
Capturing, keyword search, and listing are just the barest beginnings, and without the analysis capability are effort for no return. After all, I can capture requests just fine in an email folder.
These thoughts in mind, I asked the demo boy a few simple questions about how his tool would help categorize requests, or trace request (de)composition, or basically support any kind of decision making. He earnestly answered the third question, "Sure, you can do that with our tool! If you see a request come up 2 or 3 times, you probably want to build it in your next sprint."