Title: Modeling%20Requirements%20with%20Use%20Cases:%20A%20Picture%20Says%20a%20Thousand%20Words
1Modeling Requirements with Use CasesA
Picture Says a Thousand Words
2Introduction
3Requirement
- a condition or capability needed by a user to
solve a problem or achieve an objective - a condition or capability that must be met or
possessed by a system component to satisfy a
contract, standard specification, or other
formally imposed document - from user or evolves from user requirement
4Requirements Engineering
- requirements modeling
- elicit
- analyze
- specify
- validate
- requirements management
- project planning
- baseline
- prioritize
- change control
- trace
5Eliciting Requirements
6Sources of Requirements
- market analysis
- trends
- market size and demography
- competition
- differentiation
- business opportunities
- business engineering
- business process reengineering
- system opportunities
- needs analysis
7Involve Stakeholders
- customers
- promote and sustain the vision of the product
- users
- participate in behavioral contracts with the
system - business analysts
- facilitate and write the use cases
- subject matter experts
- know how the business ought to work
- quality engineers
- process improvement
8Contact Other Stakeholders
- customer service
- diagnostics
- field replaceable units
- remote access
- marketing and sales
- demo modes
- whiz-bangs
9Elicitation Techniques
- existing literature
- working guidelines
- current workflows
- previous proposals
- in-house and customer visits
- interviews
- let people think aloud while walking through
tasks - list entities that people use or reference
- form, folder, image, etc.
- get their attributes
- concentrate on tag lines (create, read, update,
delete, etc.)
10Elicitation Techniques
- questionnaires
- workshops
- joint requirements planning (e.g., JAD) sessions
- conducted by facilitator
- restates peoples words into a question
- directs questions
- proposes summaries of peoples judgments about
aspects of a task
11Elicitation Artifacts
- vision document
- system scope
- problem context
- competitive evaluation
- product objectives
- high-level features
12Elicitation Artifacts
- business case
- cost/benefits assessment
- return on investment
- technical assessment/alternatives
- staffing
- schedule
- risk factors prioritized
- dependence on changing technology
- window size
- experience of team
13Analyzing Requirements
14Requirements Analysis
- uses abstraction to understand the nature of a
problem - uses models to express the requirements in the
semantics of the users - complete
- consistent
- unambiguous
15Requirements Analysis
- models provide communication to
- project managers
- provides a basis for scheduling incremental
releases - human factors
- know what storyboards need to be prototyped
- software architects
- know how to create the blueprint for a system
- developers
- gives them an intuitive feel of the system to be
realized - testers
- gives them verifiable features for a test plan of
the system
16Analysis Artifacts
- activity diagrams
- current workflows or concepts of operation
- use case model
- behavioral requirements (what the software does)
- represents an outside-in perspective
- roles distributed among users
- responsibilities carries out by system responses
- glossary
- catalog of domain terms
- can evolve into an object analysis model
17Analysis Artifacts
- nonfunctional requirements
- what the software is
- UI usability and details
- navigation diagrams
- prototypes
- business policies and rules
- external and internal constraints that govern how
a business is run - likely apply to several use cases
- domain model
18Nonfunctional Requirements
- technical qualities
- performance
- capacity
- reliability
- extensibility
- configurability
- scalability
- portability
- maintainability
19Nonfunctional Requirements
- technical constraints are restrictions on the
degree of freedom to provide a solution - hardware
- memory
- storage
- peripheral devices
- media
- software
- operating system
- language
- tools
- database
- middleware
20Activity Diagram
- models as-is workflows
- visualizes flow of events as an alternative to
text - special state diagram
- activity
- state with a non-atomic action to be performed
- transition
- automatic control flow between activity states
- can divide into multiple transitions that create
parallel activities - decision
- for a set of alternate transitions with a set of
conditions - condition
- Boolean expression that guards a transition
21Activity Diagram Notation
start point
Detect card
invalid
condition
Eject card
transition
valid
activity
Verify PIN
Customer
incorrect
decision
Handle bad PIN
correct
resolved
Withdraw amount
unresolved
Authorize transaction
Central Bank
22Swimlane
- visually partitions an activity diagram
- noted by a vertical solid line
- represents a responsibility for part of the
overall activity - corresponds to an organizational unit in a
business model - separates external interaction from system
response
23Swimlane Notation
Customer
ATM
Central Bank
Insert card
Detect card
invalid
Eject card
valid
Ask for PIN
Enter PIN
Verify PIN
incorrect
Handle bad PIN
correct
resolved
Ask for function
Enter account and amount
unresolved
Authorize transaction
Check records
24Use Cases and UML
25UML
- object-oriented modeling language for
software-intensive systems - specifies
- visualizes
- constructs
- documents
- independent of
- object-oriented programming languages
- development processes
- metamodel
- establishes a conceptual framework for specifying
models
26Modeling Elements
- actor
- an external agent that interacts with the system
- use case
- a way in which the system is used by its actors
expressed from their perspective - relationship
- association between an actor and a use case
- dependency between use cases
- generalization among use cases
27Stereotype
ltlt . . . gtgt
- an adornment that extends the UML notation
- defines new semantic meaning to a model element
- typically specifies the usage context of an actor
or relationship - enclosed in guillemets
- ltltangled bracketsgtgt are an acceptable
alternative - stereotyped elements can be rendered by icons
- either 0 or 1
28Actor
- external agent that needs to exchange
information with the system - a single abstractive role played by multiple
instances - person, company, organization
- another system, persistent data source,
peripheral - primary actors
- directly obtain value from the behavior of the
system - supporting actors
- provide services that help primary actors use the
system - internal actors
- used if use cases describe details of how parts
of a system (e.g., subsystems) cooperate
29Actor Notation
- outside of scope of system
- delineates system boundary
context diagram
actor name
ltltnonhumangtgt actor name
system name
actor name
30Use Case
- abstracts a coherent function or feature of a
system that is actor-centric - achieves the actors goal while protecting the
interests of the other actors - can be completed in a single session
- describes a sequence of interactions between the
system and its actor(s) - expresses the behavioral requirements of the
system to be - triggered by an event sent by an actor
- can be triggered by a scheduled temporal event
(clock)
31Use Case Notation
use case name
use case name
actor name
use case name
actor name
use case name
use case name
actor name
system name
32Use Case Association
- ltltcommunicatesgtgt type of structural connection
between an actor and a use case - actor can associate with many use cases
- use case can associate with many actors
- bidirectional
- applies to events to and from the system
- usually unidirectional to indicate initial flow
- active for actors that initiate a use case
- initial stimulus is a triggering event
- primary or supporting actor
- passive for actors that only collaborate in a
use case - typically a supporting actor that provides a
service or receives data
33Association Notation
ltltcommunicatesgtgt event
ltltcommunicatesgtgt event
use case name
ltltcommunicatesgtgt event
actor name
use case name
actor name
ltltcommunicatesgtgt event
use case name
ltltcommunicatesgtgt event
ltltcommunicatesgtgt event
actor name
system name
34Initial Use Case Model
35Process Outline
- iterate around
- identifying system boundary with actors
- identifying each actors goals when interacting
with the system - expressing goal statements with essential use
cases - reviewing with all interested parties
36Identifying Actors
- focus on primary actors first
- characterize humans
- who uses the system
- who provides events and data to the system
- who gets information from the system
- which users communicate with each other
- may communicate outside of system
- secondary actor uses an actor as a facilitator
- do not let job titles dictate actors
37Identifying Actors
- characterize nonhuman interface points
- what other systems use this system
- data providers
- legacy feeds
- what other systems does this system use
- report consumers
- legacy systems
- off the shelf products
- what other devices does this system use
- does an external timer trigger system responses
38Identifying Actors
- then focus on supporting actors
- who installs the system
- who starts up or shuts down the system
- who maintains the system
39Specifying Actors
- human actor names tend to end in er
- brief description of
- responsibilities of a human user
- skill set
- work environment
- interface characteristics of a nonhuman actor
- active or passive communication
40Identifying Use Cases
- identify before specifying
- business process people specify actors and
identify goals that they need to achieve - business use case
- actors are all roles involved in the essential
enterprise - primary actors are active (users)
- supporting actors are passive
41Identifying Use Cases
- development team specifies actors and identify
goals that they need to achieve - system use case
- actors are roles entering into direct contact
with the software system - supporting actors are active and passive
- consider
- startup and shutdown
- installation
- backup and recovery
- diagnostics
- report generation
42Use Case Granularity
- initial use cases are placeholders
- provide functional scope and coverage
- granularity
- relative scope of use cases compared to the
applications scope - no metrics to determine correct granularity
- each use case must provide the big picture for
a subset of system functionality without
requiring an army of analysts to work on it - a medium-sized software system may have 50-75
43Specifying Use Cases
- name with an active verb-noun phrase from primary
actors viewpoint - Rent a Video
- start simple, with low precision
- high-level description from external perspective
- reflects essential goal
- specify macro-functionality
- black-box in scope
44Specifying Use Cases
- use narrative prose
- paragraph with a few sentences or probably too
big - sentences are sub goals
- natural language
- vocabulary of user
- unconstrained by technology or design decisions
- focus on what and when of system and actor
interactions - emphasize interaction as a conversation
45Initial Use Case Template
- Unique identifier
- name and optional number
- Actors
- primary or supporting
- Goal description
- actors expectations of value from using the
system - Nonfunctional requirements
- technical qualities, constraints (Keyword
requirement)
46Elaborated Use Case Model
47Process Outline
- iterate around
- defining primary flow of events
- expanding on the what and when of system and
actor responsibilities - specifying micro-functionality
- more white-box in scope
- emphasize system responses and resulting state
changes - introduce concrete technology constraints
- defining alternative event flows
- adding preconditions and postconditions
48Process Outline
- expanding on the what and when of system and
actor responsibilities - detailing the behavioral contract between the
system and its actors - system sequence diagrams
- reviewing with all interested parties
49Flow of Events
- a use case is a crisscrossing story line of
success and failure paths related to a single
goal - one primary flow of events (typically)
- precondition and trigger are condition under
which it runs - everything goes right (happy path)
- no branching
- zero or more alternative event flows
- other user choices
- exception to assumptions, preconditions, or
postconditions that result in error paths
50Primary Flow of Events
- add precision step-by-step
- number the steps
- typically 3-15 steps in primary flow
- can use a nested numbering scheme
- clearly describe trigger event that initiates use
case - describe when use case terminates
- each step is one simple action
- actor interaction
- validation step
- internal state change
- can reference which business rules are enforced
51Specifying Primary Event Flows
- guidelines
- use active voice
- when the actor does ...
- system responds ...
- write from a birds eye view
- a step can add details to a goal or add a sub
goal - use simple grammar
- clearly indicate the actors involved
- show actors intent, not the user interface
movements - validate or verify, do not check whether
- indicate while or repeat of steps for
iterations
52Alternative Flow of Events
- first brainstorm all possible what happens if
situations (success and failure) - then work out how the system deals with each one
- for each step in primary flow of events determine
- is there some other success action that can be
taken - is there something that could go wrong
- does inaction by primary or supporting actor
cause a timeout - is there some behavior that happens periodically
- is there some behavior that could happen anytime
- is there some behavior that must occur within
critical performance requirements
53Specifying Alternative Flows
- relate alternative flow to step of primary flow
and assign a letter - write elaborated sequence of steps or brief
description - indicate whether primary flow continues, jumps,
or aborts - for example, if alternatives occur in step 2 of
primary flow - 2a. alternative condition
- .1
- .2 ...
- 2b. alternative condition
- .1
54Behavioral Constraints
- assumptions
- constraints outside of system that must be in
place before a use case can be triggered - preconditions and postconditions
- constraints inside the system that attach
functional restrictions to a use case
55Preconditions and Postconditions
- preconditions
- constraints in effect before a use case can be
triggered to perform its behavior - can indicate other use cases
- specify using present tense
- postconditions
- constraints in effect after a use case has
completed its behavior - includes success guarantee, minimal guarantee on
failure, and aborted failure paths - provide verifiable and testable requirements
- specify using shall format
56Elaborated Use Case Template
- Unique identifier
- name and optional number
- Actors
- primary or supporting
- Assumptions
- conditions outside of control of system that must
be true (numbered) - Preconditions
- observable states of system that must be true
before the use case can be triggered (numbered)
57Elaborated Use Case Template
- Goal description
- actors expectations of value from using the
system - Flow of Events
- primary flows
- alternative flows
- Postconditions
- observable state of the system after the use case
executes (numbered) - Nonfunctional requirements
- technical qualities, constraints (Keyword
requirement)
58Diagram Elaborated Use Cases
- can use activity diagrams to describe elaborated
flows - visual alternative to text
- tools allow you to add text to activity states
59System Sequence Diagram
- clarifies interaction across system boundary
between actors and the system - defines temporal order of communication events
- includes data flows
- 1 per each flow of events
- only objects are actors and system as a black-box
- useful as a user interface prototype
60System Sequence Notation
object
ATM
Central Bank
Customer
time
validate card read mag strip
insert card
ask for PIN
enter PIN (num)
verify PIN
text description of use case
ask for function
enter function (type)
lifeline
ask for account
system event
enter account (type)
ask for amount
enter amount (value)
authorize (transaction)
61- Structured Use Case Model
62Process Outline
- iterate around
- defining interrelationships among use cases
- encapsulation
- refactor distinct behavior
- reusability
- share distinct behavior among use cases
- reviewing with all interested parties
63Include Relationship
ltltincludegtgt
- a step in a use case that constitutes a
significant end-to-end flow can be factored and
referenced as an included use case - included use case
- behavior is required, not optional
- no associated condition
- may capture common behavior across use cases
- allows most precise white-box description of
behavior - use case
- has knowledge of included use case
- makes full use of included use case
- depends only on result, not method of achieving
result
64Include Notation
- modeled as stereotyped dependency of use case to
included use case
Use Case
ltltincludegtgt
ltltincludegtgt
Included Use Case 1
Included Use Case 2
65Include Example
ltltincludegtgt
Withdraw Funds
Authenticate Customer
Deposit Funds
ltltincludegtgt
66Another Use for Include
- when a use case is too high-level and broadly
defined, its whole can be completely broken out
into its parts with an include relationship - a hierarchy of superordinate and subordinate use
cases - modeled as stereotyped dependency of
superordinate use case to subordinate use cases
Subordinate Use Case 1
ltltincludegtgt
Superordinate Use Case
Subordinate Use Case 2
ltltincludegtgt
67Extend Relationship
ltltextendgtgt
- additional end-to-end flow not part of primary
flow and alternative flows can be factored - extending use case
- embedded in use case under a may-be condition
- may add actors
- may capture common behavior across use cases
- often represents optional or low priority
behavior deferred to later incremental releases - use case
- is complete on its own, not tightly coupled to
extending use case - extension point indicates where extending
behavior is executed and where control is returned
68Extend Notation
- modeled as stereotyped dependency of extending
use case to use case
Use Case
ltltextendgtgt
ltltextendgtgt
Extending Use Case 1
Extending Use Case 2
69Extend Examples
Store Image
Search for Image
Retrieve Image
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
Collect Statistics
Use Word Processor
Get Mail
Create Spread Sheet
ltltextendgtgt
ltltextendgtgt
ltltextendgtgt
Authenticate User
70Generalization
- use cases exhibit a parent-child relationship
- parent use case
- captures common behavior as a separate generic
pattern that is always shared by children - has no knowledge of children use cases
- child use case
- inherits all behaviors, extensions points,
relationships of parent - can add new behaviors and specialize behaviors
- is not complete on its own, is tightly coupled to
parent for completion - different actors sharing a common role may
inherit an actor as a super role
71Generalization Notation
- modeled as generalization
Parent Use Case
Child Use Case 1
Child Use Case 2
72Generalization Example
Submit Loan Request
Submit Consumer Loan Request
Submit Business Loan Request
Business Applicant
Consumer Applicant
Applicant
73Specifying Generalization
- each step of child use case should be documented
as either - inherited from parent use case and unchanged
- inherited from parent use case and specialized
- new
74Abstract Use Case
- a use case that cannot be instantiated and
executed on its own - always used in execution of another use case
- triggered by an event in the other use cases
flow of events - does not need to have an active association with
an actor - indicates a most reusable facility
- can apply to included, extending, and parent use
cases in structured model
75Abstract Use Case Example
Generate Report
Generate Insufficient Funds Report
Generate Monthly Report
Bank Officer
76Structuring Recommendations
- elaborate all use cases before identifying use
case relationships - do not put too much effort into structuring use
cases - good for identifying reusable facilities from
common business workflows - eliminating redundancy of text is not a goal of
structuring - try not to use extend
- at worst, leave it as a conditional include
77Structuring Recommendations
- try not to use generalization
- diagrammatic simplicity but textual complexity
- use cases must be understandable to communicate
- do not apply the include relationship to create
a hierarchy of subordinate use cases until
reaching atomic use cases - like functional decomposition
- should avoid unnecessary detail
- based on CRUD considerations instead of business
workflows and interactions between actors and
system - thinking from a programmatic design perspective
78Domain Glossary
- vocabulary of domain terms
- description of business context
- data attributes
- relationships to other domain terms
- conditions and events
- synonyms and related terms
- examples
- constructions and destruction moments
- privileges
79Appendix
80Lottery Kiosk
- The business opportunity is a kiosk that
automatically dispenses lottery tickets. During
one sale, a customer deposits money, chooses
numbers, and the kiosk dispenses the ticket. A
quick pick option exists where the kiosk chooses
a random set of numbers. The customer must
insert the correct money and enter valid numbers
within time limits. The kiosk processes the data
and sends it to a main computer at lottery
headquarters. - The kiosk accepts U.S. money in coins (nickels,
dimes, quarters) and bills (1, 5). Any money
that cannot be validated is returned to the
customer. The kiosk returns the proper change in
coins. The customer can request a refund of any
deposited money in coins prior to number
selection. - The kiosk can be unavailable because it runs out
of paper or change or receives a message from
lottery headquarters to go offline. - An operator regularly restocks the printer with
tickets, refills the change dispenser, and
collects the deposited money. A technician
performs system diagnostics when the kiosk
internally fails.
81Readers Guide
- Armour, F. and Miller, G., Advanced Use Case
Modeling, ISBN 0-201-61592-4 - Booch, G., Jacobson, I., and Rumbaugh, J., The
Unified Modeling Language User Guide, ISBN
0-201-57168-4 - Cockburn, A., Writing Effective Use Cases, ISBN
0-201-70225-8 - Eriksson, H. and Penker, M., UML Toolkit, ISBN
0-471-19161-2 - Fowler, M. and Scott, K., UML Distilled Applying
the Standard Object Modeling Language, ISBN
0-201-32563-2
82Readers Guide
- Harmon, P. and Watson, M., Understanding UML The
Developers Guide, ISBN 1-55860-465-0 - Jacobson, I., et. al., Object-Oriented Software
Engineering A Use Case Driven Approach, ISBN
0-201-54435-0 - Kulak, D. and Guiney, E., Use Cases Requirements
in Context, ISBN 0-201-65767-8 - Muller, P., Instant UML, ISBN 1-861000-87-1
- Rosenberg, D. and Scott, K., Use Case Driven
Object Modeling with UML, ISBN 0-201-43289-7
83Readers Guide
- Schneider, G. and Winters, J., Applying Use
Cases A Practical Guide, ISBN 0-201-30981-5 - Warmer, J. and Kleppe, A., The Object Constraint
Language Precise Modeling with UML, ISBN
0-201-37940-6 - Programmers Report, SIGS Publications
- Dr. Dobbs Journal, Peoples Computer Co.
- http//www.omg.org (follow links)