This case study is anonymised and generalised. It shows how I would document requirements for this process, based on my hands-on experience in it.
The business problem
Banks are closely regulated, so every purchase needs to be traceable: who requested it, who approved it, which supplier was chosen and why. When those steps rely on email chains and manual checks, purchases slow down, suppliers get onboarded without complete due diligence, and audits take a long time.
Stakeholders
| Stakeholder | Interest | Influence |
|---|---|---|
| Requesting departments | Fast, simple way to buy what they need | Medium |
| Procurement team | Fair sourcing, controlled spend, less rework | High |
| Finance / Accounts payable | Invoices match POs and receipts; budget control | High |
| Compliance & internal audit | Full audit trail, supplier due diligence (KYC) | High |
| Suppliers | Clear onboarding, on-time payment | Low |
Key pain points
- Requisitions arrived incomplete, which caused back-and-forth before a PO could be raised
- Approval routing depended on people knowing who to email
- Supplier onboarding documents were collected inconsistently
- Three-way match (PO, goods receipt, invoice) was checked by hand, which delayed payment
Sample user stories
US-01: As a requester, I want a guided requisition form with required fields and budget codes so that my request isn't sent back for missing information.
- Given a required field is empty, when I submit, then the form blocks submission and highlights the field.
- Given I select a cost centre, then only valid budget codes for that cost centre are shown.
US-02: As a procurement officer, I want approvals routed automatically by value threshold and category so that no purchase skips the right approver.
- Given a requisition above the threshold, then it routes to the next approval level automatically.
- Every approval is logged with approver, timestamp and decision.
US-03: As a compliance officer, I want the system to block POs to any supplier whose due diligence documents aren't verified so that we never buy from an unvetted supplier.
- Given a supplier's status is "pending", when a PO is raised, then the system blocks it and shows the missing documents.
US-04: As an accounts payable officer, I want invoices automatically matched to POs and goods receipts so that I only handle mismatches.
- Given invoice, PO and receipt match within tolerance, then the invoice is marked ready for payment.
- Given they don't match, then it's routed to an exception queue with the reason.
RACI (to-be process)
| Activity | Requester | Procurement | Finance | Compliance |
|---|---|---|---|---|
| Raise requisition | R/A | I | I | – |
| Source & select supplier | C | R/A | I | C |
| Supplier due diligence | – | R | – | A |
| Approve PO | I | R | A | – |
| Confirm goods receipt | R/A | I | I | – |
| Match & pay invoice | – | C | R/A | – |
R = Responsible · A = Accountable · C = Consulted · I = Informed
What this shows as a BA
- Identifying stakeholders and balancing competing needs (speed vs. control)
- Writing testable user stories in Given/When/Then form
- Making ownership explicit so the process holds up in an audit
Reflection
Requesters and compliance want opposite things: less friction and more control. The best requirements serve both, for example with guided forms that make the compliant path the easiest one.