The Details Needed in A Business Requirements Document

A Business Requirements Document is typically used for complex projects so that everyone involved understands what the aim of the project is and how that will be achieved. It also documents what features and functions will be included in the project as well as sections on risk, assumptions and quality control.

It also documents how an end-user will use the final deliverable to achieve the business aims. For that reason it will contain information about the features and functions of the new product, process or software.

One of the important aspects of a BRD is to understand that it will be read by people with no technical knowledge and has to be understood by those people (as they will be approving the document). For that reason it should not be full of technical jargon (there are other technical documents that can fulfill that purpose) – it should be easily readable and as short as possible but, at the same time, it must explain in some detail how an end-user will use the project deliverable.

Functional Requirements

This section defines how exactly an end user will complete a particular task or fulfill a particular function. It states how any business information entered is processed – what sort of data an end user enters into the system and what is produced (typically a report).

Non-Functional Requirements

Non-functional requirements describe how the end-user will comply with business standards, statutory regulations or other laws that need to be adhered to.


These are elements of a project deliverable that assist the end user in completing their tasks in an easier or more efficient way. A feature of a software application could, for example, organise information in an easily readable manner on the screen, present data graphically, automated the production of reports or allow easy collaboration between departments. Features do not change the end result but they improve the experience of users performing their day-to-day job.

Reporting Requirements

For many people affected by the implementation of a changed process as the result of a project, the only thing they see that is different is a report. It is, therefore, an essential part of any project that the reports produced accurately present the data in a clear, easily readable format. Often the quality of the whole project is decided based on the quality of the reports output so a BRD should document the reporting requirements of those involved.


A project may start with the requirement to convert old data to be stored in a new system and it is a;so likely to require an archive process for new data that is built up over time in the new system. Pulling old data into the new system can be fundamental to the success of the whole project so the process must be described in the BRD.

So certain types of technical information are essential in a good business requirements document but a good project manager should ensure that there is a balance between enough detail without compromising the length and readability of a document which is, after all, intended to be read by end users and stakeholders.

How To Create An Effective Business Requirements Document

“Technology needs to understand what the business wants, so requirements have to be gathered from all relevant business functions.”

This is a commonly perceived and communicated objective for creating a Business Requirements Document. However, the experienced Business Analyst knows that the first step is not gathering requirements but creating them.

Why a Business Requirements Document (BRD)?

Constantly changing market conditions compel businesses to tailor their products and service offering accordingly. Clients today are loyal only to their top and bottom lines, and every successful business continuously adds new products or amends the existing ones to cater to client needs. But in order to efficiently support products, the business infrastructure must be enhanced or tweaked accordingly.

A BRD is a document that defines the to-be-incorporated changes from all affected support functions.

Contrary to popular belief, a BRD is not just something that Technology will use to build systems; it is a reference manual for all functions to comply with for comprehensive support, reporting and compliance with regulatory guidelines.

Why do requirements always keep changing?

Because most often, users don’t have them.

Users are the defined as those individuals who will regularly interact with the changes (as defined in the BRD) once they are built. Logically, they are burdened with the task of defining and testing these requirements as well. One key assumption, which is almost always proven false, is that users know exactly what is required.

Let’s quickly see why –

Changes can be broadly classified into two categories – enhancement of existing features and build of new functionality. While enhancements have a pre-existing base making it easier for users to know ‘what they want’, new functionality is most often based upon a business strategy or regulatory guideline.

Why a Business Analyst (BA)?

Seldom seen in the real world, a true BA should be empowered to justify his title and analyze the business need. What happens most often is that the BA is asked to reach out to the expert users and collate their inputs as requirements. Given stringent timelines, no one in the entire build process revisits what the users give.

Ideally, a BA should not be asking the users for requirements, he should ask for what functionality is expected; the BA should then convert that explanation (in simple English) to requirements that can be understood by Technology and other support functions such as Finance, Tax, Compliance and Operations.

Creating a BRD can be simple if the approach is take-from-the-users, paste-into-a-document and send-to-technology, but this invariably leads to significant rework which crops up at the testing phase. An effective business requirements document is borne out of a discussion on why something is required followed by creating the right set of requirements to achieve it.

As a management consultant Aashish has had an opportunity of working with giants in the Investment Banking, Credit Ratings, Mortagage, Insurance and Logistics Industries.

Business strategy, budgeting, prioritization, feasibility studies, efficiency analysis, team formation, resource identification, on the job motivation, stakeholder management, business development… the list seems to be a proverbial lexicon of key resume words, but as a management consider Aashish is lucky to use these skills on a regular basis while at work.

Tips for Writing Excellent Business Requirements

Understand that the purpose of the business requirements document is to ensure that the design and development team has a clear and well-defined understanding of the tasks that are going to be automated, how those tasks fit into the organizational context, and who the role players are.

Ensure that the requirements analyst meets with the major stakeholders in the project for a series of meetings designed to flesh out the requirements of the system. Subsequent meetings may include secondary stakeholders and actual end users. This is to make sure that all roles are uncovered and properly documented.

The business requirements phase of the projects consists of these three steps:

Phase 1: Conduct meetings with all stakeholders and role players.

Phase 2: Assimilate all of the information that was gathered at the meetings.

