Free PC-BA-FBA-20 Practice Test Questions and Answers (2026) | Cert Empire Practice Questions

Design thinking is a human-centered, iterative approach used to uncover innovative solutions by

focusing on user needs and exploring multiple possibilities. It emphasizes creativity, collaboration,

and experimentation.

Key Characteristics of Techniques:

Design Thinking: Uses an iterative process (empathize, define, ideate, prototype, test) to generate

innovative options.

Fishbone Diagram: A root cause analysis tool, not focused on innovation.

Rich Pictures: A visual representation of a situation, useful for understanding context but not for

generating innovative options.

Mind Maps: A brainstorming tool that organizes ideas hierarchically, but it does not inherently follow

an iterative approach.

Evaluation of Each Option:

A . Design thinking:

Design thinking explicitly uses an iterative approach to uncover innovative options.

Conclusion: This is correct .

B . Fishbone diagram:

Fishbone diagrams focus on identifying root causes, not innovation.

Conclusion: This is not correct .

C . Rich pictures:

Rich pictures visualize complex situations but do not inherently foster innovation.

Conclusion: This is not correct .

D . Mind maps:

Mind maps organize ideas but do not follow an iterative, innovative process like design thinking.

Conclusion: This is not correct .

Final Recommendation:

The technique that uses an iterative approach to uncover innovative options is:

A . Design thinking.

The Business Change Lifecycle encompasses multiple stages, including alignment, analysis, design,

implementation, and realisation. The role of a business analyst (BA) is versatile and can span across

all these stages, depending on the project's needs.

Key Considerations:

Involvement Across All Stages: A business analyst can contribute to every stage of the lifecycle, from

identifying business needs during alignment to ensuring benefits realization post-implementation.

Implementation Focus: While BAs are often heavily involved in implementation, their role is not

limited to this stage.

Realisation Stage: BAs may also be involved in the realisation stage to validate that the intended

benefits have been achieved.

Alignment Stage: Business analysis plays a critical role in aligning project objectives with

organizational goals.

Evaluation of Each Option:

A . A business analyst can be involved at every stage in the lifecycle:

This is true; BAs can contribute across all stages of the lifecycle.

Conclusion: This is correct .

B . The business analyst is involved more heavily during the implementation stage of the lifecycle

than any other stage:

While BAs are often active during implementation, their involvement is not restricted to this stage.

Conclusion: This is not correct .

C . The business analyst would not be involved in the realisation stage of the lifecycle:

BAs can play a role in validating benefits realization, so this statement is false.

Conclusion: This is not correct .

D . Business analysis does not take place in the alignment stage of a business change:

Alignment involves understanding business needs and objectives, which is a core BA responsibility.

Conclusion: This is not correct .

The Requirements Engineering (RE) Framework is a structured approach used by business analysts to

define, document, and manage requirements. It consists of five iterative stages: Investigate

Situation, Consider Perspectives, Analyze Needs, Evaluate Options, and Define Requirements .

Key Considerations:

Suitability for Waterfall Projects Only: The RE Framework is flexible and can be adapted to both

waterfall and Agile methodologies.

Iterative Stages: The framework emphasizes iteration and refinement, making it suitable for evolving

requirements.

Defining Requirements: The framework explicitly supports the definition and management of

requirements.

Sequential Steps: While the stages are presented in a sequence, they are iterative and not strictly

linear.

Evaluation of Each Option:

A . It is only suitable for use with waterfall projects:

The RE Framework can be applied to both waterfall and Agile projects.

Conclusion: This is not correct .

B . It shows five iterative stages that a business analyst needs to carry out to establish the

requirements:

This accurately describes the RE Framework's structure and purpose.

Conclusion: This is correct .

C . Using the Requirements Engineering Framework does not help to define requirements:

The framework is specifically designed to define and manage requirements.

Conclusion: This is not correct .

D . It shows steps in the requirements engineering process that a business analyst must follow

sequentially:

While the stages are presented in a sequence, they are iterative and not strictly sequential.

Conclusion: This is not correct .

A process model is a visual representation of a business process or workflow, showing how activities

