All of the above is very true and well put, but I'd like to expand upon the following:

When starting out, 'requirements management' can seem a little nebulous.  Basically you want to ensure that when you are documenting your requirements that they can easily be referenced by other documents (ie. using unique identifiers for each requirement, proper classification, etc.).  You also want to ensure that you link the requirements to the next deliverable in your software development chain (use cases, software specifications, feature descriptions, etc.).  As development occurs, you should then link the requirements to specific test plans and test cases, to ensure that what has been built meets up with what your clients said they wanted.  This is where more sophisticated integrated software tools can be helpful when you're in a large enterprise, but it's not absolutely necessary.  Just make sure you have proper control over your master requirements file (with version control, locking, etc.) and that you develop appropriate traceability matrices to map requirements throughout the development cycle.

Depending on your role, you may want to expand this mindset further to manage items such as the issue log, business rules, business processes (current and future state), etc.  What I've done is set up a 'Central Registry' file that contains all this information in tabular format.  Then when I need to develop a specific document I use the information in the registry as needed to bulid it, and refer to the items when appropriate.  For example, when building a use case, I will write the narrative and refer to the identifier/title of the business rules that impact the use case, any issues outstanding that surround the use case, which requirements are tied to this use case, etc.  This makes it clear what impacts the development of a solution surrounding that use case.