BCS Foundation Certificate in Business Analysis: Course 3507

Course 3507
BCS Foundation Certificate

in Business Analysis
by
Peter Dillon-Parkin
3507/CN/E.2/203/E.1
Copyright
© LEARNING TREE INTERNATIONAL, INC.

All rights reserved.
All trademarked product and company names are the property of their
respective trademark holders.
No part of this publication may be reproduced, stored in a retrieval system, or

transmitted in any form or by any means, electronic, mechanical, photocopying,
recording or otherwise, or translated into any language, without the prior written
permission of the publisher.
Copying software used in this course is prohibited without the express

permission of Learning Tree International, Inc. Making unauthorized copies of
such software violates federal copyright law, which includes both civil and
criminal penalties.
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent.
1
Introduction and Overview

Course Objectives
► Thoroughly prepare you to pass the

BCS Foundation Certificate in
Business Analysis
► Enable you to enter the elite global
ranks of BCS practitioners
► Gain a broad awareness and
understanding of the scope,
principles, and approaches that
underpin effective business analysis
► Confidently grasp key concepts
within the British Computer Society
(BCS) curriculum
► Align your business analysis
experience with BCS terminology and
definitions
► Reinforce your knowledge through
practice questions and drills
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. Intro -2
Course Contents
Introduction and Overview
Chapter 1 What Is Business Analysis?
Chapter 2 The Competencies of a Business Analyst
Chapter 3 The Strategic Context for Business Analysis
Chapter 4 The Business Analysis Service Framework
Chapter 5 Investigating the Business Situation
Chapter 6 Analysing and Managing Stakeholders
Chapter 7 Improving Business Services and Processes
Chapter 8 Defining the Solution
Chapter 9 Making the Business Case
Course Contents
Chapter 10 Establishing the Requirements
Chapter 11 Documenting and Modelling Requirements
Chapter 12 Validating and Managing Requirements
Chapter 13 Delivering the Requirements
Chapter 14 Delivering the Business Solution
Chapter 15 Course Summary?
Next Steps
Course Overview
► Purpose of the course: The purpose of this course is to prepare students to

take the exam for the BCS Foundation Certificate in Business Analysis
► 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.
Course Overview
1. What is Business Analysis?

2. The Competencies of a Business Analyst
Day 1 3. The Strategic Context for Business Analysis
4. The Business Analysis Service Framework
5. Investigating The Business Situation
6. Analysing and Managing Stakeholders
7. Improving Business Services and Processes
Day 2 8. Defining the Solution
9. Making the Business Case
10. Establishing the Requirements
11. Documenting and Modelling Requirements
12. Validating and Managing Requirements
Day 3 13. Delivering the Requirements
14. Delivering the Business Solution
Mock exam
Course Overview
Syllabus Target number of

Syllabus Area
weighting questions per exam
1. What is business analysis? 5% 2
2. The competencies of a business analyst 2.5% 1
Day 1 3. The strategic context for business analysis 7.5% 3
4. The business analysis service framework 2.5% 1
5. Investigating the business situation 12.5% 5
6. Analysing and managing stakeholders 10% 4
7. Improving business services and processes 12.5% 5
Day 2 8. Defining the solution 7.5% 3
9. Making the business case 5% 2
10. Establishing the requirements 10% 4
11. Documenting and modelling requirements 10% 4
12. Validating and managing requirements 5% 2
Day 3
13. Delivering the requirements 5% 2
14. Delivering the business solution 5% 2
Total 100% 40 Questions
Chapter 1
What Is Business Analysis?

Learning Objectives
► Describe the business change

lifecycle
► List the principles of business
analysis
• Root causes not symptoms
• Business improvement not IT system
change
• Options not solutions
• Feasible, contributing requirements –
not meeting all requests
• Entire business change lifecycle, not
just requirements definition
• Negotiation not avoidance
► Recognise variants of the business
analyst role
© Learning Tree International, Inc. All rights reserved. Not to be reproduced without prior written consent. 1 -2
What Is Business Analysis?
► ‘The methodical investigation, analysis, review and documentation of all or

part of a business in terms of business goals, objectives, functions and
processes, the information used and the data on which the information is
based.
► The definition of requirements for improving processes and systems,
reducing their costs, enhancing their sustainability, and the quantification
of potential business benefits.
► The collaborative creation and iteration of viable specifications and
acceptance criteria in preparation for the deployment of information and
communication systems.
► The adoption and adaptation of business analysis approaches based on
the context of the work and selecting appropriately from predictive (plan-
driven) approaches or adaptive (iterative/agile) approaches.’
—Skills Framework for the Information Age (SFIA)
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
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
► Analysts have traditionally focused on the third factor

• Today, the organisation must address all three factors
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
• No need to transfer knowledge … • Can be used on an as-needed basis

it is internal • Provide best practices based on
• Possess or can develop business numerous client engagements
domain knowledge • Offer and objective view of the
• Understand the organisational organisation
politics • Overall cost is lower
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
The Scope of Business Analysis Work
► Business analysis bridges the gap between strategy analysis and IT

systems analysis
Strategy Analysis and Definition
Increasing level of detail

Grey areas
Business Analysis
IT Systems Analysis
Business Analysis 3rd Edition Reference: Page 6
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
The Role and Responsibilities of a Business Analyst
► Business analysts use services from the Business Analysis Strategy

Framework (BASF) to ensure:
• Business change
• Technology use
◦ Are implemented in line with organisational needs
► Business analysis can vary across organisations
• They can support a range of activities
• Or specialise in a few
► Below are examples of Business Analyst specialisations:
Variants of the business analyst role

Exercise
Case Study Exercise Manual
1.1
In your Exercise Manual, please refer to Case

Study Exercise 1.1: BA Outsourcing
Advantages and disadvantages of BA outsourcing
► Please read the background information on the

Rainbow Cloud project in your Exercise manual
► Work individually to note down your thoughts
► You have 20 minutes for this activity
Learning Objectives
► Describe the business change

lifecycle
► List the principles of business
analysis
• Root causes not symptoms
• Business improvement not IT system
change
• Options not solutions
• Feasible, contributing requirements –
not meeting all requests
• Entire business change lifecycle, not
just requirements definition
• Negotiation not avoidance
► Recognise variants of the business
analyst role
1
Chapter 2
The Competencies of a
Business Analyst
Learning Objectives
► Explain the concept of the T-shaped

Professional
► Identify the three areas of business
analysis competency
The Competencies of a Business Analyst
► Competence has been described as:

• ‘The ability to do a particular activity to a prescribed standard’
—(De Ville, 1986).
► For the purposes of this course, a business analysis competence is:
• ‘An ability needed to perform the business analyst role effectively’.
Discussion Discussion
► What do you think are the most important

competencies of a good business
analyst?
The T-shaped Professional
► Individuals with a range of skills that allow them to adapt to different

situations
Multi-disciplinary breadth
of knowledge and skill
Deep
knowledge
and skill in
specific
domain
Business Analysis (4th Edition) Figure 2.1
► Individuals with a range of skills that allow them to adapt to different

situations
Multi-disciplinary breadth
of knowledge and skill
Broad, generic skills across other disciplines
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
Personal qualities Business knowledge

• Communication • Domain knowledge
• Facilitation • Commercial
awareness
Professional
Techniques
• Stakeholder
analysis &
management
• Requirements
engineering
• Investigation
• Data and
process
modelling
Competencies of a Business Analyst
Personal Business Professional

Qualities Knowledge Techniques
• Communication skills • Commercial awareness • Stakeholder analysis and
• Business case management
• Building relationships
development • Strategy analysis
• Influencing skills
• Domain knowledge • Investigation techniques
• Facilitation
• Subject matter expertise • Requirements
• Resilience
• Digital technology engineering
• Analytical skills and
• Organisation structures • Business modelling
critical thinking
• Supplier management • Data modelling
• Attention to detail
• Enterprise and related • Idea generation and
• Problem solving
architecture visualisation
Communication
• Leadership skills
Building relationships • Gap analysis
• Adaptable mindset
Influencing skills • Facilitation skills
Team • Political
working awareness
• Benefits management
Political awareness
• Team working
Analytical skills and critical thinking • Project management
• Professionalism
Problem solving • Portfolio management
Leadership
Self-belief
Professional development
Ways Of Developing the Competencies
Increase your experience by:

► Training Human
resources
• Gaining professional
Information Finance
qualifications Technology
► Industry engagement Business

• BCS and International Institute Analyst
of Business Analysis™ (IIBA®) Marketing QA
events
Project
► Workplace experience Management
• Working in different project
and organizational
environments
► Personal study
• Reading and learning from
books, magazines, newspapers
IIBA® is a registered trademark owned by International Institute of Business Analysis.
Exercise
Case Study Exercise 2.1 Manual
In your Exercise Manual, please turn to Case

Study Exercise 2.1: BA Competencies
Learning Objectives
► Explain the concept of the T-shaped

Professional
► Identify the three areas of business
analysis competency
Chapter 3
The Strategic Context for
Business Analysis
Learning Objectives
► Describe business analysis and the strategic context

• Define the factors assessed using PESTLE to analyse an external
environment
• Identify the elements of the VMOST technique used to analyse an internal
environment
► Describe the following elements of performance measurement
• Critical success factors
• Key Performance Indicators (KPIs)
► Describe the structure of a SWOT analysis
► Describe the following techniques used in strategy execution
• The POPIT model
• The purpose of the business model canvas
Strategy
Discussion
What Is Strategy?
► Strategy generates a foundation for organisational

success
• By aligning execution with the analysis of the
internal and external business environment
► Strategy supplies the organisation with:
• Business advantage
• Sustainable success
► Effective strategy improves the long-term
performance of the organisation
• With no clear, communicated strategy, the organisation
may assume there is a strategy where none exists
► Ineffective strategies degrade the long-term performance
of the organisation and cause problems at all levels
► An ineffective or non-existent strategy may cause no
immediate impact
• Over time it will degrade performance
Image: Microsoft Office Clip Art
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
• When discussing • Of decisions • Of the approach, • For the

• Strategic outputs, and delivery of
the organisation taken before and
approaches during change benefits expected strategically
with from a change aligned
and priorities execution
stakeholders initiative change
Adaptive Strategy Development
► Organisations can use an ► Related characteristics include:

‘adaptive’ or ‘lean’ strategic • Feedback acceptance Objective
development approach decision-making
• Continuous improvement
► Develop strategy iteratively,
using market feedback • Valuing knowledge
• Start-up organisations may use ► Drawbacks include:
this approach • Lack of acceptance in risk-averse
◦ Get products or services into organisations
the market quickly • Organisations where significant
• Then use product feedback to penalties exist for failure
understand market needs • When market feedback is not
► Evolve products and services to helpful, this approach may be
align with the feedback inappropriate
• Non-hierarchical organisations • In government departments, for
with high employee ownership example
and empowerment often use • Constant change may make
adaptive strategy development strategy communication difficult
Linear Strategy Development
► Linear Strategy Development ► Hierarchical or risk-averse

• Many organisations and organisations often use the linear
government departments take a approach, coupled with:
linear approach to strategy • Low employee ownership
development • Low employee empowerment
• You can adopt linear strategy
development where: ► Drawbacks of the linear approach
◦ Environmental conditions • Slower organisational reaction to
are stable changes in the internal or
external environments
◦ The organisation does not
consider market feedback • When consumer preferences
valuable change, the organisational
response may be slow, losing
► The linear approach provides a market share to competitors
consistent strategy that is easy
to communicate
“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
Hybrid Strategy Development
► Some organisations blend