are performed and how they relate to one another. It is commonly used in business analysis to

understand, analyze, and improve processes.

Key Characteristics of a Process Model:

Graphical Representation: Process models visually depict workflows and subprocesses, making them

easier to understand.

Cost Differences: Cost analysis is not the primary purpose of a process model.

Job Descriptions: Process models focus on workflows, not individual job roles.

Software Features: Informal descriptions of software features are unrelated to process modeling.

Evaluation of Each Option:

A . A graphical representation of a business process or workflow and its related sub-processes:

This accurately describes the purpose and nature of a process model.

Conclusion: This is correct .

B . The cost differences between how a customer currently does something and how they would like

to do something:

Cost differences are analyzed separately and are not part of process modeling.

Conclusion: This is not correct .

C . The detailed job description of the work to be performed by an individual:

Job descriptions are documented separately and are not part of process modeling.

Conclusion: This is not correct .

D . An informal, detailed, description of a software system feature derived from an end user's

perspective:

This describes user stories or feature descriptions, not process models.

Conclusion: This is not correct .

A mission statement defines the organization's purpose and primary objectives, often focusing on

what the organization does and how it operates in the present. In contrast, a vision statement

outlines the long-term aspirations of the organization—what it aims to become in the future. The

mission provided—"To meet or undercut all our competitors' prices"—is focused on price

competitiveness, which is a tactical approach rather than a strategic aspiration.

Let’s analyze each option:

A . To offer the best value office fitting service: While this aligns somewhat with the mission, it is

more of a value proposition or operational goal rather than a visionary statement. It lacks the

aspirational and long-term focus that defines a vision.

B . To reduce the cost of office fitting by 5%: This is a specific, measurable objective, but it is too

narrow and tactical to qualify as a vision. Visions are broader and not tied to specific metrics.

C . To increase the company's market share: Increasing market share is a strategic goal, but it is still

an intermediate step toward achieving something greater. It does not capture the overarching

ambition of the company.

D . To be the premier office fitting company: This option reflects a long-term aspiration and aligns

with the characteristics of a vision statement. It expresses the desire to achieve leadership and

excellence in the industry, which is consistent with the mission of being competitive on price while

aiming for a higher status.

According to the BCS Business Analysis Framework , a vision statement should inspire and guide the

organization toward its ultimate goal. Therefore, D is the most appropriate choice.

The Business Analysis Service Framework (BASF) identifies core and auxiliary services that support

business analysis activities. Auxiliary services supplement the core services and are essential for

delivering value.

Key Considerations:

Strategic Analysis: Focuses on high-level organizational goals and strategies but is not an auxiliary

service.

Stakeholder Engagement: Involves identifying, analyzing, and collaborating with stakeholders, which

supports all aspects of business analysis.

Project Management: While important, project management is a separate discipline and not part of

the BASF.

External Environment Analysis: Examines external factors (e.g., market trends) but is not an auxiliary

service.

Evaluation of Each Option:

A . Strategic analysis:

Strategic analysis is a core service, not an auxiliary service.

Conclusion: This is not correct .

B . Stakeholder engagement:

Stakeholder engagement is an auxiliary service that supports all business analysis activities by

ensuring stakeholder needs are understood and addressed.

Conclusion: This is correct .

C . Project management:

Project management is outside the scope of the BASF.

Conclusion: This is not correct .

D . External environment analysis:

External environment analysis is a core service, not an auxiliary service.

Conclusion: This is not correct .

A benefits plan outlines how the anticipated benefits of a project or change initiative will be

achieved, tracked, and managed. Its primary purpose is to ensure that benefits are realized as

planned.

Key Considerations:

Tracking Changes to Requirements: A benefits plan focuses on benefits realization, not changes to

requirements.

Quantifying Intangible Benefits: While intangible benefits may be included, the primary focus is on

managing all benefits, tangible and intangible.

Tracking and Managing Benefits Realisation: The benefits plan provides a structured approach to

monitor progress and ensure benefits are delivered.

Publishing to Shareholders: While stakeholders may review the plan, its primary purpose is internal

management, not external communication.

Evaluation of Each Option:

A . It provides a firm basis for tracking the benefits of making changes to requirements:

The benefits plan focuses on overall benefits realization, not specifically on changes to requirements.

Conclusion: This is not correct .

B . It quantifies intangible benefits that could not be quantified when the business case was

presented:

While intangible benefits may be included, this is not the primary purpose of the plan.

Conclusion: This is not correct .

C . It provides a firm basis for tracking the business benefits and managing their realisation:

This accurately describes the primary purpose of a benefits plan.

Conclusion: This is correct .

D . It is published to shareholders to show that their investment made will result in tangible benefits

for the organisation:

The benefits plan is primarily for internal use, not external reporting.

Conclusion: This is not correct .

Final Recommendation:

The primary purpose of a benefits plan is:

C . It provides a firm basis for tracking the business benefits and managing their realisation.

:

The hierarchy of requirements organizes requirements into levels (e.g., business needs, stakeholder

requirements, solution requirements) to ensure alignment and traceability. Let’s evaluate each

statement to determine which is false .

Key Characteristics of the Requirements Hierarchy:

Linking Requirements: The hierarchy ensures that detailed requirements are connected to higher-

level business needs and objectives.

Order of Development: The hierarchy does not dictate the sequence in which requirements should

be developed; it focuses on relationships and dependencies.

Driven by Strategy: Requirements are derived from the organization's values, strategy, and

objectives.

Traceability: The hierarchy links different types of requirements to ensure consistency and alignment.

Evaluation of Each Statement:

A . The requirements hierarchy enables detailed requirements to be linked to the business need:

This is true; the hierarchy ensures traceability between high-level and detailed requirements.

Conclusion: This is true .

B . The requirements hierarchy shows the order in which requirements should be developed:

The hierarchy does not specify the development order; it focuses on relationships and dependencies.

Conclusion: This is false .

C . Requirements are driven by the organisation's values, strategy and objectives:

This is true; requirements must align with organizational goals.

Conclusion: This is true .

D . The requirements hierarchy links different requirements to each other:

This is true; the hierarchy ensures traceability and alignment across levels.

Conclusion: This is true .

Final Recommendation:

The false statement is:

B . The requirements hierarchy shows the order in which requirements should be developed.

When documenting risks in a business case, it is essential to follow structured processes to ensure

risks are appropriately identified, analyzed, and managed. Let’s evaluate each option again based on

best practices outlined in the BCS Business Analysis Framework and other methodologies:

Key Considerations:

Risk Documentation: Risks must be recorded systematically to ensure they are visible, actionable,

and traceable.

Ownership of Risks: Assigning ownership ensures accountability and clarity about who is responsible

for monitoring and mitigating each risk.

Risk Management Lifecycle: The process typically involves identification, documentation,

assessment, ownership assignment, and response planning.

Evaluation of Each Option:

A . Create a RAID log

A RAID log (Risks, Assumptions, Issues, and Dependencies) is a widely used tool in business analysis

and project management for capturing and managing risks systematically.

It provides a centralized repository for tracking risks, assumptions, issues, and dependencies,

ensuring that risks are documented comprehensively and transparently.

This aligns with best practices for risk management and is a critical first step in ensuring risks are

appropriately recorded.

Conclusion: This is a must-do action.

B . Document the source of each risk

While documenting the source of each risk can provide valuable context, it is not a mandatory or

primary step in the initial documentation phase.

Sources of risks are often identified during risk analysis or root cause analysis, which occurs after

risks have been recorded.

Although useful, this step is secondary to creating a RAID log and assigning ownership.

Conclusion: This is not the most critical action at this stage.

C . Identify an owner for each risk

Assigning ownership for each risk is a fundamental part of risk management. Without clear

ownership, risks may remain unmonitored or unaddressed.

Ownership ensures accountability and helps streamline communication and decision-making

regarding risk mitigation strategies.

According to the BCS Business Analysis Framework , identifying risk owners is a key responsibility

during the risk documentation process.

Conclusion: This is a must-do action.

D . Provide justification for each countermeasure identified

Justifying countermeasures is part of the risk response planning phase, which occurs after risks have

