<img height="1" width="1" src="https://www.facebook.com/tr?id=117920282228096&amp;ev=PageView &amp;noscript=1">

How To Create A Business Requirements Document For Your Software Purchase

If you’re going through (or thinking about) a software purchase for your business, the preparation and due diligence you put in now can have a major impact on the Return on Investment you receive.

The best thing you can do to improve the ROI of a software purchase is to start with a basic set of requirements before you start looking at software demonstrations. Different companies use different terms to describe this document - we use "Business Requirements Document (BRD)" - but don’t get hung up on the name or acronym; it’s the content of the document that is important to understand. 

In this post, we'll review the most important components of a BRD.


How to Create a BRD.jpg



Business Requirements Document (BRD)

A written document that details your company’s basic requirements, in this case, for a software application.

Other important documents in the process of acquiring new software would be:

Functional Requirements Document (FRD)

A final set of requirements made after you purchase your new system but before your vendor starts to configure the system.

Project Plan

A written, step by step, plan (usually in columnar form, such as an Excel sheet) that details each step your vendor and your company are going to take to configure/implement your system.



  • It can be and should be provided to prospective vendors to solicit their proposed solutions or input. You will save yourself hours (more likely tens of hours) by creating this document before you start viewing software demonstrations. I can say with confidence that beginning your search with software demonstrations is not the optimal way to identify software applications and prospective software vendors.
  • You can and should provide this to your internal affected departments to get their input, additions, or corrections to this document. You may be surprised at the willingness of your staff to participate in a growth or efficiency initiative.
  • You will prosper from the knowledge you will gain about how your departments are actually doing their job and the bottlenecks or manual processing that is going on within these departments.
  • You will learn how your departments share information, or don’t.
  • You can use this as an effective “scoring sheet” to evaluate both software packages and prospective vendors.
  • This document will serve as a working document allowing additions, corrections, and deletions to be tracked. This document matures and will eventually serve as the source document for your Functional Requirements Document.




Our definition describes this as a document that details your companies’ basic requirements, but it’s actually much more than that. Think of this as an exercise, not just a document. Done properly, this can give you a window into which processes or departments are working efficiently and (maybe more importantly) which are not. You will most likely learn how departments interact and how data flows from one to the other. You also need to look at how this fits into your current technology/network environment and what environment will be necessary to accommodate your growth – your goal is to eliminate the chance that you repeat this exercise in the next 5 years (or much longer).

The creation of a BRD can be done by your company, by your vendor, or by a conjunctive effort. This document can go into varying levels of detail as it is refined, but to get a good first draft, start with answering the questions listed below. It can be as simple as listing these in a Word document. I’ve broken them into three parts to make it easier to digest: General Project Information, User Information, and Software Information.

General Project Info

  • What functionality are you trying to provide or replace? Phrased another way, what problems are you trying to solve?

This may be the most important part of the exercise. Gather input from the department(s) that will be using the software so that you have a comprehensive set of input. You must convey as clear a picture to your vendor or prospective vendors as possible. The devil is in the details and you should do a thorough first pass at gathering these details.

Example: A recent client chose a software product that advertised work flows, but they turned out to be very narrow and specific. Our client did not discover the gap until they were implementing and had already purchased the software. We advised them to bring in a third party workflow solution rather than scrap all their work and investment, but this was not the correct original choice of software for their business processes and work flows.

You may find that the problem you are addressing will directly affect multiple departments and you may need more than one application to solve your problem.

Example: You are looking for a Scheduling and Dispatch application but realize that it can’t accommodate multiple complex billing rates – you may need to add another application to provide this functionality.
  • What is your budget?

Some of our prospective clients resist sharing their budget with us at the beginning. My personal opinion on this is that it is a mistake and handcuffs your vendor from making some important decisions. Even if your prospective vendor only offers one product, it will still guide them on what level on configuration or customization can be performed to provide the right solution.

  • What is your timeline to get started? What is your timeline to “Go Live”?

Don’t underestimate the time it takes to implement a new system. Keep in mind, two major adoption-related components will affect your Return on Investment on your new software:

  • The degree to which your staff adopts the feature and functionality of the software. We often see very functional, fully featured software applications being used to a minimum of their effectiveness.
  • The number of staff members who use the software. Although related to the first, I’m referring to users who are not trained properly and either don’t use the software or are relegated to simply running or printing reports for other staff.

If you compress your timelines for implementation too much, which includes training, one of these adoption goals (if not both) will be compromised.


User Information

  • Who will serve as your internal project team and project lead to interact with the vendor throughout the process?

Even though you haven’t even chosen a software application or a vendor yet, identifying a point person, what we call a Project Manager, is important. This internal designate would oversee the eventual implementation of your new software application(s) and therefore should be involved in the production of your BRD.

  • Who is in charge of authoring and revising your BRD document?

Someone needs to manage the revisions as input is provided by team members and the document matures.

  • What team members are assigned to the completion of this document?

It’s a good idea to, at the very least, to alert your staff that this exercise is being conducted and encourage them to engage fully when interviewed.

