How is this different from a full BRD or a PRD?

It's the lightweight core of a BRD — background, scope, functional and non-functional requirements, open questions — built fast enough to produce in one sitting per round of interviews, but disciplined enough on traceability (every requirement names its stakeholder) that it can be extended into a fuller BRD or handed to product for a PRD without redoing the groundwork. It's the what, not a finished spec ready for engineering.

What happens if a requirement can't be traced to a named stakeholder?

It stays flagged, not deleted and not quietly waved through. Claude surfaces it as ungrounded specifically so you can chase down the real person it should trace to — a general impression from the notes is not the same as a stakeholder need, and this doc's entire value is that distinction being enforced every time.

Do I need the stakeholder map before I can start this?

It makes the traceability step far faster and more accurate — you're tracing to names and roles you've already scored, not guessing at them mid-draft. You can start without it, but every requirement will still need a named owner eventually, so build stakeholder-map.md first if you can.

Who approves changes to requirements.md once it's built?

The Accountable stakeholders named in your RACI, not the BA alone and not Claude. Treat any post-signoff change as a reviewed, logged update — the revision log at the top exists precisely so a requirement can only change deliberately and on the record, which is what requirements-to-signoff formalizes downstream.

Build the requirements doc every downstream playbook inherits

when to reach for this

Every BA has lived the same failure: three interviews produce three sets of half-written notes, someone builds from memory, and what ships satisfies nobody because no one wrote down what was actually asked for or who asked for it. The fix is a requirements doc — a lightweight BRD with one canonical structure: background, what's in and out of scope, functional and non-functional requirements each traced to a named stakeholder need, and the open questions still unresolved. Build it once and every other BA playbook gets sharper, because 'what we're building' finally points at one document. This is the what; gap analysis, options analysis, the business case, the user-story backlog, requirements-to-signoff, and the exec briefing are all the how and the so what that build on it.

gather this first

