PMI Professional in Business
Analysis (PMI‐PBA)®
The world’s largest global training provider
info@theknowledgeacademy.com
theknowledgeacademy.com
PMI Professional in Business Analysis
(PMI‐PBA)®
© The Knowledge Academy Ltd
PMP is a registered mark of the Project Management Institute, Inc
1
About The Knowledge Academy
• World Class Training Solutions
• Subject Matter Experts
• Highest Quality Training Material
• Accelerated Learning Techniques
• Project, Programme, and Change
Management, ITIL® Consultancy
• Bespoke Tailor Made Training Solutions
• PRINCE2®, MSP®, ITIL®, Soft Skills, and More
© The Knowledge Academy Ltd
2
1
Acknowledgements
• PMP® is a registered mark of the Project Management Institute, Inc. All rights
reserved.
• PMI® is a registered mark of the Project Management Institute, Inc. All rights reserved.
• PMBOK® Guide is a registered mark of the Project Management Institute, Inc. All
rights reserved.
• PgMP® is a registered mark of the Project Management Institute, Inc. All rights
reserved.
• PBA® is a registered mark of the Project Management Institute, Inc. All rights reserved.
© The Knowledge Academy Ltd
3
Administration
• Trainer
• Fire Procedures
• Facilities
• Days/Times
• Breaks
• Special Needs
• Delegate ID check
• Phones and Mobile devices
© The Knowledge Academy Ltd
4
2
The 5 Domains of PBA
• Domain 1: Needs Assessment
• Domain 2: Planning
• Domain 3: Analysis
• Domain 4: Traceability and Monitoring
• Domain 5: Evaluation
© The Knowledge Academy Ltd
5
Examination Weighting
10%
18%
15%
22%
35%
Domain 1. Needs Assessment
Domain 2. Planning
Domain 3. Analysis
Domain 4. Traceability and Monitoring
Domain 5. Evaluation
© The Knowledge Academy Ltd
6
3
Domain 1
Needs Assessment
© The Knowledge Academy Ltd
7
Outlines of Domain 1
• Module 1: Identify Problems or
Opportunity
• Module 5: Facilitate Product
Roadmap Development
• Module 2: Assess Current State
• Module 6: Assemble Business Case
• Module 3: Determine Future State
• Module 7: Support Charter
Development
• Module 4: Determine Viable
Options and Provide
Recommendation
© The Knowledge Academy Ltd
8
4
Overview
• It involves the process utilised to analyse a current business problem or opportunity
• It analyses current and future states to ascertain an optimal solution that will provide
value and address the business requirements
• It gathers the results of the analysis to give the decision‐makers appropriate information
for ascertaining whether an investment in the expected solution is viable
© The Knowledge Academy Ltd
9
Key Concepts
• Need assessment is a process that manages the investment decisions made by the
organisation
• The activities done as part of this knowledge area give decision‐makers information
while ascertaining which strategic initiatives to pursue, which actions to perform, and
which elements of portfolios to implement or terminate
• Understanding the business issues and opportunities with stakeholders is essential for
all projects and programs; the degree to which a needs assessment is formally
documented depends upon cultural, organisational, market, environmental, and
possibly regulatory constraints
© The Knowledge Academy Ltd
10
5
Module 1: Identify Problems or
Opportunity
© The Knowledge Academy Ltd
11
Introduction
• Identifying problems or opportunities is the process of recognising the problem to be
solved or the opportunity to be pursued
• The main advantage of this process is the generation of a clear understanding of the
situation that the organisation is thinking to address
• If the problems or opportunity is not completely understood, the organisation may
pursue a solution that does not address the requirement of the business requirement
• Several kinds of elicitations are executed to draw out adequate information and to fully
identify the problems or opportunities
• Once the situation is completely understood, it is essential to elicit relevant information
to understand the magnitude of the problem or opportunity
© The Knowledge Academy Ltd
12
6
Introduction
(Continued)
• Once the problem is recognised, a situation statement is drafted by documenting the
prevailing problems that require to be solved or the opportunity to be explored
• Drafting a situation statement assures a firm understanding of the problem or
opportunity that the organisation plans to address
© The Knowledge Academy Ltd
13
Inputs
• The following are the inputs required for Identifying problems and opportunities
Assessment of
Business Value
2
1
Elicitation Results (Confirmed/
Unconfirmed)
3
Enterprise Environmental
Factors
© The Knowledge Academy Ltd
14
7
Inputs
1. Assessment of Business Value
• The business value indicates the money, time, goods or intangibles like goodwill in
return for something exchanged
• The business analysis includes reviewing partially implemented or implemented
solutions to evaluate whether the business value that the organisation is supposed to
provide is being delivered
• When there is negative business value, the assessment is utilised to ascertain whether a
problem exists and to what severity
• The analysed situation is considered an opportunity when the business value is
expected because the organisation can pursue it further to improve the positive results
© The Knowledge Academy Ltd
15
Inputs
2. Elicitation Results
• Elicitation results include the business analysis information acquired from elicitation
activities
• Results of earlier discussions can take many forms, like diagrams, sketches, notes and
models on sticky notes, flipcharts, or index cards
• By analysis and continued collaboration, the elicitation results utilised to identify the
problems or opportunities might transition from unconfirmed to confirmed, showing
the iterative nature of elicitation and analysis within business analysis
© The Knowledge Academy Ltd
16
8
Inputs
3. Enterprise Environmental Factors
• Enterprise Environmental Factors(EFS) conditions are not under the direct control of the
team that constrain, influence, or direct the project, program or portfolio
Examples
Stakeholder
Expectations
and Risk
Appetite
Social and
Cultural
Influences
Contractual
Restrictions
Marketplace
Conditions
Legal and
Governing
Restrictions
© The Knowledge Academy Ltd
17
Tools and Techniques
• The following are the tools and techniques used in identifying problems and
opportunities
1
2
3
Benchmarking
Competitive Analysis
Document Analysis
© The Knowledge Academy Ltd
4
5
6
Interviews
Market Analysis
Prototyping
18
9
Tools and Techniques
Benchmarking
• Benchmarking is a process of comparing the company's services, products, or processes
performance against the business considered to be best in the industry
• The benchmarking aims to identify internal opportunities for improvement
• Companies can make essential improvements by studying companies with excellent
performance, finding out what makes such excellent performance possible and then
comparing those processes to how your business operates
© The Knowledge Academy Ltd
19
Tools and Techniques
• Steps for Benchmarking
Select a service, product, or internal department to benchmark
Ascertain which companies are best‐in‐class against whom you should benchmark or
which organisations you will compare your business to
Collect information on their internal performance, or metrics
Collate the data from both organisations to find out gaps in your company’s
performance
Adopt the processes and policies used by the best‐in‐class performers
© The Knowledge Academy Ltd
20
10
Tools and Techniques
Competitive Analysis
• Competitive analysis is a technique for gathering and analysing information about an
organisation's external environment
• With the help of competitive analysis, one may identify competitor strengths that
impose threats or uncover an area of weakness an organisation has as compared to its
competition
• Competitive analysis is an element of market analysis
© The Knowledge Academy Ltd
21
Tools and Techniques
Document Analysis
• Document analysis is an elicitation technique utilised to collect requirements
• It is the study of the existing document and the information related to the current
application support process to understand the process better
• Business analysts can collect requirements from stakeholders utilising interviews,
questionnaires, or facilitating sessions
© The Knowledge Academy Ltd
22
11
Tools and Techniques
(Continued)
• The goal of Document Analysis is to collect details of the key functions like business
entities, business rules, and business attributes required to be updated
• Document Analysis involves several strategies like keeping records of contract details,
analysing the business plans, training guidelines for the process, suggestion logs,
customers review, and the existing system specifications
© The Knowledge Academy Ltd
23
Tools and Techniques
Interviews
• Interviews are a formal or informal approach to obtain information from groups of
stakeholders or individuals by asking questions and documenting the answers given by
the interviewees
• Interviews are one of the various elicitation techniques that can be utilised to identify
information required to develop the situation statement
© The Knowledge Academy Ltd
24
12
Tools and Techniques
Market Analysis
• Market analysis is a technique utilised to gather and analyse market conditions and
characteristics for the organisation's market area and then overlay this information with
the organisation's projections and plan for growth
• Information concerning any number of characteristics can be researched, for instance,
growth rates, market size, customers, products, trends, distribution channels, threats,
opportunities, and so on
© The Knowledge Academy Ltd
25
Tools and Techniques
Prototyping
• Prototyping is the procedure of getting early feedback on needs by presenting a model
of the expected solution before building it
• While identifying problems or opportunities, this technique is beneficial to learn and
discover what is valuable from the perspective of the customer
© The Knowledge Academy Ltd
26
13
Output
• The following are the key outputs of identifying the problems and opportunities
1
Situation
Statement
Business Need
2
© The Knowledge Academy Ltd
27
Output
Business Need
• A business need is an impetus for a change in an organisation on the basis of an existing
problem or opportunity
• It describes why organisational changes are being proposed and why a new portfolio
program, component, or project is considered
• Once clearly defined, it is utilised to provide context while discussing the solution
options, future states as well as business requirements
© The Knowledge Academy Ltd
28
14
Output
Situation Statement
• It is an objective statement of a problem or opportunity that involves the statement
itself, the effect of the situation on the organisation, and the resulting impact
• The situation statement gives a brief format for presenting the problem or opportunity
statement
© The Knowledge Academy Ltd
29
Module 2: Assess Current State
© The Knowledge Academy Ltd
30
15
Introduction
Assess Current State is the process of analysing the current environment to
understand essential factors that are external or internal to the organisation,
which might be the reason or cause for a problem or opportunity
• The main benefit of this process is that it provides an adequate understanding of the
existing state of the organisation, providing context for ascertaining which components
of the current state will remain consistent and which changes are essential to achieve
the future state
© The Knowledge Academy Ltd
31
Inputs
• The following are the inputs for assessing the current state
Enterprise and Business Architecture
Organisational Goals and Objectives
Situation Statement
© The Knowledge Academy Ltd
32
16
Inputs
1.
Enterprise and Business Architecture
• Enterprise architecture is a set of business and technology elements required to operate
an enterprise. Enterprise architecture is assembled in the form of a model or schematic
• Modes can be examined to understand the operational and strategic impacts of a
change on several aspects of the enterprise
• Business architecture is an enterprise architecture's subset and includes elements like
the organisational structures, business functions, locations, and processes of an
organisation, involving documents and depictions of those elements
© The Knowledge Academy Ltd
33
Inputs
2.
Organisational Goals and Objectives
• Organisational objectives describe the measurable targets that a business establishes to
deliver its strategy
• The organisational objectives statement aim is to direct the actions of the organisation
to attain its goals
• Objectives are usually broad‐based and may have a span of one or more years
• Goals and objectives provide criteria which is utilised while making decisions regarding
which projects or programs are best pursued
© The Knowledge Academy Ltd
34
17
Inputs
3.
Situation Statement
• The situation statement gives an objective statement regarding the problem or
opportunity the business is looking to address, along with the impact and effect the
situation has on the organisation
• The assessment of the current state is compared with the situation statement to
ascertain the impact of the problem or opportunity on the existing environment of the
organisation
© The Knowledge Academy Ltd
35
Tools and Techniques
• The following are the tools and techniques for assessing the current State
01.
02.
03.
04.
05.
Business Architecture
Techniques
Business Capability
Analysis
Capability
Framework
Capability Table
Elicitation
Techniques
06.
07.
08.
09.
10.
Glossary
Pareto
Diagrams
Process Flows
Root Cause and
Opportunity Analysis
SWOT Analysis
© The Knowledge Academy Ltd
36
18
Tools and Techniques
Business Architecture Techniques
• The business architecture techniques are organisational frameworks available to model
business architecture
• All these techniques provide different approaches for analysing different aspects of the
business
• These models can serve as frameworks, checklists, or job aids for evaluating the current
state and can be utilised to guide strategic decisions within the organisation, particularly
at the portfolio and program levels
© The Knowledge Academy Ltd
37
Tools and Techniques
Business Capability Analysis
• Business capability analysis is a technique utilised to examine performance in terms of
people skills, processes and other resources an organisation uses to perform its work
• Historical data gathered by analysing current capabilities are utilised to understand
trends and ascertain what measures will be useful for determining whether a capability
is performing as expected to perform in its current state
© The Knowledge Academy Ltd
38
19
Tools and Techniques
Capability Framework
• A capability framework gives descriptions of the essential skills, behaviours, knowledge,
systems, abilities, and overall competencies of value to an organisation
• The capabilities analysed can be products or people. Capability frameworks may involve
information regarding financial, physical, informational, or intellectual abilities
• Capability frameworks may include information about the competencies that allow the
organisation to operate and might be utilised as a starting point when performing a gap
analysis to identify the capabilities required to achieve the future state
© The Knowledge Academy Ltd
39
Tools and Techniques
Capability Table
• Capability tables are utilised for analysing capabilities in a future or a current state
• The model can be utilised within the future‐state analysis to display the capabilities
required to solve a problem or seize an opportunity
• The technique can be applied to describe the relationship between a situation, its root
causes, and the abilities required to address the situation
• The model can provide a simple way to visualise current problems, the related root
causes, and the proposed new capabilities that could address the problem if pursued
© The Knowledge Academy Ltd
40
20
Tools and Techniques
Elicitation Techniques
• The following are the effective techniques during current state analysis
1
2
3
4
Document
Analysis
Interviews
Observations
Questionnaires
and surveys
© The Knowledge Academy Ltd
41
Tools and Techniques
Glossary
• In business analysis, a glossary presents a list of definitions for terms and acronyms
regarding a product
• A glossary must be started as early as possible in program, portfolio, or project analysis
to support common language; hence, it is a technique that is usually started with needs
assessment activities
• It might be possible to reuse a basic glossary maintained as a part of the organisation's
business architecture or from past project archives
© The Knowledge Academy Ltd
42
21
Tools and Techniques
Pareto Diagrams
• A Pareto diagram is a histogram that can be utilised to communicate the results of root
cause analysis
• Pareto diagrams are a unique form of vertical bar chart utilised to emphasise the
essential factor in a data set
• The vertical axis can describe any category of information that is significant to the
product team, like frequency or cost or consequences like money or time
• The horizontal axis can represent the categories of data being measured, for instance,
cause categories or types of problems
© The Knowledge Academy Ltd
43
Tools and Techniques
Process Flows
• Process flows define business processes and how stakeholders interact with those
processes
• Process flows can be utilised to document current as‐is processes of the business
• The models can be utilised to analyse how a process contributes to a given problem
• Value stream maps; a variation of a process flows can be utilised to identify process
steps that do or do not add value
• The information can be utilised to identify areas where a process may be streamlined to
reduce inefficiencies
© The Knowledge Academy Ltd
44
22
Tools and Techniques
Root Cause and Opportunity Analysis
• Root Cause Analysis: It is an analytical technique utilised to ascertain the basic reason
that causes a defect, variance, or risk. In businesses, root cause analysis is utilised to
identify the underlying cause of a problem so that solutions can be devised to eliminate
or reduce them
• Opportunity Analysis: Opportunity analysis: It is a technique utilised to study the major
facets of a possible opportunity to determine the potential changes in products offered
to allow its achievement. Opportunity analysis may need further work to study the
potential markets
© The Knowledge Academy Ltd
45
Tools and Techniques
SWOT Analysis
• SWOT analysis is a technique used for analysing the strengths (S) and weaknesses (W) of
a project, organisation, or options and the opportunities (O) and threats (T) that exist
externally
• This technique can be utilised to assess organisational goals, strategy, and objectives
and ease discussions with stakeholders when discussing significant and high‐level
aspects of an organisation, particularly as they pertain to a particular situation
© The Knowledge Academy Ltd
46
23
Output
Current State Assessment
• The current state assessment is an understanding of the as‐is state of the organisation
or the current mode of operations
• It is a culmination of the analysis results gathered from the examination of the existing
environment of the organisation
• Typical information captured throughout the current state analysis may be a high‐level
overview of the existing business context, for example, models processes, key and
textual description stakeholders
© The Knowledge Academy Ltd
47
Module 3: Determine Future State
© The Knowledge Academy Ltd
48
24
Introduction
• Determine future state is the process of deciding the gaps in current abilities as well as a
set of proposed changes required for attaining an aspired future state that addresses
the problem or opportunity under analysis
• The key benefit of the process is the resulting classification of a set of capabilities
needed for the organisation for transforming the existing state to the desired future
state and meet the business requirement
• The future state may include:
o New work that the organisation will take on;
o Outsourcing for acquiring the abilities that the organisation cannot obtain on its
own;
© The Knowledge Academy Ltd
49
Introduction
(Continued)
o In a different manner, the current resources are applied
o Combinations of enhanced, new, or acquired capabilities
© The Knowledge Academy Ltd
50
25
Inputs
Business Needs
• The business need is the input for the change an
organisation will undertake for addressing the current
problem or opportunity
• The business needs to direct the business goals as well
as objectives of the future state. It gives the rationale
for why the organisation wants the change
• The business needs to give appropriate data required
for formulating the aspired future state
© The Knowledge Academy Ltd
51
Inputs
Current State Assessment
• Provides the foundational information regarding the existing environment that becomes
the starting point from which the future state is based
• The current state assessment may contain information about aspects of the current
environment that can be referenced while deciding which modifications will address the
problem or opportunity
• A review of the current abilities happens for understanding the starting point or baseline
the product team is working on before recommending new capabilities
© The Knowledge Academy Ltd
52
26
Inputs
Enterprise and Business Architectures
• Enterprise and business architectures include a set of the business and technology
elements required for operating an enterprise
• The information regarding the current state is given by the architecture frameworks that
can be used as an origin point for discussions regarding the future state
• Enterprise and business architectures support the product team in knowing which
abilities are present today as well as help the team draw conclusions about which new
or improved capabilities will be required in the future state
© The Knowledge Academy Ltd
53
Inputs
Situation Statement
• It gives a context for understanding the problem or opportunity that today exists. It is
the starting point from which the future state can be built
• The future state is created for solving or address the problem/opportunity the
organisation is addressing
© The Knowledge Academy Ltd
54
27
Tools and Techniques
Affinity Diagram
• Affinity diagrams show categories as well as subcategories of ideas that cluster or have
an affinity to one another
• Affinity diagrams are used for processing a large set of information or ideas into a
manageable collection of data organised by categories while defining future state
considerations
• Affinity diagrams help to organise related causes of a problem or opportunity for
problem‐solving
• Group data by a common theme lets insights be recognised that might not be uncovered
while considering the information separately
© The Knowledge Academy Ltd
55
Tools and Techniques
Benchmarking
• Benchmarking is used for comparing one set of practices, processes, and results from
measurements against another
• This method gives another technique for determining new capabilities by comparing
against benchmarking studies of external organisations that solved the same problems
or seized opportunities that the organisation is considering
• Benchmarking studies guide final suggestions for addressing the situation and highlight
which suggestions not to proceed with
© The Knowledge Academy Ltd
56
28
Tools and Techniques
Capability Table
• In the future state, capability tables relate the recognised issues within the current state
to their connected root causes and the capabilities needed for addressing the problem
• This technique is a good choice for a model to compare the information obtained
throughout the current state analysis with the information resulting from future state
discussions
• Alongside the features or capabilities, the model describes aspects of the existing state
needed for addressing the issue and achieve the future state
© The Knowledge Academy Ltd
57
Tools and Techniques
Elicitation Techniques
• Some of the common techniques that are effective throughout the future state analysis
contain brainstorming and facilitated workshops:
1
Brainstorming
• It is used to recognise a list of ideas within a short period. The product team conducts
conversations regarding the potential capabilities that the organisation might take into
consideration for addressing the situation throughout future state analysis
• Brainstorming is a viable technique for helping product teams to make an initial list of
capabilities
© The Knowledge Academy Ltd
58
29
Tools and Techniques
2
Facilitated Workshops
• Structured meetings are conducted by a skilled, neutral facilitator and a carefully chosen
group of stakeholders for collaborating and work toward a stated objective
• Due to the facilitated workshops supporting interactivity, collaboration, as well as
improved communications among participants, the technique is a viable elicitation
technique for a team to use while describing the future state
© The Knowledge Academy Ltd
59
Tools and Techniques
Feature Model
• Feature models are another technique to give a visual representation of all the solution
features arranged in a hierarchical or a tree structure
• The capability for helping visually and logically group feature sets is the strength of the
model
• The model is used to parse out groups of features or capabilities to facilitate discussions
regarding different future state options that the organisation may want to consider.
Different versions of the feature model can be built, with every possible representation
a future state alternative
© The Knowledge Academy Ltd
60
30
Tools and Techniques
Gap Analysis
• Gap analysis compares two entities, normally the as‐is
and to‐be state of a business. Gap analysis is
performed by examining the differences between the
current and future states throughout the needs
assessment
• Gap analysis is done by comparing the capabilities
required against the current capabilities as well as
identifying the difference, or “gap”
• This gap refers to the missing capabilities that the
organisation requires for acquiring to address the
business requirements in the future state
© The Knowledge Academy Ltd
61
Tools and Techniques
Kano Analysis
• Kano analysis is used to model and analyse product features by considering the features
from the customer's viewpoint
• Kano analysis can be used for helping a product team know the importance of features
being considered for the future state
• Product features are grouped into five categories and plotted on a grid throughout the
Kano analysis
1. Basic
Features that give little satisfaction to stakeholders but
cause extreme dissatisfaction while missing from the end
solution
© The Knowledge Academy Ltd
62
31
Tools and Techniques
(Continued)
2. Performance
The features that stakeholders think about, desire, and
use for evaluating the final solution consciously
3. Delighters
The features that distinguish the product from the products
of the competitors and are sometimes referred to as the
“wow” factor
© The Knowledge Academy Ltd
63
Tools and Techniques
(Continued)
4. Indifferent
The features that do not satisfy or dissatisfy a customer. The
customer does not care whether these features are added or
not. These features are plotted along with the horizontal axis
of the Kano model
5. Reverse
Features that reduce the satisfaction level of the
stakeholders when present and increase it when excluded
from the final product
© The Knowledge Academy Ltd
64
32
Tools and Techniques
Process Flow
• Process flows describe the business processes in the current state and are used as a
starting point for discussions concerning the desired and needed modifications for the
future state
• Process flow modelling is a good technique for doing what‐if analysis to walk through
multiple future‐state scenarios with key stakeholders
© The Knowledge Academy Ltd
65
Tools and Techniques
Purpose Alignment Model
• The purpose alignment model gives a framework for supporting strategic or product
decision making
• The framework is used for describing options by aligning them with the business
objective they support
• The model can become a basis for deciding which options to proceed with and how to
pursue them
© The Knowledge Academy Ltd
66
33
Tools and Techniques
(Continued)
• The following are the four categories of objectives in the model and the actions that
might be taken from a feature perspective:
Who cares
Parity
1
Differentiating
2
3
4
Partner
© The Knowledge Academy Ltd
67
Tools and Techniques
1.
Differentiating: The features in this category are mission‐critical and give high market
differentiation
2.
Parity: In this, the features help the organisation to manage its parity in the
marketplace
3.
Partner: The features assigned are not considered mission‐critical, but if given, they
would allow the organisation to distinguish itself in the market
4.
Who cares: The features in this category are neither distinguishing nor mission‐critical
to the organisation. The features that end up in this category are usually not created
© The Knowledge Academy Ltd
68
34
Tools and Techniques
Solution Capability Matrix
• A solution capability matrix is a model that gives a simple visual method for examining
capabilities as well as solution components in one view, recognising where capabilities
will be addressed in the new solution
• Throughout the planning discussions, the product team can use the model to
understand when different solution components are delivered when timing information
is added
© The Knowledge Academy Ltd
69
Outputs
Business Goals And Objectives
• Business goals and objectives recognise what
the business expects the program, portfolio, or
project to deliver
• Business goals and objectives align with the
organisational goals and objectives but are at a
lower level due to the definition stated targets
that the business is seeking to achieve
© The Knowledge Academy Ltd
70
35
Outputs
Required Capabilities and Features
• The required capabilities and features recognise the list of net changes the organisation
requires to achieve the aspired future state
• The listed capabilities and features do not prescribe a solution. Still, additional analysis
is required for determining how these capabilities and features will be delivered
© The Knowledge Academy Ltd
71
Module 4: Determine Viable Options and
Provide Recommendation
© The Knowledge Academy Ltd
72
36
Introduction
• It is a process of applying multiple analysis techniques for examining potential solutions
to meet the business goals and objectives and to determine which options are
considered the best for the organisation to pursue
• It validates the feasibility of proposed solutions and promotes the best course of action
for executives as well as decision‐makers to meet the business goals and objectives
© The Knowledge Academy Ltd
73
Inputs
Business Goals and Objectives
• Business goals and objectives recognise what the business expects the project, program,
or portfolio to deliver
• Every viable option under consideration will be assessed for determining how well it
satisfies the stated business goals as well as objectives
• Every option will satisfy the goals and objectives separately, and some options will
satisfy them far better than others under consideration
© The Knowledge Academy Ltd
74
37
Inputs
Enterprise and Business Architectures
• Enterprise and business architectures give insights into the current state of the
organisation
• Each option can be analysed as well as explained within the context of existing
architectures while presenting viable options
• Performing this helps frame up the size and complexity of every option in terms that
decision‐makers can more comfortably relate to and understand
© The Knowledge Academy Ltd
75
Inputs
Required Capabilities and Features
• Required capabilities, as well as features, identify the list of net modifications the
organisation seeks to achieve in the aspired future state
• The capabilities and features are addressed differently by every proposed option. Which
capabilities and features are covered for defining the product scope for every option
• Initially, discussions start at a high level, but as options are discussed, formulated and
more refined, certain capabilities may be defined as more valuable than others, and
adjustments made to the solution approaches under consideration
© The Knowledge Academy Ltd
76
38
Inputs
Situation Statement
• It is an objective statement of a problem or opportunity that includes the statement
itself, the effect of the situation on the organisation and the resulting impact
• The situation statement gives the context for discussions while identifying a list of viable
options
© The Knowledge Academy Ltd
77
Tools and Technique
Benchmarking
• It compares an organisation's practices, processes and measurements of results against
established standards or against what is accomplished by a "best in class" organisation
within its industry or across industries
• Benchmarking results can help to stimulate ideas for creating a list of viable options
© The Knowledge Academy Ltd
78
39
Tools and Technique
Cost‐Benefit Analysis
• It is a financial analysis tool used for comparing the benefits given by a portfolio
component, program, or project against its costs. Generally, it is used for identifying the
most viable option from a set of options
• Cost‐benefit analysis is frequently conducted before project initiation as part of portfolio
or program management activities
• Completing a cost‐benefit analysis needs an understanding of financial analysis, so
business analysis resources may frequently seek financial analysts support within their
organisation to assist with this work
• The cost‐benefit analysis results are contained in the business case for demonstrating
why the solution option chosen and proposed is considered the most viable choice
© The Knowledge Academy Ltd
79
Tools and Technique
Elicitation Techniques
• It is used to draw information from different sources. The information needed to form a
list of viable options is obtained by applying multiple elicitation techniques
• For example, prototyping can define whether an option is viable by developing a
prototype model for assessing stakeholder expectations against the model
• Prototypes help remove uncertainties regarding options, thereby decreasing product‐
related risks
© The Knowledge Academy Ltd
80
40
Tools and Technique
Feature Injection
• It is a framework and collection of principles used for delivering successful outcomes by
developing and expediting how a product team develops and analyses product
requirements
• The framework is popular with teams that are used for adaptive development methods
o Step 1: Define the business value
o Step 2: Inject features
o Step 3: Spot examples
© The Knowledge Academy Ltd
81
Tools and Technique
Group Decision‐Making Techniques
• It can be used in a group setting to bring the participants to a final decision on an issue
or topic
• Group decision‐making techniques can be used in conjunction with other techniques for
deciding on the suggested solution option
• The team establishes how decisions will be made throughout business analysis planning
for avoiding confusion or conflict at the point when decisions are required
© The Knowledge Academy Ltd
82
41
Tools and Technique
Real Options
• It is a decision‐making process that can be used on projects that follow an adaptive
delivery model
• The technique's objective is to approach decision making with a similar level of thinking
used to approach a stock option where a decision is made about whether to continue an
option
• Decision making applies the two fundamental principles with real options
© The Knowledge Academy Ltd
83
Tools and Technique
(Continued)
• The first is to decrease the number of decisions that require to be made in the short
term, and the second is to delay all decision making until as late as possible
• Delayed decision making gives a product team more time for discovering and improving
its knowledge base; it decreases uncertainties and avoids making decisions on the basis
of assumptions
© The Knowledge Academy Ltd
84
42
Tools and Technique
Valuation Techniques
• Valuation techniques quantify the return or value that an option will provide. The
following are some common valuation techniques:
o Internal Rate of Return(IRR): The projected annual yield of an investment,
incorporating both initial as well as ongoing costs
o Net Present Value(NPV): Future value of predicted benefits is shown in those
benefits' value at the investment time
o Payback Period(PBP): The time required for recovering the investment, normally in
months or years. The longer the payback period, the greater the risk
© The Knowledge Academy Ltd
85
Tools and Technique
(Continued)
o Return on Investment(ROI): The percentage return on an initial investment. ROI is
calculated by taking the total projected net benefits and dividing them by the
investment cost
© The Knowledge Academy Ltd
86
43
Tools and Technique
Weighted Ranking
• The weighted ranking is a technique used for supporting objective decision making.
Usually, it is done with the use of a weighted ranking matrix
• A weighted ranking matrix or table is used to weight, rate, as well as score every
criterion against a collection of options
© The Knowledge Academy Ltd
87
Outputs
Feasibility Study Results
• Feasibility study results are the summarised outcomes received from the fulfilment of
the feasibility analysis
• The results are gathered into a package that is conducive to support the executive
review as well as decision making
• Many organisations may need a standardised template to package and communicate the
study results
• Although a suggested option will accompany the communication package, enough
information concerning each of the viable options considered should be given if
decision‐makers do not favour the preferred choice
© The Knowledge Academy Ltd
88
44
Outputs
Recommended Solution Option
• The recommended solution option is defined to be the best course of action for
addressing the business requirement
• This recommendation is the best option, considering the results and factors of the
completed analysis, including the financial analysis results
• The recommended solution option should contain a summary of why the option was
selected and a high‐level description of the process used for reaching the decision
© The Knowledge Academy Ltd
89
Module 5: Facilitate Product Roadmap
Development
© The Knowledge Academy Ltd
90
45
Introduction
• Facilitate product roadmap development is the process
that encourages the development of a product roadmap
that outlines, at a high level, which aspects of a product
are planned for delivery over the course of the portfolio,
program, or one or more project releases or iterations,
and the possible sequence for the delivery of these
aspects
• The main benefit of this process is that it builds shared
expectations between stakeholders for the deliverables
and the possible order in which they will be delivered
© The Knowledge Academy Ltd
91
Introduction
• Various key elements are generally documented and elicited in the product roadmap,
involving the following:
Strategy Information
Success Criteria
Portfolio
Market Forces
Program
Product Releases
Initiatives
Features
Product Vision
Timelines
© The Knowledge Academy Ltd
92
46
Inputs
• The following are the inputs required to facilitate product roadmap development
Business Goals and Objectives
• Business objectives and goals identify the deliverables for the program, project or portfolio
• Products are developed to solve the business requirement; hence, they require to align with
the stated business goals and objectives
© The Knowledge Academy Ltd
93
Inputs
• The following are the inputs required to facilitate product roadmap development
Required Capabilities and Features
• The needed capabilities and features identify the number of net changes that the
organisation will require to obtain to accomplish the desired future state
• Required features and capabilities can be displayed in the product roadmap to
communicate the proposed timing of delivery
© The Knowledge Academy Ltd
94
47
Tools and Techniques
• The following are the tools and techniques for facilitating product roadmap
development
Product Visioning
Facilitated Workshops
1
3
2
Feature Model
4
Story Mapping
© The Knowledge Academy Ltd
95
Tools and Techniques
1.
Facilitated Workshops
• Facilitated workshops utilise a structured meeting led by a proficient, impartial facilitator
and a carefully chosen group of stakeholders to cooperate and work toward a stated goal
• Facilitated workshops can be utilised to obtain the information needed to develop the
product roadmap
• Because facilitated workshops support collaboration, interactivity, and improved
communications between participants, this technique is a viable elicitation technique for
performing this work
© The Knowledge Academy Ltd
96
48
Tools and Techniques
2.
Feature Model
• A feature model is a scope model that visually describes all the features of a solution
arranged in a hierarchical or tree structure
• A new feature model can be created, or an existing one can be referenced to identify a
number of features for the product roadmap
• A facilitated workshop can be conducted to recognise the features and prioritise the
feature list into a product roadmap
© The Knowledge Academy Ltd
97
Tools and Techniques
3.
Product Visioning
• Product visioning is a technique utilised to set the high‐level direction for a product
release or a product
• It involves conducting conversations with team members to visualise and obtain
consensus about what the team envisions for the product
• Product visioning is performed by utilising one more elicitation technique, like
collaborative games
© The Knowledge Academy Ltd
98
49
Tools and Techniques
4.
Story Mapping
• Story mapping is a technique utilised to sequence user stories on the basis of their
business value and the order in which their users usually perform them so that teams
can reach a common understanding of what will be built
• Story maps assist in communicating the features and product elements that the product
team will be responsible for delivering
• The output from this technique gives insightful information utilised in the development
of the product roadmap
© The Knowledge Academy Ltd
99
Output
Product Roadmap
• A product roadmap presents a high‐level view of product features, along with the order
in which the features will be built and delivered
• It is primarily used to communicate how a product will develop and mature over time
• Product roadmaps comprise information about the product vision and the evolution of
the product during its life cycle
• Product roadmaps are utilised as a planning tool to understand a product and how it will
support organisational strategy as it is further refined and improved
• Product roadmaps must be aligned with the aims and milestones identified as part of the
strategic planning effort
© The Knowledge Academy Ltd
100
50
Module 6: Assemble Business Case
© The Knowledge Academy Ltd
101
Introduction
• It is the process of synthesising well‐researched as well as analysed information for
supporting the choice of the best portfolio elements, programs, or projects for
addressing business goals and objectives
• It helps organisations consistently scrutinise programs and projects, allowing the
decision‐makers to define whether a program and project are worth the required
investment
© The Knowledge Academy Ltd
102
51
Introduction
The following are the common set of components any business incorporates:
1.
Problem/Opportunity
• Define what is prompting the requirement for action
• Use a situation statement to document the business problem or opportunity addressed
via a portfolio component, program, or project
• Include appropriate data for assessing the situation and identify which stakeholders or
stakeholder groups are affected
© The Knowledge Academy Ltd
103
Introduction
2.
Analysis of the Situation
• Describe how a potential solution will support and contribute to the business goals and
objectives. Include root cause(s) of the problem or the main contributors to an
opportunity
• Support the analysis via appropriate data for confirming the rationale. Include needed
capabilities versus existing capabilities
• The gaps between these will form the portfolio, program, or project objectives
© The Knowledge Academy Ltd
104
52
Introduction
3.
Recommendation
• Present the results of the feasibility analysis for every potential option. Define any
constraints, assumptions, risks and dependencies for every option
• Rank is ordered the choices and lists the recommended one; include why it is
recommended and why the others are not
• Review the cost‐benefit analysis for the recommended option
© The Knowledge Academy Ltd
105
Introduction
(Continued)
• When a business case is built, it becomes a valued input for initiating a portfolio
component, program, or project. Many factors have driven the development of the
business case, including:
1. Market Demand
2. Organisational Need
3. Customer Request
4. Strategic Opportunities
5. Technological Advancement
6. Legal or Regulatory Requirement
7. Ecological Impacts
8. Social Needs
© The Knowledge Academy Ltd
106
53
Introduction
(Continued)
• Both adaptive and predictive project life cycles know the business case as a key input for
starting project‐related work; adaptive methods will gather "just enough" of the content
to get started
• Features will continue to be added as the solution is more refined with adaptive
approaches; therefore, the business case will not include the full list of benefits, as it
would in a predictive approach
• Adaptive methods will measures cost and schedule from a very high level and then
progressively expand upon this information via the iterative development cycle. At the
same time, predictive methods will finish all this analysis upfront
© The Knowledge Academy Ltd
107
Inputs
Business Goals and Objectives
• Business goals and objectives define stated targets that the business is seeking to
accomplish
• The business case links business goals and objectives and portfolio components,
programs, or projects
• Business goals and objectives are involved in the business case for providing context
regarding what the business expects to achieve by continuing the proposed change
© The Knowledge Academy Ltd
108
54
Inputs
Feasibility Study Results
• Feasibility study results are the reviewed results obtained from the feasibility analysis's
completion
• The results are included in the business case to give the supporting information to
decision‐makers who will define whether the portfolio component, program, or project
should be initiated
• Decision‐makers can review the results for understanding the proposed solutions
analysed and why each was considered a viable option
• Moreover, the feasibility results support why the recommended solution option is being
suggested
© The Knowledge Academy Ltd
109
Inputs
Product Roadmap
• The product roadmap provides a high‐level view of the product features that will be
created and delivered
• The key information from the product roadmap is included within the business case for
providing decision‐makers with insights into how the product is envisioned to evolve
© The Knowledge Academy Ltd
110
55
Inputs
Recommended Solution Option
• The recommended solution option is defined as the best course of action for addressing
the business requirement
• The recommended solution option is showcased within the business case, along with
the supporting information that rationalises its choice
© The Knowledge Academy Ltd
111
Inputs
Required Capabilities and Features
• The required capabilities and features identify the organisation's net changes to achieve
the aspired future state
• The capabilities and features needed for the recommended solution are listed in the
business case for providing decision‐makers with insight into which capabilities and
features are required when the recommended solution option being recommended is
continued
© The Knowledge Academy Ltd
112
56
Inputs
Situation Statement
• The situation statement is an objective statement of a problem or opportunity that
contains the statement itself, the effect of the situation on the organisation, and the
resulting impact
• The situation statement is involved in the business case for communicating the problem
or opportunity that the proposed solution addresses
• The situation statement is meant to help those reviewing the business case to
understand the problem or opportunity that the four organisation faces and reduce the
quick judgments regarding potential solutions
© The Knowledge Academy Ltd
113
Tools and Techniques
Document Analysis
• Document analysis is an elicitation technique used
for analysing the current documentation and
identify relevant product information
• Documentation reviews various sources for
obtaining the relevant information required to
create the business case while assembling the
business case
• The most relevant documents used are the outputs
produced from the previous Needs Assessment
processes
© The Knowledge Academy Ltd
114
57
Tools and Techniques
Facilitated Workshops
• It uses a structured meeting led by a skilled, neutral facilitator and a carefully chosen
group of stakeholders for collaborating and work toward a stated objective
• Because facilitated workshops support interactivity, collaboration, and improved
communication among participants, the technique is a good choice when a team
requires information and gathering support to assemble the business case
© The Knowledge Academy Ltd
115
Tools and Techniques
Glossary
• A glossary gives a list of definitions for terms and acronyms regarding a product in
business analysis
• A glossary can give a common vocabulary regarding terms that the stakeholders and
product team may be unfamiliar with and focuses particularly on the terms needing
clarity to understand the information in the business case while assembling a business
case
• When the product team shares a glossary over the portfolio, program, or project, a link
to the shared glossary should be given within the business case or team workspace
© The Knowledge Academy Ltd
116
58
Tools and Techniques
Product Visioning
• Product visioning is a technique that a product team
can use for obtaining a shared understanding of the
product and set a high‐level direction for its
development. It includes discussions for helping the
team to develop its ideas regarding the product
• A vision statement or corresponding output that
clearly describes the goal and rationale for creating
the solution is involved in the business case to
provide decision‐makers with a similar
understanding of the team's product
© The Knowledge Academy Ltd
117
Outputs
Business Case
• A business case gives a documented economic feasibility study, establishing the validity
of the benefits, in terms of value, to be delivered by a portfolio component, program, or
project
• The business case is the common link between the business goals as well as objectives
and the portfolio components, programs, or projects established to execute the
business strategy. Business goals and objectives may have various business cases for
supporting them
• An approved business case is input while creating a charter for initiating a portfolio
component, program, or project. Business cases are gathered as one of the final process
steps in Needs Assessment
© The Knowledge Academy Ltd
118
59
Outputs
Product Scope
• Product scope is described as the features as well as functions that characterise a
solution
• The product scope varies on the basis of which viable option from Determine Viable
Options and Provide Recommendation
• Product scope is known at a high level by the capabilities and features compared with
the chosen option. Product scope remains to be defined as the product team furthers
the analysis
• Product scope may be revised during an initiative in response to changing business
requirements, risks, or one or more constraints imposed by budget or schedule
© The Knowledge Academy Ltd
119
Module 7: Support Charter Development
© The Knowledge Academy Ltd
120
60
Introduction
• It is the process of collaborating on charter development with the sponsoring entity and
stakeholder resources using the business analysis knowledge, experience, and product
information obtained throughout the needs assessment and business case development
efforts
• It allows a smooth transition from the business case to charter development and gives
stakeholders a foundational understanding of the portfolio, program, or project
objectives, including product scope and requirements
• A portfolio charter is a document issued by a sponsor that authorises and defines the
portfolio structure and links the portfolio to the strategic objectives of an organisation
• A program charter authorises the program management team to use organisational
resources for executing the program and links the program to the strategic objectives of
an organisation
© The Knowledge Academy Ltd
121
Introduction
(Continued)
• Project charter is issued by the project sponsor or initiator to authorise a project
formally and gives the manager with authority for applying organisational resources to
project activities
• A charter establishes the scope boundaries and builds a documented record of the
initiation of the portfolio component, program, or project
© The Knowledge Academy Ltd
122
61
Introduction
(Continued)
• Usually, information that is part of a charter contains:
o Description and purpose;
o Business goals/objectives;
o High‐level product and portfolio, program, or project scope;
o Risks;
o Summary milestone schedule;
o Summary budget information;
© The Knowledge Academy Ltd
123
Introduction
(Continued)
o High‐level risks and dependencies;
o Success criteria; and
o Information regarding internal and external parties related to the portfolio, program,
or project. The size of the charter varies depending on the complexity of the
portfolio, program, or project and the information understood at the time of
creation
© The Knowledge Academy Ltd
124
62
Inputs
Business Case
• The business case defines pertinent information for defining whether the initiative is
worth the needed investment
• The needs assessment and business case build the foundation for determining the
objectives of the portfolio component, program or project, and serve as inputs to a
charter
• The business usually requires a cost‐benefit analysis in the business case to justify and
establish boundaries for the portfolio component, program, or project, which is
essential information while creating a charter
© The Knowledge Academy Ltd
125
Inputs
Product Scope
• Product scope is described as the features and functions that characterise a solution.
The initial product scope is established by the inclusion of high‐level product
requirements throughout charter development
• Moreover, the charter may include information about out‐of‐scope features for
identifying any features that have been deferred or cut from the scope
© The Knowledge Academy Ltd
126
63
Tools and Techniques
Document Analysis
• Document analysis is an elicitation technique used for analysing the existing
documentation to identify relevant product information. It can be used for identifying
information used in the development of the charter
• Reviewing organisational charts to identify a potential list of stakeholders or existing
business architecture models for understanding business areas influenced by the
proposed change is one example of how existing documentation can be reviewed to
elicit information for developing a charter
© The Knowledge Academy Ltd
127
Tools and Techniques
Interviews
• An interview is formal or informal for eliciting
information from stakeholders. It is a viable
technique for eliciting information required in
the development of the charter
• Interviews are scheduled with multiple
stakeholders who possess key information. The
information obtained from interviews can
initiate the charter or fill in information gaps
when other elicitation techniques were used
earlier
© The Knowledge Academy Ltd
128
64
Outputs
Charter
• A charter establishes the scope boundaries as well as creates a documented record of
the initiation of the portfolio component, program, or project
• It is used for establishing a partnership between the business and the product
development team by establishing internal agreements to make sure the proper delivery
of the portfolio, program, or project
• Business analysis is used in the development of the charter. Usually, the individual
assigned for performing business analysis in predictive life cycles supports the sponsor
with this work
•
In adaptive life cycles, a sponsor might be created the charter, but a product owner may
contribute to the business analysis work to help charter development
© The Knowledge Academy Ltd
129
Outputs
Shared Product Information
• Shared product information includes the compilation of all the information discussed
and shared over the product team throughout collaboration
• The product team obtains a common understanding of the solution that the portfolio
component, program, or project is commissioned for delivery when the charter is
collaboratively developed
• Building a shared understanding decreases the risk that the product team may develop
an end solution that aligns with stakeholder expectations and allows the team for
working more efficiently throughout development efforts
© The Knowledge Academy Ltd
130
65
Domain 2
Planning
© The Knowledge Academy Ltd
131
Outlines of Domain 2
• Module 1: Conduct BA Planning
• Module 4: Assess BA Performance
• Module 2: Prepare for Transition to
Future State
• Module 5: Business Metrics and
Acceptance Criteria
• Module 3: Manage Stakeholder
Engagement and Communication
© The Knowledge Academy Ltd
132
66
Module 1: Conduct BA Planning
© The Knowledge Academy Ltd
133
Introduction
• Conduct Business Analysis Planning is the process executed to obtain a shared
agreement about the business analysis activities the team will be performing and the
assignment of responsibilities, roles, and skillsets for the task needed to complete the
business analysis work
• The result's of the business analysis process are assembled into a business analysis plan
that may be formally documented and approved or maybe less formal depending on the
way the team operates
• The important benefit of this process is that it establishes expectations by encouraging
discussion and agreement on the way the business analysis work will be undertaken and
avoids confusion about the roles and responsibilities during execution
© The Knowledge Academy Ltd
134
67
Introduction
• Conducting business analysis planning process has three main objectives:
o Aggregates of each knowledge area approach into a cohesive set of agreements and
decisions about the way in which the business analysis will be conducted
o Produce an estimation of the level of efforts for business analysis activities
o Assembles a business analysis plan from the component approaches
© The Knowledge Academy Ltd
135
Inputs
• The following are the inputs required for conducting business analysis process
Charter
Enterprise Environmental Factors
Product Risk Analysis
Planning Approaches from all other Knowledge Areas
© The Knowledge Academy Ltd
136
68
Inputs
Charter
• A charter formally authorises the existence of a portfolio element, program, or project,
sets its boundaries, and creates a record of its initiation
• A charter gives an initial understanding of the scope and provides the rationale and
context for a product development initiative
• Along with the business analysis planning approaches, it becomes the base for
identifying which aspects of business analysis must be conducted and for evaluating the
level of effort involved
© The Knowledge Academy Ltd
137
Inputs
Enterprise Environmental Factors (EEFS)
• Conditions that are not under the team's direct control that constrain, influence, or
direct the portfolio, program, or project are covered under EEFs
• The influences of EEFs are usually considered while examining each business analysis
plan to assure their reasonability
Product Risk Analysis
• This involves the consolidated results from identifying and analysing product risks
• More complex or higher‐risk projects and products may need additional work effort to
address the complexity or risk
© The Knowledge Academy Ltd
138
69
Inputs
Planning Approaches from all other Knowledge Areas
• The planning approaches from the other knowledge areas can be incorporated into an
overall business analysis plan
• With the charter, they are the base for considering the complexity and duration of
business analysis activities and figure into any estimates developed that have business
analysis efforts related to them
• These components are:
o Stakeholders Engagement and communication approach
o Elicitation approach analysis approach
o Traceability and monitoring approach
o Solution Evaluation approach
© The Knowledge Academy Ltd
139
Tools and Techniques
Burn Down Chart
• A burn down chart is a graphical representation utilised to calculate the remaining
quantity of few trackable aspects of a project over time
• Burn down charts assist in visualising progress, stalled efforts, or backsliding where the
remaining quantity of what is being tracked rises over time
© The Knowledge Academy Ltd
140
70
Tools and Techniques
Decomposition Model
• A decomposition model is an analysis model that breaks down information defined at a
high level into a hierarchy of smaller, more discrete parts
• For estimation purposes, typical objects usually analysed with decomposition may
involve work products, scope, deliverables, function, processes, or other object types,
which can be subdivided into smaller components
• For product development efforts where discrete business analysis tasks and deliverables
are evaluated separately, decomposition models can be utilised to identify what must be
estimated and ultimately sequenced into a business analysis work plan
© The Knowledge Academy Ltd
141
Tools and Techniques
Estimation Techniques
• Estimation Techniques are utilised to provide a quantitative assessment of possible
amounts or outcomes. One or more of the following can be involved in typical estimation
techniques for an effort:
1.
Affinity estimating: A kind of relative estimation in which team members organise
product backlog items into groups where every product backlog item is of the same size
2.
Bottom‐up estimating: It is a method of estimating cost or duration by aggregating the
estimates of the lower‐level tasks. A decomposition model usually identifies these
lower‐level tasks
3.
Delphi: It is used to support decision‐making and to support gaining consensus by
anonymous estimating
© The Knowledge Academy Ltd
142
71
Tools and Techniques
Planning Techniques
• The following are included in typical planning technique
1.
Product Backlog:
• It is the list of each product backlog item, typically requirements, user stories, or
features, that must be delivered for a solution
• In prioritised order, individual items in the backlog are assessed as part of selecting those
items that the team is about to commit in order to deliver an upcoming iteration
• The business analysis effort for any product backlog item ensures that product backlog
items satisfy the definition of ready
© The Knowledge Academy Ltd
143
Tools and Techniques
(Continued)
• Making a product backlog item ready assists the team refine its business understanding
of that item to the point where it has enough information to start development
2.
Rolling Wave Planning
• It is an iterative planning technique in which the work to be achieved in the near term is
planned in detail, whereas the work in the future is planned at a higher level
• From the view of business analysis, business analysts working as part of a predictive life
cycle can be accountable for or work with the project manager
• To create rolling wave estimates for business analysis tasks at intervals stipulated within
the overall project schedule
© The Knowledge Academy Ltd
144
72
Tools and Techniques
3.
Story Mapping
• It is a technique utilised in planning for projects that use an adaptive life cycle
• Story mapping is utilised to sequence user stories on the basis of their business value
and the order in which their users usually perform them so that teams can reach a
shared understanding of what will be built
• From the viewpoint of planning for business analysis, story mapping can assist in
suggesting when more effort may require to be spent on analysis
© The Knowledge Academy Ltd
145
Tools and Techniques
4.
Work Breakdown Structure (WBS)
• WBS is a hierarchical decomposition of the work's total scope to be carried out by the
project team to achieve the project objectives and create the needed deliverables
• Usually, a WBS is subdivided by project phase and by deliverables or elements within
that phase
• The WBS becomes the base for creating a schedule that sequences the work required to
be achieved based on priorities, estimates, dependencies, and constraints
• For projects utilising a predictive life cycle, a WBS is typically created while planning and
then revised at regularly scheduled intervals, like phase gates
• From the viewpoint of business analysis, business analysts would be accountable for the
portion of the WBS that concentrates on business analysis tasks
© The Knowledge Academy Ltd
146
73
Outputs
Business Analysis Plan
• A business analysis plan, if formally documented, might be a separate plan or might be a
sub‐plan of the portfolio, program, or project management plan
• It describes the business analysis approach by the assembly of the sub‐approaches
across every Knowledge Areas
• It covers the whole business analysis approach, from stakeholder engagement to
decisions regarding managing requirements
• It is broader than a requirements management plan, which concentrates on the way in
which the requirements will be elicited, analysed, documented, and managed
• Whether formally documented or not, the business analysis plan summarises the
agreements reached for all of its elements
© The Knowledge Academy Ltd
147
Module 2: Prepare for Transition to
Future State
© The Knowledge Academy Ltd
148
74
Introduction
• Prepare for the transition to the coming state that determines whether the organisation
is ready for the transition and how the organisation will move from the current to the
future state to integrate the solution or partial solution into the operations of the
organisation
• The key advantages of this process are that the organisation can successfully adopt the
changes resulting from the implementation of the new solution or solution component
• That any product or program component or overall program advantage expected for the
solution can be sustained after it is pulled into operation
• Frequently utilised strategies for planning a transition incorporate are:
o Massive one‐time cutover to the future state
© The Knowledge Academy Ltd
149
Introduction
(Continued)
o Staged release of future state by target segment like by region or by type of client and
type of employee
o Time‐boxed coexistence of the current as well as a future state, with a final cutover on a
particular future date
o The permanent coexistence of the current as well as the future state
© The Knowledge Academy Ltd
150
75
Inputs
• The following are the inputs for prepare for the transition to future state:
Business Case
Current State
Assessment
Product Risk
Analysis
Product Scope
1
2
3
4
Requirements and
Other Product
Information
5
Solution Design
6
Stakeholder Engagement
and Communication
Approach
7
© The Knowledge Academy Ltd
151
Inputs
1. Business Case
• The business case defines pertinent information to determine whether the initiative is
worth the required investment
• The business case gives the context for the transition and a basis for prioritising
transition activities
2. Current State Assessment
• The current assessment is the culmination of the analysis results produced during the
assessment of the current state
© The Knowledge Academy Ltd
152
76
Inputs
(Continued)
• This evaluation can be examined in connection with the solution design to identify
differences between them and consider how to manage those differences. Common
differences are areas where the solution design:
o Provides less functionality than the current state
o Replaces current state functionality with new or enhanced abilities and gives
abilities that before did not exist in the current state
3. Product Risk Analysis
• The product risk analysis incorporates the consolidated outcomes from identifying and
analysing product risks
© The Knowledge Academy Ltd
153
Inputs
(Continued)
• Higher‐risk or more complicated products and projects may require extra effort to
address the risks or complexity of the transition
4. Product Scope
• Product scope is defined as the characteristics and functions that characterise a solution
• Understanding the product scope might be the basis for deciding how the transition
must continue and what special resources and coordination will be required
© The Knowledge Academy Ltd
154
77
Inputs
5. Requirements and Other Product Information
• Requirements and the other product information incorporate all information about a
solution and are the culmination of results from elicitation and analysis activities
• The transition requirements are part of the requirements and other product information
• Transition requirements define temporary abilities, like data conversion and training
requirements, and operational changes required to transition from current to future
• Any modelling or textual techniques utilised to describe and elaborate business,
stakeholder, and solution requirements, particularly non‐functional requirements, may
reveal transition requirements
© The Knowledge Academy Ltd
155
Inputs
(Continued)
• Usually, transition requirements emerge throughout a discussion of other requirements
and product information
6. Solution Design
• The solution design is important for preparing the transition to a future state, as it
determines it
• The solution design usually incorporates diagrams based on the product information
identified and elaborated by business analysis but go beyond what can be defined by
business analysis alone
© The Knowledge Academy Ltd
156
78
Inputs
7. Stakeholder Engagement and Communication Approach
• The stakeholder engagement and communication approach summarises all the
agreements governing how stakeholders will be engaged and communicated across the
portfolio, program, or project
• The approach identifies which stakeholders should be involved in preparing for the
transition and how best to collaborate
• Transition work may be executed poorly without the participation of key stakeholders in
transition activities
© The Knowledge Academy Ltd
157
Tools and Techniques
• The following are the tools and techniques for prepare for the transition to future
state:
Elicitation Techniques
Group decision‐making Techniques
Job Analysis
© The Knowledge Academy Ltd
Process Flows
SWOT Analysis
User Stories
158
79
Tools and Techniques
1. Elicitation Techniques
• Brainstorming: It is utilised to identify a list of ideas in a short period of time
• Brainstorming assists to move a product team from thinking about product
development to thinking through a transition
• Facilitated Workshops: The structured meeting led by the skilled neutral facilitator and
a carefully selected group of stakeholders to collaborate and work towards a stated goal.
Facilitated workshops create an opportunity to get synergy by sharing ideas for the
transition
• The stakeholders who participate in these sessions can also instil ownership in the
solution, assisting with the actual transition
© The Knowledge Academy Ltd
159
Tools and Techniques
(Continued)
• Interviews: It can be utilised to elicit information to prepare for the transition to the
future state
• Interviews with key stakeholders, incorporating those daily work, are likely to be
influenced by the transition, may be utilised to evaluate readiness for the transition and
elicit transition requirements
• Individual interviews are usually utilised to evaluate readiness so that each stakeholder
can speak candidly about concerns for the transition
© The Knowledge Academy Ltd
160
80
Tools and Techniques
2. Group Decision‐Making
Techniques
• Group decision‐making techniques can
bring participants to a final decision on an
issue or topic under conversation
• Decision‐making techniques can assist
reach excellent methods for moving a
solution from a development environment
into an operational one
© The Knowledge Academy Ltd
161
Tools and Techniques
3. Job Analysis
• Job analysis is a technique utilised to identify job requirements and competencies
required to perform efficiently in a particular job or role
• It can be utilised to determine training needs, as a precursor to writing a job posting, or
support a performance appraisal process
• As a part of preparing for the transition to the future state, job analysis is utilised to
think through what is required to hire and train individuals for few roles that may be
required to support the future state
© The Knowledge Academy Ltd
162
81
Tools and Techniques
3. Priortisation Schemes
• Prioritisation schemes are distinct approaches utilised to prioritise requirements,
characteristics, or any other product information
• The prioritisation may be utilised to prepare for a transition in any situation where it
becomes important to conduct a transition in segments. Typical reasons for segmenting
a transition incorporate:
o Need to manage a large number of transition requirements or readiness issues
o Presence of complicated transition requirements or issues need to make the
transition at various sites
© The Knowledge Academy Ltd
163
Tools and Techniques
4. Process Flows
• A process flow has visually documented the steps or tasks that people perform in their
jobs or interact with a product
• Some process flows comprise the requirements, and other product information provides
the basis for training materials on the new procedures once the transition occurs
• Additional processes may be created, when necessary, to describe the transition
processes themselves to make it easier for those responsible for the transition to know
what needs to be done
© The Knowledge Academy Ltd
164
82
Tools and Techniques
5. SWOT Analysis
• SWOT analysis is the technique for examining the strengths(S) and weaknesses(W) of an
organisation, project, or option and the opportunities(O) and threats(T) that exist
externally
• A SWOT analysis concentrated on transition can assist prepare the product team for
making a transition
• The analysis can give way for the participants to express their expectations and concerns
for the participants to express their expectations and concerns for transition at a high
level by stating these concerns as strengths, weaknesses, opportunities and threats.
• Readiness issues may surface from the weaknesses and threats that are identified
© The Knowledge Academy Ltd
165
Tools and Techniques
6. User Stories
• User stories are a way to document stakeholder requirements from users' perspectives,
concentrating on the value or advantage attained by users with the completion of that
story
• For solutions developed utilising an adaptive life cycle, some transition requirements
may be expressed as user stories
• Transition user stories may concentrate on the expectations for training materials and
communications, the rollout of the future state, or new procedures
© The Knowledge Academy Ltd
166
83
Outputs
• The following are the outputs for prepare for the transition to future state:
1
Transition
Plan
Readiness
Assessment
2
© The Knowledge Academy Ltd
167
Outputs
1. Readiness Assessment
• A transition readiness assessment determines the ability of an organisation and interest
to transition to the future state, not utilise its capabilities
• The assessment is utilised to identify any gaps in readiness that are considered risks to
accomplishing the end state and risk replies for addressing them
• A readiness assessment may take the form of a report that gives the readiness
assessment results, or it may take the form of a readiness checklist, where readiness
features can be checked off to reveal where transition elements still need attention
© The Knowledge Academy Ltd
168
84
Outputs
2. Transition Plan
• A transition plan is on the basis of the readiness assessment and the transition strategy
• From a business analysis point of view, a transition plan involves testable and actionable
transition requirements
• While there are a few general aspects of a transition plan that can be repeated from
solution to solution, other aspects may highly concentrate on products and industries
involved in transition along with the specific organisation in which the transition is
transpiring
© The Knowledge Academy Ltd
169
Module 3: Manage Stakeholders
Engagement and Communication
© The Knowledge Academy Ltd
170
85
Introduction
• Manage stakeholders engagement and communication encourages relevant involvement
in business analysis processes, keeping stakeholders thoroughly informed regarding
ongoing business analysis efforts, and sharing product information with stakeholders as
it develops
• The essential benefits of this are that it fosters constant stakeholder participation in the
business analysis process and in describing the solution and maintain ongoing
communication with stakeholders
• It concentrates on monitoring the participation of stakeholders in business analysis
activities, assuring that stakeholders remain involved throughout and evaluating whether
their participation is enough for them to have a clear understanding of the needs and
other product information
© The Knowledge Academy Ltd
171
Introduction
(Continued)
• Project team members who conduct business analysis usually work closely with those
accountable for removing roadblocks
• While managing stakeholders engagement and communication since there is more to
stakeholders engagement than their participation in business analysis activities
© The Knowledge Academy Ltd
172
86
Inputs
1
Stakeholder Engagement and Communication Approach
• This approach summarises all the agreements for governing the way stakeholders will be
involved and communicated across the portfolio, program, or project
• The agreements that are within the stakeholder engagement and communication
approach give the norms for assuring that stakeholders remain involved and continue to
engage actively and that communication is open and ongoing throughout the whole
product development life cycle
© The Knowledge Academy Ltd
173
Inputs
2
Updated Stakeholder Register
• The updated stakeholder register involves the identification, evaluation, and
characterisation of the product or project stakeholders
• The characterisation of the stakeholders is essential for evaluating whether or not the
engagement of and communication with a specific stakeholder is optimal at any point in
time
© The Knowledge Academy Ltd
174
87
Tools and Techniques
Elicitation Techniques
• Elicitation techniques are utilised to draw out information from sources
• Managing engagement and communication needs exploring significant changes to how
stakeholders are engaged, or communication is conducted across business analysis
activities
• This type of exploration can be framed by the recommendations set in the stakeholder
engagement and communication approach
• Elicitation shows the stakeholders' perspective and allows product teams to brainstorm
solutions to any communication or engagement challenges that might arise
• When eliciting information regarding engagement or communication challenges, care
should be taken to include those accountable for removing roadblocks
© The Knowledge Academy Ltd
175
Output
Improved Stakeholder Engagement and Communication
• Improved stakeholder engagement and communication result from team collaboration
and directing efforts toward addressing business analysis engagement and
communication concerns as they occur
• For challenges that occur, those accountable for business analysis usually address the
concerns by closely working with and relying upon those who have management
authority, responsibilities, or the responsibility to remove roadblocks
© The Knowledge Academy Ltd
176
88
Module 4: Assess BA Performance
© The Knowledge Academy Ltd
177
Introduction
• Assess Business Analysis Performance is the process to consider the business analysis
practices' effectiveness that is in use over the organisation, usually in the context of
considering the continuous deliverables as well as consequences of a portfolio
component, program, or project
• Practices working properly at the project level can be elevated to best practices as well
as standards for use by the organisation over upcoming projects
• The main benefit is to provide the opportunity in order to adjust business analysis
practices to meet the project, its team, and the organisation's requirements
© The Knowledge Academy Ltd
178
89
Introduction
(Continued)
• Instances of what might be evaluated include the following:
o How properly did the techniques utilised meet the participants and other
stakeholders' needs?
o Were elicitation as well as an analysis conducted effectively?
o Was there enough time in order to conduct a business analysis?
o Were stakeholders engaged adequately?
o Were any stakeholders missed?
o Were any requirements missed or not understood adequately?
o Are there defects in the product that relates to the quality or completeness of
business analysis efforts?
© The Knowledge Academy Ltd
179
Inputs
Business Analysis Plan
• The business analysis plan involves decisions regarding the way business analysis
processes will be conducted and the way the decisions will be made
• A business analysis plan can be compared to what was performed to gain insights for
better planning in the future
• A business analysis work plan, a business analysis plan's subcomponent, may consist of
level of effort estimates, and the estimates can be compared to the actual work effort to
assist the team in improving upcoming estimates
© The Knowledge Academy Ltd
180
90
Inputs
Business Analysis Organisation Standards
• These standards may involve expectations for the way the business analysis will be
conducted and the tools that might be utilised to support the efforts of business analysis
• These standards may also involve key performance indicators (KPIs) established at an
organisational level for business analysis
• Business analysis organisational standards are the component of the benchmark from
which the business analysis performance can be assessed
© The Knowledge Academy Ltd
181
Inputs
Business Analysis Performance Metrics and Measurements
• Business analysis performance metrics are qualitative or quantitative measures of
inferences that are utilised to evaluate the business analysis practices' effectiveness
• Some instances of possible metrics for business analysis practices, which, when
measured, could indicate that there may be issues with their effectiveness quantitatively,
involve:
o Percentage of defects that are requirements defects;
o Percentage of missed requirements;
o Missed business objectives;
o Percentage of unstable, volatile requirements
o Average time to get customer acceptance on the requirements;
© The Knowledge Academy Ltd
182
91
Inputs
Examples of Possible Metrics
• Teams conducting lessons learned or retrospectives where business analysis practices
are within the topics discussed as well as improvements then created to business
analysis practices;
• Teams utilising standard templates of business analysis;
• Percentage of achievement of business analysis deliverables;
• Slippage for business analysis deliverables in delivery dates;
• Requirements by their "state"
© The Knowledge Academy Ltd
183
Inputs
(Continued)
• Issues or questions about the requirements which are open;
• Stakeholders comments indicating that they are dissatisfied, uncomfortable with, or
concerned of the business analysis activities or the ones conducting business analysis;
• KPls and service‐level agreements
© The Knowledge Academy Ltd
184
92
Inputs
Business Analysis Work Products
• As the verifying requirements' part throughout a product development effort, the
business analysis deliverables' quality that may specify, describe or visually explain the
requirements and other information of the product can be assessed against benchmarks
established inside business analysis organisational standards
• Problems found while verifying needs as well as trends indicating that the same
problems happen in various efforts may be caused by utilising an improper business
analysis technique, an incapacity of the practitioners to utilise the technique, inability of
stakeholders to take part in using the technique, or inadequate detail gathered using the
technique
• These kinds of problems are worth considering as assessing business analysis
performance's part
© The Knowledge Academy Ltd
185
Tools and Techniques
Burndown Charts
• A burndown chart is a graphical representation of the quantity of some remaining
trackable aspects of a project across time
• From a business analysis perspective, when a burndown chart exposes the stalled efforts
or negative progress after various iterations have been performed, it becomes necessary
to determine whether poor or incomplete product requirements' analysis or insufficient
time enabled for this work is contributing to the problems of the team and whether
other project factors are included or are the only cause of the problem
© The Knowledge Academy Ltd
186
93
Tools and Techniques
Elicitation Techniques
• Elicitation techniques are utilised in order to draw the information from sources. Some
common effective techniques to assess business analysis performance are
brainstorming, facilitated workshops, interviews, and questionnaires as well as surveys:
o Brainstorming: Used to identify ideas in a short period. As brainstorming has a
ground‐rule where each and every idea is okay, it makes an environment where the
team members can identify problems and potential solutions of the performance
that they might have otherwise kept to themselves
o Facilitated Workshop: A structured meeting that is led by a skilled, neutral facilitator
works in the direction of a stated objective. Assessing business analysis performance
inside a facilitated workshop assists a discussion on performance to stay focused
© The Knowledge Academy Ltd
187
Tools and Techniques
(Continued)
o Interviews: Used for eliciting information regarding business analysis ‐performance
through team members. Individual interviews let team members communicate their
concerns openly they may have
o Questionnaires and Surveys: Written sets of questions are designed to accumulate the
information from several respondents quickly. They can be utilised to get anonymous
feedback from a small group quickly
o Surveys can be developed in order to elicit information on the areas where the team
members wish to see performance improvements or have concerns. Suppose
confidentiality is created as a part of the process, so participants may be more willing to
give information they would not provide in a face‐to‐face communication such as an
interview
© The Knowledge Academy Ltd
188
94
Tools and Techniques
Process Flows
• Process flows document the steps or tasks visually that are performed by individuals in
their jobs
• They can be utilised to model any activity involving business analysis activities. Drawing
and analysing the business analysis activities' flow can support the possible process‐
related problems' identification
© The Knowledge Academy Ltd
189
Tools and Techniques
Retrospectives and Lessons Learned
• Retrospectives and lessons learned utilising experience in order to plan for future work:
1.
Retrospectives: Meetings that are scheduled regularly or conducted when a body of
work is performed, like the conclusion of an iteration. Retrospectives are often utilised
in adaptive life cycles
• The agenda for the meetings let members state the following
o What is working properly, or what is not working or is unclear?
o What should be changed, and the opportunities for improvement? What changes
can be made?
© The Knowledge Academy Ltd
190
95
Tools and Techniques
2.
Lessons Learned: Meetings to discuss, analyse, as well as document the feedback
regarding the project activities which are completed
• They are usually conducted by teams developing solutions using a predictive life cycle.
The same questions as used above for retrospectives are applicable to the lessons
learned sessions
• The main differences among lessons learned and retrospectives are the timing with the
issues raised throughout the meetings are addressed and the formality about
documenting the outcomes
• Retrospectives happen regularly and frequently. For predictive approaches, they are held
at the end of stage gates or development phases
© The Knowledge Academy Ltd
191
Tools and Techniques
Root Cause and Opportunity Analysis
• Root cause and opportunity analysis techniques are utilised in order to analyse the
problems as well as opportunities
• When applied to assessing business analysis performance, root cause and opportunity
analysis, can be utilised to find the underlying reasons behind business analysis
performance challenges or to identify the reasons why some business analysis practices
are working properly
• The root cause of problems may arise in the business analysis practitioners' skill level or
other aspects of product development instead of the business analysis practices
themselves
© The Knowledge Academy Ltd
192
96
Tools and Techniques
Variance Analysis
• Variance is a quantifiable deviation, divergence or departure from a known baseline or
anticipated value. Variance analysis is a way to determine the cause as well as the degree
of difference among the baseline and actual performance
© The Knowledge Academy Ltd
193
Outputs
Business Analysis Performance Assessment
• A business analysis performance assessment summarises what has been learned about
the business analysis processes' effectiveness generally and the business analysis
techniques utilised particularly
• In some cases, it may also reflect on the individuals' skill conducting business analysis or
the degree or quality of stakeholders' participation
• Practices working properly at the program or project level can be suggested for elevation
to best practices as well as standards to use by the complete organisation for upcoming
programs and projects
© The Knowledge Academy Ltd
194
97
Module 5: Business Metrics and
Acceptance Criteria
© The Knowledge Academy Ltd
195
Introduction
• A Business Metric is a quantifiable measure utilised to track and evaluate the status of a
particular business process
• It is important to note that business metrics must address key audiences, like investors,
clients, and different types of employees, like executives and middle managers
• Every business area has particular performance metrics that must be monitored –
marketers track marketing and social media metrics, like campaign and program
statistics, sales teams monitor sales performance metrics like new opportunities and
leads, and executives look at big picture financial metrics
• Business metrics are usually tracked utilising analytics and dashboard tools
© The Knowledge Academy Ltd
196
98
Introduction
(Continued)
• Acceptance criteria are the conditions that require to
be met prior to the solution is accepted
• They are utilised to measure whether a client is
satisfied with the solution built
• Acceptance criteria form the basis of acceptance tests
and are necessary for assessing the solution
throughout product analysis sessions, where product
owners or business stakeholders decide whether to
accept and release the developed solution
© The Knowledge Academy Ltd
197
Introduction
(Continued)
• Determining the acceptance criteria includes reviewing requirements and analysis
models with business stakeholders to identify how the business stakeholder would
approve something as done
• Acceptance criteria can be created at distinct levels, involving requirement, iteration,
release, and product
• In adaptive approaches, the acceptance criteria might be written at the user story level,
where various acceptance criteria need to be met for the user story to be accepted
• Also, in adaptive methods, acceptance criteria are a concise method to write the
requirements
© The Knowledge Academy Ltd
198
99
Introduction
(Continued)
• The acceptance criteria can be written at
the level of the overall solution or
business goals
• Acceptance criteria described as part of a
portfolio or program are possible to be
high level and related to the desired
overarching goals
© The Knowledge Academy Ltd
199
Inputs
• The following are the inputs used business metrics and acceptance criteria:
1
Analysis Approach
2
Analysis Model
3
4
© The Knowledge Academy Ltd
Requirements and Other Product Information
Solution Evaluation Approach
200
100
Inputs
1.
Analysis Approach
• The analysis approach defines how the analysis will be performed for the portfolio,
program, or project
• The analysis approach incorporates how and when the acceptance criteria will be
defined in the project life cycle
• The analysis approach defines how acceptance criteria relate to user stories,
requirements, releases, and solution definitions of acceptance and the level at which
they are written
© The Knowledge Academy Ltd
201
Inputs
2.
Analysis Model
• Analysis models are the culmination of creating as well as analysing draft or final models
• The models in any state can elaborate the requirements or user stories to identify
acceptance criteria
• This iterative derivation process is similar to utilising analysis models to identify
requirements. In some cases, acceptance criteria will be defined in analysis models
• Some models, like the business objectives model, can define acceptance criteria at the
product level
© The Knowledge Academy Ltd
202
101
Inputs
3.
Requirements and Other Product Information
• Requirements and other product information are starting to describe the acceptance
criteria
• This input is useful, whether it is utilised for writing acceptance criteria on the basis of
user stories, requirements, or business goals
• Stakeholders utilise this input to decide whether to accept or reject the solution on the
basis of how well it met the requirements
© The Knowledge Academy Ltd
203
Inputs
4.
Solution Evaluation Approach
• The solution evaluation approach describes what types of metrics will be utilised to
measure the performance of a solution
• Acceptance criteria are described to establish acceptable ranges on the metrics
identified
© The Knowledge Academy Ltd
204
102
Tools and Techniques
• The following are the tools and techniques used business metrics and acceptance
criteria:
01
Behaviour‐driven Development
02
Definition of Done
03
Story Elaboration
© The Knowledge Academy Ltd
205
Tools and Techniques
1.
Behaviour‐driven Development
• Behaviour‐driven development (BDD) is a way that recommends that the team must
start with understanding how the user will utilise a product (its behaviour), write tests
for that behaviour, and then construct solutions against the tests
• Behaviour‐driven development promotes a discussion between the user or client who
needs to be satisfied with the solution and those who are implementing the solution
• The discussion usually leads to examples of real‐life scenarios that the team utilises to
build a shared understanding
• This way continues test‐driven development, which recommends that writing tests first
create better products with fewer defects
© The Knowledge Academy Ltd
206
103
Tools and Techniques
(Continued)
• While this technique is popular in adaptive approaches, it can be applied in any life cycle
approach
• The behaviour‐driven development approach incorporates a usually accepted syntax to
write acceptance criteria for user stories, the given‐when‐then format
• The given‐when‐then format assures that the business stakeholders consider the user’s
preconditions in the product, the triggers, and how the product should react in these
conditions
• Acceptance criteria are usually written as “Given , when , then .” Alternatively, any
format can be utilised for acceptance criteria
© The Knowledge Academy Ltd
207
Tools and Techniques
(Continued)
• The criteria incorporate the preconditions and information important to test the criteria,
the function being tested, and the expected post‐conditions or results after the function
is performed
© The Knowledge Academy Ltd
208
104
Tools and Techniques
2.
Definition of Done
• The (DoD) definition of done is the series of conditions that the whole team agrees to
finish before an item is considered adequately developed to be accepted by the
business stakeholders
• The definition of done for the user story or iteration assists the project team know that
the work is finished to move on to the next user story or iteration
• Once the item meets the definition of done criteria, it is marked properly in any
planning tools, like project plans, requirements management tools, or Kanban boards.
Definitions of done can be created at various levels of detail
© The Knowledge Academy Ltd
209
Tools and Techniques
(Continued)
• They can be closely related to the acceptance criteria, incorporating acceptance criteria
in the definition of done
• They are usually defined at the user story level, the iteration level, the release level, and
the product level. The definition of done might incorporate items like:
o The acceptance criteria are met
o Development, test, as well as defect standards, are conformed to
o High‐level non‐functional and usability requirements are met
© The Knowledge Academy Ltd
210
105
Tools and Techniques
3.
Story Elaboration
• Story elaboration is when user stories are supplemented with extra information from
discussions with business stakeholders until they are adequately detailed for product
development to start work
• In adaptive approaches, user stories are usually written at a higher level of detail than
functional and non‐functional requirements, so story elaboration is utilised to add the
additional details for each story so that development teams have sufficient information
to build the solution
• Adaptive life cycles explicitly describe acceptance criteria with concrete examples as
part of the elaboration of a user story
© The Knowledge Academy Ltd
211
Tools and Techniques
(Continued)
• Together, these details set a mutual contract between business stakeholders and those
accountable for developing the solution regarding what is required and how to know
that the requirement has been met
• Story elaboration is primarily utilised in adaptive methodologies because too much
information about a user story early in the project can hinder the development team’s
capability to negotiate priorities with the business and adapt to variations in the
requirements
© The Knowledge Academy Ltd
212
106
Tools and Techniques
(Continued)
• Design information and client decisions are only added to the user story “just in time”
for the development to work on the user story
• The Story elaboration can take the form of further discussions or writing narratives
around the user story, making design decisions, drafting wireframes or other analysis
models, writing acceptance criteria, and documenting business issues, rules,
constraints, and dependencies
© The Knowledge Academy Ltd
213
Outputs
Acceptance Criteria
• Acceptance criteria are concrete and demonstrable conditions about the item that need
to be met for the business stakeholders or clients to accept the item
• This output can take lists of acceptance criteria for each user story in an adaptive
approach or a list of higher‐level acceptance criteria for a release or solution in a
predictive approach
• Regardless of the level at which they are defined, the acceptance criteria must align
with the requirements and other product information because acceptance testing or
assessment of the solution will be on the basis of the acceptance criteria
© The Knowledge Academy Ltd
214
107
Domain 3
Analysis
© The Knowledge Academy Ltd
215
Outlines of Domain 3
• Module 1: Determining Analysis
Approach
• Module 6: Validate Requirements
• Module 2: Create Analyse Model
• Module 7: Prioritise Requirements
and other Product Information
• Module 3: Define and Elaborate
Requirements
• Module 8: Identify and Analyse
Product Risks
• Module 4: Define Acceptance
Criteria
• Module 9: Assess Product Design
Options
• Module 5: Verify Requirements
© The Knowledge Academy Ltd
216
108
Module 1: Determine Analysis Approach
© The Knowledge Academy Ltd
217
Key Concepts
• The analysis is the process of examining, synthesising, breaking down, and clarifying
information to further understand, complete, and improve it
• An analysis is one of the basic activities performed on the project, program, or portfolio
and typically warrants the commitment of a significant amount of effort
• Beyond analysing, documenting and modelling product information, analysis completes
the set of product information by assuring that it is accurate, adheres to standards, can
be traced to objectives, has inherent risk identified, and can be turned into the product
design
© The Knowledge Academy Ltd
218
109
Introduction
• The Determine Analysis Approach is the process of thinking ahead regarding how the
analysis will be done, including what will be analysed, which models will be most useful
to produce, and how specifications and other product information will be checked,
validated, and prioritised
• This process supports a shared understanding of the business analysis work to be done
to develop the solution. Determining the analysis approach should contain:
o When and how models will be built and analysed, which models are suitable, which
modelling language to use, which stakeholders will be using and reviewing, and how
detailed the models should be
o When requirements definition as well as elaboration will happen and the level of
depth that is suitable for the requirements
© The Knowledge Academy Ltd
219
Introduction
(Continued)
o An approach for defining the acceptance criteria that determine when and what
level of acceptance criteria to capture
o An approach for verification for understanding who will be included in verifying
requirements, when verification and how frequently, and how best to make sure
that requirements are well written, known, and compliant with any standards
o How to confirm requirements for understanding what information is used for
validation and who should be included in making sure that the requirements achieve
the business goals and objectives
© The Knowledge Academy Ltd
220
110
Introduction
(Continued)
o A prioritisation approach early in the project, program, or portfolio to make sure
that stakeholders have correct expectations regarding how priorities will be defined
and who has the authority for deciding priorities
o An approach for identifying and managing risks to make sure that important risks are
not overlooked throughout analysis activities
o An approach for evaluating product design early so that the level, as well as the
timing of design work, are accepted
© The Knowledge Academy Ltd
221
Inputs
Elicitation Approach
• The elicitation approach defines how elicitation will be done, consisting of the elicitation
activities that will be conducted
• Business analysis teams use the elicitation approach as a starting point to determine
some aspects of the analysis approach
• The planned elicitation techniques and their outputs might influence which analysis
techniques are applicable
• The individual elicitation activities timing will affect when related analysis activities
happen. The timing of stakeholder involvement in elicitation activities will influence the
timing of analysis on the basis of when elicitation outputs will be ready
© The Knowledge Academy Ltd
222
111
Inputs
Product Scope
• Product scope is specified as the features and functions that characterise a solution. The
boundaries are defined by the product scope within which analysis takes place
Situation Statement
• The situation statement gives an objective statement regarding the problem or
opportunity that the business is looking to address, along with the effect as well as
impact the situation is having on the organisation
• It gives the context regarding the problems or opportunities being analysed for helping
to define what information will require to be analysed and how it might require to be
analysed
© The Knowledge Academy Ltd
223
Inputs
(Continued)
• Different types of information business analysts are confronted with and the situation
statement helps separate irrelevant information that might interfere with proper
analysis
© The Knowledge Academy Ltd
224
112
Inputs
Traceability and Monitoring Approach
• The traceability and monitoring approach describes the traceability and change
management processes for the project, program, portfolio, or product
• One of the components of that approach is how the requirements, models, and other
product information relate to one another, which is an important input to choose
analysis techniques that support creating models, identifying requirements from the
models, and using the models together
© The Knowledge Academy Ltd
225
Tools and Techniques
Brainstorming
• Brainstorming is a technique used for identifying a
list of ideas within a short period of time
• Brainstorming is helpful to identify analysis tools
and techniques, while determining the analysis
approach including ones that might be outside a
typical tool set of business analyst
© The Knowledge Academy Ltd
226
113
Tools and Techniques
Document Analysis
• This is an elicitation technique utilised to analyse the existing documentation for
identifying appropriate product information
• Document analysis can help in defining which existing models in the organisation could
be used as a starting point for analysis, thereby affecting which analysis activities require
to be done and how long they will take
© The Knowledge Academy Ltd
227
Tools and Techniques
Retrospectives and Lessons Learned
• Retrospectives and lessons learned can use past experience to plan for future work.
Retrospectives and lessons learned can leverage past analysis experiences to plan for
future analysis work while determining an analysis approach
• Review what worked and what may require improvement in a past similar situation
while defining the analysis approach
• Retrospectives and lessons learned, combined with experience and expert judgment,
are the basis for tailoring the analysis approach for fitting the requirements of the
portfolio, program, or project and organisation
© The Knowledge Academy Ltd
228
114
Outputs
Analysis Approach
• The analysis approach defines how the analysis will be done; how to verify, validate, and
prioritise requirements and other product information; how risks will be identified as
well as analysed; how design options will be assessed; and which techniques and
templates are expected to be used for performing any analysis
• The analysis approach contains which requirements attributes require to be captured
and how the requirements architecture influences analysing models
• Moreover, it defines what other information or models from the organisation might be
used throughout the analysis. This output will likely be updated during the course of the
project, program, or portfolio
© The Knowledge Academy Ltd
229
Module 2: Create and Analyse Model
© The Knowledge Academy Ltd
230
115
Introduction
• Create and analyse a model is the process of creating structured representation, like
tables, diagrams, or structured text, of any product information to promote further
analysis by uncovering extraneous information or by identifying information gaps
• The main benefit of this process is that it assists in conveying information in an organised
manner that will provide clarity and helps to attain completeness and correctness
• Models are essential inputs for business analysis activities that transpire outside of the
Create and Analyse Models process, involving:
o Elaborating and defining requirements
o Building a shared understanding of the information
© The Knowledge Academy Ltd
231
Introduction
(Continued)
o Mapping the dependencies and relationships within and across programs, portfolios, and
projects
o Discovering information gaps that need additional elicitation
o Identifying stakeholders who were not previously included
o Promoting stakeholder understanding of the information during review or elicitation
© The Knowledge Academy Ltd
232
116
Introduction
(Continued)
o Assessing capability gaps among the current and future states of a product
o Examining changes to identify which areas of a product are impacted
o Prioritising product information or projects in a portfolio
o Estimating business analysis work
o Providing a business perspective on architectural designs
© The Knowledge Academy Ltd
233
Introduction
• The models are organised into the following categories:
Rule Models
Scope Models
2
1
4
3
Process Models
© The Knowledge Academy Ltd
Interface Models
5
Data Models
234
117
Inputs
• The following are the inputs required for Create and Analyse Model
1
Analysis Approach
2
Inputs
3
Confirmed Elicitation Results
Requirement and other Product Information
© The Knowledge Academy Ltd
235
Inputs
1.
Analysis Approach
• The analysis approach, which defines the way to conduct analysis, comprises a list of
candidate models to be created
• New model types may require creation as the models are analysed, and the analysis
approach might require updating
• The analysis approach also explains the required architecture that describes which
models are most likely to correlate to one another for modelling elaboration
© The Knowledge Academy Ltd
236
118
Inputs
2.
Confirmed Elicitation Results
• Confirmed elicitation results imply that the product team has reached a common
understanding of the elicitation results and agrees on the accuracy of the information
elicited
• Confirmed elicitation results involve requirements, notes, and other outputs from
completed elicitation activities
• These results comprise the information that is required to create first‐draft models
• As the models are created and analysed for gaps, the business analyst may find
additional questions about processes, scope, data, rules, or interfaces that will require
additional elicitation
© The Knowledge Academy Ltd
237
Inputs
3.
Requirement and other Product Information
• Requirements and other product information comprise all information regarding a
solution and are the culmination of results from elicitation and analysis activities
• The subset of this information that is important as input is any previously defined
acceptance criteria, requirements, and other analysis models
• As the work progresses, the volume of requirements along with the other product
information will be refined or grow, by providing additional context to create new models
or analyse existing ones
© The Knowledge Academy Ltd
238
119
Tools and Techniques
Context Diagram
• It is a scope model that presents all the direct system and human interfaces to systems
within a solution
• A context diagram represents the in‐scope systems and any outputs or input involving
the actors or systems providing or receiving them
© The Knowledge Academy Ltd
239
Tools and Techniques
Data Dictionary
• A data dictionary is a data model that classifies the data fields and attributes of those
fields for a data object
• The data fields are extra details for the data objects in an entity‐relationship diagram
• The attributes define information regarding the fields involving business rules enforced
by data
• Data dictionaries are usually created after other data models have been utilised to
identify the data objects and when those objects require more details specified
© The Knowledge Academy Ltd
240
120
Tools and Techniques
(Continued)
• Data dictionaries may be pulled from existing systems as a register of complete data in
the system and utilised as an input for system enhancements
• They are generally created in conjunction with defining the requirements and
acceptance criteria
ID
Business Data Object
Field Name
Example
Attribute 1: Data
Type
BD0001
Business Object Name 1
Field Name 1
Alphanumeric
BD0002
Business Object Name 2
Field Name 2
Graphic
BD0003
Business Object Name 3
Field Name 3
Integer
Example
Attribute 2: Data
Type
© The Knowledge Academy Ltd
241
Tools and Techniques
Data Flow Diagram
• It is a data model used to represent data movement between data stores, external
entities, and processes
• Data flow diagrams are normally built during analysis
• Entity‐relationship diagrams, ecosystem maps, and process flows are normally built first
to identify the data objects, systems, and processes to present in a data flow diagram
© The Knowledge Academy Ltd
242
121
Tools and Techniques
(Continued)
• The given diagram presents a sample format of a data flow diagram
Data Store
Data
Process
Step 1
Data
Process
Step 2
Data
Data
External
Entity
Data Store
Data
Data
Data
Process
Step 3
Process
Step 4
Process
Step 5
Data
Data
External
Entity
Data
External
Entity
© The Knowledge Academy Ltd
243
Tools and Techniques
Decision Tree and Decision Table
• A decision tree and decision table are rule models that present a series of decisions and
the outcomes lead by the decisions
• Decision trees and tables are often utilised to model business rules
• The two decision models are utilised in different ways, and both may be required
• Decision trees visually represent the flow of decisions and choices that lead to an
outcome and explain ordered decisions
• Decision tables help assure that the business analyst has considered every possible
combination of decision scenarios and related outcomes
© The Knowledge Academy Ltd
244
122
Tools and Techniques
Ecosystem Map
• It is a scope model that presents all the relevant systems, the relationships among
systems, and optionally, any data objects passed among them
• The systems are logical systems; hence, they might not match physical systems in
architectural diagrams
• Ecosystem maps are most helpful when they are created at the start of projects to
understand all the systems that may impact or affect the in‐scope systems
• Ecosystem maps can be created for programs or portfolios to assist in identifying
potential dependencies between projects
© The Knowledge Academy Ltd
245
Tools and Techniques
(Continued)
• The ecosystem map enables the business analyst to see possible data requirements or
interface requirements for systems directly interfacing to the solution and those up or
downstream from the solution
© The Knowledge Academy Ltd
246
123
Tools and Techniques
Entity Relationship Diagram
• An entity‐relationship diagram (ERD), also known as a business data diagram, is a data
model that represents the business data pieces or objects of information of interest in a
product and the cardinality relationship among those objects
• Cardinality is the number of times that an entity occurs in relationship to the other entity
in the relationship and whether the relationship is optional or required
• The entity‐relationship diagram assists in identifying the data that are created in,
consumed by, or output from a system
• When utilised alongside process models, ERDs can be utilised to model the data of
importance from a process perspective
© The Knowledge Academy Ltd
247
Tools and Techniques
Event List
• An event list is a scope model that represents any external events that trigger solution
behaviour
• Event lists assist in defining the in‐scope events that the solution has to handle or react
to
• An event response table is a related model that extends the event list to define the
response of the system to any event triggers
• Event lists are created early to assure that the scope of work is defined and might be
updated as work continues and new events are identified
• Event response tables are created to assist in identifying likely use cases, system flows or
user stories
© The Knowledge Academy Ltd
248
124
Tools and Techniques
Feature Model
• A feature model is a scope model that visually describes all the features of a solution
arranged in a hierarchical or tree structure
• Most projects have featured at differing levels; the top‐level features are known as Level
1 (L1) features, followed by Level 2 (L2) features, and so on
• Feature models are useful to show the way in which features are grouped and which
features are sub‐features of other ones
• Feature models are helpful because they can easily display various features across
different levels on a single page, representing a whole solution’s feature set
© The Knowledge Academy Ltd
249
Tools and Techniques
Goal Model and Business Objectives Model
• A goal model and business objectives model are scope models that organise and reflect
the goals and business objectives in relation to other product information
o Goal models typically show the stakeholder goals for a solution, with any indicated
supporting or conflicting goal relationships
o Business objectives models correlate the business objectives, business problems, and
top‐level features
• Goal models and business objectives models are usually created at the commencement
of a new project or program or earlier to assist in prioritising programs and projects
within a portfolio. They can be created at any point for prioritisation purposes
© The Knowledge Academy Ltd
250
125
Tools and Techniques
Modelling Elaboration
• Modelling elaboration is a technique that utilises the collection of models to further
identify inconsistencies, gaps, or redundancies in the product information
o Traceability matrix: It is a table that traces or connects links between items. Generally,
business analysts utilise traceability matrices to trace requirements forward to code or
other development artefacts or test cases or backwards to features and business
objectives
o Interaction matrix: An interaction matrix is a lightweight version of a traceability matrix
that is utilised to determine whether requirements are adequately detailed or if any
entities are missing
© The Knowledge Academy Ltd
251
Tools and Techniques
(Continued)
• The key difference between the two types of traceability matrices is that an interaction
matrix describes a specific point in time. In an interaction matrix, the rows are one type
of product information, usually in the form of user stories, use cases, or process flows
o CRUD matrix: CRUD, described as create (C), read (R), update (U), and delete (D),
describes the operations that can be applied to objects or data. CRUD matrices represent
who or what has permission to perform each of the CRUD operations on elements, like
data or user interface screens
© The Knowledge Academy Ltd
252
126
Tools and Techniques
Organisational Charts
• An organisational chart is a scope model that explains the reporting structure within an
organisation or a part of an organisation
• Organisational charts utilised during analysis may differ from those utilised in
stakeholder analysis
• An organisational chart is utilised to identify who might use or be affected by a solution,
not necessarily just those who were working closely with the program, portfolio, or
project
• For analysis purposes, org charts might explain departments, their roles within
departments, or individuals in the reporting structure
© The Knowledge Academy Ltd
253
Tools and Techniques
Process Flows
• Process flows are utilised to visually document the tasks or steps that people perform in
their jobs or when they interact with a solution
• Usually, process flows describe people's steps, although they may define system steps
and could be called system flows
• Process flows are also known as process maps, swim lane diagrams, process diagrams, or
process flow charts
• Process flows can be organised into various levels, where a Level 1 (L1) process flow
would show a complete end‐to‐end process at a high level in seven to ten steps
• The steps in an L1 process flow are decomposed into the next level of processes that the
user would execute and represented as Level 2 (L2) process flows
© The Knowledge Academy Ltd
254
127
Tools and Techniques
Prototypes, Wireframes, and Display‐action‐response Models
• Prototypes, wireframes, and display‐action‐response models are all interface models
• A prototype is a description of the anticipated solution before it is built. Prototypes can
be high fidelity, like an interactive user interface or low fidelity, like a sketch of a screen
layout
• A wireframe is a kind of prototype, particularly a mock‐up of a user interface design,
utilised to explain what a screen should look like. It can be low fidelity, like a sketch, or
high fidelity, like an actual representation of the final user interface
© The Knowledge Academy Ltd
255
Tools and Techniques
(Continued)
• A display‐action‐response model utilises a tabular format to define page elements and
the functions attached to each. A display‐action‐response model is always utilised with a
prototype or wireframe to connect the user interface component requirements to a
visual representation
© The Knowledge Academy Ltd
256
128
Tools and Techniques
Report Table
• A report table is an interface model that defines detailed requirements for a single
report
• Report tables include information regarding the report as a whole, like the decisions
made from the report or report name, and field‐level information, like which data fields
are displayed and any calculations
• A report table usually accompanies a report prototype to present implementation teams
what the report should look like
© The Knowledge Academy Ltd
257
Tools and Techniques
State Table and State Diagram
• The state table and state diagram are data models that present the valid states of an
object and any permitted transitions among those states
• Objects can be business data items or any piece of information of interest while
analysing a solution
• Both models explain all the states within a solution that a single object can hold and the
way in which the object transitions between states
• State tables model all states as both a column and a row in a table that enables a
business analyst to systematically consider all potential state transitions to determine if
the transition should be enabled or cannot be transitioned from other states
© The Knowledge Academy Ltd
258
129
Tools and Techniques
(Continued)
• In contrast, state diagrams visually depict the states and transitions but only show valid
transitions for the object
© The Knowledge Academy Ltd
259
Tools and Techniques
System Interface Table
• A system interface table is an interface model that records all the detailed level
requirements for a single system interface
• System interface tables are created for all systems that interfaces to the solution system
• System interface tables involve information like the data fields passed from one system
to another, the frequency and volume of the data passed, and any validation rules
required to assure that the data are passed and stored accurately
© The Knowledge Academy Ltd
260
130
Tools and Techniques
Use Case Diagram
• A use case diagram is a scope model that presents all the in‐scope use cases for a
solution
• Creating use case diagrams includes identifying a list of the solution's users and the
possible situations of how each user will utilise the solution
• The use case diagram relates the users to appropriate use cases and identifies which
ones are in or out of scope for a given solution
© The Knowledge Academy Ltd
261
Tools and Techniques
User Interface Flow
• A user interface flow is an interface model that presents specific user interfaces and
generally used screens within a functional design and plots how to navigate them
• They can accompany process flows or utilise cases to visually show the users’
interactions with the system for a scenario
• User interface flows are usually created after process flows and utilise cases to assure
that the navigation of the user interface in the system makes sense and is correct
© The Knowledge Academy Ltd
262
131
Output
Analysis Models
• Analysis models are product information's visual representations
• The analysis models might be fully completed or draft models
• They might be high‐fidelity, semantically accurate representations or low‐fidelity
sketches
• Analysis models indicate the total sum of all the models created, even though they may
not be created simultaneously
• Analysis models show the solution from various facets and enable the business analyst to
identify gaps in the requirements or models
© The Knowledge Academy Ltd
263
Module 3: Define and Elaborate
Requirements
© The Knowledge Academy Ltd
264
132
Introduction
• Define and elaborate requirements is the process and another kind of product
information at the suitable level of format, details, and level of formality needed for
various audiences
• The key benefits of this process are that it
o Assists in clarifying details regarding the product information so the team can work
from it effectively
o Stores the product information in a way that can be accessed and processed by every
stakeholder
© The Knowledge Academy Ltd
265
Introduction
• Defining and elaborating requirements includes determining all types of product
information, not just requirements. This product information commonly consists of the
following:
o Assumptions: Any factors regarding the business problems, objectives, design,
requirements, or solution that are considered true without demonstration or proof.
Assumptions could become false anytime, so they need to be tracked to
accommodate the effect of disproving them. Assumptions might be proven true in
case they are no longer assumptions and can be removed from the list
o Constraints: Constraints involves the limiting factors that affect the execution of a
program, portfolio, project, or process. In business analysis, constraints are factors
that impact the development or implementation of the solution. Business rules are a
kind of constraint
© The Knowledge Academy Ltd
266
133
Introduction
(Continued)
o Dependencies: Any product information that requirements are supported by, contingent
on, or controlled by
o Issues: Topics under discussion or in question regarding the requirements or other
product information. Issues are documented and tracked through their resolution, which
is usually needed before requirements are complete
o Product risks: If any uncertain conditions or events that, if they transpire, have positive
or negative effects on the product. Risk analysis activities may be performed in
conjunction with this process
© The Knowledge Academy Ltd
267
Inputs
• The following are the inputs required to define and elaborate requirements
1
3
2
Analysis
Approach
4
Stakeholders
Engagement &
Communication
Approach
Confirmed
Elicitation
Results
Analysis
Models
© The Knowledge Academy Ltd
5
Relationships &
Dependencies
268
134
Inputs
1.
Analysis Approach
• The analysis approach describes how the analysis will be performed for the program,
portfolio, or project
• The analysis approach involves deciding the requirements to be elaborated for the
project life cycle and the way the requirements and other product information will be
stored
• It also defines the requirements attributes that require to be captured during the Define
and Elaborate Requirements process
© The Knowledge Academy Ltd
269
Inputs
2.
Analysis Models
• Analysis models are the cumulative set of final models or drafts produced by the
iterative analysis process
• The analysis models are utilised to derive and elaborate the requirements by assisting in
identifying requirements at any level and by finding redundancies, gaps, and errors in the
requirements
• Moreover, some analysis models assist in defining the attributes of requirements
• Each analysis model can help to derive requirements in different ways
© The Knowledge Academy Ltd
270
135
Inputs
3.
Confirmed Elicitation Results
• Confirmed elicitation results involve ideas of requirements, notes, and other outputs
from the elicitation conducted
• Confirmed elicitation results imply that the product team has reached a common
understanding regarding the elicitation results and agrees to the correctness of the
information elicited
• These results are a common starting point for identifying draft requirements because
several were likely described by subject matter experts (SMEs) or found in elicitation
source materials throughout the elicitation activities
© The Knowledge Academy Ltd
271
Inputs
4.
Relationships & Dependencies
• Relationships and dependencies describe the links between requirements
• Relationships can be a parent to child, as requirements are progressively elaborated from
a high level to a low level of detail, or they can be dependency relationships like
implementation, value or benefit
• However, relationships and dependencies assist in identifying requirements or elaborate
attributes; a business analyst may identify additional relationships and dependencies
during this process and require to perform the process concurrently
© The Knowledge Academy Ltd
272
136
Inputs
5.
Stakeholders Engagement & Communication Approach
• The stakeholder engagement and communication approach summarises each agreement
for governing the way in which stakeholders will be engaged and communicated across
the project, portfolio, or program
• This approach describes who will consume the requirements, the proposed mechanism
of communication with those stakeholders, and the plan to structure and store the
requirements
• The approach supports effective interaction of the business analyst with stakeholders
because stakeholder expectations related to requirements and communication are
considered and followed; however, doing so usually requires elicitation to be performed
again
© The Knowledge Academy Ltd
273
Tools and Techniques
• The following are the tools and techniques required for defining and elaborating
requirements
Business Rules
Catalogue
1.
Product Backlog
7.
© The Knowledge Academy Ltd
Story Slicing
2.
Definition of
Ready
Requirements
Management Tools
4.
8.
Use Case
3. Geography
Glossary
5.
Story Elaboration
6.
9. Geography
User Story
274
137
Tools and Techniques
Business Rules Catalogue
• A business rules catalogue, a rule model, is a table of business rules and associated
attributes
• Business rules are not procedures or processes; instead, they define how to support or
constrain behaviours within its operations
• Business rules are essential to understand because they are required to be enforced or
implemented by the solution
• Business stakeholders may often desire to change business rules to support business
operations, so business rules justify creating a highly configurable design
© The Knowledge Academy Ltd
275
Tools and Techniques
Definition of Ready
• It is a series of conditions that the whole team agrees to complete prior to a user story is
considered adequately understood so that work can begin to construct it
• The definition of ready assists the project team know that the user story is adequately
elaborated and ready to be brought into a design, iteration, constructed, and delivered
© The Knowledge Academy Ltd
276
138
Tools and Techniques
Glossary
• The definition of terms and acronyms about a product is involved in a glossary
• Glossaries involve terms that might be unfamiliar to an organisation and terms that an
organisation defines uniquely from its industry
• A glossary assures that the entire team is aligned on the way specific terms will be
utilised, any synonymous terms, and what several acronyms mean
• When defining and elaborating requirements, the business analyst ensures that all
requirements utilise terminology as defined in the glossary and maintains the glossary
up to date as new information is identified
• Product teams may decide to develop one glossary shared across the whole portfolio,
program, or project
© The Knowledge Academy Ltd
277
Tools and Techniques
Product Backlog
• It is the list of all product backlog items, usually user stories, features, or requirements,
that must be delivered for a solution
• Generally, the items in a backlog are written as user stories, defining the functionality
that the business or customer desires to view in the final product
• These items can be requirements for the solution to be built and any defects or issues
that need to be resolved from previous iterations
• Projects that utilise adaptive approaches use the product backlog as part of the
requirements package
© The Knowledge Academy Ltd
278
139
Tools and Techniques
(Continued)
• The product backlog needs to be repeatedly refined when new backlog items are added
• The acronym DEEP defines the characteristics that a product backlog requires to
demonstrate to be considered well refined
• DEEP stands for:
o Detailed appropriately
o Estimated
o Emergent
o Prioritised
© The Knowledge Academy Ltd
279
Tools and Techniques
Requirements Management Tools
• A requirements management tool permits requirements and other product information
to be stored and captured in a repository
• When defining and elaborating requirements, the requirements are usually stored in a
requirements management tool, consisting of status, known attribute values, and related
models
• A requirements management tool may serve as the repository for the contents of a
requirements package, depending on the project life cycle approach
© The Knowledge Academy Ltd
280
140
Tools and Techniques
Story Elaboration
• Story elaboration is the process through which user stories are further detailed with
additional information until they are ready for development
• Story elaboration is called backlog refinement. In adaptive approaches, user stories are
at a higher level of detail than non‐functional and functional requirements
• Story elaboration is the technique utilised to add additional details to each story before
constructing the solution
• User stories are usually treated as a promise to discuss the details instead of rigorous
requirement statements
© The Knowledge Academy Ltd
281
Tools and Techniques
Story Slicing
• Story slicing is a technique utilised to split user stories or epics from a higher to a lower
level
• A user story, epic, or requirement could be split differently, involving by type of interface,
user or functionality, persona, data, constraints, business rules, or any combination
thereof
• Whichever mechanism is utilised to decide the way to slice the user stories, the slices are
then prioritised by the value that each slice delivers
• In predictive approaches, creating various scenarios from a broad requirement is similar
to story slicing
© The Knowledge Academy Ltd
282
141
Tools and Techniques
Use Case
• A use case is a process model that utilises a textual narrative to define the system‐user
interactions to successfully achieve an objective
• The goal represents what the primary actor is trying to achieve in the use case and
normally is part of the use case name
• Each use case comprises a normal flow, which is the most common situation of
interactions among the system and user, and alternative and exception flow, where the
scenario diverges from the normal flow
• This model is commonly utilised to identify and elaborate requirements, particularly
when moving from business requirements to stakeholder requirements or solution
requirements
© The Knowledge Academy Ltd
283
Tools and Techniques
User Story
• User stories are a process to document stakeholder requirements from the user's point
of view, focusing on the value or advantage attained by the user with the completion of
that story
• User stories can be utilised to map requirements or acceptance criteria back to process
models that show overall business user tasks
• In adaptive approaches, user stories are usually the method utilised to represent
requirements
• A user story may comprise many requirements. Acceptance criteria usually capture more
details about the users' needs
© The Knowledge Academy Ltd
284
142
Tools and Techniques
(Continued)
• User Story and Acceptance Criteria Sample Format
User Story: <Name> <User Story ID>
User Story
Acceptance Criteria
As an <actor>, I want to be able to
<function>, so that I can <business reason>
Given <prediction(s)>, when <action>, then
<post conditions>
© The Knowledge Academy Ltd
285
Output
Requirements and Other Product Information
• The output of Define and Elaborate Requirements are the requirements themselves
• These requirements can be of any kind: business, stakeholder, transition or solution
• The requirements can be stored in any repository, like a document, backlog, or
requirements management tool
• Moreover, to requirements, other product information documented as part of this
process involves dependencies, assumptions, constraints, issues, and risks
© The Knowledge Academy Ltd
286
143
Module 4: Define Acceptance Criteria
© The Knowledge Academy Ltd
287
Introduction
• Define Acceptance Criteria is the method of getting agreement as to what would
constitute proof that one or more features of a solution have been developed
successfully
• The main benefit of this process is that it provides complementary insights that can
assist in refining requirements while providing the basis of a shared understanding of
what is to be delivered
• Acceptance criteria are the conditions that require to be met before a solution is
accepted
• They are utilised to measure whether a customer is satisfied with the solution built
© The Knowledge Academy Ltd
288
144
Introduction
(Continued)
• Acceptance criteria create the basis of acceptance tests and are essential in evaluating
the solution during product review sessions, where product owners or business
stakeholders choose whether to accept and release the developed solution
• Determining the acceptance criteria includes reviewing requirements and analysis
models with business stakeholders to identify the way in which business stakeholders
would approve something as done
© The Knowledge Academy Ltd
289
Inputs
Inputs required to Define Acceptance Criteria
© The Knowledge Academy Ltd
01
02
03
Analysis
Approach
Analysis
Model
Requirements and Other
Product Information
04
Solution Evaluation
Approach
290
145
Inputs
1.
Analysis Approach
• The analysis approach is a decision regarding how and when the acceptance criteria will
be described in the project life cycle
• The analysis approach defines how acceptance criteria relate to user requirements,
stories, releases, and solution definitions of acceptance and the level at which they are
written
© The Knowledge Academy Ltd
291
Inputs
2.
Analysis Model
• Analysis models are the culmination of creating and analysing draft or final models
• The models in any state can be utilised to elaborate the requirements or user stories to
identify acceptance criteria
• This iterative derivation process is similar to using analysis models to identify
requirements
• In few cases, the acceptance criteria will be defined in analysis models. Like the business
objectives model, few models can be utilised to define acceptance criteria at the product
level
© The Knowledge Academy Ltd
292
146
Inputs
3.
Requirements and Other Product Information
• Requirements and other product information are a beginning point to define the
acceptance criteria
• This input is helpful, whether it is utilised for writing acceptance criteria based on user
stories, requirements, or business objectives
• Stakeholders utilise this input to decide whether to reject or accept the solution on the
basis of how well it met the requirements
© The Knowledge Academy Ltd
293
Inputs
4.
Solution Evaluation Approach
• The solution evaluation approach describes what types of metrics will be utilised to
measure the performance of a solution
• Acceptance criteria are described to set acceptable ranges on the metrics identified
© The Knowledge Academy Ltd
294
147
Tools and Techniques
Tools and Techniques required to Define Acceptance Criteria
01
02
03
Behaviour‐Driven
Development
Definition of Done
Story Elaboration
© The Knowledge Academy Ltd
295
Tools and Techniques
• Behaviour‐Driven Development
o Behaviour‐driven development (BDD) is an approach that implies that the team must
begin with understanding the way the user will utilise a product, write tests for that
behaviour, and then create solutions against the tests
o Behaviour‐driven development promotes a conversation between the customer or user
who requires to be satisfied with the solution and those who are performing the solution
o The conversation usually leads to instances of real‐life situations that the team uses to
build a shared understanding
o This approach continues test‐driven development, implying that first writing tests will
create better products with fewer defects
© The Knowledge Academy Ltd
296
148
Tools and Techniques
• Definition of Done
o The definition of done (DoD) is a set of conditions that the whole team agrees to
complete before an item is deemed adequately developed to be accepted by the
business stakeholders
o The definition of done for a user story or iteration assists the project team know that the
work is complete to move on to the next user story or iteration
o Once an item satisfies the definition of done criteria, it is marked properly in any
planning tools, such as project plans, requirements management tools, or Kanban boards
© The Knowledge Academy Ltd
297
Tools and Techniques
(Continued)
o The Definition of Done might include items like:
 Development, test, and defect standards are conformed to
 Acceptance criteria are met
 High‐level non‐functional and usability requirements are met
