Payments Academy

BA practice depth

D14 Business analysis and professional practice · 8 lessons

Version 1.0 | Last reviewed 2026-11-07

Gherkin, traceability, SIT and UAT design, negative testing, defect management, root cause analysis

BA practice depth: Gherkin acceptance criteria, traceability, SIT and UAT design, negative testing, defect management and root cause analysis.

What You Can Do After This Chapter

Learning objective. Learner explains how a payments business analyst gathers requirements in the domain language, writes a BRD and a functional specification, and writes user stories with Gherkin acceptance criteria. Learner maps processes in BPMN, maps data field by field from MT to MX, designs a test strategy with SIT, UAT and negative testing, manages defects by severity, and runs production support and root cause analysis.

Practical assessment. Learner receives a case where a bank must add SEPA Instant to its hub, then writes the requirements, a Gherkin acceptance criterion, a field-by-field MT to MX mapping, and a test strategy with negative cases. Learner also triages three defects by severity and drafts the root cause analysis for a failed instant payment.

Expected deliverables.

Completion criterion. Learner writes correct requirements and Gherkin criteria, maps the fields accurately, designs a complete test strategy, and triages the defects by the right severity.

In this chapter
  1. Requirements gathering for payments: workshops, elicitation and the domain language
  2. Writing a BRD and a functional specification for a payment product
  3. User stories and acceptance criteria for payments: Gherkin in practice
  4. Process mapping and BPMN: drawing the payment flow so everyone agrees
  5. Data mapping and message mapping: field by field, MT to MX
  6. Test strategy for payments: SIT, UAT, negative testing and the test pack
  7. Defect management: severity, triage and the defect lifecycle
  8. Production support and root cause analysis: keeping payments running

Start Lesson 1: Requirements gathering for payments: workshops, elicitation and the domain language →