Requirements Management in TFS: Part 2 (of 4): TFS Out of the Box

This is Part 2 of the series, Requirements Management in TFS.  For a brief background, please see Part 1: Overview.

In this part, we'll discuss a couple of the primary ways to support requirements in Team Foundation Server: the Team Portal and Work Item Tracking

Team Portal (SharePoint)

If you use some kind of document format for authoring and tracking your specifications (Word, PDF, etc.), you may already be using something like a SharePoint site to store them.  Or some kind of repository, even if it's a network share somewhere.  Team Foundation Server creates SharePoint-based (specifically Windows SharePoint Services) web portals automatically when you create a new project.  These portals provide an easy, web-based way for interested parties to "check-in" on a project's status, participate in discussions, post announcements, view process guidance documentation, and submit supporting documents and files to a document library.

It's the document library that provides a natural fit for bringing your specifications a little more in line with the rest of the application lifecycle.  The document library allows analysts to remain in their comfort application (i.e. Word), but submit changes to requirements to a location that is much more accessible to those that will consume those requirements (architects, developers, testers, etc.).  Team Foundation Server users can access the document library from within Visual Studio Team System, TFS Web Access or other interfaces, thereby allowing them to more readily react to new changes and provide feedback as necessary. 

And now that the requirements documents are in the document library and managed (indirectly) by TFS, you can easily leverage the linking capabilities of TFS to add traceability between your specifications and source code, defects, tasks, and test results.  (How do you link work items to items in the document library?  Work items can be linked to hyperlinks, so you can simply link to the URL of the specific file in the document library in SharePoint.)  This adds some real tangibility to your reporting in that you can now view reports from TFS that, for example, show all development tasks and their related requirements spec, changed source code, and validated test results.

Easy, right?  Well, yes and no.  There are some definite drawbacks to this approach (I'm leaving it up to you to decide if the good outweighs the bad), the primary being that you still don't have any more granular control over individual requirements changes than you did before.  Changes are still tracked, and linked, at the document level.  This can be challenging if you need to track changes to individual requirements (change tracking in Word will only take you so far) for auditing and compliance reasons.

Benefits	Drawbacks
Analysts remain in comfort application (Word, etc.) SharePoint is a "natural" extension in Word/Office applications Requirement specs more easily consumed by other roles in lifecycle. Provides basic mechanism to enable traceability and better "cross-artifact" reporting.	Lack of item-level granularity. Document-level linking only (can't link to an individual requirement inside specification document) Document Workflow managed by SharePoint, whereas Workflow for other lifecycle artifacts are managed by TFS.

Work Item Tracking

Team Foundation Server's work item tracking feature is a major moving part of the system.  Work Item Tracking (WIT) provides a robust yet flexible way to track any item of record throughout a lifecycle.  Some work item types provided with TFS include: bug, task, risk, scenario, or (to the point of this article) requirement. Work items are managed in the TFS database alongside code, builds, test results, etc, and provide a proper level of granularity for controlling change and traceability.

In the previous example, using the SharePoint project portal lacked the ability to control changes to individual requirements, nor did it allow linking to those individual elements.  Leveraging WIT in TFS addresses both of these shortcomings.  You can create and customize your own types of work items, allowing teams to have complete control over what types of work items are used, their fields, workflow, and even UI.  Say for example, your team typically leverages three types of requirements: Business, Functional, and Non-Functional.  TFS allows you to create custom work item types that represent each of these categories of requirements.

Now that your requirements are managed as work items in TFS, you can take advantage of all the benefits of the work item tracking system (see benefits below)

Requirements work items are accessed in the exact same manner as any other work item:

• Via Team Explorer (either embedded in Visual Studio or as a standalone client)
• Via TFS Web Access
• Via Excel & Project

Since work items are primarily access by way of queries in Team Explorer, teams can easily filter what requirements are displayed and accessed at certain points.

Reporting gets a considerable leg up using the work item tracking approach.

The biggest challenge with this approach (in my opinion) is the shift in mindset.  In case you didn't notice, I haven't mentioned using Word in this section.  WIT gets more granular than Word does for managing item-level changes, and there is not currently a Microsoft-provided integration to Word from TFS.  There is often considerable resistance to change in that, "without the document, what will we do?"

Benefits

Drawbacks

All changes will be recorded and audited Links can be created between individual requirements and other work items (any type), source code, test results, and hyperlinks) Workflow is enforced and controlled in the same manner as all other work item types Supporting information (screenshots, documents, UML diagrams, etc.) can be attached Reporting can be much more granular (showing requirement implementation rates, impact analysis, scope creep).

Change of interface may meet resistance (i.e. no more Word!) Customization work most likely involved (creating custom work item types, fields, & workflow).

Getting Into the Code

And lastly, if you're really into it, you can tap the Team Foundation Server SDK to get really creative.  For example, you can write a custom lightweight interface for business analysts to enter and track requirements work items in TFS.  Or create a custom report (although you might be better off creating a custom report via the server's reporting mechanism (SQL Server Reporting Services).  I have a little app that creates a "coverage analysis" spreadsheet in Excel that shows coverage (i.e. links) between work item types (for example, I can see if there are any business requirements that have no corresponding functional requirements).

Next:  TFS - Partner Integrations

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
  In Part 2, I discussed how you can begin to manage requirements using the built-in facilities of Team

• Anonymous
  November 06, 2007
  Every organization approaches the concept of "requirements" differently. Factors include general history,

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

• Anonymous
  February 22, 2008
  For some reason I'm getting a 500 - Internal server error on all the images on this page.

• Anonymous
  March 05, 2008
  Bebo.. They look to be working now.. can you see the images?  My blog images are posted to a server that can sometimes be less than reliable.  Sorry for the inconvenience.

• Anonymous
  March 06, 2008
  Nice summary. This coverage analysis tool you made sounds interesting. Can you give any more info on it... or even the source ? We're looking to make exactly such a tool. Thanks!

• Anonymous
  March 26, 2008
  Hi Simon, I'd love to send it to you, but I can't.  Not because I'm not allowed, but because I don't have it anymore (long story involving hard drives and VPC's).  One recommendation I can make is to check out the book "Global Outsourcing with Microsoft Visual Studio Team System".  It has some great code samples that will get you close to what I was talking about..

• Anonymous
  June 24, 2008
  Team System、Team Foundation Server、およびサード パーティ製品による要件管理についての優れたブログのシリーズを見つけましたのでご紹介します。この概要をまとめたホワイトペーパーも現在準備中です。

• Anonymous
  September 24, 2012
  The comment has been removed

• Anonymous
  February 18, 2014
  Pics 1-3, 4 in the article don't display

• Anonymous
  August 14, 2014
  Do you recommend using PBI's to track Business Analysts tasks for creating BRD's and FRD's.