Business Analyst interview questions

BRD (Business Requirements Document) and FRD (Functional Requirements Document) serve different purposes in the SDLC. BRD: - Captures WHAT the business needs and WHY - Written from a business/stakeholder perspective - Contains business objectives, scope, assumptions, constraints - Audience: business stakeholders, project sponsors, senior management - Created early in the project during requirements elicitation FRD: - Captures HOW the system will fulfill the business requirements - Written from a functional/system perspective - Contains detailed functional specs, use cases, data flows, UI wireframes - Audience: developers, QA, architects, technical teams - Created after the BRD is approved Simple analogy: BRD = "We need a car that seats 7 people and gets 30 MPG." FRD = "The vehicle shall have 3 rows, a 2.5L hybrid engine, automatic transmission..." In Agile environments, these are often replaced by Product Backlog + User Stories, but the distinction between business-level and functional-level requirements still matters.

Requirements elicitation is the process of gathering, discovering, and extracting requirements from stakeholders and other sources. Common techniques: 1. Interviews (most common) - One-on-one sessions with stakeholders - Structured (predefined questions) or unstructured (open-ended) - Best for: senior stakeholders, sensitive topics 2. Workshops / JAD Sessions (Joint Application Development) - Bring multiple stakeholders together simultaneously - Resolve conflicts and gain consensus in real time - Best for: cross-functional requirements, reducing elapsed time 3. Surveys/Questionnaires - Large number of stakeholders, geographically distributed - Quantitative data collection - Best for: validating priorities, gathering broad input 4. Observation / Job Shadowing - Watch users perform their actual work - Uncovers implicit/unstated requirements - Best for: understanding as-is process 5. Document Analysis - Review existing systems, reports, SOPs, legacy docs - Understand current state without stakeholder time - Best for: greenfield replacements, compliance requirements 6. Prototyping / Mockups - Show stakeholders something tangible early - Surfaces hidden requirements quickly - Best for: UI-heavy systems 7. Brainstorming - Group ideation to explore possibilities - Best for: innovation projects, early-stage discovery Process flow: Plan → Elicit → Document → Validate → Manage changes

A use case describes how an actor (user or external system) interacts with the system to achieve a specific goal. Components of a well-written use case: 1. Use Case Name: verb + noun (e.g., "Place Order", "Reset Password") 2. Actor: who initiates the interaction (Primary actor = the one who benefits) 3. Preconditions: what must be true before the use case starts 4. Postconditions: what state the system is in after success 5. Main Success Scenario: step-by-step happy path 6. Alternative Flows: what happens when something deviates 7. Exception Flows: error conditions Example — "User Login": - Actor: Registered User - Precondition: User has an account; is on the login page - Postcondition: User is authenticated and sees their dashboard - Main flow: 1. User enters email and password 2. System validates credentials 3. System creates a session 4. System redirects to dashboard - Alternative: Step 2 fails — system shows error, allows 3 retries - Exception: Account locked after 5 failed attempts Tips: - Write from the actor's perspective, not the system's internals - Each step should be an observable interaction - Keep main flow clean; push exceptions to alternate flows - Use active voice: "System validates..." not "Validation is performed..."

Functional requirements define WHAT the system must do — the specific behaviors, functions, and features. Non-functional requirements (NFRs) define HOW WELL the system must do it — quality attributes and constraints. Functional examples: - "The system shall allow users to reset their password via email" - "The system shall generate a monthly invoice in PDF format" - "Users shall be able to filter products by category, price, and rating" Non-functional examples: - Performance: "The login page shall load within 2 seconds for 95% of requests" - Scalability: "The system shall support 10,000 concurrent users" - Availability: "The system shall have 99.9% uptime (SLA)" - Security: "All passwords shall be stored using bcrypt with minimum cost factor 12" - Usability: "New users shall complete onboarding in under 5 minutes" - Compliance: "The system shall comply with GDPR data retention policies" Why NFRs matter: A system can meet all functional requirements and still fail if it's too slow, unavailable, insecure, or hard to use. NFRs often become the hardest constraints to retrofit — they must be considered in architecture from day one. BA's role: Document both, ensure NFRs are specific and measurable (avoid "the system shall be fast"), and get stakeholder sign-off on both.

