Free Practice Questions for the BCS Business Analysis PC-BA-FBA-20 Exam (2026 Updated)

Value chain analysis examines how an organisation creates value for customers through a set of linked activities. Porter’s value chain separates activities into primary activities and support activities. Primary activities are directly involved in creating, delivering, marketing, and servicing products or services, such as inbound logistics, operations, outbound logistics, marketing and sales, and service. Support activities enable the primary activities to operate effectively, such as procurement, technology development, human resource management, and infrastructure. Activity sampling is an investigation technique, not a value chain category. Stakeholder management concerns engagement with stakeholder groups and does not show operational value creation. The phrase “primary and secondary activities” is not the standard value chain distinction. The correct terminology is primary activities and support activities.

A RACI chart (Responsible, Accountable, Consulted, Informed) is a tool used to clarify roles and responsibilities in a project or process. Each role in the chart has a specific meaning:

Key Definitions:

Responsible: The person or role responsible for performing the task or completing the work.

Accountable: The person ultimately answerable for the task ' s completion and outcomes.

Consulted: Individuals or roles who provide input or expertise before decisions are made or tasks are completed.

Informed: Individuals or roles who need to be kept updated on progress or outcomes.

Evaluation of Each Option:

A. Responsible: The " Responsible " role is assigned to the person or team performing the task. Conclusion: This is correct .

B. Accountable: The " Accountable " role ensures the task is completed but does not necessarily perform the task. Conclusion: This is not correct .

C. Consulted: The " Consulted " role provides input or advice but does not perform the task. Conclusion: This is not correct .

D. Informed: The " Informed " role receives updates but is not involved in task execution. Conclusion: This is not correct .

Final Recommendation:

The category assigned to the role or person performing the task is:

A. Responsible.

The Project Sponsor is the senior executive or manager who owns the project, champions it, secures funding, and holds ultimate accountability for the benefits. While they are the most important stakeholder and sign off on the requirements, they are typically NOT an active, day-to-day working member of the project team responsible for executing the Requirements Engineering activities. The Project Manager (A), Business Analyst (C), and Software Tester (D) are all core, active members of the project team with specific roles in managing, defining, and validating the requirements, respectively.

(Reference: BCS Requirements Engineering – Roles in Requirements Engineering)

To determine which measures are appropriate Key Performance Indicators (KPIs) for the Critical Success Factor (CSF) " provide excellent customer service, " we must first understand the relationship between CSFs and KPIs:

Critical Success Factors (CSFs): These are the essential areas or activities that an organization must excel at to achieve its goals. In this case, " provide excellent customer service " is a CSF.

Key Performance Indicators (KPIs): These are measurable metrics used to evaluate progress toward achieving a CSF. KPIs should directly align with the CSF and provide actionable insights.

Now, let’s evaluate each option to determine whether it is an appropriate KPI for the CSF " provide excellent customer service " :

A. The number of customers who make use of their in-room mini bar

This measure tracks customer behavior related to a specific hotel amenity (the mini bar). While it may indicate customer satisfaction with the room ' s offerings, it does not directly measure the quality of customer service.

Conclusion: This is not an appropriate KPI for the CSF " provide excellent customer service. "

B. The percentage of customers who use the leisure facilities

This measure tracks how many customers utilize the hotel ' s leisure facilities (e.g., gym, pool, spa). While it may reflect customer engagement with the hotel ' s amenities, it does not directly assess the quality of customer service.

Conclusion: This is not an appropriate KPI for the CSF " provide excellent customer service. "

C. The number of customers who complain

Customer complaints are a direct indicator of dissatisfaction and can highlight areas where customer service needs improvement. A high number of complaints suggests poor customer service, while a low number indicates better service quality.

This measure is closely aligned with the CSF " provide excellent customer service " because it provides actionable feedback on service performance.

Conclusion: This is an appropriate KPI for the CSF.

D. The percentage of customers who join the hotel loyalty scheme

Customers are more likely to join a loyalty scheme if they have had a positive experience with the hotel, including excellent customer service. This measure reflects customer satisfaction and loyalty, which are outcomes of good service.

