What is a business requirements document?
A Business Requirements Document, or BRD, explains the business problem, goals, scope, options, recommendation, risks, assumptions, and approval request. In SAGE, Gate A approves BRD Part A.
Gate A — Initiation Gate.
Gate A approves the BRD (Business Requirements Document, Part A). It sits inside the Assess phase, after the pre-Gate-A BEARINGS cluster (E · A · R · I) and before the post-Gate-A cluster begins.
What Gate A approves
Lock business scope and value. Gate A is the first "should we do this?" decision the program makes on paper, with an approver's signature. Before Gate A the program is exploring; after Gate A the program is committed to the recommended option and moves into planning the delivery.
The artifact under review is the BRD (Business Requirements Document, Part A). It is the business requirements document template SAGE uses to connect the problem, causes, stakeholders, goals, options, scorecard recommendation, risks, assumptions, and requested approval. Gate A should make it clear whether the organization is funding the recommended path, holding for more evidence, or declining the program.
BRD Part A structure — the SAGE approach to a business requirements document
A business requirements document template can become bloated when it tries to describe the entire delivery plan too early. SAGE keeps Gate A focused on the business decision. The BRD Part A structure explains what problem is worth solving, why it matters, which causes must change, who is around the work, what measurable goal is being claimed, which options were considered, and why the recommended option deserves approval.
The first section of the BRD comes from B Baseline: Scope and Roots. Scope defines the current condition, affected population, impact, and evidence. Roots identifies causes that must change for the program to produce a durable result. Those two artifacts keep the BRD from becoming a solution pitch with a problem attached after the fact.
The next sections come from the pre-Gate-A BEARINGS cluster in Assess. Engagement names sponsors, approvers, influencers, operators, and affected groups. Aims turns the problem into measurable goals and KPIs. Routes compares options and trade-offs. Instrument records the Scorecard so the recommendation is traceable to criteria, weights, evidence, and judgement.
The final sections of the BRD make the decision request explicit: recommended option, decision needed, risks, assumptions, scope boundaries, expected benefit, required funding or capacity, and approval record. That is why the SAGE BRD template is useful even for teams that already have a business case format. It gives the business requirements document a direct path from evidence to decision.
A strong BRD also makes exclusions visible. Gate A should know what the recommendation does not solve, which stakeholder needs are deferred, which risks remain, and which assumptions must be validated before Gate B. That prevents the business requirements document from becoming a promise that the delivery plan cannot keep. It also gives the post-Gate-A BEARINGS work a sharper starting point.
The SAGE approach is intentionally different from a delivery specification. The BRD should not design every interface, test case, training artifact, or cutover step. Those belong in the FD and delivery planning. Gate A is concerned with whether the business case is worth continuing: problem, value, stakeholders, options, recommendation, risk, and approval.
Entry criteria
- All Scope artifacts complete: Scope and Roots.
- BRD Part A drafted — problem, goals/KPIs, scope in/out, recommended option with rationale, key risks.
- Pre-Gate-A BEARINGS complete: Stakeholders, Goals, Options & scoring, and Scorecard.
Exit criteria
- BRD (Part A) signed and approved, with an evidence link captured.
- Options decided — including an explicit accept/reject on "do nothing."
- Initiation Gate approval record exists (who approved, when, on what).
Outputs
Authorization to proceed to FD drafting (Part B) and implementation planning — i.e., the post-Gate-A BEARINGS cluster (N · G · S). Navigation, Governance, and Signals begin after Gate A is approved.
How to write a SAGE BRD
- Capture Scope and Roots. Use B Baseline to define the evidenced problem and the causes that must change.
- Complete the pre-Gate-A BEARINGS artifacts. Complete Stakeholders, Goals, Options & scoring, and Scorecard so the business case has people, value, options, and recommendation logic.
- Draft the BRD Part A document. Write the problem, goals, scope boundaries, options, recommendation, risks, assumptions, and approval request.
- Circulate the pre-read. Send the BRD, artifact links, and decision request to the sponsor, PMO lead, and required reviewers before the gate review.
- Run the gate review. Review the recommendation, scorecard evidence, risks, unresolved assumptions, and requested decision.
- Capture decision and conditions. Record approval, rejection, hold, or conditional approval with named owners and dates.
- Move into post-Gate-A planning or close the request. If approved, move into Navigation, Governance, and Signals. If not approved, record the reason and required changes.
The business requirements document template should be drafted for decision quality, not document volume. A concise BRD with clear evidence, a visible Scorecard, and unresolved assumptions is stronger than a long document that hides the decision behind narrative.
When drafting, use links rather than duplication wherever possible. The BRD should point to Scope, Roots, Stakeholders, Goals, Options & scoring, and Scorecard as source artifacts. The document itself should summarize what an approver needs to decide and preserve the trace back to the source. That keeps the BRD readable while avoiding a second, stale copy of every artifact.
Who approves
PMO lead, with input from the accountable executive and business owner identified in Engagement.
Worked example — BRD for the onboarding program
The onboarding program starts with a Scope statement: standard customer onboarding takes 18 days against a target of 7, with the delay concentrated between application approval and account activation. Roots identifies the controllable cause: manual identity-check exceptions sit in an unmanaged shared mailbox with no service target, no owner, and no escalation path.
Engagement names the branch operations director as operating sponsor, risk as a required reviewer, store managers as adoption stakeholders, engineering as delivery owner for queue automation, and analytics as measurement owner. Aims sets the target: reduce standard-account onboarding cycle time from 18 days to 7 within two quarters of launch.
Routes compares policy simplification, queue automation, staffing changes, and a hybrid approach. Scorecard shows that a hybrid route has the best balance of value speed, implementation risk, and operational sustainability. The BRD then asks Gate A to approve the hybrid route, authorize post-Gate-A planning, and require risk review of exception automation before Gate B.
BRD vs FD and FRD
BRD, FD, and FRD are often used inconsistently across organizations, so Gate A needs clear boundaries. In SAGE, the BRD is the business requirements document approved at Gate A. It explains the business problem, value claim, options, recommendation, and approval request. The FD is the Gate B delivery document. It explains functional design, requirements, interfaces, rollout planning, testing expectations, and implementation readiness.
Some teams use FRD to mean functional requirements document. If that term exists in the organization, SAGE maps the functional requirements conversation to the Gate B FD rather than the Gate A BRD. That keeps business approval and delivery design from being mixed too early. Gate A should approve the business case; Gate B should approve the delivery plan.
Gate A quality bar
Gate A is ready when the approver can understand the problem, value claim, stakeholder authority, options, recommendation, risks, assumptions, and requested decision without a side conversation. The BRD should show why the recommended path is credible, what the organization is committing to, and what must be validated before the program moves deeper into planning.
If the business requirements document template is complete but the decision is still unclear, the gate is not ready. Approval should not depend on optimism or seniority. It should depend on evidence, ownership, and a visible path into the post-Gate-A BEARINGS work.
A strong Gate A record also protects the team after approval. When priorities shift, the BRD should let the program explain what was approved, why the option was selected, what benefit was expected, and what conditions were attached. That record prevents later arguments from turning into memory contests and gives Gate B a clean foundation for delivery planning.
The quality bar should be applied before the meeting, not discovered during it. If the BRD is missing evidence, unclear about decision authority, or vague about the recommendation, the program lead should resolve those gaps with the sponsor and reviewers first. Gate A is most useful when the meeting tests a clear decision request rather than finishing the analysis in real time.
That preparation also keeps the gate respectful of reviewer time. Reviewers should arrive to validate the decision, challenge the evidence, and set conditions, not to discover the basic shape of the request. The cleaner the pre-read, the more useful the gate, and the more reliable the decision record becomes after approval. That reliability is the point of the gate itself and its conditions.
BRD template (download)
Use the SAGE BRD template as a working business requirements document template for Gate A. It keeps the business case focused on evidence, options, recommendation, and approval.
FAQ
What is the difference between a BRD and an FD?
A BRD defines the business case and recommended path. An FD defines the delivery plan, requirements, interfaces, testing expectations, rollout model, and implementation detail reviewed at Gate B.
What is the difference between a BRD and an FRD?
Many teams use FRD to mean functional requirements document. SAGE uses FD for the Gate B delivery document and BRD for the Gate A business decision document.
Who approves a BRD?
In SAGE, Gate A is approved by the PMO lead with input from the accountable executive and business owner named in Engagement. The exact approval path can be tailored by governance rules.
How long should a BRD be?
A BRD should be long enough to support a real business decision and short enough for approvers to review. A focused SAGE BRD usually emphasizes evidence, options, recommendation, risks, and decision request.
What sections does a SAGE BRD have?
A SAGE BRD includes the problem, causes, stakeholders, goals, scope boundaries, options, scorecard recommendation, risks, assumptions, approvals, and evidence links.
When does a BRD fail Gate A?
A BRD fails Gate A when the problem is not evidenced, goals are not measurable, stakeholder authority is unclear, options are not compared, the recommendation is unsupported, or material assumptions remain unresolved.