The Use Case Technique: an Overview

The Use Case Technique: An Overview

Karl Wiegers Process Impact www.processimpact.com

Source Books

 Software Requirements,3rd Ed., by Karl Wiegers and Joy Beatty (Microsoft Press, 2013)

 More About Software Requirements, by Karl E. Wiegers (Microsoft Press, 2006)

 Use Cases: Requirements in Context, 2nd Ed. by Daryl Kulak and Eamonn Guiney (Addison-Wesley, 2003)

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 1 Agenda

 Use cases defined  Use cases and user stories  Benefits of the use case approach  User classes and actors  Use case elicitation workshops  Elements of a use case  Use cases and functional requirements  Use case traps to avoid

Three Levels of Software Requirements

Business Requirements Business Rules

Vision and Scope Document

User Quality Requirements Attributes

User Requirements Document External Interfaces Functional Requirements Constraints

Software Requirements Specification

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 2 Eliciting Requirements Through Use Cases

 Provides a method to capture user requirements.  Focus on actual, but abstracted, usage scenarios.  Ask users: “Describe a goal you wish to accomplish with the system.” not: “What do you want the system to do?”

 Explore sequences of ‘actor’ actions and system responses.  Derive functional requirements and tests from use cases.

What Use Cases Are and Are Not

 Definition: A description of a set of interaction sequences that a system performs to provide a result of observable or measurable value to one or more actors.  Use cases describe:  user goals  the user’s view of the system  a set of task-related activities  Use cases do not describe:  user interface designs  technology solutions  application architecture

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 3 Examples of Use Cases

 Intuit QuickBooks “activities”:  Enter Credit Card Charge  Enter a Bill  Create an Invoice  Reconcile Account  Pay Bills  Receive Payment  Amazon.com options for a pending order:  Check Order Status  Change Shipping Options  Cancel Unshipped Items  Track Package  Buy a product online:  Search Catalog  Place Item in Shopping Cart  Pay for Items in Shopping Cart

Naming Use Cases

 Name properties:  reflect the actor’s goal from the actor’s perspective  describe a valuable transaction  be general enough to cover related scenarios  Form: active verb + object  “Generate Usage Report”, not “Usage Report Generation”  use strong verbs and specific nouns

Good Examples: Poor Examples:  Reserve Rental Car  Enter PIN  Print Invoice  Submit Form 37  Register for Payroll Deduction  Process Deposit  Check Flight Status  Manage Menus

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 4 Agile User Stories

 A “short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system” (Mike Cohn). serve as placeholder for future conversations for details augmented with acceptance tests don’t get into user interaction specifics  A common writing style: As a , I want so that .

Use Cases and User Stories

“Create an Invoice” functional Use requirements Case conversations use case analysis specification Name tests

“As a small business owner, I want to create an invoice so that I can bill a customer.”

User conversations refined user conversations acceptance Story stories tests

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 5 Benefits from the Usage-Centric Approach

 User’s terminology is applied  Reveals requirements for users to get work done  Helps analysts understand application domain  Avoids building unnecessary functionality  Permits early drafting of functional tests  Helps set implementation priorities on functional requirements

Appropriate Use Case Applications

 Use cases work well for:  end-user applications  business automation projects  web sites  devices with which users must interact

 Use cases aren’t as valuable for:  batch processes  event-driven real-time systems  computationally-intensive systems  business analytics systems

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 6 User Classes and Actors

 User Classes: Distinct communities of users for the product.  Actors: Entities outside the system that interact with it for the purpose of completing an event.

User Classes Actors

Account Owner Bank Customer Loan Applicant Depositor Chemist Technician Chemical Stockroom Staff Requester Lab Manager

Scenarios and Use Cases - 1

 A scenario is:  one specific path through a use case, or  a story about a specific instance of a use case execution, perhaps with actual users identified and specific data  Each use case typically includes multiple scenarios.  could be successful or could be failure modes

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 7 Scenarios and Use Cases - 2

