Requirements Analysis

CIS490
Software Engineering

Spring2001
 Manufacturing the software product

Modeling
Problem Modules Mapping Solution
techniques

Structured
Programming
and
VORD Languages

OO

Problem Final
Models
statement Product
 A comprehensive approach to apply
The partitioning concept
module
service
(function)
Loose
Coupling
Structured
approach module service
(function)

module
service
(function)
Partitioning
Problem
the
statement
Problem

Class service
Tight
Cohesion Object
Oriented
approach class
service

service
class
 The Software Engineering Grammatical Model
SEGM
by Osama Eljabiri

Automatic
CASE External DFD
Entities and
tools
software OO
Nouns
engineers
Data
stores
and Data flows DFD
Analyze
Build
Identify requirement Apply
Final
Initial s with grammatical
Problem ERM
problem VORD Analysis Attributes
statement and
method OO

DFD
Process
Stake
holders
use of Verbs
Methods
OCR Associations OO
Technology

Relations
ERM
 A comprehensive approach for generating software engineering documentation
By Osama Eljabiri

Verbal VORD Requirements Requirements

description method Definition Specification

Documentation
Analysis
Data flow
Graphical Structured
diagramin
representation chart
g
Stakeholders

ERM Structurded
Data Decisin Decision
dectionary table tree english

Problem Partition Break down

statement towards Determine LOOSE into
methodology COUPLING
independency blackboxed Provide
AND
TIGHT modules services
COHESION ( Functions or
classes)

Nouns
Grammatical Associate
Determine Nouns and verbs
analysis methodology to their relevant
components
Verbs

Build models
 DFD diagrams , Context diagrams
, data dictionary ,decision table
Decision tree , structured charts, pseudo code,
ERM model , architectural models
For your project
Check list

Requirements Definition , requirements specifications,

VORD method, Glossary , Introduction ,Problem statement,
Methodology

Classes , class hierarchy , dynamic models,use case scenario

Your First Project Assignment

Title page
Table of contents
Background
VORD method
Problem statement
Literature Review
Methods and Techniques used
Glossary
References
 ATM Problem Statement
