Basic Business Analyst Interview Questions: Key Concepts and Best

Responses
What do you understand by these terms?
Process Design

As a Business Analyst (BA) in software development, process design involves defining and refining
business processes to ensure that the solution effectively meets stakeholder needs and aligns with
business goals. Here's a comprehensive overview of Process Design from a BA’s perspective:

1. Understanding the Current State (As-Is Process)

 Gather information through:

o Stakeholder interviews

o Observations

o Document analysis

 Create process maps or flowcharts using tools like:

o BPMN (Business Process Model and Notation)

o Flowcharts / Swimlane diagrams

o Tools: Lucidchart, Visio, Draw.io

2. Identifying Gaps & Issues

 Look for:

o Bottlenecks

o Manual steps that can be automated

o Redundant or duplicated tasks

o Compliance or data security gaps

3. Designing the Future State (To-Be Process)

 Collaborate with stakeholders and tech teams to design the optimized process.

 Ensure alignment with:

o Business goals

o Technical feasibility

o Regulatory needs

4. Validating the Proposed Process

 Conduct workshops, walkthroughs, or reviews with:

 o Stakeholders

o Development teams

o QA team

5. Documenting the Process

 Deliverables include:

o Process Maps (As-Is and To-Be)

o Functional & Non-functional Requirements

o Use Cases / User Stories

o Business Rules

o SOPs (Standard Operating Procedures)

6. Supporting Implementation

 Work with developers and testers during:

o Sprint planning (Agile)

o UAT (User Acceptance Testing)

o Go-live support and training

🔶 Sample Tools for Process Design

Tool Use Case

Lucidchart BPMN, flowcharts

Bizagi Process modeling and simulation

Visio Swimlane diagrams, flowcharts

Balsamiq / Figma For UI mockups (if UI involved)

🔶 Example: Online Order Process

➤ As-Is Process (Manual Order Processing):

 Customer calls store

 Employee writes order on paper

 Manual billing and shipping

➤ To-Be Process (Digital Order Processing):

 Customer places order online

  System auto-generates invoice

 Order is tracked via dashboard

 Customer gets email notifications

🔶 Best Practices

 Involve end-users early and often.

 Use visuals to simplify complex processes.

 Ensure traceability of process changes to requirements.

 Keep stakeholder alignment at all stages.

🔶 Summary

Phase BA Activities

Discover Identify current processes

Analyze Spot inefficiencies

Design Propose optimized process (To-Be)

Document Create process diagrams, specs, and requirements

Support Assist development and testing teams

What is a Feasibility Study?

A Feasibility Study evaluates whether a project or solution is practical and achievable in terms of
business needs, technical capability, and cost-effectiveness.

It typically answers:

“Should we proceed with this project or not?”

🔷 Types of Feasibility Analyses a BA Conducts

Type Description

✅ Business Feasibility Does it align with business goals? Will it provide value?

✅ Technical Feasibility Can it be built with current tech and team capability?

✅ Operational Feasibility Will users adopt it? Can it be integrated into existing operations?

✅ Economic Feasibility Do the expected benefits outweigh the costs? (Cost-benefit analysis)
Type Description

✅ Schedule Feasibility Can it be delivered in the required time frame?

✅ Legal/Regulatory Feasibility Are there any compliance, data protection, or licensing issues?

🔷 Role of Business Analyst in Feasibility Study

1. Initiate Stakeholder Discussions

 Identify project objectives, constraints, and high-level requirements.

 Understand expectations and potential ROI.

2. Gather and Analyze Information

 Perform SWOT analysis (Strengths, Weaknesses, Opportunities, Threats)

 Evaluate current systems and tools.

 Identify alternatives and evaluate each one.

3. Collaborate with Technical Teams

 Discuss technical possibilities, limitations, and existing architecture.

 Review integration possibilities with other systems.

4. Cost & Effort Estimation Support

 Work with project managers and architects to assess:

o Resource needs

o Budget estimates

o Timeline

5. Document and Present Findings

 Create a Feasibility Report with:

o Executive summary

o Feasibility assessment (all types)

o Recommendation (Go / No-Go)

o Assumptions, constraints, risks

🔷 Feasibility Study Template (Simplified)

Section Content

1. Project Overview Objective, scope, goals

Section Content

2. Business Need Why is this needed? Problem statement

3. Feasibility Types Business, Technical, Operational, Economic, Legal

4. Risk Assessment Key risks and mitigation strategies

