Making the Cases for a Solution

The Story of a Use Case

On a discovery journey, stakeholders break down complex processes into steps, as shown in Mapping Out Complexity. A user story describes a process step in one sentence, saying who does what and why. A collection of user stories provides a good overview of a process. See What’s the Story to learn more about user stories.

A use case adds details to a user story, guiding the design and development of a solution. These details specify the conditions for the use case, interactions between the user and the system, and the expected outcome.

A Form-al Comparison

A user story has the form:

As a {person in a role}, I need to {perform a task} so that I can {fulfill a purpose}

A minimal use case has the form:

When {preconditions} are true, 
a {person in a role} {interacts with the system} 
to {produce an outcome} or {an exception} 

Use Case Components

Component	Definition
{preconditions}	One or more conditions that must be true to perform the use case Example: a user must log into a web site as a precondition to start a transaction on the site.
{person in a role}	The primary user in the use case A use case can involve other people and systems.
{interacts with the system}	What the {person in a role} does with the system How the system behaves when interacting with the user
{produces an outcome}	The expected result of the use case The outcome can vary depending on how the user interacts with the system.
{an exception}	Occurs when the use case does not produce an expected outcome

A use case expands “performing a task” from the user story to “interacting with the system to produce an outcome or an exception.” It specifies the steps of the interaction and the possible outcomes and exceptions.

Making a Use Case 

Let’s create an example use case for a sales representative submitting a draft proposal for management review. It is the third step in the process map below, labeled “Submit draft proposal for review”:

The user story is:

As a sales representative, I need to submit the draft proposal to my manager for review, so that s/he can approve it or specify changes.

We’ll name the use case based on the user story:

Sales representative submits draft proposal for management review

The process map shows the condition for the case with the incoming arrow labeled  “Proposal ready for review.” The arrow comes from the action, “Draft proposal.” Combining them makes the precondition for the use case:

Sales representative has drafted a proposal ready for management review.

Let’s Get Specific

How does the sales representative interact with the system to submit the proposal? The stakeholders have specified the following scenario:

1. Sales representative relates draft proposal to its opportunity

2. Sales representative indicates related draft proposal is ready for manager review

3. System notifies manager of proposal needing review

4. Manager reviews proposal

   1. Manager submits proposal to legal director for review if legal issues found in proposal

   2. Manager submits proposal to engineering director for review if proposal includes customizations

5. Manager reviews any comments made on proposal by other departmental directors

6. Manager comments on proposal

7. Manager indicates review is complete when satisfied with all reviews

8. System notifies sales representative that manager has completed review

In step 4, the manager can delegate proposal review to other departments if s/he finds wording or commitments in the proposal requiring approval of the departments’ management. If the stakeholders want the solution to track or audit those approvals, each department would have its own use case:

Sales manager submits draft proposal to legal director to review legal issues

Sales manager submits draft proposal to engineering director to review proposed customizations

Wrapping Up the Case

The use case specifies three possible outcomes:

• Proposal needs changes for management approval

• Proposal approved

• Proposal rejected (a business exception)

Most likely, the proposal needs changes after the initial review. If departments besides sales reviewed the proposal, all departments must approve the proposal to attain a “Proposal approved” outcome. This is an example of a business rule.

When the sales representative completes the changes required for approval, s/he goes through the use case again, expecting an outcome of “Proposal approved.”

Declaring Independence from Implementation

A use case only specifies system behavior - it intentionally avoids how to implement the system. For example, the use case refers to an opportunity, such as an opportunity record in Salesforce. The sales representative relates the draft proposal to the opportunity in step 1. The use case does not specify how the sales representative relates the proposal to its opportunity, such as attaching the proposal document to the related opportunity record. 

The sales representative indicates when the proposal is ready for review, and the sales manager indicates completion of his or her review. The use case does not specify how either the sales representative or manager makes the indication. An architect or developer should have the leeway to find the best way to specify how the system takes an indication that the proposal is ready for the next step in the use case.  

Step 3 of the use case specifies the system notifying the sales manager of the draft proposal. A developer could implement the notification with email, a text message, or even adding a task to a list, notifying the manager. Customer stakeholders can specify how each person receives notification, leaving the delivery implementation with the architect or developer.

Who’s on the Cases?

Who writes use cases? Popular opinion says the person in the business analyst role should write them because they have the requirements from discovery, good communication skills, and awareness of what’s valuable to the customer. A solutions architect could also write use cases on the same basis.

If a business analyst or solutions architect writes use cases, the development and quality assurance leads should review them for sound logic and completeness. Answering development team questions from a use case review is far more efficient and less disruptive than dealing with use case questions when development is underway. 

I had a senior quality assurance (QA) lead write use cases based on user stories I had written. I reviewed those use cases to make sure they correctly specified what the client intended. Sometimes I wrote use cases to provide more details to the development team. The QA lead checked those cases. Between the business analyst and QA roles, the person who writes the use cases should have the other role review them.

Summary

Use cases specify how a system delivers value to a customer within the small scope of the case. Each use case specifies who interacts with the system, what happens in the interaction, and what results from the interaction. It also includes the conditions necessary for the performance of the case. 

Process maps and user stories typically inform the creation of use cases. Use cases only specify system behavior in the context of interacting with a user. They do not specify system implementation - architects, developers, and designers deal with that.

A QA lead should always check use cases written by a business analyst or architect. If the QA lead writes use cases, the person in the business analyst or architect role should check the cases.

Use cases expand on user stories by introducing user interaction with the solution, fueling the launch of solution design and development.