Insight from Agora Consultants

Requirements Management and Team Foundation Server

Managing requirements on a software project can be tedious.  Most tools or process are not connected to Team Foundation Server which makes traceability difficult.  Agora has solved this issue with Requirements Tracker. In the course of doing large development projects for clients we are required to thoroughly document the application requirements prior to development.  Although we use Team Foundation Server for our development process we have found that the requirements management portion does not facilitate the iterative nature of requirements gathering and approval. Typically our business analysts will meet with clients and document the business requirements through a series of application design sessions.  These meetings typically occur at the client site in a meeting room where we may or may not have access to our servers.  In the past the requirements would be gathered in Word or Excel and hundreds of pages of requirements would be passed back and forth between the BA and the project team until agreement was reached (if ever).  Once the entire document was approved it would be handed off to the development team for decomposition into tasks which would be created in TFS. The problems with this approach include changing requirements would result in an entire new document that would need approval and complete loss of traceability of the requirement through the development phase. To solve this problem we wrote Requirements Tracker.  Requirements Tracker is the first requirements management tool built specifically to work with TFS.  Requirements Tracker allows a BA to document project goals, user groups, user stories, features, requirements, and screen designs all while working online or offline.  When the BA synchronizes and marks items for review the project team can review an comment on any item through a web-based or Silverlight application.  Once the requirement is approved it can be published directly to TFS.  Once in TFS the requirement can be linked directly to tasks providing full traceability throughout the development process. For more details on Requirements Tracker see

External User in Team Foundation Server (TFS) with Active Directory

