Chapter 6 USE CASES

1
Chapter 6USE CASES
The indispensable first step to getting the
things you want out of life decide what you
want. - Ben Stein

• Objectives
• Identify and write use cases
• Use the brief, casual and fully dressed formats
• Apply tests to identify suitable use cases
• Relate use case analysis to iterative development

2
Feature Lists vs. Use Cases

• Older methods of detailing requirements tended to
  have many pages of detailed feature lists.
  Usually the details could not be seen in context.
• Current philosophy is to use a higher level of
  detail with use cases instead of a list.
• Use cases focus on who the key actors are, their
  goals, and common tasks.
• (High level System Feature Lists are still
  acceptable when they can give a
• succict summary of the system and n some
  feature-driven applications, such as
• application servers, database products,
  middleware or back-end systems.)

ID Feature
FEAT1.9 The system shall accept entry of item identifiers.
. . . . . .
FEAT2.4 The system shall log credit payments to the accounts receivable system.
3
Use Cases

• Writing Use Cases is not a specifically OO
  artifact they are simply written stories they
  are stories of using a system
• However, they are a best practice for
  elaborating and understanding requirements.
• Simple and familiar storytelling makes it easier,
  especially for customers, to contribute and
  review goals.
• Use cases keep it simple (KISS)
• They emphasize goals and the user perspective.

4
Example

• Process Sale A customer arrives at a checkout
  with items to purchase. The cashier uses the POS
  system to record each purchased item. The system
  presents a running total and line-item details.
  The customer enters payment info, which the
  system validates and records. The system updates
  inventory. The customer receives a receipt from
  the system and then leaves with the items.

5
Use Case Relationships

• Use cases, in turn, influence many other
  analysis, design, implementation, project
  management and test artifacts.

Domain Model
Business Model
VISION GLOSSARY SUPPLEMENTARY SPECIFICATION
Use Case Model
Requirements
Interaction Diagrams
Design
6
Fig. 6.1 Sample UP artifact influence
?
7
Definitions

• An actor is something with behavior, such as a
  person (identified by role), computer system, or
  organization.
• Ex. Cashier
• A scenario (use case instance) is a specific
  sequence of actions and interactions bw actors
  and the system.
• It is one particular story of using a system or
  one path through the use case.
• A use case is a collection of related success and
  failure scenarios that describe an actor using a
  system to support a goal.
• A Use Case Model is the set of all written use
  cases.
• It is a model of the system functionality and
  environment.

8
Three Types of Actors

• Primary Actor
• Has goals to be fulfilled by system
• Emphasis is on the primary actor for the use
  case.
• Ex. Cashier
• Supporting Actor
• Provides service to the system.
• Other actors are listed as stakeholders.
• Ex. Automated Payment Authorization Service.
• Offstage Actor
• Interested in the behavior, but no contribution
• Ex. Government Tax Agency.
• In diagrams, Primary actors go on the left and
  others on the right.

9
Use Cases are not diagrams !

• Use Cases may have a diagram associated with
  them, and a use case diagram is an easy way for
  an analyst to discuss a process with a subject
  matter expert (SME).
• But use cases are primarily text. The text is
  important. The diagram is optional.
• Use case modeling is primarily an act of writing
  text, not drawing diagrams.
• Capture the specific ways of using the system as
  dialogues between an actor and the system.

10
Use-Case Driven Development

• Requirements are primarily recorded in the Use
  Case model.
• Iterations are planned around implementing
  particular Use Cases.
• Use Case Realizations drive design.
• The team designs collaborating objects and
  subsystems in order to perform or realize the use
  cases.
• Use Case often influence the way user manuals are
  organized.
• Functional or system testing corresponds to the
  scenarios of use cases.

11
Working with Use Cases

• Determine the actors that will interact with the
  system.
• We cannot understand a system until we know who
  will use it
• Direct users
• Users responsible to operate and maintain it
• External systems used by the system
• External systems that interact with the system
• Examine the actors and document their needs.
• For each separate need, create a use case.
• During Analysis, extend use cases with
  interaction diagrams.

12
Actors or Use Cases First?

• Because you have to understand each part of Use
  Cases, the parts are presented separately. But
  those who create use cases switch back and forth.
  
• The text describes use cases substantially before
  paying attention to actors.
• Each specification must be testable
• Write from actors perspective, in actors
  vocabulary
• Typically, both actors and use cases are
  identified early and then examined to see if more
  use cases can be found from the actors, or more
  actors found by examining the use cases.

13
Guideline Emphasize Goals

