Business Requirements Document
What the BRD a project generates prints, section by section, where each section is read from, what the executive summary and the sign-off page ask of the client, and how to render the copy the sponsor signs.
By the end of this page you will know what the business requirements document prints, which pages of the project each of its sections reads, how the executive summary comes to be, what the sign-off page asks of the client, and how to render the copy a sponsor puts their name to.
The business requirements document (BRD) is the client's document: what they need and why, in the record's own words, from the pages the business analyst filled during intake and planning. It is generated from the Documents page with the kind Business Requirements Document, numbered BRD #1, BRD #2 and so on within the project, and rendered as a PDF on A4 pages or as an HTML page. Nothing in it is typed twice: a change on the record is in the next render.
Who reads it
The sponsor and the stakeholders flagged as approving requirements, before the build starts; the project manager and the business analyst, as the agreed statement of what the project delivers; and, once it is final, every client guest of the project under Documents. The team's SRS is the other half of the same record, written for the people who build and test; a BRD never prints requirements by reference, data dictionaries or environments.
The cover
Every generated document opens with a cover: the title you gave, the kind, the project's name and key, the client, the document's reference and its version once it is final, when it was rendered and by whom, and the scope it was rendered from (the baseline's name and the date it was frozen, or the record as it stands, with a note when drafts were included). A footer on every page carries the project, the reference and the page number.
Section by section
| Section | What it prints | Read from |
|---|---|---|
| 1. Executive summary | The opening page, as written on the document or drafted by Heimdall; Not written yet. when empty. | The document's own opening page |
| 2. Business context | The project's description, then the client's name (legal name when recorded), industry and country, the methodology and the target launch. | Project settings, Clients |
| 3. Stakeholders | Name and title, role with the RACI letter, side, and which approvals they give (requirements, UAT, releases). | Stakeholders |
| 4. The people the product serves | Each persona with its role, tagline, goals and frustrations. | Personas |
| 5. Scope | Each epic in scope with its priority, summary, goal and business value, and under it a table of its stories (key, title, the As a… I want… so that… sentence, the acceptance criteria as a list, the priority). | Epics, Backlog, Acceptance criteria |
| 6. Business rules | Each rule with its key, kind, statement, the when and then, and its worked examples. | Business rules |
| 7. Glossary | Every term with its definition and the other names it goes by, in alphabetical order. | Glossary |
| 8. Risks, assumptions, issues and dependencies | Each RAID item with its key, kind, description, probability and impact where scored, mitigation and status. | RAID log |
| 9. Decisions | Each decision with its key, status, the date it was decided, what was decided and its consequences. | Decisions |
| 10. Sign-off | A sentence saying what approving the document confirms, then a signature table: one row per stakeholder flagged Approves requirements, and a row for the project manager, each with blank signature and date cells. | Stakeholders, the project's lead project manager |
A section with nothing to print says so in one line (No stakeholders recorded., No epics in scope yet.) rather than disappearing, so a reader sees what the record still lacks. A module the person who rendered the document may not open is left out entirely.
What is in scope, and what is not
Only records that carry a version, the approved ones, are printed: an epic or a story still in draft, a rule in review, a decision proposed and not yet accepted stay out. Include records still in draft on the editor prints them too, for a working copy the team reads before the record is approved. A document rendered from a frozen baseline prints exactly the epics, stories, rules and use cases that baseline holds, which is the copy a sponsor should sign: the scope they sign is the scope that was frozen, and a change to it afterwards goes through a change request.
Stories print under their epic
The scope section is organised by epic. A story without an epic is not printed in a BRD; put it under one, or leave it as the team's own item, since a BRD describes the scope the client recognises.
The executive summary
Heimdall drafts the executive summary when the field is empty and the project's AI assists are on, from an outline of exactly what the sections above will print: it names the client and what they need, what the project builds and for whom, what the document covers and how it is organised, and ends on what the sponsor is asked to do, which for a BRD is to read it and sign. It rests on the record alone and names no number, date or technology the outline does not carry. The draft is kept on the document for you to edit, and a summary you wrote is never touched; see how the opening page is drafted.
Render the copy the sponsor signs
- Approve the record first: the epics and stories, the rules, the decisions the client should see, each through its own approval.
- Compose a scope baseline from those records and have the project manager approve it, so it is frozen.
- On Documents, press Generate → Business Requirements Document, pick the baseline under What it reads, leave drafts off, write or leave the executive summary, and press Generate.
- Read the draft, edit the summary if the words are not the client's, and Save & Render Again.
- Submit for review from the approval bar; when the project manager approves, the copy is final and listed to the client's guests, who download it under Documents.
- Send the client the signed scope baseline for signature from the baseline's own approval bar; the document is the readable form of what they sign, and its sign-off table is for the paper copy.
Related
- Generated documents: generating, editing, rendering again, approving, superseding and deleting.
- Software requirements specification: the team's half of the record.
- Signing off the scope: the client's side of the baseline the BRD is rendered from.
How is this guide?
Last updated on
Generated Documents
Generate a business requirements document or a software requirements specification from the project's own record, edit the opening page Heimdall drafts, render it again, put it to the project manager, and share the final copy with the client.
Software Requirements Specification
What the SRS a project generates prints, section by section, where each section is read from, how the introduction is drafted, and how the team builds and tests against the final copy.