BA Foundation: master the stakeholder map and requirements doc everything inherits

Your team already has the stakeholder-map and requirements-doc playbooks — the worked recipes for building each document, step by step. This module is the layer above the recipe. It’s where you master the two files every other piece of BA work inherits, build them for a real initiative, and prove — against a real rubric — that you can.

It’s Module 1 of the certifiable Business Analyst track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.

Every requirement your team builds from, every business case that gets funded, every backlog item an engineer picks up — is a withdrawal from two accounts: who actually owns this decision and what was actually asked for. Most BAs never fund those accounts fully, so requirements gathering starts from whoever’s in the room and loudest, and half the “requirements” are really just impressions. The foundation is the two hours where you fund both accounts properly, and it’s the highest-leverage time in the whole track.

Why the foundation is the highest-leverage hour you’ll spend

Requirements work fails quietly, the same way analysis and messaging fail quietly. Nobody ships a requirements doc that says “we’re not sure who wants this.” They ship one that reads clean and confident — numbered, tidy, ready to hand to engineering — built on a stakeholder list that was never actually mapped, tracing to needs nobody confirmed. The document looks authoritative. It just isn’t, and the gap only surfaces in week six, when the “approved” scope turns out to have been approved by someone who was never actually Accountable, or a requirement everyone assumed was settled turns out to have been one BA’s best guess at what a quiet stakeholder probably meant.

Two documents prevent both failure modes, in order. A stakeholder map answers who’s actually in this — who decides, who does the work, who must be consulted, who just needs to be told — and forces exactly one named Accountable owner per real decision, so “who approved this?” never has more than one honest answer. A requirements doc answers what’s actually being built — background, scope boundary, functional and non-functional requirements, open questions — with every single line traced back to the named stakeholder whose need it satisfies. Build the map first, then the doc, and everything downstream — gap analysis, options analysis, the business case, the user-story backlog, requirements-to-signoff, the exec briefing — inherits both: a gap analysis measures reality against requirements that already have real owners; a business case doesn’t have to guess who signs the check; a user story traces cleanly back to the actual person who asked for it.

Skip this and Claude just helps you produce a polished-looking requirements doc faster — which is worse, because polish reads as confidence, and confidence with no traceability is how a team builds the wrong thing well. Fund the two accounts first and everything downstream gets both faster and safer for free.

Mastering the stakeholder map — the judgment the recipe can’t teach

The playbook gives you the steps: list everyone, score influence and interest, build the RACI. Mastery is the judgment inside those steps — the calls a junior BA gets wrong and a senior one doesn’t.

• Accountable is not “the most senior person in the room.” The instinct is to name whoever has the most authority generally, or whoever spoke the most in the kickoff. The actual test is narrower: who, specifically, can say yes or no to this decision and make it stick? A VP who delegates the call to a director is not Accountable for that decision — the director is, and naming the VP instead just means the sign-off you get later isn’t the one that actually holds. Ask “if this goes wrong, whose name is on the decision” — that’s Accountable, not “who’s the most important person invited.”
• Loud is not the same as Accountable, or even Consulted. Every initiative has a stakeholder who emails the most, shows up to every meeting, and has strong opinions on every detail — and sometimes that person has real authority, and sometimes they’re just engaged. Score influence and interest independently and honestly: a loud, low-influence stakeholder still gets heard (often as Informed or Consulted), but naming them Accountable because they’re persistent is how a requirements doc ends up optimizing for the wrong person’s preferences.
• A stakeholder who won’t engage is a flag, not a blank you fill in yourself. When someone doesn’t respond to interview requests, gives vague non-answers, or is simply hard to reach, the temptation is to write down what they’d probably say and move on — the deadline doesn’t care that Legal hasn’t replied. Resist it. Mark their need as an open gap in the map, chase it through their manager or a second contact if you have to, and if the initiative genuinely can’t wait, proceed with the gap named explicitly rather than silently assumed away. An acknowledged unknown is recoverable; a confidently invented need that turns out wrong is a requirement built on a lie nobody told on purpose.
• The high-influence, low-interest stakeholder is the one that bites you in week six. They won’t chase you for updates because they don’t care yet — until the thing that was quietly out of scope turns out to be exactly what they cared about, and then they care a great deal, at the worst possible time. Flagging this group explicitly (the playbook’s step two) is not a nice-to-have; it’s the single highest-value thing a stakeholder map does that a plain contact list doesn’t.

