Use Cases Descriptions and Use Case Models

1
Use Cases Descriptions and Use Case Models
2
Objectives

• To explain what use case descriptions are
• To specify the contents of use case descriptions
• To present a use case description writing process
• To present heuristics for use case descriptions
• To explain the relationship between use cases and
  requirements
• To explain what use case models are
• To explain how to design with use case models
• To outline how to use use cases in iterative
  development

3
Topics

• Use case descriptions, their formats, and their
  contents
• Writing use case descriptions
• Use case description heuristics
• Use case descriptions and requirements
• Use case models
• Designing with use case models
• Use-case-driven iterative development

4
Use Case Descriptions
A use case description is a specification of the
interaction between a product and the actors in a
use case.

• What each party does
• The order in which each party acts
• All possible courses of interaction complex
  activity flows

5
Use Case Description Contents 1

• Use case name and number
• Actors
• Stakeholders and their needs
• PreconditionsA precondition is an assertion that
  must be true when an activity or operation
  begins.
• Not checked by the use case
• PostconditionsA postcondition is an assertion of
  what must be true when an activity or operation
  ends.
• Must satisfy stakeholder needs

6
Use Case Description Contents 2

• TriggerA trigger is an event that causes a use
  case to begin.
• May be the first step in the use case
• Basic flow
• An action flow a list of steps
• Documents a standard, successful interaction
• Begins at the trigger, continues until the use
  case ends
• Extensions
• Alternative action flows
• May begin and end anywhere
• Extensions may have extensions

7
Car Wash Example Part 1
Use Case 2 Activate/Deactivate Actors Soap
sensor Stakeholders and needs CustomersNeed
their cars washed with soap, and want a
complete wash OperationsWant the carwash to
operate without constant attention Preconditions
None Postconditions The carwash is active if
and only if the soap sensor indicates that there
is soap. No wash currently in progress is
interrupted.
8
Car Wash Example Part 2

• Trigger One minute has passed since the last
  time the soap sensor was checked.
• Basic Flow
• The carwash queries the soap sensor.
• The soap sensor indicates that there is soap.
• If the carwash is active, it continues its
  operation and the use case ends.
• Extensions
• 1a The carwash is unable to query the soap
  sensor
• 1a1. The controller logs the problem and the use
  case ends.

9
Car Wash Example Part 3
Extensions (continued) 2a The soap sensor
indicates that there is no more soap 2a1. If
the carwash is inactive, the use case ends. 2a2.
If the carwash is active, the controller displays
an out-of- order message and becomes inactive
the use case ends. 2b The soap sensor does not
respond 2b1. The controller logs the
problem. 2b2. If the carwash is inactive, the
use case ends. 2b3. If the carwash is active,
the controller displays an out-of- order message
and becomes inactive the use case ends. 2a2,
2b3 A wash is in progress 2a21. The carwash
completes the current wash, then displays an
out-of-order message the use case ends. 3a The
carwash is inactive 3a1. The carwash becomes
active and displays a ready message.
10
Use Case Description Formats

• Many alternatives
• Fully-dressed format
• Underlined text refers to another use case.
• Extensions use a special numbering scheme
• Numbers are for action step sequencing
• Letters are for extension triggers
• Extension identifiers have interleaved numbers
  and letters
• An asterisk refers to all action steps
• A dash is used for ranges of action steps
• A comma separates action steps in a list.

11
Use Case Description Template
Use Case number name Actors actorList Stakeholders and NeedsstakeholderneedsList.stakeholderneedsList. Preconditions what is assumed at the start. Postconditions what is guaranteed at the end. Trigger the event that starts the use case. Basic Flow stepDescription ExtensionsextensionIdenti?er condition extensionIdenti?er stepDescription
12
Description Writing Process
13
Filling in the Initial Fields

• Stakeholders are human use case actors or anyone
  with an interest to protect.
• Only state things that really matter as use case
  preconditions.
