Business Analyst Training

The Basics of Business Analysis

with an overview of Enterprise
Architecture

Instructor: Christi Fore

What is Enterprise Architecture?

 Exercise
 If you were to explain to someone what EA
is, what would you say?
 Can you give an example of a business that
follows this?

 Turn to the worksheet on page and

answer the questions in two or three
sentences
2
So what is EA really?
Building Constraining
Relationships
Strategic
Alignment Reengineering

Standardization
Future Oriented

Common Language Reusability

Doing More with Less

Big Picture View

Better Utilization of
Resources
Building a Framework

Building a Blueprint Building Bridges

between Business
Improving Business and IT

3
What do we mean by Enterprise?

 Any collection of organizations, people or

related things that has a common set of
goals and principles. It can be:
 The entire organization
 A certain division

 A single department

 A network of geographically distant

organizations linked together by common
objectives.
4
The 4 EA Areas of Practice

 Business Architecture
 Information Architecture (Data)
 Applications Architecture
 Technology Architecture (Infastructure)

5
Business Arch vs. Technical Arch

 Business Architecture describes what the

business does, what the business looks like
and what the business needs to do it’s job
 Determines that an office needs both land and cell
phones
 Technical Architecture describes how the
business architecture is implemented when
technology is needed
 Determines what type of land and cell phones will
be used.

6
Who Drives EA?

 Business Architecture determines the

“what” of the architecture.
 Technology Architecture determines the
“how” of the architecture

In order to determine the how, we

must first know the what

7
Business Architecture

Business Process exc es

u tes realiz Business Idea

Business
Strategy defines

Current Situation Desired Situation

Business
Architecture

8
Business Architect

 Understands the As Is environment

 Plans, organizes and directs
architectural, engineering, planning and
design of the Business To Be concept
 A member of the architecture team
whose primary responsibility is to take
the “Big Picture” future view of the
structure of the organization

9
What is a BA and why am I here?
 A person who analyzes the operations of
a department or functional unit to
develop a general solution to the
problem.
 Aperson who, when presented with a
business problem, studies it and comes
up with a solution.

10
What’s the difference?

Business Analyst Business Architect

Reports to an IT project manager Reports to managers or senior
managers who may be business
or IT but are independent of the
project
Documents requirements as Documents and may define a
defined by users business strategy using
requirements provided by the
users
Operates within the confines of a Part of the decision making
predetermined architecture process to define the architecture

11
What does an Analyst do?

Ensure solutions Ensure needs are

Apply knowledge
satisfy the needs understood and
of processes
of the business met

Examine the Keep

Advocate for the
needs of the management
business
business informed

Ensure
Gather
requirements are Identify risks
requirements
valid

Facilitate Ensure use of a

Justifies changes
Feedback common language

Identifies possible Design new

Documents
improvements to business
requirements
the business processes

12
Analyst vs. Architect
Business Analyst
Speaks for the business units
A tactical thinker
More concerned about specific
project strategies and goals
Local thinker/Local decisions
Business Architect
A neutral voice
Thinks both tactically and
strategically
More concerned with enterprise
strategies and goals
Global thinker/Global decisions
13
Main Goals of Communication

To Inform:
To Request:
Providing information for use in decision
Requesting a specific action by the receiver of
making but not necessarily advocating a
the communication
course of action

To Persuade: To Build Relationships:

Reinforcing or changing a receivers belief Promoting good-will between you and the
about a topic and possibly acting on the belief. receiver

14
Required Skills

 Listening
 Empathizing
 Influencing
 Mediating
 Negotiating
 Facilitating
 Problem-solving

15
Listening
 Definition:
 Hearing - the act of perceiving sound.

 Listening - to give attention with the ear;

attend closely for the purpose of hearing.
 Hearing is just the first step in listening.
You must also understand what the
speaker said and judge what to do with the
information.

16
Paired Drawing

 You may only use size and shape

directions, such as:
 Short line

 Large square

 The artist may only guess. They may not

ask any other questions.
 Once the artist has guessed what they are
drawing, write the answer on the sheet and
hold it up.

17
Empathizing
 Definition:
 Empathize - to experience empathy.
 Empathy - the intellectual identification with or
vicarious experiencing of the feelings, thoughts, or
attitudes of another.
 Often expressed through tone of voice,
facial expression, and other non-verbal
cues.
 A powerful tool that can be used to build
trust and understanding.

18
Influencing

 Definition:
 Influence - the capacity or power of persons
or things to be a compelling force on or
produce effects on the actions, behavior,
opinions, etc., of others.
 Should always be positive and focused on
the task at hand.

19
Mediating

 Definition:
 Mediate - to act between parties to effect an
agreement, compromise, or reconciliation.
 A safe environment to air differences.
 A non-threatening way to resolve issues.
 Used to bring disagreeing parties to a
solution that all can support.

20
Negotiating

 Definition:
 A back and forth communication designed
to reach agreement where some interests
are shared and some are opposed.
 Develop a win-win for everyone involved.
 All parties may have to lose something for
the common good.

21
The Tree of Life
 Deep in the rainforest stands a very valuable tree.
The locals call it the Tree of Life. It has seemingly
magical properties. From it two powerful medicines
can be concocted. This tree is the only one of its
species in the known world. The tree stands in the
historical and factual lands of the Alwando tribe. The
tribe controls all access to the tree. It is your job to
negotiate with the tribe and secure the rights to the
tree so your company can produce its medication.

22
Facilitating

 Definition:
 To assist the progress; to make easier or
less difficult.
 Helps all parties to build:
 Trust

 A common language

 A common understand of the process

 A common expectation of the solution

23
Problem-Solving

 Definition:
 Using your skills and abilities to discover the
best possible solution to a problem.
 The main function of a BA.
 Requires a willingness to consider all
possible solutions.
 Uses all the other BA skills.

24
Summary

A Business Analyst is a link between a

broken process, new process, or a
problem and a solution. The BA gathers
business requirements and assists with
formulation of a possible solution. The
BA often functions as an intermediary for
the business and technology sides of the
agency.

25
What is a business requirement?
 A necessary attribute, capability,
characteristic, or quality of a solution in
order for it to have value and utility to a
user.
 Something the business needs from the
solution.
 What must be delivered or accomplished
by the solution for it to be considered
successful.

26
Requirement Lifecycle
Gather
Requirement

Manage
Document
Requirement
Requirement

Requirement
Lifecycle

Analyze
Classify
Requirement
Requirement

Verify
Requirement

27
© Showeet.com
Deliverables

 Each phase of the process produces at

least one deliverable.
 Each deliverable should be completed
during the appropriate phase. The phase
cannot be considered complete until the
deliverable has been approved.

28
Requirement Lifecycle
Gather
Requirement

Manage
Document
Requirement
Requirement

Requirement
Lifecycle

Analyze
Classify
Requirement
Requirement

Verify
Requirement

29
© Showeet.com
Task by Phase
Stakeholders

Elicitation Plan

Change
Management Initial Business
Plan Requirements

Requirement
Lifecycle
Process
Design Robust
Business
Prioritization Requirements

Business
Requirement
Sign Off

30
© Showeet.com
Class Project
 To practice the techniques and completing
the documents used, we are going to work
through a process improvement project.
 Each participant has a workbook that
includes all the documents and information
used for the project. Blank versions of all
documents used are available in the BA
Methodology online.

31
The Party

You just landed the job of a lifetime. It has great pay and
wonderful perks. You are throwing a party to celebrate
your new job. You plan to have a formal dinner during
the party. You have invited guests from 3 distinct
groups- your family, your friends, and your coworkers.
Not all of the people you invited know each other and of
the ones who do know each other, not all of them get
along. Using the information provided figure out the
seating arrangement for the party. Because it is a party
you want to seat everyone with people they know and
like. On the flip side you don’t want to seat people who
don’t get along at the same table.

32
The Party Documents

 Go to your workbook.
 Party documents:
 The Problem
 The Attendees
 The Party Room Space Plan
 Guidelines
 Read through all of the Party documents.

33
Determine Stakeholders
 A stakeholder is a person who has an interest in the
output of a project.
 A stakeholder can also be a source of information or
requirements.
 Stakeholders are divided into these subcategories:
 Project Sponsor and Champion
 Process Owner
 Process Users
 Anyone affected by changes in the process, including other
divisions, other agencies, and customers or clients
 Project team members are NOT stakeholders. This
would include the PM, BA, Technical Lead, etc…

34
Identify Stakeholders

 There are many ways to identify stakeholders

for a project.
 Identified in project documents such as the Project
Sponsor, Submitter and Authorizing Approver
 Identified in a Stakeholder Brainstorming Session.
Meet with known stakeholders to brainstorm
additional stakeholders.
 Identified during harvesting of documents and
creating of process flows. Often you will find other
processes that are dependent on your process
during this phase of analysis.

35
Types of Stakeholders
 Sponsor
 The senior person within an organization who has ultimate
responsibility for the success of a project by overcoming
organizational barriers and advocating for the project.
 Process Owner
 The person who is responsible for the process.
 Subject Matter Expert (SME)
 Team members who are experts in a specific field. They represent
one of the business divisions or a particular technical area.
 User
 The persons who actually use the process.
 Other affected groups
 Anyone else who would be affected by changes in the process.

36
Sources Table

 Because it is critical to gather all

requirements, the project team should
include one or more representatives from
all stakeholder groups. You may also have
a smaller work group within the team.
 The Sources table allows the BA to list
each stakeholder area and the
representative for that area.
 The Sources table is part of the
Requirements Document
37
Stakeholder(Sources Table) Activity

 Locate the Sources Table in your

workbook.
 Who are the stakeholders for the Party?
 Complete the Stakeholder Table using the
information you read earlier.

38
What is scope?
 There are two parts to scope
 Project Scope- The work that needs to be
accomplished to deliver a product, service
or result with the specified features and
functions
 Product Scope- The features and functions
that characterize a product, service or result
 Every project has a scope that has been
determined by the leadership and
decision makers.
39
Scope creep

 Scope creep is a term which refers to the

incremental expansion of the scope of a
project. Scope creep is a risk to every project
 Scope creep often causes budget and
schedule overruns
 Scope creep can come from the customer
(requests for new features) or from the
developers (features they just know the
customer wants)

40
Project Pocket Knife
Just build a simple pocket knife.

41
Know the Scope
 It is imperative that you know the scope of
your project before you begin gathering
requirements.
 You may well be given requirements which
are outside the scope of the project.
Those requirements should be documented
and presented to the decision team. They
will either adjust the scope or move them to
a future release.

42
Requirements

What are they, why do we need

them, and what do we do with them
when we have them?
Types of Requirements

 General or Business Requirement (Biz) *****

 Business Rule (BR)
 Quality Attribute (QA)
 Functional Requirement (FR)
 Use Case (UC)
 Data Definition (DD)
 External Interface (EI)
 Technical Requirement (TR)

44
General or Business Requirements

 Sound like high-level business goals or

objectives.
 Assist low income Oklahomans

 Protect children from harm

 Determined by management; should match

the goals and mission of the agency and or
divisions involved.

45
Business Rules

 Sound like policies and regulations.

 Recipients must need nursing home level of
care
 Names of reporters of possible abuse may
not be disclosed
 Determined by management or external
regulations. Often related to the federal
and state laws and regulations that define
how we do tasks.

46
Quality Attributes

 Sound like quality characteristics that a

solution should possess.
 Clients will be able to apply for any program they
are interested in
 Information will be presented at no greater than an
8th grade reading level
 May be established by policy, the users,
the SMEs, or management. These must not
violate any policy, standard, or rule.

47
Functional Requirements

 Sound like how the solution will work.

They are statements of a single action that
must be taken for the solution to be
considered successful.
 Weekly income will be converted to monthly

 Time and leave will be tracked daily

 Can be provided by any stakeholder, and

will often be found in the harvest of
procedure manuals and policy.

48
Use Case Requirements

 Sound like the name of a business

process. Generally verb-noun
combinations.
 Locate non-custodial parent

 Determine eligibility

 Can be provided by any stakeholder. They

state the goals for the system.
 Will be expanded into actual Use Cases.

49
What is Requirements Elicitation?

 The practice of obtaining the requirements of a

system or process from users, customers, and
other stakeholders. The practice is also
referred to as requirements gathering.
 You can never be sure you get all
requirements from the user and customer by
just asking them what the system should do.
You must dig deeper -- clarify, verify, and
validate.
 You must also make sure all requirements are
clear and specific.

50
Types of Elicitation Techniques

 Targeted
 Gathers information from individual SMEs.
 Interviews
 Job shadowing or observation

 Surveys or questionnaires

 Meetings

 Completing training on the process being

analyzed

51
Types of Elicitation Techniques

 Group
 Used in small to medium team situations to
create a synergy between individual team
member contributions.
 Brainstorming
 Focus groups

 Requirements workshops

 Prototyping, models, storyboards

52
Types of Elicitation Techniques

 Mass
 Used with very large groups. The
advantage of this technique is the ability to
gather requirements from large groups
using a minimum of time and staff.
 Surveys
 Town hall meetings

 User group meetings

 Electronic suggestion boxes

53
Types of Elicitation Techniques

 Harvesting
 Gathers requirements from documents such
as policy and procedure manuals and
analyzes existing systems and interfaces.
 Document analysis
 Interface analysis

 Reverse engineering

 Use available information

54
Rules for Elicitation Meetings

Participants Make sure

Stick to 12-
Provide should all be the topic
15
near-time in the same Include process is Make sure
empowered
validation of place silent well defined the facilitator
participants
Provide the session observers (you) is well
refreshments output prepared
and capable

Have Make sure

reference

Review the
and Group Session Best the room is
comfortable
Set up the
seating in a
resource
tools that will
be used
materials Practices U shape so
everyone
available Provide
beginning of Provide can see
the session summaries Take multiple
Provide user
at the frequent supplies if
friendly
Provide beginning brakes (no working in
visuals
pens, and end of more than 2 small groups
pencils and each day hours apart)
pads for
each group.
Include a Provide Define the
Keep an Decide how Include the
non- sheets to roles and
action items long the business
participant record responsibilities
list: what, group will lead
scribe (or parking lot before the
who and meet before supporters
two) items meeting
when the meeting

55
Elicitation Plan
 The BA will create the Elicitation Plan, which
specifies how elicitation will be accomplished
for each stakeholder or group. The plan
should include a physical harvest of available
data, plus at least two other types of elicitation
for larger projects. Smaller projects may only
require one type of elicitation other than the
physical harvest. The plan may also include a
determination of the number of SME’s that
should be used for large stakeholder groups.

56
Elicitation Plan Activity

 Locate the Elicitation Plan in your

workbook.
 Complete the Elicitation Plan for the Party
 Remember, you must do a physical harvest
and at least one other type of harvest.
 Complete the rest of the Stakeholder Table
if necessary.

57
Documenting Requirements

 Once you have figured out what the

requirements are and how to elicit
them, you need to understand how to
document them.
 Documentation of requirements is
important because it allows them to
be traced from the initial request
through implementation of a project.

58
Business Requirements Document

 The Business Requirements Document is

the recommended method for documenting
all business requirements
 This document will be completed for each
project. It will be updated as needed for
the life of the process. If a requirement
becomes obsolete it will be marked
“obsolete,” with the date, not deleted.

59
Business Requirements Document

 Columns
 Requirement Number (ID)
 Requirement Type

 Requirement

 Priority

 Source

 Related

 Change History

60
Business Requirements Activity

 Locate the Business Requirements

Document in your workbook.
 Using the materials provided, document all
the business requirements that you can
find for the Party.

61
V&V

 So how do you know the requirements you

documented are the right ones? Did you
record them correctly? Did you understand
them correctly? Is this really want the
customer wants? You can answer all those
questions by validating and verifying your
requirements. Verification allows you to ensure
that you heard what the customer was saying
while validation assures that the customer was
correct.

62
Verification
 The act of process of establishing the truth,
accuracy or reality of something.
 When you verify requirements you establish that
what you document is in fact what the customer
meant.
 This critical process allows you to ensure that the
requirements are not tainted by any personal bias
you might have.
 You verify requirements by presenting them in a
documented form to the person or group who gave
them to you and have them sign off that you
captured them correctly.
63
Validation

 The act or process of corroborating on a sound or

authoritative basis
 When you validate requirements you establish
that your SME is correct in their understanding of
the process.
 By validating requirements you ensure that the
SME’s personal bias is not overriding the process.
 To validate requirements you present them in a
documented form to the project sponsor or
process owner.

64
Organizing Requirements

 The next step in managing the requirements is

to prioritize them.
 Prioritizing the requirements enables the PM
and BA to make decisions based on those
priorities without having to call the whole team
to a meeting every time a decision is needed.
 Prioritization also helps the stakeholders
determine what features and functions are the
most important to them.

65
Influence to Concern Matrix
High Influence / Low Concern High Influence / High Concern
Stakeholders with political influence of Ideally this is the area that your
power but little interaction with the sponsor and champion fall into. They
project area. Examples: senior have a high level of influence and are
administration, state and federal highly involved in the project area.
partners, and regulations Examples: program administration,
program operations.
2 4

1 3
These are minor stakeholders. They This area typically includes the end
don’t have a lot of influence and don’t users. They have little influence over
always care if the project is successful. the project but are highly concerned
Example: students and parents-- they about the end result. Example:
don’t care how something is done, just Teachers and other end users of the
that is gets completed. product.
Low Influence / Low Concern Low Influence / High Concern

66
Influence to Concern Matrix

67
Prioritizing Requirements: Voting

 There are many ways of prioritizing

requirements. Here are several:
 Cumulative Voting
 Each participant is allowed a set number of votes and are
allowed to cast however many votes per requirement until
they are out of votes. They may choose to use a large
number of votes on requirements they feel are critical and
none on ones they feel aren’t necessary. The
requirements are then prioritized based on how many
votes they received.

68
Prioritizing Requirements: MoSCoW

 MoSCoW Method
 All requirements are ranked as one of the following levels
 Must- These are the critical requirements. Without them the project
fails
 Should- These are important but not critical requirements. The
project won’t fail without them but the customer won’t be very
happy.
 Could- These requirements are nice to have but not important.
Often these requirements can raise customer satisfaction without
adding much cost or time.
 Would like- These are the least critical, lowest payback
requirements. These often comprise the customers wish list.

69
Prioritizing Requirements: Team

 Team Method
 The team goes through the Requirements Document and
prioritizes each requirement. The final prioritization level
is the average of each individual level.

 Prioritization Matrix
 The BA goes through the Requirements Document and
prioritizes each requirement based on who provided the
requirement, the type of requirement, the cost to
implement the requirement, and the penalty for not
implementing the requirement. This method is somewhat
subjective.

70
Prioritization Matrix
 Enter the Cost of Implementation score
 This will be High, Moderate, or Low, not an actual cost. For
the activity, base this on more of a common sense knowledge
of what the costs might be. For a real project you would work
closely with the SME to determine the cost. The scoring
sheet lists some things to consider.
 Enter the Cost of Failure to Implement
 Again, this is a High, Moderate, or Low score, not an actual
cost. The scoring sheet lists common areas to consider for
this item.
 The Formula
 Type + Stakeholder + 2(Implementation + Penalty)= Priority

71
Prioritization Matrix Scores
Type of Requirement - This should be a rating (1-10)
based on the below scale.
Requirement Types Score

Business Rule 10

Use Cases 8

Functional Requirements 5

Technical Requirements 5

Quality Attributes 5

Data Definitions 5

External Interfaces 5

General Requirement 3

72
Failure to Implement- This could be a fine or penalty or it
may indicate an impact on services or benefits.

Cost of Failure to Implement High Moderate Low

Penalties/Fines 10-8 7-4 3-1

Training 10-8 7-4 3-1

Quality 10-8 7-4 3-1

Ease of Use 10-8 7-4 3-1

Stakeholder satisfaction 10-8 7-4 3-1

73
Cost of Implementation- This is based on how much
cost to implement.

Cost of Implementation High Moderate Low

Coding 3-1 7-4 10-8
Testing 3-1 7-4 10-8
Training 3-1 7-4 10-8
Equipment upgrades 3-1 7-4 10-8

Stakeholder dissatisfaction 3-1 7-4 10-8

74
Stakeholder Ranking
High Influence / Low Concern High Influence / High Concern
Stakeholders with political influence of Ideally this is the area that your
power but little interaction with the sponsor and champion fall into. They
project area. Examples: senior have a high level of influence and are
administration, state and federal highly involved in the project area.
partners, and regulations Examples: program administration,
program operations.
2 4

1 3
These are minor stakeholders. They This area typically includes the end
don’t have a lot of influence and don’t users. They have little influence over
always care if the project is successful. the project but are highly concerned
Example: students and parents-- they about the end result. Example:
don’t care how something is done, just Teachers and other end users of the
that is gets completed. product.
Low Influence / Low Concern Low Influence / High Concern

75
Prioritization
 Complete the columns Req Type, Priority
and Source.
 Enter either the requirement number or a
summary of the requirement in the first
column.
 Document any related requirements
 Prioritize the requirements as a team.
Document the method used and why you
chose it.

76
Baselining
 Once all team members and decision makers
have agreed that a document is complete, the
BA will have them sign a baselining document.
This allows for a change management process
to be established using the baselined
document as a starting point.
 Any changes requested after a document has
been baselined would go through the change
management process and would require
approval from the persons specified in that
process.

77
Requirement Traceability
 It is very important to be able to track a requirement
from elicitation through testing. In order to do that, the
BA must be able to establish traceability for each
requirement.
 Traceability allows the BA to document that all
requirements were produced in the process or when,
where, and by whom the requirement was eliminated
or moved to the next stage of the process.
 Using the Source and Related Requirements sections
of the Requirement Document and the Requirement
Tested section of the Test Case Document will provide
tractability.

78
Requirements Management
 The most important function for a BA once
requirements have been gathered is managing both
the actual requirements and the expectations created
by those requirements.
 A change management process for all documents
should be developed for each project or office. It may
be as simple as updating the documents and having
the approving authority sign off on the changes or as
complex as requiring a minimum number of team
members to approve each change. What works for
your office or team and is supported by ALL team
members is the appropriate process for your project.

79
Managing Expectations
 It is important that everyone involved in a
project, from team members to approving
authority to SMEs, understands what to expect
the project results to do for them. Only by
establishing and nurturing realistic
expectations can a project hope to be
considered a success.
 The project team should determine the
expected outcome of the project during the
creation of the scope and vision document and
should refer to it frequently during the process
to ensure that it remains realistic and correct.

80
Solution Development

 Solution development is a process where the

BA, working with the project team, determines
possible solutions that meet all the
requirements gathered during the elicitation
process. The solutions produced must also
meet the Vision, Goals, and Mission of the
agency as a whole and, more specifically,
those of the business unit that is dealing with
the problem being addressed.

81
Solution Development continued
 The first step in developing a solution is to
hold a brainstorming session with the project
team and all the stakeholder representatives.
You may want to include other BAs and
business process engineers.
 This meeting should be informal and should
follow rules for brainstorming. Use the same
guidelines as an elicitation meeting.
 It may be helpful to include one or two people
to act as transcribers to make sure all ideas
are recorded.
82
Brainstorming Session
Determine the Compile the ideas
participants- Should developed and verify
include the project with the participants
team, sponsor, that nothing was
Champion and SME’s excluded

Keys to Quality
Brainstorming
Determine how long Review the rules-
the session will run. Focus on quantity
Brainstorm!
It should be between Withhold criticism
Make sure the ideas
1-4 hours. After 2 Welcome unusual
are being
hours there is a ideas
documented
diminishing return on Combine and
productivity improve ideas

83
Brainstorming Activity

 Locate the Brainstorming Activity in your

workbook.
 Brainstorm with your group for a solution
to the Party problem.
 Any changes to the room layout
 Seating for the attendees

84
Analyzing Solution Possibilities
 Eliminate any ideas that do not meet the
mission, goal, and vision of the customer.
 Eliminate any ideas that do not conform with
applicable federal and state policies.
 Compare the remaining ideas to the list of
requirements.
 Eliminate any ideas that do not meet all the
mandatory/critical requirements.
 Compile the list of remaining possible
solutions.

85
Recommending a Solution
 Ideally the recommended solution will be the
one that meets the most requirements, but
consideration must also be given to budget
constraints and infrastructure if a technical
solution will be recommended.
 If multiple solution options meet approximately
an equal number of requirements they should
all be presented to the project team. The team
can then decide if one option seems better
than the others or if they will present all
options as equal.

86
Analyzing Activity

 Using the ideas that your group captured

during the brainstorming session make any
recommendations to changes in the room
layout. You may choose to draw a new
layout diagram.
 Using the layout diagram fill in your
recommended seating.

87
Diagrams, Models and Use
Cases
How to use tools to develop a
possible solution
Tools

 Diagrams
 Business Concept Diagram
 Business Node Connection Diagram
 Business Process Hierarchy
 Process Model
 Context Diagram
 System and Actor Diagram
 Use Case
 Use Case
 Use Case Diagram
89
Models and Diagrams
 Graphical representations of a process,
vision, idea or method
 A way of looking at things from a
distance to see the whole picture
 Different Models/Diagrams show
different aspects of a process.
 Should always include a Doc Block (a
box that includes the name, date
created, and who it was created by)
90
Business Concept Diagram

 This is actually two diagrams, the As Is

and the To Be.
 Communicates in a graphical manner the
difference between the current state and
the future state
 Cartoonish in nature
 A picture of the benefits that should be
realized by making the change.

91
As Is

92
To Be

93
Business Node Diagram Model

 This diagram is useful when multiple

groups are involved in the completion of
a process.
 Indicates the relationships and
communication that exists between the
groups
 Consists of nodes, needlines, arrows
and exchanges

94
Nodes

 A node is a representation of a group or

business unit.
 Each node must have at one of the processes
or tasks being analyzed.
 A node is represented by a circle
 A node can be a representation of many like
groups or units.
 A node represents the Who involved in a
process

95
Who?
 A role (sponsor)
 An organizational unit (HRMD)
 An office (State Department of Education)
 A geographical location (Oklahoma City)
 A customer profile (Students)
 A building (the capitol)
 A stakeholder (Teachers)
 A partner (Tulsa Public Schools)
 A team (The Thunder)
96
Needlines

 Represent the communication

exchanged between the nodes.
 Can be any type of communication
(phone call, text message, face to face
or electronic)
 Can be either one way or bi-directional
 Represented by an arrow

97
BNCM Example

98
Business Process Hierarchy

 Hierarchical decomposition of the

services provided or needed by the
organization in order to meet strategic
goals
 A view of the business in terms of high
level business processes.
 These processes should stay somewhat
consistent. They are processes that the
business will always do.
99
High Level Processes

 What should be at this level?

 They define what the business does:
 Services provided to customers
 Operational functions performed for employees

 They translate strategy into action

 They are not…..
 How your business does things.

100
How to Name a Process

 Must be a verb noun combination

 Should not use Acronyms
 High level should not name an org unit,
division or tool
 Should be general enough that all
groups/people that do that process could use
it
 Examples
 Mange Staff, Manage Finances, Perform Activity

101
Hierarchy Example

102
Process Model

 At its most basic level, a flow chart that

describes how a process works.
 Graphical display of a process.
 Uses standard flow charting shapes and rules.
 Can be completed at different detail levels for
the same process.
 Shows as much of the process as you need to
see but it should have a logical beginning and
ending point.

103
Process Flow Shapes and Rules
 Event Start/End

 Process Process

 Decision/ Gateway Decision

Document
 Document
Data:
 Input or Output input or
output

 Connector
104
Swim Lanes and Pools
 Swim Lanes and Pools are used to indicate
when more than one person or group of
people are involved in a process.
 Swim lanes can be used either vertically or
horizontally.
 Pools are used when more than one member
of a group do different parts of a process.
 Use a Pool only if there are at least two swim
lanes in it.

105
Swim Lanes and Pools

Pool
Swimlane
Swimlane

106
The Party Process Model Example

107
Process Model Activity

 Locate the Process Model Activity sheet in

your workbook.
 Create a Process Model for the process
Provide Food (1.3) from the BPH

108
Context Diagram

 Represents the highest level view of a

process.
 Indicates:
 Systems or Processes

 Actors

 Inputs

 Outputs

109
Context Diagram Example

Input
Actor

Actor

Output

Input
System or Process

Input

Output Output
Actor Actor

110
The Party Context Diagram

Verify Avaliability
Me

Spouse

Get a DJ

Verify Avaliability Get A DJ

Providing Music for the Party

Music Played
DJ Guests
Music Played

111
System and Actor Diagram
 Helps clarify the scope of the project.
 Suggests possible use cases.
 The Actor can be a person or system.
 External Actors provide the input or receive
the output.
 Internal Actors transform the input into the
output.
 The System is a process or set of
processes that accomplishes a goal.

112
Actor Goal Identification Diagram

System
Input Output

Actor
Actor Actor

113
The Party System Actor Diagram

Plays Music
Want Music Enjoys Music

Guest
Me DJ

114
Use Case
 Expresses the behavior of a system or
process.
 Describes the interactions and behavior as
they relate to the actor.
 Shows how the actor’s goal either gets
delivered or fails.
 Contains only one possible path. Each
solution may have multiple Use Cases.
 Can be easily translated into testing scenarios.

115
Use Case Sections
 Use Case Name
 Version
 Goal
 Summary
 Actors
 Assumptions
 Triggers
 Happy Path
 Alternative Paths
 Post Conditions
 Notes

116
Use Case Specifics

 Uses bulleted or numbered steps to describe

the path.
 Indicates where the alternative path leaves the
happy path and if it returns, indicates where
that happens.
 Documents the process but is not a story
narrative.
 Most often becomes one or more test cases

117
Use Case Activity

 Locate the Use Case Document in your

workbook.
 Using the information provided, complete
the Use Case.
 Include the Happy Path and at least one
alternative path.

118
Use Case Diagram

 Graphical representation of the Use Case.

 Shows the actors, the process, and the basic
steps.
 Does not show sequence or alternates.
 UML says this is a higher level diagram of all
the Use Cases.
 BA standards say this is a diagram on the
same level as and of a single Use Case

119
Use Case Diagram Example
Process

Process Step

Internal Actor

Process Step

External Actor

Process Step

Internal Actor

120
Office 78 Use Case

Route Application

Book Location

Family

Provide Music

Me

Provide Food

DJ

121
Use Case Diagram Activity

 Locate the Use Case Diagram in your

workbook.
 Create a Use Case Diagram for your Use
Case Happy Path.

122
Process Design Document

 The Process Design Document will be

created at this point in the process. This
document details the recommended
solution(s) and identifies their impact.

123
Process Design Sections

 Analysis Results
 Options Analyzed

 Results

 Solution Design
 Diagrams
 Implementation Considerations

 Impact

124
Process Design Document Activity

 Locate the Process Design Document in

your workbook.
 Complete the document using the process
that you created for the Process Model,
Use Case, and Use Case Model.

125
Wrap Up

 Use the tools that help you with THIS

project.
 Document, Document, Document!
 Listen to your SMEs.
 Reuse parts of the current process,
whenever possible.

126