Modeling%20Requirements%20with%20Use%20Cases:%20A%20Picture%20Says%20a%20Thousand%20Words - PowerPoint PPT Presentation

About This Presentation
Title:

Modeling%20Requirements%20with%20Use%20Cases:%20A%20Picture%20Says%20a%20Thousand%20Words

Description:

Modeling Requirements with Use Cases: A Picture Says a Thousand Words – PowerPoint PPT presentation

Number of Views:116
Avg rating:3.0/5.0
Slides: 84
Provided by: MikeD207
Learn more at: https://ewh.ieee.org
Category:

less

Transcript and Presenter's Notes

Title: Modeling%20Requirements%20with%20Use%20Cases:%20A%20Picture%20Says%20a%20Thousand%20Words


1
Modeling Requirements with Use CasesA
Picture Says a Thousand Words

2
Introduction
3
Requirement
  • 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

4
Requirements Engineering
  • requirements modeling
  • elicit
  • analyze
  • specify
  • validate
  • requirements management
  • project planning
  • baseline
  • prioritize
  • change control
  • trace

5
Eliciting Requirements
6
Sources of Requirements
  • market analysis
  • trends
  • market size and demography
  • competition
  • differentiation
  • business opportunities
  • business engineering
  • business process reengineering
  • system opportunities
  • needs analysis

7
Involve 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

8
Contact Other Stakeholders
  • customer service
  • diagnostics
  • field replaceable units
  • remote access
  • marketing and sales
  • demo modes
  • whiz-bangs

9
Elicitation 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.)

10
Elicitation 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

11
Elicitation Artifacts
  • vision document
  • system scope
  • problem context
  • competitive evaluation
  • product objectives
  • high-level features

12
Elicitation 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

13
Analyzing Requirements
14
Requirements 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

15
Requirements 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

16
Analysis 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

17
Analysis 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

18
Nonfunctional Requirements
  • technical qualities
  • performance
  • capacity
  • reliability
  • extensibility
  • configurability
  • scalability
  • portability
  • maintainability

19
Nonfunctional 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

20
Activity 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

21
Activity 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
22
Swimlane
  • 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

23
Swimlane 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
24
Use Cases and UML
25
UML
  • 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

26
Modeling 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

27
Stereotype
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

28
Actor
  • 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

29
Actor Notation
  • outside of scope of system
  • delineates system boundary

context diagram
actor name
ltltnonhumangtgt actor name
system name
actor name
30
Use 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)

31
Use 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
32
Use 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

33
Association 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
34
Initial Use Case Model
35
Process 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

36
Identifying 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

37
Identifying 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

38
Identifying Actors
  • then focus on supporting actors
  • who installs the system
  • who starts up or shuts down the system
  • who maintains the system

39
Specifying 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

40
Identifying 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

41
Identifying 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

42
Use 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

43
Specifying 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

44
Specifying 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

45
Initial 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)

46
Elaborated Use Case Model
47
Process 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

48
Process 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

49
Flow 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

50
Primary 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

51
Specifying 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

52
Alternative 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

53
Specifying 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

54
Behavioral 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

55
Preconditions 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

56
Elaborated 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)

57
Elaborated 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)

58
Diagram Elaborated Use Cases
  • can use activity diagrams to describe elaborated
    flows
  • visual alternative to text
  • tools allow you to add text to activity states

59
System 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

60
System 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

62
Process Outline
  • iterate around
  • defining interrelationships among use cases
  • encapsulation
  • refactor distinct behavior
  • reusability
  • share distinct behavior among use cases
  • reviewing with all interested parties

63
Include 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

64
Include Notation
  • modeled as stereotyped dependency of use case to
    included use case

Use Case
ltltincludegtgt
ltltincludegtgt
Included Use Case 1
Included Use Case 2
65
Include Example
ltltincludegtgt
Withdraw Funds
Authenticate Customer
Deposit Funds
ltltincludegtgt
66
Another 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
67
Extend 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

68
Extend Notation
  • modeled as stereotyped dependency of extending
    use case to use case

Use Case
ltltextendgtgt
ltltextendgtgt
Extending Use Case 1
Extending Use Case 2
69
Extend 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
70
Generalization
  • 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

71
Generalization Notation
  • modeled as generalization

Parent Use Case
Child Use Case 1
Child Use Case 2
72
Generalization Example
Submit Loan Request
Submit Consumer Loan Request
Submit Business Loan Request
Business Applicant
Consumer Applicant
Applicant
73
Specifying 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

74
Abstract 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

75
Abstract Use Case Example
Generate Report
Generate Insufficient Funds Report
Generate Monthly Report
Bank Officer
76
Structuring 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

77
Structuring 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

78
Domain 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

79
Appendix
80
Lottery 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.

81
Readers 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

82
Readers 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

83
Readers 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)
Write a Comment
User Comments (0)
About PowerShow.com