Authoring Use Cases
(Filled and Focused)
from Use Case Modeling, by Bittner
and Spence, Chapters 4, 6, and 7
1
Introduction
 We:
 Know that Use Cases represent / can
capture the functional requirements of
an application.
 Know that there are ‘levels of maturity’
of Use Cases.
 Know about Façade Use Cases and
 Know about the use of a template.
 Know different organizations will likely
require different formats, attributes…
2
Use Case Number:
Recall the format
we will use:
Use Case Name:
Actor (s):
Maturity:
(Façade/Focused/…
Summary:
Basic Course of Events:
Alternative Paths:
Exception Paths:
3
Actor Action
System Response
Extension Points:
Triggers:
Assumptions:
Preconditions:
Post Conditions:
Reference: Business Rules:
Reference: Risks
Author(s):
Date:
4
Façade Use Cases
 Also recall facts about Façade Use Cases:
 Identify the Use Cases
 Placeholders
 Help to establish a framework for further
maturity development
 Help to establish application boundary
 Contain a number of attributes, but no basic
course of events is included.
 Often features may map one to one to a use
case if feature is general (abstract) enough.
5
Outline the Use Case
 Use Cases can be:
 a short as half a page to
 as long as a number of pages
 Whatever is required to capture both the
basic and alternative flows in a form that
satisfies ALL of the stakeholders.
 If at all possible, abstract out some of
the details (glossary; domain model;
subflows, include and extend use-cases).
 KISS.
6
Start off with an Outline of Use Case
 Start off with the Use Case name, a brief
description of the use case and identify actors
(persons, systems, …)
 Identify the basic flow of events as steps.
 Walk through these! This is an art!
 Enumerate the alternate flows as A1, A2, etc.
 just an outline here.
 Will undertake the real use case authoring shortly.
 Example:
7
Sample Outline – Withdraw Money


Basic Flow (Outline format)
 Insert Card
 Validate Card
 Validate Bank Customer
 Select Withdraw
 Select Amount from List of Standard Amounts
 Confirm Transaction with Banking System
 Dispense Money
 Eject Card
List of Alternate Flows
 A1. Card cannot be identified
 A2. Customer cannot be identified
 A3. Withdraw not required
 A4. Non-standard amount required
 A5. No money in the account
 A6. Attempt to withdraw more than daily amount
 A7. No connection to the banking system
 A8. Link goes down
 A9. Card stolen – the card is on the hot-card list
 A10. The ATM is out of money
 A11. The card cannot be dispensed
 A12. A receipt is required
 A13. The withdrawal is not from
the card’s primary account
8
  etc.
Sample Outline - Comments
 Can see from outline format
 some are core functionalities
 some are extra, or complementary functions
 e.g. If receipt is always required, A12 is NOT an
alternate flow (found in basic flow).
 some are non-essential flows (like
withdrawing from other accounts than
primary)
 Might not be needed.
 Must be able to Trace the use cases back
to business rules, features, constraints, …
 Don’t create requirements that do not
trace back to required features!
9
There are a number of other
Use Case Styles
10
Sample Conversational Form
User Action
System Response
. . .
Display product offerings showing
categories selected by user
Browse product offerings
Select items for purchase
For each selected item in stock record
select items and quantities, reserving
them in the inventory
Prompt for payment instructions
Provide payment instructions
Record payment instructions capturing
payment terms and credit card type, number
and expiration date using secure protocol
Prompt for shipping instructions
Provide shipping instructions
Record shipping instructions, capturing
billing address, shipping address
preferences, and delivery options
Complete transaction
11
Record transaction and provide receipt
containing a list of the products ordered,
their quantity and prices as well as
payment terms. Credit card information
should be partially omitted, displaying only
the last four digits of the cc number.
Comments – on Conversational Style
 Good for single actor; where system/actor
engage in interactive dialog.
 Can contain a lot of detail – good – but this
can become a liability.
 Not good for capturing a number of actors
 Not good for complex responses, like
controlling an antilock braking system.
12
A Short List of Styles
 Outline formats – extremely cryptic.
 Conversational Format (shown)
 Narrative formats in sentence format




 The user ….
 The system ….
 The system…
 The user…. (almost like prose)
Flexible format; can show multiple actions and
actors.
Supports ongoing evolution of use case and use of
subflows….
 Often the preferred format for complex systems.
This one is our choice…
 There are other formats too, naturally…
13
Sample “Maturity Levels” 
 Bittner and Spence:






Discovered
Briefly Described
Bulleted Outline
Essential Outline
Detailed Description
Fully Described….
 Kulak and Guiney:




Façade
Filled
Focused
Finished (eliminated this one in latest book)
14
 Other authors: other ‘maturity levels.’
Flows in Use Cases
 Many and varied.
 ‘Captured’ differently by different
authors.
 Called different things by different
authors.
  Doesn’t really matter what they are
called as long as the alternate flows
(all kinds) are indeed captured and
understandable by all stakeholders.
15
Subflows, Alternate Behaviors, Extension Points
 Subflows: Some Use Cases are simply just
complex and long.
 It is often best to remove some of the detail
and/or complexity (factor it out), and
 Break it up into more manageable segments.
(Subflows)
 We may abstract these parts out of basic flow.
 This means we put some kind of note or
designator or some kind of tag or notation into
the flow to indicate that another segment ‘goes
here.’
16
Subflows, Alternate Behaviors, Extension Points
 Alternate Behaviors: Some use cases need to capture and
insert alternate behaviors that are not necessarily
“conditional,” but ‘may’ be… ) (Alternates)



