Documentation and SpecificationLesson 1
The Business Requirements Document (BRD)
11 minutes
The BRD is the most common formal artefact in SA enterprise BA work. It is the document that gets signed off by the business sponsor before development starts. Get it right and the project has a clear contract between business and delivery. Get it wrong and the project either stalls in approval or builds the wrong thing.
This lesson covers what goes in a BRD, how to structure it for sign-off and when not to write one at all.
What a BRD is (and is not)
A BRD isA business-level statement of what the organisation needs and why. Written for the business sponsor and senior stakeholders to read and approve. Forms the contract between business and delivery.
A BRD is notA technical specification. Engineers do not build from a BRD directly. They build from the FRS (next lesson) which interprets the BRD into technical detail. Conflating the two produces unreadable artefacts.
Standard BRD structure
Most SA enterprises use a variant of this structure. Section numbering matters; cross-references will break if you reorder later.
1
Executive summary
Two paragraphs. The business problem and the proposed solution at a level a CEO can read in 90 seconds. Often written last.
2
Business context and case
Why this project exists. The problem, the cost of doing nothing, the expected benefit. Numbers where available. The sponsor's argument for the spend.
3
Scope: in and out
What is in scope (a few paragraphs and a bulleted list). What is explicitly out of scope (equally bulleted). Out-of-scope is where the BRD earns its keep; it prevents scope creep later.
4
Stakeholders
From your stakeholder map (Module 2). Roles, accountabilities, decision rights, sign-off authorities.
5
Business requirements
The heart of the document. Numbered list of what the business needs. Each requirement is a 1-3 sentence statement, written in business language. Reference any process diagrams as appendices.
6
Assumptions and dependencies
What you have assumed about the world (the credit bureau API will be available; load shedding will average less than 4 hours per day; the new regulation will be passed by Q3). Dependencies on other projects, vendors or decisions.
7
Risks
Top 5-10 risks with likelihood, impact and mitigation owner. Not exhaustive; the project risk register is the comprehensive view. The BRD risks are the ones that affect scope or feasibility.
8
Acceptance criteria
How the business will know the project is complete. High-level, not test-level. 'The system supports motor quote generation for all SA postcodes within 2 seconds at 500 concurrent users' is BRD-level. Specific test cases live in the FRS.
9
Glossary and appendices
Domain terms with definitions. Process diagrams, RACI matrices, supporting data. Appendices instead of inline so the body stays readable.
Writing business requirements that hold up
The numbered list in section 5 is what stakeholders sign off on. Each requirement needs to be specific enough to verify, general enough to allow design flexibility and stable enough to survive 6 months of project life.
Bad business requirement'The system should be user-friendly.' Untestable, vague, sponsor-friendly but useless to delivery.
Better'The system must allow brokers to submit a motor quote in 5 minutes or less for standard cases.' Specific but still business-level (does not specify how).
Good'The system must allow brokers to submit a motor quote in 5 minutes or less for standard cases, as measured from broker login to quote PDF delivery, with broker user feedback collected at quarterly intervals.' Specific, measurable, sponsorable.
Excellent (rare)Includes the business rationale: '...because broker abandonment increases sharply above 5 minutes (current rate 38% on the legacy system).' Sponsor sees the business case embedded in the requirement.
When NOT to write a BRD
Some projects do not need one. Writing one anyway is busy-work.
1
Small incremental change in an Agile team
Sprint-sized work. User stories and acceptance criteria are enough. A BRD for a single sprint deliverable is overhead without value.
2
Internal tool with no formal sponsor
If no senior stakeholder will read or sign off, the formal sign-off artefact is unnecessary. A lighter requirements note in Confluence covers it.
3
Throwaway prototype
If the deliverable is a learning artefact, not production code, skip the BRD.
4
Continuous-improvement programme
Where the work is ongoing rather than project-shaped. Treat as a programme backlog with quarterly themes.
SA enterprise BRD reality
A few things SA BAs commonly handle.
SA-specific BRD considerations
1. Many SA enterprises require POPIA impact assessment as a section in (or appendix to) the BRD. 2. Banks and FSPs add a Compliance section listing the regulations the project touches (FAIS, Banks Act, FICA, JSE listings). 3. State-owned enterprises and government projects often follow a SITA template which is structurally similar but with mandatory sections for B-BBEE supplier breakdown and skills development plan. 4. The sign-off process often includes Risk, Compliance and InfoSec sign-off in addition to the business sponsor. Plan for at least 2-3 weeks between final draft and signed-off BRD.
Length and format
1
Length
10-30 pages is normal for a mid-sized SA enterprise BRD. Above 40 pages, readers skim. Use appendices for detail.
2
Format
Word document or Confluence page. PDFs for sign-off circulation. The original lives in the project workspace; the PDF is the snapshot of what was signed.
3
Templates
Most SA enterprises have an internal BRD template. Use it. Reinventing the structure wastes goodwill.
Key Takeaways
- The BRD is the business contract. Written for the sponsor and senior stakeholders to read and approve.
- Nine standard sections. Exec summary, context, scope, stakeholders, requirements, assumptions, risks, acceptance, glossary.
- Business requirements are specific and measurable. "User-friendly" fails; "submit in 5 minutes or less" holds up.
- SA additions. POPIA impact, compliance section, SITA template for govt, multi-stakeholder sign-off cycle.
- Not every project needs a BRD. Small Agile increments, internal tools and prototypes usually do not.