Design the software to support a computerized banking network including
both human cashiers and automatic teller machine (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are
owned by individual banks and communicate directly with their own bank's
computers. Human cashiers enter account and transaction data. Automatic
teller machines communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine accepts a cash card, interacts with the user,
communicates with the central system to carry out the transaction,
dispenses cash, and prints receipts. The system requires appropriate
recordkeeping and security provisions. The system must handle concurrent
accesses to the same account correctly. The banks will provide their
network. The cost of the shared system will be apportioned to the banks
according to the number of customers with cash cards.
 ATM Problem Statement
(SOLUTION)
Design the software to support a computerized banking network including
both human cashiers and automatic teller machine (ATMs) to be shared by a
consortium of banks. Each bank provides its own computer to maintain its
own accounts and process transactions against them. Cashier stations are
owned by individual banks and communicate directly with their own bank's
computers. Human cashiers enter account and transaction data. Automatic
teller machines communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine accepts a cash card, interacts with the user,
communicates with the central system to carry out the transaction,
dispenses cash, and prints receipts. The system requires appropriate record
keeping and security provisions. The system must handle concurrent
accesses to the same account correctly. The banks will provide their
network. The cost of the shared system will be apportioned to the banks
according to the number of customers with cash cards.
 Requirements Engineering
Feasibility Requirements
study analysis
Requir ements
definition
Feasibility Requirements
report specification
System
models
Definition of
requirements

Requirements Specification of
document requirements
Introduction to Requirements
Analysis
 What are Requirements?
IEEE definition [IEEE90]:

(1) a condition or capability needed by a user to

solve a problem or achieve an objective
(2) a condition or capability that must be met or
possessed by a system or system component to
satisfy a contract, standard, specification or other
formally imposed documents
(3) a documented representation of a condition or
capability as in (1) or (2)
Requirements are defined at different
levels
Business Needs What are the objectives/goals
of the business?

Business level
To meet these needs, what process,
Requirements procedures etc. are required?

System level What does the system have to do

Requirements to meet the business’s requirements?

Release level When and how will these

Requirements requirements be met?
 Examples of Requirements
(For Bank ATM system)

Behavioral requirements
The system shall allow the withdrawal of funds from customer
checking accounts.
The system shall allow the deposit of funds into customer checking
accounts.
The system shall only allow access to users with a valid 8 digit PIN
security number.

Non-Behavioral requirements
The system shall respond to all requests within 20 seconds.
The system shall be available 24/7 except for a 30 minute period
each day for maintenance.
 Sources of Requirements
Requirements come from:
– Users/Customers (e.g. Bank employees,
management, selected customers)
– Standards (e.g. Bank standards for data, Year2000 )
– Policy/Legal (e.g. Government Banking regulations)
– System/Process Documentation (e.g. current
system being replaced, could be manual)
– Subject Matter Experts (e.g. experts on consumer
banking)
Why do we care
about Requirements
Analysis?
Key System Development Challenges

• Determining the what are the customer’s

need
• Building a quality system that meets these
needs in a controlled, cost effective manner
• Validating that the implemented system
meets these needs
 Studies Consistently Identify Poor
Requirements as Major Cause of Project Failure

[GAO 92] - Major problem sources in two

thirds of systems examined
[Faulk 92] Survey of large aerospace firms
identified requirement as most critical
software development issue
[Boehm 81] Study of industry projects show
that requirements errors are the most costly
 Requirements Analysis Key to
Successful Development

“The hardest single part of building a

software system is deciding what to build.
...No other part of the work so cripples the
resulting system if done wrong. No other part
is more difficult to rectify later.”
- Fred Brooks, No Silver Bullet: Essence and Accidents of Software Engineering
Why is Requirements Analysis Important?

• Identifies user needs to ensure that you are

building the right system

• Help you manage the development process

to ensure a quality system

• Identify defects early, reducing costs

 Requirements Analysis Help Manage
Quality Development by
• Understanding what the really problem is
• Surfacing risks early in project life cycle by providing
basis for estimating costs and schedules.
• Reducing the development effort and avoiding wasted
money by building the wrong system.
• Helping to determine what progress has really been made.
• Helping to manage system evolution and change by
providing documentation and a baseline of what the
system will do.
Requirements Analysis helps You Manage
Quality Development by (cont.):
• Forming the basis for a formal contract between
the customer and the developers on what the
system should do.
• Provide a criteria from which acceptance testing
can be performed to validate the developer has
delivered what you wanted.
• Helping to manage system evolution and change
by providing documentation and a baseline of
what the system will do.
 Requirements analysis helps to Identify
Defects Early, Reducing Costs

The later in the development life cycle that a

software error is detected, the more
expensive it will be to fix.
 Defects Propagate and Grow
problem

correct wrong
requirements requirements

correct wrong design based on

design design wrong requirements

correct wrong code based on code based on

code code wrong designs wrong requirements
Cost to Repair Software in Relationship
to Life Cycle Stage
Stage Relative Cost of
Repair
Requirements 0.1 - 0.2
Design 0.5
Coding 1
Unit test 2
Acceptance test 5
Maintenance 20
 Role that good requirements play

• For customers, the requirements describe

what will be developed and perhaps provide
a contractual basis for the development
• For project manager, they provide a basis
for project planning and measuring progress
• For the developers, they provide the
functionality to be designed and coded
• For testers, provide the basis on which test
 Types of Requirements
• Functional (Behavioral) requirements - Specify the
inputs to the system, the outputs or responses from the
system and relationship between them
• Non Functional (Non-Behavioral) requirements -
Describe the required overall attributes of the system,
such as reliability, user friendliness, performance, and
portability
• Project requirements - Define project characteristics such
as the schedule, the cost, required design documents,
quality procedures etc. (These characteristics not always
considered a “classic requirements”)
 But capturing requirements is hard,
because need to:
• Understand precisely what is required by the
system.
• Communicate that understanding to users,
customers, designers and other stakeholders.
• Ensure that as requirements change, they are
updated and the impact of the change is
understood.
• Ensure that system meets the requirements.
Errors Made During the Requirements Phase

40% 38%

35%

30%
24% 23%
25%

20%
15% 10%
10%
4%
5% 1%
0%
Incorrect Omission Clerical Inconsis- Ambi- Misplaced
Facts Errors tency guity Requirements
 Difficulties in creating good
requirements include:
• Understanding - Users and customers do not always
know what they want until they see it
• Modeling - For a large system, the modeling the
requirements is time consuming and challenging
• Communication - Software is complex and precise, it is
hard to effectively communicate requirements for this
software across users, customers and developers,
• Management of Requirements - Since requirements are
typically not stable thourghout development, it is critical
to control and understand the impact of change to the
requirements
 What is the Requirements Process?
The requirements process is one in which
“what is to be done” is elicited and modeled.
This process has to deal with multiple
perspectives, and it uses a combination of
methods, tools and actors.
The product of this process is a model,
from which a document, called
a requirements specification
is produced.
 Requirements Process and Work
Products
• What is the process lifecycle?

• Who participates?

• What are the products?

• How do you determine if the requirements

process is working to ensure quality?
Software development lifecycle, again

Requirements Analysis

Design

Code

System Test

The Software Process, Sommerville

 Requirements process lifecycle

Activities

Ongoing Requirements Management

Analysis
Elicitation and Specification Validation
Organization
Work Products

Meeting notes Accepted

Analysis Requirement
JAD results etc. requirement
models specifications
specifications
 Activities in the requirements
process
• Requirements Elicitation is a process of identifying stakeholders
needs and bridging the disparities among the different
stakeholder’s requirements.
• Requirements Analysis and Organization is the activity of
structuring and synthesizing the information gathered during
elicitation
• Requirements Specification specifies the requirements in a
unambiguous and complete form as possible
• Requirements Validation is the activity of checking the quality
of the requirements to ensure they are: Correct, Complete,
Unambiguous, etc
• Requirements Management provides management and tracking
of the requirements as the system is being developed
 Requirements in the software
development lifecycle
Ongoing Requirements Management

Analysis
Elicitation and Specification Validation

Requirements Analysis Organization

Requirements management

Meeting notes Accepted

Analysis Requirement
JAD results etc. requirement
models specifications
specifications

Design

Code
However, requirements
will change and be
reworked throughout
System Test
the development lifecycle
 Stakeholders who participate in the
Requirements Analysis Process
• Users
• Managers,
• Analysts,
• Sponsors/funders,
• Developers.

Each with different needs and perspectives

 What is a Requirements Analyst?

• The individual(s) whom is primarily responsible

for eliciting, analyzing, specifying the
requirements as well as ensuring that the
requirements are validated and managed.
• A good requirements engineer is part
psychologist, part domain expert, part client
manager, part technologist)
Skills that a requirements analyst should
have include:
• Interviewing
• Facilitation
• Negotiation
• Analytical and problem analysis
• Presentation
• Business Knowledge
• Knowledge of requirements methods, tools, and
techniques
 History of Analysis and Design:
Structured Methods
• Late 60s - Structured Programming
• Early 70s - Structured Design
• Late 70s - Structured Analysis

All based on data flow diagrams and structure charts.

DFDs may be supported by adjunct models, such
as state diagrams and entity-relationship diagrams.
Or Information Modeling (IE)
 Requirements process lifecycle

Activities

Ongoing Requirements Management

Analysis
Elicitation and Specification Validation
Organization
Work Products

Meeting notes Accepted

Analysis Requirement
JAD results etc. requirement
models specifications
specifications
 The VORD method

Viewpoint Viewpoint Viewpoint Viewpoint

identification structuring documenta tion system ma pping
 VORD process model
• Viewpoint identification
– Discover viewpoints which receive system services and
identify the services provided to each viewpoint
• Viewpoint structuring
– Group related viewpoints into a hierarchy. Common services
are provided at higher-levels in the hierarchy
• Viewpoint documentation
– Refine the description of the identified viewpoints and
services
• Viewpoint-system mapping
– Transform the analysis to an object-oriented design
 VORD standard forms
Viewpoint template Service template
Reference: The viewpoint name. Reference: The service name.
Attributes: Attributes providing Rationale: Reason why the service is
viewpoint information. provided.
Events: A reference to a set of event Specification: Reference to a list of service
scenarios describing how specifications. These may
the system reacts to be expressed in different
viewpoint events. notations.
Services A reference to a set of Viewpoints: List of viewpoint names
service descriptions. receiving the service.
Sub-VPs: The names of sub- Non-functional Reference to a set of non -
viewpoints. requirements: functional requirements
which constrain the service.
Provider: Reference to a list of system
objects which provide the
service.
 Viewpoint identification
Query Get Customer Cash Transaction
balance transactions database withdrawal log

Manager Card Remote

Machine Order
returning software
supplies cheques
upgrade
Account Message Software
information log size Bank Invalid
User teller user
interface System cost Foreign
customer Printe
r Security
Account Stolen Order Hardware
card statement Card
holder maintenance retention
Message
passing
Remote Update Funds Card
Reliability account transfer
diagnostics validation
 Site Updating
producer Navigating Browser Information

Security Feedback
System Easiness
Operator

Selling Owners
On-line Maintainable Existing
customers

Place an Software Search GUI

Order Browser

New Comprehensive Advertising Download

contents Vacancies Time
customer

Communicating Marketing
Dependability Linking
Together Manager Sister
Companies

Maintenance
engineer
Rapidity
 Viewpoint service information
ACCOUNT FOREIGN BANK
HOLDER CUSTOMER TELLER
Service list Service list Service list

Withdraw cash Withdraw cash Run diagnostics

Query balance Query balance Add cash
Or der cheques Add paper
Send message Send message
Transaction list
Or der statement
Transfer funds
 Viewpoint hierarchy All VPs

Services
Query balance
Withdraw cash Customer Bank staff

Services Account Foreign

Teller Manager Engineer
holder customer
Order cheques
Send message
Transaction list
Order statement
Transfer funds
Customer/cash withdrawal templates
Reference: Customer Reference: Cash withdrawal

Attributes: Account number Rationale: To improve customer service

PIN and reduce paperwork
Start transaction
Events: Select service Specification: Users choose this service by
Cancel pressing the cash withdrawal
transaction button. They then enter the
End transaction amount required. This is
confirmed and, if funds allow,
Services: Cash withdrawal the balance is delivered.
Balance enquiry
VPs: Customer
Sub-VPs: Account holder
Foreign Non-funct. Deliver cash within 1 minute
customer requirements: of amount being confirmed

Provider: Filled in later

 VIEWPOINT TEMPLATE
SERVICE TEMPLATE

REFERENCE p lace an order

REFERENCE Visitor
RATIONALE
ATTRIBUTES
1- E-mail Address 1-Improve customer service by means of reducing
2- Browser Name (Ex : Netscape or explorer, version ?) communication expenses and time of response .
2-Facilitate and ease sales process.
3- Modem speed
4- Credit card
5-Personal information SPECIFICATION
Users choose this service by choosing the (order) item
EVENTS in the site (Home Page).
1- Logging –in site Each user enters his name, E-mail, other personal
2- Logging – out site information, and requested products along with
3- Press a hyper link specifications and amount. Then the method of delivery and
4- Press a control payment is determined.
User may confirm these information by pressing
(submit button), otherwise the operation maybe cancelled
SERVICES or data is cleared by pressing (reset)
1-Place on order
2- Search for information VPs Visitor
3- E – mail
4- comment and feedback
5-Browsing
NON-FUNCTIONAL REQUIREMENTS
Getting automatic reply of the company within seconds by a
SUB - VBS text report displayed on the screen.
Browser
Searcher PROVIDER Osama.j
Customer
 System contexts
• The boundaries of the system must be established
to determine what must be implemented
• These are documented using a description of the
system context. This should include a description
of the other systems which are in the environment
• Social and organizational factors may influence
the positioning of the system boundary
 Auto-teller system context
Security
system
Branch
Account
accounting
database
system

Auto-teller
system
Branch
Usage
counter
database
system
Maintenance
system
Introduction to Use Case
Modeling
 What is Use Case Modeling?
• When individuals use a system, they perform a
behaviorally-related sequence of transactions in a
dialogue with the system.
• Use cases model the system by identifying events and
describing system response (behavior)
• Use cases are a combination of English descriptions
and/or graphical representations that specify the
interaction which takes place between a user and the
system for the purpose of completing a single event
• System functionality is defined by the collection of all
use cases
 Background of Use case
modeling
• Developed by Ivar Jacobson at Erricson Telecom
• Was the center of the Objectory(TM) Methodology
• Used to supplement object modeling during system
analysis
• Widely accepted by object oriented community
• Incorporated into Unified Modeling Language (UML)
• Still a very loosely defined approach
• Many ways to do “It Right”
 A Use Case is:
• Jacobson defines a use case as “a sequence of
transactions in a system whose task is to yield a result of
measurable value to an individual actor of the system
“[Jaco95].

• A use case describes a series of interactions between a

system and an actor(s) along with the functions and
actions that the system needs to perform during these
interactions.

• A use case is triggered by some event that is initiated by

some actor and providing measurable value to an actor.
 Why Use Cases?
• Scopes the system boundaries and users
• Identifies new and missing requirements
• Communicates requirements to developers

• A very focused view of system behavior

• A very understandable format for
communication and validation
• Testing scenarios and documentation.
 Use case modeling is a flexible
technique
• Use case modeling is very flexible and modifiable
approach
• Can be applied very formally or very informally
• Other than a few basic concepts, very little
agreement in the industry on one correct approach
• This allows an organization to adapt the use case
modeling to their specific needs
• But requires thought by the practitioner as to how
to use them.
Basic Actor and Use Case
Concepts
 UML Actor Notation
• An actor is normally shown as stick figure, see below,
with the name of the actor below the figure.
• The relationship (i.e. interaction) between the actor
and the use case is represented by a line between the
actor and the use case

Use Case A

Actor
 What is an Actor?
“The actors represent what interacts with the system.”
- Ivar Jacobson [Jacobson92a]

“All the world's a stage,

And all the men and women merely players (Actors)”

- As You Like It [1598-1600], Act: II, Scene: vii, Line: 139

by William Shakespeare
 Actors
• When an event occurs that causes interactions
between the system and its environment, there are
entities in the environment that are involved in the
interaction.
• Some of the entities initiated the event, others
interact with the system as a result of the event.
• In use case modeling, these entities are known as
Actors
• An actor is an entity that interacts with the system
for the purpose of completing a event [Jacobson93].
 Examples of Actors

• Examples of actors include a bank customer

submitting a loan application or
• A travel agent determining seat availability using the
World Wide Web to interact with a reservation
system.
Travel Agent

Airline
Determine seat
Reservation availability
System

Submit a loan application Loan

System
Bank
Customer
Actors can be anything that interacts
with the System
• Actors aren’t necessarily human users of the system,
they can be: other systems, external organizations,
external devices etc., which interaction with the
system.

Person External Device Outside

System Organizations
An Actor Represents a Role
Actor is Not a specific
a ROLE Person

Bank Jane Bruce

Customer Smith Jones
 Specifically an actor is:

• A tangible entity,

• Has some interaction with system,

• It is external to the system and,

• Is a role played
 There can be a couple of significant
exceptions to these guidelines.

• First, when there is a specific physical entity,

such as an existing inventory system or
temperature sensor, known to have interactions
with the system, it is OK to explicitly model that
instance of an entity as an actor.

• Second, in some very specific situations, the

system itself can be an actor.
See ATM Use Case
 Interesting Issue: Is there only one
right way to model with use cases?
• Use cases are a very flexible and extendible technique.
• Use case modeling concepts may be applied very informally
and loosely in situations when the need exists, or can be
applied very rigorous and with great formality.
• Within the established basic concepts for use case modeling,
the application of use case modeling can vary considerably.
• Factors of length, terminology, organization of the use case
model, and structure of the internals of a use case such as
length and formality can be markedly different from one effort
to another.
• All of these various approaches have strengths and
weaknesses.
 Use Case modeling constructs and
Relationships include:
• Use Case Diagrams. High level visual representation of the actors and the use
cases.
• Initial use cases descriptions. Identify and broadly describe system behaviors
initiated by actors. They provide a high level description of the use cases.
• Base use cases. Expand on the high level system use cases, by documenting
the use case behavior in greater detail. focus on the fundamental or “base”
behaviors.
• Elaborated system use cases. Elaborates and models more specific system
behavior by adding detail to the Base use cases.
• Extends and includes relationships. Document the commonality between use
cases as well as the exception conditions and alternative courses
• Use Case Instances. Model specific “scenarios” or examples of how use cases
are executed.
• Dependency Streams. Model the dependencies between use case
 Why spend the time documenting use
cases utilizing these concepts?
• A complete use case model is not just built in one step, rather the
model will be built iteratively & progressively -There should be
representations that capture this progress as it occurs.
• The use case model has several audiences: Customers, users,
analysts, designers and systems architects, to name a few. The
different audiences will wish to view the use cases in different ways
• The multiple representations allow the use cases to be more easily
partitioned for development.
• Fourth, as an organizational technique to add order and
understandability to a large use case model
*It is important to remember that use case modeling is not a
linear process
 Use Case Modeling Process

Develop Use Case Define Extended and

Diagrams Elaborated Use cases

Define Sy stem Develop Base

Develop Dependency
Context and Identify Use Cases
Streams and
Actors Create Use Case Use Case Frameworks
Instances

Define Initial Use

Define Abstract Use Cases
Case Descriptions

Map Use Cases to Object Model

 Major Steps in Use Case
Modeling include:
• Prepare a Context and/or Use Case Diagram
and identify Actors
• Identify Initial & Base Use Cases initiated
by each actor
• Develop Instance Scenarios
• Iteratively elaborate the Base Use Cases and
determine Extends and Include Relationships
• Develop Use Case Dependency Streams and
Business function Packages
• Map use cases to Object Model
 Use Case Modeling Process

Develop Use Case Define Extended and

Diagrams Elaborated Use cases

Define Sy stem Develop Base

Develop Dependency
Context and Identify Use Cases
Streams and
Actors Create Use Case Use Case Frameworks
Instances

Define Initial Use

Define Abstract Use Cases
Case Descriptions

Map Use Cases to Object Model

 Example problem statement for
Loan Processing System
A bank has determined that they need to automate and integrate their current loan processing
activities. Currently perspective loan applicants fill out a paper loan application and
submit it to the bank. The loan request is handled manually by reviewing it for errors, and
validating the information on the application. A credit check is performed on the applicant,
both internally and externally. If the loan request is approved, the loan officer then
determines the best loan conditions and notifies the applicant. Typically the time it takes
to process a loan request is a minimum of one week. If the applicant accepts the loan, then
the bank also handles the loan payments.

The bank would like to automate as much of the loan processing as possible. With the goal of
helping to reduce the time to respond to a customer to 24 hours, as well as reducing the
number of personnel involved in the process and increasing the number of loans that can be
processed in a given period of time. The bank would also like to improve the efficiency of
their current loan service activities such as payment processing and late loan collection.

They would also like to be able to share data between the loan processing system and other
bank systems.
 Context Level Diagram
• Represents the system as a black box (a big circle)
• Defines System boundary
• External entities that interaction with it.
• With the interactions (or alternatively the
information flow between an entity and the
system)
• Evaluate the external entities to see if they are
actors, normally this is the case.
Context Diagram for Loan Processing
System
Loan Officer
Evaluate, Loan Applicant
Generate, Submit loan request
Close loan

Customer

Make loan payments

Receive Late Payment Notice
Credit request,
Loan Processing
Credit
Bureau forward payment System Provide customer,
history Loan information

Set loan terms Data Warehouse

Provide loan
statistic report Current Customer
Approve Account Information

Provide delinquent Credit worthiness

loan information Accounting System
Loan Manager

Credit
Specialist
 Find the Actors
Look for external entities that have interactions with the system in:
• Draft Context diagrams and other models that describe the system within its
environment. (eg BPR results, existing system models etc)
• The stakeholder analysis that has identified the stakeholders.
• Written specifications and other project documentation, such as memos
about meetings with users, to help find users whom may be potential actors.
• Participation in Joint Application Development (JAD) or Joint
Requirements Planning (JRP) sessions,
• Training guides and user manuals from current processes and systems.
• Finally, and most importantly, involve the key users in the use case
modeling process.
 Actors can both initiate and respond to
interactions from the system
• Initiator - An external (normally) actor that initiates a
behavior of the system
• External Servers and Receivers - Form of actor that
support a behavior of the system.

Submit a loan application Loan

System
Bank
Customer
Request Customer
Credit Report

Credit Bureau
 Primary and Secondary Actors

• A primary actor is a user who will obtain value

from or use the system directly
• A secondary actor exists only to service the system
and would not exist were there no primary actors
(e.g. operators)
• Primary actors tend to govern the system structure
and require more changes
• Recommend starting with primary actors when
identifying use cases
 Document the Actors who
participate in a use case
• Review stakeholders and context diagram.
– Select external parties that initiate system activity.

• Write a brief description of the actor.

– Example: Loan Applicant is an individual or
organization who submits a request for a loan.

• Remember:

– The actor is a role.

– A person or organization can play more than one
role.
 Sample Template for Documenting a
Actor Description
Actor Specification
Actor Name: <name> Abstract: <Yes, No>
Description: <Description of Actor’s Role>

:
Use Cases involved in Actor Type: <Primary, Secondary>
Use Case Name/ID: <name, ID> Actor Form: <Initiator, Server, Receiver>

1)
2)
3)
etc.
 Actors for the loan processing
include:
• Applicant
• Customer
• Loan Officer
• Accounting System
• Credit Specialist
• Credit Bureau
• Loan Manager
• Data Warehouse
Example specification for: Applicant
Actor Specification
Actor Name: Applicant Abstract: No
Description: An Applicant is an individual or organization who submits
a request for a loan to the Bank.

:
Use Cases involved in
Use Case Name/ID: <name, ID> Actor Form: <Initiator, Server, Receiver>

1)
2)
3)
etc.
 Example specification for: Credit
Bureau
Actor Specification
Actor Name: Credit Bureau Abstract: No
Description: Credit Bureau is a organization that maintains and
provides credit histories on individuals and organizations

:
Use Cases involved in
Use Case Name/ID: <name, ID> Actor Form: <Initiator, Server, Receiver>

1)
2)
3)
etc.
 Abstract Actors
• An abstract actor is a role that represents shared or
common behavior across two or more actors.
• For example, if there is a business customer and
individual, much of the way they interaction with
the system is the same.
• However, there are some differences in the details
of the interactions these two actors have with the
system.
• Just as in object modeling, generalization
relationships can be defined to capture this concept.
Abstract Actor Example
Customer

Individual Business
Customer Customer
 When looking for actors ask the
following questions:
• Who or what initiates events with the system?
• Who or what interacts with the system to help the system
response to an event?
• Are there any reporting interfaces?
• Are there any system administrative interfaces?
• Will the system need to interact with any existing legacy
systems?
• Are their significant special cases of the actors already
defined for the system?
• Are their any other hardware or software devices that interact
with the system and make sense to model during analysis?
 Use Case Modeling Process

Develop Use Case Define Extended and

Diagrams Elaborated Use cases

Define Sy stem Develop Base

Develop Dependency
Context and Identify Use Cases
Streams and
Actors Create Use Case Use Case Frameworks
Instances

Define Initial Use

Define Abstract Use Cases
Case Descriptions

Map Use Cases to Object Model

 Initial System Use Cases
Descriptions I
• An initial use case descriptions captures individual use
case at a high level of abstraction.
• Normally involves a couple of sentences or a free form
paragraph outlining the purpose of the use case and the
activities in the use case.
• This level of use case description allows for a quick
understanding of the interactions between the actors and
the system, and the systems responsibilities and
behaviors in response to these interactions
• Also grouped graphically in a Use Case Diagram
Initial System Use Case Descriptions
II
• Initial use cases descriptions can be developed quickly and
provide a focused, conceptual view of the major behaviors of
the system.
• They are intended as a starting point to understanding and
modeling the individual use cases.
• They are also an excellent means to present the system to key
high level decision makers in a compact and understandable
fashion, without getting bogged down in details
• More details are hen added to the use cases as the process
progresses
 Elaboration of Use Case Details

Base Use Case Detailed Use Case

Initial
Use Case Description Name:
Name:
Actors:
Actors:
Description:
Name: Description:
Event Course:
Pre-condition:
Actors: Event Course:
Pre-condition:
Description:
Event Course:
Event Course:

Post-condition:

Post-condition:

Assumptions:
Assumptions:
Sample Template for Documenting a
Initial Use Case Description.

Use Case: <Name of the use case>

Actor (s): <Names of the actor or actors who interact with the system>

Description:

<Description of the use case>

 Example Initial Use Case
Description for: Submit a Loan
Request
Use Case: Submit a Loan Request
Actor: Applicant
Description:
The applicant submits a loan for processing by the bank’s integrated
loan processing system.
The applicant fills out a membership application and submits it to the
bank for processing. The system validates information on the loan
application is validated, and the system calculates the applicant’s credit
score based on credit reports and the customer’s history with the bank.
The applicant is contacted for additional information, if needed.
Example Initial Use Case Description
for: Evaluate a Loan Request

Use Case: Evaluate a Loan Request

Actor: Loan Officer
Description: The loan officer reviews the information on a pending loan to
determine if the loan should be a approved.
Example Initial Use Case Description
for: Process an approved Loan Request

Use Case: Process an approved Loan Request

Actor: Loan Officer
Description: An approved loan application is processed to generate the
loan material and the customer is informed of the approval.
 Use Case Modeling Process

Develop Use Case Define Extended and

Diagrams Elaborated Use cases

Define Sy stem Develop Base

Develop Dependency
Context and Identify Use Cases
Streams and
Actors Create Use Case Use Case Frameworks
Instances

Define Initial Use

Define Abstract Use Cases
Case Descriptions

Map Use Cases to Object Model

 Use Case Diagrams
• Provides visually representation of the participation of actors
have with each use case
• Use case diagrams show the relationships and between the use
cases and actors.
• On a system of any size, there may be multiple use case
diagrams.
• For example, some may show the relationship between the
actors and the system,
• While others may show the uses and extends relationships
between individual use cases
• These diagrams will be iterative developed and refined
throughout use case modeling process
 Example Use Case Diagram

Use Case A Use Case B

Use Case C Use Case D

Actor X
Actor Y

The System
A Partial Use Case Diagram for the Loan
Processing System

Approve Override request

Report on Loan Portfolio Loan Manager

Evaulate Loan Request

Applicant
Loan Officer

Book a Loan

Submit a Loan Request

Accept a Loan

Loan Clerk

Send out late Notice

Customer

Send standard Payment Notice

Account Management
System

Credit Bureau Request Credit Report

Refer Deliquent Loan for Debt

Collection

Collection Agency