Business Analyst quiz — 34 questions with answers and explanations

Answer: C

The BA is accountable for requirements: correctly capturing the business problem and making them clear enough for the dev team to build. Schedule belongs to the PM, code quality to dev and QC, and prioritization to the PO.

Answer: B

They differ in the question each must answer. The BA starts from people and processes to produce requirements; the DA starts from existing data to produce insights. Both use SQL, and many Vietnamese companies combine the two roles into one position.

Answer: B

That's a solution, not a need. The need is the underlying business problem behind it. Taking the solution as-is and writing it as a requirement means the dev team will deliver exactly what was ordered while the original problem remains unsolved.

Answer: D

A non-functional requirement describes how well the system performs, not what it does: response time, concurrent users, allowed downtime, security level. The telltale sign is that it must include a number.

Answer: B

The BRD answers why to build and what to achieve, written for decision-makers. The SRS answers what the system must do, including non-functional requirements, written for the dev team. One objective in the BRD maps to many features in the SRS.

Answer: C

Alternate: paying by wallet instead of card, the order is still created. Exception: card declined or out of stock mid-way, the order is not created. Same use case, differing in whether the goal is achieved.

Answer: A

Swimlane — role columns. Cross-department processes usually break at handoff points, and swimlanes are the only thing on the diagram that makes handoffs visible.

Answer: A

Wireframe is a grey-box layout: block positions, information order, screen flow. Mockup is a static version with colors, fonts, and images matching the brand. A clickable version is a prototype, one level further.

Answer: B

Documentation is still needed, but write just enough for the team to work and keep it updated, instead of a thick upfront document left to rot. The check before writing: who will read it, and what will they do with it.

Answer: A

Fails V — Valuable. This is a story written by technical layer. Stories must be split by business flow or business rule, not by technical layer.

Answer: A

AC is the set of conditions that must be met for a story to be considered done. It locks in shared understanding between BA, dev, tester and the business side, and blocks scope creep: anything not in the AC is not yet agreed.

Answer: B

They differ in timing. Risk: the vendor may be late delivering the test environment. Issue: the environment is already two weeks late and integration is stalled. An unhandled risk that materializes becomes an issue.

Answer: D

Because of bias. The BA's role in UAT is organizing: scenarios based on everyday business situations, realistic test data, user guidance, then classifying feedback as either a defect or a new requirement.

Answer: A

Say directly that you're unsure, commit to a follow-up time, then deliver on time. A BA's credibility is built by keeping promises a few times, and that's what reduces tension in later sessions.

Answer: D

The question tests honesty and how you react when plans slip, not whether you're perfect. The most important part is when you flagged it and what you changed afterward.

Answer: C

A business-side BA can propose non-software solutions. An IT BA works in a context where a system will be built or modified, so they need to be able to read APIs, understand data models, and use basic SQL.

Answer: B

Query level: SELECT, WHERE, the various JOIN types, GROUP BY with aggregate functions, how NULL affects filtering, and understanding primary keys, foreign keys, and one-to-many relationships.

Answer: D

It's a wish, not yet a requirement, because it's not verifiable. To be usable it must be converted to something measurable: number of steps to complete a task, time for a new user to succeed on first try, error rate.

Answer: B

Everyone labels their own part Must, and the classification table loses its effect. The common fix is to cap the Must ratio in total volume, forcing parties to make real trade-offs instead of just declaring.

Answer: A

RTM links requirements up to business objectives and down to design, dev items, test cases. Because it links both directions, it reveals both gaps and excesses, and shows what must be retested when a requirement changes.

Answer: A

include is a mandatory step and usually shared: "Place order" includes "Authenticate user". extend is a conditional branch: "Place order" is extended by "Apply discount code", running only when the user enters a code.

Answer: C

Flowcharts have a few generic symbols and no strict convention, so everyone draws them their own way. BPMN is an OMG standard, so each symbol has a defined meaning and can express things flowcharts cannot.

Answer: A

State diagram — the lifecycle of an object: new, confirmed, shipping, completed, cancelled, along with the valid transitions between them.

Answer: D

A user story fills in detail through conversation, so it fits when the team can talk directly every day. When that condition is absent — long flows with many branches, teams in other time zones, contracts requiring documentation — a use case fits better.

Answer: C

A new requirement goes into the backlog and competes for priority; it does not cut into the running sprint. Change is normal in Agile, but there is still discipline about when it is brought in.

Answer: C

Usually: the BA owns the requirement content, the PO holds the priority decision authority. More important than the convention is agreeing on the boundary up front, since each organization divides it a little differently.

Answer: D

Avoidance: drop the feature that depends on an untrustworthy third-party system — the trade-off is losing scope. Mitigation: still build it but trial the integration early to catch problems — the trade-off is extra effort and time.

Answer: C

The skills and organizational group: nobody has been trained, nobody is accountable for the new step. This group is not in the software, so nobody puts it in the spec, yet it decides whether the solution is actually used.

Answer: C

A condition in ON applies at join time, so customers with no orders still appear with the order part as NULL. A condition in WHERE applies after the join, removing those NULL rows and losing the group of customers with no orders.

Answer: D

Trace back to the underlying needs before treating it as a conflict. If a contradiction remains, ground it in measurable criteria, evaluate against project goals, look for non-mutually-exclusive options, then escalate to the decision-maker.

Answer: C

Confirm the extent with the engineering team first, then revisit the underlying need, prepare at least two options with trade-offs, and present them in business terms with numbers. Going into a meeting with only bad news is the fastest way to lose trust.

Answer: D

Three common types of pushback: technical (usually valid, must adjust), workload (a scope and prioritization issue), interpretation (a flaw in how the requirement was written — fix the description, don't argue).

Answer: B

Scope creep is scope gradually expanding without adjustments to time, cost, or resources. Approved changes are normal; the dangerous part is what slips in silently.

Answer: B

Read existing documentation, build a glossary, sketch a rough flow and take it to ask questions, follow one real transaction, and find the people who actually know the work in the operations team rather than only listening to management.