Use Case (GovDev)

You can learn how to fill in the details of a use case work item in this topic. For information about what Use Cases are and how they are used in agile processes, see Creating a Great Project Backlog. For information about how to create a work item for a use case, see Work Items and Workflow (GovDev).

Required Permissions

To view a use case, you must be a member of the Readers group or your View work items in this node must be set to Allow. To create or modify a use case, you must be a member of the Contributors group or your Edit work items in this node permissions must be set to Allow. For more information, see Managing Permissions.

Defining a Use Case

A use case communicates functionality that is of value to the end user of the product or system. Each use case should simply state what a user wants to do with a feature of the software and describe it from the user's perspective. When you write use cases, you should focus on who the feature is for, what they want to accomplish, and why. You should avoid descriptions that specify how the feature should be developed.

The work item form for a use case stores data in the fields and tabs that the following illustration shows:

Work Item Form for a Use Case

When you define a use case, you must define the Title in the top section of the work item form. You can leave all other fields blank or accept their default values.

To define a Use Case

  1. In the top section of the work item form for the use case, specify one or more of the following types of information:

    • In Title (Required), type a short description.

      Good titles reflect the value to the customer or functionality that needs to be implemented.

    • In the Assigned To list, click the name of the team member who owns the use case.

      NoteNote

      You can assign work items only to members of the Contributors group.

      If you leave the use case unassigned, it is automatically assigned to you.

    • In the Rank box, type a number that indicates the relative importance of the use case compared to the other use cases in the product backlog.

    • In the Story Points box, type a number that specifies a subjective rating for the amount of work that will be required to complete a use case.

      If you specify more points, you indicate that more work will be required.

    • In the Priority list, click the level of importance for the use case on a scale of 1 (most important) to 4 (least important).

    • In the Area and Iteration lists, click the appropriate area and iteration or leave these fields blank to be assigned later during a planning meeting.

      NoteNote

      The project administrator for each team project defines area and iteration paths for that project so that the team can track progress by those designations. For more information, see Create and Modify Areas and Iterations.

  2. On the Details tab, you are provided with a template for specifying the use case information. Your team will use this information to create work items for tasks and test cases. For more information, see Task (GovDev) and Test Case (GovDev) .

  3. In the Scenarios tab, describe the alternate paths of executioon that could occur as the user is performing the functionality. This information will aid the team in the creation of work items for tasks and test cases to complete the use case.

  4. In the History box, add comments that you want to capture as part of the historical record.

    Every time that a team member updates the work item, its history shows the date of the change, the team member who made the change, and the fields that changed.

  5. Link the use case to other work items, such as tasks, test cases, bugs, and issues.

    For more information, see the following sections later in this topic:

  6. Click Save Save Work Item.

NoteNote

After you save the use case, the identifier appears in the title under the work item toolbar.

Adding and Linking Tasks to a Use Case

You add tasks to a use case to track the progress of work that has occurred to complete the use case.

NoteNote

The Requirements Traceability and Requirements Progress reports require that you create links between requirements and use cases, use cases and tasks and use cases and test cases. For more information, see Requirements Traceability Report (GovDev) and Requirements Progress Report (GovDev).

To create a Task that is linked to a Use Case

To link several existing tasks to a Use Case

  1. On the Implementation tab, click Add Links Link to.

    The Add Link to Use Case dialog box opens.

  2. In the Link Type list, leave the default option, Child as it is the only allowed option. 

  3. Click Browse.

    The Choose Linked Work Items dialog box appears.

    Link task to Use Case dialog box
  4. Type the items in Work item IDs, or browse for the items to which you want to link. You can also run the My Tasks team query to locate the tasks to which you want to link. Select the check box next to each task that you want to link to the use case. For more information, see Find Work Items to Link or Import.

  5. (Optional) Type a description for the tasks to which you are linking.

  6. Click OK, and then click Save Save Work Item.

    NoteNote

    Both the use case and tasks that you linked are updated. A Parent link to the use case is created for each task that you added.

Adding and Linking Test Cases to a Use Case

As part of planning, you create test cases and link them to Use Cases. The recommended client for creating test suites and test cases is Microsoft Test Manager. From this client, you can also link to a use case as described in How to: View Requirements or Use Cases Using Microsoft Test Manager.

To create a Test Case that is linked to a Use Case

  1. On the Test Cases tab, click Add New Linked Work Item New.

    The Add new Linked Work Item dialog box opens.

    Add new linked Test Case to a Use Case
  2. In the Link Type list, leave the default option, Tested By as it is the only allowed option.

  3. In the Work Item Type list, leave the default option, Test Case as it is the only allowed option.

  4. In Title, type a descriptive name that defines the area to be tested.

  5. (Optional) In Comment, type additional information.

  6. Click OK.

    A work item form for a test case opens with the information that you have provided.

  7. Specify the remaining fields as described in Test Case (GovDev), and then click Save Save Work Item.