• Postconditions must be true when the use case
  ends whether it is successful or not.
• The trigger is often the first step in the use
  case (but not always).

14
Writing the Basic Flow 1

• Choose a common, simple activity flow.
• Trace it from the trigger through use case
  completion.
• Scenarios are often good resources.

15
Writing the Basic Flow 2

• Steps may assume the preconditions and should
  achieve the postconditions.
• Each step should state an action of a single
  agent (the product or an actor).
• Supplemental directions about conditions,
  iteration, or currency are allowed.

16
Brainstorming Branch Points

• A branch point is a place where the action flow
  may diverge.
• Brainstorm a list of branch points and failure
  conditions.
• Look at scenarios for failed or alternative
  interactions.
• Consider errors, faults, and alternatives at
  every step.
• Dont forget an actors failure to act.

17
Rationalizing Branch Points

• Remove from further considerations any conditions
  that the product
• Cannot detect
• Cannot do anything about
• Rewrite poorly stated conditions

18
Writing Extensions

• Treat an extension as if it were a separate use
  case
• The condition is the trigger
• Extension steps are the basic flow
• Completing the use case or returning to the
  branch point are the goals.
• Scenarios are a good resource.
• Repeat the extension writing process for the
  extension (extensions may have extensions).

19
Use Case Description Heuristics 1

• Fill in the use case template from top to bottom.
• Obtain use case and actor names from the use case
  diagram.
• Make human actors stakeholders whose needs
  include completion of the task done by the use
  case.
• Write simple declarative sentences in the active
  voice.

20
Use Case Description Heuristics 2

• Make actors or the the product the subject of
  each step description.
• Write a basic flow with three to nine steps.
• Avoid sequences of steps by actors or the
  product.
• Dont specify physical details.
• Impose minimal order on activities.
• Proofread the description.

21
Use Case Models
A use case model is a use case diagram together
with use case descriptions for each use case in
the diagram.

• The diagram is a static model cataloging product
  interactions.
• The descriptions are dynamic models detailing the
  interactions.

22
Designing with Use Case Diagrams

• Models a design alternative for the interactions
  that a product will support
• Generate several design alternatives
• Alternative can be evaluated in terms of
• Unmet needs
• Extraneous features or capabilities
• Development costs
• Time and risk
• Conformance to constraints
• Feasibility, simplicity, beauty

23
Designing with Use Case Descriptions

• Use case descriptions refine the user-level
  specification in a use case diagram into
  operational-level specifications.
• Design alternatives are specified in different
  descriptions.
• Alternatives can be evaluated as already
  described.

24
Requirements and Use Case Models

• Use case models do not provide atomized
  requirements statements.
• They are not traceable
• Some product functions may not appear
• Data and non-functional requirements are not
  explicit.
• Use case models sometime serve as surrogates for
  requirements.

25
Extracting Requirements

• Extracting requirements from use case models
• Helps designers understand their designs better
• Helps find errors and improve designs
• Produces a useful artifact for engineering
  design.
• Additional requirements are also needed.
• Data and non-functional requirements
• Physical-level requirements

26
Use-Case-Driven Iterative Development

• In an iterative development project
• Choose several use cases for implementation in an
  iteration
• Furnish product design details
• Do engineering design, code, test, and (perhaps)
  deploy
• Evaluate the result for the next iteration
• Repeat these steps.

27
Process Guidelines

• Start with a complete use case diagram.
• Choose use cases for each iteration according the
  the following criteria
• Important to stakeholders
• Requires a core system function
• Requires the essentials of the system
  architecture
• The implementation is technically challenging

28
Summary

• A use cases description is structured text that
  specifies the details of a use case.
• Templates, processes, and heuristics guide use
  case description writers.
• Use case descriptions, though not requirements,
  can be a source for them.
• Use case diagrams and descriptions together form
  use case models.
• These models are a powerful product design tool.
• Use cases can drive iterative development.