5. Cost-Benefit Analysis High-level cost estimates vs expected value

6. Recommendation Proceed / Not proceed with reasons

7. Stakeholder Summary Who is impacted or consulted

🔷 Example (E-commerce Chatbot)

Feasibility Type Evaluation

Business Improves customer support & retention ✅

Technical Can be integrated with existing tech stack ✅

Operational Requires training for support staff ⚠️

Economic Cost of development vs long-term savings = favorable ✅

Schedule Needs 3 months; feasible in roadmap ✅

Legal Must ensure data privacy compliance (GDPR) ⚠️

🔷 Best Practices for BAs

 Involve all relevant stakeholders early.

 Ensure objective, fact-based analysis.

 Provide clear recommendations.

 Keep assumptions and constraints visible.

 Use visuals (diagrams, charts) where possible.

🔷 Summary Table

Phase BA Role

Initiation Understand problem, align with goals

Exploration Evaluate options, gather data

Analysis Perform feasibility assessments

Documentation Prepare and present feasibility report

Phase BA Role

Decision Support Help stakeholders make go/no-go decision

1. Use Case Diagram – Banking System

This diagram identifies actors and their interactions with system features.

🧩 Actors:

 Customer

 Bank Employee

 Admin

 Payment Gateway

✅ Use Cases:

 Login

 View Account Balance

 Transfer Funds

 Pay Bills

 View Transactions

 Reset Password

 Approve Loans (Bank Employee)

pgsql

CopyEdit

+-------------------+

| Banking System |

+-------------------+

Customer Bank Employee

| |

| |

+-----+-----+ +-----+--------+

| Login | | Approve Loan |

| View Balance |

| Transfer Funds |
 | View Transactions|

| Pay Bills |

+-------------------+

🔷 2. Activity Diagram – Fund Transfer Flow

Shows the step-by-step process of transferring funds.

pgsql

CopyEdit

Start

[Login to Account]

[Select 'Transfer Funds']

[Enter Beneficiary Details]

[Enter Amount & Remarks]

[Submit Transfer]

[Validate Balance Availability]

├── No → [Show Error] → End

↓ Yes

[Trigger Payment Gateway]

[Transaction Confirmation]

[Send SMS/Email Notification]

End
🔷 3. Sequence Diagram – Login Process

Describes the interaction between user and system components.

pgsql

CopyEdit

Customer → Login Page: Enter credentials

Login Page → Auth Service: Authenticate

Auth Service → DB: Get User Info

DB → Auth Service: Return data

Auth Service → Login Page: Result

Login Page → Customer: Show Dashboard / Error

🔷 4. Class Diagram – Banking System (Domain Model)

Defines entities and their relationships.

pgsql

CopyEdit

+-------------------+ +-------------------+ +-------------------+

| Customer |<>----| Account |<|----| Transaction |

+-------------------+ +-------------------+ +-------------------+

| customerId | | accountNumber | | transactionId |

| name | | balance | | date |

| email | | accountType | | amount |

+-------------------+ | customerId (FK) | | transactionType |

+-------------------+ | accountNumber(FK) |

+-------------------+

🔷 5. State Machine Diagram – Bank Account Lifecycle

Describes how an account changes state based on events.

pgsql

CopyEdit

[New Account Created]

↓
 Active

/ \

[Freeze] [Close]

↓ ↓

Frozen Closed

🔷 6. Component Diagram – High-Level Banking System Architecture

(Usually done with Dev help, but BAs can help define modules)

pgsql

CopyEdit

+------------------+

| Web Interface |

+--------+---------+

+--------v---------+

| Application API |

+--------+---------+

+--------v---------+

| Authentication |

| Account Services |

| Transaction Logic|

+--------+---------+

+--------v---------+

| Database |

+------------------+

🔷 Summary of UML Diagrams for BA in Banking Domain

UML Diagram What it Shows When to Use

Use Case Diagram User interactions with Requirement

UML Diagram What it Shows When to Use

system gathering

Business workflows Process

Activity Diagram
(e.g. fund transfer) mapping

Step-by-step Functional
Sequence Diagram
interaction flow clarification

Data structure / Domain

Class Diagram
entities modeling

Rule or state
State Diagram Lifecycle of key objects
management

System Technical
Component Diagram
components/modules collaboration

BRD-Business Require Documents

In software development, a Business
Requirements Document (BRD) is a key
deliverable prepared by a Business Analyst
(BA) to define what the business needs from a
software solution. It forms the foundation for
all subsequent documents like Functional
Requirement Specification (FRS) and technical
design.

