AI for Business Analysts

1 Step 1: Start with the Data Rules

BA work is full of sensitive material: client names, contracts, customer data, and commercial terms. Before using AI on any of it, read Step 5 of LLM Prompting & AI Security. In short:

• Never paste customer or tenant data, production exports, personal data, or credentials into any AI tool.
• Client documents, internal notes, and requirements go only into studio-approved tools, signed in with your studio account.
• Replace real names and figures with placeholders (CLIENT_A, TENANT_1) when the exact values don't matter.

2 Step 2: Turn Meeting Notes into Requirements

Paste your raw notes or a transcript (sanitized) and ask for a structured summary. The most valuable part is usually the list of open questions, the things nobody actually decided.

You are a business analyst on a multi-tenant SaaS product.
Below are my notes from a requirements meeting with CLIENT_A.

Produce:
1. Decisions made (only things explicitly agreed)
2. Requirements, each as one sentence starting "The system must..."
3. Open questions and ambiguities, with who should answer each
4. Action items with owners

Rules: don't add requirements that aren't in the notes. If something is
unclear, list it under open questions instead of guessing.

<notes>
...paste sanitized notes here...
</notes>

Send the summary back to the attendees to confirm. The AI can only reorganize what's in the notes, so anything left unsaid in the meeting is still missing.

3 Step 3: Draft User Stories and Acceptance Criteria

Turn the requirement below into user stories for our GitHub issues.

For each story:
- "As a <role>, I want <capability>, so that <benefit>."
- 3-6 acceptance criteria in Given / When / Then form, each testable
- An "Out of scope" list
- Edge cases to confirm with the client (time zones, permissions,
  empty states, limits, trial vs paid tenants)

Keep each story small enough for one developer to finish in a few days.
Flag any story that seems too large and suggest how to split it.

<requirement>
Tenant admins must be able to set when unpaid invoices become overdue.
</requirement>

Review every criterion against what was agreed, and cut anything the client didn't ask for. Then file the stories using the format in Writing Good Issues & Using Labels.

4 Step 4: Generate Test Cases from Acceptance Criteria

AI is good at finding the cases people forget, such as boundaries and invalid input. Ask for a table you can paste into your test plan:

Write manual test cases for the acceptance criteria below.
Return a Markdown table with columns:
ID | Criterion | Preconditions | Steps | Expected result | Type
where Type is one of: happy path, boundary, negative, permission.

Include for each criterion at least one boundary case (e.g. exactly
0, 90, and 91 days) and one negative case.

<criteria>
...paste acceptance criteria...
</criteria>

5 Step 5: Summarize Changes for Stakeholders

Pull requests are written for developers. With the GitHub CLI or Claude Code (see Claude Code & GitHub CLI Setup), you can turn them into summaries for clients and managers:

gh pr view 123                                                   # one pull request's description
gh pr list --state merged --base Dev --search "merged:>=2026-10-01" --limit 100   # everything merged since a date

Below is a list of pull requests merged this sprint. Write a summary
for non-technical client stakeholders:
- Group by user-facing feature, not by pull request
- Plain language, no code or internal system names
- Call out anything users must do differently
- Leave out internal refactors, tests, and tooling changes
- Under 250 words

<pull_requests>
...paste the list...
</pull_requests>

Check each statement against the acceptance criteria you verified (see Step 7 of Conducting Effective Code Reviews). Never tell a client something shipped based only on an AI summary.

6 Step 6: Draft Process Documents and Diagrams

• Process flows: "Write this approval process as a Mermaid flowchart." GitHub renders Mermaid diagrams in issues and Markdown files.
• Gap analysis: "Compare the current process and the proposed process below. List what changes for each role."
• Rewriting for an audience: "Rewrite this technical explanation for a finance manager, in under 150 words."
• Reviewing your own writing: "List any requirement below that is ambiguous, untestable, or contradicts another one."

7 Step 7: Check Everything Before It Leaves Your Desk

1. Trace every requirement to a source: a meeting, a client email, a signed-off document. Delete anything the AI added that you can't trace.
2. Check numbers, dates, and names against the original. Models confidently change "30 days" to "31 days" or swap two client names.
3. Get sign-off from the people who own the decision. AI drafts; stakeholders decide.
4. Mark drafts as drafts until they're reviewed, so nobody builds from an unconfirmed requirement.