Business Analyst

Role purpose

Sit between the business and the build team. Take business requirements - often incomplete, verbal, or expressed as outcomes rather than needs - and convert them into functional specifications the business can sign off, and technical specifications engineers can implement without further interpretation.

The role owns the requirement from the moment it is raised until it is delivered, tested and accepted. Success is measured by how few clarification cycles the build team needs and how little rework surfaces in UAT.

Requirements

Key responsibilities

Requirements elicitation and analysis

• Run workshops, interviews and process walkthroughs with business stakeholders, subject matter experts and operations teams.
• Challenge stated requirements to establish the underlying business need, the decision being supported, and the value being sought.
• Identify gaps, contradictions, duplication and unstated assumptions in the source requirements, and drive them to resolution rather than escalating them unresolved.
• Document current-state ("as-is") processes and define target-state ("to-be") processes, including the operational and control changes required.
• Assess regulatory, audit and data-protection implications of each requirement and flag where compliance input is needed.

Functional specification

• Author functional specification documents that define system behaviour in business terms: process flows, use cases or user stories, business rules, decision tables, validation logic, calculation logic, roles and permissions, notifications, and reporting outputs.
• Define exception paths, error handling and edge cases explicitly - not only the happy path.
• Write clear, testable acceptance criteria for every requirement.
• Secure formal business sign-off on the functional specification before build commences.

Technical specification

• Translate the approved functional specification into a technical specification that engineering can build against, covering:
• System and component architecture in scope, and the changes required to each.
• Data model changes: entities, attributes, data types, cardinality, referential integrity, retention.
• Integration and interface specifications: API contracts, request/response payloads, protocols, authentication, error and retry behaviour, throughput and volumetrics.
• Data migration and transformation rules, including source-to-target field mappings and cleansing logic.
• Configuration versus customisation decisions, with rationale.
• Non-functional requirements: performance, availability, scalability, security, auditability, logging and monitoring.
• Work with solution architects and developers to validate technical feasibility, sizing and effort, and to reconcile the specification with platform constraints.
• Document assumptions, dependencies, constraints and out-of-scope items.

Delivery and quality support

• Maintain a requirements traceability matrix linking business requirement → functional specification → technical specification → test case → delivered feature.
• Groom and maintain the backlog; ensure work items entering a sprint meet the team's definition of ready.
• Support developers through build, acting as the authority on intended behaviour.
• Author or review test scenarios; support SIT and UAT, triage defects, and distinguish genuine defects from change requests.
• Contribute to release notes, training material, user guides and operational handover documentation.

Change and stakeholder management

• Run impact assessments on change requests: effort, risk, dependencies, cost and schedule implications.
• Manage version control and change history across all specification artefacts.
• Keep business and technical stakeholders aligned on scope, sequencing and trade-offs, and communicate decisions and their consequences clearly to both audiences.

Deliverables owned by this role

• Requirements catalogue / business requirements analysis
• Functional specification document (FSD)
• Technical specification document (TSD)
• Process models (BPMN or equivalent) - as-is and to-be
• Data dictionary and source-to-target mappings
• Interface / integration specification
• User stories with acceptance criteria
• Requirements traceability matrix
• UAT test scenarios and support for execution
• Impact assessments for change requests