A user story captures a requirement from the end-user's perspective in plain language. Standard format: "As a [type of user], I want [some goal] so that [some reason/benefit]." Example: "As a registered customer, I want to save items to a wishlist so that I can purchase them later without searching again." INVEST criteria (Ron Jeffries) — what makes a good user story: I — Independent: Can be developed/delivered independently, not tightly coupled to another story N — Negotiable: Not a fixed contract; details are open for discussion between team and PO V — Valuable: Delivers value to the user or business (not just a technical task) E — Estimable: Team can estimate size/effort; if not, it needs more analysis S — Small: Fits within one sprint; if too large, split it T — Testable: Clear acceptance criteria exist to verify when it's done Acceptance criteria — written in Given/When/Then (Gherkin) format: - Given the user is on the product page - When they click "Add to Wishlist" - Then the item appears in their Wishlist tab with a confirmation toast Bad user story: "As an admin, I want to manage users." (too vague, too large, not testable) Good split: "As an admin, I want to deactivate a user account so that they can no longer log in."

A process flow diagram (also called a flowchart or business process flow) visually maps the sequence of steps, decisions, and actors involved in a business process. When to use one: - Documenting as-is (current) processes to understand how work flows today - Designing to-be (future) processes after improvement/automation - Identifying bottlenecks, redundancies, and handoff points - Communicating process to stakeholders who prefer visuals over text - Onboarding new team members Key elements: - Start/End: Oval or rounded rectangle - Process step: Rectangle (an action that happens) - Decision: Diamond (yes/no or multiple outcomes) - Arrows: Show flow direction - Swimlanes: Horizontal or vertical lanes showing which actor/department performs each step Types: 1. Basic flowchart — sequence of steps without actors 2. Swimlane (cross-functional) diagram — shows who does what across departments 3. BPMN (Business Process Model and Notation) — industry standard notation for complex processes 4. Value stream map — Lean/Six Sigma; focuses on value-add vs. waste Example use: An order-to-cash process mapped with swimlanes across Sales, Finance, and Warehouse departments to identify where orders are getting stuck. Tools: Lucidchart, Visio, draw.io, Miro, JIRA (via integrations)

Stakeholder management is the process of identifying, analyzing, and strategically engaging all parties who have an interest in or are affected by a project. Steps: 1. Identify stakeholders — everyone impacted: users, sponsors, IT, legal, compliance, vendors 2. Analyze stakeholders — understand their interests, influence, and attitude (supportive/resistant) 3. Prioritize — use a framework to decide how much engagement each needs 4. Plan engagement — tailor communication strategy per stakeholder 5. Monitor and adapt — stakeholder dynamics change; revisit regularly Power/Interest Matrix (most common framework): - High Power, High Interest → Manage Closely (key decision makers; involve frequently) - High Power, Low Interest → Keep Satisfied (executives; send regular high-level updates) - Low Power, High Interest → Keep Informed (end users; share status, gather feedback) - Low Power, Low Interest → Monitor (minimal effort; inform if needed) RACI model (for roles): - Responsible: does the work - Accountable: owns the outcome - Consulted: provides input - Informed: kept in the loop Common mistakes: - Engaging too late (after decisions are made) - Treating all stakeholders the same - Not identifying hidden/informal influencers BA tip: Document a Stakeholder Register with name, role, interest, influence, communication preference, and engagement strategy.

Gap analysis compares the current state ("as-is") with the desired future state ("to-be") to identify what needs to change. Steps: 1. Define the desired state - What does success look like? (business goals, KPIs, regulatory requirements) 2. Document the current state - How does the process/system/capability work today? - Gather data: interviews, process flows, system audits, performance metrics 3. Identify the gaps - Where are the differences between as-is and to-be? - Categorize: process gaps, technology gaps, skill gaps, data gaps 4. Analyze root causes - Why do these gaps exist? (resource constraints, outdated tech, lack of training) 5. Recommend solutions - What changes, investments, or initiatives close each gap? - Prioritize by impact vs. effort Output: Gap Analysis Report with table of gaps, root causes, recommended actions, and owners. Example: A company wants to reduce order processing time from 48 hours to 4 hours. As-is analysis shows 80% of time is manual data entry between systems. The gap is lack of integration. To-be: automated API integration between order and warehouse systems. Used in: process improvement, ERP implementations, compliance assessments, digital transformation, M&A due diligence.

