Modeling System
Requirements with Use Cases
1
Why Do We Need Use Cases?
• Primary challenge in a system design
process
– ability to elicit correct and necessary system
requirements from stakeholders
– specify requirements in a manner
understandable to users so they can be
verified and validated.
– SDLC models understood by designers not by users.
– Leads to scope creep, schedule creep, cost overruns.
2
IS Development Project Track
Record
canceled
before
completion
Over budget,
late, or without
needed features
Source: The Standish Group International, Inc., “Chaos: A Recipe for Success”
3
Introduction
Use-case modeling – the process of modeling a
system’s functions in terms of business events,
who initiated the events, and how the system
responds to those events.
– roots in object-oriented modeling (question1 )
– Gained popularity in non-object development
environments because of its usefulness in communicating
with users
– Compliments traditional modeling tools
• Focuses on Users and their tasks
• Logical model
4
Role of Use Cases
• Describes how system reacts to an event
that triggers the system
– Trigger – event that causes the use case to
be executed (opening the app, pushing a
button)
– Event-driven modeling
• All possible system responses are
documented
5
Use Case
• Process
– Gather requirements from users
– Prepare Use-Case Diagram
– Prepare Use-Case Narratives (describes what
happens in each step in the app)
• Deliverables:
– Use-Case Diagram
– Use-Case Narratives
6
Advantages (question 2)
• Tool for capturing and tracking functional requirements
• System scope decomposition
• Easily understood user communication of
functionality(primary advantage)
• Incremental and iterative development.
• Aids estimating project scope
• Provides testing baseline (test plans and test cases)
• Provides documentation baseline (user and system)
• Aids in data object or entity identification & db access
• Provides functional specifications for user and system
interface design
7
Definitions
Use-case diagram – a diagram that depicts the
interactions between the system and external systems
and users.
– It graphically describes who will use the system and in what
ways the user expects to interact with the system.
Use-case narrative – a textual description of the business
even and how the user will interact with the system to
accomplish the task.
Use case – a behaviorally related sequence of steps (a
scenario), both automated and manual, for the purpose
of completing a single business task.
– Description of system functions from the perspective of external
users in terminology they understand.
8
Sample Use-Case Diagram
9
Use-Case Diagram for a Hoosier Burger’s System
10
Basic Use-Case Symbols
Use case – subset of the overall system
functionality
– Represented graphically by a horizontal
ellipse with the name of the use case
appearing above, below, or inside the ellipse.
– Describes ONE and ONLY ONE function
– Associated with ONE and ONLY ONE role
that a user can play
11
Basic Use Case Symbols
Actor – anything that needs to interact with
the system to exchange information.
– Could be a human, an organization, another
information system, an external device,
or even time.
Temporal event – a system event
triggered by time.
– The actor is time.
12
Four Types of Actors
•
•
•
•
•
Primary business actors
Primary system actors
External server actor
External receiver actor
Remember an Actor is a ROLE not an
individual
– A given individual can have multiple roles
– Multiple individuals can have the same role
13
Relationships
• Association – relationship between an
actor and a use case – only one we will
use
• Others
– Extend – relationship between use cases
– Includes – relationship between use cases
– Depends-on – relationship between use
cases
14
Association Relationship
Definition and modeling rules
– Modeled as a solid line connecting the actor and the
use case.
– Association with an arrowhead touching the use case
indicates that the use case was initiated by the actor.
– Association lacking arrowhead indicates a receiver
actor.
– Associations may be bidirectional or unidirectional.
15
Objectives of Use-Case Modeling
• Elicit and analyze enough requirements &
information to prepare a model that:
– Communicates what is required from a user
perspective.
– Is free of specific details about how the
system will be built or implemented.
16
Use-Case Technique Steps
• Steps
1.Identify business actors.
2.Identify business use cases.
3.Construct use-case model diagram.
4.Documents business requirements use-case
narratives
17
Identifying Business Actors
• Ask the following questions:
–
–
–
–
Who or what provides inputs to the system
Who or what receives output from the system
Are there interfaces with other Information Systems
Are there automatically triggered events (temporal
events)
– Who will maintain the information in the system
• Create an Actor Glossary
18
Sample Actor Glossary
19
Identifying Business Requirements
Use Cases
• Identify and document critical or important
use cases, often called essential use
cases.
• Ask questions on next slide
• Look at DFD (good match between them)
• Summarize information in a Use Case
Glossary
20
Use Case Identification
• Ask the following questions:
– What are the main tasks of the actor
– What information does the actor need from
the system
– Does the system need to inform the actor of
any changes or events that have occurred
– Does the actor need to inform the system of
any changes or events that have occurred
21
Sample Use Case Glossary
22
Sample Use Case Glossary Continued
23
Sample Use Case Glossary Continued
24
Event Response List
• Prepare for your Use Case Diagram and
Use Case Narrative by creating an Event
Response list.
– Actor
– Event (or use case)
– Trigger (typically an input)
– Reponses (system responses)
• Sample on Moodle
25
Construct Use-Case Diagram
• Depicts Scope and Boundaries of system
• Outside system boundaries – draw and
label primary actors
• Inside system boundaries – draw and label
primary use cases
• Show relationships between actors and
use cases and between the use cases
26
Guidelines for Use-Case
Diagram Construction
• Identify system’s boundaries – scope
• List primary actors (stakeholders & users is good
place to start) – remember actors are ROLES
• List goals of primary actors
–
–
–
–
Functionality required of system
Tasks (update, read, create, delete)
Communication of external conditions to system
Extraction of information from system
• Identify major use cases
• Use glossaries and event table to help you
• Review (iterative process)
27
Sample Use Case Diagram
28
Create Use-Case Narratives
• Document first at high level to quickly
obtain an understanding of the events and
magnitude of the system.
• Then expand to a fully-documented
business requirement narrative.
– Include the use case’s typical course of
events and its alternate courses.
29
Sample Use-Case Narrative
30
Sample Expanded Use-Case Narrative
continued
31
Sample Expanded Use-Case Narrative
continued
32
Sample Expanded Use-Case Narrative
33
Guidelines for Writing Use Cases
• Focus on Flow of Events – critical to get it
right (Event table should help)
• Write each step in form of Subject-VerbDirect Object
– The patient contacts the office regarding an
appointment
• Identify initiator (trigger) of the action and
the receiver of the action
34
Guidelines continued
• Write each step from an independent
observer perspective
• Write each step at same level of
abstraction (try to accomplish equal
amounts in each step)
• Sensible set of actions
• KISS
• Iterate until comfortable
35
Parts of a Use Case
• Think of each one as a ‘transaction’
• Should have 4 parts
– Primary actor triggers (sends data or request)
– System ensures request/data sent is valid
– System processes request/data – may result
in a change to the internal state of system
– System sends result of processing to an actor
(results may include data)
36
Expanding Use Case Narratives
• Choose major use case and expand it
• Fill in details
– Identify all stakeholders
– Identify all relationships
• Expand on the normal flow of events
• Identify all alternate or exception flows
• Confirm (typically with user)
37
Expanding Use Case Narratives
• Simplify
– Decompose into smaller use cases
– Combine or merge too simple or too small use
cases
– Look for generic, common or general syntax
– Look for ways to extend, include or generalize
use cases
• Iterate
38
Extension of Use Cases
• Use the basic Use Case diagram and
some of the Use Case narratives to build
DFDs (that is where we will go next)
• Identify data required by each use case –
use to build data models
• Refer to Use Cases and data models
when doing form and report design and
system navigation
39
Use Cases and Project Management
• Use-case model can drive the entire
development effort.
• Project manager or systems analyst uses
business requirements use cases to plan
(estimate and schedule) the build cycles of
the project.
– Build cycles are scoped on the basis of the
importance of the use case and the time it
takes to implement the use case.
40