How to Put Together a Business Requirements Document for Application Development — Free Sample Document

Skip down to our free Sample Business Requirements Document

When your medtech company is ready to build a custom application, one of the first steps is to provide your developer group, whether it’s your IT department or an external vendor, with a business requirements document.

Simply put, a business requirements document spells out the requirements your application must meet to be considered successful. It helps to define what you expect of your application developers and the end result of the app.

What does a business requirements document look like, and what should you include in it? Let’s take a look.

What Is a Business Requirements Document?

A business requirements document is a detailed document that explains everything your application developers need to know about the project, including your team’s needs and expectations for the application, what you need it to accomplish, and what the deliverables should look like. Ideally, it should clearly answer every question the developer would have about how to make the project a success for your company, so that there is no ambiguity or guesswork needed.

One thing to note is that the business requirements are different from the functional requirements. While you should include any specific tech partnerships or required parameters that would affect development, it’s generally counterproductive to attempt to define all of the technical and functional aspects of the application upfront. It’s better to give your developers a clear concept of what you need. Let them drive the technical decisions that will help you achieve those goals.

What Should You Include in a Business Requirements Document?

Business requirements documents tend to be extremely detailed and precise, often because a lot of companies still use the “waterfall” development method. Waterfall development is very rigid, with little to no flexibility in the process. At Health Connective, we use a more agile development method that includes frequent client meetings and updates delivered in sprints at 2-week intervals. This allows for more flexibility during the development process if some changes are needed.

With that said, the more detailed a business requirements document is, the better. Supplying too much information is better than leaving unanswered questions on the table. The length of the document will depend on the complexity and functionality needed for the application. It’s not about aiming for an overall length, but making sure you provide all the details needed for your developers to deliver what you need.

A project summary / executive summary

This is a brief statement summarizing the project. You might find it easier to skip this section initially. Go back and write it up after you’ve filled in all of the details.

Features the application needs to have

In our example document, the client wants to build a physician locator to help users find a physician who uses their surgical platform. In the document, they’ve specified which features they want the physician locator to have, including:

• What the search options users should have, and what information they should be able to input in the search form (in this case, location and physician search options)
• What the search results should include (contact information for each practice, an interactive Google Map with pins for each relevant physician, and a listing below the map of each physician that matches the search criteria)
• What to do if the search criteria does not yield any results (directing the user to a new page that shows all physicians using the surgical platform)

Who will supply the data for the application

In the business requirements document, we don’t need to get into the technical specifics on how the data will be handed off to feed into the application. We will need to know who will supply them (in this case, the Medtech Company). The solution in this case is to use an API, but the specifics of that can be handled by the technical contact at the medtech company.

What should be included in the initial phase of the project vs. future phases

It’s often not feasible to cram every possible feature into an application in the first phase of development. It’s better to work in multiple phases so that people can begin using the application, and then you can make updates, add features, and adjust as needed based on user behavior. Here, the client acknowledges that while they would like to eventually include physician images in the search results, this feature will not be included in the initial phase of development.