Visual Studio with TFS is more than just for coding, you can use it for the whole lifecycle of a project. In this post we’ll explore how you add requirements.
If you haven’t got TFS yet, you’ll want to check out this post on getting started with TFS so you can set up your project, then you can start adding requirements
Regardless of whether you are doing Agile or Waterfall methodologies for your application development, you need to capture the requirements for the app you will be building. Let’s take a look at how to add requirements in TFS. Those requirements become tasks we assign to the programmers on our team.
In this blog we will see
If you are already comfortable with this topic scroll down to ‘How do I add a User Story in TFS’
In Agile methodologies we capture requirements with User Stories. A User story basically describes something a user wants to do. For example:
Customers can check in for a flight
Customers can book a flight
Customers can select seats for a flight
Now remember in the real world, these user stories come from the stakeholders/users/customers not the developers! When you are doing a class project you might act as the stakeholders, but in the real world or maybe even in some class projects you might have someone such as a business analyst interviewing users and collecting the user stories.
Please, please remember, the number one rule of gathering requirements
User stories capture WHAT the system can do. User stories DO NOT capture HOW the system will do it!
As developers we have a bad habit of jumping straight to the how and thinking of a requirement as ‘there will be a web service used to allow seat reservations’ THAT IS NOT A REQUIREMENT! Did I say that loud enough, should I increase the font size? I used to teach requirements courses and this concept however simple is something that many developers struggle with. A user story simply states what the users will be able to do when they use the completed system. There is nothing in a user story about using SQL Server, or clicking on a menu item, those all describe ‘HOW’ something will be done. User stories are all about what can a user do. The idea is that the users tell you what they need the system to do by providing you with these user stories. Nobody knows what they need the system to do better than the users who do the work every day. After you have collected the use stories, that’s when you, the programmer, figure out the best way to do it (the how).You have the technical knowledge to figure out the best way to implement their requirements (web services, classes, databases, etc…)
Chances are your user stories will evolve as you get further into the project. One user story might get broken down into multiple smaller or more specific user stories, priorities for different user stories change, and new user stories are identified. I can pretty much guarantee your first list of user stories is wrong. That’s not because you didn’t do a good job collecting them, it’s just the nature of colleting requirements. I have NEVER been on a project where the requirements did not change. So don’t expect to get all the user stories exactly right on your first attempt, it can’t be done! Someone will neglect to mention something, or there will be a user you didn’t talk to who knows about some weird requirement no-one else deals with, or a brand new requirement will come up part-way through the project. Your goal is to get the requirements good enough to get started and to make sure your project is agile enough to handle the new requirements and changes when they happen.
Okay so you have your user stories, either from meetings with your users, or if you are doing a class project, maybe you got the user stories from a little brainstorming with your classmates. Now it’s time to enter the stories in TFS.
You can enter the requirements using the browser, that’s important because remember in the real world, you often have business analysts collecting the user stories. A Business analyst probably doesn’t know anything about Visual Studio. This way, anyone with a browser who is added to your TFS project can add new user stories, Visual Studio is not required to add a User Story.
Go to your project page in the browser and select Add a User Story. For more information on TFS and User Stories read up on MSDN
On the User Story Details page fill out the fields. The most important fields to fill out are title, priority/rank and Story Points.
Title – is the short description of the User Story
Description and History can be used to provide more details about the user story
Assigned To – is the name of the person assigned to own the user story (that doesn’t necessarily mean the person who will code it, it means the person who best understands and can answer questions about that user story, or who can talk to the user about that user story)
Rank – is just a number you assign could be 1-10, 1-5 that gives it a rank vs other user stories
Story Points – is a number you assign, could be 1-100, could be 100-1000, that gives an indication of how much work you think it will be. This is relative to other user stories. So it doesn’t matter if you assign 20 points or 50 points to the first user story. What matters is if you have another story that is twice as difficult you assign it double the points. If you have a much easier user story the story points should be proportionally lower.
Priority – should indicate level of importance to the user from 1 –4 (1 is the highest priority)
Area and Iteration – leave at their default values for now, when you are ready to plan what will be built when, that’s when you will assign values to these fields
After you add the User stories, they will appear to the assigned user in Visual Studio in the Team Explorer window, if they expand “My Work”
These user stories are also added to your project backlog, which you can view on your TFS project page by select “View Backlog” from the Activities menu.
The backlog allows you to see all the work that is waiting to be completde on your project. There are different ways to view your backlog on this page. For example, you can see the backlog per iteration or per assigned user.
So I can now enter all my user stories in TFS. Next up we’ll look at how you create tasks for the user stories so you can assign the actual work associated with coding a user story to members of your programming team.
Don’t forget students can get Visual Studio Professional for free at DreamSpark and anyone can get Team Foundation Service for up to 5 users for free. Professional tools at no charge? What are you waiting for?
Nice article. Simple, yet very educational. Thumbs up :)
Hi, one of the important features in the management of requirements in a product life cycle is the knowledge wich customers and how many customers are requesting a certain feature. TFS lacks the functionality to relate a US with one or more customers. How can you handle this?
User stories capture WHAT the system can do :) nice liner