Business Analyst interview questions and answers

A business analyst (BA) connects the business and the technical team. They understand a business problem. They turn it into clear requirements that can be tested. They make sure the final solution really solves the problem.

Typical work:

• Ask stakeholders what they need, through interviews, workshops, and watching the work.
• Analyse and write down requirements (user stories, use cases, process models).
• Find gaps, risks, and conflicts early, and suggest options with trade-offs.
• Help developers and testers with questions, and help run UAT (user acceptance testing).
• Track changes and keep every requirement linked to a business goal.

A BA owns the quality of the analysis. The value is not in taking notes. The value is in asking why, questioning assumptions, and recommending a solution.

What they are checking: Do you see the role as analysis and advice, not just writing documents?

They record requirements at different levels, for different readers.

In practice, a BRD explains why the project is needed. An FRD describes what the solution does. An SRS is the detailed agreement that developers build from and testers check against. Many agile teams replace all three with a backlog of user stories and a short vision document.

What they are checking: Can you place each document in the right level of requirements?

Elicitation means drawing requirements out of stakeholders. Common techniques:

• Interviews: one to one. Good for depth and sensitive topics.
• Workshops (JAD sessions): group sessions that align many stakeholders quickly.
• Observation (job shadowing): watch the real work to find steps that people forget to mention.
• Document analysis: read existing manuals, reports, and policies.
• Surveys and questionnaires: reach many people at low cost.
• Prototypes and wireframes: let users react to something they can see.
• Brainstorming and focus groups: collect ideas.
• Reverse engineering of an old system.

Use a mix. Interviews plus observation usually show the gap between what people say and what they do.

What they are checking: Do you know many techniques, and can you match them to situations?

A user story is a short description of a need from the user's point of view: "As a <role>, I want <goal>, so that <benefit>."

A good story follows INVEST:

• Independent: can be built without depending on another story.
• Negotiable: details are discussed, not fixed.
• Valuable: gives value to a user or the business.
• Estimable: the team can size it.
• Small: fits within a sprint.
• Testable: has clear acceptance criteria.

Example story: "As a patient, I want to reschedule an appointment online, so that I do not need to call the clinic". The story starts a conversation. It is not a full specification.

What they are checking: Do you know INVEST and the "so that" part?

Acceptance criteria are the specific conditions a story must meet to be accepted. You can test each one. They remove doubt about what "done" means.

They are often written in Given/When/Then form:

• Given a registered user is on the login page
• When they enter a valid email and password
• Then they land on the dashboard

Add negative cases and edge cases too. A wrong password shows an error and does not say which field was wrong. After five failed attempts the account locks for 15 minutes.

Good criteria are pass or fail. They cover the normal path, errors, and limits. You can turn them directly into test cases.

What they are checking: Can you test your criteria, and do they include negative cases?

Functional requirements describe what the system does. Non-functional requirements describe how well it does it.

• Functional: "The system shall let a user reset a password using an emailed link."
• Non-functional (quality attributes): performance (page loads in under 2 seconds) and security (data encrypted at rest). Others are availability (99.9% uptime), scalability, usability, compliance (audit logging), and maintainability.

People often forget non-functional requirements. Then they cause the most costly rework. So a BA should ask about them directly and make them measurable.

What they are checking: Do you capture quality needs, not just features?

MoSCoW sorts requirements into four groups:

• Must have: without it the release fails, or it is illegal or unsafe.
• Should have: important, but there is a workaround for now.
• Could have: nice to have. Include it if time allows.
• Won't have (this time): agreed to be out of scope for this release.

Tips: keep Musts to about 60% of the effort, so there is room for risk. Agree on the groups with stakeholders in a workshop. Write down the Won't haves so expectations are clear. Other methods include value vs effort, Kano, and weighted scoring.

What they are checking: Do you know prioritisation words, and can you use them?

User Acceptance Testing (UAT) is the final test phase. Business users confirm that the solution meets their needs before go-live.

BA role:

• Help define the UAT scope and scenarios from the requirements and acceptance criteria.
• Write or review test cases in business language.
• Arrange users, test data, and the environment.
• Sort defects: a real defect, a change request, or a misunderstanding.
• Track results and get formal sign-off.

UAT is not for finding every bug. That is QA's job. UAT checks that the solution fits real business processes.

What they are checking: Do you know how UAT differs from QA testing?

In Waterfall, the BA gathers detailed requirements up front and gets them signed off. Then design, build, and test follow in phases. Change is formal and costly.

In Agile, the BA works all the time with the product owner and the team. They refine the backlog and write user stories. They clear up details just in time and support each sprint review.

The BA skills are the same: elicitation, analysis, and communication. Only the rhythm and the documents change.

What they are checking: Can you adapt to different ways of delivering projects?

A BA should be able to read data and answer questions. Use SELECT, WHERE, ORDER BY, GROUP BY with aggregates, HAVING, JOINs, and simple subqueries. Writing data (INSERT, UPDATE, DELETE) is usually left to developers.

Example: total claim amount per provider for 2025, only for providers above 100000:

