Use Case

A use case for a business analyst creating a process diagram:

1. Create a process diagram. A blank canvas appears.
2. Put one or more boxes on canvas representing tasks.
3. Label boxes with text.
4. Draw an arrow from a box, optionally to another box.
5. Label any arrow with text.
6. Move a box, maintaining linkage(s) with the box and its connecting arrow(s)
7. Drill down from a box to create a new diagram with step details.
8. Save the process diagram for later editing or display.

Making the Cases for a Solution (Key Story)

Making the Cases for a Solution excerpts:

• The Story of a Use Case
  • 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 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 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:
• Let’s Get Specific
  • 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:
• Wrapping Up the Case
  • 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.
    

What's the Story?

What's the Story? excerpts:

• What’s the Story For?
  • User stories do not refer to the solution itself. Use cases deal with a user’s interaction with the solution. We’ll cover use cases in the next article.
    

Empathy for the Customer

Empathy for the Customer excerpts:

• A Promising Meeting Takes an Unexpected Turn
  • The purposeful architect describes the product manager what she needs from the tool, including specific use cases. The product manager asks her to slow down so he can fit what she’s saying into his template. The purposeful architect feels her frustration rise as she looks at her watch. She gives him a second red flag. She suggests the product manager record their conversation so he can catch up later. He expresses concern that recording a conversation could violate company policy.
  • The product manager asks the purposeful architect if she would write her use cases and send them to him. She replied that she had already told him her use cases and he missed the opportunity to capture them. She gives the product manager his third and final red flag.
• Lessons Learned
  • The purposeful architect had enough when the product manager asked her to capture her own use cases. She had already taken the initiative for him to ask what she needed. She had to take the lead again, asking him to record their conversation instead of struggling with a template. If she provided him with her needs in writing, what initiative would he take to understand them?