Вы находитесь на странице: 1из 38

Requirements Engineering

Use Case

Requirements Development Process


Re-Evaluate

Elicitation

Analysis

Specification

Clarify

Validation

Re-Write

Correct and close gaps

Iterative process - Multiple-steps, Not sequential

RED SUN Inc

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

Unified Modeling Language (UML)


Unified Modeling Language (UML) is a graphical
language for visualizing, specifying, constructing,
and documenting artifacts of a system.
UML offers a way of writing systems requirements
from conceptual ideas, from business processes to
system functions and components.
UML is a language, NOT a methodology.
UML can be used to capture high level business
processes and to describe users perspectives on
the system.
Unified Modeling Language (UML) notations can be
used as a tool to analyze system requirements.
RED SUN Inc

Use Case Definition


Use case is a description of a systems behavior
as it responds to a user request.
Use cases describe the system and "who" can do
"what" with the system from the users point of
view.
Use cases describe the interaction between an
actor and the system, represented as a sequence
of steps.
Actor is a person, a hardware or another system
that interacts with the system to achieve a goal.

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

A Use Case Is:


A collection of scenarios made up of a basic flow
plus alternatives to the basic flow.
Always named with the goal of the actor that
started it beginning with an active verb.
A complete self-contained procedure.
Starts with the system in a stable state and
leaves it in the same state.
Has no long time gaps in the flow.
Procedurally independent of other use cases.
Can be used as the basis for a system test.
RED SUN Inc

Use Case Diagram


Use case diagram (UCD) is a type of behavioral
diagram defined by and created from a Use-Case
analysis.
Use Case diagrams present a graphical overview
of the functionality provided by a system in term s
of actors, their goals (represented as use cases),
and any dependencies between those use cases.
The main purpose of a use case diagram is to
show what system functions are performed for
which actors and the roles of the actors in the
system.
UCD have 4 major elements: The actors that
interact with the system, the system itself, the
use cases, or services that the system perform,
and the lines that represent relationships between
these elements.
RED SUN Inc

Benefits Of Use Case Diagram


This model is used to determine:
What goals do actors have?
What tasks are involved in accomplishing each
use case goal?
What must happen to respond to each event?
What step(s) occurs in multiple use cases?
What could go wrong at each step?
What might interrupt at any given step?
An actor:
Is always outside the system.
Characterizes a role of a person or a system.

RED SUN Inc

Use Case Model


A use case model partitions system
functionality into transactions (use cases)
that are meaningful to users (actors).
Use cases are a sequence of actions,
including variants, that a system (or other
entity) can perform interacting with actors
of the system.

RED SUN Inc

10

Use cases: Core Element


Construct
Use Case

Actor

System
Boundary

Description

Syntax

A sequence of actions, including


variants, that a system (or other
entity) can perform, interacting
with actors of the system.

A coherent set of roles that


users of use cases play when
interacting with these use cases.

Represents the boundary


between the physical system
and the actors who interact
with the physical system.

RED SUN Inc

11

Use cases: Core Element


Construct

Association

Generalization

Include

Description

Syntax

The participation of an actor in a


use case. i.e., instance of an actor
and of use cases communicating
with each other.

A taxonomic relationship between a


more general use case and a more
specific use case.
A relationship from a base use case
to an inclusion use case, specifying
how the behavior for the base use
case contains the behavior defined
for the inclusion use case. The base
use case depends on the inclusion
use case. Compare: extend.

RED SUN Inc

< include >

12

Notations (UML)

Use Case

System
Actor
(User)

A use case is a set of scenarios that describes an interaction between


an actor (user) and a system. A use case diagram displays the
relationship among actors and use cases.
The best way for writing use cases is to walk through a simple use case
example and watch how it can be leveraged to something complex. By
absorbing the meaning of use case diagrams, alternate flows and basic
flows, you will be able to apply use cases to any project.
RED SUN Inc

13

Why a Use Case?