been documented, assessed, and prioritized.

At this stage, John’s focus should be on identifying and recording risks, not on evaluating or justifying

solutions.

Conclusion: This is not relevant at the documentation stage.

E . Impact assessment of each countermeasure identified

Similar to option D, impact assessments for countermeasures are conducted during the risk response

planning phase, not during the initial documentation phase.

This step is premature and does not align with the immediate need to document risks.

Conclusion: This is not relevant at the documentation stage.

Final Recommendation:

Based on the BCS Business Analysis Framework and industry best practices, the two most

appropriate actions for John are:

Create a RAID log (to systematically document risks).

Identify an owner for each risk (to ensure accountability and clarity).

These steps ensure that risks are appropriately recorded and managed, laying the foundation for

effective risk management.

The stakeholder wheel is a framework used to categorize stakeholders based on their relationship to

the organization or project. It typically includes categories such as customers, partners, suppliers,

regulators, and competitors , among others.

Key Considerations:

Regulators, Compliance, Owners: While regulators and owners are valid stakeholders, "compliance"

is not a stakeholder category but rather a function or responsibility.

Competitors, Customers, Partners: These are all valid stakeholder categories commonly found on the

stakeholder wheel.

Competitors, Consumers, Providers: While competitors and consumers (a synonym for customers)

are valid, "providers" is not a standard term used in the stakeholder wheel.

Contractors, Partners, Suppliers: Contractors are not typically included as a primary stakeholder

category on the stakeholder wheel, though partners and suppliers are.

Evaluation of Each Option:

A . Regulators, Compliance, Owners:

"Compliance" is not a stakeholder category; it refers to adherence to rules or regulations.

Conclusion: This is not correct .

B . Competitors, Customers, Partners:

These are all valid stakeholder categories found on the stakeholder wheel.

Conclusion: This is correct .

C . Competitors, Consumers, Providers:

While competitors and consumers (customers) are valid, "providers" is not a standard stakeholder

category.

Conclusion: This is not correct .

D . Contractors, Partners, Suppliers:

Contractors are not typically included as a primary stakeholder category on the stakeholder wheel.

Conclusion: This is not correct .

Final Recommendation:

The list that only includes stakeholders shown on the stakeholder wheel is:

B . Competitors, Customers, Partners

The Waterfall methodology is a linear approach where requirements are defined upfront, and

changes are difficult to accommodate once the project begins. Agile methodology , on the other

hand, emphasizes flexibility and adaptability to changing requirements.

Key Considerations:

Inherent Uncertainty in Cost: While cost uncertainty exists in both methodologies, Agile does not

specifically address this drawback of Waterfall.

Inflexibility to Changing Requirements: Waterfall's rigid structure makes it difficult to incorporate

changes once the project starts. Agile addresses this by allowing iterative development and

continuous feedback.

Capturing All Requirements Upfront: Agile does not aim to capture all requirements upfront; instead,

it embraces evolving requirements throughout the project.

Stakeholder Agreement on Scope Before Work Begins: Agile encourages ongoing collaboration with

stakeholders rather than requiring scope agreement upfront.

Evaluation of Each Option:

A . The agile methodology addresses the inherent uncertainty in cost associated with waterfall:

Agile does not specifically address cost uncertainty.

Conclusion: This is not correct .

B . Agile development addresses the inflexibility of waterfall as it pertains to changing requirements:

This is the primary drawback of Waterfall that Agile addresses through its iterative and flexible

approach.

Conclusion: This is correct .

C . The agile methodology captures all requirements at the start of a project to reduce risks typically

experienced in waterfall:

Agile does not capture all requirements upfront; it embraces evolving requirements.

Conclusion: This is not correct .

D . Agile development requires stakeholders to agree to the scope of the project before the work

begins, reducing uncertainty in the design:

Agile does not require upfront scope agreement; it promotes adaptive planning.

Conclusion: This is not correct .

Final Recommendation:

The drawback of Waterfall addressed in Agile is:

B. Agile development addresses the inflexibility of waterfall as it pertains to changing requirements.

Agile requirements validation ensures that requirements are clear, feasible, and actionable before

