Chapter 4

Business Analysis Frameworks

4.1 Identify Business Analysis (BA) roles and
responsibilities

4.1.1 List Critical/Core Stakeholder Roles and

responsibilities
4.1.2 Define Types of Roles (Internal vs External)
4.2 Identify Attributes of Stakeholder
Communication

4.2.1 List elements in a Communication Plan

4.2.2 Identify Communication Channels
4.3 Identify attributes related to Gathering
Requirements

4.3.1 List Types of Requirements

4.3.2 List ways of Gathering Requirements
4.3.3 List Tools used for Capturing Requirements
4.3.4 Define Requirements Traceability Matrix/Product
Backlog
4.4 Identify Product Roadmap attributes

4.4.1 Define what a Product Roadmap is

4.4.2 List Product Roadmap components
4.4.3 Define a release plan
4.5 Identify Components of Product Delivery

4.5.1 Define Components of Project/Product Acceptance

4.1 Identify Business Analysis (BA) Roles and
responsibilities
• Critical Stakeholders? are individuals who either care about or
have a vested interest in the project. The more critical
stakeholders are those who play a role in approving, funding, or
executing the project.
• Critical or core stakeholders are business analysts, business
sponsor, process owner, product manager, product owner, etc.)
• The formal stakeholder roles are generally considered to be the Project
Owner, Sponsors, Project Manager, Team Leader, Team Members, and
the Project Clients.
• These stakeholder roles are not absolute, fixed in stone.
• It is common in large projects to have a BA, who communicates the
technical progress of the project to the business community.
• Projects that produce multiple products may have PO, who are responsible
for the value of the product produced by the project. Hence, the stakeholders
and roles may vary depending on what is appropriate for the specific
project.
• 4.1.2 Define Types of Roles (Internal vs External)
• There are two major branches of stakeholders in PMgt:
• 1. Internal Stakeholders and
• 2. External Stakeholders.
• Because PMgrs are also stakeholders, they are also either Internal or
External.
• Internal PMgt

Internal, or in-house, PMgt involves using people from within your
organization to manage and monitor a project.

PMgrs are sourced from your existing staff and are usually selected
based on skills and capabilities suited to the project’s goals.
• External Project Management

External project management
involves bringing in external
specialists instead. External
specialists are experts in their field
who work outside of the company.

When you hire an external
specialist, this means you will be
contracting project managers on a
project-by-project basis.
• Question
• Which key stakeholder groups are there in project management?
(Select two)
• Neutral X
• Internal
• Negative X
• Positive X
• External
• Internal and external stakeholders are the two main categories of
stakeholders in project management, where internal stakeholders are
defined as being employees of the firm undertaking the project and
external stakeholders as not being employees of the organization.
• Question
• Which project stakeholder role is in charge of acting as a bridge
between the business community and the technical solution providers?
• Project manager X
• Business analyst
• Project sponsor X
• Business sponsor X
• Within a project, the business analyst's function entails acting as a
technical solution provider's point of contact with the business
community. A project manager can escalate issues with a project
sponsor.
4.2 Identify attributes of stakeholder
communication
4.2.1 List elements in a communication plan
• Communication Plan
• A critical component to the overall project plan is a Communication
Plan, which describes how, when, and by whom information about the
project will be disseminated to stakeholders.
• Communication can take many forms depending on which is most
appropriate for each stakeholder. Some stakeholders may only require
an emailed update, others may prefer a phone call, and some may
require in-person meetings.
• The level of communication is determined by the Stakeholder
Register and Stakeholder Analysis.
• Each communication plan is unique to a project; however, key
components that should be included in every communication plan are
the following:

Key Stakeholders - a list of each stakeholder with contact information,
such as phone numbers and email addresses.

Team Members - a list of team members along with their roles and
contact information.

Communication Methods - a description of the main methods and
channels to use when contacting persons, such as email, phone calls,
in-person meetings, video meetings, social media communications,
etc.

Communication Type - this includes the types of communication, to
whom, how that communication will be shared, and what will be
included.

