This is an English summary of the complete book 'Business Analysis', the fourth edition (2020), written by Debra Paul and James Cadle, published by BCS.
Business Analysis Essentials: A Comprehensive Guide for Professionals and Students
BCS Foundation notes
All for this textbook (3)
Written for
Business Analysis
All documents for this subject (6)
8
reviews
By: arnaldoruiz • 2 months ago
By: ariannevanderwal • 11 months ago
By: delebode • 1 year ago
By: armithakarimi • 1 year ago
By: wardgroen • 1 year ago
By: niekboersma9 • 9 months ago
By: leonhuis75 • 5 months ago
Show more reviews
Seller
Follow
RobinKras
Reviews received
Content preview
Summary
Business Analysis (fourth edition)
Source:
Title: Business Analysis
Fourth edition (2020)
Author: Debra Paul and James Cadle
Publisher: BCS Learning and Development Ltd
ISBN: 978-1-78017-5102
Summarized by: Robin Kras, February 2023
,Contents
1. What is business analysis .......................................................................................................... 4
1.1. The origins of business analysis ........................................................................................ 4
1.2. Business Analysis principles ............................................................................................. 5
1.3. The Business Analysis Maturity Model ............................................................................ 8
1.4. The business analysis service ............................................................................................ 9
1.5. Variants of the business analyst role ............................................................................... 10
2. The competencies of a business analyst .................................................................................. 12
3. The strategic context for business analysis ............................................................................. 13
4. The business analysis service framework ............................................................................... 14
4.1. Situation investigation and problem analysis overview .................................................. 14
4.2. Feasibility assessment and business case development ................................................... 15
4.3. Business process improvement ........................................................................................ 16
4.4. Requirements definition .................................................................................................. 17
4.5. Business acceptance testing ............................................................................................. 18
4.6. Business change deployment ........................................................................................... 20
4.7. Stakeholder engagement .................................................................................................. 21
4.8. The strategic context for the Business Analysis service .................................................. 22
5. Investigating the business situation......................................................................................... 24
5.1. Background research ....................................................................................................... 24
5.2. Investigation techniques .................................................................................................. 24
5.3. Recording business situations and issues ........................................................................ 35
6. Analysing and managing stakeholders .................................................................................... 37
6.1. The power/interest grid .................................................................................................... 37
6.2. Managing stakeholders .................................................................................................... 39
6.3. Understanding stakeholder perspectives ......................................................................... 40
7. Improving business services and processes ............................................................................ 42
7.1. Business process models: event-response level ............................................................... 43
7.2. Business process models: actor-task level ....................................................................... 45
7.3. Analysing ‘as is’ business processes ............................................................................... 45
7.4. Improving business processes ......................................................................................... 46
8. Defining the solution............................................................................................................... 48
9. Making the business case ........................................................................................................ 49
9.1. When to create a business case ........................................................................................ 49
2
, 9.2. Structure of a business case ............................................................................................. 49
9.3. Business cases within an agile context ............................................................................ 52
9.4. Defining the solution ....................................................................................................... 52
10. Establishing the requirements ............................................................................................. 54
10.1. The problems with requirements.................................................................................. 54
10.2. The Requirements Engineering framework ................................................................. 54
10.3. Types of requirement ................................................................................................... 56
10.4. Requirements elicitation .............................................................................................. 57
10.5. Requirements analysis ................................................................................................. 59
11. Documenting and modelling requirements ......................................................................... 61
11.1. Documentation styles ................................................................................................... 61
11.2. Documentation ............................................................................................................. 62
12. Validating and managing requirements ............................................................................... 70
12.1. Requirements validation .............................................................................................. 70
12.2. Managing requirements ............................................................................................... 71
13. Delivering the requirements ................................................................................................ 73
13.1. Delivery lifecycles ....................................................................................................... 73
14. Delivering the business solution ......................................................................................... 76
14.1. Business Analyst role in the business change lifecycle ............................................... 76
3
, 1. What is business analysis
1.1. The origins of business analysis
Business analysis aims to ensure that any business change aligns with the needs of the
organization. Developments in information technology (IT) have enabled organizations
to create information systems that have improved business operations and management
decision-making. However, for many years there has been a growing dissatisfaction in
businesses with the support provided by technology and the professional change and
technology disciplines. This has been accompanied by a recognition on the part of
senior management that investments in technology and change often fail to deliver the
required business outcomes. While technology has the potential to deliver business
improvements, it is often the case that the business requirements are not met in a timely
fashion, resulting in limited competitive advantage to the organization. The Financial
Times reported in 2013 that this situation applies to all sectors, with IT projects
continuing to overrun their budgets by significant amounts and poor communication
between business and technical experts remaining problematic. This is where the
Business Analyst comes in to play.
It is often the case that the business needs are not well understood, the requirements
are unclear or ill-defined, and there is misalignment between them. All too often the
focus, almost from the outset, is on a preferred technical solution rather than on
understanding the problem to be addressed. The hasty selection of ‘solutions’ is often
coupled with a lack of alignment of the proposed changes and can result in a failure to
deliver business benefits and, accordingly, a waste of investment funds.
Many organizations use external consultant to provide expert advice throughout the
business change lifecycle. The reasons are clear: they can be employed to deal with a
specific issue on an ‘as-needed basis’ and they bring a broader business perspective
and can provide a dispassionate, objective view of the company. On the other hand, the
use of external consultants is often criticized, across all sectors, because of the lack of
accountability and the absence of any transfer of skills from the external consultant to
internal staff. Cost is also a key issue. Consultancy firms often charge daily fee rates
that are considerably higher than the charge levied for an internal business analyst and
while some firms provide consultant with a broad range of expertise steeped in best
practice, this is not always guaranteed.
The experiences gained from using external consultants have also played a part in the
development of the internal business analysis role. Many business analysts have argued
that they can provide the services provided by external consultants and can, in effect,
operate as internal consultants. Reasons for using internal business analysts as
consultants, apart from lower costs, include speed (internal consultants do not have to
spend time learning about the organization) and the retention of knowledge within the
organization. These factors have been recognized as particularly important for projects
where the objectives concern the achievement of business benefits through the use of IT
as a prime enabler of business change. As a result, while external consultants are used
for many business purposes, the majority of business analysts are employed by their
organizations. These analysts may lack an external viewpoint across organizations but
4
,they are knowledgeable about the particular business domain and crucially have to live
with the impact of the actions they recommend.
1.2. Business Analysis principles
• Root causes not symptoms:
o To distinguish between the symptoms of problems and the root causes.
o To investigate and address the root causes of business problems.
o To consider the holistic view.
• Business improvement not IT system change:
o To recognize that IT systems should enable business opportunity or
problem resolution.
o To analyze opportunities for business improvement.
o To enable business innovation and customer experience enhancement.
• Options not solutions:
o To challenge pre-determined solutions.
o To identify and evaluate options for meeting business needs.
• Feasible, contributing requirements, not meeting all requests:
o To be aware of financial and timescale constraints.
o To identify requirements that are not feasible and do not contribute to
business objectives.
o To evaluate stated requirements against business needs and constraints.
• The entire business change lifecycle not just requirements definition:
o To analyze business situations.
o To support the effective development, testing, deployment and post-
implementation review of solutions.
o To support the management and realization of business benefits.
• Negotiation not avoidance:
o To recognize conflicting stakeholder views and requirements.
o To negotiate conflicts between stakeholders.
These principles clarify why business analysis is so relevant in today’s business world
and set out the responsibilities that business analysts should recognize and accept. The
principles are underpinned by two key approaches:
The holistic approach
There is widespread agreement that business analysis requires the application of a
holistic approach. Although the business analyst performs a key role in supporting
management’s exploitation of technology to obtain business benefit, this has to be done
within the context of the entire business system. This means all aspects of the
operational business system need to be analyzed if the entire range of opportunities for
business improvement are to be determined. The POPIT model shows the different
views that must be considered when analyzing business improvements and identifying
required business changes:
5
, Organisation
Information
and
Technology
People Processes
This model represents the different aspects, and the correspondences between them,
that business analysts need to consider when analyzing a business system. Example
questions that should be asked about each area are shown below.
• The processes: Are they efficient, well defined and communicated? Do they
meet the performance measures expected by customers? Is there good
technology support or are there several ‘workarounds’ in existence? Do the
processes require information or documents to be passed around the
organization unnecessarily? Is there the potential for delays or the introduction of
errors?
• The people: Do they have the required skills and support to carry out the work?
How motivated are they? Do they understand the business objectives that they
need to support?
• The organization: Are roles and responsibilities well defined? Is there a
supportive management style? Is there collaborative cross-functional working?
Does the culture enable productive work?
• The information: Do the staff have the information to conduct their work
effectively? How is this information accessed? Are managers able to make
decisions based on accurate and timely information?
• The technology: Do the software products support the business as required?
Are they usable and accessible? Do they enable the organization to meet staff
and customer needs?
All of these areas should be analyzed to uncover where problems lie and what
improvements might be necessary if the business is to become more effective and
efficient.
6
, Agile software development
Agile is a software development approach that emerged in the late 1990s. The
application of Agile methods evolved as a reaction to the perceived shortcomings of the
linear development lifecycles, in particular, their emphasis on completing each stage
before moving on to the subsequent stage.
The Agile philosophy encompasses key principles and concepts including collaborative
working, iterative software development and incremental software delivery. It does not
support or require detailed definitions of requirements but instead uses evolutionary
development techniques, such as prototyping, to explore outline product requirements in
collaboration with end users.
The Agile Manifesto states:
We have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the
left more.
There has been much debate about the business analyst role within an Agile
development environment. Some authors have suggested that there isn’t a need for
business analysts on Agile projects given that Agile development teams encompass co-
located roles so enable ongoing conversations between developers and business staff.
However, this is to overlook the investigative, analytical and modelling skills provided by
professional business analysts and their ability to uncover tacit knowledge, challenge
tacit assumptions and analyze scenarios and impacts.
Early engagement of business analysis is essential to uncover the root causes of
business problems and define the business requirements. It is also needed to support
the definition, development and deployment of the solution. Within a software
development team, the business analysts help the business staff to clarify, elaborate
and prioritize their requirements at various points during the development process.
Furthermore, they bring business domain knowledge and insight, and are able to ensure
any proposed requirements align with the strategic business context.
Where organizations apply Agile methods, the product owner is the designated business
representative who works alongside the development team. This raises further questions
about the role of the business analyst, in particular about the relationship with the
product owner role. The following alternative organization models are typical:
• The business analyst works closely with the product owner to analyze the
required features and also with the development team to clarify the detailed
requirements as they evolve during the development process.
7
The benefits of buying summaries with Stuvia:
Guaranteed quality through customer reviews
Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.
Quick and easy check-out
You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.
Focus on what matters
Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!
Frequently asked questions
What do I get when I buy this document?
You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.
Satisfaction guarantee: how does it work?
Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.
Who am I buying these notes from?
Stuvia is a marketplace, so you are not buying this document from us, but from seller RobinKras. Stuvia facilitates payment to the seller.
Will I be stuck with a subscription?
No, you only buy these notes for $9.22. You're not tied to anything after your purchase.
