PC-BA-FBA-20 Practice Questions

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 true statements about workshops are b and c. Workshops are collaborative, structured meetings

involving multiple stakeholders. Statement (b) is true because having multiple stakeholders present

allows the facilitator (often the BA) to immediately cross-check and resolve conflicting information or

assumptions in real-time. Statement (c) is true because the group environment, led by a skilled

facilitator, is highly effective for discussing differing viewpoints and working towards a consensus or

agreed-upon outcome. Statement (a) is false as this describes formal observation, not a workshop.

Statement (d) is false; workshops are primarily used to gather qualitative information (opinions,

requirements, process logic), not to collect accurate quantitative data (e.g., process timings or

volumes), which is usually obtained from documents or system logs.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice –

Investigative Techniques, Workshops)

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 .

One of the key principles of business analysis is to present stakeholders with options rather than

prescribing a single solution. This approach ensures that stakeholders can make informed decisions

based on their priorities and constraints.

Key Principles of Business Analysis:

Present Options Not Solutions: Business analysts should provide multiple viable options, allowing

stakeholders to choose the best course of action.

Understand Symptoms: While understanding symptoms is important, it is part of problem analysis,

not a key principle.

Focus on Requirements Definition Only: Business analysis encompasses more than just defining

requirements; it includes understanding problems, analyzing options, and ensuring value delivery.

Integrate IT Changes: While integrating IT changes is valuable, it is not a universal principle of

business analysis.

Evaluation of Each Option:

A . Present options not solutions:

This is a fundamental principle of business analysis, emphasizing stakeholder choice.

Conclusion: This is correct .

B . Understand the symptoms of the problem being defined:

Understanding symptoms is part of problem analysis but not a standalone principle.

Conclusion: This is not correct .

C . Focus on requirements definition only:

Business analysis involves more than just requirements definition.

Conclusion: This is not correct .

D . Integrate IT changes together with project requirements to improve efficiency:

While integration is valuable, it is not a universal principle of business analysis.

Conclusion: This is not correct .

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.

Successful business change must always be aligned with the strategy of the organisation. The

primary purpose of a business change initiative is to achieve a specific business objective, and these

objectives are derived directly from the organisation's overall strategy. If a proposed change,

whether it's a new system, a process overhaul, or an organisational restructuring, does not support

the strategic goals (such as increasing market share, improving efficiency, or enhancing customer

satisfaction), it is unlikely to be approved or to deliver true value. The Business Analysis approach,

particularly in the initial stages of a project, focuses heavily on understanding the strategic context

and ensuring that the needs being addressed are strategic needs. This alignment is crucial for the

Business Case to be justifiable and for the final solution to be judged as successful, as success is

ultimately measured by the achievement of strategic goals.

(Reference: BCS Foundation Certificate in Business Analysis / BCS Business Analysis Practice –

Strategic Context & Rationale for Business Analysis)

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

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