Communication Style - this element depends on your stakeholders.
For example, some stakeholders would prefer formal communication
while others like informal communication.

Meeting Schedules - this should be set at the beginning of the project.
For example, scrum meetings are held daily, it is common for teams to
meet at least weekly, but a monthly meeting is common with other
stakeholders or clients. Meeting schedules can be changed depending
on modifications occurring in the project.

Key Messages - set key messages that you will communicate to your
stakeholders. This means setting a key message for each stakeholder
that is aligned with their role.

Communication Goals - goals can help ensure you make decisions
based on what you are trying to achieve.
• Project Status Meetings (i.e., Standup
Meetings, Daily Scrum, Daily Huddle)

• Whichever you choose to call it, this form of communication is critical

in projects using an Agile approach. The concept is simple. The Agile
team holds a 15-minute meeting each morning, before work begins, to
communicate their current work status during an iteration or sprint.
The idea of this meeting is that it should be relevant yet brief enough
that team members don’t become uncomfortable "standing" (as
opposed to "sitting").
• During the meeting, Agile team members gather around the team’s
physical task board to share progress, report impediments, and make
commitments for the current iteration or sprint. Each team member
typically answers three questions about their work status:
1. What did I accomplish yesterday?
2. What will I commit to, or complete, today?
3. What impediments or obstacles are preventing me from meeting
my commitments?
• All discussion during the Project Status Meeting should be focused
on answering these three questions. Other questions that arise are
addressed outside of the standup.
• Question
• Match each section of a communication management plan with its
description using drag and drop.
• Communication methods = Emails, phone calls, in-person
meetings
• Communication styles = Formal, informal, open
• Communication types = What is communicated and to whom
• Emails, phone conversations, and in-person meetings are examples of
communication methods that might be included in a communication
management plan.
• What is communicated and to whom are two examples of
communication types.
• Formal, casual, and open communications are all types of
• 4.2.2 Identify communication channels/ tools
• Communication
• Keeping all stakeholders informed is critical during the life cycle of a
project. As previously discussed, the Communication Plan identifies who
must be kept informed about a project and how that communication should
occur.
• The communication itself involves three components:
1. Communication Method - Email, phone calls, in-person meetings,
social media, etc.

2. Communication Style - Formal, informal, open

3. Communication Type - What is communicated and to whom

• Calculating Communication Channels
•
The pathway of communication (who tells who) is called a "channel".
The total number of communication channels depends on how many
stakeholders are involved. Before you can identify who should tell
who, you must first identify all the possible communication channels.
PMI uses the following formula:
• 2Communication Channels = N * (N – 1) /2,
• where N signifies the number of stakeholders.
• 2.1.4 Define a typical project structure for a traditional plan-
based approach
• Defining a Project Structure
• Setting expectations, communicating strategic objectives, and earning buy-
in from executives and investors, requires a plan that clearly defines the
project structure. A common visual for this plan is called a Project
Roadmap.
• The purpose of a Project Roadmap is to
provide a high-level overview of the project.
The key elements in a Project Roadmap are
the following:
• For example, if it is a small project with 4 stakeholders, there are 6
communication channels, calculated as follows:

• CC = N * (N – 1) /2,
• = 4 * (4-1)/2
• = 4 * (3)/2
• = 12/2
• Communication channels = 6
• Another example:
• Communication Channels

• If there are 10 stakeholders there are communication channels.

• CC = 10 * (10-1)/2
• = 10 * (9)/2
• = 90/2
• Communication channels = 45
4.3 Identify attributes related to gathering
requirements
4.3.1 List types of requirements (e.g., functional, nonfunctional,
stakeholder, security, solution, business, migrating, market research,
bench marking, etc.)
• What are Requirements?
• Requirements are statements provided by the stakeholder explaining
business problems or business needs that must be addressed. These
ideas then become part of the project plan for actionable solutions to
be developed.
• Main categories of requirements for a project are the following:
1. Business Requirements - what practices or policies must
be changed or created to support the project.

