REQ07 - Use Case
REQ07 - Use Case
Use Case
Elicitation
Analysis
Specification
Clarify
Validation
Re-Write
Definitions
Requirements Analysis
The techniques of deciding which features are
appropriate for the product based on
stakeholders needs.
To effectively analyze requirements BIM Engineers
need to understand and define the requirements
from the stakeholders view and verify with
them so they can prioritize their needs before
allocating requirements to BIM.
Requirements elicited from stakeholders must be
complete and clear enough to validate later.
* IEEE Standard 610.12 IEEE Glossary of BIM Engineering Terminology
RED SUN Inc
Use Cases
Use cases are descriptions in abstract terms of
how actors use the system to accomplish goals.
Each use case is a logical piece of a function that
can be indicated by an actor and described from
the actors point of view.
A use case summarizes a set of related scenarios.
BIM Engineers apply use cases to reveal
functionality requirements by clarifying what
users need to accomplish when interacting with
the system.
Use cases are a natural way to organize functional
requirements and is easier for users to
understand and verify than textual statements.
RED SUN Inc
10
Actor
System
Boundary
Description
Syntax
11
Association
Generalization
Include
Description
Syntax
12
Notations (UML)
Use Case
System
Actor
(User)
13
14
15
Actor
(User)
Receive confirmation
number from salesperson
16
Customer
System
Seller
Customer
RED SUN Inc
17
The System
The system box only appears on the toplevel diagram, and should contain use case
ovals, one for each top-level service that
the system provides to its actors.
Any kind of internal behavior that the
system may have that is used only by
other parts of the system, should not
appear in the system box.
18
The System
Deposit Money
Correct
Withdraw Money
Customer
Bank
Check Account
Balance
Identify Customer
Incorrect
Verify Account
Customer
RED SUN Inc
Bank
Update
Bank Database
19
Customer
Negotiate Price
Agree on price
Negotiate Price
With Customer
Seller
Sell Things
Purchase thing
Market System
20
Multiple Releases
Look for things
Release 1
Negotiate price
Manager
Place Order
Pay for purchase
Customer
Release 2
Ship order
Release 3
Acknowledge
order
Support
Using boundary boxes to indicate multiple release
RED SUN Inc
21
Key Concept
Each use case focuses on describing how to
achieve a goal or task. For most projects this
means that multiple use cases are needed to
define the scope of the new system.
The degree of formality of a particular BIM
project and the stage of the project will influence
the level of detail required in each use case.
Use cases should not be confused with the
features of the system:
A use case may be related to one or more features.
A feature may be related to one or more use cases.
22
Another Example
Bank
Inquiry
Withdraw Money
Deposit Money
Customer
Transfer Money
Bank
Teller
23
Another Example
Withdraw Money
Invalid PIN
(Extension)
Deposit Money
Transaction Session
Transfer Money
Customer
Inquiry
24
Start Transaction
Session
ATM Machine
Customer
A session is started when a customer inserts an ATM card into the machine. The ATM
pulls the card into the machine and reads it. The customer is asked to enter the special
identification number (Personal Identification Number or PIN) and allowed to perform
the transaction, choosing from a menu of possible types of transactions. When the
customer is finished performing the transaction, the card is ejected from the machine
and the session ends. Transactions can be aborted if there are invalid PIN entries. The
customer may abort the session by pressing the Cancel key when entering a PIN or
choosing a transaction type.
RED SUN Inc
25
Input
Expected Output
Card is accepted;
System asks for entry
of PIN
Enter a PIN
Customer perform
a transaction
Answer yes
Answer no
26
Key Concept - 1
It is important to define the basic flow of a use
case before building the structure of several flows
that are part of it.
Write the most important course of events or
which events happen most of the time.
Do not include complex exceptions in the flow
text, simple exceptions with a simple condition
and a one line response may be included. This is
simpler than creating an alternate flow.
Always start with the system in a stable state and
finish with it in a stable state.
27
28
Quality Attributes:
Data requirement:
Alternate Flows:
29
Review:
Ask yourself:
What goals do actors have?
What steps are involved in accomplishing each
use case goal?
What must happen to respond to each event?
What steps occur in multiple use cases?
What could go wrong at each step?
What might interrupt any given step?
30
31
Pre-Post Conditions
Pre-Conditions
Describe the state that the system must be in
for the use case to start.
Post-Conditions
Describe the state that the system will be in
at the end of the basic flow.
32
Summary - 1
Since no single view of requirements provides a
complete understanding, BIM Engineers need a
combination of textual and visual requirements
representations to create a full picture of the
proposed system.
Modeling and diagrams communicate certain
information more efficiently than text can. A
picture is worth a thousand words.
However, do not assume stakeholders know how
to read models, so BIM Engineers must explain
the purpose and notations of each model and ask
them to verify them.
RED SUN Inc
33
Summary - 2
The use case model provides a complete, insideout view of system functionality.
A use case is a procedure by which an actor may
use the system.
A good use case is a sequence of interactions
across the system boundary between the acto r
and the system, written in easy to understand
natural language and pictures.
An actor is always outside the system being
defined.
The actor that starts the use case is the primary
actor for that use case.
An actor is a role defined by the set of use cases
with which it is associated.
34
35