Conclusion: This is an appropriate KPI for the CSF.

E. The percentage of customers who return

Repeat customers are a strong indicator of customer satisfaction and loyalty, which are directly influenced by the quality of customer service. If customers return to the hotel, it suggests they were satisfied with their previous experience, including the service they received.

Conclusion: This is an appropriate KPI for the CSF.

The T-shaped professional model is used in business analysis to describe the ideal mix of skills and knowledge. The ' T ' shape consists of a vertical bar and a horizontal bar. The vertical bar represents the deep and specific domain knowledge or core expertise (e.g., business analysis techniques, specific industry knowledge). The horizontal bar (the top of the ' T ' ) represents the multi-disciplinary breadth of skill and knowledge that an individual can apply to various situations. This breadth includes soft skills like communication, facilitation, leadership, and a broad understanding of different business areas (like finance, operations, IT, and strategy). It is this breadth that allows the business analyst to collaborate effectively across different teams and disciplines, understand the context of the change, and recommend truly holistic solutions.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice – Competencies of a Business Analyst)

A change strategy outlines how an organization will move from its current state to its desired future state. Its purpose is to ensure a structured and effective transition.

Key Considerations:

Ensuring the simplest way for transition: While simplicity is desirable, it is not the primary purpose of a change strategy.

Ensuring the quickest way for transition: Speed is not the main focus; effectiveness and alignment with goals are more important.

Achieving the transition between current state and future state: This accurately describes the purpose of a change strategy, which is to bridge the gap between where the organization is now and where it wants to be.

Mapping the alternative options: While mapping options may be part of the planning process, it is not the ultimate purpose of the change strategy.

Evaluation of Each Option:

A. Ensuring the simplest way for transition: Simplicity is a consideration but not the primary purpose of a change strategy. Conclusion: This is not correct .

B. Ensuring the quickest way for transition: Speed is secondary to achieving an effective and sustainable transition. Conclusion: This is not correct .

C. Achieving the transition between current state and future state: This is the core purpose of a change strategy, ensuring the organization moves effectively toward its goals. Conclusion: This is correct .

D. Mapping the alternative options: Mapping options is part of the analysis phase, not the overarching purpose of the strategy. Conclusion: This is not correct .

Final Recommendation:

The best description of the purpose of a change strategy is:

C. Achieving the transition between current state and future state.

A business analyst is responsible for understanding business needs, analysing problems, eliciting requirements, exploring options, and helping stakeholders define valuable change. Options A, B, and D are all normal business analysis responsibilities. The analyst investigates the business situation, identifies needs, supports option development, and uses elicitation techniques such as interviews, workshops, observation, and document analysis to understand requirements. Ensuring that projects are delivered within budget constraints is primarily a project management responsibility. A project manager controls project delivery, manages schedule, cost, resources, risks, and progress against the approved plan. The business analyst may contribute estimates or impact analysis, but they do not normally own budget delivery. Therefore, option C is least likely to be a business analyst responsibility.

The investigation technique best suited to achieve these outcomes is the Interview. A one-on-one interview provides a private and focused setting, which is essential for discussing confidential or politically sensitive issues that a stakeholder would not be comfortable raising in a group or on a written questionnaire. The personal interaction during an interview is the most effective way to build rapport with the stakeholder, leading to more open and honest communication. This deeper level of trust and detailed conversation is what allows the analyst to gain a richer appreciation of the political and cultural landscape of the business. Special purpose records, document analysis, and questionnaires are more impersonal and cannot provide the same level of qualitative insight or trust.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice – Investigative Techniques, Interviews)

A benefits dependency network shows how business objectives, expected benefits, enabling business changes, and supporting outputs are connected. It helps analysts and stakeholders understand how a proposed change is expected to create value. The technique is useful because benefits are rarely achieved simply by delivering a system or product; they depend on business changes such as process redesign, behaviour change, training, new roles, or organisational adoption. Option B is too narrow because a benefits dependency network is not merely a stakeholder-benefit list. Option C describes cost breakdown, not benefit dependency. Option D describes requirements traceability, which is a different requirements management technique. The correct description is an overall representation linking objectives, benefits, and the business changes needed to realise those benefits.