2. User Requirements - what tools, training,

and practices must be changed or
created to meet the project goals.

3. System Requirements - what technology changes or processes must be put

into place to support the project.
• Examples of types of requirements include functional and non-functional,
stakeholder, transition, security, solution, business, migrating, market
research, benchmarking, quality, etc.
4.3.2 List ways of gathering requirements
• Gathering Project Requirements
• How do you know what are the requirements that measure success of a
project? You must gather them. Gathering is the process of determining,
documenting, and managing stakeholder needs and criteria to meet the
project objectives.
• Ways of Gathering Requirements
• There are no limits to how requirements can be gathered. Common ways of
gathering include workshops, surveys, suggestion boxes, error logs, etc. However,
many consider the most effective ways to gather requirements for a project are to
talk directly to the stakeholders.
• The two best ways to gather requirements for a project from its stakeholders are
simply the following:
1. Interviews

2. Meetings
4.3.3 List tools used for capturing requirements (e.g.,
use case, user stories, process diagrams, etc.)
• Tools and Techniques for Requirements Gathering
• Several tools and techniques are used to gather requirements to meet project
objectives.
• Listed below are some of the more common:

Interviews - typically performed by asking prepared and spontaneous
questions of stakeholders and recording their responses.

Focus Group Meetings - a technique that brings together prequalified stakeholders
and subject matter experts to learn about their expectations and attitudes regarding
a proposed product, service, or result.

Facilitated Workshops - are focused sessions that bring key stakeholders together
to define cross-functional requirements and reconcile stakeholder differences.

Questionnaires and Surveys - written sets of questions designed to quickly
accumulate information from many respondents.

Prototyping - involves building a working model for a product to help get early
feedback on its requirements. For example, "Storyboarding" is a prototyping
technique showing sequence or navigation through a series of images or
illustrations.

Observations - provide a direct way of viewing individuals in their environment
and how they perform their jobs or tasks and carry out processes. Observation is
also known as “Job Shadowing" and it is usually done externally by an observer
viewing a business expert performing a job.

Benchmarking - compares planned or actual practices and quality standards to
comparable projects.

Context Diagrams - show how all aspects of the business system will interact with
the product.

Document Analysis - examines existing documentation to identify information
relevant to the requirements.
• Group Activities for Identifying Requirements
• There are several activities used in group meetings to help identify project
requirements.

Brainstorming - used to generate a list of ideas in a short period of time.

Nominal Grouping - usually combined with
Brainstorming. Nominal Grouping is a weighted
ranking method that enables a group to
generate and prioritize issues giving
everyone equal voice. For example, stakeholders
individually offer ideas, all the ideas are ranked through a voting process by all
stakeholders, the top ideas become the requirements. This technique is the most
common!

Story Mapping (i.e., Idea/Mind Mapping) - consists of ordering user stories that
were created during brainstorming. The user stories or ideas are map along the
horizontal axis in rough order of priority (or “the order in which you would
describe activities to explain the behavior of the system”). Then down the vertical
axis to represents increasing complexity of implementation.

Affinity Diagrams - groups related ideas under topics for further analysis.

Multicriteria Decision Analysis - is a technique that utilizes a decision matrix to
provide an analytical approach for establishing criteria, such as risk levels,
uncertainty, and valuation, to evaluate and rank many ideas. Examples of criteria
are cost, cost saving, ease of implementation, ease of modification/flexibility,
increase in sales, return on investment, etc.
• Group Decision-Making Techniques
• After requirements are identified and ranked, if there are multiple alternatives, how
is a decision made as to which requirements should be included in a project?
• There are three approaches to group decision-making:
1. Unanimity - everyone agrees. In other words, the decision has unanimous support.

2. Majority - the decision has support of more than 50% of the group.

3. Plurality - if a majority cannot be achieved, the decision with the largest block is
approved. This usually occurs when more than two options are being considered.
4.3.4 Define requirements traceability matrix/product backlog
• Preparing Deliverables from Requirements
• The development and testing of product requirements into deliverables
involve up to two backlogs and a testing matrix.