🧾 Key Sections of a BRD (Business

Requirements Document)
Here’s a breakdown of standard BRD sections
with descriptions:

✅ 1. Document Control
 Version history
 Author(s)
UML Diagram What it Shows When to Use

 Approval details
 Date of creation and updates

✅ 2. Executive Summary
 High-level overview of the project
 Business goals and objectives
 Problem statement

✅ 3. Business Objectives / Goals

 Clear and measurable objectives (e.g.,
reduce transaction time by 30%)
 Aligns with organizational strategy

✅ 4. Scope of the Project

 In-Scope: Features, departments,
platforms covered
 Out-of-Scope: Excluded items to avoid
scope creep

✅ 5. Background / Current State Analysis

 Overview of existing processes or
systems
 Pain points, inefficiencies, or limitations

✅ 6. Business Requirements
 High-level requirements from
stakeholders
 Written in business language, not
UML Diagram What it Shows When to Use

technical (e.g., “The system shall allow

users to view transaction history for the
past 12 months.”)

✅ 7. Stakeholder List
 Who is impacted or involved
 Their roles and responsibilities

✅ 8. Assumptions and Constraints

 Example assumptions: "Users will have
access to the internet"
 Example constraints: budget, technology
stack, timeline

✅ 9. Business Process Flows / Diagrams

 Use UML or BPMN to show workflows,
user actions, and system interactions
 Often includes “As-Is” and “To-Be”
process models

✅ 10. Data Requirements (optional)

 Business data inputs/outputs
 Reporting or data storage needs

✅ 11. Success Criteria / KPIs

 How success will be measured
 E.g., “90% of users complete registration
within 5 minutes”
UML Diagram What it Shows When to Use

✅ 12. Risks and Mitigation

 Potential project risks (e.g., stakeholder
unavailability)
 Suggested mitigation strategies

✅ 13. Appendices
 Supporting documents
 Glossary of terms
 References (RFP, emails, policies, etc.)

✅ 14. Sign-Off
 Section for stakeholder approvals
 Indicates formal acceptance of
requirements

🧩 Optional: BRD Template Table of Contents

markdown
CopyEdit
1. Document Control
2. Executive Summary
3. Business Goals & Objectives
4. Project Scope
5. Current Business Process
6. Business Requirements
7. Stakeholders
UML Diagram What it Shows When to Use

8. Assumptions and Constraints

9. Business Process Models
10. Data Requirements
11. Success Metrics / KPIs
12. Risks and Dependencies
13. Appendices
14. Sign-Off

FRD
In software development, the Functional Requirements
Document (FRD)—also called Functional Specification
Document (FSD)—is used to define how the system should
behave to meet the business requirements outlined in the
BRD.

It is often written by a Business Analyst (BA) in collaboration

with technical and QA teams.

🧾 What is an FRD?

An FRD translates business needs (the "what") into detailed

system functionality (the "how").
It defines features, inputs, outputs, and behaviors of the
system from a user's and system’s perspective.

🔷 Key Objectives of an FRD

 Describe all functional behavior expected from the

system

 Serve as a foundation for design, development, and

testing

 Enable traceability from business requirements to

functional solutions

📚 Common Sections of an FRD

UML Diagram What it Shows When to Use

Section Description

Version history, authors, approval,

✅ 1. Document Control
date

Purpose, audience, project

✅ 2. Introduction
overview

What functionalities are

✅ 3. Scope
included/excluded

Linked documents: BRD, SRS,

✅ 4. References
regulations

✅ 5. Assumptions and External systems, APIs, teams

Dependencies involved

✅ 6. Functional Detailed functions the system

Requirements must perform

✅ 7. Use Cases / User Step-by-step flows for specific

Stories actions

✅ 8. Wireframes / UI Visuals for expected user screens

Mockups or layouts

Data inputs, outputs, validation,

✅ 9. Data Requirements
storage rules

Logic and constraints (e.g., “age

✅ 10. Business Rules
must be ≥ 18”)

How the system should behave on

✅ 11. Error Handling
failure

✅ 12. Non-functional (May link to NFR document:

References performance, security)

When will a function be

✅ 13. Acceptance Criteria
considered complete

✅ 14. Traceability Matrix Mapping of BRD → FRD → Test

(Optional) cases

✅ 15. Sign-off Approvals from stakeholders

🧩 Example Functional Requirement (Banking Domain)

Requirement ID: FR-003