Paths that are perhaps just not quite as likely as the Basic Course
of Events, but still viable paths!
E.g. Withdraw money from savings account vice checking.
Not ‘happy path’ but still quite commonly done.
 Exceptional Behaviors: Some use cases have behaviors
that are executed conditionally. (Exceptions)


especially error conditions – would be executed if some kind of
unexpected condition occurs.
Some people call things like – not enough money in account as an
exception; others might call this an alternative.
17
Subflows, Alternate Behaviors Extension Points
 Extension Points: Some use cases have the need
to be able to insert additional placeholders,
 to bound statements, or
 to tag alternate behaviors that may/may not be
“conditional.”
 Also need a syntax for indicating WHERE in the flow
of events, these other behaviors inserted, referenced,
etc. (Extension Points).
 Further, upon ‘branching’ to these behaviors, we
need to be able to unambiguously indicate where the
return, if any, should be.
  Essential thinking for mature use cases.
  Let’s look at these in more detail…
18
Subflows (1 of 4)
 Subflows are often used
 for complex use cases.
 to break down the complexity of some use cases.
 Different authors have different styles…
  Normally (not always) a subflow may be
given a tag of S1 (, …, Sn) and/or a name.
 Subflows are documented separately rather
than inserting text in line …and cluttering basic
flow.
 Executions are atomic.
 Use Case can ‘perform’ subflows in optional
sequences or in loops or even several at a
time.
 Abstracting in ‘higher19 level flow’ greatly
assists ‘complexity.’
Subflow Examples (2 of 6)
 Within the body of the flow of events, one might see the
specification:
The system captures the payment instructions using a secure prototcol
Perform Subflow Validate Payment Instructions
The system prompts the Customer to enter shipping instructions
The system captures the shipping instructions using a secure protocol
Perform Subflow Validate Shipping Instructions
…
 Another example within the body of the flow of events:
The client logs into the application
Perform Subflow S1 Login

….
(In this case, Login is not an “included” use case…)
20
Sample Subflow Login Narrative (3 of 4)
Subflow: S1 Login
1. When the user enters the system for the first time, the system prompts
the user for a password
2. The user enters this password (the system echos only ‘*’
characters to the screen as they do so). When the user
indicates (note: no implementation details…) completion of entering
the password, the system compares the password to the one associated
with the user’s profile.
3. If the password matches, the user is granted access to the
system and the use case continues  note this…we’d ‘return.’
If the user does not enter the correct password the system
reports that the password is incorrect
i. The user is given two additional opportunities to enter
the correct password
ii. If the user fails to enter a correct password in three
attempts, the system logs the failure attempt date
and time along with the user profile and the user
is logged off the system
b. If the password finally matches, the user is granted access to the
system and the use case continues
 note this; return otherwise,
21
the system reports that the password is incorrect.
Subflows – more (4 of 4)





Must be documented as a flow of events.
Notice: “Perform” or “Do”….
Like a subroutine / subprogram ‘call.’
Captures specific functionality…
A great way to reduce complexity and
clutter and yet keep essential
functionality.
22
Extension Points (1 of 7)
  Extension Points are named places in
the flow of events where additional behavior
can be inserted or attached.
 May be ‘private’ (used only in the user case in which
they appear) or ‘public’ (used by other extending
use cases).
 Can be found anywhere in flow of events.
 Within a flow of events, extension points are
shown in bold and enclosed in curly brackets
(braces)
 Example: {Display Product Catalog}, {Out of
Stock}, {Process the Order}, and {Order
Processed}.
  These extension points are normally
included as text in the Extension Point attribute
of a standard Use Case template.
23
Extension Points – (2 of 7)
 There are no specific naming conventions for
extension points.
 The named extension point should sum up
or capture some aspect of where the position
is in the use case such as {Process Order} or
what the use case has achieved, such as,
{Order Processed} (like a ‘comment’)
 Extension Point is like a ‘tag’ or ‘label’
 While the extension point can normally occur
anywhere in flow of events, it is best
implemented when placed on their own line
and not embedded in a chunk of text.
24
Extension Points – (3 of 7)
 Three kinds of extension points
 1. A single location – here, it defines a
single point in the flow of events
(inserted behavior)
 2. May be used to define a ‘state’ that
the flow of events is in. (May appear
multiple times)
 3. May delineate a range of activities,
that is, mark off a set of activities
(begin…end)
 Examples: (next two slides)
