BCS Foundation Certificate in Business Analysis: Course 3507
BCS Foundation Certificate in Business Analysis: Course 3507
BCS Foundation Certificate in Business Analysis: Course 3507
by
Peter Dillon-Parkin
3507/CN/E.2/203/E.1
Copyright
All trademarked product and company names are the property of their
respective trademark holders.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent.
1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -3
Course Contents
Next Steps
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -4
Course Overview
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -5
Course Overview
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -6
Course Overview
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -7
Chapter 1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -2
What Is Business Analysis?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -3
The Development of Business Analysis:
1. The Impact of Outsourcing
► Outsourcing:
• Obtaining services from an external supplier
► Organisations outsource IT services to:
• Reduce risk
• Save costs
• Achieve higher quality
► The outsourcing organisation
• Saves costs in staffing, infrastructure,
and support
• The outsourcing supplier increases turnover and profit
► Communication problems mean we must:
• Create understanding between business and technical groups
• Guarantee frequent and open communication
► Outsourcing emphasises requirements engineering
• This is the only way to ensure that the IT solution matches the business
needs of the organisation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -4
The Development of Business Analysis:
2. Competitive Advantage
► Three factors help IT systems deliver a competitive advantage
• They increase the importance of business analysis
2. Change 3. High-quality
1. Business Needs
Management Requirements
• Business needs must • Change management is • Rigorously defined and
drive the development a critical element in exact requirements are
of IT systems ensuring users adopt crucial to delivering
• Business change is as new technology effective IT systems
important as • By supplying training,
implementing an IT information, and help
system for transitioning
• IT initiatives fail when
the business rejects the
new way of working
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -5
The Development of Business Analysis:
3. Business Analysts as Internal Consultants
► Business analysts can work as internal consultants
• Experience using external consultants has helped to develop the internal
business analysis role
► Internal business analysts
• Are cheaper and quicker to apply to a project
• May lack the external view of a consultant
◦ But are knowledgeable about the business
Pros of an internal consultant Pros of an external consultant
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -6
The Development of Business Analysis:
The Business Change Lifecycle
► Organisations must adopt a Business
Environment
broader view of business
change
• Rather than only focusing on Enterprise Alignment Business
IT Architecture Strategy
• The business change lifecycle
reflects this, showing we
should focus on organisational Realization Definition
needs
Business
Case
► Organisations need the
business analyst role to:
• Find and address Implementation Design
organisational issues
• Locate the root causes of
problems
• Align solutions to business The Business Change Lifecycle
needs and strategy
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -7
The Scope of Business Analysis Work
IT Systems Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -8
Principles of Business Analysis
► The key principles that underlie key business analysis factors when
conducting business analysis work:
Business
Holistic Root causes not
improvement not IT
Agile
symptoms
Approach system change Philosophy
Consider all: Feasible, Key principles and
• Functional areas Options not contributing concepts including:
• Business and technical solutions requirements, not • Collaborative working
meeting all requests
aspects • Iterative software
…when focusing on development
Entire business • Incremental software
improvement of the entire change lifecycle,
business system Negotiation not delivery
not just
avoidance
requirements
definition
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -9
The Role and Responsibilities of a Business Analyst
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -11
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -12
1
Chapter 2
The Competencies of a
Business Analyst
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -2
The Competencies of a Business Analyst
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -3
Discussion Discussion
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -4
The T-shaped Professional
Multi-disciplinary breadth
of knowledge and skill
Deep
knowledge
and skill in
specific
domain
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -5
The T-shaped Professional
Multi-disciplinary breadth
of knowledge and skill
Deep
Skills required to Deep skill
interact with those knowledge
in
from another and skill in specialist
community specific discipline
domain
Specialist skills
needed to conduct
the work of the
particular discipline
Business Analysis (4th Edition) Figure 2.1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -6
The T-shaped Professional
Professional
Techniques
• Stakeholder
analysis &
management
• Requirements
engineering
• Investigation
• Data and
process
modelling
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -7
Competencies of a Business Analyst
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -9
Exercise
Case Study Exercise 2.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -10
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 2 -11
Chapter 3
The Strategic Context for
Business Analysis
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -2
Strategy
Discussion
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -3
What Is Strategy?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -4
Business Analysis and the Strategic Context
► Many benefits arise if the business analyst is aware and can apply
knowledge of the strategic context
► These include the ability to:
Question Provide
Analyse and Build relevance & Analyse leadership
discuss credibility strategic effectiveness and
alignment influence
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -5
Adaptive Strategy Development
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -6
Linear Strategy Development
“The determination of the basic long-term goals of an enterprise, and the adoption of courses of
action and the allocation of resources necessary for carrying out these goals”
—Chandler, 1962
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -7
Hybrid Strategy Development
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -8
Understanding the Strategic Context
► To understand an
organisation’s strategic context,
we should ask several Current State
questions:
• What is the organisation’s
‘current state’?
Execution
• What is the organisation’s
Strategy
desired ‘target state’?
• What is the plan to move
between the current state and
the target state?
◦ Also called strategy
execution, the strategic
mission, or the roadmap
► The answers to these questions
Target State
provide the building blocks for
strategic development
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -9
Understanding the Strategic Context:
The Core Building Blocks
► We show the core building blocks of strategic analysis below:
(Feedback)
Performance measurement
(Mission or roadmap)
► Showing techniques that aid with:
• Current-state analysis of the internal and external environment
• Definition of the target state
• Performance measurement of progress towards the target state
► Techniques on the following slides supplement the analysis of these core
building blocks
Business Analysis (4th Edition) Figure 3.1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -10
Understanding the Strategic Context
(Feedback)
Performance
measurement
Current
Strategy execution Target state
state
(Mission or roadmap)
Strengths Opportunities
Weaknesses Threats
Techniques
associated with
INTERNAL ENVIRONMENT EXTERNAL ENVIRONMENT the core building
ANALYSIS ANALYSIS blocks for the
• VMOST • PESTLE strategic context
• Balanced Scorecard • Porters Five Forces
• Performance
Measurement
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -11
Internal Environment Analysis: VMOST
► VMOST clarifies
Vision
• Vision
◦ The target state for the organisation with no focus on
how to achieve it. The target state is realised through the
completion of the ‘mission Mission
• Mission
◦ What business are we in, and what do we want to
achieve? Usually stated in a mission statement
• Objectives Objectives
◦ What are the specific goals against which our
achievements can be measured? These form
business drivers
• Strategy Strategy
◦ What medium- to long-term approach will we take
to achieve our mission and objectives?
• Tactics
◦ The specific and detailed means for strategy execution Tactics
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -12
Internal Environment Analysis: VMOST Questions
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -13
Example VMOST for the eCloudShare Project
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -14
External Environment Analysis: PESTLE Template
P
Political
E
Economic
S
Socio-cultural
T
Technological
L
Legal
E
Environmental
Trade Disposable Income Trade Climate
Research
regulations income distribution regulation change
spending
and tariffs
Demo- Environment
Money graphics Financial regulation
Government supply Technology regulation
stability Social development Customer
Interest mobility Health and values
rates safety
Pressure
Lifestyle Demand for legislation Packaging
groups
changes innovation and waste
Cost of
Social Regulatory
energy Attitudes to Global
welfare bodies
work Speed of factors
policies technology
Joblessness transfer Company
Unemploy- Education EU-based
law
ment policy factors
Pace of Employment
Employment Inflation Fashions change US-based
law and fads law factors
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -15
VMOST and the Core Building Blocks for Strategic Context
Measures
performance against
Objectives
Performance measurement
Mission Vision
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -16
Performance Measurement: Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -17
Performance Measurement:
Critical Success Factors (CSFs)
► Qualitative descriptions of the critical factors
• These must be in place for the organisation to achieve defined objectives
► Balance your CSFs between the following:
• Financial focus
• Customer-facing focus
• Learning and growth focus
• Business process excellence
► Then align them to the Vision and Mission of the organisation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -18
The Business Scorecard (BSC)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -19
Performance Measurement:
Key Performance Indicators (KPIs)
► KPIs: Quantitative performance measurements tracking how well you do
with your CSFs
• You can use multiple KPIs to measure a single CSF
• Each KPI can measure many different CSFs
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -20
Performance Measurement: Targets
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -21
Critical Success Factors (CSFs) and Key Performance
Indicators (KPIs)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -22
Performance Measurement and VMOST
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -23
SWOT Analysis Matrix: Combining External and Internal
Strengths Weaknesses
• Technological skill • Absence of important skills
Internal to the
organization
Opportunities Threats
• Changing customer tastes • Changing customer tastes
External to the
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -24
SWOT Analysis Do Now
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -25
Strategy Execution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -26
Business Model Canvas
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -27
Business Model Canvas
Key Customer
activities Relationships
Value Customer
Key partners
proposition segments
Key
Channels
resources
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -28
The Elements of the BMC 1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -29
The Elements of the BMC 2
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -30
POPIT™ as a Target Operating Model (TOM)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -31
Exercise
Case Study Exercise Manual
3.1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -32
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 3 -33
Chapter 4
The Business Analysis Service
Framework
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -2
The Business Analysis Service Framework
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -3
The Business Analysis Service Framework
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -4
The Strategic Context for the BA Service
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -5
Recipients of Business Analysis Services
• Business External
owners Stakeholders
• Executives • Governments
• Sponsor • Suppliers
• Partners
Governance • Regulators
Stakeholders • Customers
Operational
Stakeholders
• Domain experts
Project • Business users
• Product owners
Stakeholders • Support staff
• Testers
• Developers
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -6
Situation Investigation and Problem Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -7
Situation Investigation and Problem Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -8
Feasibility Assessment and
Business Case Development
► Examine the problem or opportunity and potential solutions
1. Develop business options to address these issues
2. Evaluate the options for acceptability and feasibility
► Service activities
1. Generate and describe options to resolve the problem
2. Remove unviable options
3. For each option, identify and analyse impacts, risks, and potential responses
4. Identify and analyse costs and benefits for each option
5. Evaluate financial, technical, and business feasibility of each option
6. Evaluate alignment of options with strategic goals
7. Support comparison and selection of solution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -9
Business Process Improvement
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -10
Requirements Definition
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -11
Business Acceptance Testing
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -12
Business Change Deployment
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -13
The Business Analysis Service Framework:
Stakeholder Engagement
► Stakeholder Engagement is not included in the BASF because it is an
auxiliary service
• The value proposition, activities, and techniques involved in stakeholder
engagement are relevant when a BA conducts any of the services
► The activities required to carry out the stakeholder engagement service are
as follows:
1. Identify stakeholders
2. Challenge and inform stakeholders
3. Negotiate stakeholder conflicts
4. Engage with stakeholders
5. Communicate with stakeholders verbally and in writing
6. Support stakeholders
7. Facilitate meetings and workshops and record outputs
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -14
Exercise
Case Study Exercise Manual
4.1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -15
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 4 -16
Chapter 5
Images from Business Analysis (4th Edition) Figure 4.8 (© Debra Paul)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -3
Investigation Techniques
Qualitative
approaches are
Exploratory and aim
Qualitative approaches
to understand what
is needed (the Interviews
quality of things)
Workshops
Observation
Scenarios
Prototyping Quantitative
User role analysis approaches
are concerned with
Quantitative approaches quantities or
numbers (the
Surveys or Questionnaires
quantity of things)
Activity Sampling
Document Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -4
Investigation Techniques: Interviews
Qualitative approaches
► An ‘interview’ implies a formal one-to-one meeting
• You can interview many stakeholders at once to save
Interviews
time and encourage openness
Workshops
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -5
Investigation Techniques: Workshops
Qualitative approaches
► Workshops are a collaborative forum to discuss
issues, resolve conflicts, and elicit requirements
Interviews
Prototyping
Document Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -6
Investigation Techniques: Observation
Qualitative approaches
► Observe the organisation and the staff working in it as
early in an investigation as you can
Interviews
• To get data about the environment and work practices
Workshops
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -7
Investigation Techniques: Scenarios
Qualitative approaches
► In Scenario Analysis, an analyst takes a user step-by-
step through a task
Interviews
• Enabling the user to visualise each step
Workshops
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -8
Investigation Techniques: Prototyping
Qualitative approaches
► Building simulations of a process or system so that
• Users can review and add to them
Interviews
• We can develop a greater understanding of the
Workshops
requirements
Observation
Scenarios
► There is a range of approaches to building
prototypes
Prototyping
• Mirroring the future system by using the
User role analysis
organization’s system development environment
Quantitative
approaches
• Building screen and navigation mock-ups using tools
Surveys or such as PowerPoint and paper prototypes
Questionnaires
Activity Sampling
► Flipchart sheets, pens, and sticky notes can be used to
work with the user to develop the prototype
Document Analysis
• Users can develop screens and identify navigation
• Data—input, reference, and specified/default values for
the system can also be identified
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -9
What Happens If You Don’t Prototype?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -10
Investigation Techniques: User Role Analysis
Qualitative approaches
► Identifying stakeholders who must access services in a
business system
Interviews
• Employees of an organisation may need access to HR
Workshops
services
Observation • Customers of a manufacturing organisation may need
Scenarios access to product-related services
► Individuals who interact with a system have a ‘role’
Prototyping
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -11
Investigation Techniques: Personas
Qualitative approaches
► Personas are precise descriptions of an
imaginary stakeholder and their goals
Interviews
• Imaginary
Workshops
• Specific, but stereotyped
Observation
Scenarios
► Useful for situations where the stakeholder
community is too large for effective analysis
Prototyping
• Websites
User role analysis
• Mobile-phone industry
Quantitative
approaches
► Personas let you target specific stakeholders
Surveys or
Questionnaires • Perhaps only 10 percent of the whole
Activity Sampling audience
Document Analysis
• But targeting your content lets you make that
10 percent “100 percent ecstatic”
► Covering customers as stakeholders
requires around three to five personas
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -12
Stakeholder Personas: Benefits
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -13
Personas Are Not Standalone
Customer “user”
role
Customer Personas
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -14
Quantitative Analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -15
Investigation Techniques: Surveys or Questionnaires
Qualitative approaches
► Surveys can be useful for getting a limited amount of
information from a lot of people
Interviews
• Where interviewing them individually or running a series
Workshops
of workshops is not practical or cost-effective
Observation
► Many software applications may be used to create
Scenarios
online surveys
Prototyping
• Despite the ease of development and access offered by
User role analysis these tools, surveys are not always successful in
Quantitative obtaining data
approaches
Surveys or
• Many surveys are poorly designed and discourage the
Questionnaires participants from completing them
Activity Sampling
► Effective survey design is needed if the survey is to
Document Analysis
generate the required volume of accurate data
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -16
Investigation Techniques: Activity Sampling
Qualitative approaches
► Activity sampling is observing how workers divide time
among a range of activities. How much time do they
Interviews
spend on:
Workshops
• The telephone?
Observation • Reconciling payments?
Scenarios • Sorting out complaints?
Prototyping
► Some results must have a guaranteed level of accuracy
User role analysis
• Such as where they are used to build a business case
Quantitative
approaches
► Activity sampling provides quantifiable data about how
Surveys or
Questionnaires often in a day the group studied perform an activity
Activity Sampling • Analysing that figure against the total amount of time
Document Analysis
available, we can calculate
◦ The total length of time spent on an activity
◦ The average time one occurrence of the activity takes
► This data can be useful when developing business
cases and evaluating proposed solutions
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -17
Investigation Techniques: Five-Step Activity Sampling
Qualitative approaches
Identify the activities to be recorded. Include a ‘not
Interviews working’ activity covering breaks / times away from the
Workshops desk. Perhaps include a ‘not-related’ task for first aid
Observation
or health and safety officer duties.
Scenarios
Decide on the frequency and timings, that is,
Prototyping
when and how often to record the activities being
User role analysis
undertaken.
Quantitative
approaches
Surveys or Visit the study group at the times decided upon
Questionnaires
and record what each group member is doing.
Activity Sampling
Document Analysis
Record the results.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -18
Investigation Techniques: Document Analysis
Qualitative approaches
► Document Analysis reviews documents or reports to
identify data about an organisation, process, or system
Interviews
• Documents may be physical or digital
Workshops
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -19
Recording a Business Situation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -20
Recording a Business Situation: Rich Pictures
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -21
Recording a Business Situation: Mind Maps
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -22
Recording a Business Situation: Mind Maps
Business Analysis (4th Edition) Figure 5.7 Example of a mind map Created with Xmind
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -23
Five Whys Do Now
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -24
Applicability of Investigation Techniques
► Some techniques in this chapter are good for general investigation of the
problem situation
• Others are more useful when eliciting requirements for a new system
► Some work better with a linear, analysis approach
• Others when using an Agile software development approach
► Some techniques are suitable in all situations
• The table following this slide gives a guide to the suitability of these
techniques for the different situations
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -25
Applicability of Investigation Techniques
HR Highly relevant
R Relevant in
many situations
LR Limited
relevance
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -26
Exercise
Case Study Exercise 5.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 5 -27
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -2
6
Categories of Stakeholder
► A stakeholder is anyone:
• Affected by the initiative/project
◦ Or
• Who can influence it
Competitors Regulators
Suppliers Owners
Partners Employees
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -3
6
Stakeholder Discussion
Identification
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -4
6
Analysing Stakeholders
Interest
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -5
6
Analysing Stakeholders: Power and Interest Grid
High
of a stakeholder Watch Keep satisfied
active
management
• It is our team’s
Power/Influence
perception of reality
• Which we need to
Some
cross-check Keep
onside
► The most common
disasters revolve around
the ‘low/low’
Low
classification Watch Keep Informed
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -6
6
Analysing Stakeholders: Attitude and Involvement
High
of the status
publicly or secretly, our quo
initiative
Power/Influence
► We’d like to turn them into
Some
Fans, but Sleeping Dogs
would do
• We’d also like to turn
Silent Partners into Sleeping Silent
Fans Dogs
Low
Partners
Attitude
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -7
6
Describing Stakeholder Responsibilities: RACI
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -8
6
Interacting With Your Stakeholders
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -9
6
Managing Stakeholders: Stakeholder Plan/Assessment
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -10
6
Exercise
Case Study Exercise 6.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -11
6
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -12
6
Chapter 7
Improving Business
Services and Processes
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -2
Why We Model Value Streams and Business Processes
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -3
The Business Process Hierarchy
Actor-task level
• The sequence of actions performed by an
actor in one place at a point in time
• Can be defined using text or a UML activity
diagram notation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -4
Event Response View of Process Hierarchy
Main
Level 0 (Enterprise) Business
Level 1 (Enterprise) 1 3 5
Level 2 (Event-Response)
Process 1
1. Step 1
Level 3 (Actor-Task) Task 2. Step 2
3. Step 3
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -5
Techniques Used at the Enterprise Level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -6
Techniques Used At The Enterprise Level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -7
Techniques Used at the Enterprise Level: SIPOC
► To explore the Enterprise level of the process hierarchy, you can use the
SIPOC framework
• The (SIPOC) framework looks at five key elements:
► To create a SIPOC diagram, create a basic map of the process, then
identify the:
• Suppliers who provide raw materials or stock to us
• Necessary Inputs without which the process cannot operate
• The Process itself – how we deliver customer value
• The process Outputs – the value delivered to customers
• The Customer who receives those outputs
► Finally share the diagram with your stakeholders to verify your results
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -8
Example SIPOC Diagram for a Pizza Restaurant
Dough Prepare
Food Tomato dough
Catering sauce Add sauce Whole pizza Dining
equipment Anchovies Add toppings Pizza slices Take out
Boxes Mozzarella Add cheese Boxed pizza Delivery
Condiments Capers Bake Pizza
Pepperoni Box Pizza
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -9
Techniques Used at the Enterprise Level: Value Chain
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -10
Porter’s Value Chain
Organizational infrastructure
Support activities
Human resource management Secondary
processes
Technological development
Margin (value)
$
Procurement
Organizational
Operations
Outbound
and sales
Marketing
activities
logistics
logistics
Primary
Inbound
Service
processes
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -11
Value Chain Analysis (Porter)
Orders
Complaints
Inbound Outbound Marketing Queries
Operations Service
logistics logistics and sales
Products
Organizational HR Technology
Procurement
infrastructure management development
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -12
Techniques Used at the Enterprise Level:
Value Proposition
► A value proposition clarifies three things:
1. The customer value an organisation offers through its products
◦ Value the organisation believes customers will see as beneficial to them
2. How the organisation’s products deliver what their customers need
3. How our organisation is different to our competitors
► A value proposition is a powerful tool if we understand what customers
need and prize
• We can align our understanding with customer values
Product/Service attributes
Customer
Functionality Price Quality Choice Availability Image
relationship
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -13
Event Response View of Process Hierarchy
Main
Level 0 (Enterprise) Business
Level 1 (Enterprise) 1 3 5
Level 2 (Event-Response)
Process 1
1. Step 1
Level 3 (Actor-Task) Task 2. Step 2
3. Step 3
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -14
Aspects of the Event Response Level: Business Events
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -15
Aspects of the Event Response Level
Goods In
Check and Move to
► Task refers to an individual accept back-door
activity in the overall process delivery holding area
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -16
Aspects of the Event Response Level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -17
Example: UML Activity Model
► An activity model shows the work carried out to complete the business
process, at an overview level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -18
Event Response View of Process Hierarchy
Main
Level 0 (Enterprise) Business
Level 1 (Enterprise) 1 3 5
Level 2 (Event-Response)
Process 1
1. Step 1
Level 3 (Actor-Task) Task 2. Step 2
3. Step 3
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -19
Analysis Considerations at Actor-Task Level
► The actor-task level of the process hierarchy shows the work conducted in
each task
• An ‘as is’ business process model provides insights into issues such as the
process flow between tasks
► Business analysts investigate to understand
• What improvements to recommend
• Where those improvements are needed
► A detailed task analysis examines each task in the
business process model
► Investigating in this way helps to identify:
• Problems
• Potential improvements
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -20
Analysis Considerations at Actor-Task Level
Do Now
Business Analysis (4th Edition) Figure 7.11: Image Peter Dillon-Parkin use with permission
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -21
Analysis Considerations at the Actor-Task Level
Reference
Area for
Description
analysis
Actor The role, group or system responsible for performing the task.
The event that triggers the task; other than the initial task in the
Event
business process, each task is initiated by a sub-event.
The information needed to conduct the task. This may be the same
Input as the event but, in most situations is the information used rather
than the trigger to start work.
The deliverable(s) produced from conducting the task. This may be:
Output(s) • A tangible deliverable, such as a product,
• A less tangible deliverable, such as information.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -22
Analysis Considerations at the Actor-Task Level
Reference
Area for
Description
analysis
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -23
Analysis Considerations at the Actor-Task Level
Area for
Description
analysis
Actor Customer service
Event Customer product request received
Input Details of product the customer requires
Outputs Order requirements to be fulfilled or reserved
Average time to handle call is 3 minutes; equates to 1/20 of
Check Costs
Availability of hourly rate for customer service call handler
Product
1.Complete call in maximum of 5 minutes; on average,
complete call in 3 minutes.
Performance
2.Check customer identity at outset of 100% of calls.
measures
3.Advise customers of company policies and regulations once
customer identity confirmed during 100% of calls.
1.Greet customer
2.Perform customer identity check
1. If customer fails identity check, terminate call
2. Else continue with call
Steps 3.Ask for customer requirement
1. If product available proceed to Record customer
order task
2. Else proceed to Reserve product task
4.End task
Business Analysis (4th Edition) Table 7.14
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -24
Analysis Considerations at the Actor-Task Level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -25
The Business Process Hierarchy
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -26
Analysing As-Is Process Models: Enterprise Level Issues
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -27
Analysing As-Is Process Models: Actor Level Issues
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -29
Analysis of As-is Process Model
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -30
The Purpose of Customer Journey Maps
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -31
The Purpose of Customer Journey Maps
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -32
Customer Journey Map Elements
Different personas might perform the same role. ‘Consumer’ is a very broad
grouping - identifying and analysing different ‘consumer’ personas will
Persona
• Improve your analysis
• Give you a full grasp of customer experience requirements
The personas desired outcome; may include tangible and intangible
Persona goal
outcomes
Stages of customer Identification of points of engagement for the customer in the value stream or
journey value chain definition of the high-level stages
Decomposition of those high-level stages into specific touchpoints between
Touchpoints
the customer and the organisation.
RAG assessment of Colour coding customer experience perceptions using red (negative); amber
touchpoints (neutral); green (positive)
Emotional responses of Statements or feedback that reflect the emotional response to the customer
persona experience at each touchpoint
Potential improvement
Opportunities for improvement at each stage
opportunities
Table 7.8 Elements considered within a customer journey map: Business Analysis v4. BCS Learning & Development Limited
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -33
Customer Journey Maps: Key Aspects
Aspect Description
The role and persona are the core of the customer journey map. Different
customers have different experiences at each touchpoint in the journey.
Point of view
For example, some may like a chat about the weather and others may
wish to purchase without 'unnecessary chat.'
The map should be chronological, showing the stages across a logical
Structure
time flow.
In the 'journey,' we consider the customer experience at each touchpoint,
Scope reflecting a single persona. We analyse other personas using alternative
customer journey maps.
The customer experience is the main focus of a customer journey map.
Focus The customer's external perceptions of the process are the core the
technique, not internal organisational process requirements.
Drawing the customer journey map is not enough. The map must form a
basis for:
Uses • Analysing customer experiences
• Evaluating touchpoints
• Identifying where improvement is necessary/possible
Business Analysis (4th Edition) Table 7.9
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -34
Exercise
Case Study Exercise 7.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -35
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 7 -36
Chapter 8
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -2
The Gap Analysis Process
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -3
POPIT™ And Gap Analysis
People
• Skills, motivation,
performance objectives,
Processes
recruitment approach and
• Process and task
criteria, appraisal and
definitions
development approach,
• Business events
salaries and benefits
• Business rules
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -4
Formulating Options
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -5
Formulating Options
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -6
Types of Options
Exhaustive
option
(includes all
features)
Cost
Extended
option (basic
plus some
additions)
Basic option
Time
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -7
Design Thinking
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -8
Design Thinking
Stage Techniques
Empathise Investigation techniques,
personas, empathy mapping and
customer journey mapping.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -9
Divergent and Convergent Thinking
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -11
Design Thinking
Problem or Business
opportunity outcome
Design thinking Double Diamond model (© Assist Knowledge Development Ltd.) – Graphic Peter Dillon-Parkin
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -12
Exercise
Case Study Exercise 8 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -13
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 8 -14
Chapter 9
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -2
The Business Case in the Project Lifecycle
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -3
The Business Case in the Project Lifecycle
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -4
The Business Case in the Project Lifecycle
Initial business
case before
Feasibility study
resources
committed
Decision Gates
Business case
confirmed once
Solution design
development costs
confirmed
Benefits Operation of
realization new processes
checked and systems
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -5
Identify the Areas of Feasibility Assessment
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -6
PESTLE For Feasibility Assessment
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -7
Structure of a Business Case
Introduction
Options considered
Option description
Impact assessment
Risk assessment
Recommendations
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -8
Analysis of Costs and Benefits
immediate long-term
Immediate Long-term
Realization
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -9
Analysis of Costs and Benefits
► Intangible costs
Cost model
• Training
• Downtime due to implementation
► Tangible costs
• New hardware
• Software licenses
► Tangible benefits
• Sales revenue
Benefits
• Cost savings
model
► Intangible benefits
• Help get new business
• Become more efficient
• Support our staff
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -10
Impact Assessment
► Organisation structure:
• You may need to reorganise the business structure to exploit new processes
and systems. For example, creating:
• A single point of contact for customers
• More generalist rather than specialist staff roles
► Reorganisation:
• Unsettling for staff and managers, so planning is crucial for effective project
delivery
► Interdepartmental relations:
• Relationships between departments may change
• We may need to Introduce service level agreements
• Redefine departmental relationships
► Working practices:
• New processes and systems lead to changes in working practices
• We must introduce them with care and sensitivity
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -11
Impact Assessment
► Management style:
• We may reduce the management hierarchy, empowering customer-facing
staff to make decisions. The management style will have to change
► Recruitment policy:
• The organisation may have to recruit people using a different recruitment
approach
► Appraisal and promotion criteria:
• We may need to change staff targets, objectives, and incentives to
encourage different behaviours
◦ Increased customer focus, for example
► Supplier relations:
• We may have to redefine how we work with suppliers
• Implementing a collaborative customer/supplier relationship approach rather
than one that is adversarial
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -12
Risk Assessment
► Description:
• We describe the cause of the risk and its impact
• Example: “Uncertainty over the future leads to the resignation of key
staff. This leaves the organisation with a lack of experienced staff”
► Impact assessment:
• Assesses the extent of the harm suffered if the risk occurs
• We can use quantitative measures, but a scale of ‘small’ ‘moderate’ or ‘large’
may be enough
► Probability:
• How likely it is that the risk will materialise
• Sometimes we can calculate precise probabilities, but it is enough to use a
scale of low, medium, or high
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -13
Risk Assessment
► Countermeasures
• Reduce the likelihood of the risk occurring (prevention)
• Lessen the risk’s impact if it does (mitigation)
• You can transfer the risk’s impact by using insurance
► Ownership:
• Each risk should have a risk ‘owner’
• The person best placed to take necessary countermeasures
• We may ask senior managers within the organisation to take the
responsibility
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -14
Job Aid: Handling Risk
Identify risks
Within your Plan prevention
control strategy
Low-impact Monitor/
risks reassess
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -15
Business Case Within an Agile Context
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -16
Business Case Within an Agile Context
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -17
Investment Appraisal
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -18
Payback Period
► The Payback Period is the time it takes, expressed in months and years, to
repay your investment
• A project with costs of $100,000 and benefits of $120,000, where you realise
benefits equally across a year, has a payback period of 10 months
► Payback is the point where:
• Cumulative benefits = cumulative costs
► Sometimes this is simple to calculate – sometimes it is not
• In the example below, Payback occurs somewhere after Year 1—but where?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -19
Example: Formula for Payback Period
► Since the project goes from deficit to profit during the second year, the
payback period is 1 year + n months
► You calculate n by the formula:
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -20
Payback Period: Pros and Cons
► Pros ► Cons
• Easy to apply and understand • Too simple for some projects
• Addresses the timing issues of • Ignores the time value of money
cash flows • Assumes you can accurately
• It can be helpful if carefully used forecast the payback period
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -21
Payback and Risk – Time Value of Money
£ £
Present Future
£ £
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -22
The Time Value of Money
► If we compare the two options below over five years, they come to the
same number of dollars
Option Yr0 Yr1 Yr2 Yr3 Yr4 Cumulative
Office suite 250 0 0 0 0 250
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -23
What Is A Discount Rate?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -24
Example: The Time Value of Money
► Assuming a discount rate of four percent, then our figures look a little
different:
Option Year 0 Year 1 Year 2 Year 3 Year 4 Cumul.
Office suite 250 0 0 0 0 250
Google Apps 50 50 50 50 50 250
Google Apps 50/(1.04)0 50/(1.04)1 50/(1.04)2 50/(1.04)3 50/(1.04)4
discounted
Google Apps (PV) 50 48 46 44 43 231
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -25
Net Present Value (NPV)
► Net Present Value (NPV) calculates net benefits in terms of today’s values
• It calculates the time value of money, so that you can more accurately
compare differing potential solutions or even competing initiatives
► A project that has costs of $100,000 and benefits of $120,000 shows a net
financial gain of $20,000
• The NPV of that gain is closer to $18,600 if the discount rate is 7 percent
► Pros
• Can reflect risk
• Modifying assumptions is easy
► Cons
• Not consistently accurate for initiatives early in the development phase
• Appropriate discount rates may be difficult to estimate
• May use many periods—it is difficult to predict the future three, five, or eight
years from now!
◦ Many organisations often limit their analyses to a specific number of years
in the future.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -26
The Use of Net Present Value
Using a 10%
Year Net cash flow Discount factor Present value discount rate,
compare to
0 –310,000 1.000 –310,000 cumulative net
cash flow,
1 90,000 0.909 81,810 which would be
2 90,000 0.826 74,340 50,000!
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -27
Internal Rate of Return (IRR)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -28
Calculating Internal Rate of Return
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -29
The CARDI Log
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -30
Exercise
Case Study Exercise 9.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -31
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 9 -32
Chapter 10
Establishing the
Requirements
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -2
The Importance of Requirements
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -3
The Requirements Engineering Framework
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -4
The Requirements Engineering Framework
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -5
Actors in Requirements Engineering
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -6
Types of Requirements
Business Solution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -7
Other Requirement Types
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -8
Hierarchy Of Requirements
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -9
Requirements Elicitation
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -10
Requirements Elicitation
Choose requirement gathering techniques that work best for your participants:
► Visualisation: Rich pictures, mind maps
► Modelling: Business process models, data models use case models
► CSF analysis: CSFs provide insight into the measures used in an
organisation or business area.
► Scenario analysis: A step-by-step walkthrough to uncover alternate paths in
the standard process flow
► Prototyping: Constructing prototypes to visualise screens, reports, or
scenarios
► Workshops can
• Start requirements elicitation
• Help to analyse complex requirements
• Resolve conflicting requirements
• Test prototypes of the proposed solution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -12
Requirements Elicitation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -13
Tacit Knowledge
► Stakeholders convey explicit facts about data and processes they can:
• Readily identify
• Easily articulate.
► Tacit knowledge is information stakeholders find difficult to explain
• Michael Polanyi (1966) identified tacit knowledge, saying, ‘We can know
more than we can tell.’
• Another way of expressing this is to refer to the ‘unknown knowns’
► BAs overlook requirements because business staff:
• Fail to mention them
• State their requirements reluctantly
• Avoid stating complex and difficult to explain requirements
• Feel that the need is self-evident and assume the analyst is aware of it
◦ A tacit assumption that is often incorrect
► In short, business staff often do not clearly articulate what they want the
system to do
• The analyst must help them articulate their needs
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -14
Tacit Knowledge
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -15
Tacit Knowledge: Front Story/Back Story
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -16
Tacit Knowledge: Individual and Corporate
Corporate
• Procedures
• Norms • Style guides
• Culture • Processes
• Networks • Knowledge sharing
• Organisational history repositories
• Back story • Manuals
• Company reports
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -17
Elicitation Techniques and Tacit Knowledge
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -18
Requirements Analysis
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -19
Categorising Requirements
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -20
Modelling and Prioritising Requirements
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -21
Elements Of Requirements Analysis: Requirement Filters
Checking for
Unravelling multiple overlapping or Confirming relevance
Evaluating feasibility
requirements duplicate of the requirement
requirements
Confirming quality of
expression Clear Concise Business feasibility
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -22
Requirements Filters Do Now
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -23
Elements Of Requirements Analysis: INVEST
► The INVEST acronym lets you check and improve your user stories
• INVEST is a set of quality attributes like those listed in the previous filters
INVEST
Each user story/product backlog item:
attribute
Independent Should not be dependent on other user stories but should be discrete
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -24
MoSCoW
Could have: Desirable but the solution is acceptable without these requirements
C as timescale and budget may prevent their inclusion.
Want to have but won’t have this time: Requirements deferred until a later point.
There may be business or legal reasons why certain requirements are deferred to
a later point; perhaps they relate to
W • An aspect of business strategy due to be put into operation in the future
• An anticipated legal change.
Some requirements need further consideration as they could cause delays to
mandatory requirements if implemented earlier.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -25
Business Rules 1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -26
Business Rules 2
Constraints Techniques
Operational
Techniques
guidance
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -27
Exercise
Case Study Exercise 10.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -28
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 10 -29
Chapter 11
Documenting and
Modelling Requirements
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -2
Documenting and Managing Requirements
► Requirements documentation:
• This stage documents the requirements, at varying levels of accuracy and
completeness
• You can use both writing and diagrams to document requirements
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -3
A Framework for Requirements Engineering
1. Requirements elicitation
• What do we need to know and how do
we get it?
2. Requirements analysis
• Is the information correct? Complete?
Conflicting?
3. Requirements validation
Requirements • How do we achieve understanding,
Framework ownership, and sign-off?
4. Requirements documentation
• How do we formally document what is
needed?
5. Requirements management
• What are methods for baselining the
document and handling changing
requirements?
Business Analysis 3rd Edition Reference: Page 185
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -4
Importance of Documentation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -5
Documentation Styles
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -6
Building the Requirements List
► Can you see any issues that might worry you about these requirements?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -7
Elements of a Requirements Catalogue
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -8
Requirements Catalogue: Requirements Detail Level
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -9
User Stories
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -10
User Stories: Story Card
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -11
User Stories: Story Development Principles
► The 3Cs framework summarises the principles for user story development:
► Card:
• We document each story using a card to limit the amount of story information
► Conversation:
• Each user story is a placeholder for a conversation, exploring the story in
greater depth
► Confirmation:
• Each user story is only considered fulfilled when we:
• Check it against defined acceptance criteria
• Confirm we have met the criteria
◦ We determine if we have met the user story goal by using user story
acceptance criteria
► The user story format answers the questions, Who? What? Why? The
format is:
• As a <user role> I would like <capability> so that I can <result>
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -12
User Stories: Technique
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -13
User Stories: Documentation Styles
► Epics are complex user stories that often contain compound requirements
• Epics take the same place in Agile that Business Requirements do in Linear
projects
► In the same way that BAs decompose Business Requirements into
Solution Requirements
• We 'split' each Epic into several individual
user stories
• Making it easier to prioritise, analyse,
explore, and develop the split user stories
► Epics relate to business-focused use
cases, not system use cases
• As a result, they show a more
holistic view
• Achievement of the epic's goal
drives changes to all POPIT
elements, not only software
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -14
Documentation Styles: Diagrammatic
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -15
Context Diagram
► This initial diagram is known as a Context Diagram and it has many uses,
providing:
A basis for
A means of
identifying the
exploring each of
individual use
the major
cases to be
interactions with
available to the
the solution
actors
► BAs will develop the context diagram into a Use Case Diagram
Business Analysis (4th Edition) Figure 11.1
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -16
Use Case Diagram
► A use case diagram shows the set of features stakeholders need from a
solution
• Each use case represents an actor goal achievable by interacting with the
solution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -17
Use Case Diagrams (UCD)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -18
The Use Case Diagram
Use-Case2
Actor
Actor_Name
► We also need:
• A text version of the use case called either the 'use case description' or the
'scenario'
• A structure for the use cases showing a holistic view of the system
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -19
Use Case Description
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -21
Modelling Data Requirements
► Data models allow system users to agree what data will be recorded and
accessed. Data models also provide:
• A basis for database design in bespoke developments
• Help in the evaluation of a packaged application
► Data modelling is not only the province of system developers or IT
professionals
• It is a key tool for the business analyst
► It helps analysts to understand the business rules that govern
organisational data:
• Creation
• Manipulation
• Deletion
► Data modelling helps us to understand the data needed to support process
improvements
• It helps to communicate data requirements to the design and development
team
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -22
Class Models
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -23
Objects and Classes
► Objects
• An object is anything we wish to hold data about – in a banking system, a
customer called Peter Simon, for example
► Classes
• To build a system data model we create classes of objects, not individual
objects
◦ Classes are templates providing a generic definition of the data items or
attributes
◦ Objects are the instances of a particular class
• Peter Simon is an object of the class Customer
◦ The class Customer has attributes, such as Name and Address, etc.
◦ The object Peter Simon has values associated with these attributes
Customer
Class
Name
Attributes Address
Tel. No
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -24
Classes, Attributes, and Associations
Customer Account
Class
Name Number
Address Type
Attributes Balance
Tel. No
Association
► Associations are relationships between entities
• Represent a period of time the entities are connected for a particular reason
► To which we add multiplicity
owns
Customer Account
belongs to
► But wait!
• How many accounts can a customer own?
• An account belongs to how many customers?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -25
Multiplicity
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -26
Reading Multiplicity
1 0..*
owns
Customer Account
belongs to
owns 0..*
Customer Account
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -27
The Product Backlog in an Agile Environment
► Some suggest that models are not used in projects using Agile
• Because there is no need to define the requirements up front
► The Agile Manifesto states that working software is valued over
comprehensive documentation
• The manifesto does not say that documentation has no value
• Just that working software is more valuable
► When working in Agile it is a poor idea to ignore documentation
• Most projects define requirements in some way
• Understanding the different documentation styles helps analysts to ensure
◦ We do the work needed
◦ Unnecessary or over-detailed documentation is not produced
► It is all about relevance
• We should only produce justified and relevant documentation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -28
The Product Backlog in an Agile Environment
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -29
Content of the Requirements Document
Business
Requirements
document
Introduction Business
Function Requirements Glossary of
and process Data model
models catalogue terms
background models
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -30
Exercise
Case Study Exercise 11.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -31
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 11 -32
Chapter 12
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -2
The Requirements Engineering Framework
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -3
Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -4
Formal Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -5
Formal Requirements Validation:
Business and Project Representatives
► The Business Sponsor
• Reviews the requirements to ensure they:
◦ Align with business objectives
◦ Do not venture outside the project scope
► Business Owners of individual requirements review the requirements
ensuring they:
• Express the business needs
• Are clear, correct, and without ambiguity
◦ This is the last chance for business representatives to check the
requirements before acceptance
► Subject Matter Experts
• Check that the requirements reflect the correct business practice
► Solution Architects
• Check that the requirements provide a firm basis for the development and
delivery of the solution
◦ Within the architectural context of the organisation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -6
Formal Requirements Validation:
Business and Project Representatives
► The Developers
• Check that the requirements are technically workable
► The Testers
• Check that the requirements are testable
► Project Office Representatives
• Check that the requirements are compliant with business standards and
policies
• Correct quality review procedures have been followed
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -7
Formal Requirements Validation:
Review Comments
► Methods for collating review comments on a requirements document:
• Attending a meeting
• Submitting comments via a shared online forum
• Providing individual responses via email
► Whatever your approach to the requirements document review, you must
fill two key roles
• A Chairperson who controls the review
• A Business Analyst who provides information about the requirements
◦ Which may involve presenting the requirements to the review meeting
► Different representatives should review aspects of the requirements
• A typical validation problem is stakeholders who are too busy to study the
requirements document or conduct a formal review
◦ The BA and PM should emphasise the importance of this task
Stressing the impact and risks associated with incorrect or inadequate
requirements
• However, some reviewers may feel they need to review every aspect of the
requirements document
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -8
Formal Requirements Validation: Review Outcomes
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -9
Agile Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -10
Agile Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -11
Agile Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -12
Agile Requirements Validation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -13
The Requirements Engineering Framework
► Requirements Management
• This stage is concerned with managing changes to the defined requirements
and ensuring the desired level of traceability is achieved
Requirements documentation
Requirements management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -14
Requirements Management
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -15
Requirements Management: Traceability
Horizontal
Vertical
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -16
Requirements Management: Change Control
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -17
Exercise
Case Study Exercise 12.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -18
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 12 -19
Chapter 13
Delivering the
Requirements
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -2
Delivery Lifecycles
► The business change lifecycle shows the stages to be carried out when
analysing, developing, and delivering business changes
• While this lifecycle shows the areas of activity needed to deliver business
change, it does not show how a solution is developed and delivered
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -3
Delivery Lifecycles
Waterfall
V-Model
Iterative
Incremental
13-4: Business Analysis (4th Edition) Figures 13.3, 13.4, 13.6, 13.8 (clockwise starting at top left)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -4
Delivery Lifecycles: Waterfall Approach
► Development proceeds
Feasibility
through a series of stages study
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -5
Delivery Lifecycles: The ‘V’ Model
► The ‘V’ model is a variant of the waterfall model and consists of similar
stages and sequence of the work
Unit
test
Develop criteria Test
modules modules
Develop
solution
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -6
Delivery Lifecycles (Extended ‘V’ Model)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -7
Delivery Lifecycles (Incremental)
Feasibility
study QA/Testing/
Verification
Analysis
Implementation
Design
Development
Increment 2
► A regulatory deadline or an expected
move by a competitor may make it
QA/Testing/
imperative to implement some Verification
requirements quickly
• Others may be less urgent and can be Implementation
delivered at a later point.
► One way of achieving this is to develop
and deliver the solution in a series of
increments
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -8
Delivery Lifecycles: Iterative Lifecycle (Agile)
► Using the waterfall, ‘V’, and incremental models means there must be a full
set of requirements gathered at the project start
• These form the basis for all subsequent work
► Agile, iterative development increasingly uses prototyping and related
techniques
• To evolve detailed requirements and software features
Business Analysis (4th Edition) Figure 13.7 (© Assist Knowledge Development Ltd)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -9
Delivery Lifecycles: Iterative Lifecycle (Agile)
Business Analysis (4th Edition) Figure 13.8 (© Assist Knowledge Development Ltd)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -10
Advantages and Disadvantages of the Lifecycles
Business Analysis (4th Edition) Figures 13.3, 13.5, 13.6, (top to bottom)
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -11
Advantages and Disadvantages of the Lifecycles
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -12
Advantages and Disadvantages of the Lifecycles
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -13
Exercise
Exercise 13.1 Manual
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -14
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 13 -15
Chapter 14
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -2
People at the Heart of Business Change Design and
Development
► It is impossible to change processes and systems without considering
• People and their emotional responses to change
• New skills need to carry out new work practices
• The impact of merged roles and teams on the
structure of the organisation or business area
• Task changes and the corresponding need
to redefine job roles
• Whether changes are required to performance
measures
► All of the POPIT areas need to be thought
through
• Not only in terms of what the
changes might be but also
how the changes may
be delivered
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -3
POPIT Perspective: People
People
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -4
POPIT Perspective: Organisation
► Where revised processes merged or changed roles, you must define a new
organisation structure
• Consider the impact upon the management approach
► Changes to business processes result in revised or new job roles
• For which job descriptions are required
► The business analyst should collaborate with
specialists from other disciplines, such
as organisational design, to produce
these job descriptions Organisation
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -5
POPIT Perspective: Processes
Processes
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -6
POPIT Perspective: Information and Technology
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -7
BA Role in Design
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -8
BA Role in Development
► Business analysts work with the business staff and development team to
• Help with detailed queries about the requirements
• Support them in making decisions about the software functionality
► Business analysts have an overall understanding of the solution, and can
offer a vital service during this discussion
• They are able to assess the impact of proposed software features across the
holistic solution
• identify where problems lie and suggesting potential alternatives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -9
BA Role in Testing
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -10
Implementation - Business Readiness Assessment
► In the implementation stage of the lifecycle, there are three major aspects
for the business analyst to consider and support:
• Business readiness assessment
Business
• Transition and migration
Environment
• People’s response to change
Enterprise Business
► Business readiness assessment Architecture
Alignment
Strategy
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -11
Business Readiness Assessment:
McKinsey 7S Framework
► The McKinsey 7S framework, can be
used to:
• Analyse the impact of proposed
business changes
• Assess business readiness for change
► The framework suggests key areas to
review, and highlights the need to
evaluate the ‘fit’ between these areas
• Superordinate emphasises the
importance of assessing the other six
elements within the context of
common project goals
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -12
Business Readiness Assessment (CPPOLDAT)
Customer
Product
Process
Organisation
Location
Data
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -13
Considering Migration And Transition
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -14
Considering Migration And Transition
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -15
The Human Response To Change
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -16
Responses To Change: SARAH
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -17
The Realisation Stage
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -18
The SARAH Model Do Now
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -19
Benefits Management Process
Benefits profiles
Responsibilities
Tracking procedures
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -20
Benefits Dependency Network
Design
Rewards
rewards Website hits
scheme
scheme
Business
Enabling Changes Changes Benefits Business Objective
Source: Adapted from Ward, J. and Daniel, E. (2012) Benefits Management: Delivering Value from IS and IT Investments. Wiley, Chichester
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -21
Benefits Review: Scheduled Reviews
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -22
Scheduled Reviews
Initial business
Review case before
Feasibility study
resources
committed
Decision Gates
Business case
Review
confirmed once
Solution design
development costs
confirmed
Benefits Operation of
realization new processes
checked and systems
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -23
Unscheduled Reviews
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -24
Benefits Realisation Report
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -25
Learning Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 14 -26
Chapter 15
Course Summary
Course Objectives
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 15 -3
Course Summary
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 15 -4
Any Questions?
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 15 -5
Course Exam
► The purpose of this course is to prepare students to take the exam for the BCS
Foundation Certificate in Business Analysis
• Your instructor will inform you about the exam arrangements
► Exam
• 40 multiple-choice questions.
• One hour maximum; no study aids or
other materials to be taken into the exam
• Passing mark: 26 correct answers of
40 questions or 65 per cent.
► Additional resources and further reading
• Business Analysis (4th ed). Debra Paul,
James Cadle, Malcolm Eva, Craig Rollason 2020
• This course aligns exactly with this text;
• Each learning outcome, method, technique etc. is found in this primary text.
► Case study and sample exercises
• To reinforce topics learned, there will be a series of class exercises as well
as case study exercises for each chapter.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 15 -6