Functional Requirements Vs. Business Requirements

tetmc/iStock/Getty Images

When you draw up a business plan or a project plan, you need to document the project's requirements. A business requirements document, or BRD, explains the purpose and goals of the project. Business requirements are different from functional requirements. Business requirements explain why the project is needed, and functional requirements explain how to get it done.

Satisfy the Stakeholders

The audience for a BRD is the project's stakeholders. These may be customers, clients, employees or upper management. The business requirements document tells them why the project is needed or what the company wants it to accomplish.

"The Chamber of Commerce will release a digital directory of members to attract new customers for them," is a high-level business requirements example. So is "We will boost sales by notifying regular customers about our new discount program."

Drawing up a formal BRD pushes the company to go into more detail about why it's needed. For example, is the discount program meant to increase brand awareness, build customer loyalty or undercut competing vendors?

Drafting a Business Requirements Document

A good BRD must meet several requirements:

  • It's clear and easy to understand, without jargon.

  • It explains the problem that needs to be addressed, such as low sales, negative brand image or tough competition.

  • The BRD identifies the need the project is meant to fulfill.

  • It provides enough information and guidance to ensure the project does the job.

  • The BRD identifies the problems the company may face while completing the project. For example, if there are regulations or reporting requirements the project has to meet, the BRD should list them.

  • If vendors have to support the project, the BRD identifies what they're expected to deliver.

If the prospect of writing one is intimidating, you can find a business requirements document template online.

Elements of a Business Requirements Document

If you want to draft your own BRD, there are several sections you might consider including in it:

  • An executive summary outlining the high-level business requirements. It's usually best to write the summary after you've finished the rest of the document.

  • The project objectives, which should be measurable, attainable and specific.

  • The needs statement, spelling out why the project is important.

  • The project scope section which covers the goals, the challenges and the costs.

  • A financial section dealing with the impact on the company's revenue and the plans to fund the project.

  • The project's personnel needs. How many people will be assigned to the project, for how long and from when to when?

  • The schedule, timeline and deadlines.

  • The project's costs and benefits.

Business Functional Requirements

While business requirements and business functional requirements are often talked about as the same thing, they're not. Functional requirements are the nuts and bolts. "Sell more stuff online to boost revenue" is the business requirement for a project, while "enable one-click shopping on our website" or "have the website recognize returning customers by name" are business functional requirements.

Businesses should document functional requirements as well as business requirements. This can be done in a separate document, or the BRD can include a functional requirements section.

Making Your Case

Writing an effective BRD can determine whether a project gets the go ahead or the thumbs down. Following a few best practices can help create the best and most persuasive BRD possible:

  • Figure out the company's requirements. Talk to a wide variety of employees using interviews, workshops and brainstorming sessions.

  • Get to know the stakeholders. Develop a feel for their wants and concerns. Tailor the BRD so that it satisfies them.

  • Research the BRDs from past projects.

  • Have a subject expert go over the BRD and confirm that it's accurate.

  • Be prepared to field questions about the BRD once the stakeholders see it.