Beginning Use Cases – Identifying the Actors (part 2 of 5)

Every project must understand, to some degree, what is to be built, at least at a conceptual level. There are many techniques that have been used over the years ranging from formal, lengthy requirements specifications to short concise user stories. To be successful one of the fundamental goals of requirements is the need to bring value to all members of the team including the project stakeholders. Requirements must convey the requested functionality of the users in a means that the development team can use as a starting point to create and validate software. So far in this series we have looked at establishing requirements using work items and SharePoint portals as they are incorporated with a Team Foundation Server MSF for Agile Software Development v5.0 based project. Using the user story work items established previously we will look at how the process can proceed by taking advantage of use cases and their support in Visual Studio Team Architect 2010.

As this series of posts is all about making the most effective use of VSTS Architect a very specific approach will be used for evolving requirements with use cases. Use cases have two distinct facets; one is the graphical notation as defined by the UML while the other is a textual format that describes the interactions between an actor and a system. The approach taken here will utilize both techniques and show how to leverage Team Foundation Server to tie the pieces together building upon the techniques discussed earlier.

We started our project by establishing the user stories that are currently known and have been identified as the features and capabilities that the application should support to meet the needs and desires of the users. The next step once the user stories have been entered into Team Foundation Server is to create a new Visual Studio solution to contain our models. Starting the project by creating a model in Visual Studio Team Architect first is also a very viable option. Building a model first can be a very quick and easy way to visualize the relationships between requirements ensuring that there is consistent view of the proposed solution. User stories can easily be created from the use cases as we will see.

1. Begin by open Visual Studio Team Architect 2010

2. Select File -> New -> New Project

3. Select Modeling Project from the list of available project types. In the sample the project is named Models, the solution is named WeTransport and both the “Create directory for solution” and “Add to Source Control” options are selected.

4. Once the project is created the “Add Solution to Source Control” dialog window is presented

5. Select the WeTransport project from the list of projects in source control and click the OK button.

6. Check your files into source control

Open your list of user stories that have been created for the project and list each of the roles that have been identified. If you have been creating titles for your user stories of the form “As a «role» I want to «action» to achieve «goal»” you will be able to easily identify the majority of the roles by simply reading the titles of the stories. As an example the user story “As a customer I want to be able to look up my order to see if it has shipped” identifies the role “customer”. Watch for user stories that have identified the role as “user”, this is too generic as all roles that interact with your software will be users. Look for more specific roles such as Administrator, Customer, Call Center Operator, etc. For each role create a new Actor in the model. Using “Customer” as an example, perform the following steps:

1. Open the UML Model Explorer window. View -> Other Windows -> UML Model Explorer

2. Right click the model project “We Transport” within the model explorer

3. Select Add -> Actor

4. Name the new actor element “Customer”

Your model should now contain a single element of type Actor named Customer as shown below.

Continue adding the rest of the roles identified in your user stories as actors to the model.

Once you have added all of the roles identified in the user stories to the model you have a concise single location to review the actors that are involved in your application development effort. Each of the actors within the model represents a role that an end user can assume as they use the software. A single person may easily assume multiple roles, for example a call center worker may also be a supervisor. The specifics behind each of the actors/roles should be captured and documented within the SharePoint portal site for the team project. A common technique for defining the roles and to bring them to life for the team is to use personas. Not only do personas define the responsibilities and duties of an actor but they also provide a personality with a background, name and description that bring the persona to life. Teams commonly provide pictures to go with the personas and hang them in the team room to help remind the team who they are designing the software for.