BA Fundamentals
1. What is business analysis and what does a business analyst do?
Business analysis is the practice of identifying business needs, problems, and opportunities, and recommending solutions that deliver value to stakeholders. A business analyst (BA) bridges the gap between business stakeholders and technical teams — they elicit and document requirements, model business processes, facilitate workshops, analyse data, manage stakeholder expectations, and ensure delivered solutions meet business objectives. BAs work across industries in roles ranging from IT project BAs to product analysts and data analysts.
2. What is the difference between a business requirement, functional requirement, and non-functional requirement?
A business requirement describes the high-level outcome or goal the organisation wants to achieve, without specifying how — for example, "Reduce customer onboarding time by 40%." A functional requirement describes what the system must do — a specific behaviour or feature — for example, "The system must allow users to upload identity documents in PDF or JPG format." A non-functional requirement (quality attribute) defines how the system performs — for example, "The document upload must complete within 3 seconds" (performance) or "The system must be available 99.9% of the time" (availability).
3. What is the SDLC and where does a BA fit in?
The SDLC (Software Development Life Cycle) is the structured process for planning, creating, testing, and deploying software systems. Common phases include Planning, Requirements Analysis, Design, Development, Testing, Deployment, and Maintenance. BAs are most active during Planning (defining scope and feasibility), Requirements Analysis (eliciting and documenting requirements), and Testing (verifying requirements are met through UAT). In Agile SDLCs, the BA role is continuous — working with the product owner, refining the backlog, and clarifying requirements throughout each sprint.
4. What are the key skills of a business analyst?
Core BA skills include analytical thinking and structured problem-solving, strong written and verbal communication for producing clear requirements documents and facilitating meetings, stakeholder management to balance competing priorities, data analysis using SQL, Excel, or BI tools to support decisions, domain knowledge of the relevant industry, process modelling (BPMN), UML diagramming, and knowledge of project methodologies (Waterfall, Agile). Soft skills — active listening, negotiation, facilitation, and adaptability — are equally critical and often differentiate effective BAs.
5. What is the difference between a BA and a project manager?
A Business Analyst focuses on the "what" — identifying business needs, defining requirements, and ensuring the solution is the right one for the business. A Project Manager focuses on the "how and when" — planning the project, managing resources, timelines, risks, and budget, and ensuring delivery happens on time and within scope. On large projects, both roles coexist and complement each other. On smaller projects, a single person may perform both roles. In Agile, the BA role often overlaps with the Product Owner or Product Analyst role.
6. What is a business case and what does it contain?
A business case is a documented justification for undertaking a project or initiative, presented to decision-makers to secure approval and funding. It typically includes an executive summary, problem statement or opportunity description, analysis of options (including doing nothing), recommended solution, cost-benefit analysis with ROI and payback period, risk assessment, assumptions and dependencies, success metrics, and implementation timeline. A strong business case quantifies both the costs and the tangible and intangible benefits of the proposed solution.
7. What is gap analysis?
Gap analysis identifies the difference between the current state ("as-is") of a business process, system, or capability and the desired future state ("to-be"). The "gap" represents what needs to change to achieve the desired outcome. Steps include documenting the current state through process mapping and data analysis, defining the target state based on business objectives, identifying gaps and their root causes, and recommending initiatives to close each gap. Gap analysis is used in process improvement, system migration planning, regulatory compliance assessments, and market entry analysis.
8. What is a SWOT analysis?
A SWOT analysis is a strategic framework that evaluates four dimensions: Strengths (internal advantages the organisation has), Weaknesses (internal limitations or areas for improvement), Opportunities (external factors the organisation could leverage), and Threats (external factors that could harm the organisation). BAs use SWOT to assess solution options, evaluate market positions, and justify strategic decisions. A SWOT is typically presented as a 2×2 matrix and should lead to actionable strategies: building on strengths, addressing weaknesses, seizing opportunities, and mitigating threats.
9. What is the difference between efficiency and effectiveness in a business context?
Efficiency means doing things right — achieving outputs with minimal waste of time, resources, and effort. Effectiveness means doing the right things — achieving the intended outcomes and strategic goals. A business process can be highly efficient (fast, low cost) but ineffective (producing the wrong output or not solving the actual problem). BAs must ensure both: that solutions are designed to achieve the correct business outcomes (effectiveness) and that they do so without unnecessary complexity or cost (efficiency). KPIs should measure both dimensions.
10. What is root cause analysis and what tools are used?
Root cause analysis (RCA) identifies the fundamental reason why a problem occurred — not just the symptoms — so that corrective actions address the actual cause. Common tools include the 5 Whys (repeatedly asking "why?" to drill down to the root), the Fishbone Diagram (Ishikawa/cause-and-effect diagram) that categorises potential causes under headings (People, Process, Technology, Environment, Materials), Fault Tree Analysis, Pareto Analysis (identifying the 20% of causes driving 80% of issues), and process flow analysis. RCA is used in quality improvement, incident management, and process redesign.
Requirements Engineering
11. What is requirements elicitation and what techniques are used?
Requirements elicitation is the process of gathering requirements from stakeholders through structured and unstructured means. Common techniques include interviews (one-on-one conversations with stakeholders), workshops (group sessions to gather consensus requirements), observation (watching users perform tasks to uncover implicit requirements), document analysis (reviewing existing policies, reports, and systems), surveys and questionnaires (gathering input from many stakeholders efficiently), prototyping (building mockups to clarify requirements through visual feedback), and brainstorming. The technique chosen depends on the stakeholder type, project phase, and nature of requirements.
12. What is a use case and how is it documented?
A use case describes how a user (actor) interacts with a system to achieve a specific goal. It captures the happy path (main success scenario) and extensions (alternative and exception flows). A use case document includes the use case name, ID, actor(s), preconditions, main flow (numbered steps of interaction), alternative flows, exception flows, postconditions, and business rules. Use cases are written in plain language for business stakeholders. They differ from user stories (which are shorter and Agile-focused) by including complete alternative and exception scenarios.
13. What is a user story and how is it written?
A user story is a brief, informal description of a feature from the perspective of a user, typically written as: "As a [type of user], I want [some goal] so that [some reason]." For example, "As a registered customer, I want to view my order history so that I can track past purchases." Good user stories follow the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable. Each story is accompanied by acceptance criteria that define the conditions a solution must meet to be accepted. Stories are the primary unit of work in Agile sprints.
14. What are acceptance criteria and why are they important?
Acceptance criteria are conditions that a solution must satisfy for a user story or requirement to be considered complete. They define the boundaries of the story, remove ambiguity, and provide the basis for testing. They are written in Given-When-Then (Gherkin) format: "Given [context], When [action], Then [outcome]" — for example, "Given the user is logged in, When they click 'Order History', Then a list of all past orders with dates and statuses is displayed." Clear acceptance criteria align developers, testers, and business stakeholders and prevent disputes about whether a story is done.
15. What is the MoSCoW prioritisation technique?
MoSCoW is a requirements prioritisation framework that categorises requirements into four groups: Must Have (essential requirements without which the solution is not viable and the project should not proceed), Should Have (important requirements that are not critical for the current release but should be included if possible), Could Have (desirable requirements that are lower priority and can be easily omitted), and Won't Have (requirements explicitly deferred to a future release or out of scope). It helps teams focus on delivering the highest-value requirements within constraints of time and budget.
16. What is a BRD vs. FRD?
A BRD (Business Requirements Document) captures high-level business needs, objectives, and the context for a project without specifying implementation details — it is written for business stakeholders and explains why a project is needed and what business problem it solves. An FRD (Functional Requirements Document) translates business requirements into specific system behaviours and capabilities — what the system must do — including data flows, business rules, and screen-level interactions. The FRD is written for technical teams and testers. In Agile, both are often replaced by a Product Backlog with user stories and acceptance criteria.
17. What is a data flow diagram (DFD)?
A DFD shows how data moves through a system — the sources of data, transformations applied to it, data stores, and destinations. A Level 0 DFD (Context Diagram) shows the entire system as a single process with external entities. A Level 1 DFD decomposes the system into major sub-processes. Deeper levels add more detail. DFDs use four symbols: processes (circles or rectangles), external entities (squares), data stores (open rectangles), and data flows (arrows). They are used to document system scope, identify data sources and destinations, and communicate system structure to both business and technical audiences.
18. What is requirements traceability?
A Requirements Traceability Matrix (RTM) links each requirement to its origin (business objective or stakeholder request), its design components, test cases, and delivered features. It ensures every requirement is addressed in the solution and every test case corresponds to a requirement. Forward traceability tracks requirements through to delivery; backward traceability maps delivered components back to requirements. The RTM enables impact analysis (determining what is affected when a requirement changes), ensures completeness of testing coverage, and provides an audit trail for compliance and governance requirements.
19. What is the difference between validation and verification?
Verification asks "Are we building the product right?" — it checks that the product conforms to its specified requirements (typically through reviews, inspections, and testing). Validation asks "Are we building the right product?" — it checks that the product actually meets the real business need (typically through user acceptance testing and stakeholder review). A product can pass verification (it matches the spec) but fail validation (the spec was wrong). Both are critical: verification ensures quality, validation ensures value.
20. What is scope creep and how is it managed?
Scope creep is the gradual, uncontrolled expansion of project scope without corresponding adjustments to time, budget, or resources. It is caused by stakeholders adding new requirements after scope is agreed, vague initial requirements that are interpreted broadly, and inadequate change control processes. It is managed through a formal change management process (every new requirement must be evaluated for impact and approved), clear scope documentation with explicit boundaries (in scope / out of scope), regular stakeholder communication, and using a product backlog in Agile to acknowledge new ideas without disrupting the current sprint.
Process Modelling
21. What is BPMN and why is it used?
BPMN (Business Process Model and Notation) is an internationally standardised graphical notation for documenting business processes in a format understandable by both business stakeholders and technical implementers. BPMN uses swimlane diagrams to show participants, with symbols for tasks, gateways (decision points), events (start, intermediate, end), and sequence flows. It supports both simple "happy path" diagrams and complex processes with parallel paths, loops, compensation, and exceptions. BPMN 2.0 is also executable — process engines like Camunda and Flowable can run BPMN diagrams directly.
22. What are swimlanes in process modelling?
Swimlanes are horizontal or vertical bands in a process diagram that assign activities to specific roles, departments, or systems. They show who is responsible for each step in a process and where handoffs occur between participants. In BPMN, pools represent organisations and lanes represent roles or departments within an organisation. Swimlane diagrams are excellent for identifying handoff inefficiencies, bottlenecks, and unclear ownership. They are used in customer journey mapping, service design, and process improvement projects to make responsibilities visually clear.
23. What are the types of gateways in BPMN?
BPMN gateways control the flow of a process. The Exclusive Gateway (XOR, diamond with an X) allows only one path — it is an if/else decision. The Parallel Gateway (AND, diamond with a +) splits into multiple simultaneous paths or merges them back together. The Inclusive Gateway (OR, diamond with an O) allows one or more paths to be taken based on conditions. The Event-Based Gateway routes flow based on which event occurs first (e.g., timer vs. message). Choosing the correct gateway type is critical for accurately representing real process behaviour.
24. What is a value stream map?
A value stream map (VSM) is a Lean tool that visually maps all steps in a process — both value-adding and non-value-adding — from the beginning to the end (typically from customer order to delivery). It shows process steps, information flows, inventory levels, wait times, and cycle times. It distinguishes between value-added time (time directly contributing to what the customer pays for) and waste (waiting, overprocessing, defects, transport). VSMs identify improvement opportunities and inform redesign. They are used in manufacturing, software delivery (DevOps), and service improvement initiatives.
25. What is the difference between a process and a procedure?
A process is a high-level description of how work flows through an organisation to achieve an objective — it shows the sequence of activities, roles involved, and decision points, but not detailed instructions. A procedure is a detailed, step-by-step instruction set for carrying out a specific activity within a process — it specifies exactly how a task should be performed, including tools, inputs, and outputs. BAs typically document processes (as BPMN or flowcharts) during analysis and then work with subject matter experts to create procedures. Both are needed for operational clarity and training.
26. What is process mining?
Process mining is a data-driven technique that automatically discovers, monitors, and improves real processes by extracting knowledge from event logs in information systems (ERP, CRM, ticketing systems). It has three main activities: discovery (automatically generating a process model from event logs), conformance checking (comparing the actual process against a reference model to find deviations), and enhancement (adding performance metrics like bottlenecks and cycle times to an existing model). Tools include Celonis, UiPath Process Mining, and Disco. Process mining provides objective, evidence-based insights rather than subjective stakeholder descriptions.
27. What is a use case diagram?
A UML use case diagram shows the high-level functionality of a system from the perspective of its users (actors). It depicts actors (users or external systems), use cases (specific interactions or goals), and the relationships between them (association, include, extend, generalise). An <<include>> relationship means a use case always includes the behaviour of another. An <<extend>> relationship means a use case optionally extends another under certain conditions. Use case diagrams are useful for scoping, communicating functionality to stakeholders, and planning test scenarios, but they do not show process flow.
28. What is an entity-relationship (ER) diagram?
An ER diagram models the data structure of a system by showing entities (things or concepts of interest, like Customer, Order, Product), their attributes (properties), and the relationships between them. Relationships have cardinality (one-to-one, one-to-many, many-to-many) and optionality (mandatory or optional). Crow's foot notation is commonly used. ER diagrams are produced by BAs and data architects during requirements and design phases to document data requirements and inform database design. They are essential for understanding what data needs to be captured, stored, and maintained.
29. What is a decision table?
A decision table documents complex business rules by showing all possible combinations of input conditions and the corresponding actions or outcomes. Columns represent rules and rows represent conditions (upper half) and actions (lower half). Decision tables are precise, unambiguous, and easy to validate with stakeholders and testers — they expose missing or conflicting rules that prose descriptions often obscure. They are used for pricing engines, eligibility rules, loan approval logic, and any scenario with multiple conditions driving different outcomes. Decision tables directly map to test cases.
30. What is the difference between "as-is" and "to-be" process modelling?
An "as-is" (current state) process model documents how a process is currently performed — including inefficiencies, workarounds, and manual steps. It provides the baseline for improvement and reveals pain points, bottlenecks, and compliance gaps. A "to-be" (future state) process model shows the improved or redesigned process after changes are implemented — streamlined flows, automation, eliminated waste, and better controls. The gap between as-is and to-be defines the scope of change required. BAs produce both models during process improvement projects and use the comparison to justify the investment.
Stakeholder Management
31. What is stakeholder analysis?
Stakeholder analysis identifies all parties affected by or who have influence over a project, and assesses their interests, expectations, level of influence, and likely response to the project. Tools include the Power-Interest Matrix (categorising stakeholders by their power and interest levels into Manage Closely, Keep Satisfied, Keep Informed, or Monitor quadrants), the RACI matrix (defining Responsible, Accountable, Consulted, and Informed roles), and stakeholder registers. Analysis informs the communication and engagement strategy — high-power stakeholders need active engagement; low-power/low-interest stakeholders need periodic updates.
32. What is the RACI matrix?
A RACI matrix (Responsibility Assignment Matrix) defines roles and responsibilities for each activity or decision in a project. Responsible: the person who does the work. Accountable: the single person ultimately answerable for the outcome (one per task). Consulted: people whose input is needed before the work is done (two-way communication). Informed: people who need to be kept up-to-date after decisions are made (one-way communication). The RACI matrix prevents confusion about ownership, ensures all activities have someone accountable, and helps manage communication overhead.
33. How do you handle conflicting stakeholder requirements?
Conflicting requirements are resolved through structured facilitation: first, ensure each stakeholder's perspective is fully understood and documented. Hold a workshop with key stakeholders to surface conflicts explicitly and use prioritisation techniques (MoSCoW, voting, ROI analysis) to agree on priority. Escalate unresolved conflicts to the appropriate governance forum (steering committee, project sponsor). Document agreed decisions in writing. Sometimes conflicts are resolved by deferring lower-priority requirements to a future phase. The BA acts as a neutral facilitator — they do not impose solutions but create the conditions for stakeholders to reach consensus.
34. What is a communication plan?
A communication plan defines who needs what information, in what format, how frequently, and through what channel. It includes stakeholder name, type of communication (status report, demo, workshop, one-on-one), frequency (weekly, monthly, on milestone), format (email, PowerPoint, dashboard), and owner. Effective communication plans prevent stakeholders from feeling out-of-the-loop or overwhelmed with irrelevant detail. For project BAs, regular communication — especially proactive escalation of risks and issues — builds trust and ensures stakeholder alignment throughout the project lifecycle.
35. What is a product owner's role in Agile and how does a BA interact with them?
The Product Owner (PO) in Agile represents the business and is accountable for maximising the product's value by managing and prioritising the product backlog. The BA supports the PO by eliciting and documenting detailed requirements, writing user stories and acceptance criteria, conducting stakeholder interviews, performing data analysis to inform decisions, and facilitating requirements workshops. In many organisations, the BA and PO roles are combined. The BA ensures that stories are ready for development ("definition of ready") and that delivered features meet business needs ("definition of done").
36. What is change management and how does a BA support it?
Change management is the structured approach to transitioning individuals, teams, and organisations from a current state to a desired future state. A BA supports change management by assessing the impact of proposed changes on business processes, roles, and systems; identifying affected stakeholders; contributing to training needs analysis; documenting updated process flows and procedures; assisting with user acceptance testing (UAT); and communicating changes to stakeholders. The BA bridges business understanding of the change with the technical implementation, ensuring operational readiness alongside technical delivery.
37. What is a workshop and how do you facilitate one effectively?
A workshop is a structured, time-boxed group session used to achieve a specific objective (requirements gathering, process mapping, prioritisation, problem-solving). Effective facilitation includes: preparing a clear agenda and pre-read materials, inviting the right participants (decision-makers, SMEs, users), establishing ground rules at the start, using structured techniques (brainstorming, affinity mapping, dot voting), capturing all output in real-time (whiteboard, digital tool like Miro), managing dominant personalities while drawing out quiet voices, summarising agreed outcomes before closing, and distributing minutes with actions and owners within 24 hours.
38. How do you manage a difficult stakeholder?
Managing difficult stakeholders requires empathy, clarity, and firmness. First, understand their concern — often resistance stems from fear of change, lack of information, or past negative experiences. Engage them early and frequently, involve them in requirements definition so they feel ownership, and address their concerns directly rather than avoiding them. If they are blocking progress, escalate to the project sponsor with a documented account of the issue. Document all agreements in writing to prevent future disputes. Frame all decisions in terms of business value and their specific interests to align incentives.
39. What is UAT (User Acceptance Testing)?
User Acceptance Testing is the final testing phase where actual business users validate that the delivered solution meets their requirements and is fit for purpose in the real business context. The BA supports UAT by creating test scenarios from requirements and acceptance criteria, helping users understand how to execute tests, documenting defects with sufficient detail for developers, tracking defect resolution, and managing the sign-off process. UAT differs from system testing (which verifies technical functionality) — it tests whether the system supports the business process correctly. Successful UAT sign-off is typically the trigger for deployment.
40. What is the difference between a sponsor and a champion?
A sponsor is typically a senior executive who provides funding, authorises resources, and has overall accountability for the project's success. They remove organisational obstacles and make high-level decisions. A champion is a middle-management or operational stakeholder who actively advocates for the project within their team, encourages adoption, participates in requirements sessions, and supports change management activities. Sponsors legitimise the project; champions build grassroots support for it. Both are necessary for a project to succeed — sponsorship ensures resources, while champions drive adoption.
Agile & Tools
41. What is the difference between Agile and Waterfall?
Waterfall is a sequential, phase-by-phase approach where requirements are fully defined upfront, followed by design, development, testing, and deployment in distinct phases with limited iteration. It is suitable for projects with stable, well-understood requirements and regulatory constraints. Agile is an iterative, incremental approach that delivers working software in short sprints (2-4 weeks), embraces changing requirements, and prioritises continuous collaboration between business and development teams. Agile enables faster delivery of value, earlier feedback, and the ability to adapt to changing business needs — making it dominant for software product development.
42. What is a sprint in Scrum?
A sprint is a time-boxed iteration in Scrum, typically 1-4 weeks, during which the team commits to completing a set of user stories from the sprint backlog. A sprint begins with Sprint Planning (selecting stories from the backlog and creating a sprint backlog), includes Daily Standups (15-minute sync on progress, plans, and impediments), Sprint Review (demonstrating completed work to stakeholders), and Sprint Retrospective (reviewing team processes for improvement). At the end of every sprint, the team aims to deliver a potentially shippable product increment. No scope changes are permitted during a sprint.
43. What is the product backlog and how is it managed?
The product backlog is an ordered list of all features, user stories, bug fixes, and technical improvements that represent everything the product team might work on. The Product Owner is responsible for ordering and maintaining the backlog. Backlog refinement (grooming) sessions are held regularly to add details, estimates, and acceptance criteria to upcoming stories, and to remove outdated items. Stories at the top of the backlog should be small, well-defined, and ready for development; stories further down can be larger and less defined. The backlog is a living document that evolves throughout the project.
44. What is a definition of done (DoD)?
The Definition of Done is a shared team agreement on what criteria must be met for a user story or feature to be considered fully complete. It typically includes code written and reviewed, unit tests passing, integration tests passing, code merged to the main branch, documentation updated, acceptance criteria met and verified, and product owner sign-off. A clear DoD prevents technical debt, ensures quality, and stops teams from calling work "done" when significant tasks remain. It should be agreed upon before a sprint begins and applied consistently to every story.
45. What is Kanban and how does it differ from Scrum?
Kanban is an Agile framework that manages work through a visual board (To Do, In Progress, Done) with work-in-progress (WIP) limits that prevent teams from overloading any stage. Unlike Scrum, Kanban has no sprints, roles (Scrum Master, Product Owner), or ceremonies — work flows continuously. WIP limits force teams to complete tasks before starting new ones, improving flow and identifying bottlenecks. Kanban is suited to support/maintenance work with unpredictable incoming requests. Scrum works better for new feature development with defined goals per sprint. Many teams use a hybrid (Scrumban).
46. What is story pointing and velocity?
Story points are a relative unit of effort estimation used in Agile to assess the complexity, uncertainty, and effort of user stories, independent of time. Teams use the Fibonacci sequence (1, 2, 3, 5, 8, 13) or T-shirt sizes (S, M, L, XL) and estimate via planning poker for consensus. Velocity is the number of story points a team completes per sprint, measured over several sprints to establish a baseline. Velocity is used for sprint capacity planning and release date forecasting. Points should not be translated directly to hours — they measure relative complexity, not absolute time.
47. What is a burndown chart?
A sprint burndown chart shows the remaining work (story points or hours) in a sprint over time, with a plotted "ideal" line showing the expected linear progress. If the actual line is above the ideal, the sprint is at risk of not completing all committed work. If it is below, the team is ahead. A release burndown shows remaining backlog over multiple sprints for release planning. Burndown charts are reviewed in the daily standup to identify when the team needs to re-scope or escalate impediments. They provide a simple, visual early warning system for sprint delivery risk.
48. What tools does a BA typically use?
BAs use a variety of tools depending on the project and methodology. For requirements documentation: Confluence, Jira, MS Word. For process modelling: Lucidchart, Visio, draw.io, ARIS. For wireframing and prototyping: Balsamiq, Figma, Axure. For data analysis: Excel, SQL, Power BI, Tableau. For project and backlog management: Jira, Azure DevOps, Trello. For collaboration and workshops: Miro, Mural, Microsoft Teams. Proficiency in SQL and data visualisation tools is increasingly expected as the BA role becomes more data-driven in modern analytics-oriented organisations.
49. What is an MVP and why is it important?
An MVP (Minimum Viable Product) is the simplest version of a product that delivers enough value to satisfy early customers and provide meaningful feedback for future development, without building unnecessary features. It embodies the Lean principle of validated learning — test assumptions quickly and cheaply before investing in full development. A BA contributes to MVP definition by prioritising the "must have" requirements that address the core user problem, helping the team avoid over-engineering and feature creep. The MVP is validated through real user usage and feedback, which informs the next iteration.
50. How do you write a good business requirements document in Agile?
In Agile, comprehensive upfront documentation (traditional BRD) is replaced by a lightweight, evolving set of artefacts: an Agile Project Charter (one page capturing goal, scope, constraints, and success metrics), a product vision statement, personas, journey maps, and a product backlog. For each initiative, the BA produces an epic (high-level requirement) broken into user stories with acceptance criteria written in Given-When-Then format. Documentation should be "just enough, just in time" — detailed enough for developers to build and testers to verify, but not so prescriptive that it stifles design creativity or becomes outdated before it is read.