For those who didn’t get a chance to read our earlier post – How Business Analysis can transform an idea into a remarkable software product – we talked about the importance of business analysis in building successful software products. This is the second post in our Business Analysis series.
Now you must be wondering why we have dedicated an entire post just to explain the difference between business and functional requirements. Why not just go with the flow and describe the “How To” of gathering, eliciting, documenting, and analyzing business and functional requirements; which is also the first step in any business analysis process.
The reason why we are focusing on the “differentiation” part is because organizations and service providers often struggle to make a distinction between business requirements and functional requirements. For them, there’s no clear demarcation between the two. Some don’t even regard these as two separate entities.
Why is it critical to understand the difference between Business and Functional Requirements?
It happens time and again that so many business ideas don’t actually turn into a final, intended product. That’s usually because of the failure to understand the difference between Business and functional requirements, which ultimately leads to inappropriate requirements gathering, faulty documentation, project delays, and major project failures.
Or sometimes we face situations in which although the final solution meets the needs of customers but somehow the business objectives of the client are not met.
Therefore, it’s highly critical to differentiate business requirements from functional requirements, even before you start identifying these requirements.
What are Business Requirements?
Business Requirements are high-level needs or wants of an organization the fulfillment of which allow the organization to achieve its objectives. They usually describe what a system or a solution should do.
If a company’s need is to track its field employees by means of an employee tracking system, the business requirements for the project might be described as:
“Implement a web and mobile based employee tracking system that tracks field employees and increases efficiency by means of monitoring employee activity, absenteeism and productivity.
The following points can be noted here:
- 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 the organization to achieve its objectives. It is by their fulfillment, the organization attains its broad objectives.
It’s quite clear now that the Business Requirements explain the ‘why’ and ‘what’ part of the project, i.e. ‘what’ are the needs of the organization and ‘why’ these needs should be fulfilled, i.e. what benefits the organization aims to achieve through the fulfillment of these objectives.
Business Requirements Document
The Business Requirements are documented in the Business Requirement Document (BRD). It contains following elements:
- 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
What are Functional Requirements?
Functional Requirements are the functions that the system must perform in order to fulfill the Business Requirements. Thus functional requirements are connected with the solution or software being developed.
In the employee tracking case example mentioned above, the functional requirements can be written as:
- The system shall display the longitude and latitude of the employee through GPS.
- The system shall display the positions of the employees on Google map.
- The system shall allow the managers to send notifications to their subordinate field employees.
The following points can be noted:
- The functional requirements are always written from the point of view of the system.
- 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 the project, i.e. how the software solution will be able to meet the needs of the organization.
Functional Requirements Document
The functional requirements are documented in the Functional Requirement Document (FRD) or the Functional Requirements Specifications (FRS) document.
FRD contains following details:
- Purpose of the project
- Scope of the project
- Detailed functional requirements
- Non-functional requirements
- Representation of functional requirements using Information Architecture
Case in Point
The above differentiation can also be understood with the help of the following case, where we analyzed the requirements for our client, Shepherds List LLC. Here’s how we outlined the business and functional requirements for the web development project.
“Build a responsive online classifieds listing website where users can search and browse classifieds by Churches, Categories, City and State and can also view and rate other user’s profiles, and post classifieds for free as well as Job classifieds.”
- The system shall allow the user to post a classified by providing title, price, location, description, state/area, uploading a picture, and selecting a category.
- The system shall allow the rating of users on a scale of 1-5.
- The system shall allow the users to Search Classifieds by Keyword, Category, State, City and Church.
From the above discussion, it is clear that both business and functional requirements form the foundation of effective business analysis. Business requirements explain the “why” and “what” of a project and the functional requirements explain the “How” of the project.
The periodic review and benchmarking of the (developed) functional requirements with the business requirements ensures 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).”