WELCOME

Certified Business Analysis

Approve
Develop

Professional
Trace
Direct
Need

Study Guides
BY:
PM Tutor
 COURSE STRUCTURE
BA Key Analysis &
Introduction
Concept Monitoring
Module 1
Module 2 Module 3
Approve
Develop
Trace
Direct
Need

Elicitation & Requirement Strategy

Collaboration Lifecycle Analysis
Module 4 Module 5 Module 6
 COURSE STRUCTURE
Requirements Solution
Analysis Evaluation
Module 7 Module 8
Approve
Develop
Trace
Direct
Need

Underlying
Techniques Perspectives
Competencies
Module 10 Module 11
Module 9
 COURSE OBJECTIVE
At the end of this course, you will
understand what business analysis is all
about, why it is essential to the success of
Approve
Develop

any project and how to perform it on your

Trace
Direct
Need

projects...
 Certified Business Analysis Professional

Requirement Lifecycle
Approve
Develop
Trace
Direct
Need

Module 5
 1 2 3 4 5
Approve
Develop
Trace
Direct
Need

Trace Maintain Prioritize Assess Approve

Requirements Requirements Requirements Requirements Requirements
 Requirements Life Cycle Management
The Requirements Life Cycle Management knowledge area describes the tasks that business
analysts perform in order to manage and maintain requirements and design information from
inception to retirement.

The purpose of requirements life cycle management is to ensure that business, stakeholder, and
solution requirements and designs are aligned to one another and that the solution implements
Approve
Develop

them.
Trace
Direct
Need

The requirements life cycle:

• begins with the representation of a business need as a requirement,
• continues through the development of a solution, and
• ends when a solution and the requirements that represent it are retired.

The management of requirements does not end once a solution is implemented. Throughout the
life of a solution, requirements continue to provide value when they are managed appropriately.
Within the Requirements Life Cycle Management knowledge area, the concept of a life cycle is
separate from a methodology or process used to govern business analysis work. Life cycle refers to
the existence of various phases or states that requirements pass through as part of any change.
 The Requirements Life Cycle Management knowledge
area includes the following tasks
• Trace Requirements: analyzes and maintains the relationships between requirements, designs,
solution components, and other work products for impact analysis, coverage, and allocation.

• Maintain Requirements: ensures that requirements and designs are accurate and current
throughout the life cycle and facilitates reuse where appropriate.
Approve
Develop
Trace
Direct
Need

• Prioritize Requirements: assesses the value, urgency, and risks associated with particular
requirements and designs to ensure that analysis and/or delivery work is done on the most
important ones at any given time.

• Assess Requirements Changes: evaluates new and changing stakeholder requirements to

determine if they need to be acted on within the scope of a change.

• Approve Requirements: works with stakeholders involved in the governance process to reach
approval and agreement on requirements and designs.
 The Requirements Life Cycle Management knowledge
area includes the following tasks
Approve
Develop
Trace
Direct
Need
 The BACCM in Requirements Life Cycle Management
Approve
Develop
Trace
Direct
Need
 Requirements Life
Approve

Cycle Management
Develop
Trace
Direct
Need
 Trace Requirements
Purpose
The purpose of Trace Requirements is to ensure that requirements and designs at different levels
are aligned to one another, and to manage the effects of change to one level on related
requirements.

Description
Requirements traceability identifies and documents the lineage of each requirement, including
Approve
Develop

its backward traceability, its forward traceability, and its relationship to other requirements.
Trace
Direct

Traceability is used to help ensure that the solution conforms to requirements and to assist in
Need

scope, change, risk, time, cost, and communication management. It is also used to detect
missing functionality or to identify if there is implemented functionality that is not supported by
any requirement.

Inputs
• Requirements: may be traced to other requirements (including goals, objectives, business
requirements, stakeholder requirements, solution requirements, and transition requirements),
solution components, visuals, business rules, and other work products.

• Designs: may be traced to other requirements, solution components, and other work products.
 Trace Requirements Input/Output Diagram
Develop
Maintain

Trace
 Elements
.1 Level of Formality When tracing requirements, business analysts consider the value that each link
is supposed to deliver, as well as the nature and use of the specific relationships that are being
created.