Title: Fund Transfer – Within Bank
UML Diagram What it Shows When to Use

Description: The system shall allow users to transfer funds

between their own accounts or to other accounts within the
same bank.
Preconditions: User is logged in and authenticated
Inputs: Source account, destination account, amount,
remarks
Outputs: Transaction confirmation, updated account
balances
Business Rules: Transfer amount must not exceed available
balance
Error Handling: If balance is insufficient, display error
message

🔄 BRD vs FRD – Quick Comparison

BRD (Business Requirement) FRD (Functional Requirement)

What the business wants How the system will deliver it

High-level goals Detailed system behavior

Written for stakeholders Written for developers & QA

📄 FRD Table of Contents (Template View)

markdown

CopyEdit

1. Document Control

2. Introduction

3. Project Scope

4. References

5. Assumptions and Dependencies

6. Functional Requirements

- 6.1 Requirement 1

- 6.2 Requirement 2

7. Use Case Scenarios

8. Wireframes / UI Designs

9. Data Requirements
UML Diagram What it Shows When to Use

10. Business Rules

11. Error Handling

12. Non-functional Considerations (linked or listed)

13. Acceptance Criteria

14. Traceability Matrix

15. Sign-Off

INVEST
What is INVEST?
INVEST stands for:
Letter Meaning Description
The story can be delivered and tested on its
I Independent
own without relying on others.
The story is a placeholder for a conversation,
N Negotiable
not a fixed contract.
V Valuable It delivers clear value to the user or business.
E Estimable The team can estimate the effort involved.
The story is small enough to complete in a
S Small
single sprint.
The story includes clear acceptance criteria to
T Testable
verify it works.

