We, the kin of Product Managers and Business Analysts, live and swear-by a business requirement document (BRD). Looking back to my n00b days as a BA, I used to spend hours looking at the blank document screen and wondering where to start. Not that I was technically inexperienced, but writing BRDs is not an easy task. I was more concerned about jotting down things to perfection, and that thirst for greatness often led to hours of staring and doing nothing.

Taking inspiration from my struggles, I deduced why not help upcoming fellow BAs with some handy & useful tips to write a BRD. But first, let’s start with some basics.

What’s a BRD?

It is nothing but a complete project outline for the concerned stakeholders — the client (owner, project coordinator, etc.) and the company (project manager, business analyst, etc.). A BRD answers the ‘what and why’ behind the project: 

• What is to be done?
• Why is it undertaken?

In simple words, a BRD mentions both a point and its reason for existence. For example, the client may ask for a login page (this becomes the what) so the users can store and save their information (this becomes the why). The document aims to provide clarity, help teams keep focus and remove ambiguity concerning the needs and objectives of the project taken on-board.

The structure of a BRD

Like every other business idea or plan, business requirement document too has evolved over the decade and continues to change till date. Yes, there is a standard structure/format available for every requirement document, but we BAs tweak it according to what the project demands. Here’s something for you to proceed with.

• Introduction
  • Purpose
  • Intended Audience
  • Business Goals and Objectives
  • Stakeholders, etc.

• Requirements Scope
• Functional Requirements
• Data Requirements
• Non-Functional Requirements
• Interface Requirements
• Schedule with Timelines and Deadlines
• Cost-benefit Analysis
• Expectations and Assumptions
• Business Glossary

BRD and FRD are not the same

It is easy to confuse a business requirement document with a functional requirement document (FRD). The main difference between the two is that FRD is for the technical members of the project (designer, developers, etc.), and a BRD is for the business stakeholders (owners, managers, analysts, etc.). Functional requirements are a small part of the BRD, whereas an FRD outlines these requirements in a detailed manner.

Tips for writing a BRD

Now coming to the main reason you clicked on the blog link. My tips on writing a BRD based on my experiences.

• Look into past projects and their BRDs. This is the most basic yet crucial point to keep in mind; different organizations have different approaches to writing their BRDs and you must adapt accordingly. Read the past project requirement documents and you’ll have a point to start.

• Gathering requirements is an ongoing process. Traditional pundits may not agree with me on this, but hey, we’re living in the agile-age. Accumulating as much information as possible at the start of the project is necessary but modern-day requirements evolve even within a small time frame, hence must be considered. It will help you deliver a better product to clients and boost the client-satisfaction rate.

• Please avoid using technical jargons and complex language. No one wants to read your impeccable vocabulary, aka Shashi Tharoor-ism. Just follow two rules: keep the language simple and have a good command over the grammar rules. If you must use IT-dependent verbiage, then add a reference page at the end to highlight and explain the meaning of such words for the readers. Ease in reading and understanding is the essence of a good BRD.

• Focus on whats instead of hows. Do not start explaining the project; you are writing a project overview and not a thesis statement. If you start talking about content other than facts, then it’s the no-go zone. Stop, evaluate and get back to the original intent. Remember, a BRD focuses on whats and whys.

• Make it interesting. Visual charts are the best way to make a text-heavy BRD fun to read and comprehend. Use flow charts to show processes, pyramid diagrams to highlight benefits, etc. to fill the document with life (and probably some neutral colors too).

• Seek content validation. Errors and omissions are common where humans are involved in the process, hence the need for validation. It will help identify basic/critical errors and omissions of key requirements that could throw the project off the track.

• Try and omit outdated information. Okay, this point is pretty against the traditional BRD rules, but hey someone must say it. Including features and points like scalability, usability, feasibility, etc. does not make sense anymore. Projects of today inherit these traits by default.

Is it time to move on from the classic BRD?

Think about it, the BRD formats of today are still the same as they were decades ago; isn’t it time to sketch a new pathway that considers the complexities of the present IT problems and solutions? The technology has changed, platforms have upgraded, the demand has altered, then why not the backbone of the project? I am looking forward to hearing your take on the need for modern BRDs; to get in touch with me, please visit the contact page. 

And stay tuned, as we’ll be coming up with many useful-tips oriented blogs to help you master the art of business documentation like FRD, SRS, etc.