Natural language and pictures are used so that
non-technical, as well as technical users can
understand it. A use case is a tool for getting
functional requirements out of users. It gives
them something to put ideas on and is a powerful
interview tool to verify users needs.
A good use case is also:
Easy to understand
Unambiguous
Complete including all alternate flows
Specified in a document separate from use case diagram
Agreed with the users of the system

RED SUN Inc

14

Simple Use Case Diagram Example


Start Use Case Diagrams by listing a
sequence of steps a user might take in
order to complete an action.
Example: a user placing an order with a
sales company might follow these steps:
Look at catalog and select items.
Call sales representative.
Supply shipping address information.
Supply payment information.
Receive confirmation number from salesperson.
RED SUN Inc

15

Example Of Use Case Diagram

Look at catalog and select items

Call sales representative

Supply shipping information

Supply payment information

Actor
(User)

Receive confirmation
number from salesperson

RED SUN Inc

16

Define System Boundary

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.

RED SUN Inc

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

Define System Boundary


Look For Things
To Buy
Show Things
Found Things
Pricing Things

Customer

Negotiate Price

Agree on price

Negotiate Price
With Customer

Seller
Sell Things

Purchase thing
Market System

RED SUN Inc

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.

RED SUN Inc

22

Another Example
Bank
Inquiry

Withdraw Money

Deposit Money

Customer
Transfer Money

RED SUN Inc

Bank
Teller

23

Another Example
Withdraw Money

Invalid PIN
(Extension)

Deposit Money

Transaction Session
Transfer Money

Customer
Inquiry

ATM Machine (System)


RED SUN Inc

24

Another Example: ATM

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

Preliminary Test Case


Use Case: Transaction Session
Function
System reads a
customer's ATM card
System accepts
customer's PIN

Initial System State


ATM system is on

System is asking for entry


of PIN

Input

Expected Output

Insert a ATM card

Card is accepted;
System asks for entry
of PIN

Enter a PIN

System displays a menu


of transaction types
System asks whether
customer wants
another transaction

System allows customer


to perform a transaction

System is displaying menu


of transaction types

Customer perform
a transaction

Session continues when


customer chooses to
do another transaction

System is displaying menu


of transaction types

Answer yes

System is asking whether


customer wants another
transaction

Session ends when


customer chooses not to
do another transaction

System is asking whether


customer wants another
transaction

Answer no

System ejects card and is


ready to start a new
session

RED SUN Inc

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.

RED SUN Inc

27

Developing Use Case - 1


As the use case is developed, the stakeholder
may provide additional information:
About business rules that apply to the use case
but may not have been identified previously.
About non-functional requirements (Quality
Attributes) that apply to the use case.
On data that applies to the use case.
Alternative flows that apply to the use case but
may not have been identified previously.
Requirements analysis is an iterative process.

RED SUN Inc

28

Developing Use Case - 2


Business rules:

User can only withdraw maximum of $200 a day.

Quality Attributes:

System will respond to user request within 5 seconds.

Data requirement:

The ATM Personal Identification Number (PIN) should


be 4 digits.

Alternate Flows:

User can only enter wrong password 5 times, after


that: a) machine will keep the ATM card; b) not allow
anymore password entry; c) Alert system; d) display
on screen: You have reached the max allowable
password entry, please contact the bank for further
instruction.
RED SUN Inc

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?

RED SUN Inc

30

Use Case Model


The use case model is an efficient and effective
technique for collecting essential requirements
from stakeholders and help them to focus on their
real needs, not just what they initially say they
want.
It will help all those involvedanalysts and
customersarrive at a common, shared vision of
the product capabilities as they specify what the
product will be and do.
By building use cases BIM Engineers gain an
understanding of the user's application domain
and separate Needs from Wants and Wishes
from stakeholders.
RED SUN Inc

31

Pre-Post Conditions
Pre-Conditions
Describe the state that the system must be in
for the use case to start.

E.g. The user must be logged on with the right


password. If these conditions are not fulfilled, the
use case will not start.

Post-Conditions
Describe the state that the system will be in
at the end of the basic flow.

E.g. The system is displaying the menu.

RED SUN Inc

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.

RED SUN Inc

34

Questions & Answers

RED SUN Inc

35