.2 Analyst considers:
• Derive: used when a requirement is derived from another requirement.
Develop
Maintain

• Depends: relationship between two requirements

Trace
• Necessity: when it only makes sense to implement a particular requirement if a related
requirement is also implemented.

• Effort: when a requirement is easier to implement if a related requirement is also implemented.

• Satisfy: relationship between an implementation element and the requirements it is satisfying.
• Validate: relationship between a requirement and a test case or other element that can
determine whether a solution fulfills the requirement.

.3 Traceability Repository Requirements traceability is documented and maintained in accordance

with the methods identified by the business analysis approach.
 Guidelines and Tools
• Domain Knowledge: knowledge of and expertise in the business domain
needed to support traceability.

• Information Management Approach: provides decisions from planning

activities concerning the traceability approach.
Develop
Maintain

Trace
• Legal/Regulatory Information: describes legislative rules or regulations that
must be followed. These may need to be considered when defining traceability
rules.

• Requirements Management Tools/Repository: used to store and manage

business analysis information. The tool may be as simple as a text document or
as complex as a dedicated requirements management tool.
 Techniques

• Business Rules Analysis: used to trace business rules to requirements that they
support, or rules that support requirements.

• Functional Decomposition: used to break down solution scope into smaller

Develop
Maintain

components for allocation, as well as to trace high-level concepts to low-level

Trace
concepts.

• Process Modelling: used to visually show the future state process, as well as
tracing requirements to the future state process.

• Scope Modelling: used to visually depict scope, as well as trace requirements to

the area of scope the requirement supports.
 Stakeholders
• Customers: are affected by how and when requirements are implemented, and may have to be consulted
about, or agree to, the traceability relationships.

• Domain Subject Matter Expert: may have recommendations regarding the set of requirements to be
linked to a solution component or to a release.

• End User: may require specific dependency relationships that allow certain requirements to be
implemented at the same time or in a specific sequence.
Develop
Maintain

Trace
• Implementation Subject Matter Expert: traceability ensures that the solution being developed meets the
business need and brings awareness of dependencies between solution components during
implementation.

• Operational Support: traceability documentation provides another reference source for help desk
support.

• Project Manager: traceability supports project change and scope management.

• Sponsor: is required to approve the various relationships.
• Suppliers: are affected by how and when requirements are implemented.
• Tester: needs to understand how and where requirements are implemented when creating test plans and
test cases, and may trace test cases to requirements.
 Stakeholders

Outputs
• Requirements (traced): have clearly defined relationships to other
requirements, solution components, or releases, phases, or iterations, within a
solution scope, such that coverage and the effects of change are clearly
Develop
Maintain

identifiable.

Trace
• Designs (traced): clearly defined relationships to other requirements, solution
components, or releases, phases, or iterations, within a solution scope, such that
coverage and the effects of change are clearly identifiable.
 Maintain Requirements
Purpose
The purpose of Maintain Requirements is to retain requirement accuracy and consistency throughout and
beyond the change during the entire requirements life cycle, and to support reuse of requirements in
other solutions.

Description

Maintain
Prioritize

A requirement that represents an ongoing need must be maintained to ensure that it remains valid over

Trace
time. In order to maximize the benefits of maintaining and reusing requirements, the requirements should
be:
• consistently represented,
• reviewed and approved, and
• easily accessible and understandable.

Inputs
• Requirements: include goals, objectives, business requirements, stakeholder requirements, solution
requirements, and transition requirements. These should be maintained throughout their life cycle.
• Designs: can be maintained throughout their life cycle, as needed.
 Maintain Requirements Input/Output Diagram

Maintain
Prioritize

Trace
 Elements
.1 Maintain Requirements are maintained so that they remain correct and current after an
approved change. Business analysts are responsible for conducting maintenance to ensure
this level of accuracy is retained. For requirements to be properly maintained they must be
clearly named and defined, and easily available to stakeholders.

Maintain
Prioritize

.2 Maintain Attributes While eliciting requirements, business analysts elicit requirement

Trace
attributes. Information such as the requirement’s source, priority, and complexity aid in
managing each requirement throughout the life cycle. Some attributes change as the
business analyst uncovers more information and conducts further analysis. An attribute may
change even though the requirement does not.

