BANKING SYSTEM REQUIREMENTS GATHERING: HOW TO CAPTURE WHAT MATTERS AND TRACE IT TO GO-LIVE
Requirements gathering is where a banking system implementation either builds the foundation that everything else stands on or takes on debt that will be paid down for the rest of the project.
When the work is rushed, poorly documented, or relies on the loudest voices in the room rather than the people who actually know how the institution operates, the consequences haunt you months later. Features that were assumed are missing. Workflows that no one captured break at cutover. Requirements that were never traced make their way into production as unanswered questions.
This article covers the elements of a rigorous requirements process: the role of subject matter experts, the four approaches that surface what the system has to do, the question of when workshops are the right format and when they are not, and the documentation discipline that carries requirements through testing, training, go-live, and the operations that follow.
The Bottom Line
Requirements gathering should begin before the system is selected. Doing it after locks the institution into a system it may not actually fit.
Subject matter experts are not optional. The institutional knowledge they carry cannot be reconstructed from documentation.
The four approaches to identifying requirements are not alternatives. They are complementary lenses, and a credible process applies all four.
Workshops are powerful when stakeholders are available and engaged. They are not the only valid format. The choice should be deliberate, not default.
Traceability is what turns requirements from a static document into a tool that supports testing, training, and post-go-live maintenance.
Subject Matter Experts Belong from the Start
Subject matter experts are the people who know how the institution operates. They understand the existing system, the workflows, the exceptions, and the unwritten rules that have evolved around what the current technology can and cannot do.
Without their involvement, requirements gathering relies on documentation that is often incomplete and on assumptions that often turn out to be wrong. With their involvement, the process surfaces what the new system must do, where the current system creates workarounds, and what cannot change without breaking something downstream.
Engage SMEs early and across all relative functions. Not just IT. Operations, lending, compliance, customer service, and finance each hold part of the picture, and a requirements process that talks to only some of them will miss requirements that surface later as gaps. Requirements work also belongs before the system selection decision is finalized, not after. Selecting a system without first understanding what it has to do leaves the institution committed to an unsuitable platform that will lead to greater software customization and change management issues.
Approach 1: Gaps and User Stories
The first approach to identifying requirements is documenting the gaps between the current system and the future state, then expressing each gap as a user story in the proper format.
Gap analysis is concrete. It identifies what the current system does, what the future system needs to do, and the delta between them. User stories then translate that delta into actionable units: as a [role], I need / want [capability] so that [outcome]. The format forces clarity about who the requirement is for and why it matters.
Gaps and user stories are most useful when the institution already has a clear understanding of how it operates today. If the current state is not well understood, gap analysis surfaces that absence before producing useful output. That is itself a valuable finding.
Approach 2: Out-of-the-Box Features and Documenting the Discovery
The second approach starts with what the prospective system provides out of the box and asks where the institution's requirements deviate from that baseline.
This is the practical complement to gap analysis. Rather than designing the future state from scratch and forcing the system to match it, the discovery process maps the new system's native capabilities against the institution's needs and documents what does not align. Each deviation is a candidate for configuration, customization, process change, or reconsideration of whether the requirement is necessary.
Doing this work early discourages the most expensive mistake in requirements gathering: assuming the new system has to do what the old one did, just because the old one did.
Approach 3: User Interface and Experience Requirements
The third approach captures what the system must do from the perspective of the people who use it: customers and employees.
For employees, this means mapping the journeys through tasks they perform every day, such as opening an account, processing a loan application, or resolving a customer inquiry, and confirming that the new system supports those journeys at the standard the institution needs. Persona modeling is a useful technique here, particularly for institutions with diverse user populations, as it helps contextualize the emotions and behaviour documented in the user journey maps.
Customer-facing experience requirements include the touchpoints the new system either supports directly (e.g. online banking, statements, letters) or feeds into (e.g. mobile, contact center, branch etc.). Reporting requirements, including regulatory reports, customer statements, and operational reports, belong in the experience layer too. They are often overlooked in early requirements gathering and discovered late, when the cost of addressing them is highest.
Approach 4: Non-Functional Requirements
The fourth approach addresses what the system has to do beyond the functional capabilities: how it has to perform, how it has to be operated, and how it has to recover.
Non-functional requirements include cutover plans, operational requirements, performance benchmarks, security expectations, scalability, and disaster recovery. They are often treated as a documentation afterthought, which means they surface as problems during testing or, worse, after go-live.
Treating non-functional requirements as a first-class part of the requirements process separates implementations that go live successfully from those that go live and then struggle to stay live. The article on planning a core banking implementation covers why these operational considerations belong in the foundation, not the side notes.
Workshops, Interviews, or Surveys
Workshops are powerful when stakeholders are available, engaged, and able to think collectively about how the institution operates. They bring different perspectives into the same room, surface disagreements that need to be resolved before requirements can be finalized, and produce documentation as a byproduct of the conversation.
Workshops are not the only valid format. Some requirements are more reliably captured in one-on-one interviews, particularly with stakeholders who carry highly specialized knowledge or who are not comfortable speaking in groups. Others, particularly large-volume structured requirements from front-line staff, are better captured through surveys.
The choice should be deliberate, based on the type of requirement, the availability of stakeholders, and the cultural realities of the organization. Defaulting to workshops because they are the standard practice often produces less useful output than a mixed approach that matches format to need.
Structuring a requirements process that holds up under the pressure of an implementation is its own discipline. 2Oaks' Strategic Advisory and Planning services help institutions design the approach, identify the right SMEs, and put traceability in place from the outset.
Documenting and Tracing Requirements Through Go-Live and Beyond
Requirements that exist only in workshop notes are not requirements. They are unverified assumptions waiting to surface as problems.
A requirements management discipline records each requirement in a form that can be reviewed, approved, and traced. The trace should follow the requirement from initial capture through design decisions, through test cases, through user training materials, and into the operational procedures that take effect at go-live.
Traceability is what makes requirements useful after go-live. When a defect surfaces, traceability identifies the requirement it relates to, the design decision that addressed it, and the test that should have caught the issue. When an enhancement is proposed, traceability identifies the existing requirements it intersects with. Without traceability, every change in the post-go-live environment becomes a new investigation.
For the discipline this requires in practice, the International Institute of Business Analysis (IIBA) publishes the Business Analysis Body of Knowledge (BABOK Guide), which remains the standard reference for requirements management across industries.
Key Questions Before Requirements Work Begins
Before committing to a requirements process for a banking system implementation, the leadership team should be able to answer the following with confidence:
Who at the organization holds the institutional knowledge this implementation depends on, and are they engaged in the requirements process?
Has each of the four approaches been applied, or has the process defaulted to whichever is most familiar?
Is a workshop the right format for the requirements being captured or has it become the default by inertia?
Are non-functional requirements being captured with the same discipline as functional ones?
Will requirements be traceable from capture through to operations, or is the documentation at risk of becoming orphaned after design?
If any of those surface uncertainty, the right response is to address it now. The cost of a missing or untraceable requirement compounds at every subsequent phase.
Building a rigorous requirements process? 2Oaks helps financial institutions structure requirements gathering that holds up from selection through to go-live. Get in touch to start the conversation.
This article is adapted from Transforming Banking: An Introduction to Implementing a New System, by Andrew Mills and Bruce Hogg of 2Oaks Consulting.
Learn more about 2Oaks' Executive Technology Advisory Service and how we support institutions through every phase of a banking system implementation.
Further Reading
International Institute of Business Analysis: BABOK Guide and resources. The standard reference for requirements management practice, including elicitation techniques, traceability, and the governance disciplines that carry requirements from discovery through to operations.
This article is adapted from Transforming Banking: An Introduction to Implementing a New System, by Andrew Mills and Bruce Hogg of 2Oaks Consulting.
Learn more about 2Oaks' Program Delivery and Governance practice and how we support institutions through the full implementation lifecycle.
Explore our Banking Domains expertise and how we support financial institutions through complex technology decisions.
ABOUT 2OAKS
2Oaks emerged from deep within the banking sector, where our founders personally navigated the challenges of core system modernization. This hands-on experience shaped our unique approach to technology consulting -one that combines technical expertise with practical wisdom. We're not your typical consultancy. As a vendor neutral partner, we work exclusively for our clients' interests across banking, financial services, retail, and public sectors.
What sets us apart is our commitment to co-creation and knowledge transfer. We work alongside your team, ensuring that our solutions aren't just implemented but truly integrated into your organization. Our lean, efficient approach eschews unnecessary complexity in favour of practical, results-driven outcomes. Whether you're facing a system transformation, technology upgrade, or strategic shift, reach out to 2Oaks to discover how our principled, authentic approach can drive your success.