SERIES: AI-POWERED DEV WORKFLOW · POST 3 OF 10
You have a BRD. You have an FRD. You think you are ready to hand things to the dev team. But here is the question nobody asks: are these two documents actually talking about the same project?
In theory, the FRD should cover everything in the BRD. Every business requirement should have a matching functional spec. But in practice, they drift. The BRD gets updated after the FRD is written. The FRD adds features the BRD never mentioned. Someone slips a business rule into the BRD that nobody turned into a spec. These gaps survive right up until a developer builds the wrong thing — or QA finds a feature that was never specced.
This post shows how to use Claude to cross-check your BRD and FRD, generate a traceability matrix, and fix gaps before they reach development. We are continuing with ClientHub.
Why Docs Fall Out of Alignment
In my experience, misalignment happens in one of three ways. The first is sequential drift: the BRD is written by the PM, handed to a developer to write the FRD, and nobody does a cross-check at the end. Two people, two documents, two slightly different mental models of the same project.
The second is late BRD changes. The client asks for something new after the FRD is already written. It goes into the BRD as a requirement, but nobody adds a functional spec for it. It just sits there, unsupported, until someone tries to build it.
The third is FRD scope creep. The developer writing the FRD adds features that make technical sense but were never in the BRD — no business justification, no client sign-off. Just extra complexity that the client did not ask for and the budget did not account for.
All three of these are fixable. The tool is a traceability matrix.
What “Aligned” Actually Means
Alignment means two things simultaneously:
Every BRD requirement has at least one matching FRD entry. If the BRD says “all user actions must be logged for compliance,” there should be a functional spec somewhere that describes exactly how that logging works, what gets logged, and where it is stored.
Every FRD feature traces back to a BRD requirement. If there is a functional spec for an admin reporting dashboard but no corresponding BRD requirement, either the BRD is missing something or the FRD has gone out of scope.
A traceability matrix is just a table that makes this visible. BRD requirement on one side, FRD section on the other, status in the middle. Once you can see it, you can fix it.
The Alignment Workflow with Claude
This is one of the faster things Claude can do for you. The whole process takes about 15 minutes once both documents exist.
Step 1 — Extract BRD Requirements
PROMPT 1 - Extract BRD Requirements
Read docs/ClientHub-BRD-v1.md.
List every distinct requirement from the BRD.
Number them (R1, R2, R3...) and write each one as a single clear sentence.
Do not summarise groups of requirements into one — keep them separate.Step 2 — Extract FRD Features
PROMPT 2 - Extract FRD Features
Now read docs/ClientHub-FRD-v1.md.
List every feature or functional area that has a spec.
Label them (F1, F2, F3...) and write one sentence describing each.Step 3 — Build the Traceability Matrix
PROMPT 3 - Build Traceability Matrix
Create a traceability matrix as a table with three columns:
Column 1: BRD Requirement (use the R-numbers from Step 1)
Column 2: Matching FRD Section (use F-numbers, or "None" if no match)
Column 3: Status — one of: Covered / Partial / GAP
Covered = FRD fully addresses the requirement
Partial = FRD mentions it but does not fully spec it
GAP = no FRD entry exists for this requirementStep 4 — Surface BRD Requirements with No FRD Coverage
PROMPT 4 - Surface Gaps
From the traceability matrix, list only the rows marked GAP or Partial.
For each gap, write one sentence explaining what is missing from the FRD.Step 5 — Check for Unanchored FRD Features
PROMPT 5 - Check for Unanchored FRD Features
Now check the other direction.
List any FRD features that do not map to a BRD requirement.
For each one, note whether it should be added to the BRD
or removed from the FRD.The ClientHub Traceability Matrix
Here is a condensed version of what Claude produced for ClientHub after running these five prompts. Eight requirements, two gaps found:
| BRD Requirement | FRD Section | Status |
|---|---|---|
| R1: Users must authenticate with email and password | F1: Authentication — Login Flow | Covered |
| R2: Role-based access (PM, Client, Developer, Admin) | F2: Authentication — Role System | Covered |
| R3: PM can create and manage projects | F3: Project Management | Covered |
| R4: Clients can approve or reject deliverables | F4: Deliverable Approval Workflow | Covered |
| R5: All user actions must be logged for compliance | None | GAP |
| R6: Email notifications for key project events | F5: Notification System | Covered |
| R7: PM can generate and send invoices to clients | F6: Invoicing | Partial |
| R8: Dashboard showing active projects and status | F7: Project Dashboard | Covered |
Two issues flagged. R5 is a clean gap — the BRD requires compliance logging, but there is no audit log spec anywhere in the FRD. R7 is partial — the FRD has an invoicing section, but it only covers invoice creation, not sending. The BRD said “generate and send.” Half of that requirement is unspecced.
Fixing the Gap: Audit Logging
R5 is a common one. It comes from a legal or compliance requirement that someone added to the BRD late, after the FRD was already drafted. It is vague in the BRD (“all user actions must be logged”) and completely absent in the FRD. Claude found it in 30 seconds. Writing the spec from scratch would have taken 20 minutes.
GAP FOUND — R5: Compliance Audit Logging
The BRD requires that all user actions are logged for compliance purposes. The FRD has no audit log specification. There is no defined data model, no list of what events should be captured, no retention policy, and no spec for who can access the logs.
Once the gap is identified, ask Claude to write the missing spec:
PROMPT 6 - Write Missing FRD Entry
Write a full FRD entry for the Audit Logging feature.
Context from the BRD: "All user actions must be logged for compliance."
Use the standard FRD structure:
- Feature Description
- Events to log (be specific — what user actions count?)
- Data captured per event (who, what, when, from where)
- Retention policy
- Access control (who can view logs?)
- Edge cases
- DependenciesClaude Output: Audit Logging — Key Points from Generated FRD Entry
- Events to log: login, logout, failed login, project create/update/delete, deliverable upload/approve/reject, invoice create/send, role changes, user invite/deactivate, any admin action
- Data per event: user ID, user role, timestamp (UTC), action type, affected resource ID, IP address, session token (hashed)
- Retention: logs retained for 7 years (standard compliance minimum); logs are append-only — no edit or delete permitted
- Access: Admin role only; no client or developer access to audit logs
- Dependencies: centralised logging service; all API actions must emit a log event before returning a response to the client
That output took one prompt. It is not perfect — I added the “7 years” retention figure from our actual compliance requirement, and I changed “before returning a response” to a note about async logging to avoid blocking API calls. But the structure was right and all the important fields were there.
When to Fix the FRD vs When to Cut from the BRD
Not every gap means the FRD is wrong. Sometimes the BRD is wrong. Here is the decision rule I use:
Fix the FRD when the BRD requirement came from a real business goal and the client or stakeholders would notice if it was missing. Compliance logging is a good example — there is a legal reason behind that requirement and skipping it has real consequences.
Update the BRD when the requirement was aspirational and nobody has a strong reason to keep it in scope. If you find a BRD requirement that your client has not mentioned in three meetings and your PM cannot explain the business case for, it probably belongs in a future phase, not this one.
When in doubt, ask Claude to help you frame the decision:
PROMPT 7 - Gap Decision Helper
The BRD has a requirement: "All user actions must be logged for compliance."
The FRD has no spec for this.
Help me decide: should I add an audit log spec to the FRD,
or move this requirement to a future phase in the BRD?
Consider: what is the risk of shipping without it?
What would need to be true for this to be safe to defer?Claude will give you a clear assessment. For compliance logging, it flagged that deferring it means either retrofitting it later (expensive) or shipping without an audit trail (risky). That made the decision easy: add it to the FRD now.
What Is Next
After this step, the BRD and FRD are aligned. Every requirement has a spec. Every spec has a business reason. That is the point where you can confidently hand these documents to a client for review.
Which is exactly what Post 4 covers: how to use Claude to create a client-friendly summary of your documents, handle change requests without rewriting everything from scratch, and get a formal sign-off before development starts.
Next in this series: Post 4 — Getting Client Sign-Off: Finalize Design + Docs with Claude’s Help
Got questions? Drop them in the comments — I read every one.