Phase 3: Create the business requirements document.

Phase 1: Steps to conducting the business requirements meetings

1. Prior to the meeting the analyst should create a list of questions that will be asked of each stakeholder and user involved in the business requirements gathering process.

2. The analyst should note the answers to the questions and identify new issues that were not previously identified.

Phase 2: Steps to conducting the business requirements meetings

1. The analyst should summarize the information gathered at the meeting, prepare a report, and then create another question and answer form targeting the new issues that came to light in the previous meeting.

2. This process should continue until the analyst is able to produce a final report that everyone agrees encompasses all of the business requirements.

Phase 3: After the business requirements gathering phase is completed

1. The analyst prepares the formal business requirements document and presents it to all stakeholders for approval and signoff.

2. If signoff it received, the business analyst’s work is finished unless and until additional requirements are identified later in the software development cycle.

3. If signoff is not received then it is likely that the project will go back to Stage 1 for additional business requirements gathering and analysis.

Because the success of the projects depends upon it being built to the client’s specifications and expectations, the business requirements document is a key deliverable. This stage of the project should never be skipped in order to expedite the development cycle.

Failure to identify and document all business requirements creates unnecessary project risk that will be very difficult to mitigate later in the software development project lifecycle.

The Perfect Business Requirements Document

A Business Requirements Document is a formal document that effectively provides a contract between a “supplier” and a “client”. The “client” is typically a business department and the “supplier” is the company or other business department that will create and deliver the new product, system or process. The document describes in detail every business need and is written in response to a known business problem or shortcoming. The Business Requirements Document is not expected to describe in detail the solution to the business needs but to describe what the business wants and needs. For technical products, such as new or modified software systems, further technical specifications will be prepared.

Various techniques, such as brainstorming, story boarding, use cases and interviews, will have been used to gather the requirements during a business requirements analysis process. That information needs to be written down in a clear, concise format in language familiar to the business users. The process of documenting and refining the business requirements helps to identify conflicting requirements and potential issues early on in the project lifecycle. It is the key document in the effective project management of any type of project.

The business requirements document effectively defines the Scope of a project. This is the description of what will be included in the project and also what is specifically excluded from the project.

Scope is a definition of the limits or boundaries of a project and the reason it is so important is because poor management of the project scope is one of the major causes of project failure. Good management of the project scope by the project manager involves 3 key factors:

devote adequate time to fully defining the requirements
reach a formal agreement on the scope with the stakeholders
avoid scope creep

Scope Creep

Scope creep is when un-authorised or un-budgeted tasks lead to uncontrolled alterations to the documented requirements during the course of the project. The business requirements document should address the possibility of requests for additional tasks in a project and state how they will be dealt with. This usually involves a formal Change Request Procedure that requires the agreement of all stakeholders to any changes of specification, budget or delivery time. The fact that the business requirements document is a formally approved document assists the project manager in implementing and sticking to a Change Request Procedure.

There is, of course, a tendency for changes to be requested during the life of a project. As projects progress, the end-users inevitably see areas where additional features could provide increased benefits. And the purpose of scope management is not to prevent such changes either being requested or implemented, but to ensure that all changes bring substantial, well-defined benefits. And that the budget will be increased accordingly and that the extended duration of the project is acceptable to all parties involved. Failure on the part of the project manager to manage scope adequately undermines the viability of the whole project as approved in the Business Requirements Document.

All changes to the requirements, budget and schedule must be approved by all stakeholders. In large projects it is common for end-users to see their opportunity to have all the “nice-to-have” elements added while major changes are underway – to some extent this is understandable but only if the new features add real business value such as efficiency or accountability and do not require the project to change in such a way as to lose sight of the original business needs that instigated the project in the first place

Document Iterations

A business requirements document is likely to need several iterations before it is close to reaching a document acceptable to all stakeholders. Writing such a document can be a complex and intricate process and will probably need many more iterations before approval is actually achieved. This is no reflection on the thoroughness of the analysis process but rather on the simple human difficulty in translating thoughts and speech into clear, unambiguous and thorough wording on the page. Whilst adequate detail is required to fully define the requirements, conversely, too much detail prevents the readers from absorbing the key points. Writing a document that achieves this balance is a skill in itself.

Fortunately, there are a number of best practice approaches and industry standards that can be used to good effect when writing a business requirements document.These will assist in defining the project scope and managing scope creep once the project is underway.

Key Document Elements

Whether the author of the business requirements is the business analyst or the project manager, they should have an understanding of the different levels of requirements and the different elements within the requirements. They must be able to state the business needs clearly, understand the current business process and the key business objectives driving the project.

The following list, whilst not exhaustive, covers the main areas that should be documented in a business requirements document:

Business Problem Statement
Current Business Process
Scope Statement(s)
Key Business Objectives
Project Completion Criteria
Functional Requirements
Non-Functional Requirements
Features and Functions
Reporting Requirements
Delivery Method
New/Modified Business Process
Data Retention/Archiving
Stakeholder List
Quality Measures
Checklists (Process and Requirements)

Ensuring each of these elements is incorporated in to the document with sufficient detail and clarity is the first step to creating a perfect business requirements document. Techniques for writing effective business requirements are covered on both general project management training courses and on specific business requirements courses.