A business requirements document (BRD) sets out what a business needs a project, system or process to achieve, and why. No South African authority prescribes its format: it is a project document, not a licence or registration, so its structure comes from your organisation or your methodology.
The distinction that matters most is that a BRD describes the problem and the outcome and leaves solution design to the specifications that follow. A BRD that specifies screens, database tables and technologies has become a design document.
Business Requirements at a Glance
A usable business requirements document commonly 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 that apply to the business
- Acceptance criteria: how it will be judged complete
- Risks and dependencies
Registration and Legal Requirements
A BRD is not registered with anyone. The legal requirements that touch it are those of the business itself, such as the company being properly registered with CIPC. If you are setting that up, see the company registration requirements.
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. For example, “the system must be fast” is vague, while “a search returns results within two seconds for 95% of queries” can be tested. The figures are illustrative; your business sets its own.
Out of scope is as important as scope. Writing down what is excluded prevents most disputes about what was included.
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. Conflating them produces documents nobody can approve.
Documents and Ownership Information Required
What typically supports a BRD in practice:
- Process maps of the current and intended future state
- Evidence of the problem, such as volumes, error rates, cost and cycle times
- Stakeholder interview notes and workshop outputs
- A prioritised requirements register, with each requirement uniquely identified
- Data requirements, including what is captured, retained and reported
- A glossary, so that terms mean the same thing to everyone
- A sign-off record and a change control record for amendments after sign-off
If your BRD is for a bank or business account rather than a software project, the documents are different. See the FAQ below.
Tax, Licence and Compliance Requirements
Regulatory requirements belong in the document from the start. The Protection of Personal Information Act 4 of 2013 requires a responsible party to secure the integrity and confidentiality of personal information with appropriate, reasonable technical and organisational measures (section 19), and section 72 restricts transferring personal information to a third party in a foreign country unless listed conditions are met. A system that handles personal information, or uses cloud services abroad, should state these as requirements.
If the project involves a company, note CIPC’s beneficial ownership duty. According to the CIPC beneficial ownership page, entities file beneficial ownership declarations with their annual returns, new entities within 10 business days, and changes within 10 business days, with a hard stop on filing since 1 July 2024.
Other sector legislation may apply to your industry. Ask the relevant regulator or your compliance officer which laws your system must support, and record them as requirements.
Process, Deadlines and Ongoing Obligations
Write the problem before the solution. Teams that begin with a system they have already chosen produce documents that justify the choice rather than test it. Involve the people who do the work, not only their managers.
- Describe what is needed and why, not how to build it
- Make every requirement testable
- Write non-functional requirements specifically, with numbers
- State explicitly what is out of scope
- Include POPIA and any sector regulation from the start
- Get formal sign-off and run change control on amendments
A signed BRD with a change control process means scope changes are decided rather than absorbed, and the cost of each is visible.
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.
What is most often missing?
Non-functional requirements 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, for example, sets security and cross-border transfer duties for personal information, so they shape the design rather than being added afterwards.
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.
Which CIPC documents are required for a business account?
It depends on the bank. For a company account, the FNB KYC requirements guide accepts any one of a CIPC Certificate of Confirmation, a registration certificate (CoR14.3), or a CoR18(3) if the company was converted from a close corporation, with the Notice of Incorporation (CoR14.1) and the memorandum of incorporation where applicable. FNB also asks for proof of operating address (a physical address, not a box number), a mandate validated by minutes or a resolution signed by all directors, a letter confirming holders of 25% or more of voting rights, and ID for related parties. Other banks differ, so ask your bank for its list before you apply.
Confirm regulatory requirements with the relevant regulator, such as CIPC or the Information Regulator. See all business and compliance requirements and the company registration requirements.