Why Are Business & Functional Requirements Crucial – Their Influence On Client’s Budget

Seven / Blog / Why Are Business & Functional Requirements Crucial – Their Influence On Client’s Budget

Requirements Gathering

When you create a product from scratch, Requirements Gathering is a critical stage that no one likes. This is because both the executors from the customer’s side and the developers have to think about a large number of issues while facing a ton of work ahead of them. At the same time, it is necessary to somehow start collecting the required information and validate it with stakeholders, who usually are not active participants in the process but must confirm that the solutions proposed to them are acceptable.

To understand why there is so much controversy about which approach to gathering requirements to choose, we should look at a rough list of questions that need answers to get a product vision and move forward:

For which business purposes is the product created

Which specific user needs does it need to solve

In which cases and scenarios do users and entities interact with each other, and which parameters and characteristics are required for that

How many types of users should be involved to ensure automation of user interaction at the level of all business processes

What new data is generated as a result of certain operations, and what will they be used for in the future

What permissions and capabilities should users have according to their type

How to optimize the script of single or multiple operations for user convenience

What entities should the product be endowed with

Which informers should the system issue at the appropriate steps so that the user understands what is happening and how long it will last or how it will end

What is each type of user persona, what is he used to, what is important to him, what can he expect from a new product, and what does he not want here

What checks should be applied to ensure the validity of all calculations and results

What characteristics and parameters should each entity have

How many functional units the resulting product should include

What data will the system operate on, and how many operations need to be performed

Other aspects complement spatial understanding of the product from the business requirements perspective

That’s quite a lot, isn’t it?

That is why Business Requirements and Functional Requirements are critical to the product’s success, the budget and time spent on its development, and the quality of its technical implementation. After all, this information collected during the Project Discovery stage, serves as the basis for forming all technical requirements.

That is why there are several approaches to dealing with it faster, easier, and more effectively.

Flexible Methodologies

PMI, 6th edition

Extreme Programming

We have long been convinced from our experience that everything depends on the volume of the product and its business logic, budget and deadline.

Product Types

A large product with 1+ years of development time and over 50 team members

A small-sized product with less than 0.5 years of development time and up to 25 people

A medium-sized product with 0.5 - 1 year of development time and up to 50 team members

A small-sized product with a few months of development time and up to 10 team members

Warning! When the budget is limited, the deadline is actually not of decisive importance. Therefore, you should choose an approach that prevents the preparation and validation of requirements before the start of product programming to minimize the costs of changes and revisions.

How do you know what’s right for your product?

When and for what scope of work are the requirements prepared?

Flexible Methodologies

Step-by-step preparation of requirements, which involves gathering requirements for functionality planned for a sprint or iteration.

Extreme Programming

The ongoing negotiation of requirements, sometimes daily, for functionality under development and with little lead time.

PMI, 6th edition

Complete preparation and validation of business requirements before starting product programming.

Although we should note that often tight development timelines can be a wrong reason for choosing extreme programming or agile methodologies. The argument is that there is an urgent need to develop an early product version to demonstrate to potential clients or investors as soon as possible.

However, if the budget limit is still there, there is something one must remember. Requirements that are hastily collected for a part of the product and not validated through the prism of a holistic vision of the complete functionality ALWAYS entail overspending. For numerous changes and revisions in the future and delay the launch of the product as well. At the same time, the funds spent on such changes and modifications can be safely regarded as wasted.

Comparison of budget, timeline: qualities of the same product with different approaches.

Extreme Programming

The most expensive, most protracted, and least amount of quality.

Flexible Methodologies

More expensive, more protracted, and produce less qualitative compared to RMI.

PMI, 6th edition

The cheapest, fastest, highest quality.

However, no matter how accurately the Requirements are explored and set during Project Discovery, still in the process of software development, teams and customers face Clarifications to requirements, their Expansion, Change, and, as a result, revisions. The development team engaged in programming process does not like all this at all, and the customers do not like the bills for their implementation. However, experience shows that it is necessary to be guided by what primarily limits the Customer and properly accept the consequences.

Comparison of scope of changes, revisions, refactoring and architecture changes.

Extreme Programming

The largest number of changes and modifications, refactoring, and architecture changes.

Flexible Methodologies

Lots of changes and revisions, refactoring, and architecture changes.

PMI, 6th edition

The least number of changes and revisions, refactoring, and architecture changes.

Of course, the domain expertise that the team possesses and the availability of relevant experiences also play an essential role in the quality of requirements gathering and the number of subsequent changes and revisions. As well as the participation and involvement of the customer in this process. Therefore, the best result is always at the intersection of all the aforementioned factors.

Have a good choice!