• Seeing requirements as identifying tasks to be
  done has a strong bias toward reproducing the
  existing system, even when it is being replaced
  because it is seriously defective.
• Investigating goals rather than tasks and
  procedures improves information gathering by
  focusing on the essence of requirementsthe
  intent behind them.

14
Fig. 6.2 Primary actors and goals at different
system boundaries.
15
Naming Use Cases

• Appropriate use case names are very important.
  Because they are selected early, they tend to set
  the direction for the entire project.
• Must be a complete process from the viewpoint of
  the end user.
• Usually in verb-object form, like Buy Pizza
• Use enough detail to make it specific
• Use active voice, not passive
• From viewpoint of the actor, not the system
• Golden Rule Each use case should have a name
  that indicates what value (or goal) is achieved
  by the actor's interaction with the system.

16
Naming Use-Cases
Quick Test Use Case Name Examples

• Purchase Concert Ticket
• Purchase Concert Tickets
• Purchase Ticket
• Ticket Purchase
• Ticket Order
• Pay for Ticket

17
Use Case Name Examples
Naming Use-Cases

• Excellent - Purchase Concert Ticket
• Very Good - Purchase Concert Tickets
• Good - Purchase Ticket (insufficient detail)
• Fair - Ticket Purchase (passive)
• Poor - Ticket Order (system view, not user)
• Unacceptable - Pay for Ticket (procedure, not
  process)

18
CRUD
Naming Use-Cases

• Examples of bad use case names with the acronym
  CRUD. (All are procedural and reveal nothing
  about the actors intentions.)
• C - actor Creates data
• R - actor Retrieves data
• U - actor Updates data
• D - actor Deletes data
• Collapse CRUD into one CRUD use case,
  idiomatically called Manage ltXgt.
• Ex. Manage Users use case.

19
Singular or Plural
Naming Use-Cases

• This is usually determined by context.
• There is a preference for the simplest form, but
  most common form can be better.
• In the example of concert tickets, most people
  buy more than one, but a significant number buy
  only one.
• At a supermarket, Buy Items would be best.
• At a vending machine, it would be Buy Item.

20
Use Case Template

• Name
• Primary Actor
• Scope
• Level user-goal or subfunction
• Stakeholders and Interests
• Preconditions
• Success Guarantee
• Main Success Scenario
• Extensions
• Special Requirements
• Technology and Data Variations List
• Frequency of Occurrence
• Miscellaneous (such as open items)

• This is the basic format used in the text and in
  Alistair Cockburns Writing Effective Use Cases
  (Addison Wesley, 2000, ISBN 0201702258).
• See also www.usecases.org

Preface
Optional items
21
User-goal level A complete process from the
view point of a user to meet a goal of the
user, roughly corresponding to an elementary
business process. Subfunction level Details
steps to support a user goal.
22
Define Actors

• Actors should not be analyzed or described in
  detail unless the application domain demands it.
• Template for definition
• Name
• Definition
• Example for an ATM application
• Customer Owner of an account who manages
  account by depositing and withdrawing funds

23
Preconditions and Postconditions

• Preconditions are anything that must always be
  true before beginning a scenario is a
  precondition.
• Preconditions are assumed to be true, not tested
  within the Use Case itself.
• Ignore obvious preconditions such as the power
  being turned on. Only document items necessary to
  understand the Use Case.
• Success Guarantees (or Postconditions) state what
  must be true if the Use Case is completed
  successfully. This may include the main success
  scenario and some alternative paths.
• For example, if the happy path is a cash sale, a
  credit sale might also be regarded a success.
• Stakeholders should agree on the guarantee.

24
(No Transcript)
25
(No Transcript)
26
Scenarios

• The Main Success Scenario, or happy path is the
  expected primary use of the system, without
  problems or exceptions.
• Alternative Scenarios or Extensions are used to
  document other common paths through the system
  and error handling or exceptions.

27
Documenting the Happy Path

• The Success Scenario (or basic course) gives the
  best understanding of the use case
• Each step contains the activities and inputs of
  the actor and the system response
• If there are three or more items, create a list
• Label steps for configuration management and
  requirements traceability
• Use present tense and active voice
• Remember that User Interface designers will use
  this specification
• Note Do not use the term happy path in formal
  documents.

28
(No Transcript)
29
(No Transcript)
30
(No Transcript)
31
(No Transcript)
32
Extensions (Alternative Flows)

• Extensions or Alternative Flow Use Cases allow
  the specification of
• Different ways of handling transactions
• Error processes
• Sections are convenient way to handle alternative
  courses of action