Mastering the requirements doc — traceability is the whole discipline

Here’s the test most requirements docs fail: pick any requirement at random and ask “who asked for this, in their own words, and where’s that documented?” If the answer is a name and a quote or a clear paraphrase, the doc works. If the answer is “well, it seemed like something we’d need,” the doc is a list of plausible-sounding sentences — and plausible is not the same as agreed.

A requirements doc that holds up is traceable by construction, not by afterthought:

• Every requirement names its source stakeholder — not “the business.” “FR-04: The system shall allow managers to approve expenses over $500” is a sentence. “FR-04: The system shall allow managers to approve expenses over $500 — traced to Aisha Rahman (Finance), who needs approval authority to stay with budget owners” is a requirement. The difference is whether a skeptical reader six months from now can find the person who’d confirm it’s still wanted.
• Flagged is not failed. When a requirement is drafted from a general impression rather than something a specific person said, that’s normal — interviews are messy and gaps happen — but it has to stay visibly flagged until a real stakeholder confirms it, not get quietly folded in as settled because it reads fine. The flag is the mechanism that keeps “plausible” from becoming “agreed” by default.
• Non-functional requirements need the same discipline, doubled. Nobody volunteers “the response time should be under two seconds” in an interview unless asked directly, so these categories get skipped constantly — and an invented number here is worse than an honest gap, because a fabricated performance target reads as a real constraint to the engineer who builds against it.
• The out-of-scope list is the requirement that prevents the most disputes. A vague or missing out-of-scope section means every stakeholder fills in the gap with their own assumption, and the dispute always resurfaces at sign-off, never earlier. Make it as specific and deliberate as the in-scope list — it’s doing just as much work.
• One canonical file, one revision log. The moment a requirement can be quietly edited in someone’s copy without a record, traceability is theoretically intact and practically dead. A dated revision log — what changed, who approved it — is what keeps a requirement changeable only on purpose and on the record.

The Arabic foundation — bilingual stakeholders, authored not translated

For a BA working with an Arabic-speaking stakeholder group, this is not a translation pass run over the finished English doc. It’s a parallel discipline, and skipping it produces the same failure the English doc is built to prevent: a requirement a stakeholder can’t actually read closely enough to confirm or correct.

• Interview in the language the stakeholder thinks in. A stakeholder interview conducted in a stakeholder’s second language routinely produces a thinner, more hedged answer than the same conversation in their own — not because they know less, but because nuance is the first casualty of a language gap. If your Arabic-speaking stakeholders are more precise in Arabic, interview in Arabic, and let Claude help you draft the notes bilingually rather than forcing the conversation into English first.
• Author the Arabic requirements doc from the interview, not from the English draft. A requirements-ar.md translated from requirements.md carries English sentence structure and reads like a translated memo — exactly the tell that makes a stakeholder skim instead of read closely. Write it from the same source notes, in the register the stakeholder group actually reads, the same way you’d write the English version from scratch.
• Traceability survives translation only if you check it did. Have Claude verify that every requirement in the Arabic doc still names the same stakeholder and traces to the same interview quote as its English counterpart — a subtly drifted paraphrase in translation is how “the system shall notify the customer” quietly becomes a different, softer commitment in the other language.
• Numbers and technical terms stay Western; the sign-off gate stays the same. Currency and figures stay in Western numerals; a term like RACI or a system name stays in English inside the Arabic prose. And the Arabic requirements doc clears the exact same stakeholder sign-off as the English one — the failure mode to design against is a second-language document skipping review because nobody on the approval chain reads it closely.

Done this way, an Arabic-speaking stakeholder group gets a requirements doc they can actually interrogate and sign off on with real confidence — which is the entire point of writing one down at all.

