Requirements & delivery
A system rollout, run from discovery through adoption
For Senior Business Systems Analyst roles
A company is rolling out a new enterprise platform, say expense management. It only works if the requirements match how the work really happens and the people actually adopt it. Here is the loop I run, end to end.
Requirements that match the real work, and an adoption plan that lands
The requirements come from watching how the work actually happens, not from the SOP. Every one traces to a design and a test. And the rollout is not done at go-live; it is done when the new way is the only way.
- Current → futuremapped side by side
- Every requirementtraced to design and test
- Adoptionmeasured, not assumed
The loop
- 01 Current stateHow the work actually happens today, not how the SOP says. Pain points, workarounds, handoffs.
- 02 Future state & requirementsThe target process, functional requirements, and acceptance criteria, with traceability so nothing gets lost.
- 03 Configure & validateRequirements turned into config and test cases; UAT with the people who will use it; defects triaged, not just logged.
- 04 AdoptDocumentation people can follow, training, a support path, and a check on whether it actually stuck.
01 · Current state vs future state
The same task, before and after. Toggle between them.
- Submit
- Staple paper receipts, email a scanned form to the manager
- Approve
- Manager forwards to finance; no policy check until finance catches it
- Post
- Finance keys each line into a spreadsheet, then into the GL
- Reimburse
- 2–3 weeks, next payment cycle
- Visibility
- None. "Where is my money" emails to finance
- Submit
- Photo the receipt in the app; policy rules check limits and categories at submission
- Approve
- Manager approves in the app; anything over threshold escalates automatically
- Post
- Approved expenses export to the GL nightly against a cost-center mapping
- Reimburse
- 3–5 business days
- Visibility
- Submitter sees status; finance sees a queue, not an inbox
02–03 · Requirements traceability
Requirement, acceptance criteria, the design that meets it, the test that proves it, and where it stands. Pick one.
- Requirement
- The system enforces per-category spend caps when an expense is submitted, not after
- Acceptance
- An over-limit line cannot be submitted without a flagged justification and a second approver
- Design
- Policy rules engine; caps by category and location; justification field unlocked on breach
- Test
- TC-12: submit a meal expense over the cap → blocked; add justification → routes to second approver
- Status
- Passed
- Requirement
- Approvals route by total amount, with escalation above a threshold
- Acceptance
- Under threshold → manager only; over → manager then department head
- Design
- Approval matrix keyed to amount and cost center; auto-escalation with a reminder cadence
- Test
- TC-20: submit above threshold → both approvals required in order
- Status
- Passed with a config note (reminder interval set to 48h, was 72h)
- Requirement
- Approved expenses post to the correct GL account and cost center automatically
- Acceptance
- Nightly batch; a mapping table drives account and cost center; failures are reported, not silent
- Design
- Scheduled export job; mapping maintained by finance; exception report on unmapped values
- Test
- TC-31: expense with a new cost center → export failed → mapping added → retest passed
- Status
- Failed, then Passed after the mapping fix
UAT sign-off
Run with the people who will use it. A defect is triaged (root cause, fix, retest), not just logged and left.
The result
A system that fits the work, requirements you can trace from ask to evidence, and a team that has actually moved, because the documentation, the training, and the support path were part of the plan, not an afterthought.
A generic expense-system rollout. The current/future mapping, the traceability, the UAT discipline, and the adoption work are how I actually run a delivery.
Open to a senior full-time role. Hiring brief →