If you are preparing a business requirements document for a steering committee, an ICT governance board, or a senior sponsor group, you are not writing the same document you would hand to a development team. The structure, the language, and the level of detail are different. Your job right now is to produce something that gives decision-makers enough context to approve, redirect, or reject a course of action without drowning them in functional detail they did not ask for.
Here is a working template structure I have used on governance-level BRDs across government, utilities, and enterprise environments, along with the reasoning behind each section and a concrete example of where it got complicated.
What a High-Level BRD for an Executive Audience Actually Contains
A high-level BRD is not a stripped-down version of a detailed BRD. It is a different document with a different purpose. Where a detailed BRD answers the question "what exactly does the system need to do," a high-level BRD answers the question "why are we doing this, what do we need to achieve, and what are the boundaries of our commitment." If you conflate the two, you end up with a document that is too vague for delivery teams and too dense for governance audiences.
The sections below form the core of a template that works for executive and governance readers. Each section earns its place. None of them are filler.
1. Executive Summary
This sits at the top and is often the only section a time-poor board member reads in full. It should be no more than half a page. State the business problem or opportunity, the proposed response, the budget envelope, and the expected benefit. If you cannot summarise those four things in under 200 words, you do not yet understand the project well enough to write the document.
2. Business Context and Problem Statement
This section explains what is happening in the organisation that has created the need for this work. It covers current state pain, strategic alignment, and compliance or risk drivers. This is where you connect the project to something the executive audience already cares about, whether that is a regulatory deadline, a cost reduction target, or a known operational failure. I always reference the organisation’s own strategy language here wherever possible, because it makes the document feel like an answer to a question the board has already asked.
3. Objectives and Success Criteria
List the business objectives the project must achieve, not the system features it will deliver. Success criteria should be measurable. "Improve records compliance" is not a success criterion. "Achieve 95% of active records filed in the approved classification structure within 12 months of go-live" is. Governance bodies need to be able to evaluate whether the project succeeded, and that only works if success was defined at the outset.
4. Scope
Be explicit about both inclusions and exclusions. Governance audiences make funding and resourcing decisions based on scope. Ambiguous scope leads to scope creep, and scope creep leads to the kind of conversations that damage your credibility as a BA. If you are unsure how to frame this section, the article on scope creep governance for business analysts covers the framing in practical terms.
5. High-Level Business Requirements
This is the substantive requirements section, but it operates at capability level rather than system feature level. You are describing what the business needs to be able to do, not how a system will do it. Group requirements by business domain or capability area. Each requirement statement should be testable in principle and traceable to an objective. Aim for between eight and fifteen high-level requirements for a mid-sized project. More than that and you have probably slipped into functional requirements territory.
6. Constraints, Assumptions, and Dependencies
Constraints are non-negotiable limitations the solution must work within: budget ceilings, technology standards, regulatory requirements, timelines. Assumptions are things you have treated as true in order to write the document. Dependencies are external factors the project relies on. Governance boards need all three because they inform risk. I learnt early in my career that leaving assumptions implicit is how projects get approved on false premises.
7. Options Considered
This section is optional in a detailed BRD but often essential in a high-level one. Governance audiences want to know that the recommended approach was not the first idea someone had. A brief summary of options assessed, with the rationale for the preferred option, builds confidence. Keep it to a comparison table rather than lengthy prose.
8. Indicative Costs and Benefits
Executives need to connect requirements to value. Provide indicative cost ranges rather than precise figures at this stage, and pair them with the expected benefits. Be honest about confidence levels in your estimates. A number with a stated confidence range is more credible than a precise number with no caveats.
9. Recommended Next Steps
Close with a clear recommendation and an explicit request for a decision. State what you are asking the governance body to approve. "We are seeking approval to proceed to detailed requirements analysis, with a budget of $58,000 for a ten-week analysis phase" is the kind of sentence that gives a board something concrete to say yes or no to.
Template Section Comparison: High-Level BRD vs Detailed BRD
| Section | High-Level BRD (Executive) | Detailed BRD (Delivery) |
|---|---|---|
| Executive Summary | Always included, half a page maximum | Often omitted or minimal |
| Business Context | Strategic, links to organisational goals | Operational, links to process pain |
| Requirements | Capability level, 8 to 15 items | Feature level, often 50 or more items |
| Options Analysis | Usually included | Rarely included |
| Cost and Benefit | Indicative ranges with rationale | Detailed breakdown by workstream |
| Success Criteria | Outcome focused | Acceptance criteria focused |
| Constraints | Summarised | Detailed with traceability |
| Recommended Next Steps | Explicit decision request | Not typically included |
What to Watch Out For in Each Section
- Executive Summary written last: Always write it after you have completed the rest of the document, because only then do you know what the actual key messages are.
- Requirements that are really solutions: Watch for requirement statements that describe a system or technology rather than a business need. "The system shall use SharePoint" is a solution constraint, not a business requirement.
- Cost figures without assumptions: Any cost figure presented to a governance board should be accompanied by the assumptions that underpin it, otherwise you will be held to a number that was never meant to be definitive.
- Scope that is only stated as inclusions: Explicitly stating what is out of scope is just as important as what is in scope, particularly for governance audiences who may have different expectations about what they are funding.
- Passive voice throughout: Executive readers respond better to direct, active language. "The organisation requires a solution that enables staff to classify records at the point of creation" is clearer than "records classification capabilities are required to be provided."
A Worked Example: Where the Format Became the Problem
On a system-led business reform project I worked on at Organisation A, I was asked to produce a high-level BRD for an ICT Strategy Committee. The project concerned replacing a legacy document and records management system that supported over 4,000 users, at an annual running cost of around $200,000. Four options had been assessed, ranging from a do-nothing position through to a full migration to an integrated platform. The five-year cost difference between the cheapest and most expensive options was over $6 million.
I structured the document using the template above, including a comparison table of all four options with their indicative costs, a clear recommended option, and a specific request for approval to spend $58,000 on a ten-week detailed analysis phase before any implementation commitment was made. I thought it was clean, proportionate, and appropriately bounded.
The friction came from the ICT Director, who reviewed the draft before it went to the committee and wanted me to remove the options section entirely. His view was that presenting alternatives would invite the committee to second-guess the recommendation and create debate that would delay approval. I pushed back on this, and it was not a comfortable conversation. My argument was that the committee had been burnt before by decisions that appeared to have no evidential basis, and that showing the options with reasons for discounting them would actually build confidence rather than erode it. I also pointed out that the recommended option carried a $960,000 implementation estimate, and that governance bodies at that level expect to see due diligence, not just a recommendation in isolation.
We reached a compromise: the options table stayed, but I added a clearer framing sentence before it that guided the reader directly to the recommendation. The committee approved the analysis phase at the first meeting. The ICT Director later said the options table had been the right call because one committee member had specifically asked about an alternative that was already addressed in the table, and the answer was right there in the document.
That experience reinforced something I have seen repeatedly: when you are writing for a governance audience, the instinct to simplify by removing information often backfires. What executives need is not less content, they need better-organised content with clearer signposting. If you need to understand the difference between this kind of document and a more detailed requirements artefact, the comparison at BRD vs FRD is a useful reference point, and for a practical downloadable starting point, the BRD template in Word format gives you a structure you can adapt for the executive version described here.
The best high-level BRDs I have written share one quality: they make the decision the governance body needs to take completely obvious by the time the reader reaches page two. Everything in the document before that point exists to give the decision-maker confidence that the recommendation in front of them is grounded, proportionate, and honest about what is still unknown. That is not a matter of template design alone, it is a matter of analytical judgment about what belongs in the document and what should be held back for the detailed phase that follows approval.
Frequently asked questions
What is the difference between a high-level BRD and a detailed BRD?
A high-level BRD is written for executive or governance audiences and focuses on business objectives, scope boundaries, options analysis, and indicative costs and benefits. A detailed BRD is written for delivery teams and goes into specific functional requirements, acceptance criteria, and system behaviour. They serve different purposes and should not be treated as the same document at different levels of completion.
How long should a high-level BRD be?
For most projects, a high-level BRD for a governance audience should be between six and fifteen pages, excluding appendices. The executive summary should be no longer than half a page, and the requirements section should describe capabilities rather than detailed features. If your document runs past twenty pages, you have likely included detail that belongs in the next phase of analysis rather than in the governance submission.
What do executives want to see in a business requirements document?
Executives want to see the business problem stated clearly, the recommended solution with its rationale, the indicative cost and benefit case, the key constraints and risks, and a clear statement of what they are being asked to approve. They do not want to read through detailed functional specifications, data dictionaries, or process flow descriptions.
Should I include an options analysis in a high-level BRD?
Yes, in most cases an options analysis strengthens a high-level BRD for an executive audience because it demonstrates due diligence and pre-empts questions about whether alternatives were considered. Keep it concise, ideally as a comparison table, and make the rationale for the preferred option clear. Removing options analysis to simplify the document often backfires in governance settings.
How do I write business requirements at the right level of detail for a governance board?
Write requirements at capability level rather than feature level, describing what the business needs to be able to do rather than how a system will do it. Each requirement should be traceable to a business objective and testable in principle. Aim for between eight and fifteen high-level requirements for a mid-sized project, and avoid including any requirement that reads like a system specification or solution design decision.
Try Ash, Your Virtual BA
If you are working on a BRD right now and need to calibrate the level of detail for a governance or executive audience, Ash can help you draft, pressure-test, or restructure your document so it lands with the right readers. Ash is trained across the full range of BA document types, including high-level BRDs, business cases, and requirements specifications, so you can get targeted support for exactly the stage you are at. Whether you need a starting structure or a review of what you have already written, Ash is the fastest way to move forward. Try Ash Virtual BA.
Further reading
- Successfully Documenting Requirements for a Project | IIBA® Business Analysis Blog
- Business Requirements at the Core: How to Uncover, Model, and Align Analysis with Real Business Needs | IIBA
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.