Your raw interview notes, meeting transcripts, or a messy recap of a conversation with stakeholders — pasted text or files, however rough.
The stakeholder-map.md from mapping stakeholders (if you've built it) — every requirement here needs a named owner from that map, so bring it if it exists.
Any existing scope statement, project charter, or kickoff deck, even a rough one, so Claude reconciles against what's already been agreed instead of starting blind.

the workflow

Extract the background and draft the scope boundary

Open the folder with your interview notes in Claude Desktop and ask in the chat — no terminal needed. Before any requirements, nail the boundary: why this initiative exists, and what's explicitly in and out. A fuzzy scope line is the single biggest cause of later disputes.

you ask

Read these interview notes and any kickoff materials. Draft a background section (why this initiative exists, what problem it solves, in 3-4 sentences) and a scope boundary: a bulleted in-scope list and a bulleted out-of-scope list. Where the notes are ambiguous about whether something is in scope, don't guess — list it under 'needs a scope decision' instead.

what you get back A tight background paragraph plus two clean lists — in-scope and out-of-scope — with an honest third list of scope calls that still need a real decision. That third list is often the most valuable output of the whole session.

Resist letting Claude resolve scope ambiguity on its own. An invented scope boundary is exactly the kind of plausible-but-not-agreed output this doc exists to prevent.
Draft functional requirements — each traced to a named stakeholder need

Turn the notes into functional requirements: what the solution must actually do. The traceability is not optional — every single requirement carries the name of the stakeholder (from your stakeholder map) whose need it satisfies.

you ask

From these notes and stakeholder-map.md, draft the functional requirements — what the solution must do, one requirement per line, each phrased as 'the system/process shall...'. For every requirement, name the specific stakeholder whose need it traces to, quoting or paraphrasing what they actually said. Flag any requirement you drafted from a general impression rather than something a named stakeholder specifically said.

what you get back A numbered functional-requirements list where every row reads like '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', with the ungrounded ones flagged separately.

A flagged requirement isn't wrong — it just hasn't been confirmed by anyone yet. Chase down a real stakeholder for it before it goes into the doc as settled.
Draft non-functional requirements and the constraints

Functional requirements say what it does; non-functional requirements say how well — performance, security, compliance, usability, availability. These get missed constantly because no one asks about them in an interview unless prompted.

you ask

From the same notes, draft non-functional requirements: performance expectations, security or compliance constraints, usability needs, availability/uptime expectations, and any data-handling rules mentioned. Where the notes don't cover an obvious non-functional category, don't invent a number — flag it as an open question for the right stakeholder (e.g. 'no response-time expectation was mentioned — confirm with Ops').

what you get back A short non-functional list plus an honest set of flagged gaps — the categories nobody addressed in the interviews yet, named so someone can go ask rather than silently defaulting to an assumption.
Compile the open questions — the unresolved list, not a hidden one

Every requirements effort surfaces things nobody has answered yet. Naming them explicitly, with an owner to chase, is what keeps them from being quietly assumed away.

you ask

Review everything drafted so far and compile a single open-questions list: every scope call, requirement, or non-functional item still unresolved, each with the specific stakeholder (by name, from stakeholder-map.md) who needs to answer it. Order the list by how much it blocks downstream work — the questions that block scope sign-off first.

what you get back A prioritized open-questions list — each one naming a real person to go ask, not a rhetorical question left dangling in the doc.

This list is a feature, not a defect. A requirements doc with zero open questions after one round of interviews is usually one that quietly assumed its way past real ambiguity.
Assemble the one canonical requirements.md

Pull everything into one file, ordered and skimmable. This is the document every downstream BA playbook — gap analysis, options analysis, the business case, the user-story backlog, requirements-to-signoff, the exec briefing — reads from, so it needs a stable, predictable structure.

you ask

Assemble everything into one requirements.md: background, in-scope/out-of-scope, functional requirements (each traced to a stakeholder), non-functional requirements, and the open-questions list with owners. Add a short revision log at the top (date, what changed, who approved) so changes are deliberate, not silent. Keep each requirement to one line where possible so the whole doc stays scannable.

what you get back A single, paste-ready requirements.md — the source of truth every gap analysis, business case, backlog, and sign-off inherits, with a revision log so a requirement can only change on the record.

Save this file at the root of your project folder. From here on, every downstream playbook's first question — 'what did we actually agree to build?' — has one answer: point at requirements.md.

make it your own

Feeds the whole stage-2/3 path: gap analysis measures the as-is process against these requirements; options analysis and the business case evaluate solutions against them; the user-story backlog decomposes the functional requirements into stories; requirements-to-signoff formalizes approval of this exact document; the exec briefing summarizes it upward.
Cross-reference the process map: if the initiative touches an existing workflow, run Turn interview notes into a clear as-is process map alongside this — the pain points it surfaces often become non-functional requirements or scope-boundary decisions here.
Make it a reusable skill (Power Track): load requirements.md as a reusable skill or a /traceback command so any later draft — a story, a test case, a briefing slide — gets checked against the agreed requirements automatically (see the Features tab).
Version on real change only: re-run a step when a stakeholder genuinely changes their need — don't silently edit a requirement's trace; bump the revision log so anyone building from it knows it changed and why.

watch out for

A requirement with no named stakeholder is not a requirement — it's a guess. The traceability is the whole guardrail: if Claude drafted it from a general impression rather than something a specific person said, it stays flagged until a real stakeholder confirms it, and it does not proceed to build.
"Plausible" is not "agreed". Claude can draft a coherent-sounding requirements doc from thin notes, but coherence isn't consensus — every functional and non-functional requirement needs actual stakeholder sign-off, not just internal consistency, before gap analysis or the business case builds on top of it.
Non-functional requirements are the ones everyone forgets to ask about. If performance, security, or compliance constraints aren't in the notes, don't let a plausible-sounding default slip in unflagged — an invented uptime number is worse than an honest 'not yet specified.'
Scope creep starts with a fuzzy out-of-scope line. If 'out of scope' isn't explicit and specific, every stakeholder will read the gap differently, and the dispute resurfaces at the worst possible time — usually right before sign-off.

you'll end up with A single `requirements.md` — background, scope boundary, functional and non-functional requirements each traced to a named stakeholder, and a prioritized open-questions list — that every downstream BA playbook, from gap analysis through the exec briefing, inherits as the one agreed record of what's being built and for whom.

Questions people ask

How is this different from a full BRD or a PRD?: It's the lightweight core of a BRD — background, scope, functional and non-functional requirements, open questions — built fast enough to produce in one sitting per round of interviews, but disciplined enough on traceability (every requirement names its stakeholder) that it can be extended into a fuller BRD or handed to product for a PRD without redoing the groundwork. It's the *what*, not a finished spec ready for engineering.
What happens if a requirement can't be traced to a named stakeholder?: It stays flagged, not deleted and not quietly waved through. Claude surfaces it as ungrounded specifically so you can chase down the real person it should trace to — a general impression from the notes is not the same as a stakeholder need, and this doc's entire value is that distinction being enforced every time.
Do I need the stakeholder map before I can start this?: It makes the traceability step far faster and more accurate — you're tracing to names and roles you've already scored, not guessing at them mid-draft. You can start without it, but every requirement will still need a named owner eventually, so build stakeholder-map.md first if you can.
Who approves changes to requirements.md once it's built?: The Accountable stakeholders named in your RACI, not the BA alone and not Claude. Treat any post-signoff change as a reviewed, logged update — the revision log at the top exists precisely so a requirement can only change deliberately and on the record, which is what requirements-to-signoff formalizes downstream.