BCS PC-BA-FBA-20 BCS Foundation Certificate in Business Analysis V4.1 Exam Practice Test

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 RACI chart is a technique used to clarify and document the roles and responsibilities for activities, tasks, or deliverables within a project or business process. It is an acronym that defines the four key types of involvement:

Responsible: The person or team who does the work to complete the task.

Accountable: The person who is ultimately answerable for the correct and thorough completion of the deliverable or task, and who approves the work. Only one person can be Accountable.

Consulted: The people whose opinions are sought, and with whom there is two-way communication.

Informed: The people who are kept up-to-date on progress, often only at the completion of the task or deliverable, and with whom there is only one-way communication.

The correct categories are therefore Responsible, Accountable, Consulted, Informed.

(Reference: BCS Business Analysis Practice – Stakeholder Management, RACI Matrix)

===========

The actor-task level is the lowest and most detailed level of the business process hierarchy. Its purpose is to show the sequence of actions and decisions taken by specific actors to complete a process. It effectively illustrates the work conducted within each individual task (often referred to as the procedure or work instruction). This level details how the work is performed.

Option A describes the Event-Response level (mid-level).

Option C is only part of the description—the actor is crucial, but the level shows the tasks they perform.

Option D describes the trigger for the Event-Response level.

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

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.

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 .

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.

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

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.

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

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.

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.

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.

One of the core principles of business analysis is the continuous need for negotiation and consensus building, particularly when dealing with conflicting stakeholder perspectives and requirements. Business analysis actively seeks to negotiate and resolve these conflicts rather than avoiding them, which is a key part of establishing a shared understanding of the problem and the proposed solution. The other options contradict established BA principles: the principle is to find root causes, not symptoms (leading to superficial and ineffective solutions); to investigate and evaluate multiple options, not just solutions (ensuring the optimal change is selected); and to focus on business improvement as the driver for any necessary IT system change, not the other way around. The BA role necessitates working across competing interests to reach a successful outcome, making negotiation a fundamental principle.

(Reference: BCS Business Analysis Practice – Principles of Business Analysis / Analysing and Managing Stakeholders)

Functional and non-functional requirements sit within the detailed requirements area and describe what the solution must do and how well it must perform. Functional requirements define required behaviour, services, processing, calculations, or interactions. Non-functional requirements define qualities and constraints such as performance, security, usability, availability, and reliability. In a requirements hierarchy, these requirements are developed from broader business, general, and technical requirement categories. Option B is too narrow because it describes mainly non-functional requirements, not functional requirements. Option D is wrong because the highest level is the business need or business requirement. Option A refers to project principles, not solution requirements. Therefore, functional and non-functional requirements are best described as an elaboration of General and Technical requirements.

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)

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

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)

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.

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.

The project sponsor owns the business justification for the change and is accountable for ensuring that the initiative delivers the intended business value. The sponsor champions the change, secures funding, provides strategic direction, resolves high-level issues, and remains focused on benefits realisation. Scheduling tasks, monitoring task progress, managing slippage, and controlling delivery against time and budget are mainly project management responsibilities. A project manager manages the delivery plan; the sponsor is concerned with whether the change produces the expected business benefits. The business case normally defines those benefits, and the sponsor is responsible for ensuring they are achieved or appropriately managed. Therefore, the sponsor’s responsibility is best represented by delivering the specific and agreed business benefits predicted in the business case.

To identify the stakeholder groups represented in the scenario, we need to analyze the relationships and roles described:

Stakeholder Groups in the Scenario:

Owner: The two founders of AlpineTrails, who each own 50% of the business, are clearly stakeholders as owners. They have a vested interest in the success of the business and its partnerships.

Partner: WalkNation is described as a partner organization that collaborates with AlpineTrails to offer special holidays for its members. This partnership involves shared responsibilities (marketing and booking by WalkNation, holiday organization by AlpineTrails).

Supplier: AlpineTrails books hotels, transport, and equipment to create bespoke holidays. These entities (hotels, transport providers, equipment suppliers) are suppliers to AlpineTrails and play a critical role in delivering the holidays.

Manager: While managers may exist within AlpineTrails, they are not explicitly mentioned in the scenario. Therefore, this group is not represented.

Competitor: Competitors are not mentioned or implied in the scenario, so this group is not represented.

Evaluation of Each Option:

A. Owner: The two founders of AlpineTrails are explicitly described as owners. Conclusion: This is a relevant stakeholder group .

