Free CBAP practice test: 30 questions with answers

Verification checks that each requirement is well formed, such as clear, consistent and testable. Validation asks whether requirements meet business needs, design options compare ways to meet them, and assessing solution limitations happens after implementation.

Non-functional requirements describe quality attributes such as performance, accessibility and security rather than specific behaviour. Functional requirements describe actions the system performs, transition requirements describe what is needed to change over, and business rules govern decisions.

Specifying and modelling requirements produces process, data and rule-based descriptions that make requirements precise. Defining architecture groups and relates requirements, design options compare alternatives, and value analysis evaluates them, so none of these matches producing the models.

Defining requirements architecture organizes requirements into structured groups, shows how they relate, and indicates which parts of the solution own them. Verifying individual requirements, validating them with stakeholders and defining design options each address a different question.

Defining design options describes alternative ways to meet the requirements, including their constraints, before value is assessed. Analyzing potential value and recommending a solution comes after the options are described, while verifying and validating concern the requirements themselves.

A requirements traceability matrix records relationships between requirements and related items, supporting impact analysis and coverage checks. A glossary, a decision table and a stakeholder grid each serve different purposes and do not record these links.

Assessing a change uses traceability links and requirement relationships to find everything the proposed change touches. Backlog prioritization, new elicitation and design approval are useful activities, but none of them identifies the affected items.

Maintaining requirements includes tracking status and versions and keeping approved requirements with their rationale for audit and future change. Deleting requirements at go-live loses that history, and an unversioned shared file cannot show what changed or when.

Prioritization ranks requirements using factors such as value, risk and dependencies, and it is revisited as conditions change. A one-time ranking, recording approvals or checking testability each describe a different activity rather than prioritization.

A baseline is a formally agreed set of requirements that serves as the reference point, with later changes controlled against it. A stakeholder list, an informal first draft and test summaries do not serve as that controlled reference.

Documenting how work is done today is analysis of the current state, which provides the baseline for later decisions. Defining the future state, assessing risks and defining the change strategy all come after the baseline is understood.

The change strategy is a high-level approach for moving from the current state to the future state, including solution options and the transition. Detailed backlogs, test schedules and sponsor approvals are project-level outputs rather than the strategy itself.

Assessing risks examines the threats and uncertainties of the future state and change strategy, including dependencies on external products. Defining the future state, analyzing contract terms or validating requirements do not evaluate those risks.

Strategy Analysis covers analyzing the current state and defining the future state, together with risk assessment and the change strategy. Usability testing, acceptance test planning and post-deployment measurement are outside this area; measurement of value belongs to Solution Evaluation.

The business need describes the problem or opportunity, its causes and its impact, before a solution is selected. A vendor's architecture, a test plan and a sprint plan all come after the need is understood.

Planning the business analysis approach sets how prioritization, reviews, deliverables and governance will work before elicitation starts. Starting elicitation, validating draft requirements or defining the future state without that approach skips the decisions that shape all later BA work.

Business analysis governance defines approval paths, decision rights and change escalation. Information management covers storing and maintaining BA information, stakeholder engagement planning covers how people are involved, and performance assessment measures BA work; none of them sets the decision structure itself.

Stakeholder analysis and the engagement plan identify who must be involved and how, so they must be updated when new decision-makers join. Verifying requirements, writing scope and measuring a live process do not address the stakeholder gap behind the reopened decisions.

Tracking rework and review effort as performance measures and recording lessons learned both feed improvements back into the BA approach. Dropping stakeholder review, enlarging sessions or handing reviews to a vendor without oversight weakens quality instead of improving it.

Planning the business analysis approach tailors how requirements are refined, prioritized and documented for the chosen life cycle. Analyzing the current delivery process, defining the change strategy and measuring post-deployment performance are useful activities, but they do not set these working decisions.

Assessing solution limitations finds where the solution falls short of its requirements or stakeholder needs. Measuring performance collects data, recommending actions proposes improvements, and assessing enterprise limitations looks at constraints in the wider organization.

Recommending actions to increase solution value proposes specific improvements, such as workflow changes or training, that would increase the benefit the solution delivers. Measuring, analyzing and assessing enterprise limitations all come before this recommendation.

An enterprise limitation is a constraint in the wider organization, such as policy, process or skills, that restricts the value a solution can deliver even when the solution works. A software defect, an unmet target or an unapproved requirement describes a solution or project issue instead.

Analyzing performance measures interprets collected data against target outcomes to show which targets are met and where gaps remain. Collecting the processing times is measurement itself, recommending improvements comes after analysis, and defining design options belongs to requirements design work.

A leading indicator moves before final results and signals whether the solution is likely to deliver its expected value. A lagging indicator reports results only after they occur, while login counts and raw defect counts say little about savings.

Elicitation begins with preparation, which fixes the purpose, participants and techniques before any session runs. Confirming results comes after elicitation, sending requirements to developers comes later, and a verbatim transcript is not a required first step.

Observation lets the analyst see real work as it happens, including informal workarounds that people often do not mention. The survey, document analysis and brainstorming gather stated opinions or written material and do not show actual practice.

Collaboration often needs an agreed decision process and a named decision-maker so the disagreement can be resolved and recorded. Removing managers, splitting the work into separate documents or postponing the decision leaves the conflict open.

Confirming results checks that elicitation outputs are accurate and complete, and draft notes are often reviewed with participants for that purpose. It applies to all techniques and does not replace requirements validation, which is a separate task performed later.

Prototyping gives customers something concrete to react to, which surfaces needs early in the screen flow before build effort is spent. Data mining, document analysis and load analysis do not show how customers respond to a proposed design.