Your assignment

Build the two foundation documents for one real initiative — your own (recommended: the output is the actual artifact your stakeholders sign off on) or the sample brand Mizan, a GCC bookkeeping SaaS whose newly hired Business Analyst, Noor Al-Suwaidi, runs throughout this track. Open the folder with your raw notes in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.

Module 1 deliverable — the BA foundation

1. stakeholder-map.md  (one page)
   - the full roster — every person or group connected, not pre-filtered
   - influence/interest scored high/medium/low, with the high-influence/
     low-interest group flagged explicitly
   - one sentence per stakeholder on what they specifically need
   - a RACI table across the initiative's key decisions — exactly one
     Accountable name per decision
   - a named gap list for anything still unconfirmed

2. requirements.md  (one to two pages)
   - a background paragraph and an explicit in-scope / out-of-scope split
   - functional requirements, each traced to a named stakeholder and
     their actual words
   - non-functional requirements (performance, security, compliance,
     usability), with honest gaps flagged rather than invented
   - a prioritized open-questions list, each with a named owner to chase
   - a revision log at the top

Bilingual stakeholder groups: add requirements-ar.md, authored from the
Arabic interview notes — not translated from the English file.

The Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank page.

How it’s graded — the rubric

This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your two files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.

Foundation rubric

1. Every requirement traces      No requirement rests on a general
   to a name                     impression left unflagged. Each names
                                 a real stakeholder and their actual
                                 words, or is visibly flagged as
                                 unconfirmed.

2. Exactly one Accountable       Every key decision in the RACI has one
   per decision                  — not zero, not two — named Accountable
                                 owner. Loud-but-not-Accountable
                                 stakeholders are correctly placed
                                 elsewhere in the RACI.

3. High-influence/low-interest   This group is explicitly identified in
   stakeholders are flagged      the map, not buried inside the general
                                 roster.

4. The document fits the        Background, in-scope/out-of-scope,
   canonical schema              functional + non-functional requirements,
                                 open questions with owners, a revision
                                 log. Nothing missing, nothing invented
                                 to fill a gap.

5. Arabic register is right     The Arabic requirements doc is authored
   (bilingual stakeholders)     from source notes, not translated; every
                                 requirement still traces to the same
                                 stakeholder and quote as the English
                                 version.

The discipline is deliberately what a skeptical delivery lead would demand: an unconfirmed Accountable name, an untraced requirement, or a fuzzy scope line fails quietly on every downstream document — so it has to be caught here.

The bar, shown — a worked model answer (Mizan)

You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample brand — your own doesn’t need to look like this, it needs to clear the same bar. These are Noor Al-Suwaidi’s documents, Mizan’s newly hired Business Analyst, built the week co-founder Dana Al-Qassimi asked her to run the formal requirements process for a customer-facing “dispute a charge” feature — the product safeguard Dana specced in direct response to the March 1 double-billing incident, now needing proper sign-off across Support, Finance, Data, and Engineering before a line of code gets written.

stakeholder-map.md — "Dispute a charge" (excerpt)

Roster (initial pass, unfiltered):
  Layla Al-Nasser    CX Lead, Support — owns the team that will triage
                     every dispute raised through the new flow.
  Youssef Hamdan     Finance Analyst — owns reconciliation; disputes
                     touch the same ledger the March 1 incident hit.
  Maya Haddad        Business Analyst, Data — already root-caused the
                     March 1 bug; holds the affected-customer list.
  Bilal Al-Mansouri  Engineering — owns the billing module the feature
                     will be built into.
  Dana Al-Qassimi    Co-founder, Head of Product — sponsor; specced the
                     safeguard in response to the incident.

