43 Business Analysis Interview Questions on BABOK, Techniques, and the Models That Actually Get Asked

BABOK stands for the Business Analysis Body of Knowledge, published by the International Institute of Business Analysis (IIBA), and it's the standard reference describing the knowledge areas, tasks, and techniques that make up business analysis work. No interviewer expects verbatim recall of a 500-page guide.

What they do expect is that you recognize the six knowledge areas and use the right vocabulary when a scenario calls for it. I don't think memorizing chapter numbers helps anyone in an actual interview. Recognizing the terms and applying them under a live scenario does.

ECBA (Entry Certificate in Business Analysis) has no experience requirement. CCBA (Certification of Capability in Business Analysis) requires 3,750 hours of BA work in the last 7 years. CBAP (Certified Business Analysis Professional) requires 7,500 hours across at least 4 of the 6 knowledge areas within the last 10 years.

My honest take, and it could be wrong: past a certain experience level, which letters follow your name matters less than whether you can walk through one real technique from each area you're claiming. I've watched ECBA holders out-answer CBAPs in the actual room.

Business requirements (why the organization needs the change at all), Stakeholder requirements (what a specific group needs from the solution), Solution requirements, split into Functional and Non-functional, and Transition requirements (needed only to move from the current state to the future one, then they stop mattering).

The most common mixup is folding Stakeholder requirements into Business requirements as if they're the same category. They aren't. A business requirement justifies the project. A stakeholder requirement describes what one group specifically needs, and different stakeholder groups can have requirements that pull in different directions even while serving the same business requirement.

Business analysis defines needs, requirements, and solutions for organizational change. Business analytics analyzes data for patterns and decisions, and it overlaps heavily with data analyst and data science work. The two disciplines share a name fragment and almost nothing else in daily practice.

Some job postings conflate the two, sloppily. A candidate who blurs them in an interview usually signals they didn't read the actual role description closely, which is a worse look than not knowing a technique name.

The Agile Extension is IIBA's supplementary publication applying core BA practices to Agile delivery: just-in-time elicitation instead of one large upfront pass, lightweight documentation, and analysis happening in parallel with development rather than fully ahead of it.

Knowing it exists and naming one concept from it, "just enough" analysis is the phrase that comes up most, signals real awareness. Most interviewers don't expect page-level familiarity with a supplementary guide most working BAs have skimmed once.

