Object-Oriented Analysis
and Design
Evolutionary Requirements
UP Requirements Artifacts
 Use Case Model – typical scenarios of functional




requirements
Supplementary Specifications – primarily nonfunctional requirements
Glossary – noteworthy terms including a Data
Dictionary (a recording of data requirements)
Vision – high-level requirements and business case
summary
Business Rules – (aka Domain Rules) requirements
or policies which apply to many projects required by
business or domain (e.g. tax laws)
Object-Oriented Analysis
and Design
Use Cases
Read chapter 6
Define the Problem
 The most critical question:
 “Is this the right system to make?”
Use Case Relationships
Business Model
Domain Model
Objects, attributes, associations
VISION
Use Case Model
Requirements
Design
GLOSSARY
SUPPLEMENTARY
SPECIFICATION
Interaction Diagrams
Use Cases are not Diagrams
 Use Cases have a diagram associated with them

easy way for analyst to discuss a process with a
domain expert
 Use cases are primarily text

text = important; diagram = optional
Why Use Cases?
 Simple and familiar storytelling makes it
easier, especially for customers, to contribute
and review goals.
 They keep it simple
 They emphasize goals and the user
perspective


Focus on the essence/intent of requirements
Avoid bias of reproducing the existing system
Identify Use Cases
 Capture specific ways of using the system as
dialogue between an actor and the system.
 Use cases are used to:



Capture functional system requirements
Communicate with end users and Domain
Experts
Test the system
Specifying Use Cases
 Create a written document for each Use Case






Clearly define intent of the Use Case
Define Main Success Scenario (Happy Path)
Define any alternate action paths
Use format of Stimulus: Response
Each specification must be testable
Write from actor’s perspective, in actor’s
vocabulary
Use Case Template Items










Use Case Name
Scope (the system under design)
Level ("user-goal" or "subfunction")
Primary Actor (calls on system to deliver its function)
Stakeholders and Interests (Who cares? What do they
want?)
Preconditions (what must be true at use case start)
Success Guarantee (aka Posconditions; what must be
true on successful use case completion)
Main Success Scenario (happy path/sunny day)
Extensions (alternative scenarios)
Special Requirements (non-functional requirements)
Suggested Other Use Case Items
 Technology and Data Variations (I/O methods
and data formats)
 Frequency of Occurrence (of use case)
 Miscellaneous (e.g. open issues)
 See Use Case UC1: Process Sale p. 68
Naming Use Cases
 A complete process from end user viewpoint
 Usually in verb-object form, (e.g. Register for
Classes)
 Use enough detail to make it specific
 Use active voice, not passive
 From viewpoint of the actor, not the system
Use Case Name Examples
 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)
Singular or Plural?
 Usually determined by context.
 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.
Identify Actors
 Part of understanding a system is knowing
who uses it




Direct users
Users responsible to operate and maintain it
External systems used by the system
External systems that interact with the system
Specifying Actors
 External to the system
 Non-deterministic
 May be different roles for one individual user
 May be other external systems
Identifying Actors
 Primary Actor
 Emphasis
is on the primary actor for the
use case – has goals to be fulfilled
 Stakeholders and Interests
 Other
actors are listed as stakeholders.
 The interests of each key actor should
be described.
Working with Use Cases
 Determine the actors that will 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
Preconditions
 Anything that must always be true before
beginning a scenario is a precondition.
 Assumed to be true, not tested within the Use
Case
 Ignore obvious preconditions (e.g. power is on)
Success Guarantees (Postconditions)
 States what must be true if the Use Case is
completed successfully
 May include the main success scenario and
some alternative paths
 Stakeholders should agree on the guarantee.
Scenarios
 Main Success Scenario, or “happy path” is
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.
Happy Path / Sunny Day Scenario
 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

Two column template works well for this
 If three or more items, create a list
 Label steps for configuration management and
requirements traceability
 Use present tense and active voice
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
Essential versus Real Use Cases
 Essential (black box) use case leaves out
technology and focuses only on functionality
 Real (white box) use case includes technology is
fundamental.
 E.g., essential Withdraw Cash from ATM use
case can mention identification or validation
 Only real Withdraw Cash from ATM use case
can mention a key pad or card reader
Extension Use Cases
 Users appreciate simplicity, so most use
cases leave out alternate courses
 Do this by extending the use case (see Use
Case Diagramming section below) while
leaving the original use case alone
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.
 Use Case often influence the way user
manuals are organized.
Object-Oriented Analysis
and Design
Diagramming Use Cases
read Chapter 30
Actor
 An actor is an idealized user




of a system
Actors can be users,
processes, and other
systems
Many users can be one actor,
in a common role
One user can be different
actors, if in different roles
An actor is labeled in singular
with the name of the role
Non-human Actor
 Actors can be users,
Inventory
System
processes, and other
systems.
 Non human actors typically
shown as rectangle rather
than stick figure
 Usually not primary users,
and thus are usually shown
on the right
Use Case
 Is a coherent unit of externally
visible functionality provided by a
system and expressed by a
sequence of messages
 Additional behavior can be shown
with generalize, extend, and
include use case relationships
 Labeled with the use case name
System
 A system is shown as a
rectangle, labeled with the
system name
 Actors are outside the
system
 Use cases are inside the
system
 The rectangle shows the
scope or boundary of the
system
Don’t forget the boundary and the system name, unless you are using Rational Rose!
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
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 <<include>>
 Shown is a process that I
observed in an earlier career
Extend Relationship
 Extend puts additional,
optional behavior in a use
case that does not know
about it.
 It is shown as a dotted line
with an arrow point and
labeled <<extend>>
 In this case, a customer can
request a catalog when
placing an order
Generalize Relationship
 Is a relationship between a
general use case and a more
specific use case that inherits
and extends its features
 It is shown as a solid line with
a closed arrow point
 Here, the payment process is
modified for cash and charge
cards
Use Case Example: Alarm Clock
This is a contrived
example, to show
many relations.
Your diagrams
should be simpler.