Requirements Management in TFS: Part 4 (of 4): Summary

Every organization approaches the concept of "requirements" differently.  Factors include general history, skill set, complexity, and agility.  Many development organizations are adopting Team Foundation Server to help improve team communication & collaboration, project control & visibility, and generally a more integrated experience across the various actors in the application lifecycle. 

The more pervasive TFS becomes in an organization, the more I'm asked about managing requirements within the confines if Team System.  Some shops want to know about how to integrate more RM-specific applications into the platform, while others want to leverage TFS as much as possible and wait until Microsoft releases a requirements management solution (I know, I know, Word is the most widely-used requirements tool in the world - but I think you know what I mean by now!).

If you're trying to choose which path to take (TFS-only or a partner integration), here are a few basic considerations:

 

	Benefits	Drawbacks
TFS Only	Affordability (only a TFS CAL is required) Full integration with rest of the application lifecycle (existing infrastructure is leveraged for reporting & visibility) Consistent capture & storage mechanism for all project artifacts.	Lack of specific focus on the analyst role Interface may be a bit "heavy" and counter-intuitive for analysts.
Partner Integrations	Can immediately provide requirements-specific capabilities (rich-text, use case diagramming, etc.) Many can trace/link to work items in TFS, providing end-to-end visibility	Cost (Most partner tools require their own licenses, and each user still requires a TFS CAL from Microsoft.  Maintenance costs may be a factor as well) Additional skill set is required for partner tool

Some requirements-related resources (other links can be found in the various parts of this series):

• Requirements Management on Wikipedia (also see Requirements Engineering)
• Karl Weiger's "Software Requirements" 
• Requirements Template for SharePoint

Well, I hope you at least found this series worth the time it took you to read it.  I welcome any comments and feedback as this topic is always shifting in perception, intention, schools of thought.

Series:

• Part 1:  RM in TFS - Overview
• Part 2:  RM in TFS - Out of the Box
• Part 3:  RM in TFS - Partner Integrations
• Part 4:  RM in TFS - Summary

Comments

• Anonymous
  November 06, 2007
  PingBack from http://blogs.msdn.com/slange/archive/2007/11/06/requirements-management-in-tfs-part-1-of-4-overview.aspx

• Anonymous
  November 07, 2007
  Good BLOG article.  I will pass it onto the BAs and Jacqueline. Here's a little 'Kleinigkeit:' The more pervasive TFS becomes in an organization, the more I'm asked about managing requirements within the confines if Team System. "of" Team System

• Anonymous
  November 09, 2007
  This is great, thank you!  There's not a lot of information out there on this topic.  I showed this series to my director who now plans to move forward with TFS given that we can facilitate some RM inside this tool.

• Anonymous
  January 16, 2008
  Good job Steve!  A recommedations list on the best partner requirements tool would also be helpful.

• Anonymous
  January 28, 2008
  Here's a nice blog series I ran across on requirements management with Team System, Team Foundation Server

• Anonymous
  January 29, 2008
  Steve, Thanks for the exposition - and for leaving out IBM Rational's RequisitePro. We're moving away from Rational since VSTS/TFS does a lot of the same things now and Rational has become "stale". And it has always been too expensive. As a CMMI shop, robust RM is a must. I have been evaluating Optimal Trace and CaliberRM (CaliberRM has better VSTS integration). I was not aware of the others, particularly Rosario, nor of how to be creative with TFS/SharePoint. I will have to give those a spin. Thanks!!

• Anonymous
  January 30, 2008
  This is a very informative article about how TFS fits into this scenario of RM. One more point that should have been highlighted about the workitems is the related workitem concept, where a workitem, say a Task or a Bug, can be traced or tracked back to a specific requirement, say a Requirement workitem. Also you have a related workitem report available readily in both the processes, which goes a long way in aiding Traceability matrix. Hope you appreciate this view as well.

• Anonymous
  February 20, 2008
  Shabariji, Yes, perhaps I should have more explicitly called out related work items.  I alluded to it while discussing the work item tracking approach in part 2, mentioning that different work item types can be related/linked to each other.  But yes, absolutely I appreciate this view, and thank you for briging it up. Regarding the related work item report, yes it goes qutie a ways, but it doesn't necessarily reflect a traceability matrix, which is normally used to identify holes in requirement coverage (i.e. no functional requirement for a corresponding business requirement).  Because of this, I'm a little hesitant to say that the related work item report could act as a "poor man's" traceability matrix; but you're right in that it helps.

• Anonymous
  December 03, 2009
  Thanks for the summary. A traceability matrix from work items with type "Scenario" to linked work items with type "Task" or "Bug" is exactly what I am looking for: For each scenario (requirement) list all related work items in a spreadsheet. Unfortunately the built-in TFS query functionality does not support n:m relationships. So how can I do this?

• Anonymous
  December 03, 2009
  Winrich - Take a look at TFS 2010 (currently in Beta 2).  In 2010 you have the ability query across links, as well as "type" links.  So you can construct a query that shows you all Scenarios as well as any linked Tasks (or perhaps just as importantly, Test Results) in a hierarchical view. Thanks for reading and providing feedback!