approaches and apply a mix of
adaptive and linear strategy
Linear
development
• Often in different departments
or divisions of the same
organisation
► Some departments may use
‘adaptive’ strategic development Hybrid
• Those focused on developing
new products or services
► Other departments use linear
strategic development
• Those maintaining the
traditional suite of products or
services Adaptive
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
Understanding the Strategic Context:
The Core Building Blocks
► We show the core building blocks of strategic analysis below:
(Feedback)
Performance measurement
Current state Strategy execution Target state
(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
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
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
Internal Environment Analysis: VMOST Questions
► Consider the following VMOST questions for your organisation

 Does a VMOST for the organisation exist?
 Are the elements of VMOST clearly defined?
 Is the VMOST communicated to and understood by leadership,
management and employees?
 Are the Vision and Mission elements aligned?
 Do Objectives align to and amplify the Vision and Mission?
 Are the objectives SMART (Specific, Measurable, Achievable, Relevant
and Time-bound)?
 Are the Objectives balanced (see Balanced Scorecard)?
 Does the Strategy align to the Vision, Mission and Objectives?
 Do the Tactics align to the Strategy?
Example VMOST for the eCloudShare Project
• Offer our multi-award-winning cloud-based computing services to

Vision
private individuals and businesses
• Provide cloud computing services using entirely natural and/or
Mission
sustainable energy sources
• Have the eCloudshare personal offering available and fully
Objectives operational in nine months’ time
• Have a 15% profit margin three months after the market offering
• Customer satisfaction is at the center of everything we do, and we
Strategy
will focus on a total quality approach
• Implement a continuous learning process to understand what our
customers value most
Tactics • Track how our customers perceive our services through feedback
and tracking social media
• Rolling daily analysis of income and costs
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
VMOST and the Core Building Blocks for Strategic Context
Measures
performance against
Objectives
Performance measurement
Current state Strategy execution Target state
Mission Vision
Executed via Strategy Amplified via

and Tactics Objectives
Performance Measurement: Objectives
► The objectives or outcomes the organisation must achieve

• Used to guide and measure progress towards
◦ The organisation’s Vision
◦ The completion of the Mission
► They should be Specific, Measurable, Achievable, Relevant, and Time-
bound (SMART)
Objectives for the eCloudShare project

• The eCloudshare Personal offering shall be fully operational and
available in 9 months from project start
• eCloudshare shall have a 15% Profit Margin three months after the
market offering
Business Analysis (4th Edition Table 3.4
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
Critical Success Factors for the eCloudShare project
• Customer Satisfaction is key to our success

• We want customers to recommend eCloudShare to their friends
• Building success via word of mouth is cheaper than advertising
Business Analysis (4th Edition Table 3.4
The Business Scorecard (BSC)
• Improve enterprise • Develop new products

financial health Financial • Understand market
• Broaden revenue • How must we be seen by segments
base our stakeholders? • Reduce cycle time
• Improve operating • What level of income has • Cross-sell product line
been generated?
efficiency
• How profitable is the
business?
Customer Business Processes
• How should we appear to • What business processes

our customers? Vision & must we excel at?
• How effective are our
• How will we assess our Strategy internal business
customer satisfaction?
processes?
Learning & Growth

• Service excellence
• Trusted business • How can we sustain our • Hire key technical
partner ability to change and talent
• What industry improve? • Implement cross
standards should we • How do we keep ahead of training
the competition? • Align personal goals
support?
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
Key Performance Indicators for the eCloudShare project
• 99% uptime for all eCloudShare services

• <= 1 hour response time to resolve customer problems
Business Analysis (4th Edition Table 3.4)
Performance Measurement: Targets
► Targets are specific predictors of performance

► We use them to measure how well our strategy is doing. BAs often use
red, amber, green status to show the status of targets:
• Red = performance significantly below target
• Amber = performance slightly below target
• Green = performance in alignment with or above target
Targets for the eCloudShare

Targets projectTargets
• 150,000 private customers by end of 2022

• 20 of our top targets for industry actively pursuing discussions with us
by end 2022
Business Analysis (4th Edition Table 3.4)
Critical Success Factors (CSFs) and Key Performance
Indicators (KPIs)
Critical Success Factors Key Performance Indicators

(CSFs) (KPIs)
• Key areas where things must go • Measures that show if we are
right for: achieving our CSFs
• The business to flourish • Quantitative measurements of
• A manager’s goals to be performance that track the
attained. achievement of CSFs
• Qualitative critical factors that • Multiple KPIs can be used to
help the organisation to achieve measure a single CSF
its objectives • KPIs can be used to measure
• Aligned to the Vision and multiple different CSFs
Mission of the organisation
• CSFs are ideally balanced (BSC)
• Multiple CSFs can relate to any
individual objective
Performance Measurement and VMOST
Guides & informs Guides & informs

Performance Measurement
Vision Mission Objectives Strategy Tactics
Guides & informs

Indicates progress towards
Critical Success Factors
Guides & informs

Indicates progress towards
Measures progress Measures the
towards effectiveness of
Key Performance Indicators
SWOT Analysis Matrix: Combining External and Internal
Helpful to your objectives Unhelpful to your objectives
Strengths Weaknesses
• Technological skill • Absence of important skills
Internal to the
organization
• Leading brand • Branding

• Distribution channels • Poor access to distribution channels
• Customer loyalty/relationships • High customer turnover
• Production quality • Unreliable product or service
• Scale of enterprise • Management
• Management • Ineffective processes
Opportunities Threats
• Changing customer tastes • Changing customer tastes
External to the
• Liberalization of markets • Loss of traditional markets

organization
• Technological advances • Technological advances

• Changes in policy • Changes in policy
• Lower taxes • Tax increases
• Change in population age • New distribution channels
structure • New entrants in market
SWOT Analysis Do Now
► Perform a SWOT analysis for any

organisation of your choice…
Strategy Execution
► When executing an organisational strategy, you should consider:

• The results of the internal and external environment analysis
• The gap between the organisation’s current and desired target state
► You may use several techniques for strategy development and execution
including:
• Business Model Canvas (BMC)
• Target Operating Model (TOM)
• Business Capability Model (BCM)
• Value Stream Modelling
► The BMC is discussed on the next slide
Business Model Canvas
► The term ‘business model’ has several meanings

• It refers to the way an organisation is designed to deliver products and
services to customers
◦ This provides a means through which to develop and execute strategy
► Business models align the work of the organisation with desired outcomes
• They can assess the current and target state
• To Identify and plan changes
► Osterwalder and Pigneur offer an
overview generic business model
template known as the
‘A business model describes the rationale of how an organisation creates, manages

and delivers value’
—Osterwalder and Pigneur, 2010
► By considering the components of the business model canvas and

working with stakeholders, BAs can help shape the change initiatives and:
• Influence their outcomes
• Ensure that they are strategically aligned
Key Customer
activities Relationships
Value Customer
Key partners
proposition segments
Key
Channels
resources
Cost structure Revenue streams
The Elements of the BMC 1
BMC Element Questions Addressed
Customer • Who are the organisation’s important customers?

segments • For whom is value proposed?
• What value does the organisation offer?
• Which customer problems or pains does it propose to solve?
• Which customer opportunities or gains do the products or
Value
services support or satisfy?
propositions
• What are the qualities (e.g., price, availability, choice, quality,
functions supported) offered by the products or services?
• What is the relative value of the organisation’s brand or image?
• How does the organisation interact and communicate with
customers?
• Is there variance in customer experience across different
Channels channels?
• Which channels work best?
• What additional channels do customers expect?
• How do customers pay?
Business Analysis (4th Edition) Table 3.6
The Elements of the BMC 2
BMC Element Questions Addressed

• What is the nature of the relationship that the organisation has
Customer with each customer segment?
relationships • Where might it be possible to enhance the customer
experience?
• What are the organisation’s revenue streams?

Revenue
• How profitable are each of these revenue streams?
streams
• How much does each revenue stream contribute?
Key • What key resources do the organisation’s value proposition,

resources channels and customer relationships require?
• What key activities do the organisation’s value propositions,

Key activities
channels and customer relationships require?
POPIT™ as a Target Operating Model (TOM)
► The term ‘Target Operating Model’ (TOM) is used to describe how to

structure your business to support strategy execution
► BAs align artefacts from the current business architecture to the desired
Target Operating Model
• Improving understanding of what is needed to reach the ‘to-be’ state
• Providing basis for gap analysis using the ‘as-is’ state
• Clarifying how to achieve strategic objectives
► There are many different definitions of a TOM
► One view is that the TOM should cover the
full range of POPIT™ elements
• People
• Organisation
• Processes
• Information and Technology
Exercise
3.1

Study Exercise 3.1: Internal and External
Analysis and SWOT
Learning Objectives
► Describe business analysis and the strategic context

• Define the factors assessed using PESTLE to analyse an external
environment
• Identify the elements of the VMOST technique used to analyse an internal
environment
► Describe the following elements of performance measurement
• Critical success factors
• Key Performance Indicators (KPIs)
► Describe the structure of a SWOT analysis
► Describe the following techniques used in strategy execution
• The POPIT model
• The purpose of the business model canvas
Chapter 4
The Business Analysis Service
Framework
Learning Objectives
► Identify the following services in the

Business Analysis Service
Framework (BASF)
• Situation investigation and problem
analysis
• Feasibility assessment and business
case development
• Business process improvement
• Requirements definition
• Business acceptance testing
• Business change deployment
• Stakeholder engagement
The Business Analysis Service Framework
Business Analysis (4th Edition) Figure 4.1 (© Deborah Paul)
The Business Analysis Service Framework
► BCS have developed a toolkit of skills and techniques to support the

business analyst role – the Business Analysis Service Framework (BASF)
► The BASF helps the BA to align with any context
• Whether organisational or project
► Different contexts may determine the:
• Approach needed for the business analysis work
• Modelling techniques applied to analyse Business situations
• System requirements
• Documentation templates
► Each BASF service definition states:
• The Service Value Proposition (the benefit of the service)
• The Service Activities (what the BA should do)
• Service Techniques (how work may be done)
• Activities and techniques to consider when selecting an approach for the
situation and context
The Strategic Context for the BA Service
► Business analysts do not conduct BASF services in isolation

• All services relate to the organisation's strategic context, defined using:
◦ VMOST and/or TOM
◦ Artefacts such as value stream diagrams and capability models
• We can then expand the documented organisational objectives using Critical
Success Factors (CSFs) and Key Performance Indicators (KPIs)
► BASF definitions state the context within which business analysts deliver
their services
• The detailed tactics for executing the VMOST (for example) are defined by
business analysts in the course of their work
To initiate change projects that: Organisations must:

• Investigate and improve business
• Execute their strategy
situations or processes
• Achieve their objectives
• Explore business options
• Turn their TOM into reality
• Define requirements for the business
change solutions
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
Business Analysis (4th Edition) Figure 4.8 (© Deborah Paul)
Situation Investigation and Problem Analysis
► Situation investigation and problem analysis uncovers issues, defines

problems, and shapes the project
► BA are often told about ‘problems’, but they are rarely correct or complete
• BAs find the root causes of problems so problem symptoms are not
confused with the real issues
► Key BA skills:
• Being open-minded and challenging assumptions is key to service success
• Recognising that different stakeholder perspectives lead to diverse views on:
◦ Problems to be addressed
◦ Desired outcomes
◦ Priorities for the future business system
• BAs need to understand the business context for business change initiative
► Business Analysts:
• Use gap analysis to identify actions needed to fill identified gaps
• Analyse potential improvements at a deeper level using Business Process
Modelling (BPM) or Business Activity Models (BAMs)
Situation Investigation and Problem Analysis
► Service value proposition

1. Define the problem we should address, and the business needs we should
meet
2. Define the scope of the work to achieve this
3. Outline the project investment objectives and business benefits
► Service activities
1. Investigate the situation and the problem or opportunity
2. Understand the strategic context of the situation
3. Identify and articulate the business needs
4. Define the problem
5. Define the scope of the business change project
6. Define the rationale for rejecting a project proposal
► Service techniques
• Investigate the situation and record information
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

1. Define the rationale for a proposed business change
2. Generate, describe, and evaluate the options to achieve the business
requirements
3. Quantify and describe investment objectives and predicted business benefits
4. Support informed decision-making regarding business change investment
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
Business Process Improvement

1. Describe and redesign existing business processes
2. Define required process changes that will enable business improvement and
business benefit realisation
3. Identify the actions to be undertaken to deploy the improved processes
1. Model existing processes
2. Define required (new or revised) processes
3. Identify gaps between existing (as-is) and required (to-be) processes
4. Analyse gaps between existing and required processes
5. Identify and analyse business process measures
6. Identify actions to implement new processes
7. Ensure alignment between IT systems and processes
Requirements Definition

1. Elicit, analyse, describe, and manage requirements for business and IT
changes, at the level of detail relevant to the context
2. Define requirements for business improvement and benefits realisation
1. Define requirements definition approach and quality standards
2. Elicit and interpret the requirements
3. Record requirements
4. Build models and prototypes to represent the requirements
5. Collaborate and communicate with internal stakeholders in the business
and IT functions and external stakeholders to clarify requirements
6. Analyse, prioritise, and assure the quality of the defined requirements
7. Support stakeholder review of requirements
8. Conduct user analysis and profiling
9. Ensure we align requirements with project scope and strategic business
goals
10. Establish traceability of requirements from the business need to the solution
Business Acceptance Testing

1. Define acceptance tests for a business solution
2. Collaborate with stakeholders to support business acceptance of a business
solution
1. Agree the scope for testing activities
2. Define test scenarios and test cases
3. Provide stakeholder support during business acceptance testing
• Test scenario analysis and test case definition
Business Change Deployment

1. Define transition requirements for the business changes
2. Collaborate with stakeholders to support the deployment of the required
business changes and enable their adoption
1. Assess business readiness
2. Support transition planning
3. Support the adoption of the IT and business changes
4. Develop and deliver training in the new IT and business systems
5. Support the benefits and post-implementation reviews
6. Support the realisation of the business benefits
1. Model user roles, perform training needs analysis, develop training material
2. Assess business readiness assessment using POPIT or CPPOLDAT
3. Post-implementation and benefits review
POPIT: People, Organisation, Processes, Information, and Technology

CPPOLDAT: Customer, Customer, Product, Process, Organisation, Location, Data, Applications, Technology
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
Exercise
4.1

Study Exercise 4.1: BASF Services Selection
Learning Objectives
► Identify the following services in the

Business Analysis Service
Framework (BASF)
• Situation investigation and problem
analysis
• Feasibility assessment and business
case development
• Business process improvement
• Requirements definition
• Business acceptance testing
• Business change deployment
• Stakeholder engagement
Chapter 5
Investigating the Business

Situation
Learning Objectives
► In this chapter we will define:

• Interviews
• Workshops
• Observation
◦ Formal observation
◦ Shadowing
• Scenarios
• Prototyping
• User role analysis, including
personas
• Quantitative approaches
◦ Surveys or questionnaires
◦ Activity sampling
◦ Document analysis
• Diagrammatic techniques used to
record a business situation
◦ Rich pictures
◦ Mind maps
Investigating the Business Situation
► This chapter discusses techniques

used for the services described in
the BASF
• BAs investigating a business area
use a range of tools and techniques
to analyse the issues
► A kit of tools and techniques is
better than using a checklist
• A kit increases the BA's ability to be
responsive to:
◦ Business needs
◦ Differing situations
Images from Business Analysis (4th Edition) Figure 4.8 (© Debra Paul)
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
Investigation Techniques: Interviews
► An ‘interview’ implies a formal one-to-one meeting
• You can interview many stakeholders at once to save
Interviews
time and encourage openness
Workshops
Observation ► You may sense a stakeholder is not being open when

colleagues are present, perhaps because:
Scenarios
• A dominant stakeholder inhibits others’ participation
Prototyping
• The stakeholder disagrees with a statement but feels
User role analysis
unable to express open disagreement
Quantitative
approaches ► The BA must consider political or cultural issues that
Surveys or
Questionnaires
may exist
Activity Sampling
• Make sure that you have elicited the information by
scheduling a follow-up session
Document Analysis
Investigation Techniques: Workshops
► Workshops are a collaborative forum to discuss
issues, resolve conflicts, and elicit requirements
Interviews
Workshops ► Workshops need both Discovery and Visualisation

Observation techniques
Scenarios
Prototyping
User role analysis

Quantitative
approaches
Surveys or
Questionnaires
Activity Sampling
Document Analysis
Investigation Techniques: Observation
► 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
Observation ► Reassure anyone you observe that you want to

understand the task, not judge their performance
Scenarios
Prototyping ► Take care where a worksite is unionised

User role analysis • You must get approval from trade union representatives
Quantitative • The Business Analyst must observe the required
approaches protocols
Surveys or
Questionnaires
► Different approaches to observation exist depending
Activity Sampling upon the level and focus of interest
Document Analysis • The key approaches covered in this course are formal
observation and protocol analysis
Investigation Techniques: Scenarios
► In Scenario Analysis, an analyst takes a user step-by-
step through a task
Interviews
• Enabling the user to visualise each step
Workshops
Observation ► The transition between steps allows you to analyse

where the standard approach deviates
Scenarios
• A scenario description includes:
Prototyping
◦ The business event that triggers the transaction
◦ The actions users must complete to reach their goal
User role analysis
Quantitative
approaches ◦ Any exceptions to the standard path
Surveys or
Questionnaires ► Other aspects captured include:
Activity Sampling • The actor who carries out the task
Document Analysis • Preconditions and post-conditions
► Scenarios are helpful in requirements elicitation and
analysis to help us discover
• Where we need alternative paths
• New information or tacit knowledge
Investigation Techniques: Prototyping
► 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
What Happens If You Don’t Prototype?
► To the right is a ticket machine

► How do you think you select the
language you want?
Photograph: © Peter Dillon-Parkin 2014. Used with permission.
Investigation Techniques: User Role Analysis
► 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
User role analysis

Quantitative ► An individual can have multiple roles
approaches • They may need to access two or more sets of services
◦ An individual may play the customer role for certain
Surveys or
Questionnaires
Activity Sampling
transactions in a grocery store
Document Analysis
◦ They may also play the sales assistant role in the
grocery store for other transactions
Investigation Techniques: Personas
► 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
Image: Peter Dillon-Parkin used by permission
Stakeholder Personas: Benefits
► Personas represent the needs of ► Made specific with details that

many similar stakeholders make them real
• Are quick to develop • Names, families, hobbies, types
• Reduce the time taken to of TV shows, tasks, needs
identify requirements
► When you have designed your
► Can be used to evaluate personas, you can
decisions about requirements • Bring research into play to refine
• Represent the needs of many them
similar stakeholders • Check that your assumptions are
correct
► Form a common point of focus
for a development team
► Good personas are based on
research with real people
• User research
• Observation
• Interviews
Personas Are Not Standalone
► Generic personas such as ► Personas are useful when

‘customer’ can be further analysing business system users
segmented with accessibility requirements.
• Providing a more specific • You could define a persona to
description of a user and represent customers with a
improve understanding of their specific disability to fully explore
needs and understand their
accessibility requirements
Customer “user”
role
Fred Doris Emma
Customer Personas
Quantitative Analysis
► Obtaining data needed to ► Surveys or questionnaires

quantify information provided • Gather quantitative data about
during interviews, workshops, or specific elements in a process
other qualitative techniques
► Activity sampling
► Examples of quantitative data • How often in a day is an activity
include the number of carried out?
• Users for a system
• Complaints received per month ► Document analysis
• Orders processed per day • Reviewing source documents to
uncover information about an
organization, process, or system
Investigation Techniques: Surveys or Questionnaires
► 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
Investigation Techniques: Activity Sampling
► 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
Investigation Techniques: Five-Step Activity Sampling
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.
After a set period, analyse the results.
Investigation Techniques: Document Analysis
► Document Analysis reviews documents or reports to
identify data about an organisation, process, or system
Interviews
• Documents may be physical or digital
Workshops
Observation ► Analysts must design questions about:

Scenarios
• Business areas
• Problem situations
Prototyping
User role analysis ► Document analysis:

Quantitative • Identifies questions that aid the analyst’s understanding
approaches
• Supplements techniques such as workshops, interviews,
Surveys or
Questionnaires and observation
Activity Sampling
► Analysing a document’s origin and its use can also help
Document Analysis study a process, as completed documents help to
• Clarify data needed to do the work
• Offer a basis for modelling data
Recording a Business Situation
► Analysts investigating a situation must record their findings

• Producing meeting reports for each interview and workshop so you can
agree them with the participants
► Using diagrams to record your findings can be fast and useful
• We suggest two diagrammatic techniques to help analysts record and
understand the information they have obtained
► Rich pictures
► Mind Maps
Mind map: Peter Dillon-Parkin: Used with permission
Recording a Business Situation: Rich Pictures
► A Rich Picture lets you explore, recognise, and define a situation

• Expressing the situation through a rich picture creates a mental model
► A rich picture helps to:
• Identify an issue you
wish to address
• Develop an
unstructured
description of the issue
• Open discussion about
connected topics
• Arrive at a shared
understanding of a
situation
Business Analysis (4th Edition) Figure 5.6 Example of a rich picture
Recording a Business Situation: Mind Maps
► Mind maps can be used from the start of each project

• They can capture an overview that can be used throughout the project
► You can use mind maps to:
• Capture the big picture
◦ Expand with sub-topics as you gather more information
• Identify stakeholders and project partners
• Record the high-level business case
• Capture elicitation outputs
• Record sizing and metrics
• Analyze proposed changes
• Validate requirements
• Identify aspects of solution and delivery methods
• Record implementation locations and delivery dates
Recording a Business Situation: Mind Maps
Business Analysis (4th Edition) Figure 5.7 Example of a mind map Created with Xmind
Five Whys Do Now
► Each identify a problem in your life or

workplace
► Explore the problem by repeatedly asking
‘why’ (up to 5 times)
► Note down the responses
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
Applicability of Investigation Techniques
HR Highly relevant
R Relevant in
many situations
LR Limited
relevance
Exercise

Study Exercise 5.1: Investigation Techniques
Learning Objectives
► In this chapter we will define:

• Interviews
• Workshops
• Observation
◦ Formal observation
◦ Shadowing
• Scenarios
• Prototyping
• User role analysis, including
personas
• Quantitative approaches
◦ Surveys or questionnaires
◦ Activity sampling
◦ Document analysis
• Diagrammatic techniques used to
record a business situation
◦ Rich pictures
◦ Mind maps
Chapter 6
Analysing and Managing

Stakeholders
Learning Objectives
► Identify stakeholder categories using

the stakeholder wheel
► Describe the Power/Interest grid for
analysing stakeholders
• Identify the resulting stakeholder
management strategies
► Describe stakeholder responsibilities
using RACI
6
Categories of Stakeholder
► A stakeholder is anyone:
• Affected by the initiative/project
◦ Or
• Who can influence it
Competitors Regulators
Suppliers Owners
Partners Employees
Customers Stakeholders Managers
Image © 2021 Peter Dillon-Parkin used with permission
6
Stakeholder Discussion
Identification
► Identify as many types of stakeholders as

you can…
6
Analysing Stakeholders
► Having identified our

stakeholders, what weight should
we attach to their issues?
• We shouldn’t ignore any
stakeholder
Power/Influence
► But the approach to each

stakeholder differs depending on:
How much power or

influence they have on
the project
The stakeholder’s level of

interest in the project
Interest
6
Analysing Stakeholders: Power and Interest Grid
► The Power and Interest

grid is not a picture of the
actual power and interest Constant
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
► Analysts may perceive

these stakeholders as
Low Some High
having nothing to tell us
• Which is unlikely to be
Interest
the truth
6
Analysing Stakeholders: Attitude and Involvement
► Defenders of the Status

Quo are the people who
Defenders Fans
are most likely to oppose,
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
Negative Neutral Positive
Attitude
6
Describing Stakeholder Responsibilities: RACI
► In projects, it is useful to consider the tasks or deliverables

• As well as which stakeholders are involved with them
◦ And to what degree
► A RACI chart is a simple method to achieve this
6
Interacting With Your Stakeholders
► Analyse stakeholder interaction in Stakeholder Assessment Checklist:

these two areas
• Stakeholder communication Works actively for
 Champion
• How often do you plan to interact project success
with your stakeholders?
Favours the project,
◦ Monthly?  Supporter
but does not promote it
◦ Weekly?
◦ Daily? Neither for nor against
 Neutral
• Stakeholder attitude the project
◦ How positive or negative are
Not for the project, but
your stakeholders toward the  Critic
not opposed to it
proposed initiative?
Works to impede the
► You consider this to ensure you  Opponent
project
do not miss information
• A stakeholder grid makes it easy Obstructs progress,
sometimes for reasons
 Blocker
outside the project
itself
6
Managing Stakeholders: Stakeholder Plan/Assessment
► Review your power/interest Name of stakeholder:

matrix often and make changes
Current power/influence
where necessary
Current interest
► Plan how you should work with Issues and interests
each stakeholder and how to Current attitude
approach them • Champion
• Supporter
► Create a stakeholder plan/ • Neutral
assessment • Critic
• On a one-page assessment • Opponent
sheet, such as the one opposite • Blocker
• Use a spreadsheet or database Desired support
Desired role
Desired actions
Messages to convey
Actions and communications
6
Exercise

Study Exercise 6.1: Power & Interest
Stakeholder Grid
6
Learning Objectives
► Identify stakeholder categories using

the stakeholder wheel
► Describe the Power/Interest grid for
analysing stakeholders
• Identify the resulting stakeholder
management strategies
► Describe stakeholder responsibilities
using RACI
6
Chapter 7
Improving Business
Services and Processes
Learning Objectives
► Explain the business process

hierarchy
► List techniques used to model the
enterprise level processes
► Describe aspects and analysis of the:
• Event response level
• Actor-task level
• The as-is process model
► Identify generic approaches to
improving business processes
Why We Model Value Streams and Business Processes
► Modelling helps to clarify:

• Core activities needed to deliver products and services to customers
• The value proposition offered to those customers
► Modelling shows elements of the business process:
• The actors and tasks that form the process
• The current response to a triggering event
• How each task relates to a process
• How each process relates to a value stream
► Insights offered by these hierarchical connections helps
• Managers take a holistic view of processes
• Staff understand how their work relates to others
► You can use a business process hierarchy to:
• Train existing staff who are changing roles
• Induct new staff joining the organisation
The Business Process Hierarchy
► Processes are how an Enterprise level

organisation delivers products
• High-level activities that deliver a product or
and services to customers service to customers
• Can be modelled using Value Stream or
► In this chapter, we will describe Value Chain diagrams
using Value Streams to analyse
and document the delivery of:
• Organisational services Event-response level
• Business processes
• The organisation's business process response
• Modelling and improving to an initiating event
business processes at all levels • Can be modelled using UML, activity diagram
of the Business Process notation with swimlanes, or BPMN
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
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
Techniques Used at the Enterprise Level
► A traditional (functional) view of an enterprise shows the organisation of:

• Divisions
• Functions
• Departments
• Teams
► An Organisation Chart to shows how an organisation is constructed as
well as:
• Lines of management reporting
• Staff allocation
Techniques Used At The Enterprise Level
► An enterprise level process models the core processes that deliver a

product or service to the customer
• To fulfil the value chain
. and proposition of the enterprise
Enterprise Value Chain
Generic Enterprise-Level Process
High-Level Enterprise-Level Process
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
Graphic: Peter Dillon-Parkin used with permission
Example SIPOC Diagram for a Pizza Restaurant
Suppliers Inputs Process Outputs Customer
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
Techniques Used at the Enterprise Level: Value Chain
► Michael Porter’s value chain (Porter, 1985) provides a framework for

building an enterprise view of processes
• Value chains identify which processes are needed to deliver a value
proposition
► A value chain contains two areas of activity: Primary and Support
• Primary activities:
◦ Business processes and tasks that deliver the value proposition
• Support activities:
◦ Business processes and tasks that support the primary tasks
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

Source: Porter, Michael E. Competitive Advantage: Creating and Sustaining Superior Performance. The Free Press, 1985. ISBN 978-0684841465.
Value Chain Analysis (Porter)
Orders
Complaints
Inbound Outbound Marketing Queries
Operations Service
logistics logistics and sales
Obtain raw IT systems Deliver Promote Handle

materials or products products customers
products Fulfil orders issues
Take orders
Stock control Deliver
maintenance Customer
services
Products
Organizational HR Technology
Procurement
infrastructure management development
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
Main
Process 1
1. Step 1
3. Step 3
Aspects of the Event Response Level: Business Events
► Business events take place ► The events may be External or

outside the business process Internal to the organisation
• They trigger the start of a • Most events are an actor input
process • Some events are Time-based
► Events start a business process
at a pre-defined point
Aspects of the Event Response Level
► Process refers to a set of tasks

Receive Merchandise Sell
• A different actor may conduct stock stock stock
each task
• Sometimes a primary actor Decomposes to a series of tasks
conducts the end-to-end
process
Goods In
Check and Move to
► Task refers to an individual accept back-door
activity in the overall process delivery holding area
Decomposes to a series of steps
► Step refers to an action carried Unload

out in an individual task goods
Aspects of the Event Response Level
► BAs develop business process models for many reasons

• To represent or document a process
• To help train someone in the process
• To improve the process
► A description of a process as it currently operates
is an ‘as-is’ model
• A model produced to define a future process
is a ‘to-be’ model
► Different standards exist for modelling
business processes
• You can use all standards for both ‘as is’ and ‘to be’ models
► Each standard has a notation set referencing these elements:
• Model layout
• Symbols depicting elements of the model
• Sequencing of symbols
► In this course, we will consider UML activity models
Example: UML Activity Model
► An activity model shows the work carried out to complete the business
process, at an overview level
Main
Process 1
1. Step 1
3. Step 3
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
Analysis Considerations at Actor-Task Level
Do Now
► Analyse each task in the below business process model in turn

• Use the following two slides as your guide
Business Analysis (4th Edition) Figure 7.11: Image Peter Dillon-Parkin use with permission
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.
Costs The costs associated with the performance of the task.
Reference
Area for
Description
analysis
The measures used to evaluate the performance of the task. These

are concerned with two areas:
Performance
1. Accuracy: In what areas is accuracy assessed and what is the
measures
specified level of accuracy?
2. Timeliness: was the task performed in the required timescale?
The individual actions taken when conducting the task.

The actor have to apply business rules when carrying out a step.
The business rules determine how the task, or business process, is
to be carried out after the step is completed.
Steps
For example, a business rule may specify
• What the task output should be or may
• What a different task should begin
Even that the entire process should terminate
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
UML activity diagram representing

the steps and rules in a task can
be modelled as follows.
The Business Process Hierarchy
► Business process models show the hierarchy of business processes and

tasks at each of the:
• Enterprise-level
• Event-response level
• Actor-task level Value stream
► Business process modelling uses
an iterative analysis approach:
1. Develop a top-down Enterprise
Level view
2. Expand to the
Event-response Level
3. The Event-response Level is then
expanded to individual tasks
► At Event-response Level, we should
consider changes to higher-level models
• Based on the new information emerging from the lower-level analysis
Analysing As-Is Process Models: Enterprise Level Issues
► Organisations must respond to changes in their business environment

• PESTLE allows you to analyse this
► Changes may also emerge from the organisation
• The board may appoint a new senior executive with a different perspective
◦ Possibly resulting in a new strategy or tactical changes
► Wherever change comes from, organisations must decide on a response
• Often involving business process improvements or adaptations
► Most processes change over time
• Often incremental changes to adapt to new circumstances
► Unfortunately, these changes can occur in an ad hoc and uncontrolled way
• Resulting in unwieldy business processes
Analysing As-Is Process Models: Actor Level Issues
► Actors understand their part in the business

process
• They often don’t understand the roles of
others
► As a result, they may only notice the change
that affects them
• Not the impact of change on others
► We must share changes with everyone
impacted by them, or risk failure
► A clear hierarchy of process models helps to
create stability. Such models:
• Include ‘as is’ business process models and
tasks
• Highlight problems
• Provide a basis for improvement
• Identify and clarify unknown or
misunderstood process flows
Analysis of An As-Is Process Model: Identifying Problems
► Problems with business processes tend to fall into the following

categories:
• Lack of customer focus
◦ The process fails to provide what is needed because it does not consider
 Customer requirements
 Expectations
◦ Processes may meet organisational rather than customer needs
• Lack of organisational focus
◦ The process meets customer needs but costs too much
◦ Scarce technical support leading manual intervention in processes
◦ Tasks are redundant or duplicated for historical reasons
◦ Problems with accuracy, timeliness or costs of the products or services
► When identifying ‘as is’ process problems, you must consider
• Customer needs
• Your organisation
Analysis of As-is Process Model
► Your organisation model in the ► Some improvements are

process hierarchy should clarify straightforward
the • Training and development to
• Value proposition address a skills gap
• Customer value expectations
► Other improvements may need
► These two elements determine you to change the entire process
• The performance metrics for the
► Generic improvement strategies
process
include:
• Where functional gaps may
exist in the process Simplification
◦ Analyse these gaps to
Redesign
identify improvements
Bottleneck removal
► Two aspects to analyse when Change task sequence
looking at performance gaps are:
Redefine boundary
• ‘Hand-offs’ between the tasks
• Work conducted in the tasks Automate processing
The Purpose of Customer Journey Maps
► Customer journey maps consider the external perspective

• How does a customer see the process?
► Process improvement may focus on the organisational needs of efficiency
and productivity
• At the expense of the customer experience
• When improving processes, we should focus on the external customer view
The Purpose of Customer Journey Maps
Customer Journey Map Elements
The customer role, including customer types - consumer, purchaser (on

Role
another consumer’s behalf) or reseller (intermediary).
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
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
Exercise

Study Exercise 7.1: Business Process Model
or Swimlane Diagram
Learning Objectives
► Explain the business process

hierarchy
► List techniques used to model the
enterprise level processes
► Describe aspects and analysis of the:
• Event response level
• Actor-task level
• The as-is process model
► Identify generic approaches to
improving business processes
Chapter 8
Defining the Solution

Learning Objectives
► Describe the gap analysis process

► Explain the use of POPIT™ in gap
analysis
► Describe the process for developing
option, and the type of options
available
► Describe the purpose of design
thinking
• Using divergent and convergent
thinking
The Gap Analysis Process
► Gap analysis is a systematic process

• BAs compare the existing (as-is) situation to the desired (to-be) system to
identify where:
◦ Differences exist
◦ We should make changes
► We can apply gap analysis at different levels, depending upon the situation
• Are we examining a restricted or extensive change?
► The scale of the change controls the scope of gap analysis, and the
artefacts we use to depict the as-is and to-be situations
Assemble Assemble Consider

Compare the Identify the
representations representations options for
as-is and to-be gaps to be
of the as-is of the to-be addressing the
situations addressed
situation situation gaps
POPIT™ And Gap Analysis
► The POPIT model supports several business analysis activities

• Taking a holistic view of business situations
• Structuring a gap analysis activity
• Evaluating the impact of business changes
Organisation Information:
• Job roles, management • Capture, record, reporting
structures, culture, and distribution of data and
values, standards, information
policies Technology
• Software products, hardware,
infrastructure, networking,
communication, digital and
other forms of technology
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
Formulating Options
► The output of gap analysis is business requirements

• At the ‘what is needed’ level, but with metrics
► We don’t need to specify how we will meet the business requirements
• We will do this in later chapters, when we have identified the
◦ Gaps
◦ Business requirements
• We can explore options to meet the business needs
► Any options for final inclusion in the business case must have:
• Financial feasibility
• Business feasibility
• Technical feasibility
Identify possible Evaluate Produce

Shortlist options
options shortlist business case
Formulating Options
► Two types of options:

► What
• Business options that explore what the proposed solution would include in
terms of the functionality provided to the business.
► How
• Technical options that consider how the solution is to be implemented in
terms of the technical infrastructure for the solution.
► Options must be considered holistically
• Proposals that change one or two POPIT areas but ignore the rest will fail
• High quality software applications will not work well if
◦ They are unaligned with organisational goals
◦ People lack the skills to use them
• You cannot change team structures without considering
◦ The impact on individuals
◦ Ensuring they are clear about their roles and responsibilities
Types of Options
Exhaustive
option
(includes all
features)
Cost
Extended
option (basic
plus some
additions)
Basic option
Time
Design Thinking
► Design thinking helps us to generate options and define solutions

• Concepts and techniques from product design that include:
◦ Prototyping
◦ Learning from trying out ideas
◦ Divergent and convergent thinking
◦ Keeping a focus on the customer
► Design thinking identifies options standard approaches may not identify
► Design thinking is iterative, working through a series of stages
• Revisiting each stage as necessary
• Developing and delivering an outcome to
◦ Address the problem
◦ Meet customer needs
Design Thinking
Stage Techniques
Empathise Investigation techniques,
personas, empathy mapping and
customer journey mapping.
Define Storytelling and problem framing;

perspective analysis.
Ideate Brainstorming and brainwriting;

divergent and convergent
thinking; mind mapping.
Prototype Prototyping and scenario

analysis.
Evaluate Scenario and event analysis;
reflective learning.
Create Experimentation, feedback and

review.
Divergent and Convergent Thinking
► Divergent and convergent thinking is a crucial element of design thinking

Divergent thinking is a thought
Convergent thinking is the type of
process or method used to
thinking that focuses on coming
generate creative ideas by
up with the single, well-
exploring many possible
established answer to a problem
solutions
► We encourage stakeholders to think broadly (divergent thinking) about

aspects such as:
• Where problems exist
• Issues of concern
• The range of perspectives and personas in play
• Ideas for possible solutions
► We then move to a convergent thinking session to evaluate ideas that:
• Appear manageable and workable
• Offer a potential way forward
• Build a consensus amongst stakeholders
► Critical success factor: Identifying when we have generated enough ideas
Divergent and Convergent Thinking
► Address the problem or opportunity to achieve the desired outcome

• BAs keep customer needs and goals in mind
► Divergent And Convergent thinking is a customer-centric approach
• Stakeholders work together, engaging in both divergent and convergent
thinking
• Where possible, involve customers in the design thinking process to support
the co-creation of both products and value
◦ The emphasis is on iterating to test, learn, and improve
Design thinking Double Diamond model (© Assist Knowledge Development Ltd.)
Design Thinking
Design thinking context:

• Standards
• Resources
Problem or Business
opportunity outcome
Design thinking principles:

• Collaborative
• Customer-centric
Design thinking Double Diamond model (© Assist Knowledge Development Ltd.) – Graphic Peter Dillon-Parkin
Exercise
Case Study Exercise 8 Manual

Study Exercise 8.1: POPIT and Gap Analysis
Learning Objectives
► Describe the gap analysis process

► Explain the use of POPIT™ in gap
analysis
► Describe the process for developing
option, and the type of options
available
► Describe the purpose of design
thinking
• Using divergent and convergent
thinking
Chapter 9
Making the Business Case

Learning Objectives
► Describe the business case

development lifecycle
► Identify the areas of feasibility
assessment
► Define the structure and contents of a
business case
► List features relevant to producing a
business case in an Agile context
► Identify elements of a CARDI Log
► Explain the purpose of investment
appraisal techniques including
• Payback Period
• Discounted Cash Flow
• Net Present Value
• Internal Rate of Return
The Business Case in the Project Lifecycle
► Business cases are traditionally ► This chapter first examines a

designed to service linear conventional approach to
software development life cycles business case development
(SDLCs) • We articulate the general
• Usually a methodology, such as principles of business cases
Waterfall or V-model ◦ Then consider business
► Today many projects do not use cases in Agile environments
a linear lifecycle
• Especially those projects
involving software development
► Businesses using an Agile
development approach may find
that creating a business case for
the project is not practical as:
• Their destination is not clear
• Change is likely as the project
progresses
► A business case is a crucial

document in a business change Business
project Enterprise
Environment
Business
• Business analysts present Architecture Strategy
findings and propose actions
for senior management to Alignment
consider
► This chapter considers the
purpose, structure, and content Realisation Definition
of a business case, showing Business
how to: case
• Assemble the information
• Present the finished product
Implementation Design
Initial business
case before
Feasibility study
resources
committed
Requirements Business case

analysis and confirmed after
specification detailed
requirements
Decision Gates
Business case
confirmed once
Solution design
development costs
confirmed
Solution Business case

development & revisited before
implementation deployment
Benefits Operation of
realization new processes
checked and systems
Identify the Areas of Feasibility Assessment
► Assessing feasibility falls under three broad headings:

Feasibility
Business Technical Financial
Strategic fit Available Within budget
Market appropriate Reliable Funds available

(or can be borrowed)
Timely Maintainable
Acceptable ROI
Architectural alignment Performance
Acceptable cash flow
Organisational fit Secure
Timely payback
Cultural fit Scalable
Capability fit Compatible
Regulatory alignment Proven
PESTLE For Feasibility Assessment
► Political: Is the proposed solution politically acceptable?

• Consider the political situation whether it is local, national, or International
• You should always consider the internal politics of the organisation
► Economic: Can the organisation afford the solution?
• Does it represent the best use of scarce funds?
► Socio-cultural: Does the solution fit with the organisation’s culture?
• Is it acceptable within the societal norms in which the organisation operates?
► Technological: Can we achieve the solution technically?
• Consider this together with the economic question
• Determine if an available technology is affordable at this point
► Legal: Does the solution meet regulatory or legal constraints?
► Environmental: Does the solution raise environmental issues?
• A relevant issue given concerns about the environment and climate change
Structure of a Business Case
Introduction
Management or executive summary
Description of the current situation
Options considered
Option description
Analysis of costs and benefits
Impact assessment
Risk assessment
Recommendations
Appendices with supporting

information
Analysis of Costs and Benefits
Intangible and Intangible and

Costs and benefits
immediate long-term
Tangible and Tangible and

immediate long-term
Immediate Long-term
Realization
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
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
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
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
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
Job Aid: Handling Risk
Outside your Plan mitigation

control strategy
High-impact Check cost/

risks probability
Identify risks
Within your Plan prevention
control strategy
Low-impact Monitor/
risks reassess
Business Case Within an Agile Context
► We have described the essential elements of a business case

• Relevant to all project environments
► Some organisations need to respond with increasing speed to changing
business environments
• Which has led to the adoption of Agile development approaches
◦ Avoiding large, monolithic projects and proceeding iteratively and
incrementally
► Even when large projects are unavoidable, we often divide the programme
into small sub-projects or workstreams
• Each delivering incremental business benefit
• Compare this with a linear approach where we only receive benefits when we
deliver the entire project
► In the agile context, we modify our approach to producing a business case
• Although we still consider the options, costs, benefits, impacts and risks
Business Case Within an Agile Context
► This diagram shows a series of iterations during which we refine and

analyse the requirements
• Then design, develop, and test the solution
◦ It may take two or more iterations to deliver a release of the solution
Business Analysis (4th Edition)
Investment Appraisal
► Business cases include an

investment appraisal
Payback
• Using quantified costs and benefits to
identify the financial implications of
each option
• We contrast the tangible costs and Discounted Cash Flow
benefits to see if and when the
project will pay for itself
► There are several different investment Internal Rate of Return
appraisal techniques. In this section,
we describe:
• Payback Period
• Discounted Cash Flow (DCF)/Net
Present Value (NPV)
• Internal Rate of Return (IRR)
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?
Year 0 Year 1 Year 2 Year 3

Benefits 0 90 130 140
Costs 80 20 25 30
Net benefit (80) 70 105 110
Cumulative (80) (10) 95 205

net benefit
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:
► The payback period is 1 year and 1.1 months
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
Payback and Risk – Time Value of Money
► Time value of money:

• A term describing the fact that money received or paid in the future is worth
less than money received or paid today
.
£ £
Present Future
£ £
► You can mitigate this drawback by applying the payback method to

discounted cash flows
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
Google Apps 50 50 50 50 50 250
► But – we paid for our Office suite in this year’s money!

• Some of Google Apps is being paid for in future years’ money
► So, we could have either
• Invested the money we’re not spending now or
• Avoided some of the interest we would incur on money we borrowed
► We also might feel that there is an amount of risk attached to those future
payments – interest rates may go up or down, inflation might vary
• We might want to compensate for risk
► The rate that accounts for interest and risk is called the discount rate
What Is A Discount Rate?
► An interest rate calculates what Compounding and Discounting

today’s money will be worth in the
future ► Invest $1,000 at 10% interest
• We need a discount rate to • Year 1 = $1,000 x 1.10 = $1,100
understand what future money will • Year 2 = $1,100 x 1.10 = $1,210
be worth now • Year 3 = $1,210 x 1.10 = $1,331
► We use the discount rate for ► We can create a formula for this:
calculating the current value of
future money
► The discount rate reflects cash flow
risk in two areas ► Compounding tells us what
money will be worth in the future
• The Weighted Average Cost of
Capital (WACC): What money ► Discounting tells us what a future
costs to the business, expressed amount is worth today
as a percentage ► To do this, we can rearrange the
• Risk premium: the risk that the formula:
cash flow might not materialize
after all
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
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.
The Use of Net Present Value
► For our purposes, the principal uses of NPV are

• To decide whether to rent or buy (as in the Google Apps/Office suite
example)
• We put initiatives in which inflows and outflows of cash occur at different
times into a common “currency” of today’s money
• You can then compare initiatives fairly
► NPV is simple to implement using a spreadsheet
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!
3 90,000 0.751 67,590

4 90,000 0.683 61,470
Net present value of project: –24,790
Internal Rate of Return (IRR)
► IRR calculates a percentage to show your return on investment

• We use IRR to compare projects with one another to identify
◦ Better investment opportunities
◦ What the same money would earn if left in the bank
• A project with an IRR of three per cent compared with a bank interest rate of
five per cent would not be worth doing
► We calculate IRR by identifying the discount rate that would reduce NPV to
zero
• Using whatever period the organisation mandates for the calculation
• In simple terms: at what point would financial costs and benefits balance
each other?
► IRR does not consider the size of the project
• So, projects with smaller IRR may produce more actual money
► Most accounting textbooks agree that DCF/NPV is the best method of
assessing the value of an investment
• Although many managers like the simplicity of the single-number IRR
DCF = discounted cash flow NPV = Net Present Value
Calculating Internal Rate of Return
► You can calculate IRR by using a spreadsheet

• Try different discount rates until you produce an NPV of zero
► Microsoft Excel has an automated function, the Solver add-in, that allows
you to do this
• In the example, the result is around 6.3 per cent
• Compared with a project or investment opportunity offering five per cent, this
project would be more attractive
Year Net cash flow Discount factor Present value
0 –310,000 1.000 –310,000

Using a 6.26%
1 90,000 0.941 84,697 discount rate sets
the NPV of the
2 90,000 0.886 79,706 project to zero
3 90,000 0.833 75,009
4 90,000 0.784 70,589
Net present value of project: 0
The CARDI Log
► Besides costs and benefits, business cases also

document:
• Constraints
• Assumptions
• Risks Constraints
• Issues
Assumptions
• Dependencies
► We set up a CARDI log to manage these elements Risk
that affect the project
• We create the CARDI log with the initial business
Dependencies
case
Issues
◦ With entries usually being at an overview level
• They will become more detailed as the project
proceeds
◦ And we understand more about its complexities
Exercise

Study Exercise 9.1: Developing the Business
Case
Learning Objectives
► Describe the business case

development lifecycle
► Identify the areas of feasibility
assessment
► Define the structure and contents of a
business case
► List features relevant to producing a
business case in an Agile context
► Identify elements of a CARDI Log
► Explain the purpose of investment
appraisal techniques including
• Payback Period
• Discounted Cash Flow
• Net Present Value
• Internal Rate of Return
Chapter 10
Establishing the
Requirements
Learning Objectives
► Explain the requirements engineering

framework, including the:
• Business representatives
• Project team
• Requirement types
► Describe the requirements hierarchy
► Explain requirements elicitation
techniques & tacit knowledge
► Identify the following elements of
requirements analysis
• Requirements filters
• INVEST
• Prioritising requirements using
MoSCoW
• Business rules
The Importance of Requirements
► A requirement is: ► Performance issues include

• A feature or characteristic • Security Accessibility
requested by a stakeholder that • Usability Scalability
may form part of a solution
• Requirements are at the heart of ► Stakeholders express some
change in business and IT requirements as outline ideas
• Other requirements may be
► We elicit requirements and record detailed and specific, providing a
them for future consideration firm basis for solution testing
• We analyse them to decide if they
should form part of the solution ► Sometimes we establish the detail
of a requirement at an early stage
► Some constrain the solution • Regulatory requirements
• We analyse them to identify what • Sometimes requirements evolve
compliance is needed or possible as the solution emerges
► Requirements ► Some assume ‘requirements’ are
• Determine what a solution only relevant in linear SDLCs
provides and how well the solution • This assumption is incorrect
should perform
SDLC = Software Development Lifecycle
The Requirements Engineering Framework
Requirements Requirements Requirements

elicitation analysis validation
Requirements documentation
Requirements management
► The Requirements Engineering ► The framework defines five core

Framework requirements quality activities and the interactions that
by clarifying: take place to deliver well defined
• The activities used for requirements
requirements definition
• The order of those activities
► In Requirements Engineering the
business analyst:
• Elicits
• Analyses
• Defines and documents
• Validates
• Manages
► Requirements
• To deliver the basis for business
and software development
Actors in Requirements Engineering
► An actor is an individual or group who fulfils a specific role

• Stakeholder groups include:
Business Representatives Project Team
Project sponsor Project manager
Product owner Business analyst
Subject Matter Expert Developer
Business staff Software tester
Types of Requirements
► There are four recognised types of requirement in two categories:
Business Solution
Other Requirement Types
Category Areas to explore
Related to organisational style guides and standards, defined within

the general requirements.
Style guides determine the required ‘look and feel’ for the products
or documents created within the organisation. The key areas to be
defined are:
User interface
• Display layout, styles, fonts, font sizes;
requirements • Colour palettes;
• Logos including size and resolution;
• Windows and tabs;
• Navigation styles.
• Accessibility standards & guidelines
These requirements concern areas such as:

• Data migration; specific areas include sources of data, data
Transition migration format, data conversion, data standards;
requirements • Stakeholder communication, documentation and training;
• Business continuity planning, customer service and
implementation or release strategies
Hierarchy Of Requirements
► Requirements do not stand ► Some requirements may simply

alone reflect ideas or opinions
• A hierarchy links them • Following further exploration, we
may find that they are not
► The organisation’s values, needed
strategy, objectives, and
performance measures should
drive the requirements
Compliance with Data

Protection Legislation
Functional Requirements Non-Functional Requirements

• Record Customer Details • Archive Customer Details
• Maintain Customer Details • Delete Customer Details
• Confirm Customer Details • Backup Customer Details
Requirements Elicitation
► Requirements elicitation gathers requirements from stakeholders, in

particular:
• Those who work in the organisation
• Intended users of the software

► Many requirements come from ► We may have to change some of

explicit knowledge that these elements to:
stakeholders can articulate • Deliver a new solution
• Workshops are a forum for: • Reflect new business needs and
◦ Beginning requirements practice
elicitation work
► Analysing the as-is situation
◦ Exploring requirements
helps analysts
areas in further detail
• Ask more specific questions
► Analysing project • Get information to identify and
documentation for enhancing or elaborate on requirements
replacing systems reveals
information about: ► Helping in the development of
• Reports requirements documentation or a
solution backlog
• Screens
• These techniques work well
• Actor responsibilities
when eliciting requirements
• Process flow
relating to explicit stakeholders’
• Reporting requirements knowledge
• Business rules
Requirements Elicitation Techniques
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
► Interviews allow structured discussion to identify features business

managers need
• Requirements we elicit may be at an overview level, reflecting general
business needs
◦ We can divide elicited requirements into functional and non-functional
• We document them to
◦ Align with organisational or project standards
◦ Prioritise them
• Reporting and management information requirements often originate from
meetings with business managers
► Document analysis helps to explore specific stakeholder knowledge of the
• Business area
• Processes
• Systems
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
Tacit Knowledge
► The difficulties with tacit knowledge are important

• In a world of new business practices, processes and technology, tacit
knowledge issues are common
► The business analyst helps business staff to visualise what they need the
new system to do
• Then to articulate it
► Some aspects of tacit knowledge cause problems and misunderstandings
and include:
Skills
Taken for granted information
Conceptual requirements
Tacit assumptions
Intuitive understanding
Tacit Knowledge: Front Story/Back Story
► Front story/back story

• Framing a description of a current working
practice more positively than can be justified Norms of
behaviour and
► Where stakeholders perceive analysts as communication
representing the business management
• Stakeholders give the analyst a
favourable version of the business Formal
situation and Organisational
informal stories
► Overcome this by building good networks
relationships with stakeholders
• Then stakeholders will reveal the back
story – the reality of the working practice Organisational
culture
► Use techniques such as:
• Interviews
• Observation
Situations where tacit knowledge
• Shadowing is embedded in an organisation
Tacit Knowledge: Individual and Corporate
Level Tacit Explicit

Individual
• Skills
• Task definitions
• Values
• Job descriptions
• Taken-for-granted
• Targets
knowledge
• Volumes and frequencies
• Intuitiveness
Corporate
• Procedures
• Norms • Style guides
• Culture • Processes
• Networks • Knowledge sharing
• Organisational history repositories
• Back story • Manuals
• Company reports
Elicitation Techniques and Tacit Knowledge
► Business analysts must make tacit ► Many techniques exist to help

knowledge explicit stakeholders put tacit knowledge
• To understand the requirements into words
• BAs can make this knowledge
► Requirement categories provide a explicit through
valuable basis for asking questions
• Documenting it
that stakeholders may:
• Disseminating it to the other
• Not consider relevant
members of the project team
• Have taken for granted
Requirements Analysis
► Requirements analysis reviews and analyses the elicited requirements to

• Remove duplication or error • Evaluate feasibility
• Negotiate conflicts and contradictions • Allocate priorities

Categorising Requirements
► Categorise requirements by the four requirement types:

• General
• Technical
• Functional
• Non-functional
► Group functional requirements by:
• Business area or activity
• Use case, if you are documenting the solution in this way
► Organising requirements helps analysts to see related
requirements
• And check for completeness of the requirements set
► Organising also helps business stakeholders to
prioritise and validate a set of requirements
• Making it easier to select the requirements we will deliver
in an iteration
Modelling and Prioritising Requirements
► Models, including use case diagrams and class

models, can represent requirements
• They enable us to check consistency and
completeness
► Prioritising requirements
• BAs can use several approaches to prioritise
requirements
• The approach used can vary between
◦ Organisations
◦ Different projects within an organisation
• You can use a straightforward approach of high,
medium, or low priority
► The organisation must decide the implications of
each level
• Sometimes BAs use the categories mandatory,
desirable and nice to have
Elements Of Requirements Analysis: Requirement Filters
Checking for
Unravelling multiple overlapping or Confirming relevance
Evaluating feasibility
requirements duplicate of the requirement
requirements
Removing conflicts Checking for solutions Technical feasibility
Confirming quality of
expression Clear Concise Business feasibility
Consistent Relevant Unambiguous Financial feasibility
Correct Testable Traceable
Requirements Filters Do Now
► Consider the 2 requirements below…

• Are they solid requirements based on the
requirements filters we just reviewed?
► Explain why they are good requirements
or not
1. We need to create and delete contractors.
2. We need to cross-check orders against
deliveries.
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
Should provide a brief description of a required feature that is a basis for

Negotiable
elaboration, clarification and prioritisation through collaborative negotiation
Valuable to
users or Should be outcome or goal focused and offer potential value to customers
customers
Should be able to be estimated either in terms of its relative size or the
Estimatable
amount of development effort it would require
Should be of a suitable size for iteration planning and development within a
Small
timeboxed iteration.
Should include specific measures that may be tested to evaluate whether or
Testable
not it has been achieved
MoSCoW
Must have: Mandatory in the current increment under development. It is

M absolutely essential that these requirements are included as, without them, a
solution is not acceptable.
Should have: Mandatory but may be deferred to the second increment. It is

S essential that these requirements are included in the solution, but their inclusion
may be deferred in the short term.
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.
Business Rules 1
► There are two categories of business rule to consider:

• Constraints
• Operational guidance
► Constraints govern what is or is not permitted
• For example, in a car rental organisation :
◦ A person may only hire one rental car at a time
◦ A person aged under 21 may not hire a rental car
► Operational guidance states how workers must perform processes
• Conduct a transaction
• Make a decision
• Calculate a figure
► For example
• A set of questions used to determine how a person’s identity must be
confirmed over the telephone
• Conditions that determine how a customer complaint should be handled
• A series of steps to define how sales commissions should be calculated
Business Rules 2
Constraints Techniques
Action Narrative statements that include specific

governance criteria such as those related to age or status
Data constraints Data models and definitions, CRUD matrices
Operational
Techniques
guidance
Decision Activity diagrams, business process models,

conditions decision tables, tables, matrices
Arithmetical formulae, Structured English,

Calculations
pseudocode
CRUD: Create, Read, Update or Delete

Exercise

Study Exercise 10.1: Developing
Requirements (1)
Learning Objectives
► Explain the requirements engineering

framework, including the:
• Business representatives
• Project team
• Requirement types
► Describe the requirements hierarchy
► Explain requirements elicitation
techniques & tacit knowledge
► Identify the following elements of
requirements analysis
• Requirements filters
• INVEST
• Prioritising requirements using
MoSCoW
• Business rules
Chapter 11
Documenting and
Modelling Requirements
Learning Objectives
► Identify written and diagrammatic

documentation styles
► List the elements of a requirements
catalogue
► Recognise the format of user stories
► Describe the elements of the use case
diagram used to model functional
requirements
► Outline the elements of a class model
used to model data
► Define the product backlog in
modelling and documentation in an
Agile environment
► Plan the structure of the business
requirements document
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

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?
Importance of Documentation
► Good documentation provides:

• Effective communication within the
project team
• A basis for ensuring the consistency
of the requirements
• Stakeholders with a firm basis for
validating the requirements
• Input to testing
► The requirements:
• Define what the solution is to do
• Ensure acceptance criteria to ensure
we have delivered the required
features
• The requirements document is also
used post-implementation for
maintenance and benefits realisation
Documentation Styles
► You can document requirements in several ways

• Statements
• Diagrams
• Use Cases
• User Stories
► The skill lies in selecting the correct techniques for the situation
► Things to consider when picking a documentation style:
• The development approach for the project
◦ Is it Linear or Agile?
◦ Is a Business Requirements Document or a backlog of user stories
needed?
• The type of requirement
◦ General requirement summarised in a sentence?
◦ Data requirement defined using a data model?
◦ Non-functional requirement defining access permissions at the actor or
function level?
Building the Requirements List
► As we elicit requirements, we need to document them

• Build the requirements list first, then the organised requirements catalogue
second
• We describe the requirements catalogue development later
Requirement Source Comments
1. We need a CRM system P Oxley
2. We need to print off a list of customer P Oxley
prospects
3. We need to cross-reference new P Oxley
sales against our prospect list
4. We need to create and delete J Kirby
customers
5. We need more accurate predictions F Thorne
about customer sales
► Can you see any issues that might worry you about these requirements?
CRM = customer relationship management
Elements of a Requirements Catalogue
Requirement identifier Stakeholders

Associated non-functional
Requirement name
requirements
Requirement description Acceptance criteria
Source Related requirements
Owner Related documents
Author Comments
Type of requirement Rationale
Priority Resolution
Business area Version history
Requirements Catalogue: Requirements Detail Level
► Creating a full definition for each requirement can be time-consuming

• It could waste time and effort if the details provided are not needed
► The level of detail of the definition depends upon these factors:
Requirement Solution delivery

Analysis stage Solution type
Priority level approach
Is this an initial A business process Deferring a A bespoke development is
view of the change is likely to requirement likely to need more detailed
requirements or a require a detailed means you need to requirement definitions than
more detailed description of the defer the detailed those needed to evaluate
requirements new tasks and IT definition work with an off-the-shelf software
specification? support it product
User Stories
► Agile software development employs user stories

• They are useful in discussing requirements for any approach. User stories:
◦ Define what actors need from a system
◦ Are written from the actor's perspective
◦ Identify what an individual or group need
◦ Are quick to develop and do not include elements, such as the owner,
source, and justification
► User stories provide an informal description of a requirement
• Which stakeholders and analysts can then explore through further discussion
► Most suitable for functional requirements
• Non-functional requirements need a precise definition to express the
requirement’s essence
◦ You can deliver non-functional requirements using a technical user
story
► User stories provide a ‘Contract for a conversation’
• A conversation between the user role and a software developer
User Stories: Story Card
► User stories are written on story cards

I would like to…
(what capability
is needed by the
user role?)
As a… (who is
the user role or
actor?)
So that… (how is
the user story
beneficial to the
user role?)
MoSCoW is often used Story Points are a

to show the User Story comparative method of
priority estimating effort
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>
User Stories: Technique
► We record user stories in a product

backlog, often in priority order
• The priority level determines
◦ The relative importance of a
user story to the product
◦ When we should select the
user story for inclusion in an
iteration
► Developers estimate user 'story Back of card: acceptance criteria
points' by comparing the
• User stories already delivered
• Current user story
► This is relative estimation
• We compare the story points of
completed user stories
• We then use this to estimate the
story points of new user stories
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
Documentation Styles: Diagrammatic
► ‘One picture is worth a thousand words’ (Henrik Ibsen)

• It is difficult to write unambiguous text providing a clear picture of the solution
► Models can show a clear picture of the entire solution
• Confirming that requirements are in scope
► Some models are easier for stakeholders to understand than others
• Stakeholders can interpret business process models and activity diagrams
with little modelling knowledge
• Use case diagrams and data models may need some education to
understand
► For stakeholders to:
• Understand them
• Contribute to their development
► Build these diagrams collaboratively with stakeholders, using standard
business terms
Context Diagram
► This initial diagram is known as a Context Diagram and it has many uses,
providing:
A statement of An initial view of

where the solution the scope of a
fits in an solution by
organisation and defining the actors
the wider business and their
context interactions with it
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
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
Use Case Diagrams (UCD)
• Use case diagrams represent the:

• Actors interacting with a system
• Features those actors need to access
• They are an effective way of
improving stakeholder understanding
of functional requirements
• They represent the business
stakeholder view of a solution
• You can develop them during
meetings and workshop discussions
• Develop UCDs using an ‘outside in’
approach
• Show the initial solution as a ‘black
box’, then identify the:
◦ Actors
◦ Features needed in the solution
The Use Case Diagram
► The use case diagram represents a high-level view of

• Actors interacting with the use case
• Associations and interactions between the actors and the use case
• The boundaries of the use case
Boundary
Association Boundary
Use case
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
Use Case Description
► We document the actor's interaction ► Example: In an order process:

with the system in a use case 1. Product availability information is
description, written in outline or in provided subject to a stock level
detail enquiry
► The use case description 2. If the product is available, the
supplements the use case diagram order is accepted
and includes: 3. If the product is not available,
• Actor name another information exchange
• Name and ID of the use case occurs by which the actor can
• The use case goal decide whether to:
• Sequential list of actions taking a. Accept an alternative or
place during the use case b. Cancel the original product
• Exceptions that lead to alternative request
scenarios
► Each use case can have multiple
paths resulting from: Path A Path B
• Exchanges of information and
requests
• The application of conditions
Example: Use Case Description
Withdraw Funds Use Case

1. The customer inserts the card
2. The system asks the customer to select a language
3. The customer selects a language
4. The system asks the customer to enter the PIN
5. The customer enters their PIN
6. The system validates the PIN
7. The system asks the customer to select a transaction
8. The customer chooses Withdraw Funds
9. The system asks the customer to pick an amount
10.The customer picks an amount
11.The machine dispenses the card
12.The machine dispenses the money
13.The machine prints the receipt
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
Class Models
► Class modelling is a Unified

Modelling Language (UML) data
modelling technique
• A class is a set of attributes that
describe something of interest to a
system
► A class model is a graphic
representation of
• All the classes in a business system
• Their associations with each other
► An Entity Relationship Diagram (ERD)
is an alternative data modelling
technique
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
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?
Multiplicity
► Which one to use?

• Pick one for the customer and one for the account
0..1 0..1
1 owns 1
Customer Account
0..* belongs to 0..*
1..* 1..*
Reading Multiplicity
1 0..*
owns
Customer Account
belongs to
owns 0..*
Customer Account
Each customer owns 0 or more accounts
exactly one customer belongs to Each account

1
Customer Account
belongs to
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
The Product Backlog in an Agile Environment
► A helpful approach is to develop:

• An initial set of • A context diagram that represents the • A use case
general and solution’s place in the business diagram with
technical context business staff
requirements • This should offer a
• Possibly using clear view of the
elements of the overall scope of
requirements the solution and its
catalogue template required features
• A backlog of user • Outline definitions of non-functional • A data model to
stories requirements that require further ensure the data
• Developed by exploration requirements are
consulting the actors • Where they apply to the entire project, represented in an
on the use case (such as usability requirements) a single effective way
diagram to develop definition – possibly using the
the user stories they requirements catalogue template – may
would like the be developed for each non-functional
solution to fulfil requirement
• This can then be applied across all
development activity
Content of the Requirements Document
Business
Requirements
document
Introduction Business
Function Requirements Glossary of
and process Data model
models catalogue terms
background models
► Introduction and background ► Function models

• Describe the business situation
► Data model
and drivers for the project
• Clarify the objectives, scope of ► Requirements catalogue
work, and the business context • Document the individual
for the requirements requirements here
► Business process models ► Glossary of terms
Exercise

Study Exercise 11.1: Developing
Requirements (2)
Learning Objectives
► Identify written and diagrammatic

documentation styles
► List the elements of a requirements
catalogue
► Recognise the format of user stories
► Describe the elements of the use case
diagram used to model functional
requirements
► Outline the elements of a class model
used to model data
► Define the product backlog in
modelling and documentation in an
Agile environment
► Plan the structure of the business
Chapter 12
Validating and Managing

Requirements
Learning Objectives
► Describe the following types of

requirements validation
• Formal requirements validation
• Activities in the Agile requirements
validation process
► Describe the following aspects of
requirements management
• Traceability
• Change control
► Requirements validation reviews requirements to confirm their quality

level

Requirements Validation
► In Requirements Validation, we ► Modelling standards include:

select a group of stakeholders to • Business Process Model and
review the requirements Notation (BPMN)
• If possible, the group should be • Unified Modelling Language (UML)
external to the project
► Techniques for managing
► They agree the solution delivers: requirements include:
• Defined capabilities (functional • Producing a formal Requirements
requirements) Document
• Stated characteristics and • Developing a product backlog
constraints (non-functional containing the requirements,
requirements) features and other work items
► Different documentation, modelling ► Both approaches include validation
techniques and standards can be involving business representatives
used. BAs state requirements as: such as:
• Statements • Business staff
• User stories • Project sponsor
• Use cases • Product owner
Formal Requirements Validation
► In a linear project approach, you review the requirements to determine

their accuracy
• If they are accurate, they are ‘signed off’ or ‘baselined’
• They then progress into solution design and development
► Any changes requested after the baselining are subject to
• Change control
• Configuration management
► Business and project representatives should confirm that the document
accurately states the requirements
• After validation confirms that requirements documentation is complete and
correct
► We form a review group with responsibility for checking and confirming
the requirements
• We issue the documentation for review once we have identified the reviewers
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
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
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
Formal Requirements Validation: Review Outcomes
► Three possible outcomes from a review:

1. The requirements need a significant amount of rework, and we should
review them again afterwards
2. The requirements need some amendment, but once changes are complete,
the review chairperson (usually the business sponsor) can sign them off
3. We agree on the requirements as a satisfactory statement of the business
needs
► Once we agree on the requirements, we sign them off and baseline them
• Any later changes are subject to formal change and version control
◦ We describe this in the Managing Requirements section
► The review outcome should be an agreement that the requirements:
• Are complete, consistent and conform to business standards
• Provide a firm basis for the development and delivery of the solution
Agile Requirements Validation
► In Agile Validation requirements need to be clear enough for inclusion in

the product backlog
• Validation reviews accept outline requirements in a user story format
• Outline requirements evolve as details emerge in the development process
► We refine backlog requirements until they gain ‘ready’ status
• Then we can allocate them to an iteration
• The INVEST Criteria is applied
► In Agile, business stakeholders perform the checks rather than analysts
► You should also involve technical stakeholders such as
• Solution architects
• Developers
• Testers
• Project support office representatives
► In Agile, our approach to requirements definition is different

• We reflect this in the requirements validation method
► There are two stages to Agile requirements validation:
1. When initiating the project, we agree to an outline solution and establish the
backlog
2. When maintaining the backlog, we refine user stories until they are ‘ready’ to
go into development
► We may conduct formal review processes at the project start to make sure:
• We understand the general and key solution requirements
• A solution outline is available
► Informal reviews of backlog items help to ensure the product backlog is
well-formed
► Once we have established the backlog, we refine items in it over time, to

confirm they are fit for further development
• After confirmation, they are in a ‘ready’ state
► The refinement process involves various activities:
• Ensuring individual requirements align with models developed to represent a
solution
• Producing high or low fidelity prototypes of requirements
• Helping stakeholders identify missing or incorrect features.
• Discussing use cases or user story scenarios
• Mainly where they are complex or compound
• Building swimlane models or activity diagrams to represent a task’s workflow
• Defining requirements/user story acceptance criteria
► We should apply validation to the ► Complex requirements need

extent needed by the analysis to define them clearly
requirement type enough for development
• We should break compound • We often need to understand
requirements into single their business rules
requirements • Analytical and modelling
• Non-functional requirements techniques can help with
referring to security and access, complex business rules
accessibility, and usability are
often compounded ► Data models and data definitions
help with data-related rules
► Complex requirements can be • Activity diagrams, decision
challenging to express, and we tables, and state machine
can consult SMEs to uncover: diagrams help show how
• Potential scenarios business rules relate to
• Combinations of rules and processes and decision points
actions
► Check that every iteration’s user stories are well-defined enough to begin
development work
► Requirements Management
• This stage is concerned with managing changes to the defined requirements
and ensuring the desired level of traceability is achieved

Requirements Management
► Failing to understand, document, and manage requirements leads to

downstream project difficulties
• A well-defined set of requirements is a firm basis for business change
• Problems can still occur if the requirements are not traceable
► The traceability of the requirements is a critical quality characteristic
• Traceability focuses on a requirement’s origin, ownership, and eventual
outcome
► There are two forms of traceability: horizontal and vertical
• Horizontal traceability traces the requirement from inception to delivery
• There are two forms of horizontal traceability
◦ Backwards from and forwards to traceability
► Vertical traceability traces a requirement up or down the requirements
hierarchy
• It describes how business-level general or technical requirements align
downwards to solution requirements
• And upwards to business values, policies, strategy, and objectives
Requirements Management: Traceability
Horizontal
Vertical
Requirements Management: Change Control
► Changes occur in projects due to:

• External factors – legal or regulatory changes or competitive forces
• Internal changes, such as strategies, policies, or people
► Requirements management includes change control
• Defining and implementing a change management process
► We use change management where a change arises that causes:
• A configuration item to be updated
• The creation of a new version
Document the Analyse the Consult the Deciding on the
proposed change proposed change stakeholders change
• Each change is • Each change request • Each change request Each change request,
documented as a is analysed to goes to & impact assessment
‘change request’, consider the impact, representative is reviewed by change
stating who raised time, and cost stakeholders sop control board.
the change, a associated with they can consider the Approved changes
description of the making the change. impact of the change, see the configuration
change and a including the effort item released so the
justification for and the change can be
requesting it. corresponding cost to applied, and a new
make the change version created
Exercise

Study Exercise 12.1: Class Model
Learning Objectives

requirements validation
• Formal requirements validation
• Activities in the Agile requirements
validation process
► Describe the following aspects of
requirements management
• Traceability
• Change control
Chapter 13
Delivering the
Requirements
Learning Objectives

delivery lifecycle
• The waterfall lifecycle
• The “V” model
• The incremental lifecycle
• The stages of the iterative lifecycle
(Agile)
► Explain advantages and
disadvantages of the lifecycles
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
► There are several software development lifecycles (SDLCs) in use

► Lifecycles provide a basis for conducting a development projects
• Although they focus on software development,
the lifecycles can be adapted for use on
more holistic business change projects
► The major lifecycles in use are:
• The waterfall lifecycle;
• The ‘V’ model;
• The incremental lifecycle;
• The iterative lifecycle
13-3: Business Analysis (4th Edition) Figure 13.2
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)
Delivery Lifecycles: Waterfall Approach
► Development proceeds
Feasibility
through a series of stages study
► Each stage is reviewed and

signed off before the next starts Analysis
► The backwards-facing arrows in the

lifecycle show we need to check back Design
at each stage to ensure
• There is no scope ‘creep’
Development
• The current stage builds on its predecessor
• Modifications to deliverables from the previous
stage may be made if necessary QA/Testing/
Verification
► In theory, each stage is reviewed and signed off
before the next starts
Implementation
• Thus, we should only begin analysis once a feasibility
study has been approved
Example waterfall
methodology
QA = quality assurance
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
Define Acceptance criteria Ensure user

Requirements acceptance
Design System test criteria Test solution

solution
Unit
test
Develop criteria Test
modules modules
Develop
solution
Delivery Lifecycles (Extended ‘V’ Model)
► The waterfall is bent back on itself after “Develop Solution”

• This adds another dimension making an explicit connection between earlier
developmental project stages and the later testing stages
The test criteria is made

explicit at each stage – for
example, showing how
acceptance criteria should be
defined as part of the
requirements documentation
then used during user
acceptance testing.
Delivery Lifecycles (Incremental)
► Some requirements will be more

Increment 1
important, or more urgent, than others Development
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
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)
Delivery Lifecycles: Iterative Lifecycle (Agile)
Business Analysis (4th Edition) Figure 13.8 (© Assist Knowledge Development Ltd)
Advantages and Disadvantages of the Lifecycles
► The waterfall, ‘V’ model, and incremental lifecycles give

you a sequence of stages plus a high level of control
► The disadvantage of these lifecycles when you lack
time to define all requirements at the outset, resulting
in:
• A poor BRD, where only high-priority requirements are
well defined
• Business actors unlikely to know what they want at the
project’s start
◦ Particularly true where an organisation moves into a
new business area or offering different services
• Some changes may be impossible to implement when
required, causing stakeholder dissatisfaction
• The pace of business change may cause any set of
requirements to become out of date quickly
◦ Maintaining up-to-date requirements can result in
significant work!
Business Analysis (4th Edition) Figures 13.3, 13.5, 13.6, (top to bottom)
► Iterative software development addresses many of the disadvantages

associated with the linear lifecycles
► The iterative approach expects and accepts changes during the
development process
• As a result, there may be limited focus on:
◦ Maintaining documentation
◦ Ensuring requirements
traceability
• Although based upon
incremental delivery, the
iterative lifecycle differs
from it in that requirements
evolve rather than being
defined in detail prior to the
design and delivery of
each increment
► Iterative approaches have some disadvantages:

• Where requirements concern business rules or legal constraints, we cannot
allow requirements to evolve
◦ They must be defined accurately, often at an early stage
• Not recognising this can impact product quality
◦ Risking business compliance and user acceptance
► There is no overview of the final intended solution when defining
requirements
• This can result in a fragmented view leading to an inconsistent product that
may not address important non-functional issues
► Customers may dislike too-frequent product releases
• Requiring them to change how they work more often than necessary
Exercise
Exercise 13.1 Manual

Study Exercise 13.1: Determining the
Delivery Lifecycle
Learning Objectives

delivery lifecycle
• The waterfall lifecycle
• The “V” model
• The incremental lifecycle
• The stages of the iterative lifecycle
(Agile)
► Explain advantages and
disadvantages of the lifecycles
Chapter 14
Delivering the Business

Solution
Learning Objectives
► Explain the role of the business

analyst in the business change
lifecycle
► Describe the role of the business
analyst during the design,
development and test stages
► Describe the following approaches
used in the implementation stage
• The SARAH model
• The purpose of the business
readiness assessment
► Describe how the benefits plan is
used in the realisation stage
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
POPIT Perspective: People
► New skills required of team members should be identified

• Then conduct a gap analysis to identify the necessary skill development
• Determine the means of achieving the skills
◦ This may involve the design and development of training events
► Business analysts are often involved in work
to extend and improve the skills held by
business staff
• Delivering training and support to
business users to enable them to
carry out their new work practices
People
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
POPIT Perspective: Processes
► We have already discussed how to design the “to-be” process

• This core business analysis service develops a key element of a holistic
business change solution.
► Implementing a ‘to be’ process involves much detail work
• It is often the case that this detail is overlooked or postponed
• For example, creating task definitions and
the documents to be used in the new process
► These elements must be considered at
an early stage
• To ensure that the solution is well
defined and ready for deployment
Processes
POPIT Perspective: Information and Technology
► We have already described the software development lifecycles used to

create a software product to
• Fulfil the defined requirements
• Support the business processes
► We have also discussed how BAs define requirements for the solution
• You should consider what role the BA
will take in your organization during:
◦ Design
◦ Development
◦ Testing
► The BA may document the outcome
of user acceptance testing Information
• And, in some cases, provide and
advice on how to address Technology
testing issues
BA Role in Design
► The requirements documentation produced by the business analysts

provides a basis for the design of the software product
► During design, business analysts:
• Facilitate communication between business and technical staff to ensure
requirements are understood
• Develop models and enhance documentation to ensure that there is clarity
and consistency
• Clarify aspects relating to some requirements, using techniques such as
scenario and impact analysis
• Work with solution architects to ensure that the information and technology
requirements will be fulfilled successfully
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
BA Role in Testing
► Acceptance testing is an accepted business analysis service

• Once software has been developed and tested by the IT team,
BAs support business staff performing acceptance testing
• The BAs define acceptance criteria used to confirm a requirement has been
met using User stories; Use case descriptions; The Requirements Catalogue
► A variety of techniques define test cases and test scenarios, including:
• Use case descriptions: Developed for each use case within the use case
diagram to define the system response to the occurrence of an event
• A main success scenario is documented augmented by descriptions of
alternative scenarios that may occur.
► Decision tables set out the:
• Range of conditions given a particular situation
• Actions to be taken given a specific set of conditions.
► State charts represent the:
• Different states a particular entity or class may be in during its lifetime
• Valid transitions between these states
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
• The business analyst is well-placed to

conduct a business readiness
assessment
• This involves analysing if the Realization Definition
business area where changes are Business

to be made is sufficiently prepared Case
to accept and operate the

new ways of working Implementation Design
• Several frameworks suggest
aspects to consider when
assessing business readiness
for change The Business Change Lifecycle
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
McKinsey 7S (Waterman et al., 1980)
Business Readiness Assessment (CPPOLDAT)
► The CPPOLDAT framework suggests several key areas to be evaluated

• It provides key questions to be asked when considering business readiness
Customer
Product
Process
Organisation
Location
Data
Considering Migration And Transition
► The transition requirements introduced in Chapter 10 set out key areas to

be tackled for a successful implementation
• These may be part of the business analyst role or may be supported by
business analysts
► These areas are concerned with:
• Analysing the data to be migrated to the new system, ensuring the data is in
a fit state to be migrated, defining the format of the data in the new system,
and setting up the migration processes
• Supporting the business staff to learn about the new system, possibly by
delivering formal training sessions, and providing information and guidance to
help embed the new ways of working
• Creating documentation – user guides, procedure descriptions, checklists,
and other aids for people using the new business processes and systems
• Evaluating implementation strategies and selecting the most appropriate
given the context (next slide)
Considering Migration And Transition
Direct changeover (big bang) Parallel running

We remove old systems and processes You run old systems and processes alongside
replacing them with the new system and the new systems and processes for a period.
processes. This is risky because you reduce This reduces the risks of direct changeover, as
chances of adopting contingency measures. you can revert to the previous way of working
Direct changeover is the only possible Parallel running is expensive because you must
transition strategy where: maintain two different approaches to carrying
• You must comply with legislation out work
• A system has become obsolete.
Pilot running Phased implementation

You deploy new systems and processes in a You deploy new systems and processes in
specific part of the business. You can then test phases. Only part of the solution is
how well the solution works in an operational implemented at one time with other phases
environment and learn where adjustments are delayed until the implemented changes are
needed. working well.
You can make changes before the new solution You can learn where adjustments should be
is more widely deployed. made, but only to part of the solution.
The Human Response To Change
► Emotional impact is experienced by staff during project implementation

• This is a major concern
• Failure to consider it may cause resistance and undermine the changes
► It may even cause the entire change programme to fail
• The Shock, Anger, Rejection, Acceptance, Hope (SARAH) curve sets out the
emotional curve that may affect anyone experiencing the introduction of
business change
► The SARAH model shows the stages many people go through when they
are faced with significant change in their lives
• From their:
◦ Initial dismay on learning about the change
◦ To re-establishment of optimism once they begin to see the possibilities
the change brings
Responses To Change: SARAH
Image: Peter Dillon-Parkin 2021 used with permission
The Realisation Stage
► Benefits will only be realised if:

Business
• They are well defined
Environment
• Their delivery is planned Enterprise Business
Architecture Strategy
• They are managed carefully
throughout the lifecycle Alignment
► Much thought goes into defining,

developing, and delivering the
solution successfully
Realisation Definition
• Less effort is put into realising
the expected business benefits Business
case
► A comprehensive benefits plan
that should be developed to:
Implementation Design
• Provide a firm basis for tracking
the business benefits
• Managing their realisation
The SARAH Model Do Now
► Spend five minutes jotting down ideas on

how you can help users in each of the five
emotional states in the SARAH model to
better understand and accept the changes
brought about by a project
Benefits Management Process
Benefits management: A process that is concerned with the delivery of the

predicted business benefits defined in the business case.
This process includes managing projects such that they are able to deliver the
predicted benefits and, after the project has been implemented, checking
progress on the achievement of these benefits and taking any actions
required to enable their delivery.
The Benefits Plan

Context/vision
Benefits profiles
Benefits dependency network
Responsibilities
Tracking procedures
Benefits Dependency Network
Research Design new New press

Newspaper
newspaper press release release
coverage
demographics system system
Marketing Design Launch

Brand
campaign marketing marketing
recognition
Research themes campaign campaign
Raise
customer
organizational
perception of
profile
organization Specify
Develop and
website New website Testimonials
test website
changes
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
Benefits Review: Scheduled Reviews
► Benefits review management processes are needed to ensure that the

benefits are reviewed in two circumstances:
• Scheduled reviews
• Unscheduled reviews
► Scheduled reviews
• At each ‘decision gate’ in the project the expected benefits should be
examined as part of the review
◦ At each stage, carefully consider whether the expected benefits are still
available and are still sufficient to compensate for an increase in the
expected costs of the project
◦ In the light of such a review, it may be necessary to rework the financial
case to define the expected investment return or even re-scope the
project to improve the prospects of securing the maximum business
benefit
Scheduled Reviews
Initial business
Review case before
Feasibility study
resources
committed
Requirements Review Business case

analysis and confirmed after
specification detailed
requirements
Decision Gates
Business case
Review
confirmed once
Solution design
development costs
confirmed
Solution Review Business case

development & revisited before
implementation deployment
Benefits Operation of
realization new processes
checked and systems
Unscheduled Reviews
► Unscheduled Reviews should be triggered whenever an event occurs that

could affect the expected benefits
• Major requests for change are an obvious example of such a situation as
they could cause the project to
◦ Cost more
◦ Take longer
◦ Deliver something different
• All of these might affect the benefits
► Other events could include
• A change in the key stakeholders (especially the project sponsor),
• Developments in the external business environment
• A change to the organisation’s business strategy.
Benefits Realisation Report
► A Benefits Realisation Report should be produced to assess whether the

benefits have been realised
• To ensure than where benefits have not been achieved, we identify any
additional actions that could be taken to retrieve them
◦ For example, if users are not making full use of a new system, additional
training may be required
• To reassure the decision-makers, and the wider organisation, that the time,
effort and cost of the project has been justified
• To provide input to future business cases and future projects, to help make
them more successful
• To enable the organisation, over time, to increase the capability for
choosing which projects to undertake
Learning Objectives
► Explain the role of the business

analyst in the business change
lifecycle
► Describe the role of the business
analyst during the design,
development and test stages
► Describe the following approaches
used in the implementation stage
• The SARAH model
• The purpose of the business
readiness assessment
► Describe how the benefits plan is
used in the realisation stage
Chapter 15
Course Summary
Course Objectives
► Thoroughly prepare you to pass the

BCS Foundation Certificate in
Business Analysis
► Enable you to enter the elite global
ranks of BCS practitioners
► Gain a broad awareness and
understanding of the scope,
principles, and approaches that
underpin effective business analysis
► Confidently grasp key concepts
within the British Computer Society
(BCS) curriculum
► Align your business analysis
experience with BCS terminology and
definitions
► Reinforce your knowledge through
practice questions and drills
Course Summary
Syllabus Target number of

Syllabus Area
weighting questions per exam
1. What is business analysis? 5% 2
2. The competencies of a business analyst 2.5% 1
Day 1 3. The strategic context for business analysis 7.5% 3
4. The business analysis service framework 2.5% 1
5. Investigating the business situation 12.5% 5
6. Analysing and managing stakeholders 10% 4
7. Improving business services and processes 12.5% 5
Day 2 8. Defining the solution 7.5% 3
9. Making the business case 5% 2
10. Establishing the requirements 10% 4
11. Documenting and modelling requirements 10% 4
12. Validating and managing requirements 5% 2
Day 3
13. Delivering the requirements 5% 2
14. Delivering the business solution 5% 2
Total 100% 40 Questions
Course Summary
1. What is Business Analysis?

2. The Competencies of a Business Analyst
Day 1 3. The Strategic Context for Business Analysis
4. The Business Analysis Service Framework
5. Investigating The Business Situation
6. Analysing and Managing Stakeholders
7. Improving Business Services and Processes
Day 2 8. Defining the Solution
9. Making the Business Case
10. Establishing the Requirements
11. Documenting and Modelling Requirements
12. Validating and Managing Requirements
Day 3 13. Delivering the Requirements
14. Delivering the Business Solution
Mock exam
Any Questions?
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.

BCS Foundation Certificate in Business Analysis: Course 3507

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

BCS Foundation Certificate in Business Analysis: Course 3507

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BCS Foundation Certificate in Business Analysis: Course 3507

Uploaded by

Copyright:

Available Formats

Course 3507

BCS Foundation Certificate

© LEARNING TREE INTERNATIONAL, INC.

No part of this publication may be reproduced, stored in a retrieval system, or

Copying software used in this course is prohibited without the express

Introduction and Overview

► Thoroughly prepare you to pass the

Introduction and Overview

Chapter 1 What Is Business Analysis?

Chapter 2 The Competencies of a Business Analyst

Chapter 3 The Strategic Context for Business Analysis

Chapter 4 The Business Analysis Service Framework

Chapter 5 Investigating the Business Situation

Chapter 6 Analysing and Managing Stakeholders

Chapter 7 Improving Business Services and Processes

Chapter 8 Defining the Solution

Chapter 9 Making the Business Case

Chapter 10 Establishing the Requirements

Chapter 11 Documenting and Modelling Requirements

Chapter 12 Validating and Managing Requirements

Chapter 13 Delivering the Requirements

Chapter 14 Delivering the Business Solution

Chapter 15 Course Summary?

► Purpose of the course: The purpose of this course is to prepare students to

1. What is Business Analysis?

Syllabus Target number of

What Is Business Analysis?

► Describe the business change

► ‘The methodical investigation, analysis, review and documentation of all or

► Analysts have traditionally focused on the third factor

• No need to transfer knowledge … • Can be used on an as-needed basis

► Business analysis bridges the gap between strategy analysis and IT

Strategy Analysis and Definition

Increasing level of detail

Business Analysis 3rd Edition Reference: Page 6

► Business analysts use services from the Business Analysis Strategy

Variants of the business analyst role

In your Exercise Manual, please refer to Case

Advantages and disadvantages of BA outsourcing

► Please read the background information on the

► Work individually to note down your thoughts

► You have 20 minutes for this activity

► Describe the business change

► Explain the concept of the T-shaped

► Competence has been described as:

► What do you think are the most important

► Individuals with a range of skills that allow them to adapt to different

Business Analysis (4th Edition) Figure 2.1

► Individuals with a range of skills that allow them to adapt to different

Broad, generic skills across other disciplines

Personal qualities Business knowledge

Business Analysis (4th Edition) Figure 2.2

Personal Business Professional

Increase your experience by:

► Industry engagement Business

IIBA® is a registered trademark owned by International Institute of Business Analysis.

In your Exercise Manual, please turn to Case