SEEM 3430 TUTORIAL
USE CASE
TUTORIAL
OUTLINES
▸ What is use case?
▸ Formal Use Case
▸ Informal Use Case
▸ How to build Use Cases
▸ Use Case Diagram
WHAT IS USE CASE
WHAT IS USE CASE
WHAT IS USE CASE
WHAT IS USE CASE
▸ A use case represents how a system interacts with its
environment by illustrating the activities that are
performed by the users and the system’s responses.
WHAT IS USE CASE
WHAT IS USE CASE
▸ A use case represents how a system interacts with its
environment by illustrating the activities that are
performed by the users and the system’s responses.
Use cases are a means of expressing user requirements.
Use cases are used extensively in the analysis phase.
WHAT IS USE CASE
MORE ABOUT USE CASE…
▸ Sequence of actions that provide a measurable value to an
Actor.
▸ Describes a way in which a real-world Actor interacts with
the system.
▸ Include high-level implementation decisions.
▸ Can be written in both an informal manner and a formal
manner
▸ Depicted as Ellipses in Diagrams
FORMAL USE CASE
FORMAL USE CASE
▸ The formal, or classic use case, is a tool used to gather structured
information about how users will use the software.
▸ Formal use cases are gathered in a template, which structures the
information.
▸ While this structure can vary from company to company, or even
project to project, there are a few common and critical sections to
the structure.
▸ The two main benefits of having the structure are that it helps with
thoroughness (much harder to leave a field blank than it is to forget
about it), and it helps with scanning by readers of the document.
FORMAL USE CASE
SOME COMMON ELEMENTS IN A USE CASE
▸ Actor – The person or people who will perform the steps of this use case.
▸ Preconditions – A description of the relevant and non-trivial state(s) of the
system prior to the use case starting.
▸ Normal course – A description of the use case itself. This description can
either be in narrative form, or a numbered list (1..N) of specific user
steps. When a use case (such as “User approves/rejects customer
requests”) has more than one way that a user can accomplish the needed
steps, the most common way is shown here – only a single path is shown.
▸ Assumptions – Any assumptions that are implicit in the definition of the
use case.
FORMAL USE CASE
SOME COMMON ELEMENTS IN A USE CASE
▸ Alternate courses – Descriptions of alternatives to, or deviations from
the normal course. For example, the most common course might be to
view the oldest unaddressed customer requests. An alternate course
may be to view the unaddressed requests from the largest customers.
▸ Exception courses – Descriptions of what the user will experience
when something goes wrong.
▸ Post-conditions – Description of the affected portions of the state of
the system after the use case has completed.
▸ Frequency of use – An estimate of how often a particular use case will
be exercised.
FORMAL USE CASE
ADVANTAGE
▸ Detailed information about use cases, making it easy to
estimate the cost of implementation.
▸ Thorough coverage of the use cases is influenced by the use of
a template.
▸ Easy for readers to absorb. The structure of the document
makes scanning easy, and also helps targeted lookups when a
reader needs a specific piece of information.
▸ Consistency with other use cases is much easier to assure when
using a template.
FORMAL USE CASE
DISADVANTAGE
▸ Expensive to maintain. Mapping a “use case” to the
template requires some effort. Since formal use cases
contain more (explicit) information than other use cases,
there is more content to document, validate and modify.
More content equals more cost (of maintenance).
INFORMAL USE CASE
INFORMAL USE CASE
▸ The informal use case is the tool of the Agile
Requirements Manager. It is a paragraph describing the
user’s goals and steps. Also referred to as a basic use case.
▸ Note that the paragraph format can also be replaced by a
numbered series of steps – the key differentiator of this
form relative to a formal use case is the lack of structured
fields for “everything else” about a use case
(preconditions, assumptions, etc).
INFORMAL USE CASE
INFORMAL USE CASE EXAMPLES - DETAIL
▸ Name: Enroll in Seminar
▸ Identifier: UC 17
▸ Basic Course of Action:
▸
•
Student inputs her name and student number
▸
•
System verifies the student is eligible to enroll in seminars. If not eligible then the student is informed and use case ends.
▸
•
System displays list of available seminars.
▸
•
Student chooses a seminar or decides not to enroll at all.
▸
•
another.
System validates the student is eligible to enroll in the chosen seminar. If not eligible, the student is asked to choose
▸
•
System validates the seminar fits into the student's schedule.
▸
•
System calculates and displays fees
▸
•
Student verifies the cost and either indicates she wants to enroll or not.
▸
•
System enrolls the student in the seminar and bills them for it.
▸
•
The system prints enrollment receipt.
INFORMAL USE CASE
INFORMAL USE CASE EXAMPLES - HIGH LEVEL
▸ Enroll in Seminar
▸ • Student chooses a seminar to enroll in
▸ • System checks that the student can enroll in the
seminar
▸ • System calculates fees
▸ • Student pays fees and is enrolled
INFORMAL USE CASE
INFORMAL USE CASE EXAMPLES - FREE TEXT
▸ The player has all the tradable cells in a color group and
wants to buy a house for the color group. The player has
enough money to buy the house and is shown the number
of houses own in that group [S1], and purchases the
house. The player’s status is displayed [UC13].
▸ The player has all the tradable cells in a color group and
wants to buy a house for the color group. The player does
not have enough money to buy the house. The player’s
status is displayed [UC13].
INFORMAL USE CASE
ADVANTAGE
▸ ▪ Easy to create – quick development, iteration, and
collaboration. This enables a rapid approach to
documenting use cases, and minimizes the cost of
developing the use cases.
▸ ▪ When done correctly, yields the most bang for the
buck of any use case approach.
INFORMAL USE CASE
DISADVANTAGE
▸ Challenging to be rigorous – the short format makes it
difficult to capture all the relevant information (and difficult
to avoid capturing irrelevant information).
▸ Lack of consistent structure – can be transition from use
case to use case, since the format is free-form
▸ Capturing the right level of content for your team can be
tricky.
TIPS FOR BUILDING USE CASES
TIPS FOR BUILDING USE CASES
Identify the major use cases
Activities
Start a use case form for
each use case
If more than nine, group
into packages
Typical Questions Asked
Ask who, what, and where about the tasks and their
inputs and outputs:
What are the major tasks performed?
What triggers this task? What tells you to perform this
task?
What information/forms/reports do you need to perform
this task?
Who gives you these information/forms/reports?
What information/forms/reports does this produce and
where do they go?
TIPS FOR BUILDING USE CASES
TIPS FOR BUILDING USE CASES
Identify the major steps within each use case
Activities
Typical Questions Asked
For each use case, fill
in the major steps
needed to process the
inputs and produce the
outputs
Ask how about each use case:
How do you produce this report?
How do you change the information on the report?
How do you process forms?
What tools do you use to do this step (e.g., on
paper, by email, by phone)?
TIPS FOR BUILD USE CASES
TIPS FOR BUILD USE CASES
Identify elements within steps
Activities
For each step, identify
its triggers and its
inputs and outputs
Typical Questions Asked
Ask how about each step
How does the person know when to perform this
step?
What forms/reports/data does this step produce?
What forms/reports/data does this step need?
What happens when this form/report/data is not
available?
TIPS FOR BUILD USE CASES
TIPS FOR BUILD USE CASES
Confirm the use case
Activities
Typical Questions Asked
For each use case,
Ask the user to execute the process using the
validate that it is correct written steps in the use case – that is, have the
and complete
user role-play the use case
TIPS FOR BUILD USE CASES
MORE TIPS ABOUT WRITING
▸ 1. Based on a goal.
▸ A use case describes how an actor uses the system to achieve a goal.
▸ 2. Complete or not complete.
▸ When an actor has performed the steps in a use case, the goal should be either 100%
complete or 0% complete.
▸ 3. One person, one place, one time, one event.
▸ Try to write use cases that describe how one actor responds to one event in one place at
one time.
▸ 4. Six to ten steps.
▸ Try to keep the main success scenario (aka primary flow) of a use case between six and
ten steps. Use cases should make requirements easier to comprehend.
DIAGRAM
USE CASE DIAGRAM
▸ A use case diagram at its simplest is a representation of a user's
interaction with the system and depicting the specifications of a use
case.
▸ A use case diagram can portray the different types of users of a
system and the various ways that they interact with the system. ▸ A use case diagram summarizes all of the use cases (for the part of
the system being modeled) together in one picture ▸ Typically, the use case diagram is drawn early on in the SDLC.
DIAGRAM
ELEMENTS OF A USE CASE DIAGRAM
DIAGRAM
RELATIONSHIPS IN USE CASE DIAGRAM
▸ You can now model the interactions between the
users and the system by creating the
relationships between the actors and the use
cases.
▸ 1. Association
▸ 2. Include (Use)
▸ 3. Extend
▸ 4. Generalization
DIAGRAM
RELATIONSHIPS IN USE CASE DIAGRAM
▸ You can now model the interactions between the
users and the system by creating the
relationships between the actors and the use
cases.
▸ 1. Association
▸ 2. Include (Use)
▸ 3. Extend
▸ 4. Generalization
DIAGRAM
RELATIONSHIPS IN USE CASE DIAGRAM
▸ You can now model the interactions between the
users and the system by creating the
relationships between the actors and the use
cases.
▸ 1. Association
▸ 2. Include (Use)
▸ 3. Extend
▸ 4. Generalization
DIAGRAM
RELATIONSHIPS IN USE CASE DIAGRAM
▸ You can now model the interactions between the
users and the system by creating the
relationships between the actors and the use
cases.
▸ 1. Association
▸ 2. Include (Use)
▸ 3. Extend
▸ 4. Generalization
SUMMARY
SUMMARY
▸ Use cases contain all the information needed for process modeling, but are
easier for users to comprehend
▸ A use case contains all the information needed to build one part of a process
model, expressed in an informal, simple way.
SUMMARY
TAKE AWAY MESSAGE
▸ When writing a use case,
- identify the triggering event,
- develop a list of the major steps,
- identify the input(s) and output(s) for every step, - have
the users role-play the use case to verify.
QUESTIONS
QUESTIONS
▸ Questions?