• Product Backlog - is an ordered list of user-centric requirements that

a team maintains for a product. It is compiled of all the things that
must be done to complete the whole project. It breaks down each of
the items on the list into a series of steps that helps the development
team.
• Sprint Backlog - is a subset of the Product Backlog used in an Agile approach to
project management. A Sprint Backlog contains only items that can be completed
during the few days' length of a single Sprint. After the work in that Sprint is
completed, a new iteration of Sprint is defined with items selected from the Product
Backlog and the development process is repeated. In other words, a Sprint Backlog
is a list of work items identified by the Scrum Team to be completed during a
Scrum Sprint.
• Traceability Matrix - is a grid that links the product requirement to the
deliverables that satisfy the project goals. It does this by tracking each requirement
through the project life cycle.
• Question
• What kinds of needs fall within the major project requirement
categories? (Select three)
• User requirements
• Business requirements
• Stakeholder requirements X
• Functional requirements X
• System requirements
• Business requirements, user requirements, and system requirements
make up the three basic types of project requirements.
• Question
• Which methods of communication are thought to be the most effective
for getting project requirements from stakeholders? (Select two)
• Meetings
• Interviews
• Brainstorms X
• Emails X
• The two most effective methods to get requirements from project
stakeholders are meetings and interviews, according to experts.
• Question
• Which method for acquiring requirements assigns votes to
brainstorming ideas.
• Nominal Group technique
• Delphi technique X
• Forming X
• Norming X
• Through a vote mechanism, the Nominal Group technique ranks
brainstorming ideas. Getting team members to collaborate on a project
process is a component of norming. A process called "forming" occurs
when team members first come together. The Delphi method is
employed to collect anonymous project ideas.
• Question
• Which project elements satisfy the needs of the product according to a
requirements traceability matrix?
• Tasks X
• Deliverables
• Scopes X
• Milestones X
• The deliverables that meet the product requirements are connected by
a requirements traceability matrix.
4.4 Identify product roadmap attributes
4.4.1 Define what a product roadmap is
• What is a Project Roadmap?
• Project roadmaps provide an overview of the major elements of a
project. They include objectives, milestones, deliverables, resources,
and planned timelines. A project roadmap serves as a reminder of the
project's objectives, sets expectations, and can be useful to update
stakeholders. In other words, the Project Roadmap communicates the
"why" of a project and serves as a high-level strategic view. The
Project Roadmap does not delve into the day-to-day tasks or provide a
detailed view of the progress being made by each team member.
• What is a Product Roadmap?
• Product Roadmaps are like Project Roadmaps, except a
Product Roadmap includes details such as Requirements
and Tactical Steps.
• Basically, there are two types of Product Roadmaps:
1.Traditional Roadmap - Uses a Waterfall Model (linear). The flow of
development is a long-term commitment to building specific features on a set
timeline. This roadmap is unidirectional, from requirements to design and then to
development, then to testing and maintenance.

2. Agile Roadmap - Accommodates inevitable changes while still committing to

getting meaningful work done. It communicates a short-term plan for achieving
product goals with the flexibility to adjust that plan according to customer needs.
Today, most business prefer the Agile approach and the major reason for that is the
flexibility that comes with an Agile Roadmap.
4.4.2 List product roadmap components
• Components of a Product Roadmap
• Both types of roadmaps have common components. These common
components are as follows.

Products - An item, service or method that satisfies a customer's need or
demand. It has a combination of tangible and intangible attributes (benefits,
features, functions, uses). The Product Vision is the beginning of the
roadmap.

Goals - Measurable, time-bound objectives that have clearly defined success
metrics associated with them. They appear in a product roadmap as Tasks to
show the critical accomplishments required to make the product vision a
reality.

Releases - Typically the launch of new product or feature that provides value to
customers. Releases often contain epics or multiple features that get delivered at the
same time.

Epic - A large user story that can't get delivered as defined within a single release.
It's often broken down into small features or user stories that can get delivered
incrementally.

