Key points of this lesson, in order.
Hands-on BA Deliverables Checklist
What you will learn
Your objective. By the end of this lesson, you will be able to explain hands-on BA deliverables checklist. The Business Requirements Document is the first deliverable on the checklist, and it is complete only when it states the business objectives, the scope with explicit exclusions, the prioritised requirements, the.
Why it matters. The analyst keeps the signed version in the project repository and versions every change after sign-off.
Chapter objective: Learner completes a capstone project that designs an end-to-end payment solution for a stated business problem, integrating messages, rails, controls, and operations into one coherent proposal. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Business Requirements Document
- Mapping document
- User stories
- Test cases
- Training material
- Go-live checklist
Key terms
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
Exception: A payment that cannot be processed normally and needs manual handling, investigation or repair. Exceptions arise from missing data, failed screening, account errors or system faults.
Clearing and settlement timeline showing Hands-on BA Deliverables Checklist.
Insights and practice scenarios
Worked insights and practice scenarios for this lesson. Each one is a reusable PaymentForge case, so the same case may appear in more than one lesson.
Practise this lesson
Exercise
Read the MT103 field message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
Which of the following best describes hands-on BA deliverables checklist?
Takeaway and next step
What to remember
The checklist is rehearsed twice in October so that the real night runs without surprises.
Map the message fields from this lesson in the mapping workbench.
Builds on "UAT Scenarios and End-to-End Test Cases".
Transcript and full text
Show transcript
The Business Requirements Document is the first deliverable on the checklist, and it is complete only when it states the business objectives, the scope with explicit exclusions, the prioritised requirements, the business rules, and the success criteria. The BRD must be reviewed by the project sponsor, the operations head and the compliance lead, and signed off by the end of April. A BRD that is missing the out-of-scope section is not complete, because without it the team will argue about scope for the rest of the project. The analyst keeps the signed version in the project repository and versions every change after sign-off. The mapping document is the second deliverable, and it is complete only when every MT103 field has a mapped pacs.008 element, a mapping type labelled as direct, derived or translated, and a rule for every exception. The document must include the parsing rules for fields 50K and 59, the charge code translation table, and the results of the sample conversion run on 1,000 real messages with zero critical defects. The mapping document is reviewed by IT, operations and compliance, and signed off by the same April deadline as the BRD, because the build cannot start without it. The user stories are the third deliverable, and they are complete only when every requirement in the BRD is covered by at least one story, every story has acceptance criteria in Given, When, Then format, and every story is estimated and prioritised in the backlog. The analyst checks coverage with a traceability matrix that links each requirement to its stories, and any requirement with no story is flagged as a gap. The stories are reviewed in sprint planning with the development team, and the team confirms that each story is small enough to complete in one sprint. The test cases are the fourth deliverable, and they are complete only when they cover the happy path, the reject path, the return path and the recall path, plus the boundary conditions such as the maximum amount, the earliest value date and the cut-off time. Each test case needs a unique identifier, a precondition, numbered steps, and an expected result for every step. The test cases are reviewed by the test lead and by operations, because the operations team will execute the user acceptance tests and must understand every step without asking the analyst for help. The training material is the fifth deliverable, and it is complete only when it covers the new repair queue, the new pacs.008 enquiry screens, the new error codes, and the new reconciliation report. The material includes a slide deck, a one-page quick reference card, and a set of worked examples using real message data, such as repairing a payment of 125,000 dollars with an invalid IBAN. Training is delivered in October to all 25 operations staff, and attendance is recorded, because an untrained operator on go-live day is a risk to the whole migration. The go-live checklist is the final deliverable, and it is the document the team works through on the night of the cutover. It lists every task in order. Freeze the MT103 queue, run the final conversion, verify the first 100 pacs.008 messages against the mapping rules, confirm connectivity with each nostro agent, verify the reconciliation report, and open the support bridge with the names and phone numbers of every person on call. Each task has an owner and a sign-off box, and go-live is only declared when every box is ticked. The checklist is rehearsed twice in October so that the real night runs without surprises.
The Business Requirements Document is the first deliverable on the checklist, and it is complete only when it states the business objectives, the scope with explicit exclusions, the prioritised requirements, the business rules, and the success criteria. The BRD must be reviewed by the project sponsor, the operations head and the compliance lead, and signed off by the end of April. A BRD that is missing the out-of-scope section is not complete, because without it the team will argue about scope for the rest of the project. The analyst keeps the signed version in the project repository and versions every change after sign-off.
The mapping document is the second deliverable, and it is complete only when every MT103 field has a mapped pacs.008 element, a mapping type labelled as direct, derived or translated, and a rule for every exception. The document must include the parsing rules for fields 50K and 59, the charge code translation table, and the results of the sample conversion run on 1,000 real messages with zero critical defects. The mapping document is reviewed by IT, operations and compliance, and signed off by the same April deadline as the BRD, because the build cannot start without it.
The user stories are the third deliverable, and they are complete only when every requirement in the BRD is covered by at least one story, every story has acceptance criteria in Given, When, Then format, and every story is estimated and prioritised in the backlog. The analyst checks coverage with a traceability matrix that links each requirement to its stories, and any requirement with no story is flagged as a gap. The stories are reviewed in sprint planning with the development team, and the team confirms that each story is small enough to complete in one sprint.
The test cases are the fourth deliverable, and they are complete only when they cover the happy path, the reject path, the return path and the recall path, plus the boundary conditions such as the maximum amount, the earliest value date and the cut-off time. Each test case needs a unique identifier, a precondition, numbered steps, and an expected result for every step. The test cases are reviewed by the test lead and by operations, because the operations team will execute the user acceptance tests and must understand every step without asking the analyst for help.
The training material is the fifth deliverable, and it is complete only when it covers the new repair queue, the new pacs.008 enquiry screens, the new error codes, and the new reconciliation report. The material includes a slide deck, a one-page quick reference card, and a set of worked examples using real message data, such as repairing a payment of 125,000 dollars with an invalid IBAN. Training is delivered in October to all 25 operations staff, and attendance is recorded, because an untrained operator on go-live day is a risk to the whole migration.
The go-live checklist is the final deliverable, and it is the document the team works through on the night of the cutover. It lists every task in order. Freeze the MT103 queue, run the final conversion, verify the first 100 pacs.008 messages against the mapping rules, confirm connectivity with each nostro agent, verify the reconciliation report, and open the support bridge with the names and phone numbers of every person on call. Each task has an owner and a sign-off box, and go-live is only declared when every box is ticked. The checklist is rehearsed twice in October so that the real night runs without surprises.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.