Business processes are typically organised into a three-level hierarchy to manage complexity and provide a clear line of sight from strategy to execution. The standard levels, moving from the highest to the lowest level of detail, are:

Enterprise (or Value Chain): The highest level, showing the core business functions (e.g., " Sell Product, " " Develop Product " ).

Event-Response (or End-to-End): The mid-level, showing the process triggered by a business event and concluding with an outcome (e.g., " Handle Customer Order " ).

Actor-Task (or Detailed/Procedure): The lowest level, showing the individual steps and actions taken by the actors to complete a process (e.g., " Check stock availability, " " Package item " ).

Therefore, the three key levels that define this breakdown are Enterprise, event-response, actor-task.

(Reference: BCS Modelling Business Processes / BCS Business Analysis Practice – Business Process Hierarchy)

===========

Change control is a critical aspect of requirements management in business analysis. It ensures that changes to requirements are systematically evaluated, approved, and implemented without negatively impacting the project.

Key Considerations:

Change Control Definition: Change control is a formal process used to manage modifications to requirements, ensuring that changes are necessary, feasible, and aligned with project goals.

Version Numbering: While version numbering is part of documentation management, it is not the primary purpose of change control.

Preventing Changes: Change control does not prevent changes but ensures they are managed appropriately.

Tracing Requirements: Tracing requirements involves tracking their origin and impact, which is separate from managing changes.

Evaluation of Each Option:

A. A process to control version numbering: Version numbering is a documentation practice, not the purpose of change control. Conclusion: This is not correct .

B. A process to manage changes to requirements: This accurately describes change control as a structured approach to handling modifications to requirements. Conclusion: This is correct .

C. A process to ensure that changes cannot be made: Change control does not block changes but ensures they are managed effectively. Conclusion: This is not correct .

D. A process to trace requirements: Tracing requirements is a related but distinct activity focused on linking requirements to their source and impact. Conclusion: This is not correct .

The Requirements Engineering Framework describes the sequence of activities for defining and managing the requirements for a solution. The core activities typically include:

Requirements Elicitation (gathering requirements).

Requirements Analysis (checking, prioritizing, and modelling).

Requirements Documentation (recording in a catalogue or specification).

Requirements Validation (checking fitness for purpose and completeness).Requirements Traceability (linking requirements to their source, design, and tests) is a key aspect of Requirements Management, which is the overarching framework for handling requirements changes and status, but it is typically viewed as a component of the ongoing management process rather than a standalone core engineering activity on the same level as Elicitation or Validation.

(Reference: BCS Requirements Engineering – Requirements Engineering Framework and Activities)

===========

A Requirements Catalogue (or Requirements Specification) serves as the central repository for all documented requirements for a solution. BCS guidance categorises requirements hierarchically. At the highest level are the Business Requirements (often called General Requirements (c) and Technical Requirements (d)). These constrain the lower-level Solution Requirements, which consist of Functional Requirements (a) (what the system must do) and Non-functional Requirements (b) (quality attributes like performance, security, and usability). Since the catalogue aims to provide a complete picture of the business need and the proposed solution ' s capabilities, it must contain all four categories: Functional, Non-functional, General (Business), and Technical requirements.

(Reference: BCS Requirements Engineering – Requirements Categorisation and Documentation)

The concern of consumers about unnecessary packaging is an external factor that influences the organisation. The appropriate technique for systematically analysing these external macro-environmental factors is PESTLE analysis. PESTLE stands for Political, Economic, Sociological, Technological, Legal, and Environmental factors. The increasing consumer concern about packaging falls clearly under the Sociological or Environmental categories of the PESTLE framework. This technique helps the business analyst identify trends and issues arising from outside the organisation that may create a business need or risk, which then drives strategic change. The other options are incorrect: a Power/Interest grid is for stakeholder management; Boston Box (BCG Matrix) is for product portfolio management; and a Resource Audit is for internal analysis of resources.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice – Strategic Analysis, External Environment Analysis)

