Business problem
Context, users, and the problem behind the screen.
Commercial credit change becomes risky when requirements, operational rules, approvals, test evidence, and release decisions are maintained in disconnected documents and trackers. The project demonstrates how a BA can connect those decisions without using confidential bank material.
Users and stakeholders
- Relationship Manager and Credit Analyst
- Credit Approver and Credit Administration
- Business Product Owner and Operations Lead
- Developers, QA, UAT users, and Release Steering Committee
My contribution
- Framed the case around a BA-owned evidence chain instead of a feature list or generic dashboard.
- Defined typed requirements, deterministic business rules, validation paths, traceability, and release gates for a safe public demonstration.
- Built the interactive workspace, supporting artefacts, tests, and deployment pipeline as an independent portfolio project.
Boundaries
Scope, non-goals, and assumptions.
In scope
- Commercial-credit case workflow and stage controls
- Document checklist, approval routing, and policy exceptions
- Requirement, rule, UAT, defect, CR, and release traceability
- Mock dashboards and evidence views for BA decision support
Out of scope
- Real customer data, internal bank policy wording, or production integration
- Authentication, entitlement administration, payments, accounting, or live credit scoring
- Claims of production deployment or measured bank outcomes
Assumptions
- All data, names, thresholds, metrics, and workflows are illustrative.
- Rules are generalized from common commercial-credit operating patterns.
- Local browser state is sufficient for a public demonstration; no database is required.
BA analysis
Requirements, business rules, and edge cases.
Functional requirements
- A case cannot advance when mandatory evidence or controlled approvals are incomplete.
- Every material rule or workflow change must identify affected roles, data, tests, and release gates.
- UAT failures and open defects must remain visible in the release recommendation.
- Decision views must preserve traceability back to requirements and evidence.
Business rules
- Missing mandatory documents block submission unless an approved waiver is present.
- Risk, exposure, collateral, and exception severity influence approval routing.
- Rule activation requires maker-checker approval and passed regression evidence.
- High-priority failed UAT or unresolved blocking defects produce a No-Go posture.
Edge cases considered
- A document is waived but the waiver has no reason or checker approval.
- A change request alters a rule while linked regression coverage is incomplete.
- A defect is fixed but has no retest evidence or accepted residual risk.
- A stage transition is requested by the wrong role or with missing tasks.
Validation & control
UAT coverage, defects, risk, and release confidence.
UAT coverage
- Positive, negative, boundary, role, and regression scenarios
- Requirement-to-test and defect-to-retest traceability
- Blocked-path validation for missing evidence and unauthorized transitions
- Release verification for gates, rollback triggers, and post-release monitoring
Risk and control
- Maker-checker segregation for waivers, rule changes, and sensitive decisions
- Audit evidence for state changes, approvals, overrides, and exports
- Explicit residual-risk acceptance before controlled release
- Mock-data disclaimer and confidentiality boundary on public surfaces
Judgment
Key decisions and the trade-offs behind them.
Design decisions
- Designed one evidence chain across analysis and delivery instead of isolated mini-tools.
- Kept rules deterministic and explainable so expected behavior can be reviewed and tested.
- Used progressive detail: recruiter summary first, interactive modules and artefacts second.
Trade-offs
- Local persistence keeps the demo safe and deployable, but does not model multi-user concurrency.
- Generalized rules protect confidentiality, but should not be interpreted as any bank's policy.
- Broad lifecycle coverage demonstrates BA thinking, while production integrations remain intentionally out of scope.
System understanding
Technical implementation at the level a BA should explain.
Technical details
- Next.js, React, strict TypeScript, Tailwind CSS, Lucide, and Recharts
- Typed mock data, deterministic business-rule functions, and local browser state
- Vitest business-rule tests, Playwright workflow tests, static export, and GitHub Pages
- Supporting OpenAPI contract, SQL analysis, BA documents, and CI checks
Outcome & learning
What this proves, what I learned, and what comes next.
Outcome
- Provides a live, inspectable demonstration of BA reasoning rather than a feature-only UI showcase.
- Connects requirement analysis, rules, UAT, defects, CR impact, controls, and release decisions.
- Creates concrete interview material without using confidential client artefacts.
Lessons learned
- Case-study depth is more persuasive when every screen points back to a business decision.
- Control logic needs negative and blocked scenarios, not only a happy-path workflow.
- A public banking portfolio must state assumptions and evidence boundaries as clearly as features.
Future enhancement
- Improve mobile table semantics and labelled controls across the deep workspace.
- Add a print-friendly one-page case summary after the core portfolio is launched.
- Keep database, login, CMS, and enterprise integrations out of the public MVP.