MoSCoW is a prioritization framework used to help stakeholders and teams agree on what features/requirements to include in a release or sprint. M — Must Have: Non-negotiable. Project fails without these. Launch blockers. S — Should Have: High-value but not critical for launch. Include if time allows. C — Could Have: Nice-to-have. Only if capacity remains after Must and Should. W — Won't Have (this time): Explicitly out of scope for this iteration. May be revisited later. How to use it: 1. List all requirements 2. Facilitate a workshop with stakeholders to categorize each requirement 3. Challenge "Must Have" items — teams tend to overload this category 4. Aim for: ~60% Must, ~20% Should, ~20% Could, and a clear Won't list 5. Document and get sign-off; use it to manage scope creep When to use: - Sprint/release planning in Agile - MVP scoping - When time or budget is constrained and you need trade-off conversations - Managing stakeholder expectations about what will be delivered Pitfall: If everything is a "Must Have," the framework loses its value. A BA's job is to push back and help stakeholders make real trade-offs. Example: For an e-commerce launch — Must: product listing, cart, checkout, payment. Should: wishlist, order tracking. Could: product reviews. Won't (v1): loyalty points, gift cards.

Conflicting requirements are one of the most common and challenging situations a BA faces. Here's a structured approach: 1. Understand the conflict first - Talk to each stakeholder separately to understand their perspective and underlying needs - Often the stated requirement differs from the actual business need 2. Find the root cause - Is it a resource conflict (both needs are valid but can't both be funded)? - Is it a misunderstanding (stakeholders want the same thing but expressed it differently)? - Is it a genuine business conflict (different departments have opposing goals)? 3. Facilitate a resolution session - Bring conflicting stakeholders together in a structured workshop - Present both requirements neutrally — avoid taking sides - Use objective criteria: alignment to business goals, ROI, regulatory need, user impact 4. Use prioritization frameworks - MoSCoW, weighted scoring, or value vs. effort matrix to make trade-offs visible - Ask: "If we can only do one this quarter, which delivers more value?" 5. Escalate when needed - If stakeholders cannot agree, escalate to the project sponsor or steering committee - Present the decision clearly: "If we go with Option A, we gain X but give up Y" 6. Document the decision - Record what was decided, who decided it, and the rationale - This prevents revisiting resolved conflicts and provides an audit trail Key BA skill: Stay neutral. Your job is to facilitate alignment, not advocate for one stakeholder's position.

An Entity Relationship Diagram (ERD) visually represents the data entities in a system, their attributes, and how they relate to each other. Key components: - Entity: A real-world object or concept (e.g., Customer, Order, Product) - Attribute: A property of an entity (e.g., Customer has Name, Email, Phone) - Relationship: How entities are connected (e.g., Customer PLACES Order) - Cardinality: How many of one entity relates to another Cardinality notations: - One-to-One (1:1): One employee has one company laptop - One-to-Many (1:N): One customer can place many orders - Many-to-Many (M:N): Many students enroll in many courses (needs a junction table) Why BAs need to understand ERDs: 1. Data requirements: helps document what data the system must store and manage 2. Spot inconsistencies: if stakeholders describe conflicting data structures, the ERD makes it visible 3. Communicate with developers: shared language for data design 4. Validate requirements: ensures the data model can support the required business processes 5. Integration design: when integrating systems, ERDs help identify data mapping needs BA tip: You don't need to design ERDs from scratch, but you should be able to read one, spot gaps (missing entities, wrong cardinality), and ask the right questions ("What happens when a customer has multiple addresses?"). Tools: Lucidchart, draw.io, dbdiagram.io, ERDPlus

Agile is an iterative software development methodology that delivers working software in short cycles (sprints, typically 2 weeks), with continuous feedback and adaptation. Core Agile values (Agile Manifesto): - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan BA's role in Agile: In Agile, there's often no dedicated "BA" role — the responsibilities are split across Product Owner (PO) and the team. However, when a BA exists: 1. Requirements: Work with PO to refine the product backlog; write and clarify user stories 2. Refinement: Facilitate backlog grooming sessions; break epics into stories; add acceptance criteria 3. Sprint planning: Provide clarity on stories so developers can estimate and commit 4. Sprint execution: Answer developer questions, clarify requirements in real time 5. UAT: Facilitate user acceptance testing; verify stories meet acceptance criteria 6. Retrospectives: Participate in continuous improvement Key difference from Waterfall: - Waterfall: BA gathers ALL requirements upfront, produces heavy documentation - Agile: BA works continuously throughout the project, requirements emerge iteratively - "Just enough, just in time" documentation philosophy Collaboration touchpoints: - Daily standups: flag blockers related to requirements clarity - Sprint review: validate delivered features against acceptance criteria - PO: BA is often the bridge between business stakeholders and the PO