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