WHAT IS NOT RM
I will start out with explaining some properties of Requirements Management because I all too often am in situations where people think they are doing some kind of Requirements Management using Sharepoint, documents, spreadsheets and are doing all kinds of stuff but basically have no clue what Requirements are and have no clue what Requirements MANAGEMENT is.
Requirements Management is not a process area you make up or where you invent yourself how you are going to do it. It is defined. There are pre reqs and there are ISO standards. All in all it should minimal align with the goals and thus requirements as e.g. mentioned in CMMI (http://en.wikipedia.org/wiki/Process_area_(CMMI) and click REQM and RM). If you are not confirming to being able to do bidirectional tracability you are not doing RM but e.g. making "documents where some requirements are somewhere INSIDE". So you are probably doing designs but you are definitely not doing any requirements management.
Requirements Management is not about the content but being able to MANAGE the changes. So e.g. be able to do impact analysis effortlessly due to tracebility throughout the chain etc...
WHAT ARE REQUIREMENTS
requirements are traceability items. Thus meaning everything that you can TRACE to something else. If you specify multiple houses that have multiple persons inside them living and you have a lot of them then "abcstreet 5" is a requirement and "person John" is another requirement. Again these are not documents but atomic items with some properties.
if you collect stamps and you have thousands of them you start by sorting them e.g. by country. With requirements you start by making requirement types and then make relations between the requirement types. This Requirement Type Traceability Model you can place in your Requirements Management Plan (ISO template).
There are many ways to model this but one is to split requirements in use cases on the one hand for all functional stuff and architectural decisions on the other hand for all non functional stuff. The use cases go to the software developers and the non functionals to the operational guys who can start making their designs based on it. If there are extra functional and non functional asides use cases you can define an additional type (with the exception of SOA). Example Requirement Types (from top to bottom): business driver, business goal, business use case, use case, architectural decision, business scenario. Again these are not documents.
Requirements have attributes thus e.g. priority or state or even owner. Thus for all these individual requirements you can see the state e.g. "proposed". Hundreds of attributes are possible here. With this you empower your Requirements approach. You can also think of attributes that hold the list of RFC's and Defects that were related to it...
Requirements have history and can be versioned. So you have control on who changed what when.
The Requirement TYPES traceability leads to traceability on requirements. Some which you specicify as required and others than can be implemented when needed. With this you enable doing Requirements Management: if e.g. one non functional requirement changes (someone changes "within 10ms" to "within 5ms" you know 2 things: a) that someone changed it and thus this better be as a result of an official change b) all related requirements that are impacted (because of the traceability) it makes it a breeze to do impact analysis in this way: you see immediately what potentially changes. For example: that single non functional change leads to 2 use case (steps) changes, 1 screen that changes (also defined as requirement type) and 1 documentation help part that changes. You then ask these persons how long it takes them and you have your impact. But more importantly: it helps you control this process and govern the process of all these little changes. Also for bugs: you can pinpoint which requirements were impacted and thus get a feeling for metrics on which part of the requirement most bugs occur.
Requirements and Modeling are layered: you do business requirements, then the busines model, you do use case requirements, then drag them to your modeling tool, do modeling, then do deeper technical requirements then drag these back to do technical modeling etc... So you NEED to be able to trace individual requirements to model parts to keep being able to have full traceablity.
some requirements have a relation to *requirements document*s e.g. a use case requirement (consisting of a hierarchy of requirements e.g. use case steps and alternative flow steps) related to a Use Case document. There is probably a lot more in that document but these are the requirements you trace to and want to manage.
Designs are OPTIONAl. If you set up the correct Requirements Model you can choose to have no designs. You will only have Requirements and listings of requirements. Use Cases will lead to more technical requirements deeper down in the hierarchy e.g. 1 use case req leads to 7 screen req with 5 applets req on it. If you want to put that in a document to distrubute around, fine. This also more helpful for testers: they can link their testcases and do some automated testing instead of "here you have a design base you testcase on it".
Other requirements have NO documents associated. Maybe you get a list of non functionals initially as a company standard and decide to enter them as individual requirements and maitain and extend them individually another example are a glossary and terms. You can obviously generate report out of it to list them all in a doc but the other way around "getting them from the doc" means you need to maintain the doc instead of the requirements in the first place. Double work.
To be able to manage the whole chain you need reports. So your tooling needs to be able to produce a lot of reports out of the box and some kind of handy reporting tool. Furthermore it obviously needs a integreated database behind the requirements/change/etc tooling so that you are able to say e.g. "how many high priority items have not been finished yet" or "what is planned versus actuals" etc...
Your question in broad but in general I read: traceability over the full lifecycle so from business decision to architecture to analysis to design to modeling to build to test to production. 3 people above mentioned Rational / Doors for Requirements Management.
I think you would need at a minimum such a thing for doing the requirements management. You do not ask for a ticketing system though you do need one integrated with all of this since you need to setup the traceability from the tickets, hotfixes, RFCs, defects, questions, etc.. etc.. to your requirements to manage scope and to have overall reporting.
Since Doors was mentioned 3 times take a look at http://jazz.net : it is a more or less integrated suite for a lot of these things and do some googling on it on the web. You will see Rational Requirements Composer in relation to the future of Doors: http://jazz.net/projects/rational-requirements-composer/
(Rational always had RequisitePro, then they bought Telelogic so now own the #1 and #2 solution in terms of marketshare, the Jazz platform is the new move, could compare it to Microsofts move to .NET : new platform, new technology and according to gartner/forrester the only solution that leads the way).
If you go for this I would advise to also include RTC: RTC = version management, change management, build management etc... all-in-one and also plugs in the Jazz layer. (its free for 10 users, no need to install, just click start on the server, start on the client and there you go to test it). (also a lot of reporting in it).
So for the tooling question: take a good look at Jazz and read up on the articles on there, also check for independent reviews on IT sites on it. RTC is a free download for up to 10 users (and e.g. syncs with svn/git/etc not your question just mention it).
"Being able to define requirements and track their changes over time (i.e. how is version 1.5 different than 1.0?)"
You toch 2 different process area here: 1 is requirements management that lets you have traceability over requirements. The other is configuration management where one of the basics is to include requirements in each baseline. By combining both you get your requirement. And yes: that is possible in the above solution. If you just want to look at individual requirement it is ofcourse just right mouse click to walk along the versions. If you want to compare greater sets e.g. domains or even a complete release you use a baseline comparion on the requirements and output that.
Probably if you write some custom reporting on it (remember you have a database behind it so you can do basically anything in your wildest dreams) you can even do more like specifying also "only interesting ones because of..."
Being able to collaborate with other project managers and the team when putting together the specifications
tools support several layers of that.
In the first place, since you have indidividual requirements you can open discussions traced to one requirement or a set and maintain the discussions on it instead of having to collect each individual mailbox afterwards to learn about he non trivial decision.
For project managers I dont think you want to micro manage each individual requirement change. I think the reports from the Collaborative Application Lifecycle Management tool should provide you with the issues to focus on e.g. the top 5 requirement parts scheduled next and which are way behind. (so in the case of Jazz this is the RTC part).
Probably a lot