• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
Health Connective

Health Connective

  • About
  • Projects
    • Surgical Case Review Portals
    • Online Product Catalog
    • Field-Based Program Tracking System
    • Account Management Dashboard
    • Surgical Device Certification System
    • Internal Resources Website for Marketing Division
    • Co-Branding Dashboard
  • Resources
    • Insights
      • Marcom
      • R&D
    • Healthcare Marketing Conferences
    • How to Build a Better Dashboard
    • Building an App for That: A 3-Step Planning Guide
    • Newsletters
      • Marcom Newsletter
      • Development & Design Principles Newsletter
  • Get Started
    • Discovery Process
    • Consultation

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

February 18, 2022

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.

Below are some of the things we look for in business requirements documents from clients. We also put together an example business requirements document so that you can follow along.

Download Example Document

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.

Sample Business Requirements Document

Example of a Physician Locator Document
Download
Justin Bantuelle
Justin Bantuelle
Chief Operating Officer & Web Technology Director at Health Connective

Justin Bantuelle balances the responsibilities of both the Chief Operating Officer and the Web Technology Director after having worked with Health Connective for more than a dozen years. Justin regularly leads the cross-disciplinary teams in building out and updating applications for Fortune 500 companies.

Justin keeps his technical abilities sharp by contributing to an eclectic mix of open-source and personal projects on Github.

  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    App Usability in Medical Device Design for Patients, Physicians, and Product Engineers
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Keeping the Vision for Your Product in a Hard Economy
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Your Spreadsheet Is Holding You Back
  • Justin Bantuelle
    https://www.healthconnectivetech.com/insights/author/justinhealthconnectivetech-com/
    Automation Essentials
Ashley Hohensee
Ashley Hohensee
Marketing Manager at Health Connective

As the marketing manager, Ashley ensures that our clients’ marketing strategies are put into action. This includes content writing, SEO, online advertising, analytics, and interfacing with the tools, systems, and team members needed to help our clients accomplish their marketing goals.

  • Ashley Hohensee
    https://www.healthconnectivetech.com/insights/author/ashleythealthconnectivetech-com/
    Avoiding Data Clutter--Even When You Have the Right Tools
  • Ashley Hohensee
    https://www.healthconnectivetech.com/insights/author/ashleythealthconnectivetech-com/
    How Analytics Reporting Can Help You Improve Your Surgical Dashboard
  • Ashley Hohensee
    https://www.healthconnectivetech.com/insights/author/ashleythealthconnectivetech-com/
    Why We Provide Direct Communication with Our Developers to Clients
  • Ashley Hohensee
    https://www.healthconnectivetech.com/insights/author/ashleythealthconnectivetech-com/
    Creating an Improved Product Search Experience for Medtech Customers

Filed Under: Marcom

Primary Sidebar

Table of Contents

  • What Is a Business Requirements Document?
  • What Should You Include in a Business Requirements Document?
    • A project summary / executive summary
    • Features the application needs to have
    • Who will supply the data for the application
    • What should be included in the initial phase of the project vs. future phases
    • Sample Business Requirements Document

Sign Up for the Marcom Newsletter

Twice a month, we send the latest content from the Health Connective site to help you with the planning of your projects and your team dynamics.

Popular Marcom Posts

  • When Should a Medtech Company Build a Custom Application?
  • Five Keys to Creating an Effective Physician Finder
  • Tips for Running a Successful Co-Branded Campaign for Medtech Companies

Search

Welcome!

Michael Roberts

In these blog posts, we share tips from our work with marcom teams, including how to evaluate whether or not you need a custom application, how to effectively communicate what you need to developers (whether in-house or third-party), and how to demonstrate value to the C-suite and your customers.

--Michael Roberts, Marketing Director

Recent Marcom Posts

  • From Product Experience Stats to Satisfaction: Optimize for Retention
    March 22, 2023
  • Be More Human in Your Marketing with the Right Tech
    March 8, 2023
  • Brand Communities for Patients and Consumers Go Beyond Offering Support
    February 8, 2023
  • About
  • Insights
  • Cookie Policy
  • Privacy Policy
  • Get Started
  • Consultation Package
Health Connective

(504) 581-4636
TwitterLinkedIn