What Business Analysts actually do.
Plain English. Real examples. No jargon until you need it — and when we use a term, we explain it immediately.
The one-sentence version
A Business Analyst figures out what a business actually needs, writes it down clearly, and makes sure the right thing gets built.
What BAs actually produce at work
Not vague "strategy documents." Specific, practical outputs that developers, testers, and stakeholders use every day.
User Stories
A short description of a feature written from the user's point of view. Always follows the same pattern:
I want to [do something],
so that [I get this benefit].
Real example:
I want to save my delivery address,
so that I don't have to re-enter it every time I order.
Acceptance Criteria (AC)
The conditions a feature must meet before it's considered done. Written so a tester can verify them — yes or no, pass or fail.
For the story above, the AC might be:
- The customer can save up to 3 delivery addresses
- Saved addresses appear in a dropdown at checkout
- The customer can delete a saved address at any time
- If no address is saved, the standard entry form appears
Notice: each one is specific, testable, and unambiguous. "It works properly" is not acceptance criteria.
Process Flows
Simple diagrams showing how a process works — what happens first, what decision is made, what happens next. You don't need expensive software. A whiteboard sketch is a process flow.
Stakeholder Interviews
Before writing any requirements, BAs talk to the people who will use or be affected by the system. These aren't casual chats — they're structured conversations designed to uncover the real need underneath the stated one.
The most important BA skill:
Asked once, it clarifies. Asked five times in a row, it uncovers requirements nobody knew existed.
Common BA pitfalls — good to know early
Adding features nobody asked for because they seem like good ideas. BAs document what's needed, not what's nice. "Nice to have" belongs in a separate list, clearly labelled.
"The system should respond quickly" is not acceptance criteria. "The system should respond within 3 seconds" is. If two people can interpret it differently — rewrite it.
The benefit clause in a user story ("so that...") is the most important part. It tells you why the feature exists. Without it, you can't make good trade-off decisions later.
When something is unclear, new BAs often fill the gap with an assumption instead of asking. The assumption feels faster. It almost always costs more time later.
Quick self-check — does BA fit you?
These aren't requirements — just signals worth noticing:
- You like turning messy ideas into clear plans
- Writing simple stories and clear conditions sounds satisfying
- You enjoy aligning different people around a shared understanding
- Sketching a quick diagram to explain something feels natural
- You ask "why?" more than most people around you
You don't need all five. Two or three is enough to explore further.