Insights

Why Business and Functional Requirements are Vital for a Project’s Success

business and functional requirements

In a product development process, one of the vital aspects of the success of any project is getting the requirements right. And many projects fail because stakeholders fail to understand the difference between business and functional requirements.

The ultimate success and failure of any project depend on the quality of the requirements. Although it’s rarely stated so simply, most of the software projects fail because of less emphasis being placed on Requirements Management.

37% of software projects fail because of poor requirements management

In September 1999, NASA lost its $125-million Mars Climate Orbiter when it tried to enter the orbit, just 100 kilometers too close to Mars. The mission failed due to poor requirements management: it was not discussed earlier in the stage whether the ‘navigation software’ required metric units or imperial units.

The Result: Incompatible specifications; the attitude-control system was specified using imperial units but its navigation software used metric units.

John Pike on NASA Mass Orbiter failure

Thus, getting the requirements right and utilizing them to the fullest extent is critical for a project’s success.

In the field of software product development, the importance and the relevance of the word ‘Requirements’ is increasing with the growing popularity of agile software development methodologies. Even one of the points mentioned in the Agile Manifesto explains the methodology as one which values:

“Working software over comprehensive documentation”

Getting the requirements right is critical whether you’re working in Agile or Waterfall methodology.

Requirements mismanagement

Definition of a Requirement and its Types

According to the International Institute of Business Analysis, a requirement is:

  • A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
  • A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
  • A documented representation of a condition or capability as in (1) or (2)

Business and Functional Requirements process in software development

Based on the problem domain and the methodology that a Business Analyst (BA) works with, the following are the various types of requirements, out of which, the most important ones are: Business Requirements and Functional Requirements.

Business and functional requirements are vital types of requirements

In this blog, we will explore the differences between both. It is imperative to comprehend the difference so that we offer the business with an ideal solution that will really take care of the issue, not exactly what someone thought would be a smart idea.

What are Business Requirements

Why does a client need an app?

This information may sound unnecessary to many because the client is ready to pay you to build an app. So, why should it matter to you to get the reasons?

Well, if you are passionate about building quality products and delivering seamless experiences to your clients, then you should care about the ‘whys’ as much as you do about the ‘whats’ and the ‘hows’.

And when you start to focus on the ‘why’ part of a project, it means you are taking care of the business requirements.

Business Requirements is a phase in a software development life cycle that deals with high-level needs or wants of an organization which allows the business to achieve its end objectives, vision, and goals.

They usually describe what a system or a solution should do. They give the extent of a business need or a problem that should be addressed by a particular project or task.

Business Requirements Example

ParcelKiosk is one of our clients who approached us to get a web application designed and developed to offer better parcel delivery services to customers. As they approached us, we started the discussion with an important parameter: analyzing the business needs.

What do you think the business requirement might be for this parcel delivery web app service?

ParcelKiosk case study

You might come up with an important parameter like security. However, even though security is a vital factor, it’s not a business requirement. You do not build a service like ParcelKiosk without security in mind, but creating service just for the sake of providing security—is not the end-goal.

What about “connecting a range of courier services and customers”?

This makes better sense as a business requirement compared to security because it describes what the service will do. However, is that the reason for getting the web service built, or is it really a function of the service?

Here are some possible reasons (business requirements) to build ParcelKiosk:

  • Offer a smarter solution to measure, select, and ship parcels
  • Provide capabilities to track and manage their delivery and pick-up services
  • On-time delivery and customer feedback

Do you see the difference between “connecting a range of courier services and customers” or “security” and the actual business requirements?

The following points can be noted here w.r.t business requirements:

  • The business requirements are always written from the point of view of the client.
  • They are high-level broad requirements yet detail-oriented.
  • They are not organizational objectives but aid an organization to achieve its objectives. By the fulfillment of these business requirements, the organization attains its broad objectives.

It’s quite clear now that the business requirements explain the ‘why’ part of a project: ‘why’ a particular project needs to be built, i.e. what benefits the organization aims to achieve through the fulfillment of a specific project.

Business Requirements Document (BRD)

A Business Requirements Document describes the high-level business needs. The primary target audience of a BRD is the customer and the users. The business requirements are documented in the BRD. A well-written business requirements document helps achieve the desired goal of building a successful product within the stipulated time limit.