SELECT p.provider_name, SUM(c.amount) AS total_amount
FROM claims c
JOIN providers p ON p.provider_id = c.provider_id
WHERE c.service_date >= '2025-01-01' AND c.service_date < '2026-01-01'
GROUP BY p.provider_name
HAVING SUM(c.amount) > 100000
ORDER BY total_amount DESC;

Use SQL to check requirements against real data, find duplicates and nulls, and check reports.

What they are checking: Do you have practical data skills, not just theory?

INNER JOIN returns only the rows that have a match in both tables. LEFT JOIN returns all rows from the left table, plus the matching rows from the right. Where there is no match, the right side is NULL.

I treat it as an analysis problem. I bring a recommendation, not just a complaint to the sponsor.

1. Clarify each position. Separate the real need from the proposed solution. Often the needs fit together even when the solutions do not.
2. Check each position against the business goal and success measures. Measure the...

First I find out why. It could be a new business need, a missed requirement, or just a preference. Then I run an impact analysis using the traceability matrix. I check which requirements, designs, and tests change. I check the effect on effort, schedule, cost, and risk.

I make my case with evidence. Then I support the decision. First I make sure I understand their reasons and the problem behind the request. Then I bring analysis: user data or research, cost and complexity, risk, conflict with other priorities, and the likely effect on the business goal. I suggest simpler options that meet the same need. I also suggest a cheap test, such as a prototype or a limited release, to check the idea.

HL7 (Health Level Seven) is a set of standards for sharing health data between systems.

v2 is by far the most used for internal hospital interfaces. CCDA is used to exchange documents. FHIR is the direction for new APIs and rules.

What they are checking: Can you place each standard and say where it is used?

An HL7 v2 message is a text message made of segments, one per line. Inside a segment, fields are separated by |, components by ^, repetitions by ~, the escape character is \ and sub-components are separated by &.

Common segments:

• MSH: message header (sender, receiver, message type, control ID, version)
• EVN: event
• PID: patient identification
• PV1: patient visit
• OBR: observation request
• OBX: observation result
• ORC: common order
• NK1: next of kin
• AL1: allergy
• DG1: diagnosis
• IN1: insurance

MSH|^~\&|ADT|HOSP|EHR|HOSP|20250101120000||ADT^A01|MSG0001|P|2.5
EVN|A01|20250101120000
PID|1||123456^^^HOSP^MR||DOE^JANE||19900101|F
PV1|1|I|WARD1^101^A

MSH-9 tells the receiver what the message is. The receiver replies with an ACK.

What they are checking: Can you read a raw HL7 message?

ADT (Admit, Discharge, Transfer) messages tell other systems about patient registration and movement. The trigger event is the part after the caret in MSH-9.

• A01: admit/visit notice
• A02: transfer a patient
• A03: discharge/end visit
• A04: register a patient (outpatient/ED)
• A08: update patient information
• A11: cancel admit
• A40: merge patient identifiers

ADT feeds keep lab, radiology, pharmacy and billing systems in sync with the patient master record and bed status.

What they are checking: Do you know the most common message type?

A FHIR resource is a small unit of healthcare data with a standard structure. It is identified by a type and an id. Examples: Patient, Practitioner, Organization, Encounter, Observation, Condition, MedicationRequest, AllergyIntolerance, Procedure, DiagnosticReport, Claim, ExplanationOfBenefit, Coverage, and Bundle (a container for resources).

{"resourceType": "Patient", "id": "123", "name": [{"family": "Doe", "given": ["Jane"]}], "gender": "female", "birthDate": "1990-01-01"}

Resources point to each other. An Observation points to a Patient through subject. This forms the data model.

What they are checking: Do you know the core FHIR words?

FHIR uses standard HTTP verbs on resource URLs, with JSON or XML bodies:

GET    /Patient/123                       read one
GET    /Patient?family=Doe&birthdate=1990-01-01   search
POST   /Patient                           create (returns 201 and Location)
PUT    /Patient/123                       update (replace)
PATCH  /Patient/123                       partial update
DELETE /Patient/123                       delete
GET    /metadata                          CapabilityStatement
GET    /Patient/123/_history              versions

A search returns a Bundle of type searchset with paging links. Use _include and _revinclude to get related resources. Use Observation?patient=123&code=http://loinc.org|718-7 to search by code.

What they are checking: Can you use APIs in practice?

EDI (Electronic Data Interchange) is the structured exchange of business documents between computers. In US healthcare, HIPAA requires the ASC X12 standard (version 5010) for admin transactions between providers, payers and clearinghouses.

X12 files are made of segments that end with ~. Elements are separated by *, and sub-elements by :. The envelope has ISA/IEA (interchange), GS/GE (functional group) and ST/SE (transaction set). Key transactions: 837 claims, 835 remittance, 270/271 eligibility, 276/277 claim status, 278 prior authorisation, 834 enrolment, 820 premium payment.

What they are checking: Do you know EDI basics and the envelope structure?

A 999 confirms that a file was accepted in terms of syntax.

What they are checking: Do you know the core transaction map?

