Business Analysis

What BA employers look for in candidates

• Evidence of structured thinking, clear documentation, and stakeholder communication.
• Most junior BA candidates lack real project experience, so demonstrating the process is more important than the outcome.

Portfolio artefact 1: Process improvement case study

• Choose a process you have experienced (a workplace workflow, a customer journey, a service you use).
• Draw the as-is process using swimlane notation.
• Identify three pain points with evidence (observations, data, or user feedback).
• Design a to-be process.
• Document what changed and why.
• Keep this to two pages plus diagrams.

Portfolio artefact 2: Requirements document

• Write a mock requirements document for a small system (a booking system, a notification service, a reporting dashboard).
• Include: background and objectives, stakeholder list, functional requirements (user story format), non-functional requirements, and assumptions and constraints.
• This demonstrates you know the format.

Portfolio artefact 3: User stories with acceptance criteria

• Write ten user stories in standard format (As a..
• I want..
• So that...) for a real product you know well.
• Add three acceptance criteria to each in Given/When/Then format.
• These demonstrate that you understand what makes a good requirement.

Getting your first BA role

• BA is one of the most accessible entry points into tech for career changers.
• Domain knowledge (healthcare, finance, logistics) adds significant value.
• A nurse applying for a BA role at an NHS digital programme brings context that a recent graduate cannot.

Where to look

• NHS Digital, HMRC, DWP, Cabinet Office, and local government digital teams all hire BAs regularly.
• Management consultancies (Accenture, Deloitte, PA Consulting) run graduate programmes.
• Financial services firms (banks, insurers) hire BAs for change programmes.
• LinkedIn filters for Business Analyst, Requirements Analyst.

Certifications

• BCS Foundation Certificate in Business Analysis is widely recognised and worth pursuing.
• The IIBA CBAP is for senior practitioners.
• Neither is required at entry level but BCS Foundation demonstrates commitment.

CV structure

• Highlight any experience of documentation, process improvement, or stakeholder communication even in non-tech roles.
• Operations managers, project coordinators, and customer service leads often have BA skills without realising it.

Common BA interview questions

• "Walk me through how you would elicit requirements from a reluctant stakeholder." Prepare, not just attend.
• Research their role and what they care about.
• Ask open questions.
• Listen more than you talk.
• Document and validate what you heard before the next session.

• "What is the difference between a functional and non-functional requirement?" Functional: what the system does (user can submit a form).
• Non-functional: how it does it (the page must load in under two seconds).

• "How do you handle conflicting requirements from two stakeholders?" Understand both positions fully.
• Identify the underlying business goal each requirement serves.
• Find the common ground.
• Escalate to a decision-maker only when the conflict cannot be resolved at team level.

• "What is a use case and how is it different from a user story?" Use case describes a complete interaction sequence between an actor and a system, including alternative flows and exceptions.
• A user story is a short description of a feature from the user perspective, with acceptance criteria confirmed through conversation.
• Use cases are more formal and more complete.

• "How do you manage scope creep?" Document agreed scope in a requirements baseline.
• Log change requests separately.
• Assess impact on cost and timeline.
• Escalate formally.
• Never quietly absorb changes without recording them.

Mistake 1: Documenting requirements without validating them

• Writing down what stakeholders say is not the same as understanding what they need.
• Always play requirements back, ask "what would prevent this from working?", and test edge cases.

Mistake 2: Vague acceptance criteria

• "The system should be easy to use" is not an acceptance criterion.
• "When a user submits the form with all required fields completed, they receive a confirmation email within two minutes" is.
• Specificity is the job.

Mistake 3: Being a passive note-taker in workshops

• A BA facilitates, not records.
• If you only take notes and never challenge, clarify, or synthesise, you are not doing the job.
• Practice facilitation skills explicitly.

Mistake 4: Ignoring non-functional requirements

• Performance, security, accessibility, and audit requirements are frequently forgotten until late in delivery and are expensive to retrofit.
• Ask about them early.

Mistake 5: Not learning the domain

• A BA who does not understand the business they are analysing cannot spot when a requirement is technically correct but practically wrong.
• Invest time in understanding how the organisation makes money and what its constraints are.