A business requirements document (BRD) sets out what a business needs a project, system or process to achieve, and why. It is a business artefact rather than a technical one: it describes the problem and the outcome, and leaves the solution design to the specifications that follow it.
That distinction is the one most often lost. A BRD that specifies screens, database tables and technologies has stopped being a requirements document and become a design document written by people not qualified to write one — which is how projects deliver exactly what was asked for and still fail.
Business Requirements at a Glance
A usable business requirements document contains the following.
- Background and problem statement — what is wrong now, with evidence
- Business objectives — what success looks like, expressed measurably
- Scope, and explicitly what is out of scope
- Stakeholders and their roles in decisions and sign-off
- Functional requirements — what the solution must do, not how
- Non-functional requirements — performance, availability, security, usability, capacity
- Constraints and assumptions, stated explicitly
- Regulatory and compliance requirements applicable to the business
- Acceptance criteria — how it will be judged complete
- Risks and dependencies
- A traceability approach linking requirements to their business objective
Registration and Legal Requirements
The non-functional requirements are where most documents are thin, and where most delivered systems disappoint. “The system must be fast” is not a requirement. “A search must return results within two seconds for ninety-five per cent of queries at a thousand concurrent users” is.
Availability, recovery time, data retention, audit logging, access control and capacity are all business decisions with cost implications, and they must be decided by the business rather than assumed by a developer.
Requirements should be testable. If you cannot describe how you would verify a requirement has been met, it is a sentiment rather than a requirement, and it will not be delivered or will be delivered in a way you did not intend.
Out of scope is as important as scope. The most common source of project conflict is a difference of understanding about what was included. Writing down what is excluded, explicitly, prevents most of it.
Distinguish the document types. A BRD says what the business needs. A functional specification says what the system will do. A technical specification says how it will be built. A user requirements specification describes needs from the user’s perspective. Conflating them produces documents nobody can approve.
Documents and Ownership Information Required
What supports a BRD in practice.
- Process maps of the current and intended future state
- Evidence of the problem — volumes, error rates, cost, cycle times, complaints
- Stakeholder interview notes and workshop outputs
- A prioritised requirements register, with each requirement uniquely identified
- Data requirements, including what is captured, retained and reported
- Integration requirements with existing systems
- Regulatory requirements applicable to the business and the data
- A glossary, so that terms mean the same thing to everyone
- Sign-off record showing who approved what, and when
- Change control record for amendments after sign-off
Tax, Licence and Compliance Requirements
South African regulatory requirements belong in the document, not in a late conversation with a compliance officer. The Protection of Personal Information Act shapes what personal data a system may collect, how long it may be retained, who may access it and what happens on a breach. Building a system and then retrofitting POPIA compliance is expensive and frequently incomplete.
Sector regulation adds more. Financial services systems must support the record-keeping the FAIS Act requires. Credit systems must support the affordability assessment and disclosure the National Credit Act prescribes. Accountable institutions must support the record keeping and reporting the Financial Intelligence Centre Act requires. Employment systems must support the records the Basic Conditions of Employment Act requires.
The Electronic Communications and Transactions Act matters where the system handles electronic signatures, contracting or records intended to have legal effect.
Data residency and cross-border transfer should be addressed explicitly where cloud services are used, because POPIA restricts transfers outside South Africa in defined circumstances.
Sign-off and change control are what protect everyone. A signed BRD with a change control process means scope changes are decided rather than absorbed, and the cost of each is visible. Without it, projects expand silently and blame is allocated afterwards.
Process, Deadlines and Ongoing Obligations
Write the problem before the solution. Teams that begin with the requirements of a system they have already chosen produce documents that justify the choice rather than test it.
Involve the people who do the work. Requirements gathered only from management routinely miss how the process actually operates, and the gap surfaces at user acceptance testing when it is expensive to fix.
- Describe what is needed and why, not how to build it
- Make every requirement testable, or it will not be delivered as intended
- Write non-functional requirements specifically, with numbers
- State explicitly what is out of scope
- Include POPIA and sector regulatory requirements from the start
- Address data residency where cloud services are involved
- Interview the people who do the work, not only their managers
- Get formal sign-off and run change control on amendments
- Keep a glossary so terms mean the same thing to everyone
Frequently Asked Questions
How is a BRD different from a functional specification?
A BRD says what the business needs and why. A functional specification says what the system will do. A technical specification says how it will be built. Conflating them produces documents nobody can approve.
What is most often missing?
Non-functional requirements — performance, availability, security, retention and capacity — stated specifically enough to be tested, and an explicit statement of what is out of scope.
Where do regulatory requirements fit?
In the document from the start. POPIA and sector regulation shape what data may be collected, retained and accessed. Retrofitting compliance after build is expensive and often incomplete.
Why does sign-off matter?
A signed document with change control makes scope changes visible decisions with visible costs. Without it, projects expand silently and disputes follow.
Documentation practice varies between organisations and methodologies, and regulatory requirements under POPIA, the FAIS Act, the National Credit Act and other legislation are amended. Confirm current regulatory requirements with the relevant regulator.