It has the following elements:

  • The vision of the project
  • Objectives of the project
  • Context or background of the project
  • Scope of the project
  • Stakeholder identification
  • Detailed Business Requirements
  • Scope of the solution
  • Project constraints: Time Frame, Cost of the Project, and Available resources

Why The Chrysler PT Cruiser was Tagged ‘Hero to Zero’

Chrysler Group did not focus much on BRD and went ahead with the production of their PT Cruiser, resulting in many headaches for the organization. Let’s have a look at how their business requirements document failed:

  • Stakeholders Identification: Chrysler Group identified most of the stakeholders pretty well. They were on board with vendors and the production team of the PT Cruiser. However, the two important stakeholders they missed included the end-customer purchasing the vehicle and the dealers selling the Cruiser.
  • Project Constraints: Chrysler performed a good job when it came to top-level stakeholders supplying and overseeing the build. However, what they missed was questioning the timeline for production, answering the queries of customers or of the dealers like price, model availability, and demand.

If Chrysler’s BRD included the requirements of all the stakeholders, those unforeseen delays in the product delivery (goal to deliver cars to dealership by 2001) could have been swayed well in advance of production and the needs of the end-users would have been justified.

PT Cruiser failed due to poor Business Requirement Document

Tips for Writing a Business Requirements Document (BRD)

Now that you have a basic understanding of what a BRD should accomplish, you can follow the below-mentioned tips to make sure that you write an outstanding business requirements document.

  • Practice strong requirements elicitation
  • Use plain language without passive voice and jargon
  • Research past projects
  • Validate the documentation
  • Integrate visuals

What are Functional Requirements

Functional Requirements, as the name suggests, describe the functionalities of software or a product. These are the functions that the system must perform in order to fulfill the business requirements.

They include technical details, calculations, data manipulation and processing, and other particular functionality that characterize what a framework should achieve.

If you don’t have clear functional requirements to give you an understanding of the technicality of the project, then during the project you will be unable to answer whether the decisions made by the development/design/testing teams are correct or not.

“…Failing to write a spec is the single biggest unnecessary risk you take in a software project.” ~ Joel Spolsky

If a functional detail is misaligned to a business need, it could result in the failure of the project.

effort vs time in product development process and how business and functional requirements affect them

Functional Requirements Example

One of the big FMCG players approached Net Solutions for a mobile app development project that could improve efficiency in their supply chain.

This FMCG giant started a project in 2001 which aimed at empowering rural women by generating opportunities for them to sell products and earn a livelihood.

How Net Solutions used business and functional requirements to deliver a successful FMCG project

The client wanted us to re-do their existing mobile app in a way that would automate their supply chain and the ordering process by bringing the rural women and distributors onto a single digital platform.

They aimed to improve the adoption rate, digitally enabling the entrepreneurs, and resolving the friction in the existing customer journey (all these are business requirements).

When it comes to functional requirements, we started to discuss the required app features with the client, which were:

  • Integration with third-party suppliers
  • Real-time stock updates
  • Order placement

The client assumed that these features would be enough to resolve the friction in the current customer journey, thereby improving the adoption rate.

However, while discussing the functional requirements with our client, we realized that unless we identify the friction in an existing customer’s journey and measure the digital literacy levels for the new app users, developing an app would be pointless.

The Solution that Net Solutions Delivered

We applied the Design Thinking approach and carried out ethnographic research to assess the digital readiness of the entrepreneurs and understand the gaps in the journey of the existing app’s users.

We spent a day with all the stakeholders to further identify their issues.

Using the Design Thinking approach, we were able to figure out what features should go in the new app. Moreover, this approach made our client understand that the best way to go ahead with the development of the project is to carry it out in a ‘Phased Manner’.

Net Solutions process to extract functional requirements help build a valuable mobile app

The Result:

The ethnographic research and journey mapping within our design thinking methodology helped us build a new app with features designed for and validated by the stakeholders who are ultimately going to be using it.

The following points can be noted here w.r.t functional requirements:

  • Functional requirements are always written from the point of view of the system and the stakeholders.
  • They are far more specific and detailed.
  • It is through the fulfillment of the functional requirements, that an effective solution, meeting the business needs and objectives of the client is developed.