B. Partner: WalkNation is explicitly described as a partner. Conclusion: This is a relevant stakeholder group .

C. Supplier: Hotels, transport, and equipment providers are implicitly described as suppliers. Conclusion: This is a relevant stakeholder group .

D. Manager: Managers are not explicitly mentioned in the scenario. Conclusion: This is not a relevant stakeholder group .

E. Competitor: Competitors are not mentioned or implied in the scenario. Conclusion: This is not a relevant stakeholder group .

To identify the categories of costs and benefits described in the extract, we need to analyze the content carefully:

Extract Analysis:

" New business policies and processes will be introduced, which may temporarily reduce productivity " :

This refers to a cost associated with implementing new policies and processes.

Productivity is an intangible factor because it cannot be directly measured in monetary terms.

Category: Intangible costs .

" It will ensure our products remain in the marketplace and be the first to receive compliance certification, which will enhance our reputation as the market leader " :

This refers to a benefit related to maintaining market presence, achieving compliance, and enhancing reputation.

Reputation and market leadership are intangible factors because they are qualitative and not directly quantifiable in monetary terms.

Category: Intangible benefits .

Evaluation of Each Option:

A. Tangible costs: Tangible costs are measurable financial expenses (e.g., equipment, labor). The extract does not mention any specific financial costs. Conclusion: This is not relevant .

B. Intangible costs: The temporary reduction in productivity is an intangible cost. Conclusion: This is relevant .

C. Tangible benefits: Tangible benefits are measurable financial gains (e.g., increased revenue). The extract does not mention any specific financial benefits. Conclusion: This is not relevant .

D. Intangible benefits: Enhanced reputation and market leadership are intangible benefits. Conclusion: This is relevant .

E. Irregular costs: Irregular costs refer to one-time or infrequent expenses. The extract does not describe such costs. Conclusion: This is not relevant .

A use case diagram is a visual representation of how users (or systems) interact with a system to achieve specific goals. Actors represent the entities (e.g., users or external systems) that expect to receive services from the system.

Key Elements of a Use Case Diagram:

Actors: Represent individuals or systems that interact with the system to achieve a goal.

System Boundaries: Define the scope of the system being modeled.

Users: While " users " may seem similar to actors, the term " actors " is the correct technical term in use case diagrams.

Entities: Entities typically refer to data objects or components, not those receiving services.

Evaluation of Each Option:

A. Actors: Actors are the correct element used to indicate those who expect to receive a service from the system. Conclusion: This is correct .

B. System boundaries: System boundaries define the scope of the system but do not represent those receiving services. Conclusion: This is not correct .

C. Users: While users may interact with the system, the correct term in use case diagrams is " actors. " Conclusion: This is not correct .

D. Entities: Entities represent data objects or components, not those receiving services. Conclusion: This is not correct .

The Business Readiness Assessment is a key activity conducted during the Implementation or Business Change Deployment stage of the project. Its primary purpose is to determine whether the target business areas, including the People, Organisation, and Processes, are sufficiently prepared to accept the business change and begin operating the new solution in the ' To Be ' state. This involves checking factors such as whether staff have been trained, new processes are documented, communication has been effective, and necessary resources are in place. This assessment informs the ' Go/No Go ' decision for the system ' s launch, ensuring a smooth transition to the new way of working.

(Reference: BCS Business Analysis Practice – Business Change Deployment, Business Readiness)

A mind map is used to organise ideas, information, and themes visually around a central topic. In business analysis, it helps structure early thinking, capture workshop outputs, group related concepts, and identify branches of investigation. It is especially useful when information is broad, unstructured, or exploratory. Option B describes a process model or activity diagram because flows of activities and decisions are shown using process modelling notation. Option C is closer to requirements modelling, use case modelling, product backlog decomposition, or solution architecture. Option A may be a possible outcome of analysis, but it is not the main purpose of a mind map. The key feature of a mind map is organising information into related themes and sub-themes, so option D is the best answer.

In a UML (Unified Modeling Language) Activity Diagram, the symbol used to represent a task (or action/activity) is a round-cornered rectangular box. This shape denotes an individual piece of work or step carried out within the process.

The other symbols represent:

A filled in circle (B): The Initial Node (start of the process).

A diamond shaped box (C): A Decision or Merge Node (a point where a choice is made or paths recombine).

A bullseye (D) (a filled circle inside an outer circle): The Activity Final Node (end of the process flow).

(Reference: BCS Modelling Business Processes / BCS Business Analysis Practice – UML Activity Diagrams)

===========