Video summary

32 Basic Business Analyst Interview Questions : Key Concepts and Best Responses

Main summary

Key takeaways

Educational

Main Ideas / Lessons Conveyed

  • The video prepares candidates for Business Analyst (BA) interviews by giving short, complete conceptual and situational answers to common question types.
  • It emphasizes that superficial answers usually fail; strong answers come from preparation and adding relevant completeness (examples, impacts, purposes).
  • The questions cover a broad BA skill set, including requirements, modeling, traceability, stakeholder management, prioritization, agile practices, testing, and change management.

Methodologies, Acronyms, and “How to Answer” Items

1) Core BA Conceptual Terms (and Key Points to Include in Answers)

Process Design

  • Meaning: Designing/redesigning business processes.
  • Common reasons:
    • streamline work
    • improve quality/efficiency
    • reduce cost
    • improve customer satisfaction

Feasibility Study

  • Meaning: Assessing a proposed project’s viability across technical, economic, operational (and related) fronts.
  • Purpose: Help stakeholders decide whether the project is worth pursuing.

UML Modeling (Unified Modeling Language)

  • Meaning: Use UML diagrams to represent business system facets.
  • Diagram examples:
    • use case
    • class
    • sequence
    • activity
    • state machine
    • deployment
  • Benefit: Helps analyze/document/communicate complex concepts and relationships.

BRD (Business Requirements Document)

  • Meaning: Formal document capturing business requirements.
  • Includes:
    • objectives and scope
    • functional + non-functional requirements
    • business rules
    • roles/responsibilities
    • use cases
    • dependencies
    • assumptions/limitations
    • glossary
  • Purpose: Align understanding among stakeholders, BA, and the development team.

FRD (Functional Requirements Document)

  • Meaning: Bridge between business requirements and technical specifications.
  • Includes:
    • introduction/scope
    • functional requirements
    • UI design
    • data requirements
    • system interfaces
    • error handling/reporting
    • performance and security
    • testing & acceptance criteria
  • Purpose: Reference for development, system testing, acceptance, and stakeholder agreement.

INVEST (User Story Quality Checklist)

  • I: independent and negotiable
  • V: valuable is estimable
  • S: small
  • T: testable

User stories should be written to meet INVEST attributes.

RFI / RFQ / RFP / ROI

  • RFI: request for information
  • RFQ: request for quotation
  • RFP: request for proposal
  • ROI: return on investment

BPMN

  • Stands for: Business Process Model and Notation.
  • Purpose: Diagram business processes using standard shapes/symbols; clarifies “who does what” and next steps.

CRUD

  • C: create
  • R: read
  • U: update
  • D: delete

COTS

  • Commercial Off-The-Shelf products: Ready-made software/hardware.
  • BA tasks: Assess fit with existing company processes/products.
  • Benefits:
    • cost effectiveness
    • reduced development time
    • access to special features
    • vendor support
  • Example mentioned: “SAPiRP” (as a COTS example in the subtitles)

WBS (Work Breakdown Structure)

  • Meaning: Breaks a project into smaller manageable tasks.
  • Benefits:
    • clarity
    • easier planning/management
    • better resource allocation
    • easier tracking/monitoring

JAD (Joint Application Development)

  • Meaning: Time-boxed meetings/workshops where BA, stakeholders, and SMEs gather requirements (often with a facilitator).
  • Benefits:
    • understand perspectives
    • gather and validate requirements
    • resolve conflicts on the spot

SIPOC

  • S: suppliers
  • I: inputs
  • P: process
  • O: outputs
  • C: customers

RACI / RACi Matrix (Responsibility Assignment Matrix)

  • R: Responsible (does the work)
  • A: Accountable (delegates/reviews; result ownership)
  • C: Consulted (provides input)
  • I: Informed (kept in the loop)

Clarification guidance:

  • If asked to differentiate R vs A:
    • Responsibility is task-oriented.
    • Accountability is result-oriented and usually involves approval/reporting.
  • Responsibility can be shared across many; accountability is typically only one person.

RTM (Requirement Traceability Matrix)

  • Purpose:
    • Ensure every requirement’s source is traced throughout the SDLC/PLC.
    • Ensure requirements are verifiable/validatable/testable.
    • Confirm all requirements are addressed and changes are managed.

Stakeholder Metrics / Stakeholder Mapping

  • Meaning: Maps stakeholders by impact and influence to guide prioritization and engagement.
  • Used to:
    • identify key stakeholders
    • prioritize engagement effort
    • tailor communication
    • design engagement strategies
    • improve decision-making

Identifying Stakeholders (Approach)

  • Workshops/interactions with project team/SMEs
  • Analyze documents (organizational charts, project charters)
  • Use existing databases
  • External research for impacted external bodies
  • Use stakeholder maps to validate the list

Risk warning: Missing key stakeholders can cause:

  • incomplete requirements
  • lack of support/resistance
  • misalignment with business goals
  • increased risks
  • reputation damage

Managing Challenging Stakeholders

  • Types described: negative bias and unavailability (mapped to the “high influence/high impact” quadrant)
  • Steps:
    1. Identify them
    2. Determine why they’re negative (personality conflict, fear of change, power conflict, lack of alignment)
    3. Address concerns
    4. Leverage positive stakeholders’ influence to move the project forward
    5. If unavailable: request a junior representative to attend and report, or send reports

