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.
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:
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?"
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