There are several schools of thought on how to "do RM" ranging from the very lightweight (whiteboards, sticky notes, cocktail napkins, etc) to the robust (formal elicitation, authoring, validation and management of specifications). Chances are your organization falls somewhere in between.
Past dictates future (thanks, Dr. Phil), and the same applies in how teams approach requirements management. Basically, if you're used to managing your requirements using Word documents (and believe me, you're in the majority), most likely that's what you figure to do when starting a new project.
The historically mainstream ways to manage requirements (Word, Excel, email) can be efficient (people know the tools, and again, it's how it's been done before) and satisfactory. But with the application development projects of today becoming increasingly complex and distributed (both architecture and project teams), this process becomes more difficult to manage. Throw in your regulation/compliance package-of-the-day and you quickly realize you need more. Key capabilities around collaboration, audit/history, and traceability rise to the top of the priority list.
As a result, the idea of managing requirements as individual elements (rather than parts of a larger specification document) is becoming increasingly popular.
I hear this quite often: "How does Team System support Requirements Management?" Visual Studio Team System, or more specifically Team Foundation Server, possesses the plumbing needed for the above-mentioned capabilities out of the box as part of its inherent architecture. TFS provides work item tracking to allow items (bugs, tasks, or in this case, requirements) to be treated as individually managed objects with their own workflows, attributes, and traceability. However, while the infrastructure is there, TFS wasn't designed specifically to support a requirements management process.
But if you are looking at Team Foundation Server to manage your development process, I would suggest that you take a peek at how it can be used to support your business analysts from a requirements management perspective as well. Again, although it's not specifically targeted at business analysts (it is on the radar (see: Team System Futures, however) there many of the capabilities of TFS can help support a productive RM process.
This series will take a look at a few different ways that TFS can support requirements management. In Part 2 I'll show a couple of ways to do this using TFS "natively" (without any add-ins/plug-ins); and in Part 3 I'll briefly discuss some 3rd party solutions that support requirements more directly yet still integrate with Team System. And we'll close the loop in Part 4 with a summary.
Next: TFS - Out of the Box