To link existing test cases to a use case

  1. On the Test Cases tab, click Add Links Link to.

    The Add Link to Use Case dialog box opens.

  2. In the Link Type list, leave the default option, Tested By as it is the only allowed option.

  3. Click Browse.

    The Choose Linked Work Items dialog box appears.

    Link test cases to Use Case dialog box
  4. In Work item IDs, type the IDs of the test cases that you want to link, or browse for them. You can run the My Test Cases team query to locate the test cases that you want to add, and then select the check box next to each test case to which you want to link. For more information, see Find Work Items to Link or Import.

  5. (Optional) Type a description for the test cases to which you are linking.

  6. Click OK, and click Save Save Work Item.

    NoteNote

    Both the use case and test cases to which you linked are updated. A Tests link to the use case is created for each test case that you added.

Adding and Linking Bugs to a Use Case

You can create a bug and link it to an open use case from the Bugs tab.

To create a Bug that is linked to a Use Case

To link existing bugs to a Use Case

  1. On the Bugs tab, click Add Links Link to.

    The Add Link to Use Case dialog box opens.

  2. In the Link Type list, leave the default option. Child as it is the only allowed option.

  3. Click Browse.

    The Choose Linked Work Items dialog box appears.

    Link bugs to Use Case dialog box
  4. In Work item IDs, type the IDs of the bugs that you want to link, or browse for them. You can run the My Bugs team query to locate the bugs that you want to add, and then select the check box next to each buge to which you want to link. For more information, see Find Work Items to Link or Import.

  5. (Optional) Type a description for the test cases to which you are linking.

  6. Click OK, and click Save Save Work Item.

    NoteNote

    Both the use case and bugs to which you linked are updated. A Parent link to the use case is created for each bug that you added.

Adding Details and Attachments to Use Cases

You can add details to Use Cases in the following ways:

  • Type information in the Description or History field.

  • Attach a file.

    For example, you can attach an e-mail thread, a document, an image, a log file, or another type of file.

  • Add a hyperlink to Web site or to a file that is stored on a server or a Web site.

To add details to a Use Case

To add an attachment to a Use Case

  1. On the Attachments tab, perform one of the following actions:

    • Drag a file into the attachment area.

    • Click Paste or press CTRL-V to paste a file that you have copied.

    • Click Add Attachment Add, and then click Browse. In the Attachment dialog box, type or browse to the name of the file that you want to attach.

      (Optional) In the Comment box, type more information about the attachment. To return to the Attachments tab, click OK.

  2. Click Save Save Work Item.

Resolving and Closing a Use Case

You can use the Active, Resolved, and Closed states to track the progress of Use Cases. When you have written the code to implement a use case and all unit tests have passed, you change the State of the use case to Resolved. After all tasks are completed and the use case passed all acceptance tests, you change its State to Closed . Any team member can change the state of a use case.

For more information about the data fields that you can use to track work item states, see Assignments and Workflow (GovDev).

To resolve or close an active Use Case

  1. Open the Use Case.

  2. In the State list, click Resolved or Closed.

    • If you change the state from Active to Resolved , the Reason field automatically changes to Code complete and unit tests pass.

    • If you change the state from Resolved to Closed, the Reason field changes to Acceptance tests pass.

    • If you change the state from Active to Closed , you should click the Reason that matches your intent, as Active to Closedlater in this topic.

  3. Click Save Save Work Item.

Typical workflow progression:

  • A customer representative creates a use case in the Active state with the default reason, New.

  • A team member changes the state of the use case from Active to Resolvedwhen it is code complete and unit tests have passed

  • A team member changes the state from Resolved to Closed when the test cases that were defined for the use case have passed

Atypical transitions:

  • A customer representative determines that the use case is not relevant or out of scope and changes the state from Active to Closed

  • An acceptance test for the use case fails. Therefore, a team member changes the state from Resolved to Active

  • A customer representative determines that the use case was closed in error or is now in scope and changes the state from Closed to Active

Use Case State Diagram

Use Case state diagram

Active (New)

The following data fields are automatically captured when a team member creates a Use Case:

  • Created By: Name of the team member who created the work item.

  • Created Date: Date and time when the work item was created, as recorded by the server clock.

From Active to Resolved

You can resolve an active use case for the following reason:

Reason

When to use

Additional actions to take

Code complete and unit tests pass

When the code to implement a use case is checked in and all unit tests have passed.

Assign the use case to the team member who will test it.

The following data fields are captured when a team member resolves an active use case:

  • Resolved By: Name of the team member who resolved the work item.

  • Resolved Date: Date and time when the work item was resolved, as recorded by the server clock.

  • State Change Date: Date and time when the state of the work item was changed.

From Active to Closed

You can close an active use case because of one of the following reasons:

Reason

When to use

Additional actions to take

Rejected (default)

You determine that the use case represents a feature or requirement that does not support a business requirement, scenario, or value proposition.

None.

Abandoned

The use case is no longer considered necessary to implement.

None.

Out of Scope

The team has insufficient resources to implement the use case for the current iteration.

A use case might be identified as out of scope because the team has insufficient time or because blocking issues were discovered.

Update the Iteration field to specify in which iteration the scenario will be implemented. If the scenario is deferred to the next release of the software, leave the Iteration field blank, but describe in detail why the scenario was deferred and when it should be implemented.

The following data fields are captured when you close an active use case:

  • Closed By: Name of the team member who closed the work item.

  • Closed Date: Date and time when the work item was closed, as recorded by the server clock.

  • State Change Date: Date and time when the state of the work item was changed.

Resolved

Closed

See Also