Business Requirements Document Template
[CLIENT COMPANY NAME]
[PROJECT DESCRIPTION (IF ANY)]
[PREPARER COMPANY NAME]
What is an employment contract?
An employment contract is a legal agreement between an employer and an employee which includes any details relevant to the employment arrangement, for example, the term of employment, the compensation provided and other relevant information.
TABLE OF CONTENTS
A business requirements document is a high level overview of a business problem and the proposed solution for it, often presented by a potential supplier or provider to the potential client business. Compare with a functional requirements document that would include much more detailed information and checklists.
- Executive summary
- Business objectives
- Functional requirements
- Personnel requirements
- Reporting and quality assurance
- Delivery schedule
- Other requirements
Appendix A – Glossary of Terms
There are many different options for writing a Business Requirements Document and it is a good practice to look at examples of other ones written for this business or within your industry; this template gives you a place to start.
[EXEC SUMMARY TEXT]
An executive summary should be no more than three paragraphs long and should provide a concise summary of the purpose and contents of the rest of the document. It is usually best to draft this section last.
[BUSINESS OBJECTIVES TEXT]
Business objections should use the commonly used SMART formula – specific, measurable, actionable, realistic, and time bound. If you are not familiar with this formula, an easy comparison would be the generic “I will have healthier habits this year” with the SMART version “I will lose 15 pounds in the next three months, I will do this by cutting out desserts and walking two miles every day during that time period.”
Provide information about the business, current business practices, and outline the business need that underlies this document.
The Scope section creates specification around what work is and is not part of the scope of the project being discussed. Err on the side of more detail rather than less because mutual understanding between the parties as to scope can be a primary source of dispute and cost overruns.
This is the place to be more descriptive of what work would be created from a user perspective. For example, for software development, this section would discuss that a user would be able to do this and that task, compile this data, and run that report.
[FUNCTIONAL REQUIREMENTS TEXT]
The Functional requirements section is where to put more details about the structure behind what the user of the end product or service sees. You may add subsections for user requirements, data flow diagrams and flow charts or similar types of information. Be detailed, but not too technical. The audience for this document is business decision makers.
[PERSONNEL REQUIREMENTS TEXT]
For some business projects, the identity of personnel is just as critical as any other requirements. Include enough detail to address what those needs are in the context of the rest of the project, and how they will be met.
Reporting and quality assurance
[REPORTING QUALITY TEXT]
The Reporting and Quality Assurance section will outline how progress is being measured and assessed along the way.
Include both final deadlines and milestones along the way.
[OTHER REQUIREMENTS TEXT]
Think about such things as interface requirements between old and new systems, data conversion requirements where appropriate, hardware and software requirements when incidental to the rest of the project, operational requirements if not already discussed above.
Identify assumptions that you have made about the business operations, and other details. This allows easier identification of wrong assumptions before they put an entire process off track.
Identify any limitations in terms of time, personnel, technical details, or other things that limit the scope, time, and cost of the project being discussed.
Every project has inherent risks that may cause delay or even failure of a project. You must identify this risks to show you know what they are, and also identify ways in which you would mitigate those risks.
Appendix A – Glossary of Terms
Add a Glossary of Terms if there are a lot of technical terms that need defining to add clarity to the document.