FREE SELF-GUIDED BUSINESS ANALYST TRAINING

Business Analyst Project Training: A Worked Practice Example

Business analyst (BA) project training becomes useful when you can connect a problem to evidence, a requirement and a test. This short exercise lets you practise that connection with a fictional room-booking service.

Try your own response first. This self-guided exercise includes no live coaching, human assessment, certification or employment promise.

1. Define the decision before proposing a feature

Harbor Desk is a fictional shared workspace. A staff member says: “The room summary makes us look busier than we are.”

That statement is a stakeholder claim. It suggests something to investigate; it does not prove lost revenue, poor customer experience or a software defect.

Your task is to decide what a confirmed-booking summary should count. A complete booking system also needs durations, capacity, permissions and conflict handling.

2. Read the evidence and its limits

These six invented records describe one fictional date. Each row represents a booking, not a person or status-change event.

The draft summary counts all six rows. The operations owner proposes counting only confirmed records in a summary labeled “Confirmed bookings.” Whether pending requests should reserve capacity remains undecided.

Before writing a requirement, ask:

• Operations owner: Does a pending request reserve a room, and when does that reservation expire?
• Staff user: What action will you take after reading this summary?
• Data owner: Does cancellation update the booking row or create an additional event?

Counting event records as bookings could inflate totals even after filtering status.

3. Turn the decision into a testable requirement

A vague draft says: “Make the occupancy report accurate.” It does not define occupancy, the date, the records to include or the expected result.

A more precise requirement is:

R1: For the selected date, show the number of booking records with status CONFIRMED for each room.

Label the metric “Confirmed bookings.” This count does not establish utilization or whether a room is available at a particular time.

Acceptance criterion AC1: Given Pine has one confirmed, one canceled and one pending booking on the selected date, when staff view Pine's confirmed-booking summary, then the count is one. Canceled and pending records do not contribute to that metric.

Excluding pending records from this metric does not settle whether they reserve capacity.

4. Sketch the process and locate the change

Use this simple sequence:

1. A request creates a pending booking.
2. A decision changes its status to confirmed or canceled.
3. Staff open the summary for a selected date.
4. The summary counts the records that meet its stated rule.

The proposed change belongs in step four; request and cancellation handling remain separate.

Ask what should happen when two confirmed records share a room and start time. Counting cannot resolve that conflict.

5. Check one question with SQL

Assume a table called bookings contains exactly the six rows above, with columns booking_id, room, slot and status.

SELECT room, COUNT(*) AS confirmed_bookings
FROM bookings
WHERE status = 'CONFIRMED'
GROUP BY room
ORDER BY room;

The expected result is:

This query was checked against the six-row example in an in-memory SQLite database. It returned these counts. That validates this small calculation, not a deployed booking service or its business policy.

Explain the limits alongside the result:

• The sample contains three confirmed bookings across two rooms.
• Multi-date tables need a date filter.
• Start times do not tell us booking durations, so these counts cannot measure occupied hours.
• Rooms with no confirmed bookings are absent from this query's result.
• Two confirmed bookings in the same slot would both be counted. That is a separate validation problem.

6. Connect the requirement to user acceptance testing

User acceptance testing (UAT) should check the intended behavior using explicit cases.

T3 reveals a decision hidden inside “for each room.” If the requirement means every room, including empty ones, the simple query is incomplete. Clarify the requirement and use a room inventory with a suitable join before claiming completion.

Keep the connection visible: sample observation → R1 → AC1 → T1. Checking SQL does not prove that a user interface displays the result correctly or that staff understand it.

7. Explain the work honestly

A portfolio summary could say:

I investigated a fictional six-booking sample, clarified a counting rule, wrote an acceptance criterion and checked a SQL result. The sample contained three confirmed bookings. Pending-booking policy and zero-count room display still need decisions. No customer impact was measured.

Now try a variation: the owner wants every room shown, including rooms with zero confirmed bookings. Revise the requirement, identify the extra data needed and write a test before changing the query.

For further practice, try the free demo, compare the editions or check software requirements. The demo contains one fictional banking mission and three observations. Experience Lab introduces connected banking missions and SQL practice; Core and Advanced add broader scope. Sales remain closed.

Original fictional exercise created for BA Mentorship. It contains no customer records or paid curriculum extracts.

Continue with requirements, SQL and interview practice resources.