Steve Lange @ Work

Steve Lange's thoughts on application lifecycle management, Visual Studio, and Team Foundation Server

November, 2007

  • Steve Lange @ Work

    Requirements Management in TFS: Part 1 (of 4): Overview

    • 10 Comments

    There are several schools of thought on how to "do RM" ranging from the very lightweight (whiteboards, sticky notes, cocktail napkins, etc) to the robust (formal elicitation, authoring, validation and management of specifications).  Chances are your organization falls somewhere in between. 

    Past dictates future (thanks, Dr. Phil), and the same applies in how teams approach requirements management.  Basically, if you're used to managing your requirements using Word documents (and believe me, you're in the majority), most likely that's what you figure to do when starting a new project.

    The historically mainstream ways to manage requirements (Word, Excel, email) can be efficient (people know the tools, and again, it's how it's been done before) and satisfactory.  But with the application development projects of today becoming increasingly complex and distributed (both architecture and project teams), this process becomes more difficult to manage.  Throw in your regulation/compliance package-of-the-day and you quickly realize you need more.  Key capabilities around collaboration, audit/history, and traceability rise to the top of the priority list.

    As a result, the idea of managing requirements as individual elements (rather than parts of a larger specification document) is becoming increasingly popular.

    I hear this quite often:  "How does Team System support Requirements Management?"  Visual Studio Team System, or more specifically Team Foundation Server, possesses the plumbing needed for the above-mentioned capabilities out of the box as part of its inherent architecture.  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.  However, while the infrastructure is there, TFS wasn't designed specifically to support a requirements management process. 

    But if you are looking at Team Foundation Server to manage your development process, I would suggest that you take a peek at how it can be used to support your business analysts from a requirements management perspective as well.  Again, although it's not specifically targeted at business analysts (it is on the radar (see: Team System Futures, however) there many of the capabilities of TFS can help support a productive RM process.

    This series will take a look at a few different ways that TFS can support requirements management.  In Part 2 I'll show a couple of ways to do this using TFS "natively" (without any add-ins/plug-ins); and in Part 3 I'll briefly discuss some 3rd party solutions that support requirements more directly yet still integrate with Team System.  And we'll close the loop in Part 4 with a summary.

    Next:  TFS - Out of the Box

    Series:

  • Steve Lange @ Work

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

    • 11 Comments

    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:

  • Steve Lange @ Work

    Requirements Management in TFS: Part 3 (of 4): Integrations

    • 3 Comments

    In Part 2, I discussed how you can begin to manage requirements using the built-in facilities of Team Foundation Server.  While hopefully you can see how the infrastructure for a great requirements management solution already exists in TFS, the interface and client-side functionality isn't there.

    Enter Microsoft's amazing partner ecosystem.  Several technology partners have provided integrations (or at least interfaces) to help fill the requirements management gap.  If your organization needs a more requirements-specific solution for your RM practice (and you don't want to wait for Rosario), you might want to take a peek at the below partner integrations.  They are listed in no particular order, and I have pasted abstracts from each products' respective web sites along with my personal comments (based on my exposure to the tools as well as comments from my peers and customers).  Also, I'm sure there are a few others, and I'll try to add more as they are brought to my attention:

    CaliberRM by Borland Software

    Abstract: Borland® CaliberRM™ is an enterprise software requirements management tool that facilitates collaboration, impact analysis and communication, enabling software teams to deliver on key project milestones with greater accuracy and predictability. CaliberRM also helps small, large and distributed organizations ensure that applications meet end users’ needs by allowing analysts, developers, testers and other project stakeholders to capture and communicate the users' voice throughout the application lifecycle.

    About CaliberRM for Visual Studio Team System:  CaliberRM for Visual Studio Team System allows teams to manage requirements throughout the software delivery process.  By integrating Microsoft Visual Studio Team System and Borland CaliberRM, you enable the free flow of requirements between business analysts, developers, testers, and business stakeholders. Software developers are able to respond rapidly to requirements authored by analysts using CaliberRM, through traces from requirements to tests and work items such as Change Requests and Tasks.

    CaliberRM is a client-server application that focuses on requirements management.  It's server is an object-oriented database (OODB) that stores requirements artifacts as uniquely identified objects in its data store.  It supports rich-text, document generation (think mail merge on steroids), requirement hierarchies, glossaries, and traceability. 

    TeamSpec by Personify Design

    Abstract: Personify Design TeamSpec™ provides a rich project requirement management experience directly inside Microsoft Word. By making Team Foundation Server (TFS) project artifacts such as Scenarios, QOS Requirements, Risks, Issues, Bugs, Tasks, among others, first class citizens inside Microsoft Word, TeamSpec enables Application Lifecycle contributions by the Business Analyst, Project Manager, and Executive roles.

    teamspec_screenshot

    MindManager by Mindjet

    Abstract: Use MindManager to create software requirements documents and turn those requirements into work items on Microsoft Visual Studio Team System.  The requirements map then becomes a bi- directional link to the work items.

    MindManager Pro 7 enables companies and individuals to work smarter, think creatively and save time by revolutionizing the way they visually capture and manage information.

    With MindManager 7, you will:

    • Align organizational strategy and objectives by visually conveying information in a single, centralized and coherent view.
    • Empower people to accelerate business processes by enhancing strategic thinking, facilitating quicker project planning and increasing team productivity.
    • Engage and excite employees by engaging people in stimulating real-time interactions during process planning.
    • Bring better products and services to market faster by enforcing best practices and making existing plans, processes and ideas accessible.
    • Stay ahead of the competition and foster innovation by increasing team interactions during the early stages of strategic planning.
    • Win new business faster and improve business relationships by quickly capturing relevant information and improving communication with clients.

    minjet_screenshot

    RavenFlow by Raven

    Abstract: RAVEN is an automated collaborative solution for detecting requirements errors early. It enables enterprises to elicit, specify, analyze, and validate requirements. RAVEN produces functional specifications, both graphical and textual, that everyone can understand.

    RAVEN automatically generates visual models of requirements, making errors easily visible to all stakeholders. Common requirements errors, such as ambiguous, conflicting, or missing requirements, can be detected and corrected early, reducing software costs and development time while increasing software quality.

    raven_screenshot

    stpBA StoryBoarding by stpSoft

    Abstract: stpBA Storyboarding for Microsoft® Visual Studio® Team System allows a business analyst or analyst developer to capture, define and validate requirements and scenarios in a Team System project through GUI storyboarding. Requirements can be imported from stpsoft Quew. The tool seamlessly integrates with Team System process templates and generates screen flow diagrams, HTML storyboards, UI specifications, functional specifications, Team System work items and test scripts.

    stpsoft_screenshot

    RASK (Requirements Authoring Starter Kit) - MSDN Offering

    Abstract: The Requirements Authoring Starter Kit (RASK) provides a customizable requirements-authoring solution for software development teams. RASK serves two purposes. It provides the basis of a Requirements Authoring solution and illustrates how to access Microsoft Visual Studio 2005 Team Foundation Server programmatically from Microsoft Visual Studio 2005 Tools for the Microsoft Office System (Visual Studio 2005 Tools for Office). RASK has broad functionality that you can extend with minimal effort.

    RASK integrates several Microsoft products into the solutions: Microsoft Office Word 2003, Visual Studio 2005 Tools for Office, Microsoft SQL Server 2005, and Microsoft Windows SharePoint Services. In addition, RASK uses Microsoft Visual Studio 2005 Team Suite and Visual Studio 2005 Team Foundation Server, which are part of the Microsoft Visual Studio 2005 Team System.

    RASK is not a complete requirements-authoring application and is not intended to compete with existing requirements-management applications.

    rask_screenshot

    Optimal Trace by Compuware

    Abstract:  Optimal Trace is Compuware’s business requirements definition and management solution, built to enable IT and the business to collaborate more effectively and improve IT project delivery outcomes. According to CIO magazine, ineffective requirements are the cause of over 70 percent of IT project failures. Compuware Optimal Trace addresses this problem with “structured requirements.” This approach captures software requirements from the perspective of the user, complete with visual storyboards and traceable relationships throughout the project lifecycle to business needs. Using structured requirements, IT organizations ensure that they are accurately and completely capturing the right requirements, communicating them effectively and dramatically improving their ability to deliver on the expectations of the business.

    optimaltrace_screenshot

     

    Next:  Summary

    Series:

  • Steve Lange @ Work

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

    • 10 Comments

    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):

    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:

  • Steve Lange @ Work

    Announcement: VS 2008 is HERE!

    • 0 Comments
    http://blogs.msdn.com/somasegar/archive/2007/11/19/visual-studio-2008-and-net-framework-3-5-shipped.aspx
  • Steve Lange @ Work

    Announcement: Registration open for MIX 2008

    • 0 Comments

    Registration is now open for MIX 08:  http://visitmix.com/2008/index.html

    The Next Web Now
    Now in its third year, MIX is an intimate opportunity for cutting-edge technical, creative and business strategists to engage Microsoft in a conversation about the future of the web. Come explore the latest wave of opportunities and help redefine the boundaries between: content and commerce, PC and TV, Windows and the Web.

Page 1 of 1 (6 items)