Document Analysis (reviewing existing SOPs, tickets, or old requirements to see what's already known), Observation (watching the real work happen instead of asking someone to describe it), and Prototyping (a rough wireframe that gets a much more specific reaction than an abstract question ever does).

Workshops are worth naming too, since a facilitated group session surfaces conflicts between stakeholders that one-on-one interviews tend to hide until much later in the project.

SWOT (Strengths, Weaknesses, Opportunities, Threats) is listed in BABOK's Techniques chapter and used mainly during Strategy Analysis, evaluating an initiative against internal capabilities and external conditions before committing resources to it.

Interviewers sometimes ask you to apply SWOT to a hypothetical scenario on the spot. The weak answers list four generic bullets. The strong ones name a specific, plausible weakness or threat that a stakeholder in the room would actually recognize.

It covers named, repeatable methods, MoSCoW (Must, Should, Could, Won't), weighted scoring against defined criteria, or ranking against a combination of value, risk, and cost. It's named as a formal technique because BABOK expects a documented method, not an ad hoc call that can't be defended later.

When a stakeholder challenges why their request landed at "Should" instead of "Must," a documented method gives you an actual answer. A gut call doesn't.

It compares an organization's process, product, or practice against competitors or industry standards, surfacing gaps or opportunities with an actual reference point instead of an assumption. Even on an internal system, it's relevant the moment a stakeholder claims "our competitor's tool does this in three clicks and ours takes eight."

Verifying that claim, rather than accepting or dismissing it on faith, is exactly what this technique is for.

Item Tracking is the discipline of logging issues, action items, risks, and decisions that surface during elicitation so nothing gets lost between sessions. It's named separately because the failure mode it prevents is common: a stakeholder raises a real concern in a workshop, and it quietly disappears because nobody wrote it down anywhere durable.

BABOK treats tracking as a distinct skill precisely because it's easy to skip when you're focused on capturing the bigger requirements in the room.

UML (Unified Modeling Language) is broader and mostly models software structure and behavior, use cases, classes, sequences of calls between system components. BPMN (Business Process Model and Notation) is specifically built for business process flows, with symbols for events, gateways, and swimlanes that map more directly onto how a business process actually runs.

You can read a BPMN diagram without understanding object-oriented concepts. You generally can't get full value from a UML class diagram without some.

A pool represents a whole participant in a process, an organization, a department, or a system. Lanes subdivide a pool into the specific roles or sub-units within that participant. Two pools side by side usually represent two separate organizations exchanging messages across a boundary.

Lanes inside one pool represent internal handoffs within the same organization, finance to procurement to warehouse, for instance, without ever crossing an organizational boundary.

A DFD shows how data moves between external entities, processes, and data stores using a small, fixed set of symbols. A Level 0, or context, diagram shows the entire system as one single process, with only the external entities and the data flows that cross the system boundary, no internal steps at all.

It exists to establish scope before decomposing into a Level 1 diagram and deeper. Skipping straight to Level 1 without a context diagram is a common shortcut that ends up hiding the actual system boundary from the reader.

It models the distinct states an entity can be in and the events that trigger a transition between them, an order moving from "placed" to "shipped" to "delivered," with explicit rules about which transitions are valid and which aren't.

It matters the moment a stakeholder describes a status field with more nuance than "active or inactive," and a BA needs to make explicit exactly which status changes are actually allowed, since developers will otherwise build whatever transitions are technically easiest.

An RTM formally links each requirement to its source (why it exists), the design element addressing it, and the test case validating it, so every requirement has a documented reason to exist and a documented way to confirm it was actually met.

For the practical version, how a BA actually uses one day to day, and whether you've maintained a real one, our business analyst interview questions guide covers that specific angle. Here the point is the mechanism, not the day-to-day habit of keeping it current.

A baseline is a specific, approved version of requirements frozen at a point in time, used as the fixed reference point for evaluating any future change against. Without a baseline, "the requirement changed" has no starting point to compare against.

Which means scope creep becomes nearly impossible to detect or quantify, since there's no agreed version of "before" to measure the drift from in the first place.

A transition requirement describes something only needed to move from the current state to the future one, data migration steps, temporary parallel-run access, training, and it stops mattering once the transition completes, unlike functional or non-functional requirements that describe the ongoing solution.

Teams forget them because nobody owns "temporary" work by default. A requirement that stops mattering after go-live is easy to deprioritize right up until go-live week, when it turns out someone actually needed it.

Business Analysis Planning and Monitoring (governance: how the work itself gets planned and tracked), Elicitation and Collaboration (gathering information from stakeholders), Requirements Life Cycle Management (tracing, maintaining, prioritizing, and approving requirements after they're written), Strategy Analysis (defining the business need and solution scope before detailed requirements exist), Requirements Analysis and Design Definition (structuring and verifying what was elicited), and Solution Evaluation (measuring whether the delivered solution actually created value).

Candidates blur Elicitation and Collaboration with Requirements Life Cycle Management most often, since both touch requirements. The real split is timing: one is about getting the information, the other is about what happens to it afterward.

Both certify a business analysis skillset from different parent organizations. PMI-PBA leans on project-context work; CBAP leans on the BABOK's knowledge areas without tying itself to a specific delivery methodology. Most hiring managers treat them as roughly equivalent seriousness signals, not as competing credentials.

Where it can tip one way: a company already running PMI's framework across its project management practice sometimes prefers PMI-PBA purely for internal consistency, not because it's a stronger certification on its own merits.

The IIBA Business Analysis Competency Model is a separate publication from the BABOK Guide. BABOK describes what business analysis work covers: the knowledge areas, tasks, and techniques. The competency model describes the underlying skills a BA needs to do that work well, analytical thinking, communication skills, business knowledge, interaction skills, tools and technology.

An interviewer who references the competency model by name is usually probing soft-skill readiness, not testing whether you've read the BABOK Guide cover to cover.

It's the knowledge area that governs a requirement after it exists: tracing it to other artifacts, maintaining it as things change, prioritizing it against competing requirements, assessing the impact of any proposed change, and getting it formally approved.

It's the natural pair to Elicitation and Collaboration, which is about getting the requirement in the first place. Once it's written down, ownership passes to this knowledge area for as long as the requirement stays relevant.

Past a certain point, it's mostly a resume signal, useful for clearing an ATS keyword filter or a recruiter screen more than for teaching you anything you haven't already picked up on the job. That's an opinion, and a hiring manager who values formal credentialing more than I do would disagree with it.

I'd rather interview a candidate who can walk through one real requirements traceability matrix they actually built than one who has CBAP after their name and nothing specific to point to when asked about it.

A business requirement explains why a project or change is needed at all, higher revenue, lower cost, a compliance mandate. A business rule is a standing constraint the organization operates under regardless of any specific project, "a loan applicant must be 18 or older," true whether or not any system currently enforces it.

Business requirements justify projects and eventually get satisfied and closed. Business rules persist independent of any one project and usually outlive several systems built to enforce them.

Brainstorming is unstructured idea generation with a defer-judgment rule meant to maximize the volume of raw ideas before evaluating any of them. Mind Mapping visually organizes ideas around a central concept, branching them into related groups so you can see how they connect.

They're sequential, not interchangeable. Brainstorm first to generate volume, then mind map to organize what you generated and spot the gaps or duplicates hiding in a flat list.

Both are Root Cause Analysis techniques aimed at the underlying cause behind a symptom, not the symptom itself. Five Whys is linear: repeatedly asking "why" until you hit a cause you can actually act on, typically around five iterations, though the number isn't a hard rule.

A Fishbone (Ishikawa) diagram is non-linear. It branches potential causes into categories, people, process, technology, environment, so you can explore several causal threads at once. Five Whys fits a single, well-understood symptom. Fishbone fits when you suspect several contributing factors and don't yet know which one matters most.

A business rule constrains or defines something about the business independent of any specific solution. A requirement describes what a specific solution must do to satisfy that rule. The rule stays true if you swap out the entire system; the requirement describing how a particular system enforces it might not.

Candidates who write requirements without separating out the underlying rule end up duplicating the same constraint across a dozen requirements documents, and updating the rule later means hunting down every duplicate instead of changing it once.

It examines the quality attributes a solution must meet, performance, security, availability, usability, compliance, separate from whether the feature technically works. A functional review only checks "does it do the thing."

A login feature that authenticates correctly but takes nine seconds to respond passes a functional check and fails a non-functional one. Candidates who only prepare functional-requirement examples miss this category almost entirely.

A use case diagram connects actors (people or other systems) to use cases (the specific interaction goals) with simple lines, communicating system scope at a glance, who can do what, without describing how any of it actually works internally.

A one-page diagram showing eight actors and fifteen use cases tells a stakeholder the system's boundary faster than a page of prose describing the same thing ever could. That's the actual point of the diagram, not decoration.

An Activity Diagram is UML's flowchart-style notation, often describing a single workflow's logic including decision branches, without necessarily naming which role owns each step. A BPMN diagram with swimlanes (pools and lanes) makes ownership explicit, every step lives in a specific lane belonging to a role or department.

If handoffs between roles are the actual point you're trying to surface, BPMN is the better tool. If the logic within one role's workflow is the point, an Activity Diagram is usually enough.

Exclusive gateway (XOR): exactly one path out of several gets taken, based on a condition. Parallel gateway (AND): every outgoing path happens simultaneously, no condition required. Inclusive gateway (OR): one or more paths can be taken depending on conditions, more flexible than exclusive, but not forcing all paths the way parallel does.

Mixing up exclusive and inclusive is the most common mistake candidates make describing a real process from memory, since the difference only matters when more than one condition could plausibly be true at once.

A Use Case Diagram shows what interactions exist. A Sequence Diagram shows the order those interactions happen in over time, message by message, between specific actors and system components.

Reach for a sequence diagram when timing or ordering is the actual point of confusion, an API call firing before a downstream service is ready for it, for example. A use case diagram wouldn't surface that problem at all; it isn't built to.

AS-IS documents the process as it currently runs, workarounds and inefficiencies included, whether or not anyone officially approved them. TO-BE documents the intended future state after the proposed change is implemented.

The mistake: describing AS-IS as "what the process is supposed to do" rather than what it actually does. A BA who only interviews the process owner about the ideal version, without watching the real workaround-laden reality, produces an AS-IS model that isn't actually AS-IS at all.

Trace Requirements (linking relationships between requirements and other artifacts), Maintain Requirements (keeping them accurate as time passes, retiring ones that no longer apply), Prioritize Requirements (ranking against value, risk, and cost), Assess Requirements Changes (impact analysis on any proposed change), and Approve Requirements (getting accountable stakeholders to formally sign off).

Five named tasks, each answering a genuinely different question about what happens to a requirement after it's written. Candidates who name "traceability" as the whole knowledge area are only naming one-fifth of it.

Verification asks whether the requirement is written correctly: complete, unambiguous, consistent with other requirements. Validation asks whether the requirement, built exactly as written, would actually deliver the business value it's meant to.

Candidates get it backwards by assuming "verified" means "definitely the right thing to build." A requirement can be perfectly clear and pass verification while still solving the wrong problem entirely, which is exactly what validation exists to catch, and verification alone never will.

Priority, source (who or what artifact it came from), and status (proposed, approved, implemented, deferred) are three commonly tracked attributes; others include complexity, stability, and risk.

Tracking these turns a flat list of sentences into something you can actually query later. "Show me every high-priority requirement still sitting in proposed status" is a real question a PM asks two weeks before a release, and it only has a real answer if someone tracked the attributes as the requirement was written, not reconstructed them after the fact.

This one genuinely depends on the industry, and I don't think there's one right answer that applies to every team. In a regulated context, close to mandatory regardless of delivery methodology, since an auditor doesn't care that your team is Agile.

Outside a regulated context, plenty of Agile teams get equivalent traceability from linking each ticket to its acceptance criteria and parent epic, without maintaining a separate matrix at all. Both are legitimate answers depending on who's asking and why.

A stakeholder register is a list, who's involved, their role, their interest level, their influence, maybe their preferred communication channel. A RACI matrix is an assignment tool, it maps specific deliverables or decisions to specific people using four labels: Responsible (does the work), Accountable (owns the outcome, signs off, there should be exactly one per row), Consulted (gives input before a decision), and Informed (told after the fact). The register tells you who the players are, the RACI tells you what each player actually does on each deliverable.

You build both on any project with more than a handful of stakeholders because the register alone doesn't stop the classic failure mode: three people all think they're the approver on a requirement, so you get three rounds of conflicting sign-off, or nobody thinks they're the approver, so nothing gets decided. On a 20-stakeholder rollout I'd keep the register for onboarding and communication planning, and build a RACI per major deliverable (requirements doc, test plan, go-live decision) because different people own different phases even though the overall stakeholder list doesn't change.

One gotcha interviewers listen for: candidates who let a row have two people marked Accountable. That's not a stricter RACI, it's a broken one, because when both A's disagree nobody actually has to resolve it. Fix it by asking who signs the final approval, that person is A, everyone else with sign-off input is C.

A BRD describes the business problem and the business outcome, written so a VP or a client stakeholder can read it without technical background: what's broken, what the business needs to happen, what success looks like, usually tied to a business case or ROI. It answers "why are we doing this" and "what does the business need." An FRD describes system behavior: specific inputs, specific outputs, specific rules the software has to enforce, screen-level or API-level detail that a developer or QA engineer can build and test against directly.

The reason teams collapse them isn't laziness, it's usually project size. On a small internal tool, one document with a business context section followed by a functional section covers it fine. The split earns its keep on larger or multi-vendor projects, because the audiences are genuinely different: a BRD gets reviewed and signed by business sponsors who don't want to wade through field-level validation rules, and an FRD gets used by developers who don't need the business case every time they check a rule.

The failure mode worth naming in an interview: writing business language into the FRD, "the system should make onboarding faster," instead of testable statements, "the system shall complete new-user registration in under 3 steps with no more than 5 required fields." If a requirement can't be turned into a pass or fail test case, it's still living in BRD territory and hasn't actually become a functional requirement yet.

The Product Owner owns the "what" and "why" at the product level: vision, priority, and the final call on what goes into a sprint, because Scrum only allows one person to hold that authority. The BA owns depth: breaking a prioritized epic into detailed, testable stories, writing acceptance criteria, running the elicitation sessions that surface edge cases, and keeping the backlog technically coherent so the PO's priorities are actually buildable. A PO without a BA on a complex domain, insurance, healthcare billing, tax, often ends up writing thin stories that the dev team has to interrupt sprint work to clarify.

Can one person do both? On a small team building a straightforward product, yes, and it happens constantly, especially at startups. It gets genuinely hard once the domain has real regulatory or integration complexity, because prioritization work, talking to customers, watching usage data, negotiating with stakeholders, and elicitation work, sitting with a claims adjuster for three hours mapping edge cases, both take real hours and pull attention in opposite directions. When both roles are combined, backlog grooming quietly gets shallow, and that shows up two sprints later as stories getting kicked back from dev for missing acceptance criteria.

The interview tell here is candidates who say the two roles are basically the same job with different titles. They're not. The PO answers to a single accountable-owner model in Scrum, and the BA role exists specifically because that accountability doesn't scale down into detailed requirements work without someone dedicated to it.

The two columns are the easy part. What actually makes a gap analysis useful is the third thing most junior BAs skip: for each gap, naming the concrete cause and the specific action that closes it, with rough size and owner attached. "Current state: manual invoice matching, average 4 days. Future state: automated 3-way match, same day" is a comparison, not an analysis. The analysis is naming that the gap exists because there's no system integration between AP and the warehouse receiving system, that closing it requires an EDI feed or a shared database view, owned by IT integration, roughly a 6-week build. Without that layer, the document reads like a wish list.

The other thing that separates a real gap analysis from a superficial one is being honest about gaps that aren't process gaps at all, they're capability or capacity gaps. Sometimes the future state can't be reached because the team lacks a skill, or a system genuinely can't scale to the target volume without a platform change, not just a configuration change. Calling that out early avoids the common failure where a project gets scoped assuming the current tooling supports the target state, and three sprints in someone discovers the core system has a hard record limit it can't clear.

Good gap analyses also state the cost of doing nothing explicitly, what keeps happening if the gap stays open, because that's usually what justifies budget for closing it. A future-state column with no attached cost of inaction rarely survives a prioritization conversation with finance.

Strategy Analysis happens earlier: defining the business need, assessing risk, and scoping a candidate solution before detailed requirements exist. Requirements Analysis and Design Definition takes what was elicited and turns it into structured, verified requirements and, often, potential designs.

One decides whether a problem is worth solving and roughly how big the solution should be. The other decides exactly what that solution must do. Skipping Strategy Analysis and going straight to detailed requirements is how projects end up solving a well-documented version of the wrong problem.

Say what you do know and name the specific gap, rather than guessing with false confidence. "I know root cause analysis lives somewhere in Elicitation and Collaboration or nearby, but I'd want to check exactly which task it maps to before I relied on that in a real project" is a stronger answer than a confident wrong guess.

The interviewer is checking whether you know the edges of your own knowledge, not whether you've memorized a table. I said a few questions back that certification letters matter less than technique fluency. Worth qualifying that: certifications matter more at the recruiter-screen stage, before a technical interviewer ever sees your resume, than they do once you're actually in the room being asked to reason through a gap live.

Decision Analysis evaluates choices under uncertainty using structured tools. A decision tree branches sequential choices and fits situations where decisions happen in a clear temporal order. A decision table maps every combination of independent conditions to an outcome in rows and columns.

Reach for a decision table when several boolean conditions combine independently, an eligibility rule with four separate yes/no factors, for instance, since representing that as a tree would produce a bushy, hard-to-follow structure that a table handles in a single, scannable grid.

An ERD models data at rest, entities, their attributes, and the relationships between them, with cardinality, typically used to design a database schema. A Class Diagram models both data and behavior, classes include methods, not just attributes, and relationships can represent inheritance or composition that a pure data model like an ERD generally doesn't capture.

A BA producing an ERD is usually feeding a database designer. A BA producing a class diagram is usually feeding a developer who needs to know behavior, not just structure. Confusing the two audiences produces a diagram that satisfies neither.

Diagram what people actually do, then attach a note wherever it diverges from the SOP. That divergence is usually the single most useful finding in the entire exercise, more useful than a clean diagram that matches documentation nobody actually follows anymore.

Presenting the gap explicitly, instead of quietly diagramming the SOP version because it's easier to defend in a meeting, is what turns process modeling into something a stakeholder can act on rather than a compliance box to check.

Pull the RTM entry for that requirement: the original source, the exact wording that was baselined, and the test case tied to that wording. If the feature passes the test case linked to the baselined requirement, the real dispute is about whether the original requirement was written well, not whether the built feature is wrong.

That's a materially more useful conversation to have with a stakeholder than an unresolvable disagreement over "that's not what I meant," and it's the entire reason traceability exists as a discipline rather than a nice-to-have habit.

Trace outward from the changed requirement through every linked relationship, design elements, downstream requirements, test cases, and assess each one specifically instead of assuming the ripple effect stops at the first link you find.

The real skill being tested is whether you treat the RTM as a live map you traverse, not a static document you updated once and forgot about. A change that touches five requirements often touches an unlisted sixth that nobody traced properly the first time around.

First step is confirming it's a real conflict and not a language mismatch. A surprising number of "conflicts" turn out to be two people describing the same outcome with different vocabulary, or scoped to different segments of users that got merged into one requirement by mistake. I go back to each stakeholder separately and ask them to describe the business outcome they need, not the solution they're proposing, because people often anchor on "the system must do X" when what they actually need is a broader outcome, and there might be more than one X that satisfies it.

If the conflict is genuinely a business-level disagreement, say sales wants a discount field visible on the invoice and finance wants it hidden for audit reasons, that's not mine to resolve unilaterally, and pretending to arbitrate it as a BA is the mistake I see junior BAs make. I document both positions with the underlying rationale, quantify the cost of each option if I can, audit risk exposure versus estimated deal-close impact, and escalate to whoever has actual decision authority over that tradeoff. What I do control is making sure the decision, once made, gets written back into the requirement with the rationale attached, so it doesn't resurface as a fresh argument in UAT three months later.

The other move that actually prevents a standoff is proposing a middle option nobody's mentioned, like a role-based visibility rule instead of a global show or hide. Half the time a genuine non-negotiable standoff dissolves once someone proposes a third design that satisfies the underlying need on both sides, because the actual constraint each side cared about, audit trail intact, sales rep can still explain pricing, wasn't mutually exclusive, only the specific implementations they'd each imagined were.

Payback period answers how long until you get your money back, full stop, no adjustment for the time value of money and no signal about what happens to cash flows after that point. It's the easiest for a non-financial stakeholder to grasp and it's genuinely useful as a risk gut-check, especially in volatile environments where anything past 18 months feels too uncertain to bet on, but it will happily rank a project that pays back in 14 months and then dies over one that pays back in 20 months and then generates cash for a decade.

NPV discounts every future cash flow back to today's dollars using the company's cost of capital and sums them, giving you a single dollar figure for whether the project creates value after accounting for the fact that money now is worth more than money later. It's the number finance actually cares about because it's additive across projects and directly comparable to alternative uses of the same capital. IRR is the discount rate at which NPV hits zero, and it's popular because it comes back as a clean percentage that's easy to compare to a hurdle rate, but it has a real trap: with non-conventional cash flows, an initial cost, then income, then another cost later, IRR can produce multiple valid answers or none at all, and it ignores project scale, so a tiny project at 40% IRR can create less absolute value than a bigger one at 15%.

In practice, NPV wins the argument with finance because it maps directly to shareholder value in dollar terms and doesn't break under unusual cash flow shapes. I've had this exact conversation more than once: someone pitches IRR because 35% sounds more exciting than a flat dollar figure, and the CFO reframes it in NPV terms in about ten seconds because that's the number their capital allocation model actually runs on.

The obvious first pass is grouping on the fields that should be unique and filtering for a count above one.

SELECT email, COUNT(*) AS cnt
FROM customers
GROUP BY email
HAVING COUNT(*) > 1;

That gets you exact duplicates on a single field, but it misses the real-world mess: casing differences between two versions of the same address, trailing whitespace from a legacy import, and NULL emails that GROUP BY silently drops from consideration since NULL never equals NULL. A version that actually holds up in a data quality audit normalizes the comparison field first.

SELECT LOWER(TRIM(email)) AS normalized_email, COUNT(*) AS cnt,
       STRING_AGG(customer_id::text, ',') AS ids
FROM customers
WHERE email IS NOT NULL
GROUP BY LOWER(TRIM(email))
HAVING COUNT(*) > 1;

The harder version of this question, and the one that separates a junior answer from a senior one, is when a duplicate isn't a single-field match at all, it's a fuzzy match, same person, different email, because they signed up twice with a work address and a personal one. That's not solvable with GROUP BY, it needs a composite key match, name plus phone plus billing zip, say, or a similarity function like Levenshtein distance or a trigram match if the database supports it, and even then you're producing candidate pairs for a human to confirm, not a clean automatic answer. I'd tell the interviewer directly that exact-match SQL solves the easy 80 percent and the remaining fuzzy matches need either a dedicated matching library or a manual review step.

DMAIC, Define, Measure, Analyze, Improve, Control, is a specific, statistically-grounded methodology for reducing variation and defects in an existing process, built for problems where you can actually measure a defect rate and prove a root cause with data. Classic examples are manufacturing tolerances, call center handle time, or claims processing error rates. It requires baseline measurement before you touch anything, a documented root-cause analysis, often using control charts or hypothesis testing rather than a Fishbone diagram off the top of someone's head, and a Control phase at the end that locks the improvement in with ongoing monitoring, because the single most common Six Sigma failure is a process that improves for two months and then drifts right back to where it started once nobody's watching the metric anymore.

Standard continuous process improvement, kaizen-style, is looser and faster. It doesn't require a certified Black Belt running formal statistical tests, it can run on a two-week cycle with a team just looking at a process map, spotting waste, and making an incremental change, then checking if it helped. It's the right tool when the problem is obvious once you look, three redundant approval steps, a form that asks for the same data twice, and doesn't need rigorous statistical proof to justify fixing.

Whether a BA needs both depends on the industry. In manufacturing, healthcare, or heavily regulated financial operations, DMAIC comes up constantly because defect rates carry real compliance and cost consequences, and BAs there are often expected to at least read a control chart even if they're not running the statistics themselves. In software or general enterprise operations, most process improvement work is closer to the lighter kaizen model. I've used the lighter version far more often, and reached for DMAIC specifically on one project involving a claims-processing error rate where the client's compliance team required statistical proof of control before they'd sign off on calling the process fixed.

MoSCoW sorts requirements into Must, Should, Could, Won't, based on how critical each one is to the current release, and it's fundamentally a scoping tool, it answers what's in and what's out this time. It treats priority as roughly linear: more of a Must-have feature is generally better, and the ranking doesn't ask anything about how a customer's satisfaction actually behaves as you add more of it.

Kano is a different axis entirely: it classifies features by the shape of the relationship between how much of them you deliver and how satisfied the customer is, based on surveying users with paired functional and dysfunctional questions, how they'd feel if a feature is present versus how they'd feel if it's absent. Basic, or threshold, features cause dissatisfaction if missing but don't earn extra satisfaction beyond a baseline once present, think a password reset that actually works. Performance features scale roughly linearly, more speed, more storage, more satisfaction, in a fairly direct line. Excitement features aren't expected at all, so their absence doesn't hurt you, but their presence creates disproportionate satisfaction, until the market catches up and that delighter becomes an expected baseline feature next year, which is exactly what happened to fingerprint unlock on phones.

The practical difference in prioritization: MoSCoW tells a team what fits in a release. Kano tells a team which features actually move satisfaction versus which ones just clear a bar, and that changes what priority means, because heavy investment in a Basic feature past its threshold is often wasted effort, you can't out-satisfy a customer with a slightly more reliable login screen, while modest investment in a genuine delighter can shift a product's perception disproportionately. A BA who only knows MoSCoW will happily rank Must-have features by business urgency, but won't catch a team over-investing in polishing a threshold feature nobody will thank them for, and under-investing in a smaller delighter that would have actually differentiated the release.