.3 Reusing Requirements There are situations in which requirements can be reused.

Requirements that are candidates for long-term use by the organization are identified, clearly
named, defined, and stored in a manner that makes them easily retrievable by other
stakeholders.
 Techniques
• Business Rules Analysis: used to identify business rules that may be similar across the enterprise in
order to facilitate reuse.

• Data Flow Diagrams: used to identify information flow that may be similar across the enterprise in order
to facilitate reuse.
• Data Modelling: used to identify data structure that may be similar across the enterprise in order to

Maintain
Prioritize

facilitate reuse.

Trace
• Document Analysis: used to analyze existing documentation about an enterprise that can serve as the
basis for maintaining and reusing requirements.
• Functional Decomposition: used to identify requirements associated with the components and available
for reuse.

• Process Modelling: used to identify requirements associated with the processes that may be available
for reuse.
• Use Cases and Scenarios: used to identify a solution component that may be utilized by more than one
solution.
• User Stories: used to identify requirements associated with the story that may be available for reuse.
 Stakeholders
• Domain Subject Matter Expert: references maintained requirements on a regular basis to ensure they
are accurately reflecting stated needs.
• Implementation Subject Matter Expert: utilizes maintained requirements when developing regression
tests and conducting impact analysis for an enhancement.
• Operational Support: maintained requirements are likely to be referenced to confirm the current
state.

Maintain
Prioritize

• Regulator: maintained requirements are likely to be referenced to confirm compliance to standards.

Trace
• Tester: maintained requirements are used by testers to aid in test plan and test case creation.

Outputs
• Requirements (maintained): defined once and available for long-term usage by the organization. They
may become organizational process assets or be used in future initiatives. In some cases, a requirement
that was not approved or implemented may be maintained for a possible future initiative.

• Designs (maintained): may be reusable once defined. For example, as a self contained component that
can be made available for possible future use.
 Prioritize Requirements
Purpose
The purpose of Prioritize Requirements is to rank requirements in the order of relative
importance.

Description

Maintain
Prioritize
Assess

Prioritization is the act of ranking requirements to determine their relative importance to

Trace
stakeholders. When a requirement is prioritized, it is given greater or lesser priority. Priority can
refer to the relative value of a requirement, or to the sequence in which it will be implemented.
Prioritization is an ongoing process, with priorities changing as the context changes.

Inputs
• Requirements: any requirements in the form of text, matrices, or diagrams that are ready to
prioritize.
• Designs: any designs in the form of text, prototypes, or diagrams that are ready to prioritize.
 Prioritize Requirements Input/Output Diagram

Maintain
Prioritize
Assess

Trace
 Elements
.1 Basis for Prioritization The basis on which requirements are prioritized is
agreed upon by relevant stakeholders as defined in the Business Analysis Planning
and Monitoring knowledge area. Typical factors that influence prioritization
include:
• Benefit

Maintain
Prioritize
Assess

Trace
• Penalty
• Cost
• Risk:
• Dependencies
• Time Sensitivity
• Stability:
• Regulatory
 Elements
greater if the functionality is delivered ahead of the competition. It can also refer to seasonal
functionality that only has value at a specific time of year. or Policy Compliance: requirements
that must be implemented in order to meet regulatory or policy demands imposed on the
organization, which may take precedence over other stakeholder interests.

Maintain
Prioritize
.2 Challenges of Prioritization is an assessment of relative value. Each stakeholder may value
Assess

something different. When this occurs, there may be conflict amongst stakeholders.

Trace
Stakeholders may also have difficulty characterizing any requirement as a lower priority, and
this may impact the ability to make necessary trade-offs.

.3 Continual Prioritization Priorities may shift as the context evolves and as more information
becomes available. Initially, prioritization is done at a higher level of abstraction. As the
requirements are further refined, prioritization is done at a more granular level and will
incorporate additional bases for prioritization as they become appropriate. The basis for
prioritization may be different at various stages of the change.
 Guidelines and Tools
• Business Constraints: regulatory statutes, contractual obligations and business policies that may
define priorities.

• Change Strategy: provides information on costs, timelines, and value realization which are used to
determine priority of requirements.