Business vs Functional vs Non-Functional Requirements

  • Business requirements: High-level business needs (e.g., improve efficiency, customer interaction, compliance).
  • Functional requirements: What the system should do (technical features/functions).
  • Non-functional requirements: How well the system performs (e.g., reliability, response time, scalability, usability).

Requirement Elicitation Techniques

  • Examples:
    • interviews
    • workshops
    • document analysis
    • surveys/questionnaires
    • observations
    • prototyping
    • use cases
    • brainstorming
    • focus groups
    • storyboarding
    • user stories
    • JAD
    • contextual inquiry
    • data gathering
  • Choice depends on:
    • project complexity/goals
    • stakeholder availability & preferences
    • timeline/resources
    • desired depth of understanding

Requirement Prioritization Techniques

  • Examples:
    • MoSCoW
    • ranking
    • Kano model
    • user story mapping
    • cost of delay
    • value vs complexity
    • importance vs urgency
    • analytic hierarchy process

Why prioritization matters:

  • choose the right product
  • plan efforts/resources
  • improve productivity
  • reduce operational cost
  • increase ROI
  • manage time and improve chances of on-time delivery within budget

Importance vs Urgency Matrix

  • Quadrants:
    • High importance + high urgency (highest priority)
    • High importance + low urgency (critical; schedule for later)
    • Low importance + high urgency (requires careful evaluation; may waste time/resources)
    • Low importance + low urgency (defer/eliminate)

MoSCoW Method

  • M: Must have (mandatory/critical; without it project fails)
  • S: Should have (important; increases value; scope/time can stretch)
  • C: Could have (nice-to-have; may skip)
  • W: Won’t have (explicitly not targeting; improves focus and delivery)

Kano Model

  • Categorizes requirements by satisfaction:
    • Basic/Expected: presence doesn’t satisfy; absence dissatisfies heavily
    • Performance/Satisfiers: increases satisfaction as fulfilled
    • Exciters/Delighters: unexpected features beyond expectations; provide competitive edge

Documents and Tools for Requirements

  • Documents: BRD, FRD, use cases, user stories, RTM, SRS, etc.
  • Tools: Microsoft Word/Excel, Visio-like tools, Jira, SharePoint, Lucidchart, Enterprise Architect, etc.

Visual Models for Requirements (Examples)

  • use case diagrams, activity diagrams, class diagrams
  • data flow diagrams (DFDs), wireframes, mockups
  • BPMN, sequence diagrams, state diagrams
  • entity relationship diagrams, decision trees
  • UI flow diagrams, storyboards

Business Analysis vs Business Analytics (Difference)

  • Business analysis:
    • focus: understanding business needs for an effective solution
    • activities: requirement gathering/elicitation/prioritization, solution definition, stakeholder communication
  • Business analytics:
    • focus: analyzing data patterns/trends to support decision-making
    • activities: data collection/cleaning, analysis, visualization, modeling

Agile Events (Scrum)

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective

Purpose: time-bound collaboration/inspect/adapt/communicate.

Velocity (Agile)

  • Measures how much work a team completes in a time frame.
  • Used for planning future sprints and forecasting timelines.
  • Important: don’t compare velocity across teams (team composition/complexity differs).

Sprint Burndown Chart

  • Shows work remaining over time within a sprint.
  • Helps monitor scope creep and stay on schedule by comparing planned vs actual progress.

Observation Techniques (for Requirements Discovery)

  • Shadowing, work sampling, direct observation, video recording
  • Focus groups, participatory observations
  • Document analysis, task analysis, field studies
  • Remote observation

Ethical considerations:

  • don’t disturb workflow
  • respect privacy/confidentiality

Types of Gaps During Analysis

  • Process gaps
  • Functional gaps
  • Data gaps
  • Knowledge gaps
  • Skills gaps
  • Stakeholder gaps
  • Performance gaps
  • Compliance gaps

Methods to identify gaps:

  • process mapping
  • root cause/sort analysis
  • benchmarking
  • customer feedback
  • gap analysis
  • metrics and performance matrix analysis
  • capability assessment
  • risk analysis
  • stakeholder analysis
  • technology analysis

SDLC Stages (Expected BA Knowledge)

  • Requirements gathering → system design → implementation/coding → testing → deployment → maintenance → retirement/phase out.

2) BA Role During Testing Phases

During SIT (System Integration Testing)

  • Help with test planning (inputs on strategy/objectives/coverage)
  • Review test cases
  • Validate test results vs expected outcomes
  • Analyze/manage defects (prioritize based on root cause and business impact)

During UAT (User Acceptance Testing)

  • Identify suitable users
  • Define test scenarios
  • Analyze/validate results before passing defects to dev
  • Ensure requirements map to test cases
  • Document/report for corrections and support stakeholder sign-off

3) Handling Continuously Changing Requirements (Change Management Approach)

  • Many projects fail due to uncontrolled changing requirements and weak processes.
  • Suggested BA approach:
    • Treat yourself as the “chain” holding the project and organization together.
    • Ensure change requests come through the right channel.
    • Don’t automatically document—confirm whether the change is truly mandatory vs “good to have.”
    • Request proper documentation, then explain timeline and budget repercussions.
    • If mandatory: follow complete requirement classification and change process.

Speakers / Sources Featured

  • No named speakers are mentioned in the subtitles.
  • Source/format: a YouTube video presented by an unnamed narrator/host (speaking directly to the audience).

Original video