Influence / interest / need:
  Layla Al-Nasser     High / High.  Needs disputes visible in one queue
                      with the customer and amount, so agents don't
                      search tickets manually.
  Youssef Hamdan      High / Medium.  Needs a disputed charge tagged
                      distinctly from a refund in the ledger, so it
                      doesn't silently distort the monthly close.
                      FLAGGED: high influence, medium interest — won't
                      chase for updates, but will block sign-off on the
                      ledger-tagging requirement if it's wrong.
  Bilal Al-Mansouri   High / High.  Needs the edge cases (already
                      refunded, already closed in finance) decided
                      before he estimates the build.
  Dana Al-Qassimi     High / High.  Needs the v1 scope to stay to the
                      core flow — no scope creep into a full disputes
                      case-management system.

RACI (key decisions):
  Decision                          R              A               C                    I
  Final v1 scope                    Noor           Dana            Layla, Bilal         Youssef
  Ledger-tagging logic              Noor           Youssef         Bilal                Layla
  Support queue design              Noor           Layla           Bilal                Dana
  Go-live date                      Bilal          Dana            Layla, Youssef       Maya

Gap list: none unconfirmed — all four Accountable names confirmed
directly with each owner before this map was circulated.

requirements.md — "Dispute a charge" (excerpt)

Background
  Following the March 1 double-billing incident (11 customers
  overcharged AED 300–1,200), Dana Al-Qassimi requested a formal,
  cross-team requirements process for a self-serve "dispute a charge"
  feature, rather than a one-off patch — this touches Support, Finance,
  Data, and Engineering and needs proper sign-off before any build.

In scope
  - A customer-facing control to flag a specific charge as disputed
  - A single queue where Support sees all flagged charges with
    customer and amount
  - Ledger tagging that keeps a disputed charge distinct from a refund

Out of scope (v1)
  - Automated refund processing — a human still approves every refund
  - A general case-management system for non-billing disputes
  - Retroactively re-flagging charges from before this feature ships

FR-01  The system shall let a customer flag any charge on their
       account as disputed.
       Traced to: Layla Al-Nasser (Support) — "half our March tickets
       were customers with no way to say 'this looks wrong' except
       emailing us."

FR-02  The system shall prevent a charge from being flagged twice —
       a second attempt shows the existing "Flagged" state.
       Traced to: Bilal Al-Mansouri (Engineering) — raised during
       scoping as an obvious duplicate-state risk.

FR-03  The system shall tag a disputed charge distinctly from a refund
       in the ledger, and shall not alter the charge amount until
       Finance resolves it.
       Traced to: Youssef Hamdan (Finance) — "March 1 taught us that a
       silent adjustment to the ledger is how a reconciliation takes
       twice as long."

NFR-01 Disputes must appear in the Support queue within 60 seconds of
       being flagged.
       Traced to: Layla Al-Nasser — no formal SLA given; flagged as an
       open question, not invented as a hard number.

Open questions (prioritized)
  1. What's the SLA for Support to respond to a flagged dispute? —
     owner: Layla Al-Nasser. Blocks: queue design sign-off.
  2. Does a disputed charge pause any dunning/collection workflow on
     that invoice? — owner: Youssef Hamdan. Blocks: FR-03 sign-off.
  3. Does flagging require a reason code, or free text only? — owner:
     Bilal Al-Mansouri. Blocks: v1 estimate.

Revision log
  2026-07-01  v0.1  Drafted from stakeholder interviews.  Noor Al-Suwaidi.

What you’ve proven — and what’s next

Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade stakeholder map and requirements doc and demonstrated the judgment behind them. That’s the Foundation stage of “Certified Business Analyst with Claude.”

From here the track turns the foundation into a full requirements-to-delivery operation, each module assessed the same way:

• Module 2 — gap analysis & options: measuring the as-is process against these requirements, and weighing solutions with a real business case.
• Module 3 — the backlog & sign-off, Module 4 — the exec briefing, Module 5 — SWOT, risk & the operating discipline, then the capstone — a complete initiative taken from stakeholder map to signed-off delivery, graded into the certificate.

First, make what you built reusable. Grab the Foundation toolkit — the BA CLAUDE.md and the two templates that turn the documents you just wrote into files your whole team installs and inherits. And if you’re rolling this across a team, the operating guide is the safety and sign-off layer that goes underneath all of it.