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
PingBack from http://blogs.msdn.com/slange/archive/2007/11/06/requirements-management-in-tfs-part-1-of-4-overview.aspx
This is Part 2 of the series, Requirements Management in TFS. For a brief background, please see Part
In Part 2, I discussed how you can begin to manage requirements using the built-in facilities of Team
Every organization approaches the concept of "requirements" differently. Factors include general history,
So you think we can't do this in VSTS? Steve Lange has written an elaborate 4-part series about how you
So you think we can't do this in VSTS? Steve Lange has written an elaborate 4-part series about how
Here's a nice blog series I ran across on requirements management with Team System, Team Foundation Server
Great series !!!
Really really cool work, If i have time I'll like to translate your post to spanish and post them.
(In every new project I have to explain a lot of concepts, and you write them in a very easy/read way)
Bye from Spain
Definitely let me know how your translation goes!
Team System、Team Foundation Server、およびサード パーティ製品による要件管理についての優れたブログのシリーズを見つけましたのでご紹介します。この概要をまとめたホワイトペーパーも現在準備中です。