I used to dread writing BRDs. Not because the thinking was hard — I know how to structure requirements. The problem was time. A solid BRD for a mid-sized project took me the better part of two days. Back-and-forth with the client to pin down what they actually wanted. Chasing edge cases. Making sure the dev team had enough detail to build from. And then something always got missed, and we caught it halfway through development.
A few months ago I started using Claude Code for BRDs. Not to replace my judgment — I still make every decision. But Claude handles the first draft, the gap-checking, and the formatting. Now I have a solid BRD draft in about 20 minutes. This post shows exactly how I do it, using a real project called ClientHub as the example throughout.
ClientHub is a client portal web app: agencies manage projects, clients log in to approve deliverables and raise change requests, and developers track their assigned tasks. Features include authentication, role-based access, a project dashboard, a deliverable approval workflow, commenting, invoicing, and email notifications. We will use this same project as the running example across all 10 posts in this series.
What Is a BRD and Why Does It Matter?
A Business Requirements Document (BRD) captures what needs to be built and why. It is not a technical specification — that comes later in the Functional Requirements Document. The BRD is the agreement between the business and the delivery team about what success looks like.
Your project manager reads it to track scope. Your client signs off on it. Your lead developer reads it to understand priorities. Your designer reads it to understand the users. Four different people. One document.
Skip the BRD and you will pay for it later. I have seen projects where no one wrote a BRD and everyone assumed they were aligned. They were not. The developer built what was technically impressive. The PM built what the brief said. The client expected what they had
imagined. Three different things. The BRD is the document that makes all three people look at the same picture.
The 8 Sections Every BRD Must Have
A BRD does not need to be 40 pages. Most of mine are 8 to 12 pages. What it does need is complete coverage across these eight areas:
- Project Overview
One paragraph. What are you building, who is it for, and why does it exist? No jargon. If someone new joined today and read only this section, they should understand the mission. - Business Goals and Success Metrics
What does success look like in six months? List three to five measurable goals. “Users can approve deliverables without calling the PM” is a business goal. “Reduce PM admin time by 30%” is a success metric. Both belong here. - Target Users
Who actually uses this? Not everyone. List your user types with a one-sentence description of each. For ClientHub: Agency Project Manager, Client Stakeholder, and Developer. - Scope — In and Out
Explicitly list what is included and what is not. “Out of scope: mobile app, payment processing, third-party integrations.” This section alone prevents most scope creep conversations. - Functional Requirements (High-Level)
What must the system do? Keep these brief at the BRD level — one sentence per requirement. You will expand them in the Functional Requirements Document later. - Non-Functional Requirements
Performance, security, accessibility, browser support. “The dashboard must load in under two seconds on a standard 4G connection.” These get forgotten and then become
late-stage arguments. - Assumptions and Constraints
What are you assuming to be true? What limitations exist? Budget, timeline, existing infrastructure, third-party dependencies. Write these down before they surprise you. - Timeline and Milestones
High-level only. Phase 1, Phase 2, go-live date. This gives everyone a shared sense of pace and helps the client understand what they are getting when.
Setting Up Claude Code for This Task
Claude Code runs in your terminal. Install it from the Anthropic documentation (docs.anthropic.com), then open a terminal in your project folder and type claude to start a session.
The key to getting a strong BRD from Claude is giving it good context upfront. Do not just say “write me a BRD.” Tell it what you are building, who is involved, and what you know so far. The more context you give, the less you have to correct. Here is the context-setting prompt I use at the start of every BRD session:
PROMPT 1 – Context Setting
You are helping me write a Business Requirements Document (BRD) for a new software project. Here is what I know so far:
Project name: ClientHub
What it does: A client portal web app where agencies manage projects, clients approve deliverables and raise change requests,
and developers track their assigned tasks.
Key user types:
- Agency Project Manager: creates projects, manages team, communicates with clients
- Client Stakeholder: views progress, approves or rejects deliverables, raises change requests
- Developer: views assigned tasks, marks progress, uploads deliverables
Before you write anything, ask me the clarifying questions you need to write a strong BRD. Focus on anything that would affect scope, user flows, or business goals.
Notice I am not asking Claude to write the BRD yet. I am asking it to ask me questions first. This is important. Claude will surface assumptions and gaps you have not thought of. For ClientHub, it came back with eight questions. Two of them changed how I scoped the notification system entirely.
The Step-by-Step Prompting Workflow
Once context is set and you have answered Claude’s clarifying questions, work through the BRD one section at a time. Do not ask for the whole document at once — you will get something generic. Ask for one section, review it, refine it, then move on.
Step 1 — Project Overview
PROMPT 2 – Project Overview
Write the Project Overview section of the BRD. Keep it to one paragraph, no jargon.
It should be clear enough for a non-technical client to read and immediately understand what we are building and why.Claude’s output for ClientHub was usable on the first try. I made one edit: it used the word “leverage,” which I always cut. That is the level of editing a well-prompted output needs.
Step 2 — Business Goals and Success Metrics
PROMPT 3 – Business Goals
Write the Business Goals and Success Metrics section.
Include 4 business goals, each with 2 measurable success metrics. Goals must be outcome-focused, not feature-focused.
Good: "Reduce client-PM back-and-forth by centralising feedback in one place." Bad: "Build a dashboard."Here is an excerpt of what Claude produced for ClientHub. This is close to what I would have written myself — and it took 15 seconds:
| Example Output: Business Goals Section – ClientHub BRD |
| Eliminate email as the primary channel for project updates Metric A: 90% of client feedback submitted through the portal within 3 months of launch. Metric B: Average deliverable approval time reduced from 48h to 24h Give clients real-time visibility into project progress without PM involvement Metric A: Client logins average 3+ times per week per active project Metric B: PM time spent on status communications reduced by 40% Create an audit trail for all project decisions and approvals Metric A: Every deliverable approval recorded with timestamp and user ID Metric B: 100% of change requests formally logged in the system Enable agencies to manage multiple client projects from one workspace Metric A: Average PM manages 5+ simultaneous active projects Metric B: Project setup time from creation to first deliverable under 10 min |
I kept this almost exactly as Claude wrote it. I reworded one metric and added a note about how we would actually measure the PM time reduction. The rest was ready to paste into the document.
Step 3 — Scope
The scope section is where I always ask Claude to be strict. The out-of-scope list matters just as much as the in-scope list:
PROMPT 4 – Scope
Write the Scope section with two parts: In-Scope and Out-of-Scope. Be specific and conservative about what is in scope.
List at least 5 items that are explicitly out of scope. Include things a client might reasonably assume are included, such as: mobile apps, payment processing, time tracking, third-party API integrations.
For ClientHub, Claude added “automated invoice generation” and “resource scheduling” to the out-of-scope list — both things I would have forgotten to exclude explicitly. That kind of catch is worth the whole exercise.
Step 4 — Gap Check
Once the main sections are drafted, run a gap check. This is the most valuable thing Claude can do in the whole BRD process:
PROMPT 5 – Gap Check
Review the BRD we have written so far. Tell me:
1. Any business goals that do not have supporting functional requirements
2. Any functional requirements that do not connect to a stated business goal
3. Any user type whose needs are not addressed in the requirements
4. Any non-functional requirements that are missing given the users and goals we have described
Do not rewrite anything yet. Just list the gaps.For ClientHub, Claude flagged three things I had missed: (1) no notification requirements, despite the goals referencing real-time visibility; (2) no mention of how a developer gets assigned to a project; and (3) no accessibility requirement even though client stakeholders were listed as users. All three were legitimate gaps. None of them would have made it into a BRD I wrote from scratch.
Step 5 — Export the BRD
Once you are happy with the content, ask Claude to compile the full document and save it. In Claude Code, you can write directly to a file in your project:
PROMPT 6 – Export
Compile the complete BRD for ClientHub based on everything we have discussed. Format it cleanly in Markdown with proper headers and section numbers.
Save it as docs/ClientHub-BRD-v1.md in the current project folder.Claude Code writes the file directly to your project folder. From there, you can convert it to Word, share it on Confluence, or export it as a PDF for client review. Post 5 in this series covers the Confluence step in detail.
Tips for Better BRD Prompts
Give business context, not feature lists.
Do not say “I want a login page.” Say “Users need to access their own project data securely, and different user types should see different views.” Claude produces far better requirements when it understands the why behind a feature
Ask Claude to flag its assumptions.
Add “list any assumptions you are making” to your prompts. Claude will surface things like “I am assuming email is the primary notification channel” — and sometimes it is wrong. Better to catch that in the BRD than in the FRD.
Work section by section, not all at once.
A prompt that says “write the entire BRD” produces something generic. Section by section gives you quality. The full prompting and review process takes about 45 minutes, which is still 75% faster than writing from scratch.
Use your existing documents as context.
If you have meeting notes, a brief, or an old proposal, paste it into Claude’s context at the start. The more real information it has, the more specific and accurate the output will be.
Read the out-of-scope list with a sceptic’s eye.
After Claude generates the scope section, go through the out-of-scope list and ask yourself: “Would my client assume this is included?” If yes, it either needs a spec or an explicit exclusion with a brief explanation of why.
Wrapping Up
The BRD you create in this session is not the final document, it is a strong first draft that you will refine with client feedback and share with your team. But getting to that strong first draft in 20 minutes rather than two days changes how you work. You spend that saved time on decisions that actually need your judgment.
Every section we covered today like business goals, scope, non-functional requirements, gap checking, etc feeds directly into the next post. Next post takes this ClientHub BRD and turns it into a full Functional Requirements Document. That is where the real detail lives, and where Claude does some of its most useful work.