✅ Example: INVEST-Friendly User Story (Banking App

Error in message stream
Retry
You said:
yes
ChatGPT said:
Great! Let’s apply the INVEST model to a Banking App and show
how a high-quality user story looks in software development.

✅ Example User Story (Banking App – Fund Transfer)

🔸 User Story:
As a registered customer, I want to transfer money between my
own accounts, so that I can manage my funds efficiently without
visiting the bank.

🧪 Apply the INVEST Criteria:

INVEST Explanation
I- This story can be developed and tested without
Independent needing the bill payment or login functionality.
N- The transfer method (e.g., NEFT, IMPS) or UX details
Negotiable can be discussed further with the Product Owner.
Users can manage money between accounts—this
V - Valuable
reduces their need for branch visits.
The development team can estimate the story based
E - Estimable
on similar API integrations.
Limited to internal transfers only; can be done in 1
S - Small
sprint.
Acceptance criteria allow for functional testing and
T - Testable
UAT.
✅ Acceptance Criteria (Testable)
1. ✅ User must be logged in.
2. ✅ User can select source and destination accounts.
3. ✅ Amount must be validated against available balance.
4. ✅ Transfer confirmation should be shown after success.
5. ✅ An SMS and email confirmation should be sent.

🧾 Another Example – View Transaction History

As a customer, I want to view my past 6 months of transactions, so
that I can track my spending and detect any unauthorized activity.
Acceptance Criteria:
 ✅ System should show date, amount, and description for each
transaction.
 ✅ User can filter by date and transaction type.
 ✅ Only transactions from logged-in user’s account should be
shown.
 ✅ Pagination for long lists (e.g., 10 per page).

🔄 Summary: INVEST User Stories Help You

✅ Focus on delivering value
✅ Keep scope small and manageable
✅ Enable fast development and testing
✅ Avoid dependencies and ambiguity
Here are all major requirement prioritization techniques used in
software development, especially by Business Analysts, Product
Owners, and Project Managers:

🔹 1. MoSCoW Method
 Must have
 Should have
 Could have
 Won’t have (this time)
✅ Use when: Stakeholders are involved, and there's a need for
simple categorization.

🔹 2. Kano Model
 Categorizes features based on customer satisfaction:
o Basic needs (must-haves)
o Performance needs (more = better)
o Excitement needs (delight features)
✅ Use when: User satisfaction and innovation are key.

🔹 3. Value vs. Effort Matrix (or Value vs. Complexity)

 Features plotted on a 2x2 matrix:
o High Value, Low Effort (Quick Wins)
o High Value, High Effort
o Low Value, Low Effort
o Low Value, High Effort (Avoid)
✅ Use when: Teams want visual and quantitative decision-making.

🔹 4. 100 Dollar Test (Cumulative Voting)

 Stakeholders distribute 100 "dollars" (or points) across
requirements.
✅ Use when: Need group consensus or democratic prioritization.

🔹 5. RICE Scoring
 Reach × Impact × Confidence ÷ Effort
Score = (Reach × Impact × Confidence) / Effort
✅ Use when: Prioritizing product features with business metrics.

🔹 6. WSJF (Weighted Shortest Job First)

 Used in SAFe Agile
WSJF = Cost of Delay / Job Duration
✅ Use when: Working in scaled agile environments.

🔹 7. Bubble Sort / Pairwise Comparison

 Compare each requirement with every other one in pairs.
✅ Use when: You have limited items and need precise ranking.

🔹 8. Opportunity Scoring
 Based on how poorly a need is met and how important it is.
✅ Use when: Focusing on gaps in current product offerings.

🔹 9. Eisenhower Matrix
  Prioritizes by:
o Urgent & Important
o Important, Not Urgent
o Urgent, Not Important
o Neither
✅ Use when: Time management is crucial for features or tasks.

🔹 10. Buy a Feature

 Stakeholders are given budgets to "buy" the features they
value most.
✅ Use when: You want to simulate trade-offs and budgeting.

🔹 11. Ranking / Scoring Models

 Assign weights or scores to requirements based on:
o Business value
o Risk
o Cost
o Strategic alignment, etc.
✅ Use when: You need a quantitative and data-driven approach.

🔹 12. Priority Groups / Bucketing

 Divide into High, Medium, Low groups.
✅ Use when: Quick, broad prioritization is needed.
Definition of Ready (DoR)
Definition of Ready (DoR) is a set of criteria that a user story or
backlog item must meet before it can be pulled into a sprint or
iteration for development. It ensures the team clearly understands
the scope, goals, and requirements of a task before they start
working on it.

📌 Why Definition of Ready is Important

 Ensures clarity and completeness of requirements
 Reduces rework due to misunderstood or incomplete stories
 Aligns the development team, product owner, and
stakeholders
 Improves planning accuracy

🧩 Typical Criteria in Definition of Ready

✅ Criteria 💡 Description
The story follows a consistent format
Clearly defined user story
(e.g., “As a user, I want…”)
Testable conditions that must be met
Acceptance criteria are
for the story to be considered
defined
complete
✅ Criteria 💡 Description
Any blockers, external systems, or
Dependencies are identified
teams are known and addressed
The story has been story-pointed or
Estimates are available
sized
All team members have a shared
Team understands the story
understanding of the scope
UI/UX or designs are ready (if Wireframes, mockups, or visual
needed) designs are available if required
Stakeholders understand how it
Business value is clear
impacts users or business
Performance and non-
functional requirements If relevant (e.g., load time, security)
considered

🧠 Example of DoR for a Scrum Team

A user story is considered "Ready" when:
 It is independent, negotiable, valuable, estimable, small, and
testable (INVEST)
 It has clear acceptance criteria
 Any external dependencies are resolved
 The team has reviewed and understood it during backlog
grooming

Would you like a Definition of Ready vs Definition of Done

comparison as well?
You said:
yes
ChatGPT said:
Here’s a clear comparison between Definition of Ready (DoR) and
Definition of Done (DoD):

🔄 Definition of Ready vs Definition of Done

Aspect Definition of Ready (DoR) Definition of Done (DoD)
Ensures a story is
Ensures a story is ready to be
🔍 Purpose complete and meets
worked on
quality standards
Before development starts After development, to
⏳ When it's
(during backlog confirm the item is
used
refinement/planning) completed
Quality, completeness,
Clarity, preparedness, and
📋 Focus and compliance with
shared understanding
acceptance criteria
- Code completed
- Peer reviewed
- User story is clearly written
- Tested (unit + QA)
- Acceptance criteria defined
🧩 Common - Meets acceptance
- Estimated
Criteria criteria
- No blockers or dependencies
- Deployed to staging
- UI/UX ready (if needed)
- Documentation
updated
👥 Who uses Product Owner, Business Development Team, QA,
it Analyst, Development Team Product Owner
✅ Outcome Team agrees to start working Team agrees the item is
on the item done and potentially
Aspect Definition of Ready (DoR) Definition of Done (DoD)
shippable

📌 Summary
 DoR = Entry criteria
 DoD = Exit criteria
✅ A user story that meets the Definition of Ready can be pulled into
a sprint
✅ A user story that meets the Definition of Done can be released to
production (or demoed in Sprint Review)