• Sections are a segment of a use case executed out
  of sequence

33
Two Parts for Extensions

• Condition
• Describe the reason for the alternative flow as a
  condition that the user can detect
• Handling
• Describe the flow of processing in the same
  manner as the happy path, using a numbering
  system consistent with the original section.
• 3A. Condition If actor performs action the
  system

34
Documenting Extensions

• Use same format as Happy Path
• Document actions that vary from ideal path
• Include error conditions
• Number each alternate, and start with the
  condition
• 3A. Condition If actor performs action the
  system
• If subsequent steps are the same as the happy
  path, identify and label as (same)
• Steps not included in alternate course are
  assumed not to be performed.

35
(No Transcript)
36
Special Requirements

• If a non-functional requirement , quality
  attribute, or constraint affects a use case
  directly, describe it as a special requirement.

37
Technology and Data Variations List

• Often there are technical differences in how
  things are done even though what is done is the
  same. These things can be described in the
  Technology and Data Variations List.
• For example, if a card reader cannot read the
  magnetic stripe on a credit card, the cashier
  might be able to enter it on the keyboard.

38
Types of Use Cases

• High Level Use Case (Brief)
• Name, Actors, Purpose, Overview
• Expanded Use Case (Fully Dressed)
• Add System Events and System Responses
• Essential Use Case (Black Box)
• Leave out technological implications
• Ex. The system records the sale. (no mention of
  database etc.)
• Concrete Use Case (White Box)
• Specify technology

39
Guideline Defer Decisions

• By using essential use cases as long as possible,
  and only using real use cases during module
  design, you allow time to understand the problem
  before you create a solution. Premature use of
  real use cases often confirms existing technology
  when a better technology might be available.
• Define the problem fully before you start to
  define a solution. Any work that you do on the
  problem domain tends to increase the range of
  possible solutions, while work in the solution
  domain limits your choices.
• You want to be certain that the problem domain is
  large enough to hold some good solutions and
  hopefully an ideal solution before you start to
  narrow your choices.

40
Contrasting Examples

• Essential Style
• ...
• Administrator identifies self.
• Systems authenticates identity.
• Concrete Style
• ...
• Administrator enters ID and passsword in dialog
  box (See Picture 3).
• System authenticates Administrator.
• System displays the edit users window. (See
  Picture 4)
• ...

41
Technology
Types of Use Cases

• The distinction between an essential (black box)
  use case that leaves out technology and a real
  (white box) use case that includes technology is
  fundamental.
• For example, in an Automated Teller Machine, an
  essential use case can mention identification or
  validation, but only a real use case can mention
  a key pad or card reader.

42
Expanded Essential Use Cases(Fully Dressed Use
Cases)
Types of Use Cases

• Purpose
• to allow the system designer and client to
  visualize the flow of actor actions and system
  responses. From this the client will understand
  how users will use the system, and the designer
  will be able to write pseudocode for each
  function. In addition, it is possible to use
  this document to anticipate opportunities for
  user error, which must be accounted for in the
  final system.
• Definitions
• What it is an analysis document which describes
  in detail the elements of functions identified in
  a High Level Use Case.
• What is is not Expanded Essential Use Cases are
  not graphical drawings. They do not include
  stick figures, boxes representing the system, or
  any other icons found in a High Level Use Case
  although they may be associated with one.

43
Expanded EssentialUse Cases
Types of Use Cases

• How to make one
• Step 1 Name the Use Case (system function, e.g.
  enter timesheet information).
• Step 2 Identify the Actor(s) involved.
• Step 3 Describe the Intent of the Use Case in
  language the client will understand.
• Step 4 Identify the Assumptions and Limitations
  relevant to this Use Case and other Use Cases
  which the current one might extend or build upon.
• Step 5 Specify the ideal flow of actions (using
  two columns, if you like) labeled Actor Actions
  and System Responses. Number each step. This
  constitutes the Happy Path for this Use Case.
• Step 6 Identify opportunities for user error and
  create an Alternative Path to handle each.

44
Note (from page 68 of text)
Types of Use Cases

• The example on pages 68-72 of the text of a fully
  dressed use case is very detailed and contains
  just about everything you could put into a use
  case. It is that detailed mainly for
  instructional purposes.
• Almost all use cases are much smaller, usually a
  page or two.

45
Segmentation

• When a use case is repeated, you dont want to
  repeat the contents.
• For example, an alarm clock might show the same
  display when you are setting the current time and
  when you are setting the wake-up time
• Separate out the Display Time use case and
  refer to it in both use cases

