Track 1 – Foundations

Goal: Learning how to think beyond the surface

• Who is the user in this recurring transfer story, and what real-world problem are they trying to solve by setting a frequency?

• Why is “transaction limit validation” and “daily limit validation ”  a business rule and not just a system behavior?

• What could go wrong for the user if we did not validate minimum and maximum amounts for the amount field?

• Did we need to clarify what “daily” or “bi-weekly” actually means instead of assuming everyone understands it the same way?

Foundations takeaway:
You are building analytical muscle.

Track 2 – Interview Ready

Goal:

Learning to explain your thinking clearly.

• If an interviewer asked me how I handled edge cases in this transfer feature, could I clearly walk through the logic without sounding scattered?

• How would I explain why we discussed weekend processing and disclaimers instead of just building the frequency field? How could I weave this into a story I tell in the interview?

• If asked how I ensure requirements reduce production risk, how would I use the transaction limit example to demonstrate that?

• How would I explain the difference between what AI generated in Jira and what we improved manually — in a way that shows critical thinking?

Track 3 – Early BA

Goal: Write implementation-ready, testable stories.

• Did I clarify whether transaction limits are validated in real time or only at submission — and why does that matter?

• Did I define what happens if a recurring transfer hits a limit on a future date?

• Did I specify whether when “never ” is selected as the  recurring transfers have system safeguards (e.g., review triggers, alerts, caps)?

• Did I make acceptance criteria testable for every frequency type and end-date combination?