Features - Represents new or improved functionality that delivers value to users.
Features provide more detailed information about new functionality.

Minimum Viable Product (MVP) - A development technique in which a new
product gets just enough core features for it to function. The goal of the MVP is to
quickly get feedback from customers and improve the product without having to
invest a lot of time or money that would potentially go to waste.

User Stories - Defines a new software feature from an end-user perspective —
including what the user wants and why. The words "features" and "user stories" are
often used interchangeably but are not the same. User Stories are stored in the
Product Backlog.

Timeline - Product roadmaps typically include dates to show when new products
and updates to existing ones will be completed and released.
• To build a roadmap, product owners
consider market trajectories, value
propositions, and engineering
constraints. Once these factors are
reasonably well-understood, they're
expressed in a roadmap as initiatives
and timelines.
• The Product Roadmap must be clear
and concise to keep the team focused
and motivated towards the same goal.
If you want to plan out every detail,
put that information in the Product
Backlog.
4.4.3 Define a release plan
• What is a Release Plan?
• A Release Plan provides a high-level summary timeline of the release
schedule (typically three to six months) based on the product roadmap
and the vision for the product's evolution. In other words, where a
Product Roadmap
communicates the "why"
and "how" of a product, a
Release Plan details the
"what" and "when".
• Question
• What distinguishes a product roadmap from a project roadmap?
(Select two)
• Requirements
• Stakeholder participation X
• Tactical steps
• Deliverables X
• Because they are far more thorough than project roadmaps, product
roadmaps also include requirements and tactical stages.
4.5 Identify components of product delivery
4.5.1 Define components of project/ product acceptance (e.g.,
requirements traceability matrix/product backlog, Transition Plan,
etc.)
• What are the two components of Project Acceptance?
• Before a deliverable can be approved for sign-off by the Customer, a
set of conditions must be met. These conditions are contained in the
documents known as Acceptance Criteria and the Traceability
Matrix.
• Acceptance Criteria (AC) - a set of requirements listed in a written document that
include performance requirements and essential conditions that must be met before
project deliverables are acceptable. These criteria set out the specific circumstances
under which the user will accept the final output of the project. If requirements and
acceptance criteria are not documented, expectations and assumptions about the
project may vary for executives, stakeholders, and the project team. The project is
likely to fail if these people have different expectations.
• Acceptance Criteria provide the following benefits:

Manage expectations

Define scope and reduce ambiguity

Establish testing criteria

Defend against scope creep
• Traceability Matrix - is a grid that links the product requirement to the
deliverables that satisfy the project goals. It does this by tracking each requirement
through the project life cycle. The purpose is threefold:


Ensure each requirement adds business value.

Tracks requirements throughout the project life cycle.

Provides a structure for managing changes to the product scope.
• There are three types of Traceability Matrices:
1. Forward Traceability - maps the requirements to test
cases. This helps ensure that the project is moving in
the right direction and ensures all the requirements
are tested thoroughly.

2. Backward Traceability - is the reverse direction of

Forward Traceability. Backward Traceability maps test
cases to requirements. This helps ensure that the scope
of the project is not expanding because of the addition
of features or functionality that were not part of the
original requirements.
• 3. Bidirectional Traceability - does both. It maps
requirements to test cases for Forward Traceability, and
test cases to requirements for Backward Traceability in
a single document. This document helps ensure that all
the specified requirements have corresponding test
cases and vice versa.

• When is a Project Finished?

• If the final product(s) meet the Acceptance Criteria, and their requirements are
complete according to the Traceability Matrix, the project is finished,
• and so, the Review Meeting can be scheduled!
• Question
• Which kind of traceability in a requirements matrix makes sure that a
project's scope doesn't grow?
• Backward traceability
• Forward traceability X
• Multidirectional traceability X
• Bidirectional traceability X
• Backward traceability in a requirements traceability matrix associates
test cases with requirements, which helps prevent project scope
expansion.
• Forward traceability links test cases to requirements.