Maintain
Prioritize
• Domain Knowledge: knowledge and expertise of the business domain needed to support
Assess

Trace
prioritization.

• Governance Approach: outlines the approach for prioritizing requirements.

• Requirements Architecture: utilized to understand the relationship with other requirements and
work products.

Requirements Management Tools/Repository: including a requirements attribute for prioritization

can help the business analyst to sort and access requirements by priority.
• Solution Scope: considered when prioritizing requirements to ensure scope is managed.
 Techniques
• Backlog Management: used to compare requirements to be prioritized. The backlog can be the
location where the prioritization is maintained.
• Business Cases: used to assess requirements against identified business goals and objectives to
determine importance.

• Decision Analysis: used to identify high-value requirements.

Maintain
Prioritize
• Estimation: used to produce estimates for the basis of prioritization.
Assess

Trace
• Financial Analysis: used to assess the financial value of a set of requirements and how the timing
of delivery will affect that value.

• Interviews: used to gain an understanding of a single or small group of stakeholders' basis of

prioritization or priorities.
• Item Tracking: used to track issues raised by stakeholders during prioritization.
• Prioritization: used to facilitate the process of prioritization.

• Risk Analysis and Management: used to understand the risks for the basis of prioritization.
• Workshops: used to gain an understanding of stakeholders' basis of prioritization or priorities in a
facilitated group setting.
 Stakeholders
• Customer: verifies that the prioritized requirements will deliver value from a customer or end-
user perspective.
• End User: verifies that the prioritized requirements will deliver value from a customer or end-user
perspective.
• Implementation Subject Matter Expert: provides input relating to technical dependencies and
can negotiate to have the prioritization changed based on technical constraints.

Maintain
Prioritize
• Project Manager: uses the prioritization as input into the project plan and into the allocation of
Assess

Trace
requirements to releases.
• Regulator: can verify that the prioritization is consistent with legal and regulatory constraints.
• Sponsor: verifies that the prioritized requirements will deliver value from an organizational
perspective.

Outputs
• Requirements (prioritized): prioritized or ranked requirements are available for additional work,
ensuring that the highest valued requirements are addressed first. • Designs (prioritized):
prioritized or ranked designs are available for additional work, ensuring that the highest valued
designs are addressed first.
 Assess Requirements Changes
Purpose
The purpose of Assess Requirements Changes is to evaluate the implications of proposed
changes to requirements and designs.

Description

Maintain
Prioritize
Approve

The Assess Requirements Changes task is performed as new needs or possible solutions are

Assess
Trace
identified. These may or may not align to the change strategy and/ or solution scope.
Assessment must be performed to determine whether a proposed change will increase the
value of the solution, and if so, what action should be taken.

Inputs
• Proposed Change: can be identified at any time and impact any aspect of business analysis
work or deliverables completed to date.
• Requirements: may need to be assessed to identify the impact of a proposed modification.
• Designs: may need to be assessed to identify the impact of a proposed modification.
 Assess Requirements Changes
Input/Output Diagram

Maintain
Prioritize
Approve

Assess
Trace
 Elements

.1 Assessment Formality Business analysts will determine the formality of the assessment
process based on the information available, the apparent importance of the change, and the
governance process. Many proposed changes may be withdrawn from consideration or
declined before any formal approval is required. A predictive approach may indicate a more
formal assessment of proposed changes.

Maintain
Prioritize
Approve

Assess
Trace
.2 Impact Analysis Impact analysis is performed to assess or evaluate the effect of a change.
Traceability is a useful tool for performing impact analysis. When a requirement
changes, its relationships to other requirements or solution components can be reviewed. Each
related requirement or component may also require a change to support the new requirement.

.3 Impact Resolution Depending on the planned approach, various stakeholders (including the
business analyst) may be authorized to approve, deny, or defer the proposed change. All
impacts and resolutions resulting from the change analysis are to be documented and
communicated to all stakeholders.
 Guidelines and Tools
• Change Strategy: describes the purpose and direction for changes, establishes the context for the
change, and identifies the critical components for change.

• Domain Knowledge: knowledge of and expertise in the business domain is needed to assess
proposed requirements changes.

Maintain
Prioritize
Approve

