The Use Case For Creating Goal-Driven Use Cases

There are 8 reasons we write use cases. Most of the benefits of documenting use cases come from communication, but all of the benefits depend upon the initial creation of the use case. The first step to determining the best way to create a formal use case is to understand the use case of creating use cases.

Why Write a Use Case for Use Case Creation?

By writing a formal use case for the use case creation process we are doing two good things and one bad thing.

The first good thing that we are doing is providing a real example of a formal use case.
The second good thing we are doing (we hope) is being memorable. With a Meta-Use Case (Thanks, B. Zaniello for that one), we are providing both a guide to writing use cases and a concrete example of the benefits of using a formal use case format.

The bad thing we are doing is requiring people to know how to read a formal use case to benefit from this article.

The Bigger Picture

Our goal is to gain an understanding of all 8 goals for use cases, and the scenarios in which they are used. With this understanding, we can improve our ability to apply use cases to achieve software product success.

The Use Case for Creating Goal-Driven Use Cases

Title: Business Analyst Creates Goal-Driven Use Cases

Description: The process a business analyst uses to define the use cases that support a single market requirement (goal). A single goal may be achieved with one or more supporting use cases. This document covers both possibilities.
Goals: This use case supports all 8 goals identified for creating use cases.
Primary Actor: Business Analyst (BA).

Secondary Actor: Stakeholder.

Trigger: The MRD has been completed and the creation of functional requirements has been requested.

Precondition: A Market requirement has been defined and documented.

Post-condition: The use case(s) needed to achieve the requirement have been defined.

Normal Course:

1. The BA interviews stakeholders and reviews existing documents to identify the business processes that support the market requirement.
2. The BA documents the trigger, preconditions and post-conditions for the processes.
3. The BA identifies any alternate processes that achieve the same goal.
4. The BA identifies the actors (or personas) that are involved in the particular processes.
5. The BA determines if one or more use cases are required to meet the market requirement. The following steps are repeated for each use case.
6. The BA documents a reference to the single requirement being supported.
7. The BA documents the steps in the process, where each step has a single actor and a single action.
8. The BA identifies the frequency of occurrence of the process.
9. The BA defines a priority for the use case.
10. The BA documents the frequency and notes the source of data.
11. The BA documents the priority of the use case and records assumptions and calculations used to prioritize.
12. The BA confirms that there are no re-useable use cases in the current use case.
13. The BA documents any assumptions made during the use case definition

Frequency of Occurance:

During the initial phase of a project, a business analyst may spend 100% of her time in creating use cases. During the middle or end of a project, very little time is spent on writing use cases.

Alternate Courses:

A1: Migration projects
A1.1 For a process-migration project, the BA starts by documenting the existing processes, then identifies the new business processes that allow the requirement to be achieved.

A2: Multiple requirement support
A2.6.a The BA identifies any other requirements that are also supported by the current use case.
A2.6.b The BA documents references to all supported requirements.

A3: Frequency variation within process
A3.7.a. The BA identifies that steps within the process have varying frequency of occurrence (an iterative step within a process, or a looping process).
A3.7.b. The BA either makes a note of the variation in frequency for the individual steps in either absolute or relative terms.

A4: Reuse of existing use cases
A4.8.a. The BA has identified that some of the steps of this use case are duplicates of an already documented use case.
A4.8.b. The BA replaces the duplicated steps with a reference to the use case that is being reused.
A4.8.c. The BA updates the included use case with a reference to the current use case.

A5: Anticipated Reuse of portion of this use case
A5.8.a. The BA has decided that some of the steps in the current use case should be managed as a separate, reusable use case.
A5.8.b. The BA creates the new use case representing the reusable steps.
A5.8.c. (Same as A4.8.b – A4.8.c)

A6: Duplication of several (but not all) steps of another use case
A6.8.a. The BA identifies that several steps in the current use case are repeated in another use case.
A6.8.b. The BA creates a new use case that includes the duplicated steps. (Same as A5.8.a – A5.8.b)
A6.8.c. The BA updates the current use case. (Same as A5.8.c)
A6.8.d. The BA updates the other overlapping use case (Same as A5.8.c)

Exception Courses:

E1: Data Not Available
The BA identifies any missing information as “TBD” (To be determined).
Note: The BA should make concrete plans to identify each TBD item, possibly assigning it as an action item or scheduling a date for when it will be updated.

Includes:

There are no included use cases for this use case

SummaryThis use case represents the process that a BA follows when creating a use case.Please comment with any feedback on how to improve this use case.