PC-BA-FBA-20 BCS Foundation Certificate in Business Analysis V4.1 Questions and Answers

Scenario development (often linked to Use Case analysis) is a technique that uses narrative descriptions to explore how a business process or a proposed system feature will work. The process of creating a full scenario typically involves several steps: establishing the context, defining the main success scenario, and then exploring alternatives. The step where the handling of unusual conditions or outcomes is considered is Identify exception situations. Exceptions are the circumstances that cause the main path of a process or interaction to be interrupted or fail, and they represent unusual or undesirable deviations from the expected flow. These conditions, which could include error messages, data unavailability, or system failures, must be thoroughly analyzed and documented to ensure the proposed solution is robust and complete. This step is distinct from identifying the main tasks (A) or the normal flow sequence (B).

(Reference: BCS Requirements Engineering / BCS Business Analysis Practice – Scenarios and Use Cases)

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.

 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 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

In Agile, the Product Backlog is an ordered list of work that may be needed to improve or deliver the product. It normally contains user stories, features, defects, technical work, and other backlog items. It is prioritised so that the highest-value or most urgent items are considered first. It also contains work that may be selected for future sprints. However, once items are selected for the current sprint, they become part of the Sprint Backlog, which is the development team’s plan for the sprint. Therefore, the Product Backlog does not specifically represent what the team is working on in the current sprint. That is the purpose of the Sprint Backlog. Option C is therefore the statement that is not 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 .

The Waterfall lifecycle is a sequential approach where phases such as requirements, design, build, test, and implementation are completed in order. Its advantages include strong project control, clear documentation, formal stage approval, and greater predictability around scope, schedule, and cost. These features can be useful where requirements are stable and governance is strict. However, Waterfall is weak when business requirements change frequently. Because requirements are defined early and later stages depend on earlier sign-off, changes can be expensive, slow, and disruptive. Agile and iterative approaches were developed partly to address this weakness by allowing evolving requirements and incremental delivery. Therefore, “quickly and inexpensively reacts to changes in business requirements” is not an advantage of Waterfall. The correct answer is option C.

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)

In an iterative or Agile lifecycle, requirements are not defined entirely upfront but are explored and refined just-in-time, immediately prior to implementation. The stage where the detailed solution requirements (functional and non-functional) are elaborated, modeled, and defined—ready for construction—is the Develop solution stage (often referred to as the Implementation or Construction phase of an iteration/sprint). The detailed work of defining, modelling, and validating the specific requirements happens as a preparatory step for the actual build, distinguishing it from the preceding planning phase (C) or the upstream strategic work (A, B).

(Reference: BCS Requirements Engineering – Lifecycle Models, Iterative Development)

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 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.

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)

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 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 .

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.

Scenario analysis is an investigation technique used to explore and evaluate potential future scenarios or situations. It helps stakeholders understand how different factors might impact a business area or process.

Key Characteristics of Scenario Analysis:

Broad View: Scenario analysis provides a comprehensive understanding of the business area by considering multiple possible outcomes.

Prototyping Basis: The insights gained from scenario analysis can inform the development of prototypes.

Tacit Knowledge Identification: By exploring real-world scenarios, it helps uncover implicit knowledge embedded in business practices.

Testing Scripts: Scenario analysis is not directly involved in preparing test scripts, which are typically created during the testing phase.

Evaluation of Each Option:

A. Provides a broad view of the business area under investigation: Scenario analysis evaluates multiple possibilities, offering a broad perspective. Conclusion: This is true .

B. Provides a basis for developing subsequent prototypes: Insights from scenario analysis can guide prototype development. Conclusion: This is true .

C. Helps identify tacit knowledge used in business practice: Exploring scenarios uncovers hidden knowledge and practices. Conclusion: This is true .

D. Helps prepare the scripts that will be used to test the delivered solution: Preparing test scripts is part of testing activities, not scenario analysis. Conclusion: This is false .

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 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 customer journey is used to understand the experience from the customer’s point of view as they interact with an organisation, product, service, or process. It helps identify customer touchpoints, expectations, frustrations, emotions, and pain points across the end-to-end journey. Although customer journey analysis may later highlight process improvements, its most direct purpose is not internal process redesign. Value chain analysis is used to understand organisational activities that create value, not customer experience. Balancing employee and customer interactions may be a secondary consideration, but it is not the core purpose. The customer journey technique is especially useful in service improvement, digital transformation, and customer experience work because it exposes what the customer sees and feels, rather than only what the organisation’s internal process model shows.

Traceability links requirements to other project artefacts. There are two main types: horizontal and vertical. Horizontal traceability (Option A) links a requirement forward to its design, code, and test cases, and backward to its source (Option D), tracing its lifecycle from inception to delivery. Vertical traceability concerns tracing a requirement up or down the requirements hierarchy (C). This ensures that lower-level requirements (e.g., functional) are aligned with and fully support the higher-level business objectives, policies, and strategy. For example, it traces a solution requirement up to the business requirement it satisfies, validating that every low-level detail is necessary and justified by a high-level business need.

(Reference: BCS Requirements Engineering – Requirements Traceability)