25
Use Case Including Extension Points (4 of 7)
(In the flow of events)
1. The use case starts when the actor Customer
selects to browse the catalog of product offerings
{Display Product Catalog}
(Note that this is: on a line by itself, and is an example of
the ‘state’ the use case is in… and is an example of type 2
(see previous slide)). Next interchange shows this.
2. The system displays the product offerings
highlighting the product categories associated
with the Customer’s profile.
{Select Products}
(Note again, an example of type 2: shows the state the flow
26
is in.) Actor is selecting products…
Use Case Including Extension Points (5 of 7)
(In the flow of events) – Continuing…
3. The Customer selects a product to be purchased,
entering the number of items required.
4. For each (note: implies iterative behaviors) selected
item that is in stock, the system records the product
identifier and the number of items required, reserving
them in the inventory and adding them to the
Customer’s shopping cart.
{Out of Stock}
(This is an example of type 1 extension point. Behavior
can be placed here or ahead…addressed ahead)
5. Steps 3 and 4 are repeated until the Customer selects
to Order the Products.
{Process the Order}
(Again, shows the state the flow is in. type 2)
6. The system prompts the Customer
to enter payment
27
instructions.….
Use Case Including Extension Points (6 of 7)
(In the flow of events)
Recall the {Out of Stock} extension point:
This extension point may be placed in multiple
places in the flow of events if there were/are
multiple places where the use case is dependent on
the system not being out of stock. In this case, the
behaviors would be documented separately –
perhaps at the end of the use case.
Or
{Out of Stock} //additional behavior could be placed
in here in line if the condition only appears once
(style).
Clearly the reference would be preferred to inline
behavior if the condition 28appears multiple times.
Example of Extension Point (7 of 7)
 And…example of the third kind:
In a use case for a system that controls a
pump to dispense fuel, you could delimit
the section of the flow of events where
fuel is being dispensed with extension
points:
{pump activated}
…
…
{pump deactivated}
29
Alternate and Exception Behaviors (1 of 6)
 Note: These are alternate or exceptional
behaviors.
 Always dependent upon some condition
occurring at an explicit point in a flow of events.
 Alternate / Exceptional Flows are conditional flows!
 Conditional flows are not necessarily errors.
 Conditional flows may be choices the user makes
 Conditional flows may be errors.
 May be absolutely essential flows basic to the Use Case
 Reference alternative / exceptional
behaviors in the Use Case Narrative?
 Can use ‘step’ references, such as A4 or E6, or
 Reference them numerically,
A1, A2, E1, …or, use a
30
 name like an Extension Point or combination…
Alternate and Exception Behaviors (2 of 6)
 Three kinds:
 1.

 2.

General Alternate Flow
Can start at any point within a use case
Specific Alternate Flow
Can start at a specific named point in another
flow of events (public reference)
 3. Bounded Alternate Flow
 Like the general flow, but can only occur
between two named points.
 First, the syntax for alternative flows…
31
General Alternative Flows (3 of 6)
 Alternative (and exception) flows are named and
numbered.
 Can number the alternative flow A1…An that
captures the purpose. (may have a name too)
 The first line of the alternative flow’s flow of
events identifies the point at which the
alternative will be activated and the conditions
under which it will occur.
 This clause is always of the form:
At {extension point} when <some event occurs>…
or
At {extension point} if <some event occurs>
(two and three slides ahead)
32
General Alternative Flows (4 of 6)
 Before looking at an example, note: The last line of the
alternate flow and any other exit points within it must
state explicitly where the actor resumes the flow of
events!
 may be where original extension point was triggered, or
 may be at some other extension point elsewhere in the flow
of events – unless the use case ends.
 If behavior is optional, return is normally to the original
extension point and flow may continue there or at some
other designated point.
 For ‘exceptional’ (e.g. error condition) behavior, return
may be to the end of the use case
 (If use case ends in the alternative
flow, then an explicit
33
‘use case ends here’ needs to be included.)
Examples of Specific alternate flow (5 of 6)
 A3. Product Out of Stock
 Could indicate this in Extension Points attribute.
At {Out of Stock}, if there are insufficient
amounts of the product in the inventory to
fulfill the Customer request, the system
informs the user that the order cannot be
fulfilled
(… the flow continues to describe the offering of
alternative amounts and products to the customer)
The flow of events is likely resumed from
the point at which it was interrupted.
However, the use-case might end here too.
34
Example of a Bounded Alternate Flow
 A1. Undertake a Keyword Search
 Documentation:
At any point between {Display Product Catalog}
and {Process Order}, when the Customer selects
to undertake a keyword search
The system prompts the Customer to enter the
product search criteria
The Customer enters the product search criteria
(…the flow continues to describe what the Customer
and the System do to complete the search…)
The flow of events is resumed at {Select Product}
35
Summary
 So, there is no ‘one style fits all.’
 Remember: the most important
thing – by far – is to be certain to
capture and document all the
required functionality.
 Ensure sufficient detail is present to
support follow-on design.
 All the ‘whats’ must be addressed.
36