PC-BA-FBA-20 Questions and Answers

To identify the generic business improvement strategy that involves eliminating redundant tasks, we need to analyze each option:

Key Considerations:

Change task sequence: This strategy involves reordering tasks to improve efficiency but does not necessarily eliminate redundancy.

Simplification: This strategy focuses on streamlining processes by removing unnecessary or redundant tasks, making workflows more efficient.

Redefine boundary: This strategy involves changing the scope or boundaries of a process, which may or may not involve eliminating redundant tasks.

Bottleneck removal: This strategy targets specific constraints or bottlenecks in a process but does not focus on eliminating redundant tasks.

Evaluation of Each Option:

A. Change task sequence: Changing the order of tasks does not inherently eliminate redundancy. Conclusion: This is not correct .

B. Simplification: Simplification directly involves identifying and removing redundant or unnecessary tasks to streamline processes. Conclusion: This is correct .

C. Redefine boundary: Redefining boundaries changes the scope of a process but does not specifically target redundancy. Conclusion: This is not correct .

D. Bottleneck removal: Removing bottlenecks addresses constraints but does not focus on eliminating redundant tasks. Conclusion: This is not correct .

Personas are fictional but evidence-based representations of typical users or customer groups. They help business analysts and design teams understand user goals, behaviours, needs, frustrations, and motivations. Personas are often developed from user research and can be based on generic user roles, then enriched with characteristics that make them realistic and useful for analysis. They are not equivalent to a RACI chart because RACI defines responsibility, accountability, consultation, and information responsibilities for tasks. A single real user may also perform multiple roles, so option B is too restrictive. Personas are useful in user-centred design and requirements analysis, but they are not mandatory for decision analysis. Therefore, the true statement is that personas are taken from generic user roles.

The Iterative (or Agile) lifecycle model is specifically designed to deal with changing requirements and a rapid pace of change. Unlike linear models like Waterfall or the V model, which expect requirements to be fixed early, the iterative model delivers the solution in a series of repeated cycles (iterations/sprints). This approach embraces the reality that requirements will change as stakeholders learn more about the evolving product and the business environment shifts. It explicitly incorporates frequent feedback loops and allows for the adaptation of requirements throughout the project, making it the most flexible and suitable model for unstable or complex environments.

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

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.

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.

Critical success factors define the areas where an organisation must perform well to achieve its objectives. They are broad success areas, such as improving customer service, reducing operating costs, increasing market share, or improving product quality. Key performance indicators are measurable values used to monitor whether those success factors are being achieved. Therefore, KPIs track progress against CSFs. CSFs are not sub-targets within KPIs; the relationship works the other way around. KPIs also are not measured by CSFs because CSFs are qualitative success areas, while KPIs are measurable indicators. For example, if a CSF is “provide excellent customer service,” relevant KPIs might include complaint numbers, customer satisfaction scores, repeat customer percentage, or response times. This makes option C the correct relationship.

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)

Gap analysis is a structured process used to identify the differences between the current state (as-is) and the desired future state (to-be). The first step in this process involves understanding the current situation.

Key Steps in Gap Analysis:

Assemble representations of the existing situation: This involves documenting the current state, including processes, systems, and capabilities.

Compare representations of the existing and target situations: After understanding the current state, it is compared with the desired future state to identify gaps.

Identify gaps to be addressed: Once gaps are identified, they are prioritized based on their impact and feasibility.

Consider possible actions to address the gaps: Finally, potential solutions or actions are developed to bridge the identified gaps.

Evaluation of Each Option:

A. Assemble representations of existing situation: Understanding the current state is the foundational step in gap analysis. Without this, there is no baseline for comparison. Conclusion: This is correct .

B. Consider possible actions to address the gaps: This is a later step in the process, not the first. Conclusion: This is not correct .

C. Compare representations of the existing and target situations: Comparison occurs after the current state has been documented. Conclusion: This is not correct .

D. Identify gaps to be addressed: Identifying gaps follows the documentation and comparison steps. Conclusion: This is not correct .

Final Recommendation:

The first step in the gap analysis process is:

A. Assemble representations of existing situation.

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 .

Gap analysis is a technique for comparing the current state of the business ( ' As Is ' ) with the desired future state ( ' To Be ' ) to identify what is missing and what needs to change. The logical first step is to establish the current starting point. Therefore, the process begins by:

Assemble representations of existing situation (The ' As Is ' model). This involves investigating and documenting the current processes, organisation, people, information, and technology (POPIT).

Assemble representations of target or desired situation (The ' To Be ' model).

Identify gaps to be addressed (The difference between As Is and To Be).

Consider possible actions to address the gaps (Developing the recommendations).

(Reference: BCS Business Analysis Practice – Gap Analysis)

===========

The BCS Business Change Lifecycle (which governs the entire change process from initial alignment to final benefit verification) typically comprises five key stages: Alignment, Definition, Design, Implementation, and Realisation. Realisation is the final, crucial stage where the actual benefits and expected business outcomes from the implemented solution are reviewed, measured, and confirmed against the original Business Case. Options A, B, and C are important activities or concepts that occur within the lifecycle but are not one of the five named stages of the complete end-to-end lifecycle model.

