The BA Foundation toolkit: the files your team installs

You finished the Foundation module with two documents: a stakeholder-map.md and a requirements.md for your initiative. This toolkit makes them infrastructure. A file you wrote once helps you once; a file your team installs — that Claude reads on every task — helps every initiative, forever.

Everything here is copy-able. Replace the Mizan placeholders (the “dispute a charge” initiative from the module) with your own, save the files in the folder your team works in, and open it in Claude Desktop. From then on, every requirements task in that folder starts from your real stakeholders and agreed scope instead of each person’s guess.

The whole pack is three files and a handful of prompts. That’s the point — a foundation small enough to actually get installed beats a beautiful one that lives in a doc nobody opens.

The BA CLAUDE.md

This is the standing context Claude reads automatically when it opens your project folder, so nobody has to re-explain the initiative every chat. Keep it short and current — it points at the two foundation docs rather than repeating them.

# CLAUDE.md — [Initiative name] requirements

## Who we are
We're the BA function running requirements for [initiative — one line,
e.g. "a customer-facing dispute-a-charge feature touching Support,
Finance, Data, and Engineering"]. Stakeholders span [teams/roles].

## The two source-of-truth files — read these first
- stakeholder-map.md   → WHO is in this (roster, RACI, one Accountable
                         name per decision)
- requirements.md      → WHAT we're building (scope, functional +
                         non-functional requirements, each traced to a
                         named stakeholder)
- requirements-ar.md   → the Arabic requirements doc (authored, not
                         translated), where a stakeholder group needs it
Always read the relevant ones before drafting anything downstream. If a
draft conflicts with them, the files win — flag the conflict, don't
quietly override it.

## How we work with you
- You draft; a named stakeholder decides. Never invent what a
  stakeholder would say — if their need isn't confirmed, flag it as
  open, don't fill it in from a general impression.
- Ask before assuming. A guess dressed up as a requirement is the
  single most expensive mistake this file exists to prevent.
- The house rule: every requirement traces to a name. No exceptions —
  an untraceable line is a flag, not a finished requirement.

## What's safe in this folder
- Safe: interview notes with names of colleagues in their professional
  capacity, requirements drafts, process maps, aggregate metrics.
- Never here: customer PII beyond what a requirement needs to reference,
  salaries, HR complaints, anything under NDA. Tell me if a file looks
  like it contains them.

## House rules
- Every requirement, functional or non-functional, names its source
  stakeholder — or stays visibly flagged until it does.
- Every RACI decision has exactly one Accountable name, confirmed by
  that person, not assumed from a title.

On Desktop you create and edit this in the file pane — no commands. Anthropic’s docs call the “Ask permissions” mode the one recommended for new users; leave it on, and the first time Claude reads this file you’ll approve it in the prompt.

The stakeholder-map.md template

The map teams get wrong by scoring importance instead of influence and interest separately, and by naming Accountable by seniority instead of by who can actually make the call stick. This template forces both distinctions explicit.

# stakeholder-map.md — [Initiative]

## Roster (unfiltered — every person or group connected)
- [Name, role] — [one-line note on their connection to the initiative]
- [Name, role] — [...]
(List everyone before ranking anyone. The person you cut here is the
one who blocks sign-off later.)

## Influence / interest / need
| Stakeholder | Influence | Interest | What they specifically need |
|---|---|---|---|
| [Name] | High/Med/Low | High/Med/Low | [in their words, not assumed] |

⚠ High-influence / low-interest (flag explicitly — they won't chase you):
- [Name] — [why they matter even though they're quiet right now]

## RACI — one Accountable name per decision
| Decision | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| [e.g. final scope] | [name] | [ONE name] | [names] | [names] |
| [e.g. go-live date] | [name] | [ONE name] | [names] | [names] |

## Open gaps (not guesses)
- [Stakeholder] — [what's unconfirmed, and who's chasing it]

The requirements.md template

The document that makes traceability structural, not aspirational. The trace column is the discipline — a requirement without one doesn’t ship as settled.

# requirements.md — [Initiative]

## Revision log
| Date | Version | What changed | Approved by |
|---|---|---|---|

## Background
[3–4 sentences: why this initiative exists, what problem it solves,
what triggered it.]

## Scope
In scope:
- [...]
Out of scope:
- [...]  (be as specific here as in-scope — this is the line that
  prevents the most disputes)
Needs a scope decision (not yet resolved):
- [...]

## Functional requirements
FR-01  The system/process shall [...].
       Traced to: [Name, role] — "[what they actually said]"
FR-02  [...]
       ⚠ FLAGGED — drafted from general impression, not a named
       stakeholder. Confirm with: [who].

## Non-functional requirements
NFR-01 [performance / security / compliance / usability / availability]
       Traced to: [Name] — [...], or flagged as an open question if
       nobody addressed it in interviews.

## Open questions (prioritized — blockers first)
1. [Question] — owner: [Name]. Blocks: [what downstream work].
2. [...]

The saved-prompt library (Foundation)

The recurring foundation jobs, as prompts you reuse. Paste them in the chat with the right files open; on the Terminal & Automation track these become slash commands so they’re one keystroke, but you need none of that to use them today.

Draft a requirements doc from raw notes
  "Read these interview notes and stakeholder-map.md. Draft functional
   and non-functional requirements — one per line, each traced to the
   specific stakeholder whose need it satisfies, quoting or paraphrasing
   what they actually said. Flag any requirement drafted from a general
   impression rather than something a named person specifically said."

Spot untraced requirements
  "Read requirements.md. List every functional and non-functional
   requirement that has no named stakeholder trace, or whose trace is
   vague ('the business', 'users' — not a real name). For each, tell me
   exactly who I need to go confirm it with before this can be treated
   as settled."

Pressure-test the RACI
  "Read stakeholder-map.md. For every decision in the RACI, confirm
   there is exactly one Accountable name — flag any decision with zero,
   or more than one. Also flag any stakeholder scored high-influence but
   low-interest who isn't clearly named as a risk to watch."

Translate this for an Arabic-speaking stakeholder
  "Read requirements.md and these Arabic interview notes for [stakeholder
   group]. Author requirements-ar.md from the Arabic notes directly — not
   a translation of the English file — in a register this stakeholder
   group would read as native, and confirm every requirement still traces
   to the same person and quote as its English counterpart."

Close the gap list
  "Read the open-questions list in requirements.md and the gap list in
   stakeholder-map.md. Reorder both by how much they block downstream
   sign-off, and tell me, for each, exactly who I need to go ask —
   don't suggest an assumption to fill the gap instead."

Installing it (Desktop, no setup)

1. Save the three files — CLAUDE.md, stakeholder-map.md, requirements.md (plus requirements-ar.md for bilingual stakeholder groups) — in the folder your BA work lives in.
2. Open that folder in Claude Desktop and approve the read in the “Ask permissions” prompt.
3. Start any task by opening the relevant docs; the prompts above do the rest.

That’s the whole install. The foundation you built in the module is now shared infrastructure — and Module 2 of the track extends this same pack with the gap-analysis and options-analysis templates that build on it. If you’re rolling this across a team rather than for yourself, read the operating guide for the data-safety and sign-off layer that belongs underneath.