Business Requirements & Functional Requirements

Written by Rares Taut

Published on Jun 23, 2020

Read time 6 min

Category App Development

What’s The Difference And Why Should You Care?

Successful products usually do not have a clear-cut success formula, although you can control for some well-known industry elements, such as having good customer support, great UX, a reliable technological stack, etc.

Of these industry elements, two important factors that are easily confused between one another are the business requirements and the functional requirements, especially when the concept of ‘features’ comes into discussion.

For example, having a ‘location tracking’ feature for your app is not a business requirement.

The business requirement would be something like “provide a way for team leads to track our employees to know their location at all times while working”.

A good way for this is to apply the 5 Whys technique, on which we touched upon in the first chapter of our book, From A to App Success (free to download).

Going a step further, if you say that the location tracking for your app should let the user pinpoint his location on the map, then you have delineated a part of the functional requirement of this feature.

So, you could say that the functional requirement is the response to the business requirement.

But let’s go a bit in-depth into each one of them individually.

Business Requirements

Also known as stakeholder requirements, these are the required elements that the business needs to meet in order to achieve its goals.

Put simply, the business requirements are the what (needs to be achieved), while the functional requirements are the how (it needs to be achieved).

These are usually framed by the business side of the equation, be it by the stakeholders or someone like myself (the business analyst), through rigorous analysis on a few areas.

These are usually done by non-technical people, as there is no need for tech literacy, because they are portrayed in a high-level of abstraction understandable by almost anyone.

An example of a business requirement would be that “the product must not keep any personal data after a user deletes his account”.

Based on this clear objective, the functional requirements done by the business analyst or the system analyst need to fulfill this need.

As a client, you should be engaged with the business analyst in brainstorming sessions that properly dig deep to understand what your business needs truly are, in order to properly capitalize on them further.

After you have your set of business requirements, in come the functional requirements.

Functional Requirements

Ideally, functional requirements need to solve the business requirements as efficiently as possible.

This efficiency should be in all of the different plains of the business: financial, user experience, stakeholder happiness, etc.

That’s why a thorough understanding of the business requirements are the cornerstone of delivering a functional and usable product.

There are cases when you are faced with multiple solutions to a business requirement.

In cases like these, you need to have your business analyst together with the system analyst to figure out the best solution out there.

Don’t be afraid of trade-offs, as they are bound to happen, but try instead to leverage them as best you can.

For example, you might find out that you wrote a business requirement for “let users find yard sales in their area based on location”. Keyword ‘location’.

Sure, you’ll think that of course you’re going to develop a native mobile app with a marketplace that lets users find items in their area.

But then you figure out that you don’t quite have the budget yet for two native platforms (iOS and Android), but you want to do something in order to get investors.

So you talk with the system analyst and he proposes that you do a PWA (progressive web app) that can run on mobile devices.

Although not native for mobile devices, it gets the job done until you get the funds to properly develop the app for iOS and Android.

This would be considered a major tradeoff, but you can leverage it to your advantage by developing something that can rake in funds for further development.

Plus, it’s cheaper to make and cheaper to validate (or invalidate) by the market, so you get a quicker reality check if your business requirements are something that actually solves a real-word problem.

The solution is considered to solve the right problem with the (roughly) wrong tool. (Wrong might be too much of a rough word, probably ‘not the best’ would work better).