1. Registration and eligibility: collect insurance, check coverage (270/271), and get prior authorisation if needed.
2. Service delivery and notes.
3. Charge capture and coding: assign ICD-10 diagnosis codes and CPT/HCPCS procedure codes.
4. Claim creation and scrubbing: build the 837 and run checks to catch errors.
5. Submission to the payer through a clearinghouse.
6. Adjudication: the payer checks eligibility, medical need, coding and price. Then it pays, denies or holds the claim.
7. Remittance: the 835 and the EOB explain the payment and adjustments.
8. Payment posting and billing the patient for the balance.
9. Denials and appeals, then follow-up.

A BA should know where data can break at each step.

What they are checking: Do you understand the domain from start to end?

A rejection happens before adjudication. The claim failed format or front-end checks, for example missing data, an invalid code or a wrong member ID. It was never processed. You must correct it and send it again.

A denial happens after adjudication. The payer processed the claim and refused to pay. Typical reasons are no coverage, no authorisation, not medically necessary, or filing too late. You handle a denial by correcting the claim and appealing. Use the CARC and RARC codes on the 835 to understand why.

What they are checking: Do you know the difference between a rejection and a denial?

HIPAA (Health Insurance Portability and Accountability Act, US) protects health information and sets standard transactions. Main rules:

• Privacy Rule: who may use or share PHI. Patients can see their data and ask for changes. Share only the minimum necessary.
• Security Rule: admin, physical and technical safeguards for electronic PHI (access control, audit logs, encryption, risk analysis).
• Breach Notification Rule: after a breach, tell the people affected, the regulators, and sometimes the media.
• Transactions and Code Sets Rule: standard X12 formats and code sets.
• Enforcement Rule: penalties.

It applies to covered entities (providers, plans, clearinghouses) and their business associates. Business associates sign a Business Associate Agreement (BAA).

What they are checking: Do you know the compliance rules?

PII (personally identifiable information) is any data that can identify a person, such as name, national ID or email. PHI (protected health information) is health information that identifies a person. It covers past, present or future health, care, or payment for care. It is held or sent by a HIPAA covered entity or business associate, in any form.

• ICD-10-CM: diagnosis codes (what is wrong). They are alphanumeric, up to 7 characters, for example E11.9 for type 2 diabetes without complications. ICD-10-PCS is used for hospital inpatient procedures.
• CPT: procedure and service codes kept by the AMA. They have five characters, for example 99213 for an office visit. Modifiers change them.
• HCPCS Level II: codes for supplies, equipment, drugs and services outside CPT, for example J-codes for injectable drugs.

I work from the message to the cause:

1. Get the failing raw message and the ACK or error code from the engine logs.
2. Check the header: version, message type and event, sending application, and delimiters.
3. Check the required fields against the interface specification. Look at the PID-3 identifier, the name, the...

A use case describes how an actor (a user or another system) interacts with the system to reach a goal. It includes the main flow, other flows, and exceptions. A user story is a short statement of a need, with acceptance criteria.

An RTM is a table that links each requirement to its source (a business goal). It also links forward to design, development, test cases, and release. It proves that every requirement is covered. It also shows that every test or feature has a reason to exist.

Gap analysis compares the current state (as-is) with the wanted state (to-be). It finds what is missing to get there.

Steps:

1. Define the wanted future state and the success measures.
2. Document the current state (process, systems, skills).
3. List the gaps.
4. Suggest actions, rank them, and estimate the effort.

I document a process by interviewing the people who do it. I walk through real examples. Then I draw it as a flow with clear owners and decisions.

The product backlog is the ordered list of everything that might be built: features, fixes, and technical work. The product owner owns the order.

A user directly uses the solution. A stakeholder is anyone who is affected by the project or can influence it. This includes sponsors, regulators, support teams, and users.

Scope creep is uncontrolled growth of scope after the baseline is agreed. It usually comes from small requests that nobody records.

Verification checks that requirements are well written. Validation checks that they are the right requirements.

A good requirement is one clear statement that you can test, with a measurable result. For example: "The system shall show search results within 2 seconds for 95% of queries."

A want is a proposed solution ("add an export button"). A need is the real problem behind it ("finance must reconcile weekly figures without typing the data again"). If you take wants literally, the solution is often poor.

A practical BRD includes:

• Executive summary and the business problem.
• Objectives and success measures (KPIs).
• Scope: what is in and what is out.
• Stakeholders and their roles.
• Current state and wanted future state.
• Business requirements and business rules, with priorities.
• Assumptions, limits, and dependencies.
• Risks and how to reduce them.
• Cost-benefit or a summary of the business case.
• Glossary and approvals.

I check the change against everything it touches before anyone approves it.

1. Understand the request and the business reason.
2. Use the traceability matrix to find the affected requirements, designs, tests, and interfaces.
3. Estimate the effect on effort, cost, and schedule with the technical team.
4. Find the...

First I find the cause. It may be unclear first requirements, a changing business situation, or a stakeholder who was not involved enough. Then I do these things:

• Confirm the baseline again and show the agreed change process.
• Ask for each change to come with a reason and business value, and run an impact analysis....