More Abstract Prepare a mailing label

Prepare a mailing label to send a package by second-day UPS.

Chris wants to send a 2.5-pound package by Less second-day UPS from Portland, OR, to Abstract Rochester, NY. She wants it insured for $75 and she wants a return receipt. The package is marked fragile.

Use Case Elicitation Workshop

Use Case: View an order. Actor: Requester Frequency: 5/user/day Preconditions: system contains orders, user identity is verified Postconditions: order has been shown

Actor Actions System Responses

user enters order display order number he wants details to view

user enters order error message: number, but it order number doesn’t exist not found

etc. for all normal and exception pathways

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 8 Products from Use Case Analysis

Drafted SRS Verified SRS Drafted Tests Verified Shared Models Vision Use Case Use Case Drafted Models Workshops Descriptions

Business Rules

Data Dictionary

Use Case Template

ID and Name: Created By: Date Created: Primary Actor: Secondary Actors: Description: Trigger: Preconditions: Postconditions: Normal Flow: Alternative Flows: Exceptions: Priority: Frequency of Use: Business Rules: Other Information: Assumptions:

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 9 Sample Use Case for an ATM - 1

Name: Withdraw Cash Actor: Account Owner Description: The user withdraws a specific amount of cash from an account. Trigger: Account Owner selects Withdrawal action. Preconditions: 1. The Account Owner is logged in to the ATM. 2. The Account Owner has at least 1 account with a positive balance. 3. The ATM contains cash. Postconditions: 1. The requested amount of cash has been dispensed. 2. The account balance is reduced by the amount withdrawn plus any fees. 3. The ATM cash balance is reduced by the amount withdrawn. Priority: High

Sample Use Case for an ATM - 2

 Normal Flow: 1. System displays user’s accounts. 2. Account Owner selects desired account. 3. System asks user to choose amount to withdraw from a list. 4. Account Owner chooses amount to withdraw. 5. System dispenses cash. 6. Account Owner removes cash from dispenser.

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 10 Sample Use Case for an ATM - 3

 Alternative Flows:  at step 3, actor can choose to enter a custom amount  describe where the branch takes place, what happens, and where the alternative flow rejoins the main flow  Exceptions:  amount is not a multiple of $20  amount exceeds daily withdrawal limit  amount exceeds account balance  amount exceeds cash available in ATM  indicate the step number where the exception could take place and how the system handles it

Use Cases and Functional Requirements - 1

 Two schools of thought:  Use cases are the functional requirements.  Use cases reveal the functional requirements.

User View Developer View

Functional Use Cases Requirements

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 11 Use Cases and Functional Requirements - 2

 Precondition  “The system shall verify that the account is set up for ATM withdrawals.”  Steps in Flow  “The system shall display a list of standard withdrawal amounts. The user shall select one of these amounts or ‘Other’.”  Postcondition  “The system shall reduce the total cash remaining in the ATM by the amount of the withdrawal.”  Business Rule  “The system shall print the available balance on the receipt, unless the account is a business account.”

Organizing Information: Use Case and SRS

Use Case Organization SRS Organization Pre ~~~~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ Normal ~~~~~~~~~~~~ Flow ~~~~~~~~~~~~ ~~~~~~~~~ A ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ ~~~~~~~~~ E ~~~~~~~~~ ~~~~~~~~~~~~ Post ~~~~~~~~~~~~ Rules ~~~~~~~~~~~~ ~~~~~~~~~~~~ Other

The Use Case Technique: An Overview Copyright 2018 Karl Wiegers Page 12 Use Case Traps to Avoid

 Use cases that users don’t understand.  “Use cases” that aren’t about user goals.  Too many use cases.  Highly complex use cases.  Describing specific user interface elements and actions.  Failing to consider alternative flows and exceptions.  Prematurely detailing low-priority use cases.  Undefined or inconsistent system boundary.  Not using other requirements models.

The Use Case Technique: An Overview

NO SURPRISES!