• Governance Approach: provides guidance regarding the change control and decision-making

Assess
Trace
processes, as well as the roles of stakeholders within this process.

• Legal/Regulatory Information: describes legislative rules or regulations that must be followed.

These may impact requirements and must be considered when making changes.

• Requirements Architecture: requirements may be related to each other, therefore the business
analyst examines and analyzes the requirement relationships to determine which requirements will
be impacted by a requested requirements change.

• Solution Scope: must be considered when assessing changes to fully understand the impact of a
proposed change.
 Techniques
• Business Cases: used to justify a proposed change.
• Business Rules Analysis: used to assess changes to business policies and business rules, and develop
revised guidance.
• Decision Analysis: used to facilitate the change assessment process.
• Document Analysis: used to analyze any existing documents that facilitate an understanding of the

Maintain
Prioritize
Approve

impact of the change.

Assess
Trace
• Estimation: used to determine the size of the change.
• Financial Analysis: used to estimate the financial consequences of a proposed change.
• Interface Analysis: used to help business analysts identify interfaces that can be affected by the
change.
• Interviews: used to gain an understanding of the impact on the organization or its assets from a
single or small group of stakeholders.
• Item Tracking: used to track any issues or conflicts discovered during impact analysis.
• Risk Analysis and Management: used to determine the level of risk associated with the change.
• Workshops: used to gain an understanding of the impact or to resolve changes in a group setting.
 Stakeholders
• Customer: provides feedback concerning the impact the change will have on value.
• Domain Subject Matter Expert: has expertise in some aspect of the situation and can provide insight into
how the change will impact the organization and value.
• End User: uses the solution or is a component of the solution, and can offer information about the impact
of the change on their activities.
• Operational Support: provides information on both their ability to support the operation of the solution

Maintain
Prioritize
Approve

and their need to understand the nature of the change in the solution in order to be able to support it.

Assess
• Project Manager: reviews the requirements change assessment to determine if additional project work is

Trace
required for a successful implementation of the solution.

• Regulator: changes are likely to be referenced by auditors to confirm compliance to standards.

• Sponsor: accountable for the solution scope and can provide insight to be utilized when assessing change.
• Tester: consulted for establishing impact of the proposed changes.

Outputs
• Requirements Change Assessment: the recommendation to approve, modify, or deny a proposed change
to requirements.
• Designs Change Assessment: the recommendation to approve, modify, or deny a proposed change to one
or more design components.
 Approve Requirements
Purpose
The purpose of Approve Requirements is to obtain agreement on and approval of requirements and designs
for business analysis work to continue and/or solution construction to proceed.

Description
Business analysts are responsible for ensuring clear communication of requirements, designs, and other

Maintain
Approve
Prioritize
business analysis information to the key stakeholders responsible for approving that information. Approval

Assess
Trace
of requirements and designs may be formal or informal. Predictive approaches typically perform approvals
at the end of the phase or during planned change control meetings. Adaptive approaches typically approve
requirements only when construction and implementation of a solution meeting the requirement can
begin.

Inputs
• Requirements (verified): a set of requirements that have been verified to be of sufficient quality to be
used as a reliable body of work for further specification and development.

• Designs: a set of designs that have been determined as ready to be used for further specification and
development.
Approve Requirements Input/Output Diagram

Maintain
Approve
Prioritize
Assess
Trace
 Elements
.1 Understand Stakeholder Roles The approval process is defined by the task Plan Business Analysis
Governance. Part of defining the approval process is understanding stakeholder roles and authority levels.

.2 Conflict and Issue Management To maintain stakeholder support for the solution, consensus among
stakeholders is usually sought prior to requesting approval of requirements. The approach for determining
how to secure decisions and resolve conflicts across an initiative is planned for in the task Plan Business

Maintain
Approve
Prioritize
Analysis Governance.

Assess
Trace
.3 Gain Consensus Business analysts are responsible for ensuring that the stakeholders with approval
authority understand and accept the requirements. Approval may confirm that stakeholders believe that
sufficient value will be created for the organization to justify investment in a solution.

