Team Foundation Server and Requirements Management….my crudites

It’s been my wish to join the best & brightest group of people who have been actively consuming, woodcrafting, living, loving TFS.  Finally it starts here with my cocktail…. TFS and requirements management…. I’ve tried to be very simple and 1st course of meal provides only the overview and setting the expectation right…what TFS can do for your shop and what not…

Here we go….

Is TFS a comprehensive “requirements management” tool….?????

TFS wasn’t designed specifically to support a requirements management process……However, we can leverage the features to manage the development process…..TFS can help support a productive RM process

How????

2 primary ways
SharePoint or Team Portal
Same as your existing (might be) repository, like a network share for authoring and tracking your specifications
Work Items
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

Team Portal (Sharepoint)

• Team Foundation Server creates SharePoint-based (specifically Windows SharePoint Services) web portals automatically when you create a new project.
• 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.
• Allows analysts to remain in their comfort application (MS-Word)
• Changes to requirements is much more accessible to those that will consume those requirements (architects, developers, testers, etc.).
• How to access?

1. Team Explorer (either embedded in Visual Studio or as a standalone client)
2. TFS Web Access

Value-add

• Changes are tracked, and linked, at the document level.
• Analysts remain in comfort application (Word, etc.)
• SharePoint is a “natural” extension in Word/Office applications
• Requirement specs are more easily consumed by other roles in lifecycle.
• Provides basic mechanism to enable traceability and better “cross-artifact” reporting.

Drawback

• Still don’t have granular control over individual requirements changes. ‘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.

WorkItems:

• A fast and flexible way to track any item of record throughout a lifecycle
• Managed by TFS in TFS database
• Provides a proper level of granularity for controlling change and traceability.
• Customizable – Create and customize Work Items – example, we can create work item types that represents Business, Functional, and Non-Functional and have own set of attributes.
• How to access?

1. Team Explorer (either embedded in Visual Studio or as a standalone client)
2. TFS Web Access
3. Excel & Project

Advantages:

• 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).
  

Challenges:

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

Work Item customization – how open is that…..??

• TFS SDK – you can write a custom lightweight interface for business analysts to enter and track requirements work items in TFS.
• SQL Server Reporting Services – to create custom report

we’ll talk more on work items, tracking, customization, 3rd party RM tool integration, reporting in upcoming posts….stay tuned…. 🙂