The technique focused on analyzing the fit between an organisation ' s offerings and customer needs, specifically examining the combination of product and service attributes, the company ' s image, and the customer relationship, is the Value Proposition. The Value Proposition describes the unique benefits, value, and experience that a company promises to deliver to its customers to satisfy their needs and wants better than the competition. It ' s a critical tool for ensuring that the business improvement efforts are truly valuable from a customer ' s perspective. Porter ' s Five Forces and SWOT analysis are macro-strategic tools, and SIPOC is a process analysis technique.

(Reference: BCS Business Analysis Practice – Improving Business Services and Processes, Value Proposition)

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)

===========

The power/interest grid is a tool used in stakeholder analysis to categorize stakeholders based on their level of power (influence) and interest in the project. The position of stakeholders on the grid reflects their current status.

Key Considerations:

Where the Stakeholders Will Be After the Proposed Change: The grid represents the current state, not future projections.

Where the Stakeholders Should Be: The grid does not prescribe ideal positions but reflects actual positions.

Where the Stakeholders Actually Are at a Point in Time: The grid is a snapshot of stakeholders ' current power and interest levels.

Where the Stakeholders Believe They Should Be: The grid is based on objective analysis, not subjective beliefs.

Evaluation of Each Option:

A. Where the stakeholders will be after the proposed change: The grid reflects the present, not future states. Conclusion: This is not correct .

B. Where the stakeholders should be: The grid does not prescribe ideal positions but reflects actual positions. Conclusion: This is not correct .

C. Where the stakeholders actually are at a point in time: This accurately describes the purpose of the power/interest grid. Conclusion: This is correct .

D. Where the stakeholders believe they should be: The grid is based on objective analysis, not subjective beliefs. Conclusion: This is not correct .

Final Recommendation:

The position of stakeholders on a power/interest grid represents:

C. Where the stakeholders actually are at a point in time.

The Requirements Catalogue (or the Requirements Specification section) is the comprehensive, organised list of all types of requirements. Technical Requirements are the non-functional constraints placed on the solution ' s design or build (e.g., specific hardware, operating system compatibility, integration protocols). While these inform other models, they are typically documented and tracked with other requirements (Functional and Non-functional) in the master Requirements Catalogue, often within the Non-functional or System Requirements section of the catalogue structure. Options A, B, and C are supporting documents or models, not the primary repository for a list of technical requirements.

(Reference: BCS Requirements Engineering – Requirements Catalogue Structure)

Kaplan and Norton ' s Balanced Business Scorecard is a strategic framework that evaluates organizational performance across four key perspectives: Financial, Customer, Internal Business Processes, and Learning and Growth . To determine which area has not been considered, we need to map the provided KPIs to these perspectives.

Mapping the KPIs:

The time to deliver orders for products: This relates to operational efficiency and falls under the Internal Business Process perspective.

Consumer satisfaction with products: This directly measures customer experience and falls under the Customer perspective.

Wastage in product production: This also relates to operational efficiency and falls under the Internal Business Process perspective.

The qualifications of production employees: This measures employee capabilities and development, falling under the Learning and Growth perspective.

Evaluating Each Perspective:

Financial: None of the provided KPIs address financial performance, such as revenue, profitability, or cost management. Conclusion: This perspective has not been considered .

Customer: Consumer satisfaction with products is a clear indicator of the Customer perspective. Conclusion: This perspective has been considered.

Internal Business Process: Both " time to deliver orders " and " wastage in production " relate to internal processes. Conclusion: This perspective has been considered.

Learning and Growth: The qualifications of production employees indicate employee development, which aligns with this perspective. Conclusion: This perspective has been considered.

Final Recommendation:

The Financial perspective has not been considered in the company’s KPIs.

Feasibility assessment is a critical part of developing the Business Case and typically involves four key areas: Business, Technical, Financial, and Legal/Ethical. The assessment that addresses whether a proposed solution or change initiative aligns with the organisation ' s overall objectives, mission, and strategy is Business Feasibility. This check is vital because if a proposal does not support the strategic direction, it will not deliver the expected value, regardless of its technical or financial viability. It ensures that the change is the right thing for the business to do at a strategic level.

(Reference: BCS Business Analysis Practice – Feasibility Assessment, Business Case Development)

The Stakeholder Wheel (or Stakeholder Interest Groupings) is a model used to categorize stakeholders in the strategic analysis phase, particularly for external environment analysis. This technique groups stakeholders based on their primary relationship to the organisation. The key groups included in the stakeholder wheel are Suppliers, Customers, Competitors, Partners, Owners (Shareholders), Regulators/Government, Media, and Employees/Trade Unions. Based on the options provided, the group that contains three valid, distinct categories from this standard model is Regulators, Auditors, Owners. While ' Auditors ' can be considered part of the ' Regulators ' or ' Owners ' (depending on their role), and ' Owners ' are often Shareholders, this option best reflects the high-level external interest groups used for broad strategic categorization compared to the internal focus of B or the mixed categories of A and C. The inclusion of Regulators and Owners is essential for any strategic stakeholder analysis.

(Reference: BCS Business Analysis Practice – Stakeholder Analysis, Stakeholder Wheel)