Free ECBA practice test: 30 questions with answers

Business analysis enables change by first understanding the underlying need and the value sought, not by documenting a solution that is already chosen. Writing specifications and listing vendor features skip the need, and early costing is premature.

The six BACCM concepts are change, need, solution, stakeholder, value and context. The first option lists project management knowledge areas, and the other two mix delivery terms and modelling terms with words that are not BACCM concepts.

The BABOK view is that business analysis enables change by defining needs and recommending solutions that deliver value, which continues beyond sign-off. Complete documents, schedule management and vendor selection are narrower activities that do not describe the purpose of the BA role.

Assessing outcomes checks whether the solution delivered the need and value it was intended for, which on-time and on-budget delivery alone does not prove. The other options treat delivery as success or add scope before results are known.

An empowering mindset focuses on helping others make good decisions and build capability, which is what the analyst does here. Gatekeeping, compliance and competitive mindsets centre on control, rule enforcement or individual output rather than shared capability.

Effective business analysis keeps its focus on delivering value and revisits its assumptions as conditions change. Freezing requirements, documenting everything up front and deferring every decision each ignore that change is expected in such programs.

Respect and open collaboration mean hearing each view out and recording it fairly before a decision is reached. Speed, individual ownership and deference to seniority each close off discussion in different ways.

Sorting conflicting input, forming a hypothesis and testing it against data is analytical thinking and problem solving. Tools and technology, industry business knowledge and interaction skills are also foundational competencies, but the scenario does not mainly draw on them.

Impact analysis identifies the processes, systems and people affected by a change and assesses how their workload and responsibilities shift. Vendor selection, training material creation and budget approval are project activities that follow or support the analysis rather than forming part of it.

Engaging the affected staff to understand their concern lets the change be shaped with the people it affects. Proceeding on sponsor approval alone, delaying indefinitely or simply announcing the change each ignore the underlying concern.

Regularly comparing planned milestones and measures with actual results shows whether the change is on track and where it needs correction. Closure-only reporting, informal updates and meeting counts do not show progress against plan.

A simple improvement is a small, contained change that can be made with little risk to other areas, which fits this proposal. The other options describe larger changes with wider scope, which removing one duplicate field does not have.

Building rapport with each group first helps the analyst understand each need accurately, and the perspectives can then be reconciled together. Adopting the most senior view, voting or recording unchecked problems skips validation of the real need.

MoSCoW is a prioritization technique that sorts needs into must, should, could and won't categories, which fits this sorting task. Process modelling, interface analysis and data dictionary creation are useful analysis techniques but do not rank needs.

Validation confirms that requirements accurately reflect stakeholder needs before sign-off, which is the purpose of the walkthrough. Prioritization, solution assessment and elicitation are separate activities that this walkthrough is not designed to perform.

Validation confirms that the solution meets the need it was built for, while verification checks conformance to the specification. Elicitation and stakeholder analysis are different activities that do not test whether the form meets the need.

Options are compared on feasibility and on the risks they bring, since both determine whether they can realistically meet the need. Colour choices, meeting counts and presentation length do not show whether an option can deliver the value sought.

A process flow diagram is a design artifact that shows steps, decision points and handoffs in a future-state process. A stakeholder map, a glossary and a lessons learned register are useful project artifacts but do not depict how the process runs.

Tailored communication addresses each group's roles and interests in terms they care about, which builds understanding and buy-in. A single document, delegation to executives or a briefing for IT alone each ignore how differently the groups view the change.

High-influence, low-interest stakeholders should be kept satisfied through consultation on key decisions and attention to their concerns, because their influence could block the change. Minimal monitoring, daily sessions or a general newsletter do not match that level of influence.

A review session gives stakeholders a chance to ask questions and raise concerns, which encourages real feedback. Treating silence as approval, waiting until design ends or seeking only a sponsor signature each miss the feedback needed to validate the requirements.

Turning a vague goal into a measurable desired outcome tied to the business vision gives the change a clear target for value. Jumping to a solution, accepting vague wording or costing the program each skip that step.

A KPI is a measure tied to a business goal, which lets the organization track whether the change is moving toward the value it targets. Task counts, stakeholder lists and cost rankings are useful but do not measure progress toward a business goal.

Value barriers are conditions that restrict how much value a change can deliver, and both factors here fit that description. Desired outcomes are the results sought, while core concepts and scope items describe other things.

Validating information quality means checking that data is accurate, current and relevant to the situation being analysed. Trusting the source, enlarging an outdated sample or relying on the sponsor's opinion do not establish that the data still applies.

Statutory rules and budget ceilings are constraints that restrict which solutions are possible. Colour preferences, expected benefits and customer requests are needs, preferences or value expectations rather than limits on the solution.

Validating information quality means understanding how each source was collected and whether its definitions and coverage are comparable before choosing or combining the figures. Choosing the higher figure, averaging blindly or polling preferences each skip that validation.

BA roles are defined by the responsibilities performed, and those tasks may be carried out by different people, including product owners. The other options tie the role to a job title, a certification or a single narrow task, which do not define it.

Predictive approaches suit well-understood scope with fixed rules and high change costs, because requirements can be agreed before build. Adaptive, ad hoc and prototype-first approaches suit uncertain or fast-changing needs, which this scenario does not describe.

Organizational culture and the value placed on analysis determine whether BA findings are heard and acted on, which is the issue described here. Programming languages, office layout and licence models do not affect whether analysis is respected.