Gathering user requirements is a difficult task. Even when a client knows his or her actual business requirements and goals, it is hard to define how this translates to an actual solution. On top of that, when several different types of users need to register their requirements, these can look very different indeed.
In a common scenario, the “Vision and Scope document” would paint a few different pictures:
“…a reliable platform with 99.8% uptime, capabilities for granular restore of data without additional downtime. Virtualization support is a must. User data and information should be controlled and governed centrally.” IT Administrator
“…a system that is easy and fast to use so that I can spend more time on actual research instead of administering the results.” Laboratory Researcher
“…a centralized repository for storing and serving staff self-service forms and policies.” Human Resources Administrator
To model these requirements, we can use the Use Case diagram functionality of Visual Studio 2010. This would tie the requirements to different actors as in this simple example from MSDN:
As an example, an online meal selling system must allow customers to choose items from a menu, and must allow the providing restaurants to update the menu. You can summarize this in a use case diagram:
You can also show how a use case is composed of smaller cases. For example, ordering a meal is part of buying a meal, which also includes payment and delivery:
You can also show which use cases are included in the scope of the system that you are developing. For example, the system in the illustration does not take part in the Deliver Meal use case. This helps set the context for the development work. (In a use case diagram, subsystem containers can be used to represent the system or its components.)
It also helps your team discuss what will be included in successive releases. For example, you could discuss whether, in the initial release of the system, Pay for Meal is arranged directly between the restaurant and the customer, instead of going through the system. In that case, you could move Pay for Meal outside the Dinner Now System rectangle for the initial release.
This modeling type gives you a clear indication of what user requirements have been gathered and how these can be linked to the user who requested it. On top of that, we can model the sequence in which the requirements fit together, interact or how one requirement is broken down between actors and existing systems. For this task, we can use a Sequence Diagram from Visual Studio 2010. Again, a simple example from MSDN:
You can use a sequence diagram to show the interchange of messages between your system and external actors, or between parts of your system. This provides a view of the steps in a use case that shows very clearly the sequence of interactions. Sequence diagrams are especially useful where there are several interacting parties in a use case, and also where your system has an API.
For example:
One advantage of sequence diagrams is that it is easy to see what messages come in to the system that you are constructing. To design the system, you can replace the single System lifeline with a separate lifeline for each of its components, and then show the interactions between them in response to each incoming message.
You can now tie these requirements together with your work items in Team Foundation Server (TFS) and especially with the User Story in your sprint backlog using MSF For Agile. To do this, right-click a UML element and select “Link to Work Item…”
Then create a complete user story and associate acceptance tests.
Later on we can use these requirements to navigate and track work completed during the sprints which can be a good tool for the support team when we enter the support and administration phase of the project.
For more information on Visual Studio modeling of user requirements, see http://msdn.microsoft.com/en-us/library/dd409376.aspx.