46
Extension Use Cases

• Users appreciate simplicity, so most use cases
  leave out alternate courses
• You can do this by extending the use case while
  leaving the original use case alone

47
Warning

• Use cases should not be misused to imitate
  function specification by successive iteration
• Dont refine them until the program is fully
  specified
• The uses relation should only be used when the
  same scenario is encountered more than once

48
Use Cases are always wrong!

• Written documentation gives the illusion of
  authority and correctness, but it is an illusion.
• Use cases give a preliminary understanding that
  users and developers can discuss and agree on.
• But there should be constant feedback from
  customers in the development process to correct
  missing information and misinformation before it
  jeopardizes the functionality of the program.

49
Fig. 6.3 Partial use case context diagram
50
Fig. 6.4 Notation suggestions AND Alternate actor
notation
OR
Payment Authorization Service
51
Fig. 6.6 Use case diagram (context diagram) for
Monopoly system.
52
Use Case UC1 Play Monopoly Game

• Scope Monopoly application
• Level user goal
• Primary actor Observer
• Stakeholder and Interests
• Observer wants to easily observe the output of
  the game simulation.
• Main Success Scenario
• 1. Observer requests new game initialization,
  enters number of players.
• 2. Observer starts play.
• 3. System displays game trace for next player
  move
• Repeat Step 3 until a winner or Observer cancels.
• Extensions
• a. At any time, System fails
• 1. Observer restarts System.
• 2. System detects prior failure, reconstructs
  state, and prompts to continue.
• 3. Observer chooses to continue.

53
Fig. 6.7 Process and setting context for writing
use cases.
54
Association Relationship

• An association is the communication path between
  an actor and the use case that it participates in
• It is shown as a solid line
• It does not have an arrow, and is normally read
  from left to right
• Here, the association is between a Modeler and
  the Create Model use case

55
Relationships in Use Cases

• There are several Use Case relationships
• Association
• Extend
• Generalization
• Uses
• Include
• Most Use Cases have only associations. Use other
  relationships sparingly.

56
Extend Relationship

• Extend puts additional behavior in a use case
  that does not know about it.
• It is shown as a dotted line with an arrow point
  and labeled ltltextendgtgt
• In this case, a customer can request a catalog
  when placing an order.

57
Uses Relationship

• When a use case uses another process, the
  relationship can be shown with the uses
  relationship
• This is shown as a solid line with a closed arrow
  point and the ltltusesgtgt keyword
• Here different system processes can use the logon
  use case

58
Include Relationship

• Include relationships insert additional behavior
  into a base use case.
• They are shown as a dotted line with an open
  arrow and the key word ltltincludegtgt
• Shown is a process that I observed in an earlier
  career.

59
Use Case Example Alarm Clock
This is a contrived example, to show many
relations. Your diagrams should be simpler.
60
Chapter 7OTHER REQUIREMENTS
Fast, Cheap, Good Choose any two. -
anonymous

• Objectives
• Show Supplementary Specification, Glossary,
  Vision Business Rules
• Compare and contrast system features with use
  cases
• Define quality attributes

61
Introduction

• While the primary requirements of a computer
  system tend to be the functional requirements,
• i.e.,the list of activities that the system must
  perform,
• it is also necessary to capture an number of
  other requirements to build a system, called
  non-functional requirements.
• in a Vision Statement, Glossary, Business
  (Domain) Rules and Supplementary Specification.
• Produce only the required (or enough)
  documentation to produce the desired results
  efficiently and effectively.
• Documentation costs money and takes time.

62
Other Requirement Artifacts

• Supplementary Specification
• Captures and identifies other kinds of
  attributes, such as reports, documentation,
  packaging, supportability, licensing, and so
  forth.
• Glossary
• Captures terms and definitions it can also play
  the role of a data dictionary.
• Vision
• Summarizes the vision of the project an
  executive summary.
• Business Rules (or Domain Rules)
• Capture long-living and spanning rules or
  policies, such as tax laws, that transcend one
  particular application.

63
Vision

• When someone joins the project, it is useful to
  be able to say
• Welcome! Please go read the 7-page Vision at the
  project web site.
• It is also useful to have an executive summary
  that briefly describes the project, as a context
  for the major players to establish a common
  vision of the project.

64
The Vision

• The Vision serves to communicate to project
  sponsors and key stakeholders
• the reasons for the project,
• the problems to be solved,
• a description of the stakeholders and their
  needs,
• Root problems and goals,
• along with a description of the proposed
  solution.
• It includes the core requirements and becomes the
  contractual basis to develop further requirements.

