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)

Team Explorer's Documents folderIf 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. 

Document Library in TFS PortalAnd 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.

Bug linked to a changeset and work item

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

Requirements QueriesTeam 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:

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: