business analyst training the basics of business analysis with an overview of enterprise...
TRANSCRIPT
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?
3
Building Relationships
Strategic Alignment
Future Oriented
Doing More with Less
Better Utilization of Resources
Improving Business
Constraining
Reusability
Building a Blueprint Building Bridges between Business
and IT
Common Language
Big Picture View
Standardization
Reengineering
Building a Framework
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 organizationA certain divisionA single departmentA network of geographically distant
organizations linked together by common objectives.
4
The 4 EA Areas of Practice
Business ArchitectureInformation Architecture (Data)Applications ArchitectureTechnology 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
8
Business Process excutes
Business Strategy
realizes Business Idea
Business Architecture
Desired SituationCurrent Situation
defines
Business Architect
Understands the As Is environmentPlans, 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
A visionary
10
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.
A problem solver
What’s the difference?
Business Analyst Business ArchitectReports 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 defined by users
Documents and may define a business strategy using requirements provided by the users
Operates within the confines of a predetermined architecture
Part of the decision making process to define the architecture
11
12
What does an Analyst do?
Apply knowledge of processes
Examine the needs of the
business
Ensure solutions satisfy the needs of the business
Advocate for the business
Ensure requirements are
valid
Gather requirements
Ensure needs are understood and
met
Identify risks
Keep management
informed
Facilitate Feedback
Ensure use of a common language
Justifies changes
Documents requirements
Design new business
processes
Identifies possible improvements to
the business
Analyst vs. Architect
Business Analyst Business ArchitectSpeaks for the business units A neutral voice
A tactical thinker Thinks both tactically and strategically
More concerned about specific project strategies and goals
More concerned with enterprise strategies and goals
Local thinker/Local decisions Global thinker/Global decisions
13
14
Main Goals of Communication
To Inform:Providing information for use in decision making but not necessarily advocating a
course of action
To Request:Requesting a specific action by the receiver of
the communication
To Persuade:Reinforcing or changing a receivers belief
about a topic and possibly acting on the belief.
To Build Relationships:Promoting good-will between you and the
receiver
15
Required Skills
ListeningEmpathizingInfluencingMediatingNegotiatingFacilitatingProblem-solving
16
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.
17
Paired Drawing
You may only use size and shape directions, such as:Short lineLarge 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.
18
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.
19
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.
20
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.
21
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.
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
23
Facilitating
Definition:To assist the progress; to make easier or
less difficult. Helps all parties to build:
TrustA common languageA common understand of the processA common expectation of the solution
24
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.
25
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.
26
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.
Requirement Lifecycle
27
Requirement Requirement LifecycleLifecycle
Gather Gather RequirementRequirement
Document Document RequirementRequirement
Classify Classify RequirementRequirement
Verify Verify RequirementRequirement
Analyze Analyze RequirementRequirement
Manage Manage RequirementRequirement
© Showeet.com
28
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.
Requirement Lifecycle
2929
Requirement Requirement LifecycleLifecycle
Gather Gather RequirementRequirement
Document Document RequirementRequirement
Classify Classify RequirementRequirement
Verify Verify RequirementRequirement
Analyze Analyze RequirementRequirement
Manage Manage RequirementRequirement
© Showeet.com
30
Task by Phase
30
Requirement Requirement LifecycleLifecycle
StakeholdersStakeholders
Elicitation PlanElicitation Plan
Initial Business Initial Business RequirementsRequirements
Robust Robust Business Business
RequirementsRequirements
Business Business Requirement Requirement
Sign OffSign Off
Change Change Management Management
PlanPlan
Process Process DesignDesign
PrioritizationPrioritization
© Showeet.com
31
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.
32
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.
The Party
33
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.
34
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…
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
36
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.
37
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
38
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.
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
41
Just build a simple pocket knife.
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?
44
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)
45
General or Business Requirements
Sound like high-level business goals or objectives. Assist low income OklahomansProtect children from harm
Determined by management; should match the goals and mission of the agency and or divisions involved.
46
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.
47
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.
48
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 monthlyTime 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.
49
Use Case Requirements
Sound like the name of a business process. Generally verb-noun combinations.Locate non-custodial parentDetermine eligibility
Can be provided by any stakeholder. They state the goals for the system.
Will be expanded into actual Use Cases.
50
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.
51
Types of Elicitation Techniques
TargetedGathers information from individual SMEs.
InterviewsJob shadowing or observationSurveys or questionnairesMeetingsCompleting training on the process being
analyzed
52
Types of Elicitation Techniques
GroupUsed in small to medium team situations to
create a synergy between individual team member contributions.
BrainstormingFocus groupsRequirements workshopsPrototyping, models, storyboards
53
Types of Elicitation Techniques
MassUsed 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.
SurveysTown hall meetingsUser group meetingsElectronic suggestion boxes
54
Types of Elicitation Techniques
Harvesting Gathers requirements from documents such
as policy and procedure manuals and analyzes existing systems and interfaces.
Document analysis Interface analysisReverse engineering
Use available information
55
Rules for Elicitation Meetings
Group Session Best Practices
Participants should all be in the same
place
Make sure the topic
process is well defined
Provide near-time
validation of the session
output
Provide pens,
pencils and pads for
each group.
Provide summaries
at the beginning and end of each day
Include a non-
participant scribe (or
two)
Have reference
and resource materials available
Make sure the facilitator (you) is well
prepared and capable
Take frequent
brakes (no more than 2 hours apart)
Keep an action items
list: what, who and
when
Provide refreshments
Define the roles and
responsibilities before the meeting
Provide multiple
supplies if working in
small groups
Review the tools that will
be used beginning of the session
Decide how long the
group will meet before the meeting
Include silent
observers
Include the business
lead supporters
Set up the seating in a U shape so everyone can see
Provide user friendly visuals
Make sure the room is comfortable
Stick to 12-15
empowered participants
Provide sheets to
record parking lot
items
56
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.
57
Elicitation Plan Activity
Locate the Elicitation Plan in your workbook.
Complete the Elicitation Plan for the PartyRemember, you must do a physical harvest
and at least one other type of harvest. Complete the rest of the Stakeholder Table
if necessary.
58
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.
59
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.
60
Business Requirements Document
ColumnsRequirement Number (ID)Requirement TypeRequirementPrioritySourceRelatedChange History
61
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.
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
63
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.
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
65
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.
66
Influence to Concern Matrix
High Influence / Low ConcernStakeholders with political influence of
power but little interaction with the project area. Examples: senior administration, state and federal
partners, and regulations
2
High Influence / High ConcernIdeally this is the area that your
sponsor and champion fall into. They have a high level of influence and are
highly involved in the project area. Examples: program administration,
program operations.4
1These are minor stakeholders. They don’t have a lot of influence and don’t
always care if the project is successful. Example: students and parents-- they don’t care how something is done, just
that is gets completed.Low Influence / Low Concern
3This area typically includes the end
users. They have little influence over the project but are highly concerned
about the end result. Example: Teachers and other end users of the
product.Low Influence / High Concern
67
Influence to Concern Matrix
68
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.
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
71
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
72
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
73
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
74
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
75
Stakeholder Ranking
High Influence / Low ConcernStakeholders with political influence of
power but little interaction with the project area. Examples: senior administration, state and federal
partners, and regulations
2
High Influence / High ConcernIdeally this is the area that your
sponsor and champion fall into. They have a high level of influence and are
highly involved in the project area. Examples: program administration,
program operations.4
1These are minor stakeholders. They don’t have a lot of influence and don’t
always care if the project is successful. Example: students and parents-- they don’t care how something is done, just
that is gets completed.Low Influence / Low Concern
3This area typically includes the end
users. They have little influence over the project but are highly concerned
about the end result. Example: Teachers and other end users of the
product.Low Influence / High Concern
76
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 requirementsPrioritize the requirements as a team.
Document the method used and why you chose it.
77
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.
78
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.
79
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.
80
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.
81
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.
82
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.
83
Brainstorming Session
Keys to Quality Brainstorming
Determine the participants- Should include the project
team, sponsor, Champion and SME’s
Determine how long the session will run. It should be between
1-4 hours. After 2 hours there is a
diminishing return on productivity
Review the rules- Focus on quantityWithhold criticismWelcome unusual
ideasCombine and improve ideas
Brainstorm! Make sure the ideas
are being documented
Compile the ideas developed and verify with the participants
that nothing was excluded
84
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
85
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.
86
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.
87
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.
Diagrams, Models and Use Cases
How to use tools to develop a possible solution
89
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
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 natureA 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?
96
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)
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-directionalRepresented 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 actionThey 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
103
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.
104
Process Flow Shapes and Rules
Event
Process
Decision/ Gateway
Document
Input or Output
Connector
Start/End
Process
Decision
Document
Data:input or output
105
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.
106
Swim Lanes and Pools
PoolSw
imla
neSw
imla
ne
107
The Party Process Model Example
108
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
109
Context Diagram
Represents the highest level view of a process.
Indicates: Systems or ProcessesActors Inputs Outputs
110
Context Diagram Example
System or Process
Actor
Actor
Actor Actor
Input
Output
Input
Input
Output Output
111
The Party Context Diagram
Providing Music for the Party
Spouse
Me
DJ Guests
Get A DJ
Get a DJ
Verify Avaliability
Verify Avaliability
Music PlayedMusic Played
112
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.
113
Actor Goal Identification Diagram
Actor Actor
System
Actor
Input Output
The Party System Actor Diagram
114
Me DJ
Plays Music
Guest
Want Music Enjoys Music
115
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.
116
Use Case Sections
Use Case Name Version Goal Summary Actors Assumptions Triggers Happy Path Alternative Paths Post Conditions Notes
117
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
118
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.
119
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
120
Use Case Diagram Example
Process
Process Step
Process Step
External Actor
Internal Actor
Internal Actor
Process Step
121
Office 78 Use Case
Route Application
Book Location
Provide Food
Me
Family
DJ
Provide Music
122
Use Case Diagram Activity
Locate the Use Case Diagram in your workbook.
Create a Use Case Diagram for your Use Case Happy Path.
123
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.
124
Process Design Sections
Analysis ResultsOptions AnalyzedResults
Solution DesignDiagrams Implementation Considerations
Impact
125
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.
126
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.