Business Analyst
Turn a messy stakeholder conversation into a clean requirements doc, a mapped process, and a business case with options — all from the Claude Desktop chat, no terminal required.
Full worked systems, not one-off prompts — each walks the whole workflow end to end. Pick one and follow it.
Map every stakeholder before you write a single requirement
Turn a messy list of names into a stakeholder map — who cares, what they need, their influence and interest, and a RACI per key decision — so nothing proceeds without a named, accountable owner.
Build the requirements doc every downstream playbook inherits
Turn scattered stakeholder interview notes into one requirements doc — background, in-scope/out-of-scope, functional and non-functional requirements each traced to a named stakeholder need, and open questions — that every gap analysis, business case, backlog, and sign-off inherits.
Turn interview notes into a clear as-is process map
Turn scattered interview notes, screenshots, and a walkthrough into a clear as-is process map — step by step, who does what, with pain points and breakdowns flagged inline.
Find the gaps between today and the target state
Compare the current state against the future state in your requirements doc, and get every gap named with its root cause — not just a list of differences nobody can act on.
Turn scattered concerns into a SWOT and a living risk register
Turn a pile of half-formed worries and notes about an initiative into a structured SWOT and a risk register with likelihood, impact, owner, and mitigation for each risk — built to be revisited, not written once and shelved.
Compare solution options and land on one
Score 2-4 candidate solutions against the same criteria — cost, effort, risk, time-to-value — and get a defensible recommendation, not a pros/cons list nobody can act on.
Build the business case
Turn a requirements doc into a defensible cost-benefit case: quantified where you can, honest about what's a guess, with the payback math and the risks that could break it laid out for a named decision-maker.
Break requirements into a traceable backlog
Turn the requirements doc's functional requirements into epics and user stories with clear acceptance criteria — every story traced back to the specific requirement and stakeholder need it satisfies, so nothing in the backlog exists without a reason.
Turn workshop chaos into decisions, same day
Turn a messy workshop transcript — multiple stakeholders talking past each other, half-decisions, tangents — into a clean synthesis: decisions made, owners assigned, open questions, and next steps, sent before people forget what they agreed to.
Take requirements from draft to full sign-off
Draft the requirements doc from stakeholder input, circulate it, track who has and hasn't responded, resolve conflicting feedback, and land a version every named stakeholder has actually signed off on before build starts.
Compress an initiative into a two-minute exec briefing
Pull requirements, options considered, business case, current status, and risks into a one-page update a VP or steering committee can absorb in under two minutes.
Get certified: Business Analyst with Claude
The path above is free to explore. The Capability Track sequences it into assessed modules — you build the real artifacts for your own brand, get them graded against a rubric, and earn a verifiable certificate. Module 1 is a free sample.
Team-plan modules are free for a limited time — open while we’re in preview.
Explore the Capability Track →The non-negotiables before any of this ships. Read the operating guide for the full data, brand, legal, and rollout playbook.
- Every requirement traces to a named stakeholder need. Not "the business wants X" — who asked, in their own words, and what problem it solves for them. An untraceable requirement is the one that gets silently dropped or silently changed later.
- Nothing moves to build without a named, signed-off owner. A business case, a requirements doc, or a scope change is a draft until a real person's name is on the approval — Claude can produce the document in minutes, but it cannot produce the sign-off.
- "Nobody agreed to this" is the failure mode to design against. Before you circulate any
requirements-doc.mdorbusiness-case.md, ask Claude to list every claim and requirement with its source stakeholder — a blank next to any line is a gap to close before it ships, not after. - Strip names and sensitive detail before it goes in the chat. Stakeholder conversations often carry HR complaints, salary context, or customer PII in passing — keep that in a workspace your company approved, share only what the document needs, and approve each read in the 'Ask permissions' prompt.
- Separate the stated ask from the underlying need. Have Claude draft both explicitly (
stated askvs.likely need) in every requirements doc — a feature request is rarely the real problem, and conflating the two is how you build the wrong thing well. - Claude drafts the document; you run the room. Use it to turn notes into a clean requirements doc, process map, or options table fast — but reading the stakeholder, negotiating scope, and chasing the actual sign-off stay with you.
Questions people ask
- Is this different from a Data Analyst role?
- Yes — they're neighbors, not the same job. A Data Analyst answers questions with numbers: queries, dashboards, `SQL`. A Business Analyst sits between stakeholders and delivery: gathering requirements, mapping process, weighing options, and building the business case that gets a decision signed off. You'll use Claude for writing and structuring, not for statistics.
- Is it safe to put stakeholder conversations and notes into Claude?
- Treat it like any shared drive: fine for meeting notes, requirements drafts, and process maps. Strip names, salaries, or anything an HR or legal team would flag before it goes in, keep sensitive material in a workspace your company approved, and approve each read in the 'Ask permissions' prompt.
- Does this replace the BA's judgment?
- No. Claude drafts the requirements doc, the options table, and the exec summary fast — you still run the room, decide what a stakeholder actually meant, and chase the sign-off. The traceability is only real once a named owner agrees to it.
- What's a realistic first task?
- Take messy notes from one stakeholder conversation and ask Claude to turn them into a short requirements doc — the ask, the underlying need, and open questions. It's the keystone every other BA document builds from, and it takes ten minutes to see the difference.