LAB-01: Write Requirements for Same-Day Cross-Border Payments for SMEs
Requirement analysis
A mid-sized bank wants to offer same-day cross-border payments to its small and medium enterprise customers, who today wait two to three days for supplier payments to arrive. The current process relies on manual checks, emailed instructions and a correspondent chain that the customer cannot track. In this lab you act as the business analyst who turns that business problem into a clear, testable set of requirements. You will define the objectives and the scope, identify the stakeholders, record the assumptions and dependencies, and write the business rules that govern cutoffs, charges and value dates. You will then separate functional requirements from non-functional requirements, so that the development team knows what the solution must do and how well it must do it. By the end of the lab you will have a requirements pack that a sponsor can sign off and a development team can build from without guessing.
0 of 5 steps done. Tick each step as you finish it, your progress is saved in this browser.
Interview the product owner and two SME customers to describe the problem in business terms, not technical terms. Record the pain: slow settlement, no tracking and lost supplier discounts. Set three measurable objectives, for example same-day value for 90 percent of payments submitted before the cutoff, end to end tracking for every payment, and a 30 percent reduction in manual handling. Agree how each objective will be measured after launch, and get the sponsor to confirm that the objectives are worth the investment before you write any requirement.
Draw the scope boundary: which currencies, corridors, channels and customer segments are in scope, and which are out. List every stakeholder, from the SME product team and operations to compliance, treasury, technology and the correspondent banks. Build a RACI for the key decisions, naming who is responsible, accountable, consulted and informed. Confirm the scope with the sponsor in writing, because a same-day payment project grows quickly if new corridors or currencies are added without a formal change decision.
Write down every assumption the solution depends on, such as correspondent banks supporting same-day value in the chosen corridors, and the core banking system exposing real time balances. List the dependencies, including the sanctions screening upgrade, the FX pricing feed and the customer notification service. Note the constraints, for example the regulatory cutoff times, the liquidity limits and the budget. For each assumption, name the owner and the date by which it must be confirmed, so an unconfirmed assumption never becomes a surprise at testing.
Capture the rules that decide how a payment behaves: the cutoff time in each corridor, the charge bearer options, the FX rate lock period, the handling of insufficient funds, and the rules for repair when beneficiary data is incomplete. Write each rule as a single clear statement with its condition and its result, and give it a unique identifier. Walk the rules through with operations and compliance using two worked examples, one clean payment and one that misses the cutoff, and correct any rule that the examples prove wrong.
Write the functional requirements as testable statements, each with a unique identifier, a priority and an acceptance test in mind. Cover initiation, validation, screening, routing, status reporting and reconciliation. Then write the non-functional requirements: response time under two seconds for a status enquiry, availability of 99.9 percent, audit logging of every state change, and data protection for customer details. Review the full set with the product owner and the test lead, remove duplicates, and trace every requirement back to a business objective.
Templates.
- Business problem statement: one page that states the problem, the affected customers, the cost of doing nothing and the measurable objectives.
- Stakeholder and RACI template: a table of stakeholders, their interest, their influence and their RACI role for each major decision.
- Business rules register: a numbered list of rules with condition, result, owner, source and status.
- Requirements specification template: sections for scope, functional requirements, non-functional requirements, assumptions, dependencies and sign off.
Worked example. Northbridge Bank, a fictional mid-sized bank in the United Kingdom, wants its SME customers to pay suppliers in Germany and the Netherlands on the same day. Today a payment of 45,000 euros from a Manchester engineering firm to a supplier in Rotterdam takes two days, and the customer cannot see where the money is. The analyst interviews the product owner, two SME customers and the operations manager, and sets the objective that 90 percent of payments submitted before 11:00 reach the beneficiary bank the same day. The scope covers euro payments through the correspondent network, initiated in internet banking, with a cutoff of 11:00 London time and a fixed fee of 12 pounds. A business rule states that any payment submitted after 11:00 is queued for the next business day and the customer is told immediately. Another rule states that a payment with a missing IBAN is returned to the customer for repair rather than sent to the correspondent. The requirements pack lists 28 functional requirements, including real time status updates and a pacs.002 based status feed, plus non-functional requirements for 99.9 percent availability and full audit logging. The sponsor signs off the pack, and the development team estimates the build from it without a single clarification meeting in the first sprint.
Deliverables.
- Business problem statement with measurable objectives and success criteria
- Stakeholder map and RACI for the same-day cross-border payment service
- Business rules register covering cutoffs, charges, FX and repair handling
- Requirements specification with functional and non-functional requirements traced to objectives