Articles
Business Systems Analyst Interview Case: Requirements, Data Mapping, and Acceptance Criteria
Work a business systems analyst refund case from stakeholder conflicts through field mapping, duplicate handling, and falsifiable acceptance tests.
A business systems analyst case is rarely solved by writing a neat requirement sentence on the first try. The hard work is deciding which stakeholder statement is a rule, which is a preference, and which data event proves the system behaved correctly. In this original practice case, Support wants customers to see refunds immediately, while Finance wants ledger totals to reconcile before anything is shown as complete. The exercise is fictional; it is not a report of an employer's interview. The IIBA Business Analysis Standard distinguishes understanding a need from specifying and validating a solution. That distinction is the backbone of the answer.
A useful warm-up is Clarify ambiguous requirements under pressure; then test your answers against the refund contract below.
The case: a partial-refund process with conflicting language
Imagine a retailer replacing a manual refund spreadsheet with an order-service workflow. Customers can request a partial refund for one or more order lines. Support says, “As soon as we click refund, the customer should see it as done.” Finance says, “A refund is done only after the payment provider confirms it and the ledger matches.” Engineering says the provider sends asynchronous events and sometimes retries the same event. The interviewer asks you to produce requirements, a source-to-target map, and acceptance criteria by the end of the case.
Do not resolve the conflict by picking the loudest stakeholder. Ask what “done” means at each system boundary. A Support agent may need immediate evidence that a request was submitted. A customer may need an honest status such as “processing.” Finance may reserve “completed” for confirmed money movement and a recorded ledger entry. These can be compatible requirements if status names and transitions are explicit. First identify the actors, the triggering action, the authoritative source for each state, and the exception path when provider confirmation never arrives.
Here is a possible clarification script: “When Support clicks refund, what acknowledgement can we guarantee synchronously? What provider event confirms money movement? What ledger record must exist before we call it completed? Who owns a stuck state, and after how long? Can two agents request overlapping refunds against the same order line?” The interviewer may answer only some questions. State assumptions for the rest and mark them for validation. A strong BSA does not transform missing information into a polished but unsupported specification.
Convert statements into a state contract
For this exercise, assume a refund request has requested, submitted, confirmed, rejected, and needs_review states. These names are proposed design choices, not facts about a payment provider. requested means the internal system accepted a validated request; submitted means the provider accepted an operation for processing; confirmed means a provider confirmation was received and the ledger posting succeeded. rejected means a provider or validation failure closed the attempt. needs_review marks a mismatch or timeout requiring an owner. A customer-facing label can differ from the internal state, but the mapping must be documented.
Now write one business rule per contentious point. The requested refund amount must be positive and no greater than the still-refundable amount of the selected order lines. Currency must match the original charge unless a documented conversion policy exists. A customer-facing “completed” status requires both provider confirmation and ledger posting. A duplicate provider event must not create a second ledger entry or increase the refunded total. An agent must see a pending or failed state rather than a false success. The business owner must approve what happens when provider confirmation and ledger posting disagree.
These rules separate need from implementation. “Use a message queue” is an implementation proposal; “process provider retries without duplicating financial effects” is a requirement. The IIBA Core Standard emphasizes traceability and validation of requirements and designs. In your answer, connect every rule to a stakeholder decision and an observable test. That is more useful than a large list of vague user stories.
Map data across the source and target boundary
The mapping should say what is authoritative, how a value changes, what happens when it is missing, and who owns exceptions. Suppose the source is refund_request, the payment-provider event is provider_refund_event, and the targets are refund_status and ledger_entry. The following is a compact interview artifact, not a production schema. A real implementation would need provider contract details and Finance sign-off.
| Target field | Source and transformation | Null, duplicate, or exception rule |
|---|---|---|
refund_id | Internal immutable request ID, carried in provider metadata when supported | Required; lookup failures go to review, never to a guessed order |
order_id and line_id | Validated order-line references from the request | Required; reject a line outside the order |
requested_amount_minor | Agent input converted once to integer minor units under currency rules | Required and positive; reject excess over remaining refundable amount |
currency | Original payment currency | Required; mismatched provider currency requires review |
provider_event_id | Provider's unique event identifier | Required for event dedupe when contract supplies one; missing ID follows an agreed exception policy |
provider_refund_id | Provider operation identifier | Required before confirmed state; repeated events map to the same operation |
status | State transition based on validated action and confirmed provider event | Unknown event type cannot silently become confirmed |
ledger_entry_id | Ledger posting result keyed to refund operation | One posting per confirmed refund; retry must return the existing posting |
The distinction between event ID and refund-operation ID matters. Two notifications about the same refund might have different event IDs. Event dedupe prevents processing the exact notification twice; operation-level idempotency prevents two postings for one underlying refund. If a payment provider lacks the identifiers assumed here, the BSA must ask Engineering and Finance for a defensible correlation key and exception handling. “Deduplicate by amount and timestamp” risks merging legitimate separate refunds. Do not assert a key without a contract.
Show one row end to end. A customer paid $50 for an order line, and Support requests a $15 partial refund. The internal request records 1,500 minor units, the original currency, the order and line IDs, and a unique refund ID. A provider confirmation for that refund leads to one ledger entry of 1,500 minor units and confirmed status. If the provider sends the same confirmation twice, the second event produces no additional posting. If the provider reports rejection, the request becomes rejected or needs_review according to the agreed transition; it never becomes “completed” because Support clicked a button. These are constructed values and a proposed policy, not a live system observation.
Write acceptance criteria that can fail
“Refund works” and “data is accurate” are not acceptance criteria. They have no falsifying example. IIBA's guidance on acceptance and evaluation criteria supports expressing criteria that let stakeholders assess a solution. Write examples with initial state, event, expected state, and observable record. Let Finance and Support challenge them before Engineering treats them as a contract.
| Given | When | Then |
|---|---|---|
| An order line has 5,000 minor units paid and 1,500 already confirmed refunded | An agent requests 3,600 more | The request is rejected because only 3,500 remain refundable; no provider call or ledger posting occurs |
| A valid 1,500-unit request is accepted internally | The provider has not confirmed it | Support and the customer see a processing state, not completed; an owner can find the pending operation |
| A provider confirms the 1,500-unit refund and ledger posting succeeds | A duplicate event arrives | Status remains confirmed and exactly one 1,500-unit ledger entry exists |
| A provider confirms but ledger posting fails | The event is retried | The request enters a visible review or retry state; completion is withheld until the ledger result is known |
| A provider event refers to an unknown refund ID | The event is ingested | The event is quarantined for investigation; no order or customer is guessed |
The first criterion reveals a concurrency question: two agents may each request a refund that is individually within the remaining balance but jointly exceeds it. State that the remaining refundable amount must be checked and reserved or updated atomically under the chosen transaction design. The BSA does not need to prescribe a database lock in every interview, but they should expose the invariant: confirmed plus pending refunds must not exceed the original refundable amount under the approved policy. Ask whether a rejected provider operation releases a reservation and how stale pending operations are reconciled.
The fourth criterion avoids a dangerous shortcut. Provider confirmation and local ledger success are two events, so “all-or-nothing” cannot simply be assumed. Define the visible state during the gap and the owner who reconciles it. A test should simulate a posting failure and a retry, then inspect both the customer status and the ledger. If the organization prefers to display provider completion before ledger reconciliation, Finance must explicitly accept that policy and the product must label the state honestly. The BSA's job is to make the trade-off decidable.
Handle change, schema drift, and sign-off
Suppose Finance later asks to support refunds in a second currency. Do not insert a conversion formula into a footnote. Reopen the policy: original-charge currency, exchange-rate source and timestamp, rounding, ledger currency, customer disclosure, and exception owner. Trace the change to mapped fields, validation rules, user-visible status, reports, and tests. A decision log should show what changed and who approved it. This is what requirements traceability does in a small case: it prevents an apparently local field change from breaking another system's meaning.
At the implementation boundary, schema validation can catch missing or unexpected fields, but it cannot decide financial semantics. Microsoft's mapping data flow documentation describes schema handling as one concrete implementation mechanism. Use that example to explain the difference: an ingestion step can reject a missing refund_id; the business rule still determines how an orphan event is investigated and whether the customer is shown a pending state. Avoid presenting a tool's feature as proof that the end-to-end requirement is satisfied.
A concise sign-off package has a state diagram, the field map, acceptance examples, unresolved questions, and named owners. Support approves the wording and agent workflow. Finance approves completion and reconciliation rules. Engineering confirms that identifiers, transitions, and failures are implementable. The product or business sponsor approves scope and trade-offs. Sign-off is not a promise that no change will occur; it establishes a current baseline and a path for changing it.
How to present the case in an interview
Open with the conflict: “Support needs immediate acknowledgement; Finance needs confirmed financial completion. I will define distinct states so both needs can be met without a false success signal.” Then draw the source-to-target boundary and name the authoritative event for each state. Present two normal-path examples and two failure examples. Close with a list of unknowns that would alter the design, such as provider identifiers, partial-refund policy, concurrency control, and ledger timing. This shows analysis rather than an overconfident specification.
If time is short, prioritize the data contract and three acceptance tests over a large diagram. Ask the interviewer for a policy answer when one is essential. If none is available, state a provisional assumption and make its risk visible. The case is scored most persuasively when a reader can trace a stakeholder statement to a business rule, a mapped field, and an observable result. That is the evidence that ambiguity has been reduced enough for a team to build and test.