Hence, the functional requirements explain the ‘how’ part of a project, i.e. how a software solution will be able to meet the needs of the organization.

Functional Requirements Document

The Functional Requirements Document outlines the functions required to achieve the business needs. These functions are documented in the Functional Requirements Document (FRD) or the Functional Requirements Specifications (FRS) document.

A well-written FRD depicts each process flow for each activity, interlinking the dependencies.

FRD contains the following elements:

  • Purpose of the project
  • The scope of the project
  • Detailed functional requirements
  • Assumptions/constraints
  • Representation of the functional requirements using Information Architecture

Tips for Writing a Functional Requirements Document (FRD)

Creating a document that enlists the technical functionalities that are required for the successful delivery of a software/product is just like writing a message to all the involved team members about the technical tasks you would want them to perform.

The following tips would help you in writing an effective Functional Requirements Document:

  • Double-check your facts
  • Use simple language
  • Add illustrations or diagrams
  • Observe time frames

Key Challenges in Writing a Good Business and Functional Requirements Document

It is a big challenge to write “good” or “valid” business and functional requirements. Most common challenges that are encountered while building these requirements documents include:

  • An incomplete understanding of the requirement; failing to ask for clarification
  • Incorrect interpretation of the requirement; applying personal filters to the information that alters the intent
  • Writing about implementation (the how) instead of requirements (the what).
  • Implementation decisions should be deferred to as late a point in the Requirements Elicitation Process as possible.
  • Using undefined acronyms
  • Using incorrect sentence structure

Importance of assessing requirements quality in software product development

Conclusion

From the above discussion, it is clear that the requirements are the backbone of every business. Both business and functional requirements form the foundation of an effective business analysis. Business requirements explain the “why” and “what” of a project and the functional requirements explain the “how” of the project.

A periodic review and benchmarking of the (developed) functional requirements with the business requirements ensure the overall success of a project. Here’s the concluding statement that will go a long way in helping you clearly distinguish business requirements from functional requirements.

“The starting point of any business analysis is to understand the business requirements (what and why) of the client and transform them into functional requirements (how).”

Garima

About the Author

Garima is an extremely accomplished Sr. Business Analyst at Net Solutions. Apart from developing business analysis processes, her commission is to inspire and empower everyone she encounters to be their very best. Her cross-industry experience make her a proven expert with a thorough knowledge in engineering concepts. She is a big believer that we can work and learn while having fun.

Leave a Comment

Garima

3:17 PM, Nov 25, 2019

Thanks John for your comment. As per your feedback, I have updated the blog. I would love to hear back your thoughts on the same.

John

3:51 PM, Sep 26, 2019

The distinction you make is between "what and why" versus "how". However your first business requirement example seems to start right off with a very prescriptive "how": i.e. "web and mobile-based". Can you explain this apparent inconsistency?

Bukola Watson

9:02 AM, Aug 24, 2019

Well thought out blog on the distinguishment between Business Requirement and Functional Requirements. You are right on the money that too many people confuse the two, however, your insight brings clear perspectives on the difference.

Deepti Goel

10:22 PM, Jul 09, 2019

wonderful

tasha

6:49 PM, Aug 30, 2018

Simple and precise. Thank you!

Priyanka Bhusari

12:52 PM, Feb 05, 2016

Absolutely cleared my confusion between the two.

Pravalika

2:26 PM, Apr 15, 2015

Very informative blog .. helped me with differences

Aditya

1:21 PM, Apr 09, 2015

Very nicely written. Crisp and Detail.

kishore

4:40 PM, Jan 10, 2015

Nice article ,precise and to the point.Good learning.Thanku

Srinivas Rao

10:27 PM, Oct 05, 2014

Excellent article..very concise..helped me gain perspective..

Jason

11:26 PM, Feb 20, 2014

Hi Abhay
Great article,very well explained indeed.I have one question regarding on your functional requirement examples, you mention solutions in terms of Google Maps and GPS, as these could be solutions, should they be mentioned in the requirement?
Regards

Pardeep

9:56 AM, Aug 06, 2013

Must read article

Sunny Kumar

9:45 AM, Jul 27, 2013

nice blog post.. very useful for every business analyst

Vinaykrishnan Menon

9:02 PM, Jul 26, 2013

Absolutely brilliant!