The Business Analysis Service Framework identifies services that business analysts may provide across the change lifecycle. Business acceptance testing is closely aligned with business analysis because it confirms whether the delivered solution meets business requirements and is acceptable from the business perspective. The business analyst often supports acceptance criteria, test scenario preparation, traceability from requirements to tests, and stakeholder validation. Regression testing is mainly a technical testing activity used to check that existing functionality has not been broken by changes. “Business analysis testing” is not a standard testing service, and “business user testing” is less precise than business acceptance testing. The key point is that business acceptance testing validates business fitness for purpose, not merely technical correctness. Therefore, option A is the correct BASF-specific testing service.

A class model is used to represent business objects or data entities and the relationships between them. Its core elements include classes, attributes, and associations. A class represents a type of business object, such as Customer, Order, or Product. Attributes describe the information held about each class, such as customer name or order date. Associations show how classes relate to each other, for example, a Customer places an Order. Dataflow is not an element of a class model. Dataflow belongs more naturally to process modelling or data flow diagrams, where the analyst shows how information moves between processes, actors, or systems. Since the question asks for the item that is NOT part of a class model, the correct answer is Dataflow.

MoSCoW prioritisation categorises requirements into Must have, Should have, Could have, and Won’t have for now. Must-have requirements are essential; without them, the solution would fail or be unacceptable. Should-have requirements are important but may be deferred if necessary. Could-have requirements are desirable and would add value, but they are not essential to business success or core solution viability. “Want to have” is not a standard MoSCoW category, although it sounds similar to informal prioritisation language. The wording “desirable but not essential” points directly to Could-have requirements. These are typically delivered only if time, budget, and capacity remain after higher-priority requirements are addressed. Therefore, option A is the correct MoSCoW category.

Regulators are stakeholders who define, monitor, or enforce rules, standards, legislation, and compliance obligations that affect an organisation. In business analysis, regulators may influence what changes are possible, acceptable, or mandatory. For example, financial, data protection, safety, or industry regulators may require proposed changes to comply with legal or professional standards. Partners may collaborate with the organisation, but they do not normally enforce rules. Managers control internal resources and operations, but they are not the external rule-enforcing stakeholder category. Owners have financial or strategic interest in the organisation, but they do not normally monitor regulatory compliance unless they also hold a governance role. Since the question asks who monitors whether proposed changes fall within enforced rules, the correct stakeholder category is Regulators.

Interviews are valuable in requirements elicitation because they allow the business analyst to explore stakeholder knowledge, experience, concerns, assumptions, and expectations through direct conversation. This is especially useful for uncovering tacit knowledge: knowledge that stakeholders possess but may not have formally documented. Through questioning and follow-up, the analyst can probe unclear points and understand motivations, constraints, and priorities. Option B describes observation, not interviewing. Option C describes workshops, which are better for group consensus and shared understanding. Option D describes surveys or questionnaires, which are better for collecting responses from a large population. Interviews are strongest where depth, context, and personal insight are required. Therefore, the key advantage is access to tacit knowledge through direct stakeholder dialogue.

The digital business analyst role focuses on leveraging technology to drive innovation and transformation. This variant of the business analyst role requires creative thinking, adaptability to rapid change, and the ability to exploit emerging technologies.

Key Characteristics of Business Analyst Roles:

Enterprise Business Analyst: Focuses on aligning business strategies and objectives across the organization.

Digital Business Analyst: Emphasizes innovation, digital transformation, and the adoption of emerging technologies.

Project Business Analyst: Works within project teams to define and deliver specific solutions.

Test Business Analyst: Specializes in ensuring requirements are met through testing and quality assurance.

Evaluation of Each Option:

A. Enterprise business analyst: While enterprise BAs focus on strategic alignment, they do not specifically emphasize innovation or emerging technologies. Conclusion: This is not correct .

B. Digital business analyst: This role explicitly involves thinking innovatively, embracing change, and leveraging emerging technologies. Conclusion: This is correct .