© The Knowledge Academy Ltd
298
149
Tools and Techniques
• Story Elaboration
o It is the process by which user stories are enhanced with additional information from
conversations with business stakeholders until they are adequately detailed for product
development to start work
o In adaptive approaches, user stories are usually written at a higher level of detail than
non‐functional or functional requirements, so story elaboration is the technique utilised
to add the extra details for each story so that development teams have sufficient
information to build the solution
o Adaptive life cycles explicitly describe acceptance criteria with concrete instances as part
of the elaboration of a user story
© The Knowledge Academy Ltd
299
Output
Acceptance Criteria
• Acceptance criteria are accurate and demonstrable conditions about an item that must
be satisfied for the customers or business stakeholders to accept the item
• This output can take the form of lists of acceptance criteria for every user story in an
adaptive approach or maybe a list of higher‐level acceptance criteria for a solution or
release in a predictive approach
• Regardless of the level at which they are described, the acceptance criteria must align
with the requirements and other product information because the evaluation of the
solution or acceptance testing will be based on the acceptance criteria
© The Knowledge Academy Ltd
300
150
Module 5: Verify Requirements
© The Knowledge Academy Ltd
301
Introduction
Verify Requirements is the process of verifying requirements that
are of adequate quality
Key Benefit
• It enhances the possibility that the requirements are stated or understood in a manner
that fulfils the defined standards for the organisation, which allows communication of
the requirements to every interested party and contributes to the final product’s quality
© The Knowledge Academy Ltd
302
151
Introduction
(Continued)
• Verification is the process of examining the requirements and other product information
for errors, conflicts, as well as adherence to quality standards
• Verification also involves evaluating whether requirements and other product
information comply with regulations, specifications, or imposed conditions
• In contrast, validation is the assurance that a product meets the customer's needs and
other identified stakeholders
• In the absence of standards or in addition to them, a measure of quality at a basic level
involves evaluating the information for the 3Cs: correct, complete, and consistent
• Analysis models can also be verified against modelling or syntax standards
© The Knowledge Academy Ltd
303
Inputs
Analysis Approach
• The analysis approach describes the way the analysis will be done for the portfolio,
program, or project
• The analysis approach includes a decision about when verification of the product
information will be done
• It also defines the verification techniques and which, if any, standards must be utilised
© The Knowledge Academy Ltd
304
152
Inputs
Business Analysis Organisational Standards
• Business analysis organisational standards define any expected quality characteristics,
syntax rules, formatting rules, and requirements structure imposed by the organisation
on every business analysis deliverable
• These standards describe what a good requirement or requirements set is and might be
based on industry standards
• For example, quality characteristics involve concise, feasible, measurable, traceable,
testable, unambiguous, consistent, precise, correct, complete, and prioritised
© The Knowledge Academy Ltd
305
Inputs
Compliance or Regulatory Standards
• Compliance or regulatory standards are levied by external organisations, usually for
reasons associated with protecting personal information, security, legal considerations,
or safety reasons
• Generally, they are government or industry regulations. A few standards take the form of
what the documentation for a project should involve, while others may list actual
requirements that the project has to cover in its requirements set
• When utilising external standards as input, the reviewer must ensure that the
requirements or documentation produced fulfils the standards so that the project can
pass an internal or external audit
© The Knowledge Academy Ltd
306
153
Inputs
Requirements and Other Product Information
• Requirements and other product information gathered throughout the portfolio,
program, or project give the information for verification
• The individual performing verification examines the materials utilising the suitable
standards or techniques
• Suppose the reviewer is someone other than the author, the reviewer gives feedback
regarding any changes that should be made to the requirements and other product
information to make the information clearer or better conform to the selected standards
© The Knowledge Academy Ltd
307
Tools and Techniques
1
INVEST
• The term INVEST defines the characteristics that user stories should demonstrate to be
considered “ready” and “good” for development in adaptive approaches
• This is the primary verification technique utilised in adaptive approaches
• INVEST is an acronym for Independent, Negotiable, Valuable, Estimable, Small, and
Testable
© The Knowledge Academy Ltd
308
154
Tools and Techniques
2
Peer Reviews
• Peer reviews include one or more co‐workers reviewing the work finished by the
business analyst
• Generally, the peer who performs the review is another team lead, business analyst, or
quality control team member
• The following are the common types of peer reviews, in order of least to most formal:
o Peer Desk Check: An informal peer review completed by one or various peers at the
same time to look over the materials
© The Knowledge Academy Ltd
309
Tools and Techniques
(Continued)
o Walkthrough: A peer review in which the materials’ author walks the peer reviewers by
the authored information. These reviews are usually held utilising an elicitation
workshop technique
o Inspection: A rigorous and formal form of review in which practitioners close to the work
inspect the work for consistency, completeness, and conformance to external and
internal standards, often referring to a checklist
© The Knowledge Academy Ltd
310
155
Output
Verified Requirements and Other Product Information
• Verified requirements and other product information involve product information
assessed to ensure no errors and addresses the quality standards to which the
information will be held
• Verified requirements are not a guarantee that those requirements address the
requirements of the business
• The requirements also have to be prioritised, validated, and approved
• When requirements and other product information are utilised as inputs into other
processes, the inputs might involve product information that has been verified
© The Knowledge Academy Ltd
311
Module 6: Validate Requirements
© The Knowledge Academy Ltd
312
156
Introduction
• Validate requirements is the process by which it is checked that the requirements fulfil
the goals and objectives of the business
• This process's key benefit is to reduce the risks of missing stakeholder expectations of
delivering the wrong solution
• Validation is the process of assuring that all requirements and other product information
reflect the stakeholders' intention correctly and that each requirement aligns with one
or more business requirements
• While verification assures that the product information meets the required standards
and is properly written, validation assures that an appropriate solution is being made
© The Knowledge Academy Ltd
313
Introduction
(Continued)
• Coming to a common understanding with the business stakeholders that the solution
will address as well as support the goals and objectives of key performance indicators
(KPI) is the main goal of validating the product information
• Validation can be iteratively conducted or on a set of final information all at once
• The requirements as business goals or objectives change may need to be revalidated
and updated to reflect those changes
© The Knowledge Academy Ltd
314
157
Inputs
• The following are the inputs required to validate requirements:
Acceptance Criteria
Analysis Approach
Business Goals and Objectives
Requirements and other Product
Information
© The Knowledge Academy Ltd
315
Inputs
Acceptance Criteria
• Acceptance criteria define conditions that are concrete and demonstrable about an item
that must be satisfied for the customers or business stakeholders to accept the item
• An item can be an iteration, requirement, solution or release. When performing
validation activities, acceptance criteria ensure that all the requirements and other
product information are mapped to acceptance criteria that are agreed upon
• If that is not the case, then the iteration, user story, solution or release is not on track to
be accepted
• Acceptance criteria can be created at various levels, which involves the iteration,
requirement, release, and product levels
© The Knowledge Academy Ltd
316
158
Inputs
(Continued)
• Acceptance criteria can be written at the level of the entire business or product
objectives
• In adaptive approaches, acceptance criteria might be written at the user story level,
where numerous acceptance criteria must be satisfied for the user story to be accepted
• In adaptive approaches, acceptance criteria give a succinct way in order to write the
requirements
© The Knowledge Academy Ltd
317
Inputs
Analysis Approach
• The analysis approach describes how the analysis will be performed for the program,
portfolio, or project
• A decision is involved in the analysis approach about when validation of the product
information will be performed
• In addition, it defines which validation techniques are suitable to use
© The Knowledge Academy Ltd
318
159
Inputs
Business Goals and Objectives
• Business goals and objectives define the business's results, expecting a program,
portfolio, or project to deliver
• Validation includes making sure that all requirements trace back to the business goals
and objectives to build what is proposed will satisfy the stated goals and objectives
© The Knowledge Academy Ltd
319
Inputs
Requirements and Other Product Information
• Requirements and other product information resulting from Define and Elaborate
Requirements and accumulated during the program, portfolio, or project give the
information for validation
• The person by whom validation is performed reviews the materials and either fixes the
problems or gives feedback to the author about any changes that must be made
• Usually, this input will change due to validation because product information or
requirements will be discovered to be missing, incorrect or unnecessary
• Verification and validation can take place iteratively or simultaneously as more
information is required or as levels of formality for both validation and verification
happen
© The Knowledge Academy Ltd
320
160
Tools and Techniques
Delphi
• Delphi is a consensus‐building method, which consolidates anonymous input from SMEs
(Subject Matter Experts) utilising rounds of voting
• During Validate Requirements, each SME gives feedback on whether they find the
requirements sufficient and valid. The team comes together so that they can discuss the
survey outcomes and continues voting until consensus is reached
• This method lessens groupthink or peer pressure in the validation process and avoids
having the team give in to a voice of authority they might disagree with
• Delphi can be used on any other product information or requirements, like features,
acceptance criteria and user stories
© The Knowledge Academy Ltd
321
Tools and Techniques
Goal Model and Business Objectives Model
• The goal and business objectives models define the business objectives the solution that
is meant to accomplish, along with the high‐level features for the solution
• The model can either be helpful for mapping user stories or requirements through
features or other models back to business objectives to make sure that requirements
are in alignment with business objectives
© The Knowledge Academy Ltd
322
161
Tools and Techniques
Traceability Matrix
• A traceability matrix is a grid that permits linkages among objects
• A traceability matrix can be used to trace requirements to other types of requirements
in the hierarchy, for instance, from business requirements to solution requirements
• It can be utilised to trace requirements to downstream items or analysis models
• A traceability matrix is primarily used throughout Validate Requirements to trace the
requirements to analysis models and eventually to the business objectives supported by
each requirement
© The Knowledge Academy Ltd
323
Tools and Techniques
(Continued)
• This analysis makes sure that requirements cover each and every business objective and
that each requirement directly traces back to support a business objective
• Any requirements that cannot be traced back to business objectives are probably not
valid and can be cut from the scope
© The Knowledge Academy Ltd
324
162
Tools and Techniques
Walkthroughs
• These are used to review the requirements with the stakeholders as well as to receive
confirmation that the requirements as stated are valid
• Validated requirements reflect accurately what the stakeholders are asking the
development team to build
• Walkthroughs involve holding a meeting or meetings in order to review the
requirements as a group, to make sure that there is a common comprehension of the
requirements and whether they are necessitated
• Usually, a business analyst will send the requirements to the business stakeholders to
review individually prior to the walkthrough takes place
© The Knowledge Academy Ltd
325
Tools and Techniques
(Continued)
• Walkthroughs can be used to review more than just requirements, involving user stories
and analysis models
• Walkthroughs that are particularly focused on reviewing requirements are usually called
requirements walkthroughs
© The Knowledge Academy Ltd
326
163
Output
Validated Requirements and Other Product Information
• Validated requirements and other product information comprise product information
that the stakeholders agree meets the business goals and objectives
• Validated requirements do not ensure that those same requirements are well written
and address the standards to which the project will be held
• In addition, the requirements have to be prioritised, verified, and approved
• When requirements and other product information are utilised as inputs into other
processes, the inputs might involve product information that has been validated
© The Knowledge Academy Ltd
327
Module 7: Prioritise Requirements and
Other Product Information
© The Knowledge Academy Ltd
328
164
Introduction
• Prioritise requirements, and other Product Information is the process of understanding
the way in which individual pieces of product information attain stakeholder objectives
and utilising that information, along with other agreed‐upon prioritisation factors, to
facilitate ranking of the work
• The main benefit of this process is that it aligns all stakeholders with how the
requirements accomplish the goals and objectives and ascertain how to allocate the
requirements to iterations or releases accordingly
• Prioritising requirements is an essential step in managing product scope
• Prioritisation ascertains what must be worked on first or next so that business goals are
accomplished in an order that best fulfils the organisation's requirements
© The Knowledge Academy Ltd
329
Introduction
(Continued)
• Prioritisation supports the allocation of requirements to iterations or releases for release
planning purposes
• Requirements and other product information, like defects or issues, are prioritised
utilising factors like cost, value, difficulty, risk and requirements
• Prioritising any item at any level usually includes two efforts, and they do not have to be
sequentially ordered
• The first effort is when the subject matter experts, business stakeholders, or product
owners prioritise requirements based on their estimated business value
© The Knowledge Academy Ltd
330
165
Introduction
(Continued)
• The second effort is to understand the project team's views of effort and the risk of each
requirement
• The business analyst promotes the prioritisation discussions and works with the team to
assure that the high‐priority requirements can be completed within program, portfolio,
or project boundaries
© The Knowledge Academy Ltd
331
Inputs
• The following are the Inputs required for Prioritise Requirements and Other Product
Information
1
Analysis
Approach
© The Knowledge Academy Ltd
2
Business Goals
and Objectives
3
4
Change
Request
Relationships
and
Dependencies
5
Requirements &
Other Product
Information
332
166
Inputs
• Analysis Approach
o The analysis approach describes the way in which analysis will be performed for the
program, portfolio, or project
o The analysis approach involves a decision regarding the prioritisation, including
which techniques will be utilised, when prioritisation is performed, and who will
participate in and make prioritisation decisions
© The Knowledge Academy Ltd
333
Inputs
• Business Goals and Objectives
o Business Goals and objectives describe what results in the business is expecting a
program, portfolio, or project to deliver
o The desired outcomes particularised by the business objectives are the main
consideration in prioritising which requirements and related work must be
completed first
o A key purpose of the prioritisation process is to ensure that what the team builds,
whether it meets the business goals and objectives
© The Knowledge Academy Ltd
334
167
Inputs
• Change Request
o Change requests are requests to make a change to a requirement or other
suggestions for changes to the product raised by the project team or business
stakeholders after a list of requirements is baselined
o Change requests are prioritised simultaneously with other work involving any
undeveloped requirements
o Seldom a change request is of higher priority than existing work
o Few change requests may need items to be removed from the scope to
accommodate the change
© The Knowledge Academy Ltd
335
Inputs
(Continued)
o In adaptive approaches, there may not be a formal change request process
o When a stakeholder requests a change, it is usually written in a user story and added to
the backlog
o A new product backlog items are prioritised against the backlog items that are already
present
© The Knowledge Academy Ltd
336
168
Inputs
• Relationships and Dependencies
o Relationships and dependencies describe the links among requirements.
Prioritisation choices can be affected by relationships and dependencies
• Requirements & Other Product Information
o Requirement and other product information involve all the information regarding a
solution and are the culmination of results from elicitation and analysis activities
o The requirements and other product information accumulated throughout the
program, portfolio, or project include the information prioritised
© The Knowledge Academy Ltd
337
Tools and Techniques
Backlog Management
• A product backlog is the record of all the work required to be completed to produce the
solution
• A backlog can include high‐level product information like features or projects managed at
a portfolio or program level
• Backlog management is utilised in adaptive approaches to manage backlog items to be
worked on during a project
© The Knowledge Academy Ltd
338
169
Tools and Techniques
(Continued)
• Backlog management indicates the process by which the owner of the backlog, usually a
product owner, helps to maintain the backlog up to date
• If roles are separate, the business analyst often assist the product owner in refining the
product backlog, which includes adding and removing backlog items, elaborating backlog
items, and reprioritising based on changing requirements or business priorities and
conditions
© The Knowledge Academy Ltd
339
Tools and Techniques
Goal Model and Business Objectives Model
• The goal and business objectives models define the business goals that the solution is
meant to accomplish, along with the high‐level features for the solution
• Each model can be utilised as a tool to assist in prioritising the requirements as per how
much they achieve or support the objectives
• Any requirements that do not relate to and support the business goals can be cut from
the scope or assigned a low priority
• Any remaining in‐scope requirements are measured by how much they assist in
achieving the business objectives
© The Knowledge Academy Ltd
340
170
Tools and Techniques
Iteration Planning
• In adaptive approaches, sprint planning or iteration planning or iteration is the activity
utilised to identify the subset of product backlog items that the product development
team will work on for the current sprint or iteration
• The whole team collaborates just before or at the commencement of the iteration to
choose the backlog items that must be part of an iteration backlog
• Business analysis activities assure that product backlog items are ready to be developed
© The Knowledge Academy Ltd
341
Tools and Techniques
Kanban Board
• A Kanban board is utilised in adaptive approaches to track work in progress by the
project team
• It is a visual representation of which work is in progress, whereas the product backlog is
the prioritised list of every possible work
• The Kanban board presents the steps in a workflow as a project life cycle phases and
work in progress (WIP) limits for each phase
• WIP limits define how many items can be in one workflow step at a time
• These limits maximise the team's productivity by assuring that it never takes on more
work than it can handle
© The Knowledge Academy Ltd
342
171
Tools and Techniques
(Continued)
• The items from the product backlog are pulled by the project team into the kanban
board and move across every workflow step as each step is completed, assuming there is
room in the next workflow step
• This technique also clearly shows what is or is not complete for any given user story
• If bottlenecks emerge, the Kanban board and the WIP limits become input into
prioritisation decisions for work in the product backlog and to manage the progress of
items
© The Knowledge Academy Ltd
343
Tools and Techniques
Prioritisation Schemes
• Prioritisation schemes are different methods used to prioritise components, portfolios,
projects, programs, requirements, features, or any other product information. The
analysis approach identifies which prioritisation schemes the team has agreed to utilise
and when
• The following are some commonly utilised schemes:
© The Knowledge Academy Ltd
01
02
Buy a feature
Delphi
03
Minimum Viable Product
344
172
Tools and Techniques
04
05
MoSCoW
Multivoting
07
08
Time Boxing
Weighted Ranking
06
Purpose Alignment Model
09
Weighted Shortest Job First (WSJF)
© The Knowledge Academy Ltd
345
Tools and Techniques
Traceability Matrix
• The traceability matrix maps requirements backwards to analysis models and business
objectives and forwards to business rules, implementation details, designs, and tests
• For prioritisation purposes, a traceability matrix can be utilised to help prioritise
requirements using the business objectives to which they are traced
• If the business objectives are ranked and quantified accordingly, then the requirements
that trace to the highest‐value goals might be the highest‐ranked requirements
• Any requirements that are not traced to the business objectives are out of scope
© The Knowledge Academy Ltd
346
173
Output
Prioritised Requirements and Other Product Information
• Prioritised requirements and other product information represent requirements and
other product information on which the stakeholders agree; that is important to address
first to achieve the business goals and objectives
• The result of prioritisation may define what work must be completed next, or it might be
a full ordering of all work, with items allocated to releases or iterations
• The prioritisation output can take the form of a backlog ordered by business value and
risk in adaptive approaches or a prioritisation attribute set on every requirement in
predictive approaches
© The Knowledge Academy Ltd
347
Output
(Continued)
• Prioritisation also shows which items are of low priority and might be logical to cut from
scope if change requests come in and are prioritised higher or if the team runs out of
budget or time for a release
• When requirements and other product information are utilised as input into other
processes, they might involve product information that has been prioritised
© The Knowledge Academy Ltd
348
174
Module 8: Identify and Analyse Product
Risks
© The Knowledge Academy Ltd
349
Introduction
• The process of examining and uncovering assumptions and uncertainties that could
negatively or positively affect success in the definition, development, and the expected
results of the solution
• The main of this process is that it supports proactive management of uncertainties in
business analysis activities, and it uncovers and proactively addresses areas of potential
weaknesses and strengths in the product
• The following activities are included in identifying and analysing product risks
Identifying
Product Risks
© The Knowledge Academy Ltd
Performing Qualitative
Risk Analysis
350
175
Introduction
Performing Quantitative
Risk Analysis
Implementing Risk
Responses
Planning Risk Responses
Monitoring Risks
© The Knowledge Academy Ltd
351
Input
• The following are the Inputs required for Identifying and Analysing Product Risks
Analysis
Approach
© The Knowledge Academy Ltd
Business
Goals And
Objectives
Enterprise
Environmental
Factors (EEFS)
Product
Scope
Requirements
and Other
Product
Information
352
176
Input
1.
Analysis Approach
• The analysis approach describes how the analysis will be performed for the program,
portfolio, or project
• The analysis approach includes a decision regarding how to conduct risk analysis,
comprising the details regarding the product risk management process, the risk
categories, and the way in which risks will be documented
© The Knowledge Academy Ltd
353
Input
2.
Business Goals and Objectives
• Business objectives and goals identify what the business expects a program, portfolio, or
project to deliver
• Product risks are evaluated and rated on whether and how much they may affect the
business goals and objectives
• Evaluating assumptions that were made in describing business goals and objectives
might also lead to identifying additional risks
© The Knowledge Academy Ltd
354
177
Input
3.
Enterprise Environmental Factors
• Enterprise Environmental Factors are the conditions that influence, direct, or constrain
the way in which business analysis is conducted
• Analysis of EEFs can uncover factors of product risk, like when a contractual or legal
restriction impacts how business analysis processes are conducted. EEFs also involve
stakeholder risk appetite, which might influence risk responses
4.
Product Scope
• Product scope is described as the features and functions that define a solution
• Product risks are estimated and rated on whether and how they may affect the product
represented by the statement of the product scope
© The Knowledge Academy Ltd
355
Input
5.
Requirements and Other Product Information
• Requirements and other product information involve all the information regarding a
solution and are the result's culmination from elicitation and analysis activities
• Product information can be estimated to identify product risks
• For example, constraints, assessing assumptions, dependencies, and requirements may
assist in uncovering product risk factors
• Product risk responses may trigger additions or modifications to requirements and other
product information
© The Knowledge Academy Ltd
356
178
Tools and Techniques
1.
Elicitation Techniques
• Elicitation techniques are utilised to draw information from sources. Product risks are
uncovered through elicitation; hence, any elicitation techniques can be utilised to
identify and analyse product risks
2.
Process Flows
• Process flows visually document the tasks or steps that individuals perform in their jobs
or interact with a product
• These models may be utilised to identify product risk or possible failure points through
analysing process steps, decision points as well as handoffs between different actors in a
process
© The Knowledge Academy Ltd
357
Tools and Techniques
3.
Product Backlog
• The product backlog is the list of each and every product backlog item, usually user
stories, features, or requirements that are required to be delivered for a solution
• Projects that employ adaptive approaches utilise the product backlog as a part of the
requirements package. When required, tasks known as risk spikes or spikes can be added
to the product backlog to assess risks
• The product backlog's items are ranked in order of business value or significance to the
customer as well as are constantly updated during a product's life cycle or project's
duration
© The Knowledge Academy Ltd
358
179
Tools and Techniques
4.
Risk Burndown Chart
• Burndown charts are utilised for communicating progress over time
• On adaptive projects, risk burndown charts can be utilised to show risk status across
iterations
• The sum of exposures across every product risk is mapped for each iteration. Ideally, the
burndown chart must show a downward slope when connecting the data points to
indicate that product risk exposures are reducing as iterations progress
© The Knowledge Academy Ltd
359
Tools and Techniques
5.
Risk Register
• A risk register is a tool that is used to support the analysis of product risk. Product risks
are logged with corresponding details, which may involve the following:
© The Knowledge Academy Ltd
Risk ID
Risk Description
Date Logged
Risk Owner
Status
Impact Rating
360
180
Tools and Techniques
(Continued)
Probability Rating
Exposure
Trigger
Risk Response
Risk Response Owner
Workaround
© The Knowledge Academy Ltd
361
Output
Product Risk Analysis
• The product risk analysis incorporates the consolidated results from identifying and
analysing product risks. The product risk analysis may involve:
o Identified product risk
o List of possible responses
o Relative rating or priority list of risks
o Warning signs and symptoms
o Risks requiring responses in the near term
o Risks for additional analysis and response
o Trends in qualitative analysis results
o Total risk exposure
o Watch list low priority risk
© The Knowledge Academy Ltd
362
181
Module 9: Assess Product Design Options
© The Knowledge Academy Ltd
363
Introduction
• It is the process of identifying, analysing and comparing solution design options on the
basis of business goals and objectives, predictable costs of implementation, feasibility,
and associated risks and using the assessment results for recommendations regarding
the design options presented
• This process permits informed recommendations of design options. The assessing
product design goes beyond what the product should do and starts concentrating on
making or looking
• There are various options for building a solution, and business analysis is used to
evaluate them
• This process involves understanding which design options are available and analysing
how those designs evolve into a solution
© The Knowledge Academy Ltd
364
182
Introduction
(Continued)
• Each option’s analysis results give relevant information for articulating the options' pros
and cons, risks, and costs. Every option is compared against the others for determining
which option
• Every option is compared against the others for defining which option best achieves the
overall product goals as well as objectives and adheres to limitations, budget, and time
constraints. Designs that are not viable are removed from consideration
• Requirements work is finished in its entirety before design with a predictive life cycle;
hence, design modifications have a much larger impact and tend to be costlier than with
adaptive methods, especially if continued as a result of discoveries made throughout
the product development
© The Knowledge Academy Ltd
365
Inputs
Business Goals and Objectives
• Business goals and objectives determine the business's results expecting a portfolio,
program, or project to deliver
• Designs require to be aimed at accomplishing these goals as well as objectives. Poorly
designed solutions that satisfy the requirements can keep the solution from achieving
the aspired goals as well as objectives
© The Knowledge Academy Ltd
366
183
Inputs
Enterprise and Business Architectures
• Enterprise and business architectures aggregate technology business functions,
locations, organisational structures, and processes
• The architectures are used to make sure that the proposed designs can operate within
the current architectures or for understanding how those architectures might change
with proposed designs. Either architecture might constrain the design options
• Business architectures can help identify design elements that require incorporation for
different regions, users, languages, and organisational customs, as well as any
opportunities for reusing the capabilities
© The Knowledge Academy Ltd
367
Inputs
(Continued)
• In certain cases, a single design might not work for all the components of the business
architecture
• Enterprise architecture can help to identify system or data limitations or reuse
opportunities for consideration while selecting design options
• Some designs may not be feasible with current technologies. Certain design options
might require more resources than the existing architectures can support
© The Knowledge Academy Ltd
368
184
Inputs
Prioritised Requirements and Other Product Information
• Designs are built to reflect how a solution will satisfy the requirements
• Prioritised requirements represent the stakeholders’ agreement about which
requirements need to be addressed first in the solution and represent which
requirements are most important to account for in the designs
• Requirements sometimes contain legitimate design constraints. Some organisations
have certain branding or look‐and‐feel requirements or capability or technical
limitations that lead to design choices or limitations
• However, well‐written requirements avoid unnecessarily constraining or biasing the
design
© The Knowledge Academy Ltd
369
Inputs
(Continued)
• Designs need to be created while considering known risks and should address the
impact of those risks on the design
• Additional risks uncovered during design also need to be analysed
© The Knowledge Academy Ltd
370
185
Tools and Technique
Affinity Diagram
• It displays categories and subcategories of ideas that cluster or having an affinity to one
another
• Affinity diagrams can help identify design options by organising user stories,
requirements or features
• Likewise, design options can be organised in an affinity diagram for grouping the same
designs and aid in deciding while choosing from among different design options
• Moreover, organising design information into categories can facilitate brainstorming
new design ideas
© The Knowledge Academy Ltd
371
Tools and Technique
Brainstorming
• It is an elicitation technique that can identify a list of ideas in a short period.
Brainstorming can be used for identifying design options and any risks associated with
them
Competitive Analysis
• It is a technique for obtaining and analysing information regarding the external
environment of the organisation
• Competitive analysis is used to identify and compare design options to build an
advantage for the product in the marketplace compared to competitors. It is useful for
understanding if a proposed design is far more than what a competitor offers
© The Knowledge Academy Ltd
372
186
Tools and Technique
Focus Groups
• Focus groups bring together prequalified stakeholders as well as subject matter experts
for learning regarding their expectations and attitudes regarding a proposed solution. It
can be used to solicit attitudes and ideas regarding different design options
Product Backlog
• It is the list of all product backlog items, usually user stories, features, or requirements,
that must be delivered for a solution. Product backlog items must be factored into the
design, even if the design is lightweight and not formally documented
• Tasks are added to the product backlog for evaluating complex design options in
adaptive approaches. These tasks are termed as spikes
© The Knowledge Academy Ltd
373
Tools and Technique
Real Options
• It is a decision‐making technique that motivates teams to delay decision making until
the latest possible time
• Delayed decision making gives an opportunity for obtaining as much information as
possible regarding the issue or item under discussion
• When assessing product design options, delaying a recommendation regarding a
possible design gives more information to be discovered and analysed, answering
unknowns and decreasing the number of uncertainties that would be present if the
design choice had been made previously
© The Knowledge Academy Ltd
374
187
Tools and Technique
Vendor Assessment
• Vendors may give the best solution that satisfies the requirements of various projects
• Relevant vendors and their products are evaluated for understanding every solution's
viability, weaknesses, strengths, and risks while assessing product design options
• Performing a vendor assessment entails identifying a set of criteria by which vendors
and their products will be evaluated
• The criteria used for this assessment might be a collection of requirements, features, or
user stories that can be prioritised or weighted
© The Knowledge Academy Ltd
375
Tools and Technique
(Continued)
• Certain criteria that can be used for assessing vendor offerings might be qualitative
criteria
• For example, measures are used for evaluating the experience of working with the
vendor or solution
© The Knowledge Academy Ltd
376
188
Outputs
Viable Product Design Options
• Design options are descriptions of how the solution could be constructed
• Stakeholders have reviewed viable product design options to make sure that they
achieve the business goals as well as objectives are feasible
• It is represented with the pros and cons of every option. Construction of the solution or
component of the solution can start once a design is chosen
© The Knowledge Academy Ltd
377
Domain 4
Traceability and Monitoring
© The Knowledge Academy Ltd
378
189
Outlines of Domain 4
• Module 1: Determining Traceability
and Monitoring
• Module 2: Establishing
Relationships and Dependencies
• Module 3: Select and Approve
Requirements
• Module 4: Manage Changes to
Requirements and other Product
Information
© The Knowledge Academy Ltd
379
Overview
• This knowledge area involves the processes that are utilised to establish relationships
and dependencies among requirements and other product information, assuring that the
requirements are approved and managed and that the impact of changes is assessed
Defining &
Aligning
Initiating
Planning
Determining Traceability
& Monitoring Approach
Executing
Monitoring &
Controlling
Establish Relationships
& Dependencies
Releasing
Manage changes to
Requirements & Other
Product Information
Select & Approve
Requirements
© The Knowledge Academy Ltd
380
190
Key Concepts
• Traceability is the capability of tracking information across the product life cycle by
establishing linkages within objects, which are also called relationships or dependencies
• Traceability is sometimes considered as forward and backward or bidirectional because
requirements are not traced only in one a direction
• Monitoring assures that product information remains correct from the point when
product information has been approved by its implementation
• Monitoring involves managing changes in the product information and ascertaining
suggested actions to maintain the product’s quality
© The Knowledge Academy Ltd
381
Module 1: Determine Traceability and
Monitoring Approach
© The Knowledge Academy Ltd
382
191
Introduction
• Determine Traceability and Monitoring
Approach is the process of considering the
way the traceability will be performed on
the program, portfolio, product or project
and defining the way in which requirements
changes will be managed
• The main benefit is that it sizes the level of
traceability and formality of the
requirements change management process
for the situation properly
© The Knowledge Academy Ltd
383
Introduction
• A properly sized traceability and monitoring approach assures:
A traceability process that reduces the possibility of missing requirements in the final product
A traceability process that is not wasteful and time‐consuming to maintain
A change management process that assures that changes align with the project or business
objectives
A change management process that makes it easy to implement the changes which are
required
A traceability and change management process that aligns to organisational standards fulfils
regulatory requirements and addresses future requirements, giving valuable information
regarding the product over the long term, beyond the current project
© The Knowledge Academy Ltd
384
192
Inputs
• The following are the inputs for determining traceability and monitoring process
Configuration
Management Standards
2
1
Compliance or
Regulatory Standards
3
Product Scope
© The Knowledge Academy Ltd
385
Inputs
1.
Compliance or Regulatory Standards
• Compliance or regulatory standards are an enterprise environmental factor imposed by
external organisations, usually for reasons associated with protecting personal
information, security, safety, or legal considerations
• The tailoring options may be constrained because the traceability and monitoring
approach requires adhering to compliance and regulatory standards
• Compliance and regulatory standards usually require more formal approaches to
traceability and monitoring
© The Knowledge Academy Ltd
386
193
Inputs
2.
Configuration Management Standards
• Configuration management is formally documented templates, processes, and
documentation utilised to apply governance to changes to the solution or subcomponent
under development
• Configuration management makes sure that the product being built adheres to its
approved requirements
• The traceability and monitoring approach must adhere to the configuration management
standards within the organisation
• When such standards are not in place or developed, the team must determine what the
configuration management process will be for all aspects of the project or program,
consisting of the business analysis work
© The Knowledge Academy Ltd
387
Inputs
(Continued)
• Configuration management for business analysis assures that the requirements and
requirements associated with the product information, like traceability matrix, models,
and issues list, are stored where they can be simply accessed by project stakeholders,
safeguarded from loss, and where access to previous versions is available when required
• A business analyst may accomplish these objectives with a configuration management
system (CMS), a wiki platform or a requirements management repository
© The Knowledge Academy Ltd
388
194
Inputs
3.
Product Scope
• The product scope is described as the function and features that define a solution
• The product scope is utilised to understand the level of product complexity used to
discover an appropriate size for the traceability and change management approach
© The Knowledge Academy Ltd
389
Tools and Techniques
Retrospectives and Lessons Learned
• Retrospectives and lessons learned to give past performance information to the product
team to utilise it in enhancing future performance and, ultimately, the end product
• While determining how best to approach traceability and monitoring, product teams can
depend upon gained knowledge and learning to discover which traceability and
monitoring approach to follow
• Retrospectives and lessons learned, coupled with experience and expert judgment, are
the basis for tailoring the traceability and change management processes to fit the
program, portfolio, or project and the organisation's requirements
© The Knowledge Academy Ltd
390
195
Output
Traceability And Monitoring Approach
• The traceability and monitoring approach describes the way in which the traceability and
change management activities will be performed during the program, portfolio, or project
• The traceability elements of the approach involve types of relationships, types of objects
to trace, the level of tracing detail needed, and information regarding where tracing
information will be tracked
• The monitoring elements of the approach involve how decisions are documented and
communicated, how changes are proposed and reviewed, and how changes are made to
existing product information
• Both approaches define the roles and responsibilities and the way in which the
information is stored
© The Knowledge Academy Ltd
391
Module 2: Establish Relationships and
Dependencies
© The Knowledge Academy Ltd
392
196
Introduction
• Establishing Relationships and Dependencies is the method of tracing or settings linkages
between requirements and other product information
• The essential benefits of this process are that it assists in checking that every
requirement adds business value and fulfil the customer's expectations, and it helps in
monitoring and controlling product scope
• The linkages among different elements of the product information assists in doing the
following:
Make sure that product information adds
business value and fulfil
Manage scope
© The Knowledge Academy Ltd
393
Introduction
Minimise the possibility of missing
requirements
Perform impact analysis
Make release decisions
© The Knowledge Academy Ltd
394
197
Introduction
• The following are a few examples of relationships between requirements
o Subsets: A requirement may be a subset of another requirement
o Implementation Dependency: Few requirements are dependent on the
implementation of other requirements before they can be implemented
o Benefits of Value Dependency: Seldom, a requirement's benefits cannot be realised
unless another requirement is implemented first
© The Knowledge Academy Ltd
395
Inputs
• The following are the inputs required for establishing a relationship and dependencies
process
Product Scope
Requirements and Other
Product Information
Traceability and Monitoring
Approach
© The Knowledge Academy Ltd
396
198
Inputs
Product Scope
• The product Scope is described as the function and feature that characterise a solution
• Product information is traced to the function and features that make up the definition of
product scope
• When there are elements of product information that are incapable to trace back to the
functions and features defined in the product scope, the value of involving them should
be questioned
• If it is ascertained that the product information must be included, then the product
scope may require to be re‐evaluated
© The Knowledge Academy Ltd
397
Inputs
Requirements and Other Product Information
• Requirements and other product information involve all information regarding a solution
and are the culmination of results from analysis and elicitation activities
• Relationships and dependencies are established between the requirements and other
product information resulting from analysis and elicitation
© The Knowledge Academy Ltd
398
199
Inputs
Traceability and Monitoring Approach
• The traceability and monitoring approach describes the decisions made by the team
regarding how traceability will be performed on the program, portfolio, or project
• The traceability and monitoring approach may involve details concerning the objects that
will be traced, to what level traceability will be performed, and where relationships will
be maintained or tracked
• As the project, program or portfolio progresses, more objects are created, developing
the opportunities to establish linkages between these objects
© The Knowledge Academy Ltd
399
Tools and Techniques
• The following are the tools and techniques required for establishing a relationship and
dependencies process
Traceability Matrix
Story Slicing
1
5
2
4
3
© The Knowledge Academy Ltd
Feature Model
Requirements
Management Tools
Story Mapping
400
200
Tools and Techniques
Feature Model
• It is a scope model that visually represents each feature of a solution arranged in a
hierarchical or tree structure
• The feature model display relationships between features and which features are sub‐
features of other ones
• The feature model assist teams in establishing and communicating relationships
between different features
© The Knowledge Academy Ltd
401
Tools and Techniques
Requirements
• Requirements management tools enable requirements and other information of the
product to be captured and stored in a repository. These tools usually have the
functionality to:
1
Maintain audit trails and perform version control to help with change management
2
Facilitate review and approval processes by workflow functionality
3
Create visual models and interactive prototypes
© The Knowledge Academy Ltd
402
201
Tools and Techniques
4
Support team collaboration
5
Integrate with office productivity software for simple export and imports
6
Track and report on requirements status
7
Help in performing detailed traceability on the basis of trace links established in the tools
© The Knowledge Academy Ltd
403
Tools and Techniques
Story Mapping
• Story mapping is a technique utilised to sequence user stories on the basis of their
business value and the order in which their users usually perform them so that teams
can reach a shared understanding of what will be built
• Horizontally, the story map presents what will be delivered within an iteration, and
vertically the story map describes higher‐level groupings or categories of the user stories
• User stories may be grouped by various categories like themes, functionality, or
application
• Story mapping can be utilised to establish relationships between user stories to
iterations and the higher‐level categories
© The Knowledge Academy Ltd
404
202
Tools and Techniques
Story Slicing
• It is a technique utilised to split user stories or requirements from a higher to a lower
level
• Story slicing is a medium of establishing relationships between requirements as lower‐
level, or user stories are subsets of higher‐level epics or requirements
Traceability Matrix
• It is a grid that connects product requirements from their origin to the deliverables that
satisfy them
© The Knowledge Academy Ltd
405
Tools and Techniques
(Continued)
• The matrix can support linkages among several different objects, providing a mechanism
for tracking product information through the product and project life cycles
• A traceability matrix can be utilised to establish relationships among product
deliverables, information, and project work to ensure that all relate to business
objectives
• Establishing these linkages manages scope creep by assuring that only appropriate
product information is incorporated into the solution
© The Knowledge Academy Ltd
406
203
Output
Relationships and Dependencies
• Relationships and dependencies are the connections built between objects, like
elements of the product information, project work and deliverables
• Relationships and dependencies are established to ensure that product information adds
business value and satisfies customer expectations, decreases the probability of missing
requirements, manages scope, performs impact analysis, and makes release decisions
© The Knowledge Academy Ltd
407
Module 3: Select and Approve
Requirements
© The Knowledge Academy Ltd
408
204
Introduction
• Selecting and approving requirements facilitates conversations with stakeholders to
negotiate and confirm the requirements that must be included within an iteration,
release, or project
• The key advantage is that it gives the authorisation to consider how as well as when to
build all or part of the solution in order to develop and change the product
• Approving requirements is performed to get an agreement that depicts the
requirements correctly what the product team is being asked to build
• Requirements that are approved set the requirements baseline
• Organisations and projects differ in the way the requirements are approved
© The Knowledge Academy Ltd
409
Introduction
(Continued)
• A few organisations need a formal sign‐off on the
requirements package, like a business
requirements document, in other organisations
or for particular projects, the approval may be
formal, needs approval just verbally
• On adaptive projects, approved requirements
could be represented by the backlog items ready
for development or the iteration planning results,
where decisions on the backlog items’ list to be
addressed in the current or next iteration are
made
© The Knowledge Academy Ltd
410
205
Inputs
• The following are the inputs required for select and approve requirements:
1
Product Scope
2
Relationships and Dependencies
3
Stakeholders Engagements and Communication
Approach
4
Verified Requirements and Other Product
Information
© The Knowledge Academy Ltd
411
Inputs
1.
Product Scope
• Product scope is defined as the characteristics and functions that characterise a solution
• Requirements approval is performed to confirm with stakeholders that are defined
product information is accurate and within the set scope parameters
2.
Relationships and Dependencies
• Relationships and dependencies describe the links between requirements. Relationships
can be the parent to child, as requirements are progressively elaborated from the high
to the low level
• They can also be dependency relationships like implementation, advantage, or value
© The Knowledge Academy Ltd
412
206
Inputs
(Continued)
• Relationships and dependencies may indicate the requirements that may require to be
selected and approved with each other
3.
Stakeholders Engagements and Communication Approach
• The stakeholder engagement and communication approach summarises all the
agreements to govern how stakeholders will be engaged and communicated over the
portfolio, program or project
• It includes the decisions about the roles, responsibilities as well as authority levels
governing the requirements for the approval process
© The Knowledge Academy Ltd
413
Inputs
(Continued)
• The approach identifies the one responsible for analysing, approving, rejecting and
proposing the modifications to requirements
4.
Validated Requirements and Other Product Requirements
• Validated requirements and other product information is product information that the
stakeholders agree to meet the business objectives and goals
• Although verification and validation do not have to be sequenced, the requirements and
supporting product information are normally verified and validated before being
presented to stakeholders for analysis and approval
© The Knowledge Academy Ltd
414
207
Tools and Techniques
• The following are the tools and techniques used in select and approve requirements:
1
Backlog Management
2
Collaborative Games
3
Definition of Ready
4
Delphi
© The Knowledge Academy Ltd
415
Tools and Techniques
(Continued)
© The Knowledge Academy Ltd
5
Facilitated Workshops
6
Force Field Analysis
7
Group decision‐making Techniques
8
Iteration Planning
416
208
Tools and Techniques
(Continued)
9
Prioritisation Schemes
10
Requirements Management Tool
11
Story Mapping
© The Knowledge Academy Ltd
417
Tools and Techniques
1.
Backlog Management
• Backlog management is the technique
utilised in adaptive methods to maintain
the requirements list
• The list is ranked in order of business value
or importance to the client and sized by
the development team to work on the
highest‐value items it can deliver over the
specified duration
• The prioritisation of the backlog can be
interpreted as approval
© The Knowledge Academy Ltd
418
209
Tools and Techniques
2.
Collaborative Games
• Collaborative games are the collection of elicitation techniques that foster innovation,
collaboration, and creativity to achieve the elicitation activity’s goal
• Collaborative games can work through requirements‐related conflicts and assist teams
in working towards consensus on requirements
© The Knowledge Academy Ltd
419
Tools and Techniques
3.
The Definition of Ready
• The definition of ready is the series of conditions that the whole team agrees to finish
before the user story is considered adequately understood so that work can start to
construct it
• The definition of ready can be utilised in place of approval in adaptive life cycles to assist
the project team know that the user story is adequately elaborated and ready to be
brought into an iteration for the development team to work
© The Knowledge Academy Ltd
420
210
Tools and Techniques
4.
Delphi
• Delphi is the consensus‐building technique. Experts participate in this technique
anonymously
• The facilitator utilises a questionnaire in order to elicit ideas about the significant points
related to the subject
• The responses are summarised and are then recirculated to the experts for additional
comments
• Further rounds are repeated to solicit comments from the experts again until the results
begin to coverage. Consensus may be reached in some rounds of this process
© The Knowledge Academy Ltd
421
Tools and Techniques
5.
Facilitated Workshops
• Facilitated workshops utilise a structured meeting led by the skilled, neutral facilitator
and a carefully selected group of stakeholders in order to collaborate and work towards
a stated objective
• Facilitated workshops can bring teams together to select and approve requirements or
solve requirements conflicts hindering the team from reaching consensus
• The workshops are considered as a basic technique of reconciling the stakeholder
differences
© The Knowledge Academy Ltd
422
211
Tools and Techniques
6.
Force Field Analysis
• Force field analysis is the decision‐making technique that can assist product teams in
analysing whether there is enough support to continue a change
• The description of the change is placed in the middle of the model, and the team
identifies the forces for or against the proposed change
• The forces that support the change are listed on the left side, and then forces that are
impediments are listed on the right side. Each force is provided with a weight on the
basis of how important the force is and how easy it will be to influence it
• Positive forces are the conditions that must be strengthened, and negative forces need
to be weakened or eliminated
© The Knowledge Academy Ltd
423
Tools and Techniques
7.
Group decision‐making Techniques
• Group decision‐making techniques can be utilised in a group setting to bring
participants to a final decision on an issue or topic under discussion. Some decision‐
making techniques involve the following:
© The Knowledge Academy Ltd
1
Autocratic
2
Delphi
3
Force Field Analysis
424
212
Tools and Techniques
(Continued)
4
Majority
5
Plurality
6
Unanimity
© The Knowledge Academy Ltd
425
Tools and Techniques
(Continued)
i.
Autocratic
• Only one person can decide for the group
ii.
Delphi
• Decreases bias and prevents an individual from imposing undue impact on the team.
Delphi decides consensus
iii.
Force Field Analysis
• Decides by exploring the forces for or against a change and evaluating which is greatest
© The Knowledge Academy Ltd
426
213
Tools and Techniques
(Continued)
iv.
Majority
• Reaches the decision when support is collected from more than half of the group
members
v.
Plurality
• Obtains a decision by taking the most common response received from the decision‐
makers
vi.
Unanimity
• Decided by everyone agreeing on a single course of action
© The Knowledge Academy Ltd
427
Tools and Techniques
8.
Iteration Planning
• In adaptive approaches, iteration planning, or sprint planning, is the activity utilised to
identify the product backlog items’ subset from the product backlog that the
development team will work on for the current iteration or sprint
• Because the consequences of iteration planning give the backlog items deemed the
planning work for the current or next iteration, these items can be interpreted as
approved
9.
Prioritisation Schemes
• Prioritisation schemes are the methods utilised to prioritise requirements,
characteristics, or other product information
© The Knowledge Academy Ltd
428
214
Tools and Techniques
(Continued)
• Prioritisation schemes can also be utilised to solve conflicts related to requirements
• The stakeholder engagement and communication approach describes which
prioritisation schemes to utilise and when
10. Requirements Management Tools
• Requirements management tools enable requirements and other product information
to be captured and stored in a repository
• Requirements management tools usually incorporate workflow functionality to facilitate
the processes of review and approval
© The Knowledge Academy Ltd
429
Tools and Techniques
(Continued)
• Requirements management tools catered to
adaptive projects may incorporate functionality
to create and manage the product as well as
iteration backlogs
11. Story Mapping
• Story mapping is the technique utilised to
sequence user stories on the basis of their
business value and the order in which their users
perform them so that teams can arrive at a
shared knowledge of what will be built
© The Knowledge Academy Ltd
430
215
Outputs
(Continued)
• Story mapping can perform release allocation in which characteristics or solution
components are assigned to distinct product releases
© The Knowledge Academy Ltd
431
Outputs
Approved Requirements
• Approved requirements are the requirements that includes:
o Verified requirements are of enough quality and
o Validated requirements meet business needs
• The approved requirements are an indication that those having the authority to approve
requirements have agreed that the requirements as stated are what the product
development team must build
• On projects utilising an adaptive life cycle, the approved requirements can be
represented by the prioritised backlog ready for development or stories chosen from
the product backlog as the planned work for the following iteration
© The Knowledge Academy Ltd
432
216
Outputs
(Continued)
• On predictive projects, once the requirements analysed, are approved by decision‐
makers and the approved set of requirements establishes the requirement baseline
© The Knowledge Academy Ltd
433
Module 4: Manage Changes to
Requirements and Other Product
Information
© The Knowledge Academy Ltd
434
217
Introduction
• Manage the changes to requirements and other product information is reviewing
changes or defects that arise throughout a project by understanding the value and
influence of the changes
• As changes are agreed upon, the information about those changes is reflected wherever
important to support prioritisation and eventual product development
• The key advantages of this process incorporate:
o Facilitating the incorporation of significant solution changes for projects
o Limiting changes that are not required
o Giving an understanding of how the change will influence the end product
© The Knowledge Academy Ltd
435
Introduction
The following courses of action are possible after the proposed change is assessed:
• Changes Approved
o Required updates to the affected business analysis deliverable are made. Planned
and in‐process business analysis activities are adjusted when they are affected
o There is no concept of approval in an adaptive life cycle because any proposed
change can be added to the backlog
• Change Deferred
o The decision to defer making the change is documented, with the rationale for the
decision
© The Knowledge Academy Ltd
436
218
Introduction
(Continued)
o When the change is given with a proposed date for an upcoming product release, it
is noted and reflected in the relevant plans to assure that the change is addressed at
the requested future date
o In adaptive life cycles, this is similar to the proposed change being assigned a lower
ranking in the product backlog
Change Rejected
• The decision to reject the proposed change is documented, with the rationale for the
decision
© The Knowledge Academy Ltd
437
Introduction
(Continued)
• Unlike the action for a deferred change, there are no remainders for the upcoming date
are established in the plans because this work will not happen
• In adaptive life cycles, this refers to not adding the item to the backlog or removing the
item from the backlog
More Information Required
• Despite best efforts to assure that the impact analysis is constructed completely,
sometimes the change Control Board (CCB) or approval team requests more information
© The Knowledge Academy Ltd
438
219
Introduction
(Continued)
• In adaptive life cycles, backlog items are elaborated just to prioritise the product
backlog; and if they are selected for an iteration, items are elaborated more to gather
the required details for the development
• The idea that a change will need more information is inevitable as the elaboration
process is factored in the approach
© The Knowledge Academy Ltd
439
Inputs
• The following are the inputs to manage changes to requirements and other product
information:
Approved Requirements
Business Goals and Objectives
Change Requests
© The Knowledge Academy Ltd
Product Scope
Relationships and
Dependencies
Traceability and Monitoring
Approach
440
220
Inputs
1.
Approved Requirements
• Approved requirements are verified, validated, and considered as a correct
representation of what the product development team must build
• In predictive life cycles, change requests are assessed against the approved
requirements in order to conduct an impact analysis
2.
Business Goals and Objectives
• Business goals and objectives define the targets that are stated that the business is
trying to accomplish. Product information or new or revised requirements is assessed to
ensure that these requirements align with and support the stated goals as well as
objectives
© The Knowledge Academy Ltd
441
Inputs
3.
Change Requests
• Change requests are appeals for the change to a requirement or other suggestions for
product information raised by the business stakeholders or project team after a set of
requirements is baselined
• Change requests may arise from various sources, like new regulations, internal or
external constraints, missed requirements, or stakeholder recommendations after
observing part or all the solution in development or completed
© The Knowledge Academy Ltd
442
221
Inputs
4.
Product Scope
• Product scope is defined as the characteristics and functions that characterise a solution
• In adaptive life cycles, additional characteristics are added to the product backlog and
prioritised on the basis of evaluating the advantages or value: hence, product scope
evolves with time
• In predictive life cycles, new or revised product information is assessed against the
product scope in order to evaluate the size of the change and impacts
• When a proposed change is determined to be outside the defined product scope,
decision‐makers must consider whether a change to the product is viable
© The Knowledge Academy Ltd
443
Inputs
5.
Relationships and Dependencies
• Relationships and Dependencies are the linkages that are established between objects,
like components of product information, deliverables, as well as project work
• This information is utilised in adaptive life cycles when prioritising the backlog, as a
newly added backlog item may have linkages to other items in the backlog and can be
grouped and prioritised together
• In predictive approaches, relationships, as well as dependencies, can be utilised to
identify other impacted backlog items to size up the impact of making a change
• In the predictive life cycle, relationships and dependencies reduce the possibility of
missing requirements, support impact analysis, and assist the team in maintaining scope
© The Knowledge Academy Ltd
444
222
Inputs
6.
Traceability and Monitoring
• The traceability and monitoring approach
describes how traceability and change
management activities will be performed
during the portfolio, program, or project
• The approach incorporates information on
who can propose and approve changes and
how those changes are proposed and
assessed
© The Knowledge Academy Ltd
445
Tools and Techniques
1.
Backlog Management
• Backlog Management is a technique utilised in adaptive approaches to keep the backlog
items’ list to be worked on throughout a project
• The list is ranked in order of business value or relevance to the customer and sized by the
development team so that the highest‐value items are picked and delivered in the next
development cycle
• Proposed changes or new stories are added to the backlog’s bottom, where they sit till
the next time the backlog is reprioritised
• In adaptive life cycles, backlog management is the technique that is utilised to manage
changes
© The Knowledge Academy Ltd
446
223
Tools and Techniques
2.
Change Control Tools
• On projects following a predictive life cycle, change control tools can be automated or
manual and are utilised to manage change requests and the resulting decisions. These
tools may already be in place within the organisation
• When a change control tool is being introduced on a project, the stakeholder
requirements that are included in the change control process must be considered
• The following are the example of change control tools
o Configuration Management System (CMS)
o Version Control System (VCS)
© The Knowledge Academy Ltd
447
Tools and Techniques
3.
Group Decision Making Techniques
• Group Decision‐making techniques can be utilised in a group setting to bring participants
to a final decision on a topic or issue under discussion
• Group decision‐making techniques can be utilised in conjunction with other techniques
to decide whether suggested changes should be acted on
© The Knowledge Academy Ltd
448
224
Tools and Techniques
4.
Impact Analysis
• Impact analysis is a technique utilised to evaluate a change in relation to the way it will
affect related elements
• When a change to product information is proposed, an impact analysis is performed to
assess the proposed change about the way it will affect portfolio, program, project, and
product’s components, involving requirements and other product information
• Impact analysis involves identifying the risk related to the change, the work needed to
incorporate the change and the schedule and cost implications in an integrated manner
© The Knowledge Academy Ltd
449
Tools and Techniques
5.
Requirements Management Tools
• Requirements management tools enable requirements and other product information to
be stored and captured in a repository
• Requirements management tools usually involve functionality to maintain audit trails
and perform version control to help in change control
• Workflow functionality can facilitate review as well as approval processes for changes
• Traceability information stored in requirements management tools helps in impact
analysis
• Requirements management tools configured to adaptive projects may involve
functionality to create as well as manage iteration and product backlogs
© The Knowledge Academy Ltd
450
225
Tools and Techniques
6.
Traceability Matrix
• The traceability matrix includes information on the relationships and dependencies
among requirements and other product information
• The elements of product information impacted by the change can be identified within a
traceability matrix
• The affected relationships are simply recognised and can be utilised to quantify the size
and complexity of the change promptly and roughly
• In adaptive approaches, formal traceability matrices are utilised or named rarely as such,
but the concept of tracing to understand impacts to the things that are already built still
applies
© The Knowledge Academy Ltd
451
Output
Recommended Changes to Requirements and Other Product Information
• It defines the proposed action after analysing each impact related to making a proposed
change, involving impacts to product and project scope, value, risk, product usage,
schedule, and cost
• The possible courses of action involve:
o Approving the change
o Rejecting the change
o Deferring the change
o Requesting more information before making a decision about the change
© The Knowledge Academy Ltd
452
226
Domain 5
Evaluation
© The Knowledge Academy Ltd
453
Outlines of Domain 5
• Module 1: Evaluate Solution
Performance
• Module 2: Determine Solution
Evaluation Approach
• Module 3: Evaluate Acceptance
Results and Address Defects
• Module 4: Obtain Solution
Acceptance for Release
© The Knowledge Academy Ltd
454
227
Introduction
• Evaluation determines the way in which a solution meets the business requirements
properly that are expressed by stakeholders, including delivering value to the customer
• Evaluation activities are performed to evaluate whether or not a solution has reached
the desired outcomes of the business
• Solution evaluation practices apply to anything that should be evaluated, from a
discrete usage situation to an overall business result
© The Knowledge Academy Ltd
455
Introduction
(Continued)
• It includes the work performed to analyse
the measurements obtained for the solution
by comparing the actual acceptance testing
results to the expected or desired values, as
described by the acceptance criteria
• Over the long term, these activities assess
whether the expected value of the business
for a solution has been achieved or not
© The Knowledge Academy Ltd
456
228
Introduction
(Continued)
• Evaluation activities may happen the following points:
o When a go/no‐go or release decision should be made for a solution or a substantive
segment of it;
o Throughout a short‐term period, once a solution or segment is placed into
operation, like after a warranty period; or
o When a solution is in operation to get a long‐term perspective regarding whether
the goals and objectives of the business for the solution were met and whether the
value expected is constant to be delivered
© The Knowledge Academy Ltd
457
Module 1: Evaluate Solution Performance
© The Knowledge Academy Ltd
458
229
Introduction
• Evaluate Solution Performance is the process to evaluate a solution to determine
whether the solution which is implemented or solution component is delivering the
expected business value
• The main benefit of this process is that the analysis gives tangible data in order to
determine whether the solution the business has invested in is getting the business
results that were expected and serves as an input to decisions regarding future
initiatives
• The actual business value of a solution is measured in terms of the goals or objectives of
the business
© The Knowledge Academy Ltd
459
Introduction
(Continued)
• The business analysis also evaluates the reasons that are underlying behind the results
obtained
• Evaluation of solution performance usually happens after a solution has been released.
Hence, it is more probable that the evaluation of solution performance will happen
throughout the portfolio or program activities instead of project activities
© The Knowledge Academy Ltd
460
230
Introduction
(Continued)
• The related business goals as well as objectives evaluated acceptance results from an
earlier release, performance data, and baseline data, when available, are analysed in
order to determine whether the value has been delivered, and the reasons for better‐
than‐expected results or the basic reasons of any problems
• The following are the basic reasons for missed business value:
o Technical Issues
o Business practices or constraints
o Resistance to the product or how it is used
o Opportunistic workarounds devised by those using the product to get around real or
perceived solution limitations
© The Knowledge Academy Ltd
461
Inputs
Business Case
• A business case defines the pertinent information in order to determine whether the
initiative is worth the needed investment. It is an authoritative source where the
benefits which are expected have been stated
Business Goals and Objectives
• Business goals, as well as objectives, define stated targets that the business is seeking to
achieve. They give the context for evaluating solution performance as they describe the
business value, which is expected
© The Knowledge Academy Ltd
462
231
Inputs
(Continued)
• Some instances of business objectives cover the following:
o Extended throughput in the product manufacturing
o Costs Reduction
o Maximised sales volume
• Many products support goals as well as objectives of the business that can be associated
with one or more than one key performance indicators (KPIs), which are target
performance levels
© The Knowledge Academy Ltd
463
Inputs
Evaluated Acceptance Results
• Evaluated acceptance results are the comparisons among the acceptance criteria as well
as the actual results, and the main problem for differences between them
• The evaluated acceptance occurs from when the solution was released define the
product's state, and particularly any proficiencies or deficiencies it may have, that might
have altered the business value, which is expected
• A product that surpasses the expectations can give a base for upcoming opportunities. A
product that does not meet expectations may have defects, which will require the cost's
analysis to address the defects and the business impact of addressing them or accepting
them
© The Knowledge Academy Ltd
464
232
Inputs
Performance Data
• Performance data are a product's assessed output. Some of the instances of outputs
that might be measured involve:
o Throughout in the product's manufacture, the volume of some output that is
generated by the product, costs reduction, productivity get in utilising a service,
users adopting a solution, sales volume, revenue generated, individuals reached in a
marketing campaign, as well as customer satisfaction levels
• Performance data are usually measured and gathered from the business area that takes
the solution's ownership or by instrumentation made into the solution
© The Knowledge Academy Ltd
465
Inputs
Solution Evaluation Approach
• The solution evaluation approach gives the agreements that were made about the way
the solution evaluation activities will be done
• The solution evaluation approach identifies the metrics that will be utilised in order to
evaluate whether the business value that is expected has been achieved
• It explains the way in which solution performance will be evaluated. As the solutions can
be evaluated long once released, the initial solution evaluation approach may require to
be updated with time on the basis of the current state
© The Knowledge Academy Ltd
466
233
Tools and Techniques
Cost‐Benefit Analysis
• Cost‐benefit analysis is a financial analysis tool that is utilised in order to determine the
benefits given by a project or solution over its costs
• Thinking about the outcomes of an actual versus expected cost‐benefit analysis is a way
to evaluate the solution's business value
• Conducting a cost‐benefit analysis can assist in determining whether the suggestions
made as the evaluation of solution performance's part are expected to be cost‐effective
© The Knowledge Academy Ltd
467
Tools and Techniques
Elicitation Techniques
1.
Facilitated Workshops
• Utilise a structured meeting led by a skilled, neutral facilitator as well as a group of
stakeholders that are carefully selected to collaborate and work in the direction of a
stated objective. Facilitated workshops may be conducted with decision‐makers to
identify the root cause and any variances collaboratively
2.
Focus Groups
• Allow getting feedback directly from customers or end‐users. Concentration groups can
be utilised to learn about the deficiencies in business value that are important of
concern to stakeholders
© The Knowledge Academy Ltd
468
234
Tools and Techniques
3.
Interviews
• It may be conducted with individual stakeholders and users in order to get insights
regarding root causes in situations where the expected as well as actual business value
widely differs
• The privacy, as well as confidentiality of an individual interview, may reveal
considerations that might not be expressed in a facilitated workshop or focus group
4.
Observation
• An elicitation technique gives a straight way of eliciting information regarding the way in
which a process is performed, or a product is utilised by viewing individuals in their
environment performing the jobs or tasks
© The Knowledge Academy Ltd
469
Tools and Techniques
Product Portfolio Matrix
• A product portfolio matrix, also named a growth‐share matrix, is a market analysis
quadrant diagram that is used by some organisations to analyse their products or
product lines qualitatively
• An axis reflects market growth from low to high, while the other reflects the market
share of the organisation from low to high
• The matrix gives a quick visual way to evaluate that products are meeting or exceeding
the expectations of the performance in the marketplace, which can contribute to
evaluating the product's performance
© The Knowledge Academy Ltd
470
235
Tools and Techniques
Prioritisation Schemes
• Prioritisation schemes are various methods that are utilised in order to prioritise the
requirements, features, or any other information regarding the product
• For evaluating the solution performance, prioritisation schemes can be utilised to rank
the benefits' value gained from the solution and the severity of the challenges it creates
• This can give a method to think about whether the benefits outweigh the challenges and
vice versa
© The Knowledge Academy Ltd
471
Tools and Techniques
Root Cause & Opportunity Analysis
• Root cause analysis is utilised in order to determine the primary underlying reason that
makes a variance, defect, or risk
• Opportunity analysis is utilised to study the main facets of a possible opportunity to
determine the changes in products that are offered for the achievement
• When used to evaluate the solution performance, root cause and opportunity analysis
can assist in uncovering the reasons the actual business value either did not meet or
possibly surpassed expectations and where there may be any other opportunities for
product improvement
© The Knowledge Academy Ltd
472
236
Outputs
Assessment of Business Value
• The assessment of business value results from comparing the business value which is
expected from a solution over the actual value realised
• If the business value that was intended is not achieved, the assessment consists of the
reasons why
• The assessment is utilised to decide whether to develop a new product or enhance,
retire, or discontinue an existing product
• The work performed to implement the suggestions will require to be prioritised as the
ongoing planning activities part the organisation performs for portfolio or program
management
© The Knowledge Academy Ltd
473
Module 2: Determine Solution Evaluation
Approach
© The Knowledge Academy Ltd
474
237
Introduction
• Determine Solution Evaluation Approach
in determining those aspects of the
organisation or solution that will be
evaluated, and the way, when, and who
will measure the performance
• The main benefit of the process is that
performance indicators and metrics are
selected or defined to be gathered,
reported on, and evaluated to support the
organisation or product's continual
improvement
© The Knowledge Academy Ltd
475
Introduction
(Continued)
• Determining an approach for Solution Evaluation includes conducting research,
discussions, as well as analysis in order to identify how and when to evaluate the
product
• The solution evaluation approach defines two basic types of metrics: Metrics is used to
evaluate the solution or components for acceptance throughout or after the
development
• Acceptance criteria are defined to set acceptable ranges on these metrics. Metrics are
expected to be used later in order to determine if the business value was delivered
• As solution performance is not assessed until after a solution is released, the choice of
metrics or the way they are measured might change over time
© The Knowledge Academy Ltd
476
238
Introduction
(Continued)
• A metric is a collection of quantifiable measures used to evaluate a solution or business.
The team must consider some metrics when determining the solution evaluation
approach, which are the following:
o What kind of performance data will be gathered for the metrics, when, as well as
how usually?
o Who is accountable for gathering and reporting the performance data? Are there
built‐in collection and reporting mechanisms available for these metrics already?
o If not, what further abilities are required? Who will cover the developing costs?
© The Knowledge Academy Ltd
477
Inputs
Metrics & KPIs
• A metric is a collection of quantifiable measures utilised to evaluate a solution or
business
• A metric defines the way solution performance can be quantified in solution evaluation
• Various types of metrics could be utilised to evaluate a solution. Business objectives are
a metric that describes the business value of a product which is desired
• Key performance indicators (KPIs) are a related metric that is often defined by the
executives of an organisation, used to evaluate the progress of an organisation in the
direction of meeting its objectives or goals
© The Knowledge Academy Ltd
478
239
Inputs
Product Scope
• Product scope is described as the
features as well as functions that
characterise a solution
Product
• The product scope, as well as the
business goals and objectives on which
a solution is based, suggests what
information must be gathered and
measured for the purposes of
evaluation
© The Knowledge Academy Ltd
479
Inputs
Situation Statement
• A situation statement defines the problem or opportunity and its effect on the
organisation
• The situation statement may recommend the ways to measure whether or not the
problem or opportunity has been addressed
• The situation statement might also be utilised to determine how, when, and how
generally a solution must be evaluated
© The Knowledge Academy Ltd
480
240
Tools & Techniques
Elicitation Techniques
• The following are some of the common elicitation techniques that can support
determining the solution evaluation approach are document analysis, facilitated
workshops, as well as interviews:
1.
Document Analysis
• An elicitation technique utilised to analyse existing documentation in order to identify
the relevant product information
• A team may get ideas for likely metrics from the documentation that inventories the
kind of information that is collected or available when the solution is in place. The team
may also reutilise all or part of a documented solution evaluation approach
© The Knowledge Academy Ltd
481
Tools & Techniques
2.
Facilitated Workshop
• It uses structured meeting that is led by a
skilled, neutral facilitator and a group of
stakeholders which are selected carefully
to collaborate and work toward a stated
objective
• A facilitated workshop's structure
promotes an effective and concentrated
meeting for proposing metrics
© The Knowledge Academy Ltd
482
241
Tools & Techniques
3.
Interviews
• Used to elicit information regarding the solution evaluation approach. They can be
scheduled with different stakeholders possessing the key information for determining
the approach
• When required, individual interviews can give each and every stakeholder with an
opportunity to speak candidly about the organisation's ability to capture proposed
metrics
© The Knowledge Academy Ltd
483
Tools & Techniques
Group Decision Making Techniques
• Group decision‐making techniques are the methods that can be utilised in a group
setting in order to bring participants to a final decision on an issue or topic under
discussion
• Decision‐making techniques are utilised in order to reach a consensus about the
solution evaluation approach
• For instance, teams must decide which metrics to gather, the information against costs
to obtain it, which proposed metrics to use, and the frequency of gathering metrics
© The Knowledge Academy Ltd
484
242
Tools & Techniques
Prioritisation Schemes
• Prioritisation schemes are the various methods that are utilised to prioritise the
requirements, features, or any other information of the product
• When developing the solution evaluation approach, the interest in gaining information
should be balanced against the cost of getting and communicating that information
• The balance is obtained by decision making and may need prioritising among the
metrics that are proposed
• Prioritisation schemes like MoSCoW can assist in deciding which metrics must, should,
could, and would not be gathered, as can weighted rankings
© The Knowledge Academy Ltd
485
Tools & Techniques
Retrospective and Lessons Learned
• Retrospectives, as well as lessons, learned leverage past experiences in order to plan for
the future
• As an element of devising a solution evaluation approach, retrospectives and lessons
learned can be utilised in order to learn about the ease of gathering and analysing
different types of metrics and the effectiveness of various evaluation techniques
© The Knowledge Academy Ltd
486
243
Outputs
Solution Evaluation Approach
• The solution evaluation approach defines
when and the way a solution will be
evaluated, the metrics' types that will
support evaluation, the possibility of
collecting and communicating the actual
performance data for the metrics, and the
individual who is accountable for
conducting the evaluation as well as
communicating results
© The Knowledge Academy Ltd
487
Module 3: Evaluate Acceptance Results
and Address Defects
© The Knowledge Academy Ltd
488
244
Introduction
• Evaluating acceptance results and addressing defects is decoding what to do with the
results from a comparison of the defined acceptance criteria against the solution
• The important benefit of this process is that it enables informed decision making about
whether to release all or components of a solution and whether to undertake changes,
fixes, or enchantments to the product
• This process compares the acceptance criteria along with the actual results of
acceptance testing in order to provide recommendations on how to deal with situations
where aspects of a solution do not meet the acceptance criteria specified for it
© The Knowledge Academy Ltd
489
Introduction
(Continued)
• The test results that are part of evaluating acceptance criteria and addressing defects
may arise from:
© The Knowledge Academy Ltd
1
Exploratory Tests and User Acceptance Tests
2
Day‐in‐the‐Life (DITL) Tests
3
Preproduction or Simulated Production Testing
4
Tests of Functionality Within a Scenario
5
Tests of Non‐Functional Requirements
490
245
Introduction
The following are the recommendations to address the defect and may comprise:
• Potential workarounds to business practices or product usage that will not interfere with
the functionality of other products or cause the product to function in unintended ways
• Probable modifications to the product, which could need a change request
• Possible adjustments to how or which results are measures
• Recognising a need to investigate the technical causes of the defect
• Communications to customers and users in order to clarify how the product is supposed
to be used
© The Knowledge Academy Ltd
491
Inputs
Acceptance Criteria
• Acceptance criteria are concrete and display
conditions that have to be met for the business
stakeholders or customers to accept the item
• They may take the form of lists of acceptance
criteria for every user story in an adaptive approach
or a list of higher‐level acceptance criteria for a
release or solution in a predictive approach
• Acceptance criteria are a key input because they
demonstrate the conditions against which the
solution is being tested
© The Knowledge Academy Ltd
492
246
Inputs
Actual Acceptance Results
• Actual acceptance results include the pass or fail results by comparing test results
against the acceptance criteria, usually provided by a quality control team
• In business analysis, the actual acceptance results are then analysed to ascertain the
causes for any differences between the test results and acceptance criteria in order to
recommend how to address the defects
• For organisations that conduct regression testing, regression test results may be
valuable to analyse as well, as they may reveal situations where new or enhanced
functionality influences existing functionality
© The Knowledge Academy Ltd
493
Tools and Techniques
Prioritisation Schemes
• Prioritisation schemes are different methods
that are used to prioritise requirements,
features, or any other type of product
information
• As a part of addressing defects, prioritisation
schemes can be utilised to rank each defect on
the basis of its severity and how likely a user is
to encounter it, and on the impact of not fixing
the defect
© The Knowledge Academy Ltd
494
247
Tools and Techniques
Root Cause Analysis
• Root cause analysis techniques are used to
ascertain the reason for a variance or a defect
• Root cause analysis techniques can be utilised to
identify the causes why actual results did not
meet the acceptance criteria
• These root cause reasons will also figure into
decisions about whether or not to move forward
to gain acceptance for a release
© The Knowledge Academy Ltd
495
Tools and Techniques
Traceability Matrix
• A traceability matrix is a grid, and it connects product requirements from their origin to
the deliverables that satisfy them
• A traceability matrix can be employed to build relationships among product information,
deliverables, and project work to assure that each relates to business objectives
• As part of evaluating acceptance results, a traceability matrix can be utilised as a tool to
evaluate the business impact of not addressing variations from acceptance criteria and
defects
• For instance, there could be a notable business impact from not addressing defects
connected with the features that trace to a high priority objective
© The Knowledge Academy Ltd
496
248
Tools and Techniques
Variance Analysis
• It is a quantifiable deviation, departure, or
divergence from a known baseline or expected value
• It is a technique that is used for determining the
cause and degree of difference between the
baseline as well as actual performance irrespective
of the product life cycle
• When there are notable differences between the
acceptance criteria and actual results from testing,
variance analysis may be applied to consider cases
of the differences
© The Knowledge Academy Ltd
497
Outputs
Evaluated Acceptance Results
• Evaluated acceptance results provide a summarised comparison between the
acceptance criteria as well as the actual acceptance results, including the root cause for
variances or defects, the analysis of the cost to address the defect, and the business
impact of addressing it or accepting it
• Some organisations will track the evaluated acceptance results recommendations in
logs
• When evaluated acceptance results are communicated, recommendations regarding
ways to address the defect may be incorporated
© The Knowledge Academy Ltd
498
249
Module 4: Obtain Solution Acceptance for
Release
© The Knowledge Academy Ltd
499
Introduction
• Obtaining solution acceptance for release is the process of facilitating a decision on
whether to release a partial or full solution into production and eventually to an
operational team, and transitioning knowledge and existing information about the
product, its risks, associated issues, and any workarounds that may have arisen in
response to those issues
• The chief benefit of this process is the creation of an agreed‐upon break between
building a solution and releasing a solution or acceptance by the stakeholders
© The Knowledge Academy Ltd
500
250
Introduction
(Continued)
• Release decisions are based on the following:
o Acceptability of the solution, as evidenced by the evaluated acceptance results
o Confirmation that the organisation is ready for the release
o Confirmation that the transition activities to prepare for the release has been
completed to the degree necessary, including the coordination of this solution
release with any other releases that are happening concurrently
o Acceptance of any remaining product risks and workarounds
© The Knowledge Academy Ltd
501
Inputs
Approved Requirements
• Approved requirements are requirements that
are verified, validated, and are considered as an
accurate representation of what the product
development team should build
• Approved requirements provide the baseline for
comparisons made in release decisions between
what was approved for the solution and what
was executed in the product
© The Knowledge Academy Ltd
502
251
Inputs
Evaluated Acceptance Results
• Evaluated acceptance results provide a summarised comparison between the
acceptance criteria as well as the actual results, including the root cause for variances or
defects
• The analysis of the cost to address the defect, along with the business impact of
addressing it or the definition of done, is also part of these results
• Evaluated acceptance results provide strong evidence of whether or not the solution has
met or surpassed expectations
• Any recommendations within evaluated acceptance results for how to deal with the
discrepancies may impact when and whether a solution is accepted for release
© The Knowledge Academy Ltd
503
Inputs
Product Risk Analysis
• The product risk analysis comprises the consolidated results from identifying and
analysing product risks
• The product risk analysis consists of the recommended responses to manage and
control potential threats and strategies to take benefit of potential opportunities
associated with the product
• This context is required while seeking solution acceptance for a release to ascertain the
degree to which the product risks have been addressed
• Product risks not addressed within the duration of the project may be transferred to
operational teams to manage going forward
© The Knowledge Academy Ltd
504
252
Inputs
Readiness Assessment
• It is an evaluation of how well an organisation is prepared for a change
• It provides an evaluation of the organisation's ability to transition to the future state
enabled by the solution
• It also identifies risks to achieve readiness for the transition and may also propose
responses for how to address those risks
• Consideration of whether any understand readiness risks remain and whether the
organisation is ready for the release at the proposed point in time will figure into release
decisions
© The Knowledge Academy Ltd
505
Inputs
Stakeholder Engagement and Communication
Approach
• It summarises all the agreements for governing how
stakeholders will be engaged and communicated with
across the portfolio, project, or program
• The stakeholder engagement communication approach
incorporates information about which roles are
responsible for the release decision and how the release
decisions will be made
© The Knowledge Academy Ltd
506
253
Inputs
Transition Plan
• A transition plan is based on the readiness assessment along with the transition strategy
• It comprises the development of all the communication, rollout, training and user
documentation procedure updates, including business recovery updates and other
collateral and final production tasks required to cut over and adapt to the future state
successfully
• It provides the information needed to coordinate and assure that the release of the
solution will occur at a time when the business can accept the changes and that any
interruptions caused by the transition itself are not in conflict with other in‐process
programs and project works
© The Knowledge Academy Ltd
507
Tools and Techniques
Facilitated Workshops
• Facilitated Workshops use a structured meeting led by a skilled, neutral facilitator and a
carefully selected group of stakeholders in order to collaborate and work toward a
stated objective
• Whenever possible, release decisions should be made during a facilitated workshop to
let all stakeholders hear the reason for the decisions made
• The individuals who evaluated the acceptance criteria should attend and contribute to
the decision making
• It can be helpful to provide summarised information in a tabular or visual form
whenever possible to help decision‐makers execute their decisions
© The Knowledge Academy Ltd
508
254
Tools and Techniques
Group Decision Making Techniques
• Group decision‐making techniques are used in a
group setting to bring participants to a conclusive
decision on an issue or topic under discussion
• In order to make the release decision, group
decision making is carried out using an agreed‐
upon model for reaching a decision
• The decision model should be identified as part of
the stakeholder engagement as well as the
communication approach
© The Knowledge Academy Ltd
509
Outputs
Release Decision
• A release decision may allow the release or partial release of the solution, delay it or
refuse and prevent
• A release decision often involves a sign‐off
• The formality of the sign‐off depends upon the type of project, the type of product, the
project life cycle, the scale of the release, as well as corporate and regulatory constraints
• Organisations with informal sign‐off practices require to obtain sign‐off in a way that is
acceptable to the organisation
© The Knowledge Academy Ltd
510
255
Congratulations
Congratulations on completing this course!
Keep in touch
info@theknowledgeacademy.com
Thank you
© The Knowledge Academy Ltd
511
256
/The.Knowledge.Academy.Ltd
/TKA_Training
/+TheKnowledgeAcademyWinkfield
/the-knowledge-academy
/TheKnowledgeAcademy
The world’s largest global training provider
info@theknowledgeacademy.com
theknowledgeacademy.com
To the best of our knowledge, the information contained herein is accurate and reliable as of the date of publication; however, we do not assume any liability whatsoever for the accuracy and completeness of the
above information.