Learn business analysis, with practice after every lesson
8 lessons, about 135 minutes of reading, and 24 multiple-choice questions. Each lesson names the mistake that most often costs people the interview, because that is where the hours actually go. Part of the free coding course.
Requirements are decisions, not documents
BasicsA business analyst sits between the people who want something and the people who build it, and the job is not transcription. When a stakeholder says 'we need a dashboard', that is a proposed solution, not a requirement. The requirement is the decision they cannot currently make — and once you know what that decision is, the dashboard may turn out to be a weekly email, a threshold alert, or nothing at all.
The habit that makes the difference is asking why until you reach the outcome. Why do you need it? To see which regions are behind. Why does that matter? So we can move budget before quarter end. That third answer is the actual requirement, and it tells you the thing must arrive before the budget deadline and needs a regional breakdown — two constraints the original request never mentioned.
Write requirements so that anyone can tell whether they were met. 'The report should be fast' is not testable; 'the report loads in under three seconds for a full year of data' is. Ambiguity does not disappear when it reaches a developer — it gets resolved by whoever is closest, usually silently and usually differently from what the stakeholder pictured, and the disagreement surfaces at demo.
Syntax
// A user story with acceptance criteria anyone can verify.
//
// AS A regional sales manager
// I WANT to see revenue by territory against target, refreshed daily
// SO THAT I can reallocate budget before the quarter closes
//
// ACCEPTANCE CRITERIA
// - Shows current quarter, split by the 6 territories
// - Shows actual, target, and variance as a percentage
// - Data no more than 24 hours old, with the timestamp visible
// - Loads in under 3 seconds with a full quarter of data
// - A manager sees only their own territories
//
// Note what the criteria surfaced that "we need a dashboard" did not:
// a deadline, a permission model, and a freshness requirement.Key points
- A stated request is usually a solution. The requirement is the decision underneath it, and asking why three times gets you there.
- Acceptance criteria must be checkable by someone who was not in the room. 'Fast' is not; 'under three seconds' is.
- Ambiguity you leave in a requirement gets resolved by a developer, silently, and usually differently from what the stakeholder imagined.
Practice challenge
A stakeholder says they need a better dashboard. Write the three questions that turn that into something buildable, then write the request as a user story with one testable acceptance criterion.
Q1: who uses it and what decision do they make with it?
Q2: what can they not see today?
Q3: how will we know it worked?
Story: As a regional manager, I want weekly sales by store against target, so that I can act on shortfalls before month end
Acceptance: the report shows the current week per store with variance to target and loads in under five secondsQ1: ______
Q2: ______
Q3: ______
Story: As a ______, I want ______, so that ______
Acceptance: ______Show a hint
- 'Better' is not a requirement - the first question is always who, and for what decision
- The acceptance criterion must be something someone can verify as true or false
Check yourself
1. When a stakeholder says 'we need a dashboard', what is that?
Show answer
B. A proposed solution — the requirement is the decision underneath
2. What makes acceptance criteria useful?
Show answer
B. Anyone not in the room can verify whether they were met
3. What happens to ambiguity left in a requirement?
Show answer
B. A developer resolves it silently, usually differently from what was pictured
Process mapping and finding the real problem
Working levelBefore changing a process you have to see it, and what people describe is rarely what happens. Ask three people how invoices get approved and you will get three answers, none of which mention the spreadsheet one team keeps because the system does not handle their case. Process mapping surfaces those gaps, and the gaps are usually where the actual problem lives.
Map the current state before designing the future one. The temptation is to skip straight to the improved version, and it produces designs that break on the exceptions nobody documented. Walk the process with the people doing it, note every handoff, every wait and every place work goes backwards — rework loops are where time disappears, and they rarely appear on the official diagram.
The distinction worth holding onto is between the problem and its symptoms. 'Approvals take nine days' is a symptom. Mapping might show that seven of those days are one queue, and that the queue exists because a single person approves everything over a threshold set in 2019 that inflation has made meaningless. The fix is a threshold change, not a software project — and being the analyst who finds that is worth more than being the one who specifies the system.
Syntax
// Current state — measure the waits, not just the steps.
//
// Submit ──► Manager approves ──► Finance checks ──► Paid
// 0.1d 6.0d ◄── the queue 1.2d 0.5d
// │
// └── 22% bounce back for missing PO ──► rework loop
//
// Total elapsed: 9.1 days. Actual work: ~1.8 days.
// Everything else is waiting or rework.
//
// The two questions that follow:
// 1. Why does the manager queue take 6 days?
// -> one approver, threshold ₹50,000 set in 2019, now catches everything
// 2. Why do 22% bounce?
// -> the PO field is optional in the form but mandatory in finance
//
// Neither fix is a software project. Both were invisible on the org chart.Key points
- Map what actually happens, not what the documentation says. The undocumented spreadsheet is usually where the problem is.
- Measure waits and rework loops, not just steps. Elapsed time minus working time is where the opportunity sits.
- Separate the symptom from the cause. 'Approvals take nine days' is a symptom; a threshold set in 2019 is a cause, and a much cheaper fix.
Practice challenge
An approval process takes 11 days: request (10 min), manager review (2 days), finance check (7 days waiting for a weekly meeting), issue (1 hour). Name the bottleneck, state the wait-to-work ratio, and give the change with the largest effect.
Bottleneck: the finance check, because it waits for a weekly meeting
Wait vs work: almost all of the 11 days is waiting; actual work is about two hours
Biggest change: approve below a value threshold without the meeting, or meet daily - automating the request form saves minutes, not daysBottleneck: ______
Wait vs work: ______
Biggest change: ______Show a hint
- Separate time spent working from time spent waiting before deciding anything
- The step people usually want to automate is the one costing ten minutes
Check yourself
1. Why map the current state first?
Show answer
B. What people describe is rarely what happens, and the gaps are where the problem is
2. What should you measure besides the steps?
Show answer
B. Waits and rework loops — where elapsed time actually goes
3. 'Approvals take nine days' is…
Show answer
B. A symptom — the cause might be a threshold nobody has revisited
Making the case with numbers
AdvancedThe analysts who progress are the ones who can put a number on the thing they are proposing. A recommendation without a quantified benefit competes for attention against every other request and usually loses to whichever one has a business case attached. This is where SQL matters for a BA — not because the role is technical, but because being able to size a problem yourself is the difference between proposing and waiting.
A usable business case has four parts: what it costs, what it saves or earns, when it pays back, and what you are assuming. The assumptions are the part people skip and the part a finance reviewer will go to first. State them explicitly — 'assuming volume stays at current levels' or 'assuming two of the four teams adopt it' — because a case with visible assumptions can be challenged and adjusted, while one without them gets rejected wholesale.
Present the range, not a single number. 'Saves between eighteen and thirty lakh a year depending on adoption' is more credible than a precise figure that implies a certainty you do not have, and it survives contact with reality better. When the outcome lands inside the range you gave, you are the analyst whose numbers can be trusted next time — which compounds far faster than being spectacular once.
Syntax
-- Size the problem yourself rather than asking for a report.
-- This is the SQL that turns 'approvals feel slow' into a number.
WITH cycle AS (
SELECT invoice_id,
DATEDIFF('day', submitted_at, paid_at) AS days_total,
DATEDIFF('day', submitted_at, approved_at) AS days_waiting_approval
FROM invoices
WHERE submitted_at >= DATEADD('month', -6, CURRENT_DATE)
)
SELECT COUNT(*) AS invoices,
ROUND(AVG(days_total), 1) AS avg_days,
ROUND(AVG(days_waiting_approval), 1) AS avg_in_approval,
SUM(CASE WHEN days_total > 10 THEN 1 ELSE 0 END) AS breached_sla
FROM cycle;
-- 4,182 invoices | 9.1 days avg | 6.0 in approval | 1,730 breached
--
-- The case writes itself:
-- 1,730 late payments x ₹1,200 average late fee = ₹20.8 lakh/year
-- Cost to fix (threshold change + form validation) = ~2 weeks of work
-- ASSUMING volume and fee rates hold at current levels.Key points
- Quantify the benefit or the recommendation competes on opinion, and loses to whichever proposal has a number attached.
- State your assumptions explicitly. A finance reviewer goes there first, and a case with visible assumptions can be adjusted rather than rejected.
- Give a range rather than a false precision. Landing inside a range you predicted is what makes your next number believed.
Practice challenge
Two weeks before launch, the sponsor adds a requirement that needs three weeks of work. Give the response that is neither a flat refusal nor a silent yes, and name what you must document either way.
Response: state the cost in the currency they control - this adds three weeks, so either the date moves, something in scope comes out, or it ships in a follow-up release; put the choice to them
Document: the change request, the impact assessment and the decision made, with who made itResponse: ______
Document: ______Show a hint
- A BA does not own the scope decision - they own making the trade-off visible
- The documentation is what protects everyone when the date is missed
Check yourself
1. Why does SQL matter for a business analyst?
Show answer
B. Being able to size a problem yourself is the difference between proposing and waiting
2. What do finance reviewers examine first?
Show answer
B. The assumptions behind it
3. Why present a range rather than one figure?
Show answer
B. It reflects real uncertainty and landing inside it makes your next estimate credible
Run the requirements workshop
Job-readyGetting eight people with different interests into a room and leaving with something buildable is the business analyst's defining skill, and it is almost entirely preparation. A workshop that starts with "so, what do you need?" produces a wish list. One that starts with a current-state map produces requirements, because people correct a picture far more readily than they describe a process from memory.
Prepare three things: the current process as you understand it, deliberately including a step you are unsure about; the specific decisions you need made by the end; and who has authority over each of them. That last point is what stops the workshop ending in agreement that evaporates the following week — if the person who can say no was not there, nothing was decided.
In the room, your job is to make disagreement visible rather than to smooth it. Two people using the same word differently is the single most expensive thing you can miss, and it surfaces only when you ask each to define it. Write decisions on the wall as they are made, read them back at the end, and send them the same day — a decision nobody wrote down was not a decision.
Syntax
Workshop prep — invoice approval redesign
BEFORE
Current-state map drawn and printed (with one step marked "?"
on purpose — people correct a picture faster than they describe one)
Decisions needed:
D1 approval threshold below which no finance sign-off is required
D2 who approves when the manager is on leave
D3 does the mobile case matter for v1, yes or no
Authority: D1 = Finance Director (INVITED, must attend)
D2 = Ops Manager D3 = Product Owner
IN THE ROOM
Walk the map. Ask "what actually happens here?" not "is this right?"
When two people use "approved" differently — STOP. Define it.
Finance: "approved" = posted to the ledger
Ops: "approved" = manager clicked yes
-> that single word was two requirements
AFTER (same day, or it did not happen)
Decisions + owner + date. Open questions with a name against each.
"No decision reached on D2" is a valid and useful outcome.Key points
- Bring a current-state map, not a blank page. People correct a picture accurately and describe a process badly.
- Confirm who has authority over each decision before you invite anyone. Without them the workshop produces agreement, not decisions.
- Chase the word two people define differently. It is usually two requirements wearing one label, and it is the most expensive thing to discover late.
Practice challenge
In a workshop, Finance says an invoice is 'approved' when it posts to the ledger. Operations says it is 'approved' when the manager clicks yes. Nobody notices. Say what this costs if it goes undetected, how you surface it in the room, and what you write down.
Cost: two different requirements get built as one. It surfaces in testing or in production, when finance reports an approved invoice that was never posted - and fixing it then costs many times more than the two minutes it takes now.
Surface it: stop and ask each person to define the word out loud. Do not paraphrase for them; the difference only appears in their own words.
Write: two distinct states with distinct names - 'manager-approved' and 'posted to ledger' - plus who owns each transition, and get both parties to confirm the split before moving on.Cost if missed: ______
How to surface it: ______
What you write: ______Show a hint
- The expensive failure is that everyone agrees in the room
- The fix is not a better word; it is admitting there are two states
Check yourself
1. Why bring a current-state map to an elicitation workshop?
Show answer
B. People correct a picture more accurately than they describe a process
2. Two stakeholders use "approved" differently. You should:
Show answer
B. Stop and have each define it
3. A decision that was agreed but never written down is:
Show answer
B. Not a decision
Stakeholders: who decides, who blocks, who is loud
BasicsMost requirements failures are not analysis failures, they are the wrong people in the room. The person who talks most in a workshop is frequently not the person who decides, and the person who can stop the project at the end is frequently not in the workshop at all. So the first task on any piece of work is to map who these people actually are: who signs off, who does the work the change affects, who controls a dependency, and who has a veto that only appears late — legal, security, compliance, procurement.
Two axes are enough to make this useful: how much a person is affected, and how much power they have over the outcome. High power and high interest is who you work with continuously. High power and low interest — a finance director whose approval you need once — must be kept informed enough to say yes quickly, and is exactly the person who derails a launch when a first contact happens in week ten. Low power and high interest are usually the people who do the work daily; they know where the process really breaks and they are chronically under-consulted.
The single most valuable question in this map is who can say no, because that names your real constraints. Ask it explicitly and early: who has to approve this, and has anything like it been rejected before? Then get decisions in writing from the person entitled to make them, because verbal agreement in a meeting is remembered differently by everyone present, and an unrecorded decision is one that will be relitigated at the worst moment.
Syntax
// MAP BEFORE YOU ELICIT. The loudest voice is rarely the decider.
//
// HIGH POWER
// keep satisfied | manage closely
// (finance dir: | (product owner,
// approves once, | ops lead:
// derails late) | work with daily)
// ----------------+------------------ HIGH INTEREST ->
// monitor | keep informed
// (adjacent teams)| (the people who do
// | the work; know where
// | it actually breaks)
// LOW POWER
// FOR EACH PERSON, WRITE DOWN:
// what they need from this
// what they are afraid of <- drives objections
// what they can approve or block
// how they want to be kept informed
// THE QUESTION THAT SAVES PROJECTS, ASKED IN WEEK ONE:
// "Who has to approve this before it ships,
// and has anything like it been rejected before?"
//
// Late-appearing vetoes: legal, security, compliance,
// procurement, data protection, works council.
// They are never in the kickoff and always in week ten.
// RECORD DECISIONS IN WRITING
// who decided | what | when | why | what was rejected
// Verbal agreement is remembered differently by everyone
// present, and gets relitigated at the worst possible moment.Key points
- Map power against interest. The high-power, low-interest approver who is contacted first in week ten is the classic cause of a late derailment.
- Ask who can say no, in week one. Legal, security, compliance and procurement hold vetoes and are rarely invited to a kickoff.
- Record every decision with who made it and what was rejected. An unwritten agreement will be remembered differently and reopened when it is most expensive.
Practice challenge
On a payments change: the ops lead uses it daily, a finance director must approve spend once, a vocal project manager attends every meeting but decides nothing, and compliance has a veto nobody has mentioned. Place each on power/interest, say who most often derails a project like this, and write the question to ask in week one.
Ops lead: low power, high interest - keep informed; knows where the process actually breaks
Finance director: high power, low interest - keep satisfied; needs enough to say yes quickly
Project manager: low power, high interest despite being the loudest voice
Compliance: high power, low interest - a late-appearing veto, and the real risk here
Most likely to derail: the high-power low-interest approver contacted too late - compliance or finance in week ten
Week-one question: who has to approve this before it ships, and has anything like it been rejected before?Ops lead: ______
Finance director: ______
Project manager: ______
Compliance: ______
Most likely to derail: ______
Week-one question: ______Show a hint
- The loudest participant and the decision maker are frequently different people
- Legal, security, compliance and procurement are never at the kickoff
Check yourself
1. Which stakeholder most often derails a project late?
Show answer
B. A high-power, low-interest approver contacted too late
2. What question should be asked in week one?
Show answer
B. Who has to approve this, and has anything like it been rejected before?
3. Why record decisions in writing?
Show answer
B. Verbal agreement is remembered differently and gets relitigated later
Stories and acceptance criteria a developer can build from
Working levelA user story is a placeholder for a conversation, not a specification, and its value is that it states who wants something and why. The 'so that' clause is the part most often dropped and the most useful, because it names the outcome and therefore permits a better solution than the one requested. 'As an ops lead I want to export to CSV so that I can reconcile against the courier invoice' invites the observation that an in-product reconciliation might serve better than an export — a conversation the sentence 'add a CSV export button' forecloses entirely.
Acceptance criteria are where ambiguity is actually removed, and they must be testable. 'The report should be fast' is not a criterion because two reasonable people will disagree about whether it was met; 'the report renders within three seconds for a store with 100,000 orders' can be checked and either passes or does not. Writing them in given-when-then form is a useful discipline mainly because it forces you to state the starting condition, which is where the unexamined assumption usually hides.
The criteria that get skipped are the ones that generate the bugs. Happy paths are easy and everybody writes them; the value you add is in the empty state, the error state, permissions, and the boundaries. What does this show when there is no data at all? What happens when the export fails halfway? Who is allowed to see it? What about exactly zero, exactly one, and the maximum? Slicing stories thin enough to be finished in days rather than weeks is what keeps all of this honest, because a story that takes a month has usually hidden several decisions nobody has made.
Syntax
// STORY -- the "so that" is the part that earns its place
// As an ops lead
// I want to export reconciled orders to CSV
// so that I can match them against the courier invoice
//
// The outcome is reconciliation, not CSV. Naming it invites
// "should we reconcile in-product instead?" -- a conversation
// "add an export button" makes impossible.
// ACCEPTANCE CRITERIA MUST BE TESTABLE
// NOT: "the report should be fast" (who decides?)
// YES: "renders within 3s for a store with 100,000 orders"
//
// Given a store with orders in the selected range
// When the user selects a date range and clicks Export
// Then a CSV downloads containing one row per order
// And the totals match the on-screen summary exactly
// THE CRITERIA PEOPLE SKIP ARE WHERE THE BUGS LIVE
// EMPTY: no orders in range -> what is shown?
// ERROR: export fails halfway -> partial file? a message?
// PERMISSIONS: who may export? does it respect row-level access?
// BOUNDARIES: exactly 0, exactly 1, the maximum allowed
// CONCURRENCY: two exports at once?
// SCALE: 500,000 rows -- still a synchronous download?
// SLICE THIN
// "Export orders" (a month) hides several undecided questions.
// "Export current page as CSV" (two days) surfaces them
// immediately, while they are still cheap to answer.Key points
- The 'so that' clause names the outcome and permits a better solution than the one requested. Dropping it turns a conversation into an order.
- A criterion that two reasonable people can disagree about is not a criterion. Put a number and a condition on it so it can be checked.
- Empty, error, permission and boundary cases are where the defects come from. Happy paths write themselves; these are the analyst's contribution.
Practice challenge
A stakeholder asks for a CSV export button on the orders screen. Write the story including the 'so that' clause, one testable acceptance criterion in given/when/then, and the four non-happy-path criteria that are usually skipped.
Story: As an ops lead, I want to export reconciled orders to CSV, so that I can match them against the courier invoice
(the outcome is reconciliation - which invites asking whether in-product reconciliation would serve better than an export)
Criterion: Given a store with orders in the selected range, When the user selects a date range and clicks Export, Then a CSV downloads with one row per order and totals matching the on-screen summary exactly
Skipped cases: 1 empty - no orders in range 2 error - export fails halfway 3 permissions - who may export, and does it respect row-level access 4 boundaries - exactly 0, exactly 1, and the maximum row countStory: As a ______, I want ______, so that ______
Criterion: Given ______ When ______ Then ______
Skipped cases: 1 ______ 2 ______ 3 ______ 4 ______Show a hint
- The 'so that' names the outcome and permits a better solution
- The happy path writes itself; the other four are the analyst's contribution
Check yourself
1. Why does the 'so that' clause matter?
Show answer
B. It names the outcome, which permits a better solution than the one requested
2. Which is a testable acceptance criterion?
Show answer
B. The report renders within 3 seconds for 100,000 orders
3. Which cases most often generate defects?
Show answer
B. Empty, error, permission and boundary cases
Asking the database the right question
AdvancedAn analyst who can get their own numbers is far more effective than one who queues for them, and the skill needed is smaller than people assume. Most of it is knowing what to ask for and how to check that the answer is credible. Before writing anything, establish the grain — what does one row of this table represent — because a question about orders answered from a table of order lines returns a number several times too large, and it will look entirely reasonable.
The specific hazards are few and they repeat. A join that multiplies rows when the key is not unique, which inflates every sum downstream. An inner join that silently drops unmatched rows, so a total shrinks with nothing to indicate it did. NULLs, which are excluded by both WHERE clauses and aggregates in ways that are correct and surprising — COUNT(column) ignores NULLs while COUNT(*) does not, so the two disagree and both are right. And soft deletes, where a status column marks rows as cancelled and every query that omits the filter counts them anyway.
The habit that makes the difference is sanity-checking before reporting. Does the total roughly match a number the business already trusts? Is the row count in the range you expected? If you group by a category, do the parts sum to the whole? A five-minute check against a known figure catches the join that doubled everything, and it is far cheaper than being corrected in the meeting. When a number does disagree with an existing report, that gap is usually a definition difference — different date field, different status filter — and finding it is genuinely useful work rather than an embarrassment.
Syntax
-- ESTABLISH THE GRAIN FIRST. What is one row?
SELECT COUNT(*) AS rows, COUNT(DISTINCT order_id) AS orders
FROM order_lines;
-- 412,880 rows | 138,204 orders <- ~3 lines per order.
-- Counting rows here answers a question about LINES, not orders.
-- SOFT DELETES: the filter everyone forgets
SELECT status, COUNT(*) FROM orders GROUP BY 1;
-- completed 120k | cancelled 14k | test 300
-- Every query without a status filter includes all of these.
-- NULL behaves differently, correctly, and surprisingly
SELECT COUNT(*) AS all_rows, -- 138,204
COUNT(customer_id) AS with_customer, -- 137,900 (NULLs ignored)
SUM(amount) AS total -- NULLs skipped
FROM orders;
-- WHERE region != 'West' also EXCLUDES rows where region IS NULL
-- CHECK THE JOIN DID NOT MULTIPLY
SELECT COUNT(*) FROM orders; -- 138,204
SELECT COUNT(*) FROM orders o
JOIN customers c ON c.id = o.customer_id; -- 141,050 <- why?
SELECT id FROM customers GROUP BY id HAVING COUNT(*) > 1; -- duplicates
-- SANITY CHECK BEFORE YOU REPORT
-- does the total roughly match a number finance already trusts?
-- do the grouped parts sum to the whole?
-- is the row count in the range you expected?
--
-- Disagreeing with an existing report is usually a DEFINITION
-- difference (order date vs ship date, which statuses count).
-- Finding it is the useful work, not an embarrassment.Key points
- Establish what one row represents before writing the query. Counting rows in an order-lines table answers a question about lines, not orders.
- Check the row count before and after a join. Duplicate keys multiply rows and inflate every total, and the result still looks plausible.
- Sanity-check against a number the business already trusts. When yours disagrees, the cause is usually a definition difference worth naming explicitly.
Practice challenge
You report 412,880 orders from order_lines. Finance says it is about 138,000. Explain the discrepancy, name two other filters commonly missing from a query like this, and say what to do when your number disagrees with an existing report.
Discrepancy: order_lines has one row per LINE, not per order. COUNT(*) counted lines; COUNT(DISTINCT order_id) is about 138,000 at roughly 3 lines per order.
Missing filter 1: soft deletes - cancelled and test rows are still in the table and counted unless excluded by status
Missing filter 2: NULL handling - WHERE region != 'West' also excludes rows where region IS NULL, which is correct and surprising
When numbers disagree: it is usually a definition difference (order date vs ship date, which statuses count). Find and name it - that is useful work, not an embarrassment.Discrepancy because: ______
Missing filter 1: ______
Missing filter 2: ______
When numbers disagree: ______Show a hint
- Establish what one row represents before writing anything
- Sanity-check against a figure the business already trusts
Check yourself
1. A table has 412,880 rows and 138,204 distinct order_ids. What does COUNT(*) tell you?
Show answer
B. The number of order lines, not orders
2. Row count rose after an inner join. What is the likely cause?
Show answer
B. Duplicate keys on one side multiplied rows
3. Does WHERE region != 'West' include rows where region IS NULL?
Show answer
B. No — NULL comparisons are not true, so those rows are excluded
UAT, sign-off and the change that arrives late
Job-readyUser acceptance testing asks a different question from the testing that came before it. Development testing asks whether the software does what was specified; UAT asks whether it does what the business actually needs, in a real process, with real data. Which is why it must be run by the people who do the work rather than by the project team, and why a UAT that consists of the analyst demonstrating the feature is not a test at all — it confirms the thing works the way its builder expects.
Good UAT is prepared, not improvised. Write scenarios from real business processes end to end rather than feature by feature, because the defects that matter appear at the handovers between features. Use production-like data, since problems with volume, edge cases and messy real values never appear against ten tidy test records. Define in advance what counts as a pass and what severity blocks release, so the argument about whether an issue is a blocker happens before anyone is under launch pressure and not during.
Late change is inevitable and the response to it is what separates a controlled project from a chaotic one. Every change has a cost — in effort, in schedule, and in what will not be built instead — and the analyst's job is to make that visible so the decision is made by whoever owns the trade-off rather than absorbed silently by the team. That means writing down what is affected, what it displaces and what the alternative is, and having the named person choose. And when a change is accepted, the requirement and its acceptance criteria are updated too, because documentation that no longer matches the system is worse than none: people trust it and are wrong.
Syntax
// UAT ASKS A DIFFERENT QUESTION
// dev/QA: does it do what was specified?
// UAT: does it do what the business actually needs,
// in a real process, with real data?
// -> run by the PEOPLE WHO DO THE WORK, not the project team.
// A demo by the analyst proves it works as its builder expects.
// PREPARE IT
// scenarios = whole business processes, end to end
// "Receive a courier invoice, reconcile it, flag disputes,
// export the summary, close the period"
// NOT feature-by-feature -- defects live at the handovers.
// Production-LIKE data: volume and mess, not 10 tidy rows.
// Agree severities BEFORE testing starts:
// blocker cannot complete the process -> no release
// major workaround exists -> release with a fix date
// minor cosmetic -> backlog
// Deciding severity under launch pressure never goes well.
// LATE CHANGE: make the cost VISIBLE, then let the owner choose
// what it affects (requirement, criteria, test, training)
// what it costs (effort + schedule)
// WHAT IT DISPLACES <- the part usually left unsaid
// the alternative (defer to phase 2? partial version?)
// -> named decision maker chooses. Not the team, silently.
// WHEN A CHANGE IS ACCEPTED, UPDATE THE REQUIREMENT AND ITS
// ACCEPTANCE CRITERIA TOO. Documentation that no longer matches
// the system is worse than none: people trust it and are wrong.
// SIGN-OFF: who signed, what they accepted, what is deferred
// and by when. "Approved" alone is not a record of anything.Key points
- UAT must be executed by the people who do the work, against realistic data and whole processes. A demonstration by the project team tests nothing.
- Agree severity definitions before testing begins, so what counts as a blocker is settled outside the pressure of a launch date.
- Make the displacement cost of a late change explicit and let the named owner decide. Absorbing it silently is how a schedule fails without any decision being taken.
Practice challenge
Two days before release a stakeholder asks for one extra field on the export, calling it small. UAT has not started and severities were never agreed. Write the four things to record about the change, say who decides, and name what must be updated if it is accepted. Then say who should execute UAT and why a project-team demo is not a test.
Record: 1 what it affects (requirement, criteria, tests, training) 2 what it costs in effort and schedule 3 what it displaces from the plan 4 the alternative (defer to phase 2, or a partial version)
Who decides: the named owner of the trade-off, not the team absorbing it silently
If accepted, also update: the requirement and its acceptance criteria, plus the UAT scenario - documentation that no longer matches the system is worse than none, because people trust it and are wrong
Who runs UAT: the people who do the work, with production-like data, because a demo by the project team only confirms it behaves as its builder expects
(Also: agree severity definitions now, before testing, not under launch pressure)Record: 1 ______ 2 ______ 3 ______ 4 ______
Who decides: ______
If accepted, also update: ______
Who runs UAT: ______ because ______Show a hint
- The displacement cost is the part usually left unsaid
- Several small changes absorbed quietly are how a date slips with no decision anyone can point to
Check yourself
1. Who should execute UAT?
Show answer
B. The people who do the work in the real process
2. When should severity definitions be agreed?
Show answer
B. Before testing starts, away from launch pressure
3. What is most often left unsaid about a late change?
Show answer
B. What it displaces from the plan
Common questions
Do I need any background to start Business Analysis?
No. This track begins at its own beginning and assumes nothing, and the first lesson explains what the thing is before showing you any syntax.
How long does the Business Analysis track take?
About 135 minutes of reading across 8 lessons, plus the practice challenges and 24 multiple-choice questions, which is where the time actually goes.
Is it free?
Yes, and there is no account. Everything runs in your browser.
More: all 15 tracks · what employers actually ask for · the full syllabus