The Business Requirements Document – Is it still useful and if so, what should it contain?
Some people these days are arguing that the Business Requirements document is considered out dated and obsolete. This is not quite true. It is more a case of understanding what format or process is most relevant for your project to document your requirements in and then applying it accordingly. In many cases there is still a need to have a formal Business Requirements document which is well written and formally reviewed and approved. There is still in many organisations the need to document the initial business requirements for a particular initiative upfront before the organisation will release funding to implement that project. This doesn’t necessarily mean that those organisations are not considering the fact that the business requirements will change along the way, but rather that they recognise the need to put a stake in the ground and do an estimate of what resources, effort, budget and risks are involved based on what they know about what they want to implement today. Even in some Agile based projects (perhaps hybrid Agile/Traditional project combinations) it is often the case that the business stakeholders would agree some baseline initial business requirements before they embark on the Agile based delivery and implementation of those business requirements.
So the Business Requirements document may be a cumbersome beast in some cases to develop but as long as the organisation is flexible enough to realise its shortcomings down the track in the context of change and need for adaptability the business requirements document remains extremely valuable to organisations.
What should be included in a Business Requirements Document?
Having worked in many organisations with many different Business Requirements document templates it is fair to say that there are many variations on this particular theme however most Business Requirements documents will have certain key content sections in common. Let’s consider these common content sections and the importance and relevance of each.
Project Context or Background
The Project Content or Background section describes the general purpose of the project and provides a short history of where the initiative originated from. This section should be kept short and factual and provide just enough information to put the rest of the document into business context. The Project Context should also clearly state the business objectives for the project.
Problem Statement
The Problem Statement is an unstructured definition of what the problem is that the project is solving. It should include all the key problems or business needs which will be addressed as part of the project’s solution in the language of business problems or needs that exist.
Scope
The Scope section consists of two key lists of scope statements. These two lists include “In Scope” and “Out of Scope” scope items. The scope statements must describe each scope item as a discreet and individual concept of what is included and what is excluded from the project. Each individual scope statement must also have a unique identifier assigned to it.
Current State
The Current State section of the Business Requirements document can consist of a few different types of components to describe the current state of the business area that the project is addressing. It can be a conceptual diagram demonstrating how systems are currently interacting or it could be current high level business processes describing how processes are currently executed. The overarching purpose of this section is to demonstrate and describe the key points that will be addressed by the project in the way that it currently operates.
Future State
The future state section on the other hand should describe what the anticipated conceptual future state would look like after the project has been implemented successfully. Again, this could be represented as a conceptual diagram showing the implementation and interaction of new systems or improvements or it could illustrate business process efficiencies. The type of diagram and description format you choose to use in this section is highly dependent on the nature of the project you are under taking.
Important: A good idea would be to align the type of illustration used in the current state diagram and description with that of the future state section. This enhances the readability and comprehension for the reader.
Business Requirements
The Business Requirements section of the Business Requirements document is certainly the most important part of the document and should be completed with great detail and completeness. It is recommended that this section is broken into subheadings describing the different types of requirements which will be covered in the Business Requirements document. You should note at this point that you do not necessarily need to always include all the types of requirements as listed below in your business requirements documents. It varies depending on the type of project you are on and it also depends on what project methodology your organisation follows. However we are outlining all the different types of requirements that could potentially form part of a Business Requirements document.
- Stakeholder Requirements
The subsection, Stakeholder Requirements are referring to the requirements, which were raised by the Stakeholders for your project. These requirements describe “what” the business stakeholders need from the new solution. This type of requirement is probably the only mandatory requirement type that must be part of the Business Requirements document.
Important: Remember to always only describe only one concept per requirement statement and always assign an identifier for each requirement statement. Learn more about how to write requirements. It is recommended that you document your requirement statements as a unique line item in a table format. You can also have a column to show the priority of the requirement as well as the owner (who raised the requirement).
A Functional Requirement is a requirement that essentially describes what a particular user would like to be able to do using a system. It describes “how” a business need will be fulfilled with a provided solution. Described in another way, functional requirements describe what functionality a user wants to be able to perform using a system. Functional requirements are different from Stakeholder requirements in that they describe “how” the stakeholder expects a system to behave or “how” specifically a requirement must be implemented.
Important: Each Functional Requirement must have at least one stakeholder requirement that describes the requirement from a “what” perspective. Typically stakeholder requirements will have more than one functional requirement describing “how” it will be implemented.
The non functional requirements are the requirements that describe the underlying qualities of a system rather than what specific functions we expect the system to be able to perform. These types of requirements are not always included in the Business Requirements document simply because they can be more solution oriented and may rather be included in a Solution Requirements document. However, it can form part of the Business Requirements document as well and should be considered when you document your requirements.
Example categories that you could include in this subsection of the Business Requirements document include: Usability Requirements, Security Requirements, Performance Requirements, Data Storage and Retention Requirements, Compliance Requirements and other similar categories where the system attributes are described.
- Transition or Temporary Requirements
The subsection of Transition or Temporary Requirements refers to those types of requirements where the requirements are only valid for a short period of time. Examples of these types of requirements can include requirements relating to data migration, training or temporary environments that need to be set up. This type of requirement doesn’t always form part of the Business Requirements document and could potentially be documented in Training and Change Management Plans or Technique Infrastructure documents.
Other sections that you should include as part of your Business Requirements Document
UML Use Case Descriptions or Business Processes
Although some smaller projects may require additional sections to be included describing how the solution will be implemented in the formats such as that of UML Use Case Descriptions or Business Process Maps, this is more relevant in the context of Solution Requirements documents or Functional specification documents. You may want to consider putting any solution specific descriptions in the Appendix section of the Business Requirements document.
Glossary
The Glossary of terms is an important part of any document and even more so in a Business Requirements document. It is essential to clarify any acronyms or terms that may have unclear or double meanings to the reader to ensure there are no misinterpretations of any requirements or concepts.
Appendixes
The Appendix section of a Business Requirements document is a very handy way to include more detail on a particular subject if required. For example, if you feel there is a need to elaborate on some of the Current or Future state business processes, the appendix section is a good place to add this detail to.
Document Review & Sign Offs
Also remember to include somewhere in your Business Requirements document some detail about who should review the document, key changes that you made and who is required to approve the document. These are just general housekeeping aspects that every document should have but worth mentioning here.
In conclusion
As a final point about the Business Requirements document it is worth recapping the fact that every organisation and project has its own unique set of circumstances and needs when it comes to documenting business requirements. Although it is very important to be thorough and specific in your approach, you must also be flexible and relevant in the way you choose to formulate your Business Requirements document as a Business Analyst.
Please share your views and opinions on how you use Business Requirements Documents in your organisation.