In our organization we develop software for clients.  As part of that process we need to gather feedback from our clients when they encounter a bug.  We use Team Foundation Server 2010 internally for all aspects of our software development practice including bug collection.  We wanted to collect our client's bug reports in TFS as well. Team Foundation Server requires that all users be members of Active Directory.  Naturally, our external clients are not members of our Active Directory.  Some companies handle this by creating a single Active Directory account and requiring their external testers to all login with that account.  This is not ideal since nobody really knows who created the bug.  Other companies handle this by creating Active Directory accounts for all external testers.  For us this was not practical since over time we would have 100s of external testers that would clutter our Active Directory.  Additionally, this poses a security risk since you have created domain accounts for external users. The solution is to use a second domain for your external users.  This can either be a Windows Server running as a domain controller or you could install Active Directory in Application Mode (ADAM) on a server (or even a workstation).  The following steps will guide you through the process of creating the secondary domain and integrating it with Team Foundation Server. Step 1 - Create the domain The full details for setting up a Windows Server and Active Directory are beyond the scope of this blog, but in summary you need to do the following: Install Windows Server 2003 or Windows Server 2008 on a standalone server (i.e. the server is not part of your corporate domain) Add the Active Directory role to your server Add DNS role to your server Your new domain should be something different than corporate domain (e.g. mydomain-ext.local) At this point you should have a working domain controller that you can create external users on. Step 2 – Configure DNS First you should configure the DNS on external domain controller to forward requests to your corporate DNS.  This will allow the secondary domain to resolve DNS queries to your corporate domain and the internet.  Open the DNS console in MMC, then right click on your server and select Properties.  Next, select the Forwarders tab and enter the IP addresses of your corporate DNS servers. Now on the corporate DNS you need to tell it how to get to the domain controller for your secondary domain.  Open the DNS console in MMC on your corporate domain and right click on the server and select Properties.  On the Forwarders tab click New and enter the name of your secondary domain and add the IP of the secondary domain DNS server. Step 3 - Establish trust between your corporate domain and the secondary domain Next you need to tell your corporate domain to trust your secondary domain.  This will allow users to authenticate in the secondary domain and use resources (if permitted) in the corporate domain.  The trust relationship can be one-way or two-way.  One-way is all you need, but in screen shot below you will notice that the relationship I create was two way.  I did this so I could be an administrator on the secondary domain controller with my corporate domain account.  The level of trust you create is up to you. Open the Active Directory Domains and Trusts console in MMC.  Right click on your corporate domain and select Properties.  Click the Add Trust button and follow the wizard to create the trust. At this point you should have a trust relationship established between the two domains.  If you want to test this you can try to set the permission on a domain resource such as a file share and when you click the Locations button you should now see both domains. Step 4 - Create external users and groups in the new domain Now you are ready to add your external users to the secondary domain.  I would recommend creating new Organizational Units (OUs) either under the Users OU or under a new OU.  In the example below I created a root OU named External Users and then a new OU under that for each client.  Create your users in the appropriate OU.  Create a group in each OU and add all the users in that OU to the group.  For example under Client ABC you will have User 1 and User 2 and a group named Client ABC Testers with members User 1 and User 2. Next add a group named TFS WIOV Users and add all your external user groups to this group. Step 5 - Add the TFS WIOV Users group to the Work Item Only View Users group in Team Foundation Server Unless you buy licenses for your external users they are only permitted to use Work Item Only View (WIOV) on TFS.  You need to add the external users to a special WIOV group on TFS so they will see the WIOV site.  On the TFS server launch the TFS Administration Console.  Click the Application Tier, then Group Membership.  Select the Work Item Only View Users group and click Properties.  Next click Windows User or Group in the Add Member section and click the Add button.  Add the TFS WIOV group that you created in your secondary domain. By doing this you now only need to add additional external testers to the TFS WIOV group in your secondary domain and they will automatically be part of the TFS WIOV Users group. Step 6 - Add the external users or groups to Team Foundation Server We’re almost there!  Now you need to explicitly add the users or groups to TFS projects.  This is the same as adding internal users.  In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Group Membership. You can now add your external tester group (e.g. Client ABC Testers) directly to one of the pre-existing groups or create a new group.  I prefer to create a new group to allow greater control over their permissions. Click New and create a group named External Testers.  Once the group is created click Properties, select Windows User or Group in the Add Member section and click the Add button and add your external tester users or groups (e.g. either User 1 and User 2 explicitly or just Client ABC Tester group).  I prefer to add the group that way you only have to add users to the group in Active Directory and you don’t have to come into Visual Studio to add the users individually. Step 7 - Setup security for external users to meet your needs You have now added the external users to the project, but they don’t have permission to do anything.  The last step is to configure permissions for the External Testers group.  In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Security.  Select Team Foundation Server Group in the Add section and click the Add button.  Select the External Testers group for your project.  Once the group has been added check Allow for View project-level information and click Close. In Visual Studio select the project in the Team Explorer, right click and select Team Project Settings then Areas and Iterations.  On the Areas tab click Security.  Once again add the External Testers group as above.  Once the group has been added check Allow for “Edit work items in this node”, “View this node”, and “View work items in this node”.  Click close. You’re done! Conclusion At this point external users should be able to use the Team Foundation Server Work Item Only View (WIOV) website by going to http://<TFSserver>:8080/tfs/web/.  They will see the WIOV version of the TFS website which allows them to create new work items and view the work items that they created.  A summary of what is happening is shown below. An additional benefit to this approach is that your external testers can use the same domain account to test web applications that require domain login. About the Author Kevin Walker is a partner at Agora Consulting Partners.  Kevin is responsible for the Application Lifecycle Management practice which focuses on application development and process improvement using Team Foundation Server.  Contact Kevin at

TFS 2010 Hierarchical Queries

One of the great new features in Team Foundation Server 2010 is hierarchical queries.  A hierarchical query allows you to return multiples sets of related data in one query. The screen shot below shows a typical hierarchical query.  In this query I have selected “Work Items and Direct Links” which sets up the hierarchy.  Next, I set the top level work items to filter on Test Cases and the secondary work items to filter on Bugs and Resolved.  This gives me a query of all my test cases that have associated resolved bugs.  Perfect query for a tester to run through resolved bugs. Another great way to use this type of query is to find missing items.  Suppose you want to find all the user stories that have not test cases.  The key to this type of query is to select “Only return items that do not have the specified links”.  In the query below I have filtered for user stories with no test cases.  This is a great way to catch part of your application that does not have test coverage.

Team Foundation Server 2010 RC Install

Can you install TFS 2010 RC over top of TFS 2010 Beta 2? No, setup detects that the Beta 2 is installed and aborts the install. However, you still get the RC version installed without too much effort.  In short, you have to: Backup your database Uninstall the Beta 2 version Install the RC version and select “Upgrade from previous version” Checkout Bryan Krieger’s great blog for the full details.