IT Business Analist (SEPA)

The Opportunity

As a SEPA IT Business Analyst, you are a key player connecting Business, Architecture and IT delivery within the payments landscape.

You translate business problems, opportunities, regulatory demands and quality expectations into clear, testable functional and non-functional requirements. You lead requirements elicitation together with Customer Journey Experts, architects and engineering squads and describe expected IT-service behaviour using domain language and Gherkin scenarios.

Your responsibility does not stop when requirements are documented. You maintain traceability from the original business requirement through functional design and implementation to end-to-end validation, ensuring that the delivered SEPA IT service behaves as intended and meets the agreed functional and non-functional requirements.

This extends the IT BA Way of Work, which defines elicitation, analysis, documentation, modelling and verification of delivered IT solutions as core IT BA responsibilities.

Your Role and Work Environment

SEPA services support high-volume and business-critical payment processes. These services operate within a regulated and continuously evolving European payments ecosystem.

In this role, you contribute to initiatives involving areas such as:
-SEPA Credit Transfer
-SEPA Instant Credit Transfer
-SEPA Direct Debit

You work across domains and squads to ensure that requirements are understood consistently, functional dependencies are transparent, and the intended solution can be delivered safely and effectively.

Your Role and Work Environment

Requirements Engineering:

You take the lead in eliciting requirements for SEPA IT services.

You work with Customer Journey Experts, Product Leads, architects, Risk, Compliance and engineering squads to understand the business problem or opportunity, regulatory obligation and expected behaviour of the IT service.

Requirements are not created in isolation. You facilitate conversations until there is a shared understanding between Business and Tech.

You:
– Elicit business, architecture, IT, regulatory, functional and non-functional requirements.
– Challenge ambiguous, conflicting, incomplete or untestable requirements.
– Analyse the As-Is and To-Be processes and identify gaps, dependencies and impacts.
– Facilitate requirement workshops with CJEs, architects and squads.
– Establish acceptance criteria before implementation begins.
– Prioritize requirements, for example using MoSCoW.
– Translate requirements into scenarios using Gherkin, expressed in domain language understandable by Business and Technology.
– Use scenarios as a mechanism for discussion and shared understanding, rather than treating Gherkin simply as test documentation.
– Maintain scenarios throughout refinement, E2E design, development and validation.
– The IT BA Way of Work explicitly identifies requirements elicitation, categorization, prioritization and techniques such as story mapping, impact mapping and epic/feature/story slicing as part of the role.

Non-Functional Requirements

A key responsibility of the SEPA IT BA is to ensure that the solution does not only provide the correct payment functionality, but also delivers the quality characteristics required of a mission-critical payment service.

You lead the identification, clarification and validation of non-functional requirements together with the relevant engineering, architecture, security, risk and operational stakeholders.

Tests and Validates

The IT BA verifies that the delivered IT-solution meets the requirements, supported by use case translation into high level test cases.

Performance and Scalability

– Establish measurable requirements and perform the validation for End-to-end response time, Processing latency, Transaction throughput, Peak volumes, Concurrent processing, Batch processing windows, Capacity and scalability and Timeout behaviour and thresholds.
 
E2E Performance, Quality and Defect Triage

You establish and chair IT-service defect triage for the SEPA services within your responsibility.

The objective is not simply to distribute defects, but to establish the functional root cause, affected requirement and accountable component.

Together with representatives of the contributing squads, you:
– Review failed automated IT-service tests.
– Review findings from exploratory testing.
– Determine the violated requirement or scenario.
– Analyse the failure across application boundaries.
– Identify the root cause.
– Assign ownership to the appropriate squad.
– Determine whether requirements or scenarios require clarification.
– Track resolution and re-validation.

Squads outside the immediate organizational area should participate where their applications contribute to the affected IT service.