they are implemented in an iteration. This aligns with Agile principles of delivering value

incrementally and avoiding waste.

Key Considerations:

Accurate Estimation for Sprint Planning: While estimation is important, it is not the primary purpose

of requirements validation.

Correctness of Backlog Items: Ensuring correctness is part of validation but applies to all backlog

items, not just those allocated to an iteration.

Testing Requirements: Testing occurs during or after development, not as part of validation.

Readiness for Development: Validation ensures that requirements are well-defined, understood, and

feasible before they are developed.

Evaluation of Each Option:

A . To ensure estimation for sprint planning is accurate:

Estimation accuracy is important but not the primary purpose of validation.

Conclusion: This is not correct .

B . To ensure any requirements added to the backlog are correct:

Correctness applies to all backlog items, not just those allocated to an iteration.

Conclusion: This is not correct .

C . To ensure that requirements allocated to an iteration have been tested:

Testing occurs after development, not during validation.

Conclusion: This is not correct .

D . To ensure any requirements allocated to an iteration are ready to be developed:

This is the primary purpose of Agile requirements validation—to ensure requirements are clear,

actionable, and feasible before development begins.

Conclusion: This is correct .

Final Recommendation:

The purpose of Agile requirements validation is:

D . To ensure any requirements allocated to an iteration are ready to be developed.

Prototyping is a technique used to create a working model of a system or product to validate

requirements and gather feedback. Let’s evaluate each statement to determine which are false :

Evaluation of Each Statement:

A . Suitable for waterfall requirements elicitation:

Prototyping is generally not suitable for traditional waterfall methodologies because waterfall

follows a linear, sequential approach where requirements are defined upfront before development

begins. Prototyping, on the other hand, involves iterative feedback loops, which are more aligned

with Agile methodologies.

Conclusion: This statement is false .

B . Allows an analyst to confirm their understanding of requirements:

Prototyping enables analysts to validate their understanding of requirements by creating a tangible

representation of the system for stakeholders to review and provide feedback.

Conclusion: This statement is true .

C . Only suitable for Agile project environments:

While prototyping is commonly used in Agile environments due to its iterative nature, it is not

limited to Agile. Prototyping can also be used in hybrid or iterative waterfall projects to clarify

requirements and reduce ambiguity.

Conclusion: This statement is false .

D . Enables the elicitation of usability requirements:

Prototyping is particularly effective for gathering usability requirements because it allows

stakeholders to interact with a mock-up or early version of the system, providing insights into user

experience and interface design.

Conclusion: This statement is true .

An organization chart visually represents the structure of an organization, including roles,

responsibilities, and reporting relationships. By reviewing the organization chart, Sara can learn

specific details about the sponsor of her project.

Key Considerations:

Position in the company hierarchy: The organization chart clearly shows where the sponsor fits within

the company’s structure (e.g., senior leadership, middle management). This helps Sara understand

their level of authority and influence.

Span of control: The chart also reveals how many teams or individuals report to the sponsor,

providing insight into their scope of responsibility and decision-making power.

Culture within their team: While the chart may hint at team structure, it does not provide qualitative

information about team culture, which requires direct observation or interviews.

Scope of their responsibilities: The chart outlines reporting lines but does not explicitly detail the

specific responsibilities of the sponsor.

Preferred management style: Management style is a behavioral trait that cannot be inferred from an

organization chart alone.

Evaluation of Each Option:

A . Their position in the company hierarchy:

The organization chart explicitly shows the sponsor's position in the hierarchy, helping Sara

understand their level of authority.

Conclusion: This is relevant .

B . Their span of control:

The chart reveals how many people or teams report to the sponsor, indicating their span of control.

Conclusion: This is relevant .

C . The culture within their team:

Team culture is not represented in an organization chart. It requires additional qualitative data.

Conclusion: This is not relevant .

D . The scope of their responsibilities:

While the chart provides structural information, it does not specify the exact responsibilities of the

sponsor.

Conclusion: This is not relevant .

E . Their preferred management style:

Management style cannot be determined from an organization chart.

Conclusion: This is not relevant .