Caution: We believe it is a mistake to create your BRD without the participation of some line level employees. Department Heads are not always aware of what your front line employees do on a day-to-day basis in their systems. There is often a great deal of “out-of-system” processes being used. By not including your software “power users” in the requirements process, you run the risk of missing important requirements.

  • What departments will be effected by this change?

I.E. A change in the process that a salesperson uses to send Quotes may affect your accounting department if that quote is turned into a Sales Order and then an Invoice. This is another reason for this document, you begin to identify dependencies within departments and the software that they use.

  • What is the experience level of the personnel that will be using the system?

All staff is not created equal. Some of the staff of our clients have extensive software backgrounds and some don’t. Some of the accounting staff personnel of our clients have no formal accounting training. Factor in these considerations - complex software residing on your internal server will require a higher degree of technical competence than a well-designed/more intuitive solution that is hosted in the cloud.

Note: The theme developing here is to choose your key personnel early in the process. Choose your person or team to create the BRD and choose your person or team to run the project. These may be the same personnel, but give some thought to who is best suited to provide the best outcome for your company’s goals.

  • Who will be using the new software? What departments and what personnel?

This is different than “what departments or personnel will be affected”. Understanding who will be using the software will help in choosing someone from each department who is best suited to contribute to creating your requirements. We would call this your “Business Process Area Owner” – the person who is most knowledgeable of this Business Process Area. These internal personnel assignments should not default to a department head. You may find that the “Power User” who works for the department head may be the better selection due to their in-depth knowledge of your current software and/or process.


Software Information

  • List your existing software.

You should list all your software applications, not just the one you are replacing. If you are automating a department or process for the first time, you should still list all your current applications.

  • List your current hardware infrastructure. Are you open to cloud or hosting?

Do your current software applications run on an internal server? What is the cost and risk of maintaining this server? Is your server protected properly? The answer to these questions, and others, will help you determine if you are a candidate for hosted or true cloud software. Most applications are either client server or true cloud, but few offer their product in both forms. Don’t be fooled by client server software that is hosted.

  • Is the software you’re replacing integrated with any other software?

We are referring to an automated exchange of information, either one way or bidirectional, between two separate pieces of software. We aren’t referring to manually exporting/importing data out of/into two software applications. Today’s need for disparate software applications to talk to each other is a whole industry unto itself. You may want to inquire about a Unified Platform as an alternative to purchasing individual integrations between separate software packages. List any of your software integrations.

  • Will the new software need to be integrated with any other software applications?

Will your new software have to talk to any of your existing software? The most ubiquitous type of integration would probably be those that connect a software program that runs a company to an accounting software application. As your company grows, an integrated system will become a when, not if decision.

  • What type of data is to be sent from/into the new software package to another?

An example is a sales order created in one system which creates, once closed, an invoice in your accounting system. Do you require bi-directional communication for your applications?

Caution: Many software applications state integrations with other popular industry programs. Integrations can be written 3 basic ways (another Blog post here) but suffice to say, that all integrations are not created equal. Remember, an integration is another piece of software – by connecting, say Salesforce to NetSuite, you have 3 pieces of software to manage. Your needs may not be met by many integrations and your vendor should be willing to discuss the details of this. Avoid taking for granted that an “integration” will fit your needs; in some cases, it may not even come close.

  • Will you need to add other functionality to your system later?

This could affect the software that you choose now. You should be aware of the changing landscape in software solutions and ask prospective vendors about on-premise vs. hosted vs. true cloud software. You should be able to ask your prospective vendors to give their opinions and explanations of these technologies and the shift being made by companies like Microsoft. The days of having 5 different applications running your company and maintaining technical staff and/ or development staff are ending and the input of your vendors can educate you how to take advantage of this to grow your company. It may be time for you to look at your platform, not just add individual programs that require integrations to exchange data.



If you're enjoying this blog post, you might like the White Paper

"Turbo-Charge Finance for Growth with Cloud Financials"


Access the White Paper




A vendor who will not assist you in the production of a BRD should have a credible explanation (I can’t think of one).

A vendor who doesn’t feel it is necessary to create a BRD, or similar document, should raise a red flag. This is your “Go To” document to assure that your requirements are both understood and met.

A vendor who provides a timeline early in the process but agrees to then compress this timeline based on your or their time constraints should be reviewed carefully. Embrace process over speed.

Just my opinion, but a vendor who goes immediately to a demonstration without knowing anything about your company or your requirements always puzzles me. We work with Field Service companies each and every day. The idea that their common offerings would mean that they run their business in the same way or have similar staff experience is not something we have found to be remotely the case. You don’t want to fit your business into the software, you want the solution that is designed for your way of working, running your staff and providing your services.



Some companies hire an outside party to write their BRD. For example, the federal government adheres to this practice, with the caveat that the company that writes the BRD cannot bid on the project. I’m not suggesting this course of action, but even if you are thinking about just buying QuickBooks Pro off the shelf on the way out of Best Buy, start by documenting your requirements.

You may only perform some of the steps outlined in this post, but your company will be better for having done the exercise.


If you have any questions about the information presented here,

please feel free to call Greg Nelson at:

(571) 384-5380 x103



Next: The easiest way to make a shortlist of prospective vendors - what questions to ask and how to compare each.


leave your comments

New Call-to-action