C. Project business analyst: Project BAs focus on delivering specific solutions rather than driving innovation or digital transformation. Conclusion: This is not correct .

D. Test business analyst: Test BAs focus on validation and quality assurance, not innovation or technology adoption. Conclusion: This is not correct .

Final Recommendation:

The variant of the business analyst role that needs to think innovatively and embrace change is:

B. Digital business analyst.

The true statements about formal observation are b and d. Formal observation is when a business analyst watches an individual or group perform their work. Statement (b) is true as observing the environment directly helps the analyst understand the physical business environment and how it influences the work. Statement (d) is true because observation is particularly effective for identifying tacit knowledge (unspoken or unwritten rules, shortcuts, or skills) that the worker may take for granted or find difficult to articulate during an interview. Statement (a) is false as observation is a passive technique, not suitable for actively negotiating or resolving conflicts, which is better suited for workshops or interviews. Statement (c) is false as observation does not actively engage a wide range of stakeholders to obtain buy-in.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice – Investigative Techniques, Observation)

A T-shaped professional is a concept used to describe individuals who possess a combination of broad and deep skills. Let’s evaluate each option to determine which best describes this concept:

Key Characteristics of a T-Shaped Professional:

Vertical Line (Deep Expertise): Represents specialized knowledge or expertise in one specific area.

Horizontal Line (Broad Skills): Represents a wide range of general skills or knowledge across multiple disciplines, enabling collaboration and adaptability.

Evaluation of Each Option:

A. T stands for Talented: While " talented " may describe the individual, the " T " specifically refers to the shape that visually represents their skill profile (broad and deep). Conclusion: This is not correct .

B. T-shaped professional has a deep level of skills in many areas: A T-shaped professional does not have deep expertise in many areas; they have deep expertise in one area and broad skills across others. Conclusion: This is not correct .

C. The crossbar of the T-shape represents having a good level of skills across many areas, and deep level of skills in a specialism: This accurately describes the T-shaped professional: the horizontal bar represents broad skills, and the vertical bar represents deep expertise in a specific area. Conclusion: This is correct .

D. A T-Shaped professional possesses a deep understanding in a given area and leads a team of people in other areas: While leadership may be a trait of some T-shaped professionals, it is not a defining characteristic of the concept. Conclusion: This is not correct .

Requirements documentation generally follows two main styles: text-based and diagrammatic (or model-based).

Data model (A), Use case model (C), and Business process models (D - e.g., UML Activity Diagrams or BPMN) are all forms of diagrammatic documentation, using standardised graphical notation to express requirements.

A User story (B) is a short, simple, text-based statement written in the format: " As a [role], I want [goal] so that [benefit] " . It is a form of text-based requirement documentation used primarily in Agile environments, not a diagrammatic style.

(Reference: BCS Requirements Engineering – Documentation Styles)

===========

The Use Case Diagram is a conceptual model that shows the interaction between users (actors) and the required features (use cases) of the system. In an Agile context, use cases provide a high-level view of the system ' s intended functionality, which can be directly mapped to Epics and subsequently decomposed into lower-level User Stories. The use case diagram helps the team understand the scope and the user ' s interaction paths, making it an excellent visual tool for managing and breaking down the product backlog (of user stories) into manageable chunks. The other options are too technical (A, D) or focus only on object state (B).

(Reference: BCS Requirements Engineering / BCS Agile – Use Case Modelling and Product Backlog Management)

The technique described is a Mind map. A Mind Map is a non-linear, visual tool used for structuring information and generating ideas around a central concept. It is characterized by having a central image or topic from which topic-related branches and sub-branches radiate. The structure helps the business analyst (or a group in a workshop) to organize complex, unstructured thoughts, visualize associations, and explore an area holistically. This technique is often used in the initial stages of investigation, such as problem analysis or requirements elicitation, to help gain a broad understanding of the scope and related issues. This is distinct from a Process map (which shows the flow of activities), an Entity relationship diagram (which models data structures), or the Business analysis process model (which models the BA ' s work steps).

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice – Investigative Techniques, Mind Maps)

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 .