65
Topics for a Vision

• Introduction
• Positioning
• Business Opportunity
• Problem Statement
• Product Position
• Alternatives and Competition
• Stakeholder Descriptions
• Market Demographics
• Non-user Interests
• User Interests
• Key high-level goals and problems for
  stakeholders
• User-Level Goals
• User Environment

• Product Overview
• Product Perspective
• Summary of Benefits
• Assumptions and Dependencies
• Cost and Pricing
• Licensing and Installation
• System Features
• Other requirements and constraints

See Section 7.6 NexGen Example
66
Why system features in Vision?

• Use cases are not the only way to describe
  functional requirements.
• Sometimes a succinct list of key functional
  requirements, called system features, will give
  a better immediate grasp of the problem and
  proposed solution.
• A system feature is an externally observable
  service provided by the system which directly
  fulfills a stakeholder need.
• Features are behavioral functions a system can
  do. They should pass the linguistic test
• The system does ltfeature Xgt.

67
(No Transcript)
68
(No Transcript)
69
(No Transcript)
70
Glossary

• The Glossary captures terms and their definitions
  in the business domain supported by the system.
• Be careful. Even simple terms may mean different
  things to different stakeholders and need to be
  defined.
• The Glossary can also perform the role of a Data
  Dictionary, or be supplemented by one.
• Data Dictionary records data about the data, that
  is metadata.
• Aliases - relationships to other
  elements
• Description - range of values
• Format (type, length, unit) - validation rules

See Section 7.8 NexGen Example
71
(No Transcript)
72
Supplementary Specification

• The Supplementary Specification captures such
  requirements as documentation, supportability,
  packaging, licensing and many of the -ilities
  of systems.

73
Supplementary Specifications

• Common Functionality
• Logging
• Error Handling
• Pluggable Business Rules
• Security
• Usability
• Human factors
• Reliability
• Recoverability
• Performance
• Supportability
• Adaptability
• Configurability
• Implementation Constraints

• Purchased Components
• Free Open Source Components
• Interfaces
• Noteworthy hw and interfaces
• Software interfaces
• Application-specific Domain Rules
• Legal Issues
• Info in Domains of Interest
• Pricing
• Credit and Debit Payment Handling
• Sales Tax
• Item Identifiers

See Section 7.4 NexGen Example
74
More Specifications

• Reports
• Operating Systems
• Networking Systems

• Process Tools
• Development Tools
• Design Constraints
• Internationalization
• Standards
• Physical Environment
• Operation Rules

75
(No Transcript)
76
(No Transcript)
77
(No Transcript)
78
Domain Rules

• Domain or Business Rules are not functional
  requirements.
• Domain Rules tell how the business works, while
  functional requirements tell how the system
  works.
• Company policies, the laws of physics, and
  government regulations are examples of Domain
  Rules.

79
Industry Domains

• Most computer consulting firms organize their
  staff by industry, so that they can develop
  application specific knowledge that will be
  useful to the companies hiring them.
• In New Jersey, most consulting companies have at
  least a Telecommunications Practice and a
  Pharmaceutical Practice.
• Other areas might include Retail, Insurance,
  Wholesaling, Light Manufacturing, and Electric
  Utilities.

80
Knowledge Domains

• In addition to Industry specific knowledge, there
  are many areas of knowledge that apply across a
  number of industries.
• The most thoroughly specified of these knowledge
  domains is accounting.
• Others might include inventory, scheduling, and
  queuing.
• Each has a body of specific knowledge that
  specialists know well.

81
Guidelines

• Should we analyze these thoroughly during
  inception?
• Reliable Specifications An Oxymoron?
• Should these artifacts be at the project web site?

82
Requirements Reliability

• Never assume that requirements are completely
  understood, adequately captured, effectively
  described, or reasonably complete.
• Requirements discovery and scope creep tend to
  occur throughout the software development process
  and even after the system is put into production.

83
UML Diagrams in Inception

• Aside from the possible inclusion of a few high
  level use case diagrams, the inception phase is
  almost all text.
• Most diagramming occurs in the Elaboration Phase.

84
Process Evolutionary Requirements in Iterative
Methods
Discipline Artifact Inception Elaboration Construction Transition
Iteration-gt I1 E1En C1Cn T1..T2
Business Modeling Domain Model s r
Requirements Use-Case Model s r
Requirements Vision s r
Requirements Supplementaty Specification s r
Requirements Glossary s r
Requirements Business Rules s r
Design Design Model s r
Design Sw Arch Model s
Design Data Model s r