Pass the BCS Business Analysis PC-BA-FBA-20 Questions and answers with CertsForce

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 .

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)

Agile requirements validation ensures that requirements are clear, feasible, and actionable before they are implemented in an iteration. This aligns with Agile principles of delivering value incrementally and avoiding waste.

Key Considerations:

Accurate Estimation for Sprint Planning: While estimation is important, it is not the primary purpose of requirements validation.

Correctness of Backlog Items: Ensuring correctness is part of validation but applies to all backlog items, not just those allocated to an iteration.

Testing Requirements: Testing occurs during or after development, not as part of validation.

Readiness for Development: Validation ensures that requirements are well-defined, understood, and feasible before they are developed.

Evaluation of Each Option:

A. To ensure estimation for sprint planning is accurate:Estimation accuracy is important but not the primary purpose of validation.Conclusion: This is not correct .

B. To ensure any requirements added to the backlog are correct:Correctness applies to all backlog items, not just those allocated to an iteration.Conclusion: This is not correct .

C. To ensure that requirements allocated to an iteration have been tested:Testing occurs after development, not during validation.Conclusion: This is not correct .

D. To ensure any requirements allocated to an iteration are ready to be developed:This is the primary purpose of Agile requirements validation—to ensure requirements are clear, actionable, and feasible before development begins.Conclusion: This is correct .

Final Recommendation:

The purpose of Agile requirements validation is:

D. To ensure any requirements allocated to an iteration are ready to be developed.

The Requirements Engineering (RE) Framework is a structured approach used by business analysts to define, document, and manage requirements. It consists of five iterative stages: Investigate Situation, Consider Perspectives, Analyze Needs, Evaluate Options, and Define Requirements .

Key Considerations:

Suitability for Waterfall Projects Only: The RE Framework is flexible and can be adapted to both waterfall and Agile methodologies.

Iterative Stages: The framework emphasizes iteration and refinement, making it suitable for evolving requirements.

Defining Requirements: The framework explicitly supports the definition and management of requirements.

Sequential Steps: While the stages are presented in a sequence, they are iterative and not strictly linear.

Evaluation of Each Option:

A. It is only suitable for use with waterfall projects:The RE Framework can be applied to both waterfall and Agile projects.Conclusion: This is not correct .

B. It shows five iterative stages that a business analyst needs to carry out to establish the requirements:This accurately describes the RE Framework's structure and purpose.Conclusion: This is correct .

C. Using the Requirements Engineering Framework does not help to define requirements:The framework is specifically designed to define and manage requirements.Conclusion: This is not correct .

D. It shows steps in the requirements engineering process that a business analyst must follow sequentially:While the stages are presented in a sequence, they are iterative and not strictly sequential.Conclusion: This is not correct .

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

Key Characteristics of Business Analyst Roles:

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

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

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

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

Evaluation of Each Option:

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

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

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

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

Final Recommendation:

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

B. Digital business analyst.

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

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

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)

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 .

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