Content

1. Overview
2. The Use Case Model
   1. Steps
3. Writing the Use Cases
   1. Levels of Formality
      1. Fully Dressed Form
         1. Flow
         2. Essential & Concrete Styles
         3. Other Need-to-Knows
   2. Which Style to Choose?
4. Use Case Driven Development

Overview

A use case is a sequence of actions a system performs, yielding observable result of value to a particular actor.
It writes stories of stakeholders using the system to achieve their goals.

• Systematic & intuitive way of capturing requirements
• Focus on providing value
• Understandable to stakeholders
• Identifies functions of softwares good to users
• Away from product features, towards user goals -> build the right system

The Use Case Model

• Supplementary specification
  • Collect non-functional requirements not specific to any use case
• Actors (roles)
  • Primary actor
    • Has user goals fulfilled by using services of the system
    • The goals drive the use cases
  • Supporting actor
    • Provides a service to the system
    • Clarifies external interfaces and protocols

Steps

1. First steps
   1. Define system boundary
   2. Identify primary actors
   3. For each actor:
      • Identify user goals
        • What they do with the system?
      • Describe at the correct level (elementary business processes)
   4. Define use cases that satisfy user goal
      • Name each one according to its goal
2. Find primary actors
   • Same time as identifying their goals
   • Ask:
     • Who starts/stops the system?
     • Who does user & security management?
     • Who evaluates system activity?
     • Time driven events?
3. Find actor's goals
   • Actor-goal list
     • Generally 1 use case for each goal
   • Names of use case reflects actor's intention (verb first)
   • Risk & priority columns can be added
   • Group similar types of goals

Elementary Business Process

A task performed by 1 person in 1 place at 1 time, in response to a business event, which adds measurable value and leaves data in a consistent state

Not a rule; it's a general guideline on starting to work with use cases.

Around 5-10 steps, not too small/large.

Use Case Context Diagram

Primary actors ---- API ---- Supporting actors

Writing the Use Cases

• How the use case starts & ends
• Normal flow of events
  • Sequence of actions & interactions between actor & system
• Alternate flow of events
  • Rejoin the basic flow | end

Levels of Formality

• Brief: a paragraph summarizing the main success scenario
• Casual: several paragraphs covering a number of scenarios
• Fully dressed: all steps written in detail

Fully Dressed Form

Flow

A use case are a set of scenarios - flow of interactions.

• Main success scenario
  • Trigger to goal delivery & clean-up
  • Only one
  • No conditional branching
• Extensions (alternative flows & exceptions)
  • One at a time
  • Each refers to the relevant step of main scenario they extend
  • Specify the rejoin point

Essential & Concrete Styles

• Essential
  • Focus on user intent
  • Avoid technical, design, implementation details
• Concrete
  • Embeds UI design decisions

Other Need-to-Knows

• General description
  • What use case is about, why it exists, outcome of execution
• Special Requirements
  • Usually non-functional
  • Often moved to supplementary spec later
• ID & name
  • Name: action verb + noun
• Preconditions
  • The state that must be in before the use case can be triggered
  • Assumed by the use case; checked by system but not checked within the use case
  • Not the user's goal
• Postconditions
  • The state upon successful completion
  • Meets the stakeholders' needs
  • E.g. something displayed to the user; something physical presented to the user; some internal state change
• Trigger
  • Not repeated if it is the first step in flow
• Primary actor and other stakeholders' interests
  • Reveals what should be in the use case & what should not

Which Style to Choose?

• Fully dressed
  • Won't work closely with users during development
  • Product complex & safety-critical | mission-critical
  • Developers not familiar with the domain
  • Use Cases + Supplementary Spec serve as Software Requirements Spec
  • Use Cases serve as sole basis for testing
  • The team is large, fragmented, or geographically separated

Use Case Driven Development

• Analysis & design begin with use cases
• Basis for testing
• Support traceability
• An increment = a working realization of a set of use case scenarios
• Each iteration is driven by the use cases through all the disciplines
• Basis for planning, estimation, and management
• Guide for user manual, useful shortcuts, aids to usability, etc.