.4 Track and Communicate Approval The business analyst records approval decisions, possibly in
requirements maintenance and tracking tools. In order to communicate the status of requirements, it is
necessary to keep accurate records of current approval status. Stakeholders must be able to determine what
requirements and designs are currently approved and in line for implementation. There may be value in
maintaining an audit history of changes to requirements: what was changed, who made the change, the
reason for the change, and when it was made.
 Guidelines and Tools
• Change Strategy: provides information which assists in managing stakeholder consensus
regarding the needs of all stakeholders.

• Governance Approach: identifies the stakeholders who have the authority and responsibility to
approve business analysis information, and explains when such approvals will take place and how

Maintain
Approve
they will align to organizational policies.

Prioritize
Assess
Trace
• Legal/Regulatory Information: describes legislative rules or regulations that must be followed.
They may impact the requirements and designs approval process.

• Requirement Management Tools/Repository: tool to record requirements approvals.

• Solution Scope: must be considered when approving requirements to accurately assess

alignment and completeness.
 Techniques

• Acceptance and Evaluation Criteria: used to define approval criteria.

• Decision Analysis: used to resolve issues and gain agreement.

Maintain
Approve
Prioritize
Assess
Trace
• Item Tracking: used to track issues identified during the agreement process.

• Reviews: used to evaluate requirements.

• Workshops: used to facilitate obtaining approval.

 Stakeholders
• Customer
• Domain Subject Matter Expert
• End User
• Operational Support:
• Project Manager
• Regulator

Maintain
Approve
Prioritize
Assess
• Sponsor

Trace
• Tester

Outputs
• Requirements (approved): requirements which are agreed to by stakeholders and are ready for
use in subsequent business analysis efforts.

• Designs (approved): designs which are agreed to by stakeholders and are ready for use in
subsequent business analysis or solution development efforts.
 Check
Knowledge

Introduction
Q &A
Integrate
Monitor
Direct
Develop
Manage
Charter
 Knowledge Check

1. Which Requirements Management and Communication task may seek

approval and sign off on the communicated requirements?

Integrate
Introduction
A. Obtain requirements sign- off

Develop
Monitor
Manage
Charter
B. Communicate requirements

Q &A
Direct
C. Conduct requirements review
D. Create requirements package

B. Communicate requirements
 Knowledge Check
2. Which document determines how the business analyst shares
requirements information with their stakeholders?

Integrate
Introduction
A. Requirements management plan

Develop
Monitor
Manage
Charter
B. Project management plan

Q &A
Direct
C. Requirements package
D. Business analysis communication plan

D. Business analysis communication plan

 Knowledge Check

3. What stakeholder is responsible and accountable for the project scope?

A. Project sponsor
B. Business analyst

Integrate
Introduction
C. Project manager

Develop
Monitor
Manage
Charter
Q &A
Direct
D. Process owner

C. Project manager
 Knowledge Check
4. The performance of the Requirements Management and Communication
tasks is governed by which plan?

A. Requirements management plan

Integrate
Introduction
B. Project management plan

Develop
Monitor
Manage
Charter
Q &A
C. Business analysis plan

Direct
D. Configuration management plan

C. Business analysis plan

 Knowledge Check
5. What technique is recommended for tracing requirements when there are
relatively few requirements?

A. Coverage matrix

Integrate
Introduction
B. RACI matrix

Develop
Monitor
Manage
Charter
C. Onion diagram

Q &A
Direct
D. Process model

A. Coverage matrix
 Knowledge Check
6. Which statement is TRUE about communicating requirements?
A. Requirements must be verified and validated in order to be communicated.
B. Requirements must be formally distributed, reviewed, and agreed upon.

Integrate
Introduction
C. Requirements must be traced and reusable prior to being communicated.

Develop
Monitor
Manage
Charter
D. Requirements may be communicated without using a requirements package.

Q &A
Direct
D. Requirements may be communicated
without using a requirements package.
 Knowledge Check
7. An email message is sent to project stakeholders with a graphical model
subset of the solution requirements attached to the message. This is an
example of what type of requirements presentation format?

Integrate
Introduction
Develop
Monitor
Manage
A. Informal

Charter
Q &A
Direct
B. Targeted
C. Formal

D. Virtual

A. Informal
 You
Thank

Introduction
Q &A
Integrate
Monitor
Direct
Develop
Manage
Charter