(Reference: BCS Business Analysis Practice – Business Change Lifecycle)

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.

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.

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 .

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

Workshops are structured meetings designed to achieve specific objectives through group participation. Regardless of the workshop ' s focus, collaboration is a fundamental goal.

Key Considerations:

Collaboration: Workshops bring stakeholders together to share ideas, solve problems, and make decisions collaboratively.

Reviewing the Business Case: While reviewing the business case may be a specific objective of some workshops, it is not a universal goal.

Creating Mind Maps and Process Models: These are tools or outputs of workshops, not overarching goals.

Brainstorming Ideas: Brainstorming is a technique used in workshops but is not the ultimate goal of all workshops.

Evaluation of Each Option:

A. Collaboration: Collaboration is the core purpose of workshops, enabling participants to work together effectively. Conclusion: This is correct .

B. Reviewing the business case: This is a specific objective, not a universal goal of all workshops. Conclusion: This is not correct .

C. Creating mind maps and process models: These are tools or outputs, not goals. Conclusion: This is not correct .

D. Brainstorming ideas: Brainstorming is a technique, not the overarching goal of all workshops. Conclusion: This is not correct .

Final Recommendation:

The goal of all workshops is:

A. Collaboration.

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)

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.

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)

To determine the best source of information for Natasha to understand how Halliday Holdings ' brand is perceived, we need to evaluate the options based on their relevance and objectivity.

Evaluation of Each Option:

A. Independent industry websites: Independent industry websites often provide unbiased insights into how a company ' s brand is perceived by customers, competitors, and the market. These sources aggregate reviews, ratings, and expert opinions, making them a valuable resource for understanding external perceptions. Conclusion: This is the best source .

B. The company website: The company website reflects the organization ' s internal perspective and branding efforts. While useful for understanding how the company presents itself, it does not provide an external view of brand perception. Conclusion: This is not the best source .

C. The company ' s organizational structure: The organizational structure provides insights into the company ' s internal hierarchy and operations but does not relate to external brand perception. Conclusion: This is not relevant .

D. The company ' s complaints procedures: Complaints procedures reflect internal processes for handling customer issues but do not provide a comprehensive view of overall brand perception. Conclusion: This is not the best source .

Actor-task level analysis looks at detailed work performed by specific actors, roles, or users. At this level, a task can be broken into smaller steps, inputs and outputs can be identified, and performance measures can be applied to assess efficiency, quality, or timeliness. Therefore, options B, C, and D are valid statements about actor-task analysis. Value chain analysis, however, is not used at this detailed actor-task level. It is an enterprise-level technique used to understand how organisational activities create value for customers. It examines primary and support activities across the business, not the detailed steps performed by a particular actor. Because value chain analysis belongs at a higher level of business process analysis, option A is the false statement.

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)

===========

In a UML Use Case Diagram, the entities that interact with the system being modeled (the System Boundary) are called Actors. An Actor represents a role played by a user, piece of hardware, or another system. External systems that exchange information with the system being defined are always represented as an actor outside the system boundary, just like human users. This clearly separates the responsibilities of the system under study from all entities and systems that lie outside its scope.

(Reference: BCS Requirements Engineering – Use Case Modelling)

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 .

To determine the best way to present the changes to the scheduling team, we need to consider the nature of the information being communicated and the audience (the scheduling team). The extract describes changes to processes, roles, and systems, which are best represented visually to ensure clarity and understanding.

Key Considerations:

Business Process Model (BPM): A BPM is a visual representation of the steps in a process. It is particularly useful for communicating changes to workflows, roles, and responsibilities. Since the extract discusses splitting the scheduling team into two groups and introducing new software and processes, a BPM would effectively illustrate how these changes impact the workflow.

Business Activity Model (BAM): A BAM focuses on high-level activities and their logical dependencies, often used in strategic planning. However, it is less detailed than a BPM and may not adequately capture the specific changes to scheduling processes.

POPIT (People, Organization, Process, Information, Technology): POPIT is a framework for analyzing business change across multiple dimensions. While it provides a holistic view, it is not a presentation tool and would not be the best choice for directly communicating the changes to the scheduling team.

Prototype: A prototype is typically used to demonstrate the functionality of a system or software. While the introduction of telephony software and an online booking system could involve prototyping, this option does not address the need to communicate process and role changes.

Evaluation of Each Option:

A. Business Process Model: A BPM is ideal for illustrating the changes to the scheduling process, including the split into inpatient and outpatient teams and the integration of new software. It provides a clear, step-by-step visual representation that the scheduling team can easily understand. Conclusion: This is the best option .

B. Business Activity Model: While a BAM could provide a high-level overview of the changes, it lacks the detail needed to explain specific process adjustments. Conclusion: This is not the best option .

C. POPIT: POPIT is a framework for analysis, not a communication tool. It would not effectively convey the changes to the scheduling team. Conclusion: This is not the best option .

D. Prototype: Prototyping is relevant for demonstrating software functionality but does not address the need to communicate process and role changes. Conclusion: This is not the best option .

Final Recommendation:

The changes should be presented using a Business Process Model , as it effectively communicates the revised workflows and roles to the scheduling team.